Thursday, February 24, 2011

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!



Tuesday, February 22, 2011

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.

Thursday, February 17, 2011

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.

Thursday, February 10, 2011

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.

Tuesday, February 8, 2011

Bug Tracker Exercises

TOS Exercises: 6.4, 6.5, 6.6, 6.7


6.4
The oldest bug on the VTK Mantis BugTracker is dated: 2003-08-13 16:09.  The summary of the bug is "0000142: Application Error on Render after changing vtkImageActor DisplayExtent."  When the xMin was changed while viewing a 2048x2048x1 image, the image was being incorrectly wrapped in the viewer.  This bug was never reported to have been fixed, most likely because it is a minute problem, or it no longer exists with newer versions of VTK.  


Theoretically, if you decrease the xMin value of an image that is loaded with a pixel dimension, then there are a few ways to handle the area that is no longer needed:
1) You could re-render the image using a canvas with smaller dimensions.
2) Display whitespace in the area that is no longer being used because of the smaller image.
3) Wrap the image in the area that was initially defined, but no longer used.


The fact that the image is wrapping isn't necessarily a bug, but rather a preference of handling the modification.  Personally, I'd have the image and canvas re-rendered to fit the smaller pixel dimensions.


Maybe this bug wasn't officially worked on and fixed because newer versions of VTK have implemented different methods of handling image renders.


6.5
I had already created an account on the Mantis BugTracker.  This process involved filling out a basic info form submission and email verification response.  My username is perry.spy.


6.6
This is a work in progress.  Since we changed project focus, I have been having problems getting VTK built.  Although I have been making progress on a daily basis, errors are still being generated in the compilation stage of VTK installation.  Obtaining missing dependencies is the smallest of problems that I've had.  Currently, I'm running into issues where I've had to modify the file structure, create links between directories, and change CMake settings.  Hopefully I'll have VTK built soon...


As far as reproducing a bug, a vast majority of the bugs found on the VTK Mantis BugTracker are exceedingly specific, which makes reproducing them on my machine rather difficult.  For example, many describe errors involving specific hardware configuration, system configuration, or specific platforms.  All of which I would be unable to reproduce.


Furthermore, I think that the majority of the BUG documentation is good, based on the examples read in TOS 6.6.  By this, I mean that the bug summaries are good, platform version, system information, configuration, and steps to reproduce are all (for the most part) documented in each bug.


6.7
Triage, or prioritization based on severity of condition, is an excellent and necessary process with OpenSource projects due to the vast number of bugs, and few number of developers working on the issues.  All bugs should be reported, but not all bugs should be given equal time and effort in terms of bug fixing.  The Mantis BugTracker system that ITK and VTK use includes a triage system.  All bugs contain one of the following severity values: feature, trivial, text, tweak, minor, major, crash, and block.  Mantis BugTracker also gives you the option of sorting based on an assortment of bug attributes.  Clearly, sorting by severity is important for dedicated developers.


5 "major" bugs for VTK are:
*0011817: vtkRenderingPythonTkWidgets.dll cannot be found when trying to create a vtkTkRenderWidgetInteractor using vtkpython.exe
*0011810: VTK 5.6.1 fails to build against Tcl 8.6.1.1 due to errorline being declared private in the Tcl_Interp structure
*0011771: SetOrientation doesn't work for the vtkTextProperty of vtkAxis
*0011790: vtkBoxWidget2 does not respect interaction filters.
*0011739: Medical Image Properties from vtkMedicalImageReader2 always return null when loading a DICOM file


These bugs are of great severity because they are generally cross-platform, and have to do with modular component interaction errors, or necessary functionality.

Thursday, February 3, 2011

Freeciv

The task of building Freeciv was rather enjoyable compared to the other projects that I've tried to build in the past.  Maybe it's just that I've become more comfortable getting dependencies, or perhaps it was just taken more lightly since this was only an exercise.

Either way, the only real problems I ran into was having to get dependency packages, and that is more of an exhaustive process than a troubling one.  A few of them I downloaded manually by using "sudo apt-get install", but I also utilised the package manager.  There didn't seem to be any errors in Freeciv itself, or any added complexities of a unique install process that some I've encountered while building other projects in the past.

As far as ITK, I've gotten itk core built (the hardest part of that was figuring out how to use CMake).  Now I just need to build VTK, the visual application project that runs with ITK.

Tuesday, February 1, 2011

Downloading and Building and Installing! Oh my!

The first step was to download the most current ITK tar.gz from their site as well as installing CMake.  CMake is a cross-platform, open-source build system.  ITK uses CMake to control the software compilation process so that updates can be compiled more independently.  CMake can be downloaded as pre-compiled binaries, and therefore needs no installation itself.

First, make a directory to contain the ITK content:
$ sudo mkdir /usr/local/itk

Navigate into the itk directory:
$ cd /usr/local/itk

Extract the itk files: and delete the tar.gz:
$ sudo tar xvzf InsightToolkit-3.14.0.tar.gz

Delete the tar.gz, since it is no longer necessary:
$ sudo rm -rf InsightToolkit-3.14.0.tar.gz
Next, create a bin directory:
$ sudo mkdir /usr/local/itk/InsightToolkit-3.14.0/bin
 
Navigate into the bin directory: 
$ cd /usr/local/itk/InsightToolkit-3.14.0/bin

Run CMake to compile: 
$ sudo ccmake -DITK_USE_REVIEW=ON ..
 
This will open the CMake GUI.
Press 'c' to compile.

Wait for the compile to finish.
Press 'g' to generate the make files.

Now install:
$ sudo make -j4
$ sudo make install
 
Tada, ITK is now installed! 

Subversion

Subversion is a simple and powerful version management tool.  Fortunately, I have become quite comfortable using the svn commands from my summer internship at MUSC's BioInformatics department and also working on Dr. Manaris' Music Armonique Project.

The first step was to checkout 462playground/ from the stono.  This was done by entering the command:
$ svn checkout https://cirdles.cs.cofc.edu/repos/462playground/

Next, I created a new directory with the command:
$ svn mkdir perry

Then I created a test.txt file containing some text using vi editor, and added it to my directory with the command:
$ svn add test.txt

To commit my changes, I issued the command:
$ svn commit

Out of curiosity, I updated my checkout to see if any of our classmates had added anything new with the command:
$ svn update