Patches

In chapter 7 of the Teaching Open Source book, we are learning how to create, submit, and incorporate patches.  We are currently in the process of submitting our bug fix to the Sugar Labs project so this is timely. 

The first exercise was to note the differences when the -u option was used and not used in the patch command.  Here are the 2 commands and their outputs:

[megan.weaver@stono ~]$ diff hello.c.punct hello.c
6c6
<    printf("Hello, World.\n");
---
>    printf("Hello, World!\n");

[megan.weaver@stono ~]$ diff -u hello.c.punct hello.c
--- hello.c.punct       2011-02-23 13:11:09.000000000 -0500
+++ hello.c     2011-02-23 13:11:35.000000000 -0500
@@ -3,6 +3,6 @@
 #include <stdio.h>
 int main() {
-   printf("Hello, World.\n");
+   printf("Hello, World!\n");
    return 0;
 }
The -u command shows a lot more information in the output.

In the next exercise, we changed a file in core utilities and created a patch file from the differences.  The change was to the echo.c file.  The change resulted in the echoed string being reverse.

Fixing Our Bug

What seemed like a relatively simple bug to fix turned out to be a little complicated.  The person who posted the bug suggested that any white space before and after the user's name should be trimmed.  We emailed the developers' list to let them know that we were interested in tackling the bug, and to ask them where we could find the code. 

Bringing this issue to their attention caused quite a string of emails about how making this change could negatively affect some users.  There are some users who choose to add white space in their user name to make a picture (emoticon).  We sort of understood the issue, but I wanted to make sure that we could duplicate this type of user name so that we could test our fix on those situations.  We followed a link in one of the developers' emails to a blog that included a picture of the multi line user names so we could see what it looked like.  Then it took a while to actually implement one.  It's not actually possible to type a new line character into that field.  We were finally able to make it work by typing the multi line emoticon into the Write activity and then pasting it into the user name field.

Once we were able to reproduce the situation, we could attempt to fix the problem.  We assumed that when first creating an account, a user would only enter a name with no special characters or new lines.  In this file, we simply trimmed (strip()) the name before saving it.  Once logged into Sugar, the user has the option of changing their name in Settings.  In this file, we check to see if any of the characters were a new line character.  If that were true, we wouldn't strip the white space.  If it were false, we assumed it was just a normal name that only included letters so we stripped the white space.

The Sugar Labs wiki didn't give instructions for submitting a bug fix.  To learn more about this process, Jordan emailed the developers' list again and attached the 2 files that we changed.  I think he received a reply stating that they agreed with our changes.  Not sure yet what will be done with them.

A New Adventure...

Tuesday was the annual CS Alumni Symposium.  There were about 9 alum present who told us a little about their current jobs/projects, gave us some advice for preparing for jobs, and answered questions.  The most helpful thing I came away with was that it is very important to be working on some project(s) outside of school. 

I was a little discouraged because I haven't done any outside projects.  I haven't even had an internship.  At first, I thought maybe I could get more involved in the Sugar Labs project.  Then I remembered that a friend of mine asked (a while ago) if I would be interested in working on a website that he and his clients could use for his business.  At the time, I felt a little overwhelmed and didn't see how I could possibly accomplish the task.  Now, I do have some more time (since I'm not working this semester), and feel like I have learned enough since then that it would be possible.  I contacted him yesterday and asked if he would be interested in an Android app (and maybe a similar website later).  I have more interest in learning how to develop an Android app and think it would be less of an undertaking.  He thought that was a great idea and we plan to meet to discuss his requirements within the next week.

In the meantime, I have installed all the necessary tools to develop an app, and I'm working on the tutorials on the Android Developers' site.  So far, I've written the "Hello, Android" app.  It took a while to get the Android Emulator working, but I finally have my "Hello, Android" app running!

In this project, I'm hoping to use the design skills I'm using in my Software Architecture and Design course, get some more Java experience, and have a better understanding of a software project from start to finish.  I'm also thinking we'll need to have some sort of database involved for what he wants.  Though I've worked with databases and sequel statements before, it will be good to learn how to integrate a database into the program.

Thinking about this application for my friend has also given me an idea for a Sugar Labs activity.  I think it's something that could be simple enough to implement and release before the end of the semester, and then we could add functionality later on if we'd like to continue with it.  I'm going to present the idea to my team next time we meet.

Bug #2485

We selected bug #2485.  This is an issue either when a user first signs up for a Sugar user account, or when a user updates his/her user name in the settings.  Greenfeld created this ticket because he believes the user name should be trimmed if there are leading or trailing spaces. 

We found the bug by emailing the developers' mailing list and simply asking.  At first we had tried a search in the code, but our search returned many results, and we didn't really have a good idea of what words to search for.  It was much easier just to ask, and the developers were very responsive. 

It was fairly easy to fix the bug in the code once we found it (in the two different files).  Then we rebuilt the project and ran it to make sure it changed what we were intending. 

Although our bug seemed straightforward and easy to fix, the contributors on the mailing list brought up some issues and potential negatives effects that this fix might cause.  We think that there is a compromise for fixing this bug (i.e., in the initial setting but not in the update settings section).  In order to test the bug, we'll need to learn more about creating a user account with a "fancy name" since that is the feature that might be affected by changing the code.

Tracking Bugs

