Planning for POSSCON and Sqwashing Another Bug

During our group meeting yesterday, I tackled a small bug (0011257) found in VTK/Utilities/octree/octree_curser.cxx.  The bug itself was very simple; One of the conditional statements "if ( axis < 0 || axis >= (1<<d_) )" had to be changed to "if ( axis < 0 || axis >= d_) )".  The way it was before, if the class was already loaded elsewhere, then it would cause an error.

I made the change to the file in my branch of the code, and then went through the steps to commit my code.  I did run into a small problem of not remembering my keyring password, so I did not complete the git commit, but I should be able to get that submitted soon.

As far as POSSCON planning goes, I read through the list of speakers that will be there.  There are a few individuals that I'd enjoy having a conversation with.  Below are the individuals that are most interesting imo:

• Dr. Jihad S. Obeid - CoEE Endowed Chair in Biomedical Informatics at the MUSC
• Dr. Dan Russler - VP Clinical Informatics, Oracle Health Sciences Strategy
• Walter Bender - Founder & Exec. Dir. - Sugar Labs, Co-founder One Laptop per Child
• Sebastian Dziallas - Engineering Manager, Sugar on a Stick (SoaS)
• David Nalley - Community Manager, CloudStack
• Mel Chua - Hacker, Red Hat Community Leadership Team

Spring Break

Over Spring Break, I tried to think as little about school work as possible.  That being said, I did make sure to read the daily VTK digest via the mailing list to keep up to date with the current VTK news.

Last night, I started to play with the code a bit.  There are a few bugs from the timeline that I think I could work on personally.  Next time the group meets, we should be able to get another bug finished and submitted.  I'm hoping that I will be able to use my branch of the project to commit the changes.

Creating a Timeline and Getting into Git

Our group met on Sunday evening to create a timeline for us to adhere to for the remainder of the semester.  This involved finalising our selection of bugs, deciding how much time to allocate to each bug based on severity and complexity, and roughly choosing an order in which to tackle them.

Out of the bugs we chose, one of them seems difficult, and will be worked on steadily for the rest of the semester.  For the remaining bugs, we are anticipating being able to squash and submit one bug per week.

In addition to creating a timeline, I also created my own branch of the project on the project's version tracker site.  Up until now, my project was built using the distributed source make files.  For us to submit our first bug, we were using Glen's machine, because he had already  set up Git.

To do this, I first had to set up an account on the project's version manager site.  Then I installed Git on my machine and linked it to my account on the project's site.  Finally, I create my own branch, which I named "bugSquashing".  Now, I can work with my own copy of the project, and commit my version after changes have been made.

Patch/diff Exercises

TOS Exercises:  7.2.2, 7.8, 7.9

7.2.2 - Testing the 'diff' command

When using the '-u' flag for the diff command, the output is changed to be more robust.  The entire contents of the file are shown as well as the lines that were removed and added.  Without the '-u' command, only the modified lines are displayed.

$ diff -u hello.c.punct hello.c

--- hello.c.punct       2011-02-24 11:45:00.000000000 -0500

+++ hello.c     2011-02-24 11:44:19.000000000 -0500

@@ -5,6 +5,6 @@

 #include <stdio.h>

 int main() {

-   printf("Hello, World!\n");

+   printf("Hello, World.\n");

    return 0;

 }

$ diff hello.c.punct hello.c

8c8

<    printf("Hello, World!\n");

---

>    printf("Hello, World.\n");

7.8 - Creating a patch file

First, I created a file called 'foo' with the contents 'bar' using vi editor.

To make the patch file, I entered the command:

$ diff -u /dev/null foo > foo-1.0.patch

Next I deleted the file 'foo' in order to test the patch.

$ rm foo

To apply the patch, I typed the following command:

$ patch < foo-1.0.patch

Then I checked the contents of the file:

$ cat foo

bar

Success!  A patch file was created, and applied successfully.

7.9 - Patch echo

I followed the 7.9 Exercise steps (since they are explicitly listed out, it would be redundant for me to explain the process).

Everything worked as it should.  I now know how to create patches!  Cool!

Bug Squashed

We had a very productive group meeting this morning.  Up until now, we had come up with several methods of squashing the bug, but were having minor problems.

After some back and forth on the bug page's message board, we received some helpful advice from a developer named David Doria.  He gave us a link to the vtkSTLWriter Class documentation.  Fixing the bug ended up being incredibly simple.  The necessary steps were:

1. Add a conditional statement
2. Add a cout with the warning text
3. Modify the .h file to include a function call in the source code

As far as submitting the code, we all found various wiki posts about submitting, but it wasn't until Glen found a detailed step by step process that we were able to get anywhere with submission.  The commit process is basically a sequence of git and ssh commands (this process has been posted on our wiki).

Unfortunately, we were halted in the commit process due to lack of authorization.  An e-mail was sent out to the developer's mailing list, and hopefully we will be authorized to submit the code soon.

Alumni Symposium

Last Tuesday was the Alumni Symposium.  It was really nice to hear the different viewpoints of individuals who are now successfully pursuing Graduate school, industry, or starting their own business.  Particularly, I was interested in the advice that they all had to give.

The overall advice was to be proactive in keeping up with new technologies and  technological breakthroughs.  It was also advised to get involved in an OpenSource project, and learn how to code for mobile devices.  Fortunately, our Software Engineering course is providing the experience of participating in an OpenSource project.

I have always wanted to learn how to program for the Android OS.  Their advice has reinforced my interest in writing a mobile device app.  In my spare time, I will try to be more active in pursuing this goal.

Squashing a Bug

On Tuesday after class we decided to scan the VTK BugTracker again to select a different bug to work on.  After looking at all of the bugs (yes we looked at every open bug) we decided to work on "0010854: vtkSTLWriter should warn when input is not all written".


Basically, vtkSTLWriter only writes up to 3 points for each polygon, however, there is no limit to the number of points that can be input. This is how it is meant to function. The problem is that there is no alert to the user when not all of the input is being used. So, whenever the input exceeds 3 points, the user should be warned that the output does not reflect the input.

We then decided on a strategy for tackling the bug.

1. Locate the vtkSTLWriter code.
2. Incrementally count the number of points passed to the method in the points list.
3. Implement a conditional statement to check the number of points (whether or not it exceeds 3).
4. If True, display warning message via standard output to the user informing them that only the first 3 points were being used.

We also located the segment of code that handles vtkSTLWriter.  The fix should not be too difficult, and hopefully we will be able to have our submitted code approved by the revision committee.

Overall, this was a very productive meeting.