Since we have been dealing with bugs, we are now looking at the proper way to create and submit patches. My group, The A-Team, had already looked through this chapter together in preparation for correcting our Sugar - Pippy bug, but we had not completed the text's exercises as directed yet. Here is a summary of my experience with those exercises...
Exercise 7.2.2
This exercise is about exploring the diff command. This command allows you to compare two files and find any changes or differences. The basic format is diff <file1> <file2>. There is an option with the diff command, -u, that changes the output. Without this option the command only outputs what has been removed and what has been replaced. When you include this option it includes a lot more information about the file and what lines were changed. It actually includes the text of the file and shows the lines that have been removed and the lines that have been added in their context. I can see how this extra information could be very helpful! What if the line that was added to a file is simple x += 1;? There is no context to help the programmer decide if this was a good change!
Exercise 7.8
The wording in this exercise is actually rather confusing. By the time I did this exercise I thought I was pretty comfortable with the concept of patches and using the diff command. Actually, I would still hold to that assessment, but I didn't understand what I was supposed to create and compare. After looking at the blogs of my classmates, I made a decision about what to do and here are my results.
The exercise says first to create a file, foo, with the contents bar. So I started with creating a file, bar.txt, and placing a simple sentence in that file. Then I used a unix command to copy the bar file into a file called foo.txt. Finally, I created a patch file using the diff command in which I compared the empty file, /dev/null, with my foo file. The contents of the patch show the contents of the file being added. I'm still not sure that this is what the instructions intended, but it is what I did.
Exercise 7.9
This exercise asks us to create a patch on the echo command so that it echoes the words entered in reverse order. It was pretty easy to follow the directions provided until I reached the end of them, where the instruction was to enter the code $ ./configure$ make, which simply gave me error messages because ./configure$ does not exist. This turned out to be one of those silly mistakes that just requires a bit of space and some critical thought. Apparently, when I started working on this assignment I was more tired than I thought because I simply didn't recognize that the '$' implied a new prompt and the make command is a familiar and separate command. Like I said, one of those silly mistakes. Fortunately for me I did not spend too much time fussing with it. I chose to walk away and about an hour later had the unexpected epiphany!
Overall, this was an interesting a rather simple task. It was actually kind of fun to play with patches. This whole week or two has been very encouraging as we go forward with out projects!
Wednesday, February 23, 2011
Tuesday, February 22, 2011
Patching the Bug
As mentioned earlier in my blog, we were able to take our bug from creating the ticket to submitting the patch. Due to the simplicity of our bug this whole process was relatively easy!
Submitting the ticket was as simple as filling out the form on the bug-tracker website. As we began reading TOS Chapter 7 regarding patches our next set of questions were answered. We knew how to fix the problem - writing the new code was very simple, but what were we supposed to submit to fix it? The answer was a patch, creating by diff-ing the original file with the corrected file. So we ran that simple command and named our file according to the best-practices guidelines found in our text book.
Now that we had created the patch we had to figure out Sugar's procedure for submitting them. After some research on the IRC and websites we found two methods. The first is to simply attach the patch to the bug ticket. The second was to submit the patch to the git server using the git send-email command. Since we weren't sure which was best, we did both! And then there was the waiting for a response.
I was extremely pleased to check my email this morning and find a chain of sugar emails related to our patch. More specifically, accepting it!
I also had a little problem with my Ubuntu system, requiring me to check-out the current version of sugar again and was pleasantly surprised to find our fix already in place! Success!
Submitting the ticket was as simple as filling out the form on the bug-tracker website. As we began reading TOS Chapter 7 regarding patches our next set of questions were answered. We knew how to fix the problem - writing the new code was very simple, but what were we supposed to submit to fix it? The answer was a patch, creating by diff-ing the original file with the corrected file. So we ran that simple command and named our file according to the best-practices guidelines found in our text book.
Now that we had created the patch we had to figure out Sugar's procedure for submitting them. After some research on the IRC and websites we found two methods. The first is to simply attach the patch to the bug ticket. The second was to submit the patch to the git server using the git send-email command. Since we weren't sure which was best, we did both! And then there was the waiting for a response.
I was extremely pleased to check my email this morning and find a chain of sugar emails related to our patch. More specifically, accepting it!
I also had a little problem with my Ubuntu system, requiring me to check-out the current version of sugar again and was pleasantly surprised to find our fix already in place! Success!
Thursday, February 17, 2011
Thoughts for the Future
This week I attended College of Charleston's Computer Science Alumni Symposium. At this annual event, several CS Alumni are invited to return to the school and share their experiences and lessons learned with current students. I had also attended this event last year and found it to be a valuable time, so I was glad for the opportunity to participate again.
It was interesting to me how many of them recommended things that we are actually doing in this class. The advice to get involved with FOSS projects was repeated several times, along with the advice to find something that you are passionate about and get involved. We also were encouraged to start getting familiar with refactoring code because in your job you will most likely be working with code written by someone else, and it may not be the highest quality work. I was pleased to hear that our experiences in this class are exactly what people out in the corporate world are looking for in future employees.
Unfortunately I also found myself personally discouraged. I am eager to use this degree upon graduation, but at this time my life has so many unknowns after May. I know that women with families can pursue successful careers in this field because I know many who have, including the women in the CofC Computer Science Department. However, I seem to be in a holding pattern. All I know is that I will not be living in Charleston after the summer and I will be learning a whole lot about motherhood - which will always trump my career. I'm hopeful of finding some sort of part-time work that allows me to telecommute or perhaps start my own small consulting business, but I think for the first year, or even first few years, I will simply be working for myself, fostering that creativity that future employers will be looking for.
Here comes the real test - when school is over and life's changes clamor for my attention, will I take the initiative and make the time to exercise what I've learned? I know my education has given me the resources to continue learning on my own. I hope I will.
Here's to the future!
It was interesting to me how many of them recommended things that we are actually doing in this class. The advice to get involved with FOSS projects was repeated several times, along with the advice to find something that you are passionate about and get involved. We also were encouraged to start getting familiar with refactoring code because in your job you will most likely be working with code written by someone else, and it may not be the highest quality work. I was pleased to hear that our experiences in this class are exactly what people out in the corporate world are looking for in future employees.
Unfortunately I also found myself personally discouraged. I am eager to use this degree upon graduation, but at this time my life has so many unknowns after May. I know that women with families can pursue successful careers in this field because I know many who have, including the women in the CofC Computer Science Department. However, I seem to be in a holding pattern. All I know is that I will not be living in Charleston after the summer and I will be learning a whole lot about motherhood - which will always trump my career. I'm hopeful of finding some sort of part-time work that allows me to telecommute or perhaps start my own small consulting business, but I think for the first year, or even first few years, I will simply be working for myself, fostering that creativity that future employers will be looking for.
Here comes the real test - when school is over and life's changes clamor for my attention, will I take the initiative and make the time to exercise what I've learned? I know my education has given me the resources to continue learning on my own. I hope I will.
Here's to the future!
Wednesday, February 9, 2011
Who ya gonna call? BUG-BUSTERS!
Ok, maybe that was a little bit corny, but hey, that is me. At this point in our HFOSS projects we are getting involved with the bug tracker and solutions. We have been tasked to identify a bug and fix it. This assignment has had its ups and downs...let me explain.
At first we were all very optimistic because the bug tracker is very organized. At least it impressed us more than what we saw last semester in our projects. There is also a simple section of bugs that are supposed to be easy to fix - a good place for beginners. However, as we started reading those tickets we got confused. Many of the remaining open tickets either already had patches waiting for approval or the developers disagreed on the proper method of handling the bug reports or we still didn't understand what they were talking about. This was turning out a bit more complicated than it first appeared.
However, we continued searching and using the software and discovered an error in a Pippy program. Pippy is an activity for the Sugar OS that provides a simple Python programming environment. Since this is educational it comes with several sample programs built into it. One of these programs, Factorial, is supposed to do a factorial calculation on a number entered by the user. What it actually does is give the user an error message saying that a variable is never defined. The problem is that the coder refers to the user's number as 'number' in some places and as 'n' in other places - a common newbie or 'quick-and-dirty' coding mistake.
Since there was no bug ticket about this we thought maybe this error was left intentionally, but after communicating with the Activity Team on the IRC, they encouraged us to pursue a solution. Ah, sweet relief! I'm actually pleased that we get to see this bug all the way through discovery and solution. It's almost like we get a little bit of positive bonus learning experience! I know this project has and will continue to provide lots of 'extra' learning opportunities, but most of them tend to be unexpected complications, while this seems (for now) to be simply an opportunity to participate in an extra step. I'm pleased to say that I'm still quite optimistic about the project!
At first we were all very optimistic because the bug tracker is very organized. At least it impressed us more than what we saw last semester in our projects. There is also a simple section of bugs that are supposed to be easy to fix - a good place for beginners. However, as we started reading those tickets we got confused. Many of the remaining open tickets either already had patches waiting for approval or the developers disagreed on the proper method of handling the bug reports or we still didn't understand what they were talking about. This was turning out a bit more complicated than it first appeared.
However, we continued searching and using the software and discovered an error in a Pippy program. Pippy is an activity for the Sugar OS that provides a simple Python programming environment. Since this is educational it comes with several sample programs built into it. One of these programs, Factorial, is supposed to do a factorial calculation on a number entered by the user. What it actually does is give the user an error message saying that a variable is never defined. The problem is that the coder refers to the user's number as 'number' in some places and as 'n' in other places - a common newbie or 'quick-and-dirty' coding mistake.
Since there was no bug ticket about this we thought maybe this error was left intentionally, but after communicating with the Activity Team on the IRC, they encouraged us to pursue a solution. Ah, sweet relief! I'm actually pleased that we get to see this bug all the way through discovery and solution. It's almost like we get a little bit of positive bonus learning experience! I know this project has and will continue to provide lots of 'extra' learning opportunities, but most of them tend to be unexpected complications, while this seems (for now) to be simply an opportunity to participate in an extra step. I'm pleased to say that I'm still quite optimistic about the project!
Tuesday, February 8, 2011
Bugs - The Not-So-Sweet Side of Sugar
After getting Ubuntu back up and running I began rebuilding Sugar. This time I ran into more trouble than I did previously. Checking out the source code and running the dependency check went just as smoothly, albeit a little more slowly, than the last time. However, when I built it before I was able to run a simple command, sudo apt-get install <list_of_packages>, and include the list of missing dependencies. When this command ran it easily installed all of the dependencies. This time it didn't work. I had to run the command for each dependency and find the right order to do so. I also had to download an additional package, or set of packages, related to abiword which apparently does not come with my current version of Ubuntu. While this build took much longer than the first and involved a far more in-depth investigation, it was still successful.
I finally began investigating bugs and was quite impressed with the organization of the bug tracker. It was very easy to navigate and find different types of bugs, different ages of bugs, different priorities, etc. As I looked for the oldest open bug I found one, ticket #122 dates back to late 2008 and appears to have a current status of 'assigned.' This bug seems to be a documentation request about a missing link on the planet.sugarlabs.org website. This website is the collection of Sugar-related blogs. I expect that this hasn't been fixed, or at least it's status has been ignored, simply because it is so low on the priority list. Another bug that is actually related to how Sugar runs is ticket #245, which has been reopened. This is about two years old, but has been modified in the last few months and is a request for a spinning cursor, or some way to signal that the machine is thinking, as it loads a language tool. From the discussion, it seems that this was deemed unimportant because the load time for that tool is so small. It also seems that they group has made a decision and has whatever they want to fix it, but is waiting for the next release to commit.
Our next step was to join the bug tracker, which was very simple. Just click the button that says 'Register,' fill out the form, and voila! It was interesting to see how the appearance of the page changed and how much more information was available! I like the different views when you are logged in!
The third step was to find a bug and try to reproduce it. I was pretty excited about this challenge and found a new bug, ticket #2591, that I was really excited to try. This bug states that when a user in the Favorites view clicks and drags an activity icon over a different activity icon and drops it there, then the first activity will open when the second activity is selected! Fascinating, right? Well, I thought so until I tried to run the Sugar Emulator. While it worked just fine when I rebuilt it, it no longer does. I had to re-check it out, rebuild it, and then I found a new problem. Ubuntu's keyring manager is not accepting my password today and therefore interfering with my Sugar Emulator. So, instead of replicating this bug, I will be researching how to fix the keyring manager, or starting over from scratch. Yay!
As I begin that search and fix, I do not have time to triage some bugs. I hope to come back to that soon, but if I can't run Sugar, I can't proceed with anything else for the project, so that is taking priority...
I finally began investigating bugs and was quite impressed with the organization of the bug tracker. It was very easy to navigate and find different types of bugs, different ages of bugs, different priorities, etc. As I looked for the oldest open bug I found one, ticket #122 dates back to late 2008 and appears to have a current status of 'assigned.' This bug seems to be a documentation request about a missing link on the planet.sugarlabs.org website. This website is the collection of Sugar-related blogs. I expect that this hasn't been fixed, or at least it's status has been ignored, simply because it is so low on the priority list. Another bug that is actually related to how Sugar runs is ticket #245, which has been reopened. This is about two years old, but has been modified in the last few months and is a request for a spinning cursor, or some way to signal that the machine is thinking, as it loads a language tool. From the discussion, it seems that this was deemed unimportant because the load time for that tool is so small. It also seems that they group has made a decision and has whatever they want to fix it, but is waiting for the next release to commit.
Our next step was to join the bug tracker, which was very simple. Just click the button that says 'Register,' fill out the form, and voila! It was interesting to see how the appearance of the page changed and how much more information was available! I like the different views when you are logged in!
The third step was to find a bug and try to reproduce it. I was pretty excited about this challenge and found a new bug, ticket #2591, that I was really excited to try. This bug states that when a user in the Favorites view clicks and drags an activity icon over a different activity icon and drops it there, then the first activity will open when the second activity is selected! Fascinating, right? Well, I thought so until I tried to run the Sugar Emulator. While it worked just fine when I rebuilt it, it no longer does. I had to re-check it out, rebuild it, and then I found a new problem. Ubuntu's keyring manager is not accepting my password today and therefore interfering with my Sugar Emulator. So, instead of replicating this bug, I will be researching how to fix the keyring manager, or starting over from scratch. Yay!
As I begin that search and fix, I do not have time to triage some bugs. I hope to come back to that soon, but if I can't run Sugar, I can't proceed with anything else for the project, so that is taking priority...
Monday, February 7, 2011
Finding my way back...
After completing the Freeciv assignment for last class, I ran into some unexpected troubles. Some package that I was required to install managed to corrupt my Windows registry. When I returned to my computer later and rebooted I was unable to access either my Ubuntu system or my Windows user profile. Since mine was the only visible account with administrative privileges, I was rather stuck. When I booted into Safe Mode I was able to access my account and perform a back-up. After a few hours of emotional turmoil and backing up my computer, I was drained and had to walk away. Actually, I didn't walk away. I lied down right where I was and took a nap.
About an hour and a half later my dad, my personal Windows guru, called me to help me work out my problem. My dad has been a computer scientist working for Chevron for over 25 years and has a lot of experience with troubleshooting. He also seems to know Windows inside and out! He led me through a secret back door of Safe Mode to grant administrative privileges to another user profile. Here is the secret:
After this I still needed to get Ubuntu installed on my machine and catch up to where I was with my SugarLabs project. I was hesitant to use Wubi again since that allowed some damage to my Windows installation, but I am also not a fan of VirtualBox. I had heard of people booting into Ubuntu using a flash drive and began investigating a way to do that.
Most of the instructions I found were to have a fresh install every time you boot up, not a persistent boot. I finally found some instructions to create a persistent bootable Ubuntu flash drive. I admit I was nervous going into this but I didn't see another way, so I started following the instructions. To my utter delight and surprise, everything went smoothly! When it was time to use the flash drive I was a bit lost, though. The instructions show that during a boot the screen should show a few special keys for book options. Unfortunately, my screen does not, so I rebooted several times trying different keys mentioned in their example. Finally I chose F2 which brought me to the boot menu. I managed to figure out how to tell my computer to boot from the flash drive and tried it. AND IT WORKED!
In order to make sure that this was a persistent boot I changed a few settings and created a document. Then I rebooted to see if the changes stuck and they did! Now to make sure that Windows still booted properly...shut down the computer, remove flash drive, boot up...and Windows works fine! Finally, it was time to get back to SugarLabs. Maybe that is something better saved for another blog. Here, suffice it to say that I'm getting back on track. My registry is still not fixed so I will continue to work on that, along with using subversion for future backups, but I think that will be an ongoing learning process.
About an hour and a half later my dad, my personal Windows guru, called me to help me work out my problem. My dad has been a computer scientist working for Chevron for over 25 years and has a lot of experience with troubleshooting. He also seems to know Windows inside and out! He led me through a secret back door of Safe Mode to grant administrative privileges to another user profile. Here is the secret:
- In Safe Mode run a command terminal as administrator.
- Enter the command $ net localgroup administrators <UserProfile> /add
- At this point you can reboot in normal mode and access the user profile to which you just granted admin privileges.
After this I still needed to get Ubuntu installed on my machine and catch up to where I was with my SugarLabs project. I was hesitant to use Wubi again since that allowed some damage to my Windows installation, but I am also not a fan of VirtualBox. I had heard of people booting into Ubuntu using a flash drive and began investigating a way to do that.
Most of the instructions I found were to have a fresh install every time you boot up, not a persistent boot. I finally found some instructions to create a persistent bootable Ubuntu flash drive. I admit I was nervous going into this but I didn't see another way, so I started following the instructions. To my utter delight and surprise, everything went smoothly! When it was time to use the flash drive I was a bit lost, though. The instructions show that during a boot the screen should show a few special keys for book options. Unfortunately, my screen does not, so I rebooted several times trying different keys mentioned in their example. Finally I chose F2 which brought me to the boot menu. I managed to figure out how to tell my computer to boot from the flash drive and tried it. AND IT WORKED!
In order to make sure that this was a persistent boot I changed a few settings and created a document. Then I rebooted to see if the changes stuck and they did! Now to make sure that Windows still booted properly...shut down the computer, remove flash drive, boot up...and Windows works fine! Finally, it was time to get back to SugarLabs. Maybe that is something better saved for another blog. Here, suffice it to say that I'm getting back on track. My registry is still not fixed so I will continue to work on that, along with using subversion for future backups, but I think that will be an ongoing learning process.
Thursday, February 3, 2011
A True Programmer is ... Lazy
This week the class had an assignment to complete the checkout and build of Freeciv, as modeled by our textbook in Chapter 5. Knowing my schedule leading up to the due date, I began work promptly after the previous class. Unfortunately, I ran into some problems with installing some of the dependencies and when my research only confused me more, I chose to walk away for a while. Let me actually explain that process.
A big part of my confusion was translating the commands used in Fedora to the commands used in Ubuntu. When I finally figured out that I should just use the command I was already familiar with, sudo apt-get install <package>, this helped move me along. However, some of the packages couldn't be found. I then found the instructions to get those packages from their source website, downloaded them, and followed their install instructions. Thinking that my problems were over, I repeated my commands and discovered that the packages still could not be found. Then I remembered that last semester we had trouble with installing dependencies because they simply weren't where the system expected them to be, so I began looking for instructions to tell me how to fix that mapping problem. I tried what I found and it still didn't work. Frustrated, this is where I walked away.
I knew that most of the class was using Ubuntu, not Fedora, and would probably run into many of the same problems with dependencies, so I kept checking the class blogs to see if there was any helpful advice. Finally, this morning I found several recommending the use of the Synaptic Package Manager, instead of the terminal, to install the problem dependencies. Never having used Synaptic Package Manager, I thought that this would be another good thing to learn, since it seems to be so very helpful. I wasn't exactly sure which packages to install since so many appeared in my searches, so I just tried to cover my bases with the most recent version and all of its extensions (-dev, -doc, etc.). Having completed this, I moved on to the configure experience.
I attempted to run the command ./autogen.sh, but the terminal said that no such file could be found. That was fine since the book showed the same result. I followed their instructions and still ended up with the same error. Frustrated again, I opened the actual folder to see if the file existed and sure enough, it did! Why, then, could my computer not find it? I almost surrendered but then I realized something very important! This morning I had not returned the the Freeciv folder and was instead working from my home folder. I just love those small, easy, careless mistakes that can take hours to find! Anyway, the careless mistakes continued as I mis-typed the command in the Freeciv directory. When I finally got through my careless mistakes I finally had victory - the rest of the build was rather simple.
I thought this exercise was a good reminder of several things. First, it reminded me that sometimes you need to walk away and come back with a fresh perspective. Second, it reminded me to be extremely careful and mindful about spelling and directories - always check in those places first when you come across an unexpected error. Third, it reminded me that sometimes it is okay to be lazy. I don't mean lazy as in putting things off and doing barely enough to get by, but lazy in the sense of really using all of your resources. Knowing that most of the class used Ubuntu and would be blogging about their experiences gave me an extra set of resources to search. But I still had to be patient for them to appear when my own Google searches proved mostly useless.
I was also encouraged by one of chapter's closing comments. The author wrote, "Very few people know every detail about Autotools, or about any build tools. Experienced developers know as much as they need to know to get the job done, and they know where to look for help when they're stuck." I am getting a lot of practice knowing what to look for and where to find it this semester, but sometimes I still feel so lost and inexperienced. It helps to be reminded that experienced programmers still don't know everything - I just need to know how to learn it.
A big part of my confusion was translating the commands used in Fedora to the commands used in Ubuntu. When I finally figured out that I should just use the command I was already familiar with, sudo apt-get install <package>, this helped move me along. However, some of the packages couldn't be found. I then found the instructions to get those packages from their source website, downloaded them, and followed their install instructions. Thinking that my problems were over, I repeated my commands and discovered that the packages still could not be found. Then I remembered that last semester we had trouble with installing dependencies because they simply weren't where the system expected them to be, so I began looking for instructions to tell me how to fix that mapping problem. I tried what I found and it still didn't work. Frustrated, this is where I walked away.
I knew that most of the class was using Ubuntu, not Fedora, and would probably run into many of the same problems with dependencies, so I kept checking the class blogs to see if there was any helpful advice. Finally, this morning I found several recommending the use of the Synaptic Package Manager, instead of the terminal, to install the problem dependencies. Never having used Synaptic Package Manager, I thought that this would be another good thing to learn, since it seems to be so very helpful. I wasn't exactly sure which packages to install since so many appeared in my searches, so I just tried to cover my bases with the most recent version and all of its extensions (-dev, -doc, etc.). Having completed this, I moved on to the configure experience.
I attempted to run the command ./autogen.sh, but the terminal said that no such file could be found. That was fine since the book showed the same result. I followed their instructions and still ended up with the same error. Frustrated again, I opened the actual folder to see if the file existed and sure enough, it did! Why, then, could my computer not find it? I almost surrendered but then I realized something very important! This morning I had not returned the the Freeciv folder and was instead working from my home folder. I just love those small, easy, careless mistakes that can take hours to find! Anyway, the careless mistakes continued as I mis-typed the command in the Freeciv directory. When I finally got through my careless mistakes I finally had victory - the rest of the build was rather simple.
I thought this exercise was a good reminder of several things. First, it reminded me that sometimes you need to walk away and come back with a fresh perspective. Second, it reminded me to be extremely careful and mindful about spelling and directories - always check in those places first when you come across an unexpected error. Third, it reminded me that sometimes it is okay to be lazy. I don't mean lazy as in putting things off and doing barely enough to get by, but lazy in the sense of really using all of your resources. Knowing that most of the class used Ubuntu and would be blogging about their experiences gave me an extra set of resources to search. But I still had to be patient for them to appear when my own Google searches proved mostly useless.
I was also encouraged by one of chapter's closing comments. The author wrote, "Very few people know every detail about Autotools, or about any build tools. Experienced developers know as much as they need to know to get the job done, and they know where to look for help when they're stuck." I am getting a lot of practice knowing what to look for and where to find it this semester, but sometimes I still feel so lost and inexperienced. It helps to be reminded that experienced programmers still don't know everything - I just need to know how to learn it.
Subscribe to:
Posts (Atom)