Day 13: Need a Patch Stat!

Today's task was a fruitful experience in using the diff command in a Unix shell to compare a couple of example files.  This simple command proved to be "very powerful" (something Dr. Manaris seems to say about all the Unix commands we have learned in Operating Systems).  In reading TOS Chapter 7, our team can now formally submit a patch to the Sugar software with our changes involving the removal of white space and the new line character (i.e. \n) from the username field.  In using the diff command on my desktop PC running Ubuntu 10.04, I was able to see the changes in the two files printed to the terminal.  Comparing directories produced the same results, but with a larger listing showing multiple changes in different files.

Creating a patch file seems like the way to go in getting our fix committed to the code base.  Something like the following should do the trick while in the directory containing the files:

patch < model.patch window.patch

I went a little further to discover how to create the same effect in MS-DOS.  As it turns out, there is the same single command, fc, that takes two files, compares them, and outputs the results to the terminal.  I do not like to think that this command prompt has died, but it has not surfaced in my academic learning.  But, maybe that's just the point, I am to learn Unix and to discover MS-DOS.  One thing I noticed, the fc command is unable to compare two Microsoft Word documents, possibly because of all the specialized formatting in the background of every document.  Simple text files created using Notepad use the ANSI Encoding attribute, so they can be used appropriately when comparing the files.

Day 12: First Submission

After staying ahead of schedule for about a week, we were finally ready to submit our fix.  Our team member, Megan, adjusted some of the white space in the code that would have worked otherwise, but since Python is sensitive with things like its indents, it was causing the program to crash while messing with the input box for the user name.  We are currently waiting for a response from the developers to see if they will accept the fix, or possibly recommend some additional alterations of their own.

Since it seems I cannot post the files themselves that we modified for the fix, I can only say the following were affected:

• window.py
• model.py

Day 11: CS Symposium

Today's event was the 5th Alumni Symposium for the Computer Science Department at the College of Charleston.  We all sat down to listen to a "3 minute madness" presentation by each of the presenters.  Between the information presented by each person, I was hearing the same concepts taught to us by the Software Engineering courses.  There was much to do about the proper gathering of requirements and communication among people involved in a software project.

It was refreshing to hear about what these representatives look for in a qualified candidate in hiring someone for  a position in their companies.  The fact that one need not know everything there is about computer science in the general sense, but rather know the specifics of selected pieces in order to acquire the job wanted, is the idea I try to follow.  I actually became interested in the database side of things in CS, and I am taking up a Microsoft Certification course to be a DBA starting March 2nd of this year.  In the end, I consider the Symposium to have been a great experience for all the CS students to get an idea of how their skills will be applied at the job of their choice.

Day 10: Target Unconfirmed?

We have now decided on a bug for our team's project to pursue in hopes of resolving an issue with ticket #2485.  The link leads to a description of the bug, telling interested users about an Unconfirmed bug(?) where students using the Sugar software were able to enter leading and trailing white space before entering a username.  Our team member Jordan has already come upon a solution to the problem; since the code is written in Python, we will use the .strip() command to shrink the username to the remaining text.

Just after e-mailing the developers about this potential problem, Walter Bender, one of the lead developers, replied both in a comment to the bug and in an e-mail to the developers list:

"Be careful here: some students are using the name field to input a multi-line emoticon graphic as their name. I don't worry too much about white-space in single-line names, but it could matter in a multi-line name."

An emoticon (i.e. the smiley face graphics commonly seen in forums) does present a problem in using the .strip() Python command.  Any options in the .strip(<option>) command are for characters only.  Somehow, these students have been able to place graphics into the supposed text-only box and we need a solution as to how to either remove the use of emoticons or convert the graphic to its text equivalent (that way the .strip() command can remove the white space present in multiple lines).

Day 9: Bug Problem

I just completed another activity assigned to the class as a way to introduce ourselves to the bug tracking side of software development.  This activity involved navigating the bug tracker in order to create an understanding of our project's layout in terms of tracking bugs.  I found the oldest bug to have a ticket number of #17, assigned the status of assigned, and given a milestone as to when the bug was discovered (in this case, at v0.86).

The bug itself is causing a problem with the Sugar emulator used to test and develop the code.  Upon reading the history and some of the comments made about the bug, it seems it is a cross-functional instance where Xephyr is turning off access control because the "Sugar-Emulator uses the '-ac' flag in the Xephyr command line."  This just means other programs can run via a USB drive or some other forms of I/O and take over without the ability to kill them while the Sugar code is in execution.

Creating an account in the bug tracker, so we can get notifications of future bugs, is as easy as signing up for an e-mail account.  Simply click the Register link at the top of the page and enter the essential information.

Submitting a bug report has been something I have known how to do since my experience with Relic's games.  Their system is well organized, in that if the program crashes, a Bug Report pops up and allows the user to enter the information to better understand the problem.  Upon reading TOS, Chapter 6, I now know a standard by which to submit a bug in order to get the proper response to which it deserves ("Never underestimate the power of attention").

As far as reproducing a bug, I have come across a case where the instructions to reproduce the bug are given in the comments!  They are the following for ticket #297:

• Use Browse
• hover slowly over a link until the cursor changes
• the pointing finger should be at the position you were hovering - but it is already over half of the lin

In my reproduction of this bug I have experienced no form of failure.  I read on to find that the issue had been resolved with a patch for some instances/distributions (including my own).  It was suggested that the bug be moved from a status of blocker to critical for the remaining distributions.

In the end, this activity brought about a change in life for me, in terms of performing a proper bug investigation and submission.

Day 8: Practice Build

Today's task was similar to the previous day's events.  We had an activity that allowed us to retrieve and build the source code of a simple project as an example for future use.  However, our team had already done this step in the development of our project with Sugar.  The activity required us to check out the latest version of Freeciv (a game) using Subversion and the terminal commands:

svn co svn://svn.gna.org/svn/freeciv/trunk freeciv
svn update (in the Freeciv directory)

This process was similar to that of getting the source code for Sugar, in that we received a clone of the source from the repository and issued the same update command in order to acquire the latest version.  The next step in the activity with Freeciv differed from that in building Sugar.  Instead of getting any of the dependencies manually, like in the activity, Ubuntu recognized any packages outstanding that were required for the Sugar code and installed them alongside the code during the installation process ("This is where Linux distributions shine" TOS).

See the link in the Day 7 post for the instructions on how to install and build the Sugar code.

Day 7: Get the Source, Get the Build

Saturday's meeting:

Today we had the chance to install the Sugar application on Ubuntu.  First, we installed the application using the following command in Ubuntu's terminal:

sudo apt-get install sugar

Second, after installation we had no clue where the application was located in the File System, so we searched for about a half hour.  To our surprise, the application runs as another session in Ubuntu, or in other words instead of using the default GNOME session, one needs to switch to the Sugar session while at the log in screen in order to run the application.  Lastly, one needs to download some activities to run in Sugar, the most useful being the Surf browser activity because the Sugar documentation for installation had recommended this browser as it is the only one that cooperates with the system.

As far as getting the source code and building Sugar our team member, Megan, found the gold mine in terms of useful documentation.  The following wiki, sugar-jhbuild, gives a detailed description of the installation process.