During class on Thursday, we made our decision on what we would like to accomplish for the rest of the semester. We've decided to create a nutrition-based activity for Sugar. This would require us to learn how to create an activity on our own, and we weren't positive whether or not this would be a feasible task for this semester. For the weekend, we decided that it would be a good idea for each of us to attempt to try creating a Hello World activity in Sugar.
On Friday night, I was able to successfully compile and run a Hello World activity on my version of Sugar. I followed this guide to do so, and sent the information onto the other team members to try out. After a little work, it seems that everyone was able to do this (not perfectly, but I'd say close enough). Since we were able to complete this within a couple hours, I think it's safe to say that our idea is a reachable one.
The idea (at the moment) is to create an activity where the user will enter in what they've eaten for the day, and the system will return a rating on how well the user has balanced their nutrition for the day. This would be a great tool for younger kids, and would help them learn how to keep a well-balanced diet. We've talked a little about what each of our responsibilities are going to be as well. Responsibilities include the following:
1. Database design - We think we're going to use SQLite
2. GUI
3. Algorithm design - for the rating system
We're very early in developing ideas for the project at the moment, so some things will most likely change as we look more into detail about designing the activity. I have a bit of experiences, so I will most likely start out by spending time designing data tables for our activity.
In general, I think this is a great idea for our project. While it could turn out to be a heavy workload for us, the greatest thing about creating our own work is that we can set the bar where we need to. Of course, we will try to create reasonable goals throughout the semester. However if things work out well (and we've met our goals), we could very easily expand them (by adding new features, etc.). I'm excited about the project and I'm ready to get to work.
Monday, February 28, 2011
Wednesday, February 23, 2011
Experience using diff
Using the diff tutorial in TOS Chapter 7 turned out to be really useful. At first, we were stuck on how to go about formally submitting our bug fix for the string trimming problem. It turns out that Sugar uses these exact same practices that TOS teaches to create a patch.
7.2:
Some things I've noticed about diff:
1. It provides a very detailed report on the difference between the two provided (creation date, line differences, what's being added and removed, etc.).
2. The -u command displays all lines that remain unchanged after using diff. Not using -u only displays the lines that are different between the two files.
7.8:
This was a fairly simple exercise. Here's the steps I took to complete it:
1. Created a file called foo.txt and a file bar.txt.
2. I left the file 'foo' blank, and wrote "This is a test." in the file bar.txt
3. I used this command: diff -u bar.txt foo.txt > foo.patch
The contents of the file bar.txt are placed into foo.txt.
7.9:
Following 7.9 gave me a good idea how to go about applying what I've done for our own project in Sugar. I changed the lines of code that it asked (to create a reverse ordering of the output), and created a patch for it.
To do this, i followed these instructions:
1. Created a copy of the file using this: cp echo.c echo.c.reverse
2. Opened Gedit and modified the code of echo.c as it has instructed.
3. Created a patch for the file using this: diff -u src/echo.c.reverse src/echo.c > echo-reverse.output.patch
To test the changes, I used "./configure" to build the project, and "make" to created all of the out files that can be run. After running echo, it prints "reversed this is".
Some notes about our team:
We've come to a decision about our ideas for the rest of the semester, and we're all in agreement on creating a nutrition activity. Our goal for the weekend is for each of us to create a hello world activity, and make sure that we're able to do this successfully. If we're able to complete this by the weekend, I think that will be fair judgement on how difficult it would be for us to complete activity by the end of the semester.
7.2:
Some things I've noticed about diff:
1. It provides a very detailed report on the difference between the two provided (creation date, line differences, what's being added and removed, etc.).
2. The -u command displays all lines that remain unchanged after using diff. Not using -u only displays the lines that are different between the two files.
7.8:
This was a fairly simple exercise. Here's the steps I took to complete it:
1. Created a file called foo.txt and a file bar.txt.
2. I left the file 'foo' blank, and wrote "This is a test." in the file bar.txt
3. I used this command: diff -u bar.txt foo.txt > foo.patch
The contents of the file bar.txt are placed into foo.txt.
7.9:
Following 7.9 gave me a good idea how to go about applying what I've done for our own project in Sugar. I changed the lines of code that it asked (to create a reverse ordering of the output), and created a patch for it.
To do this, i followed these instructions:
1. Created a copy of the file using this: cp echo.c echo.c.reverse
2. Opened Gedit and modified the code of echo.c as it has instructed.
3. Created a patch for the file using this: diff -u src/echo.c.reverse src/echo.c > echo-reverse.output.patch
To test the changes, I used "./configure" to build the project, and "make" to created all of the out files that can be run. After running echo, it prints "reversed this is".
Some notes about our team:
We've come to a decision about our ideas for the rest of the semester, and we're all in agreement on creating a nutrition activity. Our goal for the weekend is for each of us to create a hello world activity, and make sure that we're able to do this successfully. If we're able to complete this by the weekend, I think that will be fair judgement on how difficult it would be for us to complete activity by the end of the semester.
Monday, February 21, 2011
Submitting Our Bug
We've had a pretty successful experience (so far) with submitting our fix for the name spacing issue. After class on Thursday, Megan managed to get the code to work successfully. Our code does the following two things:
1. When the user initially creates an account, the changes we've made trim any white space to the left and right of the user's name. Before our changes, the white space would have remained on the left and right side of the user's entry when creating the name.
2. When the user edits their name, the changes we've made will trim any white space to the left and right of the user's name, only if the user doesn't have any newline characters in the name. Before our changes, the white space would have remained on the left and right side of the user's entry when editing the name.
The comments made about our initial talk with the developers led us to include change #2. The developers noted that some users like to have multi-line names (that usually make some sort of picture). Trimming the space off the left and right sides would've made the names not display how those users would prefer them to. Since we check for the newline character, this is still an option for those users.
Today I submitted our fix to the development team, and telling them the solution we came up with in an email. I described the approach we took, and Walter replied saying that this was a reasonable approach to take.
For the future:
We've talked a little bit about what our plan is for the remainder of the semester. Megan mentioned the idea of creating our own simple activity. I think this would be a great idea, as long as it's a reasonable task. Creating an entire activity from scratch sounds hard at first, but there are plenty of guides and tutorials available for us to get started.
1. When the user initially creates an account, the changes we've made trim any white space to the left and right of the user's name. Before our changes, the white space would have remained on the left and right side of the user's entry when creating the name.
2. When the user edits their name, the changes we've made will trim any white space to the left and right of the user's name, only if the user doesn't have any newline characters in the name. Before our changes, the white space would have remained on the left and right side of the user's entry when editing the name.
The comments made about our initial talk with the developers led us to include change #2. The developers noted that some users like to have multi-line names (that usually make some sort of picture). Trimming the space off the left and right sides would've made the names not display how those users would prefer them to. Since we check for the newline character, this is still an option for those users.
Today I submitted our fix to the development team, and telling them the solution we came up with in an email. I described the approach we took, and Walter replied saying that this was a reasonable approach to take.
For the future:
We've talked a little bit about what our plan is for the remainder of the semester. Megan mentioned the idea of creating our own simple activity. I think this would be a great idea, as long as it's a reasonable task. Creating an entire activity from scratch sounds hard at first, but there are plenty of guides and tutorials available for us to get started.
Wednesday, February 16, 2011
Alumni Symposium
On Tuesday, the Alumni Symposium turned out to be a great event for Computer Science majors, or even just students that were interested in Computer Science. There were about 10 different speakers that talked for about three minutes about their personal job experience after graduating at CofC.
Some of the speakers talked about what they look for in people that apply at their companies. The general consensus was that employers look for people that don't just have strong experience in specific programming languages (or strong skills, etc.) in Computer Science, but mostly what we spend time doing outside of the classroom. They really like to hear about personal projects (related to programming or software development) that we've worked on in our own time. This seems to be important to employers, because it shows that we are really interested in the field of Computer Science.
After the speakers finished, the room was opened into a question and answer session that any students had for the alumni. There were some interesting questions going around. Some people asked about what types of things that their employers look for when hiring. Another hot topic was cloud computing, and its importance in the future of the Computer Science. Everyone seemed to have their own opinions about cloud computing, and how big of a toll it will take on the future.
With the addition of free food (which is my personal favorite), the Alumni Symposium turned out to be a great event, and I'll be sure to attend next year (as a Senior).
Some of the speakers talked about what they look for in people that apply at their companies. The general consensus was that employers look for people that don't just have strong experience in specific programming languages (or strong skills, etc.) in Computer Science, but mostly what we spend time doing outside of the classroom. They really like to hear about personal projects (related to programming or software development) that we've worked on in our own time. This seems to be important to employers, because it shows that we are really interested in the field of Computer Science.
After the speakers finished, the room was opened into a question and answer session that any students had for the alumni. There were some interesting questions going around. Some people asked about what types of things that their employers look for when hiring. Another hot topic was cloud computing, and its importance in the future of the Computer Science. Everyone seemed to have their own opinions about cloud computing, and how big of a toll it will take on the future.
With the addition of free food (which is my personal favorite), the Alumni Symposium turned out to be a great event, and I'll be sure to attend next year (as a Senior).
Monday, February 14, 2011
Bug Progress
During our presentation on Thursday, the consensus for us was to find out how to properly create multiple-line names. Not long after our presentation (during the time left over from class), we made excellent progress. Megan figured out how to create multiple-line names. This helped us better understand what Walter was saying about how our fix could potentially mess up names of users that have multiple lines. Once we tested this out, it all made sense. Now the tricky part was to figure out a work-around. With the time remaining in class, we all gathered together to look at what our possibilities were. We're left with two options:
1. Implement our current fix only on initial creation of the user's name, that way they can still edit their names later.
2. Implement a more sophisticated fix that will allow the user to have multiple-lined names, both on creation of the user account, and when editing the account.
Of course we would like to opt for the second solution, that way no user's of sugar will ever be able to tell the difference in what we've done. We spent some time on Thursday trying to figure out a possible algorithm to address this fix, but we knew we would need to spend more time on it this weekend. On Friday, I set up a folder for our group on Subversion, and I uploaded the current changes I made for our bug.
Yesterday (Sunday), our team met up for about two hours to try and make some more progress on this bug. To start, I made sure that everyone was able to access subversion successfully, and get the code that we had when we left off, and it seems that everyone was able to get the code successfully. We continued working on the bug, and made some progress. After we had left on Thursday, we were unable to open the About Me section (the place where you enter the name), because it seems that the code did not compile successfully. We were able to properly compile the code, but then seemed to be stuck in some sort of infinite loop. After reviewing our code multiple times, I was able to successfully update the user name, but it seems that it wasn't properly recognizing the multi-line characters. Since this isn't due just yet, we decided to call it a night and pick this up again later this week when we're able to meet.
1. Implement our current fix only on initial creation of the user's name, that way they can still edit their names later.
2. Implement a more sophisticated fix that will allow the user to have multiple-lined names, both on creation of the user account, and when editing the account.
Of course we would like to opt for the second solution, that way no user's of sugar will ever be able to tell the difference in what we've done. We spent some time on Thursday trying to figure out a possible algorithm to address this fix, but we knew we would need to spend more time on it this weekend. On Friday, I set up a folder for our group on Subversion, and I uploaded the current changes I made for our bug.
Yesterday (Sunday), our team met up for about two hours to try and make some more progress on this bug. To start, I made sure that everyone was able to access subversion successfully, and get the code that we had when we left off, and it seems that everyone was able to get the code successfully. We continued working on the bug, and made some progress. After we had left on Thursday, we were unable to open the About Me section (the place where you enter the name), because it seems that the code did not compile successfully. We were able to properly compile the code, but then seemed to be stuck in some sort of infinite loop. After reviewing our code multiple times, I was able to successfully update the user name, but it seems that it wasn't properly recognizing the multi-line characters. Since this isn't due just yet, we decided to call it a night and pick this up again later this week when we're able to meet.
Thursday, February 10, 2011
Presenting our Bug Report
While we thought we had a handle on how to fix our bug, we've gone through some recent considerations on how to properly address it. The first thing that has come to light is that certain Sugar users like to make their names in a way that takes up multiple lines. We still need to figure out a way to properly address this.
Here are the options that we explored and plan to present:
1. To cut of the extra space on each side of the string on both initial launch, and when editing the user's name.
2. To cut of the extra space on each side of the string only when the user enters in their name for the first time.
I plan to present the bug to class directly from my machine, so that we can view and discuss the changes that take affect after applying our current "fix" for the bug.
For the future: We still need to figure out how to properly address the multi-line names. First, we need to figure out how they are created. Once we understand the process of creating the name, we will be able to provide a better solution to the problem.
Here are the options that we explored and plan to present:
1. To cut of the extra space on each side of the string on both initial launch, and when editing the user's name.
2. To cut of the extra space on each side of the string only when the user enters in their name for the first time.
I plan to present the bug to class directly from my machine, so that we can view and discuss the changes that take affect after applying our current "fix" for the bug.
For the future: We still need to figure out how to properly address the multi-line names. First, we need to figure out how they are created. Once we understand the process of creating the name, we will be able to provide a better solution to the problem.
Monday, February 7, 2011
Bugs, bugs, and more bugs.
6.4:
Here is the bug that we've been working on. When the user enters in a profile name for their account during setup, the field currently does not trim any spaces entered on the left or right side. This occurs during the initial setup of setting up the profile name, or if the user decides to edit it later.
This bug has been sitting around for about 3 months, and I have a decent idea why. We sent an email to the development team asking where to get started on this bug, and they pointed us in the right direction. Walter Bender wrote back within minutes pointing us to where we can fix this. Minutes after, others began replying, and arguing whether or not this was actually a bug, or if it was more of a feature. They argued that the user should be able to enter in spaces in their name if they prefer to. The main reason this bug is because the community is unsure how to handle it.
6.5:
I've created an account on the Sugar Lab's bug tracker.
6.6: Bug report
This bug can be reproduced in two ways:
A. Initial creation of the user account, following these steps.
1. User launches the Sugar OS for the first time.
2. The user is prompted to enter in a name.
3. The user enters in text in the Name field, and puts spaces before or after the desired name.
4. The user clicks the check sign, and continues to set up the Sugar OS for the first time.
5. The user clicks on their main Sugar icon, then clicks on their name.
6. The user clicks on My Settings, then About Me.
7. The user clicks within the name text field, and finds space to the left and right of the desired name.
B. Editing the user account name.
1. The user opens the Sugar OS.
2. The user clicks on their main Sugar icon, then clicks on their name.
3. The user clicks on My Settings, then About Me.
4. The user clicks within the name text field, and enters space to the left and right of their name.
5. The user clicks the check mark to save the changes.
6. The user clicks About Me again, then clicks within the Name field and finds space to the left and right of their name.
6.7:
Bug Triage:
SugarLab's bug tracker is organized into three priorities: Low, Minor, Normal, High, Major, and Immediate.
Bug #2564: This bug has to do with the simplicity of backing up and restoring files in the Sugar OS. While this bug is important, it may not be the most pressing one to complete, since most users aren't going to be backing up files often, especially kids. I would say that this should be prioritized as Normal.
Bug #2352: This bug is about documentation that is missing from Patchwork. While it is important to keep documentation updated for programmers to use as a guide, it's definitely not a critical problem that would effect the user's experience. I'd say this is a Low priority bug.
Bug #2227: This bug contains a detailed log of an error thrown when trying to launch a Sugar OS component called XoPhoto. I would argue that this is either a High, or Major priority bug, because the component is completely unusable by certain users. While the component may not be used by a high number of users, it is still important because the users that are affected cannot use the software at all.
Bug #1741: This bug is a complaint about the absence of a detailed report of a connection error when integrating a Jabber server in the Sugar OS. The error given does not provide the user with any useful information about what the problem might be. I'd say this is a Normal, maybe Low priority bug.
Bug #1936: This bug talks about the Sugar OS datastore, which is a component that can be very large depending on the amount activities and other components installed in the Sugar OS. When the datastore has a high amount of data, it returns an error, which is provided in the bug report. This could potentially be a big problem if a high number of users have a lot of data stored in the Sugar OS. This would be a High or Major priority bug.
Side note: I finally remembered to sign up for the Alumni Symposium next week.
Here is the bug that we've been working on. When the user enters in a profile name for their account during setup, the field currently does not trim any spaces entered on the left or right side. This occurs during the initial setup of setting up the profile name, or if the user decides to edit it later.
This bug has been sitting around for about 3 months, and I have a decent idea why. We sent an email to the development team asking where to get started on this bug, and they pointed us in the right direction. Walter Bender wrote back within minutes pointing us to where we can fix this. Minutes after, others began replying, and arguing whether or not this was actually a bug, or if it was more of a feature. They argued that the user should be able to enter in spaces in their name if they prefer to. The main reason this bug is because the community is unsure how to handle it.
6.5:
I've created an account on the Sugar Lab's bug tracker.
6.6: Bug report
This bug can be reproduced in two ways:
A. Initial creation of the user account, following these steps.
1. User launches the Sugar OS for the first time.
2. The user is prompted to enter in a name.
3. The user enters in text in the Name field, and puts spaces before or after the desired name.
4. The user clicks the check sign, and continues to set up the Sugar OS for the first time.
5. The user clicks on their main Sugar icon, then clicks on their name.
6. The user clicks on My Settings, then About Me.
7. The user clicks within the name text field, and finds space to the left and right of the desired name.
B. Editing the user account name.
1. The user opens the Sugar OS.
2. The user clicks on their main Sugar icon, then clicks on their name.
3. The user clicks on My Settings, then About Me.
4. The user clicks within the name text field, and enters space to the left and right of their name.
5. The user clicks the check mark to save the changes.
6. The user clicks About Me again, then clicks within the Name field and finds space to the left and right of their name.
6.7:
Bug Triage:
SugarLab's bug tracker is organized into three priorities: Low, Minor, Normal, High, Major, and Immediate.
Bug #2564: This bug has to do with the simplicity of backing up and restoring files in the Sugar OS. While this bug is important, it may not be the most pressing one to complete, since most users aren't going to be backing up files often, especially kids. I would say that this should be prioritized as Normal.
Bug #2352: This bug is about documentation that is missing from Patchwork. While it is important to keep documentation updated for programmers to use as a guide, it's definitely not a critical problem that would effect the user's experience. I'd say this is a Low priority bug.
Bug #2227: This bug contains a detailed log of an error thrown when trying to launch a Sugar OS component called XoPhoto. I would argue that this is either a High, or Major priority bug, because the component is completely unusable by certain users. While the component may not be used by a high number of users, it is still important because the users that are affected cannot use the software at all.
Bug #1741: This bug is a complaint about the absence of a detailed report of a connection error when integrating a Jabber server in the Sugar OS. The error given does not provide the user with any useful information about what the problem might be. I'd say this is a Normal, maybe Low priority bug.
Bug #1936: This bug talks about the Sugar OS datastore, which is a component that can be very large depending on the amount activities and other components installed in the Sugar OS. When the datastore has a high amount of data, it returns an error, which is provided in the bug report. This could potentially be a big problem if a high number of users have a lot of data stored in the Sugar OS. This would be a High or Major priority bug.
Side note: I finally remembered to sign up for the Alumni Symposium next week.
Thursday, February 3, 2011
Freeciv experience
The experience I had with Freeciv in TOS chapter 5 was very helpful. Too bad I didn't go through it earlier this weekend however, because it is essentially the same sort of thing I've been dealing with in SugarLabs. The guide through the Freeciv installation teaches us how complex these projects can be. There are a ton of sources, packages, files, extensions, etc. that need to be in place in order for things to build properly. Taking the time to make sure that you've properly added all of the required dependencies for a project is very important, and can save you a lot of time in the long run.
Some of the processes I went through in Freeciv were a bit confusing at first. Freeciv keeps referencing "yum" to download packages, but in Ubuntu we use "apt-get". There were also some subtle differences in package names that Freeciv referred us to, but searching for the packages in the Ubuntu Software Center allowed me to figure out which ones I needed. Also, there were quite a few packages it asked to install that my version of Ubuntu seemed to already have in place.
Some of the processes I went through in Freeciv were a bit confusing at first. Freeciv keeps referencing "yum" to download packages, but in Ubuntu we use "apt-get". There were also some subtle differences in package names that Freeciv referred us to, but searching for the packages in the Ubuntu Software Center allowed me to figure out which ones I needed. Also, there were quite a few packages it asked to install that my version of Ubuntu seemed to already have in place.
The next phase of Freeciv was "make". Make seems to be the building of the entire Freeciv project. Running make required us to install a c++ compiler. The one that Freeciv referenced didn't work, but it seems that Ubuntu also already has one built in called "libstdc++6". Generally, most of the error messages that I would get weren't always the same as the ones documented by Freeciv, but finding the solution wasn't too hard.
Once this was completed, I was expecting to feel some sort of accomplishment for gathering all of the packages/files successfully, but it seems there wasn't any sort of "Congratulations" for getting here. Seems that the main goal of this assignment was simply to have an idea of how to successfully build a project that has a handful of dependencies.
Some Sugar-related stuff:
I've gotten all of the packages that were throwing errors previously in my jhbuild for sugar to work. The activities seem to work properly now, and I'm able to build the project.
The next step will be getting ourselves set up with subversion this weekend, along with trying to figure out how to get started with the bug we're going to address.
I've gotten all of the packages that were throwing errors previously in my jhbuild for sugar to work. The activities seem to work properly now, and I'm able to build the project.
The next step will be getting ourselves set up with subversion this weekend, along with trying to figure out how to get started with the bug we're going to address.
Subscribe to:
Posts (Atom)