As the title already gave away, the latest patch we submitted on gerrit has finally built successfully
The patch page itself is here
Now we just have to wait and hear what they say about our code, which is probably going to be another mountainous challenge to deal with, but that’s what we signed up for after all …
It has been the fifth time that we have re-forked our repository as new and re-submitted the patch. As I write, I am cloning a fresh fork for the 5th time.
The problem is that patch submitting from a new repository seems to be pretty easy. But once that patch fails (for simple reasons sometimes), editing the code and re-submitting the patch becomes a pain because git begins messing up with previous commits. Yesterday even strange duplicate codes were showing up in my local file. So the only choice is to delete my fork and create a new fresh one, apply changes and submit the patch. There is definitely an easier way, but git is not making it easier for us.
One good thing that happened is that now we can actually see the log for the Jenkins build, which tells us why something fails.
If the fifth fork fails and we have to do this all over again, … it’s table turning time.
Two days after the first patch was submitted, we received two comments from the reviewers: one saying that our commit title was not good (too long and doesn’t contain bug number). So we needed to resubmit the patch.
But that wasn’t a piece of cake. For some reason, the logerrit review submitting system kept giving errors. 
Googling the error didn’t produce any worthy solution (or I wasn’t able to see the worth in the solutions suggested) and they didn’t respond when we reached out to them. Fortunately, I used another system of submitting using git-review.
This time, the patch got submitted again, but the Jenkins building tool still just emailed me back saying that the build failed again. I am currently building the project in my local and see what happens …
Finally our efforts are ready to see sunlight!! My fear that I would be work-less all week was reverted and I managed to submit our code patch for review. The process was not easy and LibreOffice’s explanation of how to submit a patch was kind of confusing … or we were confused somehow. As I posted it last time, this are instructions they posted:
First, we misinterpreted the first line to mean that we create a new branch from the terminal, when what we have to do was pick an existing local branch that is already in the github repository. Actually it is not even necessary to find a non-master branch as I submitted the patch from the master branch of my forked, updated repository. Github says that it is always better not to used master for stuff, but I don’t see any eminent danger here.
Second I did not use the “add file” part at all since my branch is already up to date with my local, and we spent most of our time last time trying to add individual files. And the commit has already been done while pushing changes from local to github.
In general, if one is working in a branch that is already in sync with the local where all the changes are committed, all they have to do is the last line (./logerrit …), which will give them a little more pain about Change-IDs. Once, that is solved, the patch will be submitted.
Anyway, I set the person who posted the bug as a reviewer (as he requested) and our code is proudly sitting and waiting for review (as you can see it in the link below)
https://gerrit.libreoffice.org/#/c/23668
Our bug was relatively simple, and there is a large possibility that our code was not perfect at all, but I feel great about actually going through most of the process of contributing code to an open source project. What is the next step? Maybe another bug? …
In short, patch submitting over the weekend + Monday did not work out. We added ourselves as members of the developer list and began the process of submitting the path, following this process
However, after we created a new branch, we are having trouble making it sync with github and add all our file changes using the add command. The errors also include a mismatch of email addresses between gerrit and github (author email address does not match your user account) which doesn’t make sense because Shona had the same email address setup for both systems.
Anyway, that is where we are now, and it is very likely that we will be on hiatus until next Tuesday as my awesome teammate (she made me say it … but I agree) is going to a codeathon in California, and my build is broken 😦 😦 But I will try my best to continue working on it by possibly cloning her already updated code. We shall see …
This week, Shona and I have been mainly working on transferring our solution code from our local only copy, where we have been working on, to a forked copy of the source code connected to github. After pushing the code to github, we worked on connecting our system with gerrit, LibreOffice’s code review system where they review code before submission.
The gerrit setup included some straight-forward command line work as outlined on LibreOffice’s developers page. We are currently in the process of adding ourselves to LO’s developers list (a requirement before one submits a patch in gerrit), a process currently stalled due to email dysfunction during our last meeting yesterday. We are hoping we will submit the patch for review over the weekend.
Fstream did save our lives, because we have a strong feeling that we have actually fixed the bug! But first, I need to calm myself down and go over a few problems we encountered before we caught the aforementioned feeling.
After we set up file output, we began testing our new function by inserting pictures of varied sizes to see what the function does to them and how it changes their final dimensions. This led to us finding out that pictures that are bigger than the slide remain untouched (like we want them to) but when pictures smaller than the slide are entered, the system crashes. We stopped our class meeting on Wednesday after this dreadful discovery.
When we met again tonight, therefore, we inserted more outputs (mostly Shona’s not very nice one-liner opinions about me!) to see how far into the function the system goes in before crashing. When we opened the text file after the next crash, Shona’s opinons were ALL over the page. What a nightmare! It turns out that our ‘while’ statement that checks to see if the picture was smaller than the slide was going on forever, and we could have easily used an ‘if’ statement in stead. And we did that. And our function worked as expected.
After the excitement that we might actually have fixed a bug, we also found out that we both love making lists. The night couldn’t have gone any better! So, we made a list of what is left for us to do which looks something like this:
And we can’t wait until the crossing-off starts. That’s always the fun part.
Last time we met, Shona and I had discovered that our function createSIZEFILL was not doing what it was supposed to, or rather doing a lot of what it was supposed to. So it was clear that there is something Impress is doing with the size and dimensions of the photos and the slides that we could not understand.
Today, our first solution for understanding how the dimensions and units work was to find out the dimension of our sample picture and the slides and try to hard-code something that would give us the result we want. After spending half an hour trying to convert pixels to inches, (O but now we know that there is a thing called DPI and it’s a fancy name for Dots Per Inch!) we figured we were headed to a dead-end any way since we do not know if the system is going to recognize inches or whatever unit.
So it was necessary that know what was going on behind the scenes; what picture dimensions it was receiving and what slide dimension it is assuming and what the unit might be. We initially had tried to ‘cout’ things but we weren’t sure where things were going to be ‘cout’ed. Therefore, file output was the better option. I personally hated fstream in C++, because there was always something wrong either with the creation of files or their eventual location. But this time, it worked in the first try!
Now we can see what values we are working on and can output how the variables change in our every try. If we can see trends of change, it would be easy to debug dysfunctional code. Also, we kinda white-boarded!
Break is cool and all, but these days LibreOffice is knocking my head with a rock. It would have been great if it was about the bug we are working on, but no, I am back to build problems. Due to some problems in my first already built code, I decided to download a new archive and build it, but it keeps failing for several reasons (Fork Processing error, gtk version, … ) I even installed a new Ubuntu 15, but I still do not know if it is a problem with my system or some new changes they committed to the code. It is truly frustrating to think about how much progress I could have made in the bug solving if I was not spending my time on this.
Complaining aside though, we did make a tiny bit progress in the bug at least since my last blog. So where were we? Yeah, scope problem. We solved that problem quickly enough by finding the header file that contained all definitions of functions and variables. So we defined our new check-box variable “pFILLCheck” and our new function “createFILLSize” in the header file as follows.
Once the necessary stuff is declared in the scope, we ran the program again, but didn’t get the result we wanted. We found out that even the function of the “Keep Aspect Ratio” check-box was disrupted (it didn’t produce any changes to the photo rendering it stretched in stead) It turned out the problem was with the arrangement of the if statements (we had several independent if statements in stead of one set connected by if else) we changed that and now we have something like this.
In this manner, the check-boxes function independently. We are aware that in this case, we do not have a mechanism to handle if both check-boxes are checked independently, but we are currently prioritizing the functioning of the fillsize feature independently, and this arrangement makes it easy to debug. Unfortunately though our function is not producing what we wanted. It sure is doing something by zooming extremely into the center of the photo, which is kind of what we are going for but in a very exaggerated manner. Eventually, the problem seems to be in our function and the next plan will be to have a close look into how it is functioning right now and how it could be fixed.
Last Wednesday, Shona and I started the implementation of our code in the two files that we have identified. So, we created the checkbox in the UI file and added the necessary, declarations, conditions and function in the cxx file.
Obviously, and as we have well expected, our code did not fix the problem right away. At first, we though the function itself was not doing what it was supposed to do, and attempted to in stead define a function that does something very simple, just so that we would know the function is actually implemented. It was not. And the error message we got (which I cannot display here, ’cause my code base is corrupted for some reason and is not building anymore… but coming soon…) indicated that the new check-box variable we declared was not declared in the scope.
At the moment, we are assuming that there is another file or element of code with which these variables are connected to, and our next step would be to find that out.
Now I am Open-Sourcing 