So far I think everyone in our team is leaning toward the idea of small improvements for Fortune Hunter, mainly the ones addressed on their active ticket tracker. I think we should try fixing the (only) other bug, which would require us to actually play the game and progress to that point where the player gets stuck in the dungeon. We haven't gotten this far before, so we would really have to understand the rules and gameplay, and then we would have to look into the appropriate sections of code to find out what could be causing this problem.
We were also interested in improving some of the graphics of the game, specifically the enemies. They are currently transparent wherever they have the color black. We tested this in class Thursday by finding in the folder hierarchy and the code itself where certain enemy characters were used and editing the graphics files in Gimp to make black appear as a different, noticeable color. We were correct in thinking the black color was the problem since other colors showed up fine. So it might be somewhere in the code that specifically calls out that color and sets it as something else, but we have yet to find it.
Other contribution ideas include always-needed documentation and maybe some minor improvements to gameplay. Jon did mention that they were in the process of converting the code over to the new version, which I'm sure they could use some help with. However, looking into the other bug might be the best way to start off the rest of our contributions for the semester.
Monday, February 28, 2011
Wednesday, February 23, 2011
Patch Exercises
7.2.2. Exercise - Compare diff formats:
$diff hello.c hello.c.punct
8c8
< printf("Hello, World!\n");
---
> printf("Hello, World.\n");
$diff -u hello.c hello.c.punct
--- hello.c 2011-02-22 14:18:15.000000000 -0500
+++ hello.c.punct 2011-02-22 14:18:08.000000000 -0500
@@ -5,6 +5,6 @@
The first format, without the -u option has in its output's first line "8c8", where the 'c' between the numbers indicates that changes were made, and first number '8' means line 8 in the original file (hello.c) was replaced with line 8 (second number '8') in the modified file (hello.c.punct).
The -u option in the second format specifies to use the unified diff format for the output.
--- and - indicate the original file. +++ and + indicate the modified file.
The double-at signs indicate where changes were made in the modified file. The first number between these signs is the starting line of the actual code (excluding comments), and the second number shows how big the modified "hunk" is. Here, it is 6 lines of code starting at line 5.
7.8. Exercise - Create a Patch for a New File
The file foo needs to be created using the contents of an existing file bar. We can compare the contents of bar with an empty file (/dev/null on ubuntu) by using diff with the unified format and output the results to bar.patch. Then we can apply the patch and specify a file foo, which then creates the new file foo with the contents of the original bar file.
diff -u /dev/null bar > bar.patch
patch foo < bar.patch
Interesting.
7.9. Exercise - Patch echo
This part took longer than I thought it would (gotta love compiling). But then I had to figure out what the patched code was actually supposed to be doing. And then I realized they changed one of the parameters in their modified code. Oops. (Recompile.)
Now it works. Anything entered after src/echo and separated by a space comes back in reverse order, just like the exercise describes.
Thursday, February 17, 2011
Finally Committed the Fix
We edited the code (with comments) to fix the bug as described in a previous post, and then wanted to commit it.
Comments were added in the commit command to include committer name and a description.
git log
The log shows these changes, but no code is uploaded yet.
But then we couldn't figure out how to push the code.
I had to use the tutorial here to set up a key because using git push kept telling me the The git:// url is read-only. Please see http://git.sugarlabs.org//
I don't know if the key was necessary because after I logged into git.sugarlabs.org (and Jon had added me as a committer), I noticed the project-xavier page for Fortune Hunter had more options for the clone & push urls. But this was only after I started setting up the key so I added one anyway.
git add BattleEngine.py
git commit
Comments were added in the commit command to include committer name and a description.
git log
The log shows these changes, but no code is uploaded yet.
But then we couldn't figure out how to push the code.
I had to use the tutorial here to set up a key because using git push kept telling me the The git:// url is read-only. Please see http://git.sugarlabs.org//
I don't know if the key was necessary because after I logged into git.sugarlabs.org (and Jon had added me as a committer), I noticed the project-xavier page for Fortune Hunter had more options for the clone & push urls. But this was only after I started setting up the key so I added one anyway.
I also did a git pull in the current directory with the new url:
git pull gitorious@git.sugarlabs.org:project-xavier/mainline.git master
I finally got it uploaded by using git push:
git push gitorious@git.sugarlabs.org:project-xavier/mainline.git master
Now everything is up on the main page, with details available.
Their diff of the old file and the one I uploaded shows some straggler code, thankfully commented out, that may accidentally have been added while trying to find a fix. Oops. I was pretty sure I'd re-cloned the files from git in a new directory and edited in our fix. This definitely needs to be addressed, but can wait since it is commented out and the program runs correctly (no scan bug now).
Wednesday, February 16, 2011
CS Alumni Symposium
The Alumni Symposium last Tuesday was very interesting. Then again it was another one of those "Oh crap what am I going to do after I graduate??" kind of things. Apparently make lots of money. There seem to be a lot of opportunities in this area for CS majors, and I would totally be out there scouting out possible jobs if I were staying in Charleston. Fortunately, most of their advice is applicable everywhere, such as making sure you love what you want to do and being prepared to learn new stuff on the fly.
I definitely think this class is helping us gain more hands-on experience with current technology and in communications among and contributions to the open source world, and that seems to be a good stepping stone to the real world.
I definitely think this class is helping us gain more hands-on experience with current technology and in communications among and contributions to the open source world, and that seems to be a good stepping stone to the real world.
Sunday, February 13, 2011
Fixed Bug
I was able to fix the scan damage bug we were working on. I describe the fix here. We'd already found where the code was messing up (MAFH2/BattleEngine.py), so we just needed to add and delete some stuff. I had to look through the rest of the code to find how to get information about the selected enemy, but found it in the attack phase part, since we know that attacks the specified enemy. For the message window, I had to search the code for where certain messages were printed. Once we found that, we added the correct parts about hp and weakness, the details of which were found in the previous version's code (outside the MAFH2 folder).
Brittany uploaded the code to our repository on the CSCI462 playground, and I submitted the fixed version of BattleEngine.py.
We also had a team meeting over Skype with Jon. He gave us some more information on how to submit the fix using git and to address the bug report, which we will start working on before its due date next Tuesday.
Brittany uploaded the code to our repository on the CSCI462 playground, and I submitted the fixed version of BattleEngine.py.
We also had a team meeting over Skype with Jon. He gave us some more information on how to submit the fix using git and to address the bug report, which we will start working on before its due date next Tuesday.
Thursday, February 10, 2011
Bug
More information can be found here on our wiki: http://fourscompany.wikispaces.com/First+Bug.
Fortune Hunter only has two active bugs at the moment, so we chose the "scan damage" bug. We were able to replicate it during gameplay, and then looked through the code using Netbeans to find where the word "scan" occurs. We found some possible places where the bug could be happening and need to investigate further, because everything interacts with one another.
Everything else with our project seems to be going smoothly.
Fortune Hunter only has two active bugs at the moment, so we chose the "scan damage" bug. We were able to replicate it during gameplay, and then looked through the code using Netbeans to find where the word "scan" occurs. We found some possible places where the bug could be happening and need to investigate further, because everything interacts with one another.
Everything else with our project seems to be going smoothly.
Monday, February 7, 2011
Testing and Debugging Exercise
Notes and Exercises for Chapter 6 in TOSS
This chapter had some really useful information concerning bugs and how to handle and report them, especially since I'm currently interning at Hawkes Learning testing math software and reporting bugs, just as the chapter describes.
As for our Fortune Hunter involvement, we found all of two active bugs during the last class. The "oldest" bug (6.4 Exercise) happens to be the one we're planning to work on, so that works somewhat in our favor. I reproduced the bug (6.6 Exercise) while playing the game during last class (only in CS classes is that considered okay...). While their description of the bug is short, it's very much to the point, and does include the necessary information.
I also created an account at fedoraproject.org and applied to join the gitfortune_hunter group, assuming that's the right one. However, it looks like I can log in to the bug tracker Trac simply using my Google account, with full access to everything I might need for bugs. (6.5 Exercise)
I created a Sugar Labs user page here following the directions of Jon from the Math4 RIT team (as always, very helpful), and sent him a rather late email introducing myself, and more importantly, asking how to get Fortune Hunter's screen resolution down to a reasonable size for our laptops. It's very difficult to replicate bugs and simulate gameplay when the screen must be continuously moved to see the playing area and the accompanying messages.
The first bug (and oldest) involves the "scan" method during an attack actually dealing damage instead. Enemies are quickly defeated using this method. Its priority is "major," as it should be, high enough to be of importance, but not the highest since it does not affect movement through the game (it actually helps it). But those sly fourth-graders might realize the bug's presence and use it to their advantage, defeating the game's purpose of teaching math.
The second bug ("newest") is getting stuck in the 3rd dungeon. I have no idea what "Dungeon 3" is, maybe because we haven't had enough experience with the game yet. I'm sure upon reaching that dungeon, I would suddenly become very aware of it if the bug is still in effect. Its "critical" priority is sound, considering getting stuck in a dungeon would ruin your progress and defeat the purpose of playing the game (since you can't win). (6.7 Exercise)
This chapter had some really useful information concerning bugs and how to handle and report them, especially since I'm currently interning at Hawkes Learning testing math software and reporting bugs, just as the chapter describes.
As for our Fortune Hunter involvement, we found all of two active bugs during the last class. The "oldest" bug (6.4 Exercise) happens to be the one we're planning to work on, so that works somewhat in our favor. I reproduced the bug (6.6 Exercise) while playing the game during last class (only in CS classes is that considered okay...). While their description of the bug is short, it's very much to the point, and does include the necessary information.
I also created an account at fedoraproject.org and applied to join the gitfortune_hunter group, assuming that's the right one. However, it looks like I can log in to the bug tracker Trac simply using my Google account, with full access to everything I might need for bugs. (6.5 Exercise)
I created a Sugar Labs user page here following the directions of Jon from the Math4 RIT team (as always, very helpful), and sent him a rather late email introducing myself, and more importantly, asking how to get Fortune Hunter's screen resolution down to a reasonable size for our laptops. It's very difficult to replicate bugs and simulate gameplay when the screen must be continuously moved to see the playing area and the accompanying messages.
The first bug (and oldest) involves the "scan" method during an attack actually dealing damage instead. Enemies are quickly defeated using this method. Its priority is "major," as it should be, high enough to be of importance, but not the highest since it does not affect movement through the game (it actually helps it). But those sly fourth-graders might realize the bug's presence and use it to their advantage, defeating the game's purpose of teaching math.
The second bug ("newest") is getting stuck in the 3rd dungeon. I have no idea what "Dungeon 3" is, maybe because we haven't had enough experience with the game yet. I'm sure upon reaching that dungeon, I would suddenly become very aware of it if the bug is still in effect. Its "critical" priority is sound, considering getting stuck in a dungeon would ruin your progress and defeat the purpose of playing the game (since you can't win). (6.7 Exercise)
Wednesday, February 2, 2011
Freeciv Example
For homework I followed the directions here to install the Freeciv code in Chapter 5. I especially liked the advice of Google being your friend, which I found out the hard way in my early experiments with Ubuntu. I checked out the Freeciv code with subversion and updated it, and then opened the INSTALL file for further directions. I didn't seem to have nearly as many dependency issues as the author describes, but I also have a bad habit of tinkering with my system much too frequently and probably had already installed some of these packages along the way, or else Ubuntu just likes making things easy. My biggest problem actually was that I tried to build the code on a FAT32 partition instead of my ext4 home and libtoolize continually failed to create symbolic links until I remembered that partition never plays nice with those. Moving the freeciv folder to a normal Linux filesystem immediately resolved the problem.
The autogen file went right on into configuring everything, but then failed when looking for a libcurl dependency, so I installed libcurl3-dev, and had no more issues with that either. I mindlessly ran "make" afterwards because that's what the end of the configuration told me to do, but then saw in the chapter they wanted us to output the logs to files. I felt no need to rerun make with the logging because I believe the author's commands to do as they say, though the "1" (standard output) and "2" (errors) indicators were new to me. I did enjoy the author's supposedly "serious business" link to the always-nerdy xkcd comics.
From what I could make of the whole experiment is that the autotools program generates the configure file for the project, which eventually leads to a successful compilation of code according to the diagram at the end.
In relation to the class, I guess it would be a good thing for us to know what's going on inside the autogen script so as to build better code all around.
My main concern though is why is this presented so late in the game? Hopefully we all, whether on our own time or for a class, have compiled code from source before. And if not, why isn't this stuff taught in lower level classes? Of course, introducing these issues in Programming 101 might scare people away, but learning how to program inside a single secluded environment isn't helping anyone when it comes to the importance of a code's interactions and distribution among people and other machines.
The autogen file went right on into configuring everything, but then failed when looking for a libcurl dependency, so I installed libcurl3-dev, and had no more issues with that either. I mindlessly ran "make" afterwards because that's what the end of the configuration told me to do, but then saw in the chapter they wanted us to output the logs to files. I felt no need to rerun make with the logging because I believe the author's commands to do as they say, though the "1" (standard output) and "2" (errors) indicators were new to me. I did enjoy the author's supposedly "serious business" link to the always-nerdy xkcd comics.
From what I could make of the whole experiment is that the autotools program generates the configure file for the project, which eventually leads to a successful compilation of code according to the diagram at the end.
In relation to the class, I guess it would be a good thing for us to know what's going on inside the autogen script so as to build better code all around.
My main concern though is why is this presented so late in the game? Hopefully we all, whether on our own time or for a class, have compiled code from source before. And if not, why isn't this stuff taught in lower level classes? Of course, introducing these issues in Programming 101 might scare people away, but learning how to program inside a single secluded environment isn't helping anyone when it comes to the importance of a code's interactions and distribution among people and other machines.
Tuesday, February 1, 2011
Sugar: Not So Sweet Sometimes
Math4 Projects: Installing the code for both Fortune Hunter and PacMath using git was relatively easy and I described how to do it on our team's wiki, currently under the Discussion page. Everything is written in Python, but I could not find any kind of executable in the Fortune Hunter folders. I was able to "run" PacMath, but playing of game itself does not seem to be implemented yet and the project may be inactive.
So I went on to try to install the Sugar Learning Environment itself...
Sugar Emulator: I use Ubuntu 10.04 on my main computer, so I tried to follow the directions given on the sugar wiki (can be found here):
echo "deb http://bazaar-download.sugarlabs.org/Platform/Ubuntu-10.04 ./" >> /etc/apt/sources.list
echo "deb http://bazaar-download.sugarlabs.org/Distribution:/0.90/Ubuntu-10.04 ./" >> /etc/apt/sources.list
gpg --keyserver keys.sugarlabs.org --recv-keys 75BB5FDF
gpg --armor --export 75BB5FDF | apt-key add -
apt-get update
synaptic
search for "sweets", install all (these are the Activities)
"sweets-distribution" failed to install, so I unmarked it and went on my way.
I think this process installed both the Sugar Desktop environment for Ubuntu and the Sugar Emulator.
Sugar-emulator appears in the gnome menu and runs as it should. I was able to install the Fortune Hunter activity (login required for Sugar Labs) inside the emulator, but the resolution is a problem. Apparently Sugar activities default to 1200x900, which is strange considering the XO's 7.5 inch display. My 15.4 inch monitor does not even support resolutions that high, so I was unable to see any of the important activities and messages going on at the bottom of the game. Running "sugar-emulator -f" for fullscreen mode does not improve the situation.
Another major problem with the emulator is that it fails to recognize my arrow keys, essential for gameplay in Fortune Hunter. This is/was a known problem in Xephyr which runs the emulator, and none of the suggested workarounds work on my system.
So I tried something else...
Sugar on a Stick in VirtualBox: I followed the directions here, downloaded the appropriate files, set up VirtualBox for Fedora, and started the virtual machine. The biggest problem with using a virtual machine is how slow it can be. Also, it does not seem to save any modifications, unless I missed something in the configuration. The keyboard works as it should, but the bottom part of the Fortune Hunter game is still cut off, leaving the best solution so far to be...
Sugar Desktop in Ubuntu: At least for using Fortune Hunter. But this requires I log out of my normal gnome desktop to log in to Sugar every time I need to use. I can see MOST of the game, and everything else seems to be working.
Standalone Activities? I came across a manual for creating Sugar Activities, and it even says that developers should first create a standalone Python program. We should probably contact the RIT students working on Fortune Hunter and see if there is a standalone executable buried somewhere in their files.
Thoughts: I still believe our best bet for contributing to the Math4 Project would be to eventually create our own, new Activity as a group, rather than jumping into a project that seems to be largely concentrated with other students who have their own ideas on where this program is heading. They are very helpful and eager to get us started working on Fortune Hunter though. It also seems to be the only currently active project going on for Math4.
So I went on to try to install the Sugar Learning Environment itself...
Sugar Emulator: I use Ubuntu 10.04 on my main computer, so I tried to follow the directions given on the sugar wiki (can be found here):
echo "deb http://bazaar-download.sugarlabs.org/Platform/Ubuntu-10.04 ./" >> /etc/apt/sources.list
echo "deb http://bazaar-download.sugarlabs.org/Distribution:/0.90/Ubuntu-10.04 ./" >> /etc/apt/sources.list
gpg --keyserver keys.sugarlabs.org --recv-keys 75BB5FDF
gpg --armor --export 75BB5FDF | apt-key add -
apt-get update
synaptic
search for "sweets", install all (these are the Activities)
"sweets-distribution" failed to install, so I unmarked it and went on my way.
I think this process installed both the Sugar Desktop environment for Ubuntu and the Sugar Emulator.
Sugar-emulator appears in the gnome menu and runs as it should. I was able to install the Fortune Hunter activity (login required for Sugar Labs) inside the emulator, but the resolution is a problem. Apparently Sugar activities default to 1200x900, which is strange considering the XO's 7.5 inch display. My 15.4 inch monitor does not even support resolutions that high, so I was unable to see any of the important activities and messages going on at the bottom of the game. Running "sugar-emulator -f" for fullscreen mode does not improve the situation.
Another major problem with the emulator is that it fails to recognize my arrow keys, essential for gameplay in Fortune Hunter. This is/was a known problem in Xephyr which runs the emulator, and none of the suggested workarounds work on my system.
So I tried something else...
Sugar on a Stick in VirtualBox: I followed the directions here, downloaded the appropriate files, set up VirtualBox for Fedora, and started the virtual machine. The biggest problem with using a virtual machine is how slow it can be. Also, it does not seem to save any modifications, unless I missed something in the configuration. The keyboard works as it should, but the bottom part of the Fortune Hunter game is still cut off, leaving the best solution so far to be...
Sugar Desktop in Ubuntu: At least for using Fortune Hunter. But this requires I log out of my normal gnome desktop to log in to Sugar every time I need to use. I can see MOST of the game, and everything else seems to be working.
Standalone Activities? I came across a manual for creating Sugar Activities, and it even says that developers should first create a standalone Python program. We should probably contact the RIT students working on Fortune Hunter and see if there is a standalone executable buried somewhere in their files.
Thoughts: I still believe our best bet for contributing to the Math4 Project would be to eventually create our own, new Activity as a group, rather than jumping into a project that seems to be largely concentrated with other students who have their own ideas on where this program is heading. They are very helpful and eager to get us started working on Fortune Hunter though. It also seems to be the only currently active project going on for Math4.
Subscribe to:
Posts (Atom)