The Sugar Labs project uses Trac, "an enhanced wiki and issue tracking system for software development projects," which includes a bug tracking feature.  I was able to search for all open bugs and then sort them by Ticket #.  (I assumed tickets are assigned sequentially and would be in date order.)  The oldest I found was Ticket #17, which was opened on 11/12/08.  Apparently there was a problem with access control when using the Sugar Emulator.  From the description given, it sounded like an easy fix to make, but as I read further comments on the bug, several people tried and were unsuccessful at fixing the problem.  I also noticed that the bug was also reported on Ubuntu's Sugar issue tracking system.  It seems that the bug was fixed and the status changed to closed on that system.  I think that this bug is no longer a problem, but it was never changed to closed on the Sugar tracking system.  The status is still "New."

Creating an account on the Sugar Labs bug tracking system was very easy.  I guess they welcome comments and help from anyone willing to use and work with Sugar.

The bug my team has started working on is Ticket #2485.  It seems to be more of a feature that user "greenfeld" thinks should be included rather than a defect.  The issue is that a user can enter spaces before or after the user name, and the program does not automatically trim the extra spaces.  This bug was easy enough to reproduce using the Sugar Emulator.  There doesn't seem to be any information missing in the description since it is a pretty simple issue. 

The most recent "New" bugs I could find were all entered by m_anish within the last day or so.  Apparently Walter Bender looks at new bugs because he commented on several of these entries in the last hour.  Most of his comments revealed that he was unable to reproduce the reported bug.  When we asked about the bug that we would like to work on, Walter and others replied with concerns about changing the code in question.  It might affect other functionality.  Walter also added this concern to the ticket.

Freeciv

Got a bit of a late start on this task because of Ubuntu issues (again).  This is the second time I have somehow disabled my Ubuntu installation by running the Update Manager.  I think I will ignore it when it pops up from now on. 

Once I was able to uninstall and re-install Ubuntu, I started the process of getting the code and building Freeciv.  The TOS book spelled out the instructions in detail, but apparently they are for Fedora, not Ubuntu.  This didn't cause too much of a problem because most of the differences were easy to find by searching for them on Google.  I was able to figure out several of the more difficult ones thanks to my classmates' blogs (Brittany Johnson and Bobby Strickland). 

Part of the lesson in chapter 5 of the TOS book was that "Sometimes you follow all the instructions, and it still doesn't work."  This chapter walks through the instructions for building Freeciv and points out where information is missing and how to go about finding it.  I found it interesting that even the TOS book seemed to have left out some information when trying to teach about it so we had to improvise.  Good learning experience. 

Sugar Update:
About a week ago, we found a bug that we thought we could tackle.  After doing some searches in the many files of code, we sent an email to the developers' mailing list in hopes that someone could tell us right where the code we needed to look at was located.  Several people responded quickly (including Walter Bender, co-founder of OLPC), and we were able to fix the bug in class and build/run with the changes to see the difference.  That was an exciting moment for us! 

I'm not sure if they will let us check the code back in.  I assume there is some sort of screening process before they let just anyone work on the code and commit changes to the repository. 

Another important lesson from this was the possible side effects of fixing this bug.  Several developers responded with concerns that changing the code might negatively affect the use of "fancy names".  Something that we assumed was relatively straight-forward and simple affects other functionality that we didn't even know about. 

Building and Installing Sugar

Thanks to the great documentation on the wiki (http://wiki.sugarlabs.org/go/Development_Team/Jhbuild), this assignment was not too difficult, once I had Ubuntu set up on  my computer.  I had Ubuntu at one point, but I uninstalled it because the Sugar Emulator (that is available in the Ubuntu Software Center), messed up my mouse functionality.  When I tried to re-install Ubuntu, I kept getting an error message that I did not have permission to download the file.  I was at the CofC Computer Science Lab at that time (Saturday afternoon), and eventually realized that the network there was blocking the install.  When Ubuntu wouldn't work, I tried to install Fedora instead, thinking that might be a better match for Sugar anyway, since Sugar on a Stick is based on Fedora.  What I learned is that Ubuntu is much easier for beginners to install.  Fedora requires you to set up your partitions manually for the dual boot mode.  I was hesitant about this, not wanting to erase all my Windows files, and I eventually gave up because I couldn't get it to work. 

I have learned a valuable lesson with these projects (projects in which I don't really know what I'm doing, and I'm just learning what I can along the way).  When I get to the point of extreme frustration and irritability, it's best to leave the project for a little while and come back to it later when I'm in a better frame of mind.  And so I left the project alone for the rest of the evening and decided to tackle it on Sunday.

In the meantime, I was thinking about the different posts I had read on the wiki.  I remembered reading about sugar-jhbuild in the FLOSS Manual for creating activities.  At the time, I didn't think much about it because the author did not recommend using this method.  In thinking about it further, though, he wasn't recommending it because his audience was wanting to run a version of sugar in which they could test their activities.  Our goal at this point was not to simply run sugar, but to get the source, build it and then run it. 

So I found the instructions on the wiki (above) for using sugar-jhbuild.  The instructions were straightforward (all executed from command line) but took a while to execute (at least a half hour).  I have Ubuntu version 10.04, and the instructions point out that only version 9.10 is supported.  I didn't want to uninstall and re-install Ubuntu again (that would be 4 times, actually), so I decided to try it on my version (hoping that maybe the wiki just hadn't been updated recently).  The build seemed to work fine, except there were many errors that I chose to ignore when given the option.  (I assume these had something to do with using the unsupprted Ubuntu version.)  When I ran the program, it seemed to work fine, except that none of the activities worked (probably because of the errors I ignored). 

There's also a package called "sweets" that is used for developing the core of Sugar.  We'd like to look into that a little more to see if that will be a better route for us.

I am pleased with our progress so far.  The bug that we are considering has to do with the user's login, and I think we have what we need to work on that.  We would still like to get the activities working so we can explore those source packages as well.