Can't believe the semester's almost over already, and that we've been working with Fortune Hunter for awhile now. We're doing our poster presentation tomorrow, and the giant printed copy looks good. Putting it together will make our progress with the final presentation go a little smoother. I also clicked through our wiki to make sure all the formatting looks good and matches since the final pdf export of it is due tomorrow.
Overall, I think this has been a good class this semester. The workload was definitely manageable since we were able to conform it to our schedules, and the work itself was pretty enjoyable, since we chose the project ourselves. My team members were very easy to get along with. Most of the time we did our our things with FH, but we were able to make it all come together, and to help each other out in different aspects of FH and its setup.
I learned a lot about git and subversion, even though I gained more experience with git because that's where the actual project is hosted. I would like to learn more about subversion and how to utilize it more efficiently in my own work. I also learned more about Python in general, and about Pygame, Netbeans, and the Sugar OS. I will definitely be using Netbeans in future projects (already have in my other class) because it makes things so much easier to deal with, coding-wise. Pygame looks like it has a lot of potential for graphics within Python, so that could be useful in the future. And as for the Sugar OS, I think their message in general and their involvement in the OLPC campaign are very inviting aspects for contributors.
To be honest, though, I don't know about further contributions for Fortune Hunter itself, but I think our team did our best to make sure any other contributors to the project will have an easier time getting into it. But Jon and his team were SO helpful, and I hope any other projects I work with in the future have that same kind of support. I think this was a great first-time experience in really getting involved in a "real," outside project, and our team's interactions with the main developers and amongst ourselves were very beneficial in learning how to work in that kind of environment.
Wednesday, April 20, 2011
Tuesday, April 19, 2011
Poster & Other Updates
I finished up all my commits and fixes last week, so all I needed to do this week was gather up the materials I wanted to include in our poster for Thursday. (http://spinner.cofc.edu/~physics/poster_11/abstracts.html Ooh there we are, number 14!) It definitely looks like a lot of posters are going to be there, so this will be interesting to check out everyone else's projects too.
Our poster's looking pretty good, Brittany put all of our stuff together and I helped her shave off some words to make it more presentable. Can't wait to see it blown up.
Otherwise, there's not much to update in terms of FH progress. Staci and Ryan are still getting their graphics and code ready for a commit, and Brittany's working on the never-ending documentation. I'm going to go over our wiki to make sure everything's organized and updated. We need to start working on our final presentation, which shouldn't be too hard since most of our stuff has been summarized in the poster, and we can use that as a starting point.
Less than a week left of classes!
Our poster's looking pretty good, Brittany put all of our stuff together and I helped her shave off some words to make it more presentable. Can't wait to see it blown up.
Otherwise, there's not much to update in terms of FH progress. Staci and Ryan are still getting their graphics and code ready for a commit, and Brittany's working on the never-ending documentation. I'm going to go over our wiki to make sure everything's organized and updated. We need to start working on our final presentation, which shouldn't be too hard since most of our stuff has been summarized in the poster, and we can use that as a starting point.
Less than a week left of classes!
Thursday, April 14, 2011
Success!
Yesterday was a very successful day, after 5+ straight hours of coding. Some issues that were addressed are listed below.
Dungeon 3 Stuck Bug:
I finally changed the Dungeon 3 Stuck bug in the ticket tracker to 'wontfix' and made it a task related to the reimplementation of the puzzle doors instead, after last week's efforts to address it.
Text Overflow in Navigator:
I also added a task to the ticket tracker concerning the overflowing text in the Navigator. Again, last week's efforts yielded little success in that area with the discovery of pygame's text formatting limitations. Since I don't know how exactly the original developers want to deal with this, I figured it's better to just bring it to their attention on the tracker for now.
SVN commit Oops:
I edited some code and submitted it to our svn repos, and continued to work on my next task, when I realized the code was actually messed up. It's okay though, because I fixed it right away and re-commited the working code along with a "just kidding" addition in the comment to indicate the new revision works this time. I really wasn't kidding when I warned my group that I was the one mostly likely to break the code (and somehow overwrite the working editions). I'm still not entirely sure about svn usage, as far as reverting back to old revision and the merging of files, and I will look into that later. But the proper code was finally submitted.
On to good news...
Minor Typo:
I fixed the minor "forunute" misspelling in the MafhActivity.py file. No big deal. Fixed in both svn and official git repos. I used this as my tester commit since I discovered my key messed up for the git repos. I had to create a new one, following the same instructions in a previous blog entry, and then I had no problems using the instructions posted on our wiki's Getting Code page.
Messages in Navigator:
First I fixed the Heal messages, to say whether or not you actually healed after the magic heal command. That wasn't so bad. But it led to all sorts of other problems, and fixed some others at the same time. No more random '0's or blank messages leaving the player confused.
Battle Timer:
Turns out the battle timer doesn't actually work. It kind of still doesn't, but at least the game does more appropriate things now when the player is past their time limit. This relates to the messages, since I added some code that creates a "Time's up!" message. If the battle timer has reached its limit, the graphic will remain on the screen and the player will still be at the current puzzle or numerical input as before (nothing changes here). However, ANY action at this point will take them back to the previous menu, and show the "Time's up!" message, whether they enter a correct value or select the correct puzzle piece. While this may not be the best solution, since the ideal one would be to remove the timer graphic when time is up and return to the menu then with the message, this is a good starting point and worth committing. So I did. Especially after spending so much time on it.
Now what...
I updated the wiki Timeline to show my changes, and both the git and svn repos have all my committed fixes. As far as direct contribution to the Fortune Hunter project for the semester, I think I've basically completed my part. Our wiki page still needs some better modifications and organization to reflect our updates, so that's what I'll be working on for the next week, along with getting the other team members on board with their own commits.
Brittany submitted our poster abstract and started working on our poster presentation due next Thursday. Doing that alongside the final Prezi presentation should make both projects easier. Everyone in our group is mostly finished with their assigned tasks. Good thing too, since our last class is next week!
Dungeon 3 Stuck Bug:
I finally changed the Dungeon 3 Stuck bug in the ticket tracker to 'wontfix' and made it a task related to the reimplementation of the puzzle doors instead, after last week's efforts to address it.
Text Overflow in Navigator:
I also added a task to the ticket tracker concerning the overflowing text in the Navigator. Again, last week's efforts yielded little success in that area with the discovery of pygame's text formatting limitations. Since I don't know how exactly the original developers want to deal with this, I figured it's better to just bring it to their attention on the tracker for now.
SVN commit Oops:
I edited some code and submitted it to our svn repos, and continued to work on my next task, when I realized the code was actually messed up. It's okay though, because I fixed it right away and re-commited the working code along with a "just kidding" addition in the comment to indicate the new revision works this time. I really wasn't kidding when I warned my group that I was the one mostly likely to break the code (and somehow overwrite the working editions). I'm still not entirely sure about svn usage, as far as reverting back to old revision and the merging of files, and I will look into that later. But the proper code was finally submitted.
On to good news...
Minor Typo:
I fixed the minor "forunute" misspelling in the MafhActivity.py file. No big deal. Fixed in both svn and official git repos. I used this as my tester commit since I discovered my key messed up for the git repos. I had to create a new one, following the same instructions in a previous blog entry, and then I had no problems using the instructions posted on our wiki's Getting Code page.
Messages in Navigator:
First I fixed the Heal messages, to say whether or not you actually healed after the magic heal command. That wasn't so bad. But it led to all sorts of other problems, and fixed some others at the same time. No more random '0's or blank messages leaving the player confused.
Battle Timer:
Turns out the battle timer doesn't actually work. It kind of still doesn't, but at least the game does more appropriate things now when the player is past their time limit. This relates to the messages, since I added some code that creates a "Time's up!" message. If the battle timer has reached its limit, the graphic will remain on the screen and the player will still be at the current puzzle or numerical input as before (nothing changes here). However, ANY action at this point will take them back to the previous menu, and show the "Time's up!" message, whether they enter a correct value or select the correct puzzle piece. While this may not be the best solution, since the ideal one would be to remove the timer graphic when time is up and return to the menu then with the message, this is a good starting point and worth committing. So I did. Especially after spending so much time on it.
Now what...
I updated the wiki Timeline to show my changes, and both the git and svn repos have all my committed fixes. As far as direct contribution to the Fortune Hunter project for the semester, I think I've basically completed my part. Our wiki page still needs some better modifications and organization to reflect our updates, so that's what I'll be working on for the next week, along with getting the other team members on board with their own commits.
Brittany submitted our poster abstract and started working on our poster presentation due next Thursday. Doing that alongside the final Prezi presentation should make both projects easier. Everyone in our group is mostly finished with their assigned tasks. Good thing too, since our last class is next week!
Tuesday, April 12, 2011
Long week...
I'm very much aware I missed a blog posting on Thursday. However, I've made a lot of progress with FH since last Tuesday. I was working on the formatting issues on our handheld device graphic, but discovered that those files are in the FortuneEngine folder which we aren't supposed to be working on in regard to Fortune Hunter as it's a different project entirely. I also discovered through some research that PyGame which is used in FH doesn't like line breaks so much. So what we thought would be a simple fix for the text running off the graphics during battles is actually out of the realm of our project as of now. The BattleMenu.py file has code for both a display and a "second display" which is actually for the number input during a critical attack. I tried creating a third display for a second line following the first display, however with the way graphics are set up, I do not think this is a possible/good solution. There is no way to change the font size of the text of the display object once it is drawn/added to the scene, unless we edited code dealing with pygame itself (different project). So I may just file the text runoff as a bug and let the original developers decide how to deal with this issue. However, I was able to at least adjust the font sizes in the Menu, making the text on the buttons themselves bigger and easier on fourth grade eyes.
I also figured out how to fix the strange messages that popped up when using the Heal magic attack. It would leave the old message up, and sometimes would display a '0', such as when re-selecting a previously selected puzzle piece. This is initially set in the code as default. I fixed the code in BattleEngine.py starting at line 312 to show what happens when the player successfully completes the puzzle ("Healed!") or has failed to perform the Heal ("Failed to heal").
But then I ran into bigger issues. The first (minor) issue is that the documentation needs to show that the max heal is 40 somewhere. A major issue however is that when the timer runs out on puzzles (any, not just Heal, including the critical attack multiplication problems), nothing happens! As far as I can tell, the player can still successfully complete the puzzle and be awarded healing points or deal the appropriate damage. Pretty sure that wasn't intended considering a timer exists in the first place. This needs to be addressed promptly, since it's a major aspect of the game. I'll look into the code to see if it's a do-able fix considering the time we have left, which isn't much. Every issue we run into in this game seems to only lead to more issues, but we are still making progress because we can build better documentation through our experiences thankfully.
One easy fix to boost our morale is that there is a typo in the MafhActivity.py file (used to run the program itself). How we managed to miss this all along, I will never know, especially since it pops up in the Terminal window every time I run the game (am I the only one on my team running from a terminal for debugging issues?).
I also realized that instead of waiting to submit everything to the git project all at once like our original plan, we should be doing it as we go along, so it'll be easier to leave the right comments, and in case if we need to roll back, everything will be in place. I will discuss this with my team members in class today. We also need to get started on the Poster abstract due Friday, and its presentation next week. Yikes.
I also figured out how to fix the strange messages that popped up when using the Heal magic attack. It would leave the old message up, and sometimes would display a '0', such as when re-selecting a previously selected puzzle piece. This is initially set in the code as default. I fixed the code in BattleEngine.py starting at line 312 to show what happens when the player successfully completes the puzzle ("Healed!") or has failed to perform the Heal ("Failed to heal").
But then I ran into bigger issues. The first (minor) issue is that the documentation needs to show that the max heal is 40 somewhere. A major issue however is that when the timer runs out on puzzles (any, not just Heal, including the critical attack multiplication problems), nothing happens! As far as I can tell, the player can still successfully complete the puzzle and be awarded healing points or deal the appropriate damage. Pretty sure that wasn't intended considering a timer exists in the first place. This needs to be addressed promptly, since it's a major aspect of the game. I'll look into the code to see if it's a do-able fix considering the time we have left, which isn't much. Every issue we run into in this game seems to only lead to more issues, but we are still making progress because we can build better documentation through our experiences thankfully.
One easy fix to boost our morale is that there is a typo in the MafhActivity.py file (used to run the program itself). How we managed to miss this all along, I will never know, especially since it pops up in the Terminal window every time I run the game (am I the only one on my team running from a terminal for debugging issues?).
I also realized that instead of waiting to submit everything to the git project all at once like our original plan, we should be doing it as we go along, so it'll be easier to leave the right comments, and in case if we need to roll back, everything will be in place. I will discuss this with my team members in class today. We also need to get started on the Poster abstract due Friday, and its presentation next week. Yikes.
Sunday, April 3, 2011
Dungeon Stuck Bug
Some progress was made regarding the other bug.
The first room is the second line from the bottom in MAFH2/assets/map/al[#].txt file. I figured this out because in the 3rd dungeon, this is the only line with two non-unlocked doors and an entrance door, and in the 1st dungeon, this line has an unlocked door and an entrance door. I modified the second to last line in the code for the 1st dungeon, al1.txt, from NuSe00000000000000000 to NpSe00000000000000000 to check the "puzzle" flag's behavior and to do further testing.
(In the old version, a startPuzzle() method is defined in MAFH.activity/pippy_app.py, line 1708. The method is called in MAFH.activity/pippy_app.py, line 1573.)
I tried to incorporate the appropriate files and code into the new MAFH2 version. I copied all the asset files associated with puzzles and environment. I modified the MAFH2/Dungeon.py to include the variables and paths for puzzle stuff, and found the comment in line 145, #TODO: START PUZZLE. Nice. I added some code from pippy_app.py in there, but couldn't get the actual puzzle to run. I looked for where the puzzles run when you select magic attacks in the menu, but I don't think they've gotten that far yet.
At least we've discovered this is not a bug after all, even though to an outside tester, it would definitely seem that way. Setting the flags to unlocked lets you continue in the game (for testing), but some of the higher levels do not have enemies yet.
This task is not something I think we'd be able to accomplish within the short time we have left, but I will update the bug tracker to indicate that it is not a bug after all, with a link to the Reimplement Puzzle Doors task.
The first room is the second line from the bottom in MAFH2/assets/map/al[#].txt file. I figured this out because in the 3rd dungeon, this is the only line with two non-unlocked doors and an entrance door, and in the 1st dungeon, this line has an unlocked door and an entrance door. I modified the second to last line in the code for the 1st dungeon, al1.txt, from NuSe00000000000000000 to NpSe00000000000000000 to check the "puzzle" flag's behavior and to do further testing.
(In the old version, a startPuzzle() method is defined in MAFH.activity/pippy_app.py, line 1708. The method is called in MAFH.activity/pippy_app.py, line 1573.)
I tried to incorporate the appropriate files and code into the new MAFH2 version. I copied all the asset files associated with puzzles and environment. I modified the MAFH2/Dungeon.py to include the variables and paths for puzzle stuff, and found the comment in line 145, #TODO: START PUZZLE. Nice. I added some code from pippy_app.py in there, but couldn't get the actual puzzle to run. I looked for where the puzzles run when you select magic attacks in the menu, but I don't think they've gotten that far yet.
At least we've discovered this is not a bug after all, even though to an outside tester, it would definitely seem that way. Setting the flags to unlocked lets you continue in the game (for testing), but some of the higher levels do not have enemies yet.
This task is not something I think we'd be able to accomplish within the short time we have left, but I will update the bug tracker to indicate that it is not a bug after all, with a link to the Reimplement Puzzle Doors task.
Wednesday, March 30, 2011
Fortune Hunter Update Again
While running the game in class last time, we came up with a lot of stuff that needs improvement. The list of all the things we're working on right can be found on our wiki's Timeline page. While we don't have specific dates, we are all very well aware of how much time is left in the semester. Some tasks are bound to be harder than others, and will require more time than others, but this won't be realized until we're actually working on them.
I also updated the wiki to include some testing tips. I had to force the resolution on my external monitor to a larger one (which I know the 22-inch TV can support), and found some relevant xrandr stuff from googling. i added detailed instructions for my other team members. Using the scale function, we can at least see the entire game on our laptop monitors, even if it's less than ideal clarity.
I played the game a few times (the right way) and realized the progression of the dungeons. I was worried because the feedback from Jon and our actual experience with the game seemed to indicate that most of the first version's features hadn't yet been implemented in our second one. Jon sent us over to Justin Lewis, who claims to have done most of the code for the second version and would be able to answer our questions. Jon also mentioned that the dungeons are noticeably different when going from one to another, because the scenery/theme changes. Yea, that never happens in the second version and we couldn't play the first version well enough to find out. But I did discover that you actually do progress through the dungeons in the second version, the only indicators being that "the door slams behind you!" and an "INVALID FLAG" error in the console. Sounds great. However, upon arrival in the 3rd dungeon, I really was stuck, and couldn't move through any of the doors. I know where the dungeon room files are located, and now that I can get to that part in the game, I can test to make sure I fix the right line.
I also found a way to deal excessive damage to the enemies during an attack, so we can progress easily through the game for testing purposes (such as to get to the third dungeon).
They seem to be in the process of implementing all these old features into the new game, but at a slower pace. They also seem to be willing to take whatever help they can get, and that's what we're here for.
I also updated the wiki to include some testing tips. I had to force the resolution on my external monitor to a larger one (which I know the 22-inch TV can support), and found some relevant xrandr stuff from googling. i added detailed instructions for my other team members. Using the scale function, we can at least see the entire game on our laptop monitors, even if it's less than ideal clarity.
I played the game a few times (the right way) and realized the progression of the dungeons. I was worried because the feedback from Jon and our actual experience with the game seemed to indicate that most of the first version's features hadn't yet been implemented in our second one. Jon sent us over to Justin Lewis, who claims to have done most of the code for the second version and would be able to answer our questions. Jon also mentioned that the dungeons are noticeably different when going from one to another, because the scenery/theme changes. Yea, that never happens in the second version and we couldn't play the first version well enough to find out. But I did discover that you actually do progress through the dungeons in the second version, the only indicators being that "the door slams behind you!" and an "INVALID FLAG" error in the console. Sounds great. However, upon arrival in the 3rd dungeon, I really was stuck, and couldn't move through any of the doors. I know where the dungeon room files are located, and now that I can get to that part in the game, I can test to make sure I fix the right line.
I also found a way to deal excessive damage to the enemies during an attack, so we can progress easily through the game for testing purposes (such as to get to the third dungeon).
They seem to be in the process of implementing all these old features into the new game, but at a slower pace. They also seem to be willing to take whatever help they can get, and that's what we're here for.
Tuesday, March 29, 2011
POSSCON
We left for POSSCON bright and early Friday morning. Actually it wasn't even bright yet. We got fancy, scan-able IDs with our information loaded into them. The intro speaker said the day was going to be a lot more laid-back and low-paced than the previous days (which I'd missed).
The first workshop I went to was the Great OpenOffice.org Challenge, even though nobody submitted Microsoft documents as requested (I'm not a Microsoft user). David Both explained his history in open source and his experiences with OpenOffice(.org). It was all very interesting information but as one guy mentioned, he was "preaching to the choir." Most people attending POSSCON already have an interest in open source so telling us the wonders of this open source office suite wasn't anything new, at least not for me. However, people started discussing open source software's use in business and in churches, and the workshop definitely veered off course from OpenOffice related stuff.
After the workshop, we were released for a long lunch break before the next workshop. Some classmates who'd attended the 3D printing workshop were telling us about it. Later, as I was wondering through the conference hall, I noticed the 3D printing machine was still running in one of the lecture rooms, so I ventured on down to check it out. The android figure was just finishing up, and the presenters Neil Underwood (from RepRap) and Jim McCracken were getting ready to pack up the machine. I told Neil I'd missed the 3D printing workshop so he started telling me all about the machine in front of us and the other machine he works with, the self-replicating 3D printer, explaining the effects on costs when the printer can print itself. It is a very interesting concept and I think it could easily be taken further into other aspects of technology. Both Jim and Neil pointed out a few things on the machine when I asked about them such as the connections (since the circuit board was mounted in the open). John "maddog" Hall had wandered in to the room too since he was waiting on his little android guy to finish printing.
Maddog presented the second workshop I attended, on the history of Linux. His first slide asked if Jesus would have attended POSSCON, and he thought yes, he would have been an advocate of open source. His presentation was pretty interesting, especially learning about the transition from open source to closed source and now back to open source, and why things have gone certain ways. I think it's important to understand that history when considering the future of open source software. Near the end of his presentation, he gave some examples of some very young guys who'd entered the computer science world with the help of open source and have been very successful with it; however, I was wondering where the women were? It's almost as if our society steers young girls away from technology, which is going to have very detrimental effects in the technological-oriented future if we keep this up. It would have been nice to ask Maddog about this, but it was hard to approach some presenters when others were swarming them or when they were in the middle of eating during lunch. Either way though, some of these problems are very evident and need to be addressed, which can start with people like us as students.
Overall I think it was a pretty good conference, I'm just disappointed that I wasn't able to attend the earlier two days (what's up with conferences in the middle of the week anyway?). I most likely won't be able to attend next year either since I won't be in this area, but I think the northeast is going to have even more to offer, so that's something I'll look into.
The first workshop I went to was the Great OpenOffice.org Challenge, even though nobody submitted Microsoft documents as requested (I'm not a Microsoft user). David Both explained his history in open source and his experiences with OpenOffice(.org). It was all very interesting information but as one guy mentioned, he was "preaching to the choir." Most people attending POSSCON already have an interest in open source so telling us the wonders of this open source office suite wasn't anything new, at least not for me. However, people started discussing open source software's use in business and in churches, and the workshop definitely veered off course from OpenOffice related stuff.
After the workshop, we were released for a long lunch break before the next workshop. Some classmates who'd attended the 3D printing workshop were telling us about it. Later, as I was wondering through the conference hall, I noticed the 3D printing machine was still running in one of the lecture rooms, so I ventured on down to check it out. The android figure was just finishing up, and the presenters Neil Underwood (from RepRap) and Jim McCracken were getting ready to pack up the machine. I told Neil I'd missed the 3D printing workshop so he started telling me all about the machine in front of us and the other machine he works with, the self-replicating 3D printer, explaining the effects on costs when the printer can print itself. It is a very interesting concept and I think it could easily be taken further into other aspects of technology. Both Jim and Neil pointed out a few things on the machine when I asked about them such as the connections (since the circuit board was mounted in the open). John "maddog" Hall had wandered in to the room too since he was waiting on his little android guy to finish printing.
Maddog presented the second workshop I attended, on the history of Linux. His first slide asked if Jesus would have attended POSSCON, and he thought yes, he would have been an advocate of open source. His presentation was pretty interesting, especially learning about the transition from open source to closed source and now back to open source, and why things have gone certain ways. I think it's important to understand that history when considering the future of open source software. Near the end of his presentation, he gave some examples of some very young guys who'd entered the computer science world with the help of open source and have been very successful with it; however, I was wondering where the women were? It's almost as if our society steers young girls away from technology, which is going to have very detrimental effects in the technological-oriented future if we keep this up. It would have been nice to ask Maddog about this, but it was hard to approach some presenters when others were swarming them or when they were in the middle of eating during lunch. Either way though, some of these problems are very evident and need to be addressed, which can start with people like us as students.
Overall I think it was a pretty good conference, I'm just disappointed that I wasn't able to attend the earlier two days (what's up with conferences in the middle of the week anyway?). I most likely won't be able to attend next year either since I won't be in this area, but I think the northeast is going to have even more to offer, so that's something I'll look into.
Tuesday, March 22, 2011
Fortune Hunter Update
Last week in class, we discovered this merchant/shop system Jon talked about isn't even implemented in the released Sugar version of Fortune Hunter. So we decided to scrap those plans, since that would be way too much work for these last five weeks of class. We're going back to our original plan of fixing the last bug and implementing smaller tasks described in the ticket list, such as graphics and documentation. Much more manageable considering the time we have.
I looked into the code for the dungeons, can be found here, so I'll know how to fix it, and found the text file for Dungeon 3 under MAFH2/assets. However, while Jon claims this is an easy one-liner fix, and I really do believe that, knowing WHICH line to fix is the problem, especially since we have yet to really understand the code.
I looked into the code for the dungeons, can be found here, so I'll know how to fix it, and found the text file for Dungeon 3 under MAFH2/assets. However, while Jon claims this is an easy one-liner fix, and I really do believe that, knowing WHICH line to fix is the problem, especially since we have yet to really understand the code.
Wednesday, March 16, 2011
POSSCON Plans Next Week
I will be attending POSSCON in Columbia next Friday, March 25. Since it's the last day, not a lot is going on unfortunately, but it's the only reasonable day my schedule can allow. They're having two workshops that day (and lunch!), so I'm planning to attend the ones on OpenOffice and the history of linux.
I actually use OpenOffice all the time (even though Office 2010 looks pretty nice, but won't run under wine), so learning more about the suite and what I could do to help improve it would be awesome.
David Both is hosting this workshop, so he be will one of the speakers I'd like to approach. I'm not really sure yet what kind of questions to ask him besides the usual "how do I get involved?" and "how can OpenOffice make my life easier?", but I'm sure after the workshop, I'll have some other relevant topics to address.
The second workshop is on the history of Linux, again something I use everyday, and is hosted by Jon "maddog" Hall. With a nickname like "maddog" how could you NOT want to meet him? Also, as someone who seems to have been there since the beginning of (CS) time, he would be a good person to ask where he thinks Linux and open source are headed in the future.
Hopefully all the speakers will stick around for the final day, and will be easily identifiable. Other possible candidates to harass would be Walter Bender, the co-founder of Sugar Labs and One Laptop Per Child, or even better, David Nalley, whose name we've seen before because he is involved with the Math4 project. While the Math4 project is a good idea in theory, it really doesn't seem to be picking up as much as its developers had originally hoped. Sugar Labs and OLPC seem more likely to hold out longer into the future, and I really like the idea of sending internet-enabled laptops to developing countries as a means of educating the people there, starting with the children. I would definitely be interested in learning about more ways to get involved with OLPC and in general how we can use technology to make education more accessible to everyone.
I actually use OpenOffice all the time (even though Office 2010 looks pretty nice, but won't run under wine), so learning more about the suite and what I could do to help improve it would be awesome.
David Both is hosting this workshop, so he be will one of the speakers I'd like to approach. I'm not really sure yet what kind of questions to ask him besides the usual "how do I get involved?" and "how can OpenOffice make my life easier?", but I'm sure after the workshop, I'll have some other relevant topics to address.
The second workshop is on the history of Linux, again something I use everyday, and is hosted by Jon "maddog" Hall. With a nickname like "maddog" how could you NOT want to meet him? Also, as someone who seems to have been there since the beginning of (CS) time, he would be a good person to ask where he thinks Linux and open source are headed in the future.
Hopefully all the speakers will stick around for the final day, and will be easily identifiable. Other possible candidates to harass would be Walter Bender, the co-founder of Sugar Labs and One Laptop Per Child, or even better, David Nalley, whose name we've seen before because he is involved with the Math4 project. While the Math4 project is a good idea in theory, it really doesn't seem to be picking up as much as its developers had originally hoped. Sugar Labs and OLPC seem more likely to hold out longer into the future, and I really like the idea of sending internet-enabled laptops to developing countries as a means of educating the people there, starting with the children. I would definitely be interested in learning about more ways to get involved with OLPC and in general how we can use technology to make education more accessible to everyone.
Monday, March 14, 2011
Timeline update
Last class we came up with a list of ideas each of us would work on for the remainder of the semester (and added a cool new Google calendar to our wiki). However, after sending an email to Jon, he suggested we work on adding back in the merchant/shop feature of the previous version of the game to the current version. He also mentioned that the bug I was going to work on is actually a very simple fix, and that he wasn't really sure about Ryan's proposed contribution to the graphics.
We've updated our wiki to reflect these changes and the calendar to show due dates within our group. As of now, our progress updates include:
We've updated our wiki to reflect these changes and the calendar to show due dates within our group. As of now, our progress updates include:
- Playing the game and getting to know the code (both versions)
- Designing our contributions, including implementation of menus, creation of graphics, and any accompanying documentation
- Modifying our contributions for consistency and overall design
- Adding them into the code, with lots of testing
- Finally, submitting them to the official game and accessing any feedback we receive
Wednesday, March 2, 2011
(Not much to) Update?
Since class was cancelled Tuesday, there's not much to update on our team's progress. Everyone seems to be on board with our ideas so far and we'll come up with a more definite timeline very soon.
I did skim over Chapter 8 in TOSS. It looks like it's all about documentation, which of course is important (along with making code more understandable in general so minimal documentation is actually needed).
Documentation is one of our possible contributions to Fortune Hunter later, especially to make things easier for developers working on the project in the future (like the submodule stuff for the fortune engine, which another team was also having trouble with).
I did skim over Chapter 8 in TOSS. It looks like it's all about documentation, which of course is important (along with making code more understandable in general so minimal documentation is actually needed).
Documentation is one of our possible contributions to Fortune Hunter later, especially to make things easier for developers working on the project in the future (like the submodule stuff for the fortune engine, which another team was also having trouble with).
Monday, February 28, 2011
Project Progress - Where are we going now?
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.
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.
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.
Wednesday, January 26, 2011
Installing Subversion
As with everything else in Linux, installing subversion was an adventure.
Here's the process (compiled from different sources) I used in case anyone else needs it and for when I have to install it on my other computer later.
Set up users and groups (Ubuntu Help Docs for Subversion):
Had to modify the users and groups directions because they seem out of date, added from the command line instead.
sudo addgroup subversion
sudo adduser <USERNAME> subversion
sudo adduser www-data subversion
Must log out here!
Create repos:
sudo mkdir /home/svn
cd /home/svn
sudo mkdir myproject
sudo svnadmin create /home/svn/myproject
Edit file permissions:
sudo chown -R www-data:subversion myproject
sudo chmod -R g+rws myproject
Install Rabbitcvs:
Integrates nicely into Nautilus
sudo add-apt-repository ppa:rabbitvcs/ppa
sudo apt-get update
sudo apt-get install rabbitvcs-core rabbitvcs-nautilus rabbitvcs-gedit rabbitvcs-cli
Server setup? (subversionary.org)
Still need to figure out if ssh starts at boot, and if not how to start it manually or automatically.
sudo apt-get install openssh-server
svn co svn+ssh://jaime@asus/home/svn/myproject
To checkout:
svn co <address>
To check-in:
Do stuff with document
svn add <document>
svn commit -m "<comments go here>"
Success:
I was able to log into the playground. Checking stuff out downloaded it onto my local drive. I created a test folder and file, added, and committed them, and they surprisingly showed up in the playground, so I must've done something right.
I still don't know how well the server part works, or the best way to go about testing that.
Sugar News:
Still haven't had time to figure out how to install actual Activities in Sugar (due by Tuesday, plenty of time left), but our updated wiki is looking very nice!
Here's the process (compiled from different sources) I used in case anyone else needs it and for when I have to install it on my other computer later.
Set up users and groups (Ubuntu Help Docs for Subversion):
Had to modify the users and groups directions because they seem out of date, added from the command line instead.
sudo addgroup subversion
sudo adduser <USERNAME> subversion
sudo adduser www-data subversion
Must log out here!
Create repos:
sudo mkdir /home/svn
cd /home/svn
sudo mkdir myproject
sudo svnadmin create /home/svn/myproject
Edit file permissions:
sudo chown -R www-data:subversion myproject
sudo chmod -R g+rws myproject
Install Rabbitcvs:
Integrates nicely into Nautilus
sudo add-apt-repository ppa:rabbitvcs/ppa
sudo apt-get update
sudo apt-get install rabbitvcs-core rabbitvcs-nautilus rabbitvcs-gedit rabbitvcs-cli
Server setup? (subversionary.org)
Still need to figure out if ssh starts at boot, and if not how to start it manually or automatically.
sudo apt-get install openssh-server
svn co svn+ssh://jaime@asus/home/svn/myproject
To checkout:
svn co <address>
To check-in:
Do stuff with document
svn add <document>
svn commit -m "<comments go here>"
Success:
I was able to log into the playground. Checking stuff out downloaded it onto my local drive. I created a test folder and file, added, and committed them, and they surprisingly showed up in the playground, so I must've done something right.
I still don't know how well the server part works, or the best way to go about testing that.
Sugar News:
Still haven't had time to figure out how to install actual Activities in Sugar (due by Tuesday, plenty of time left), but our updated wiki is looking very nice!
Tuesday, January 25, 2011
Day Five - Team Reports
Math4 History: Each member of our team contributed something about the history or the people of the Math4 Project to the wiki. Most of the information was gathered straight from Math4's wiki. It's a relatively new project so there isn't much history to really go over, and only a few main contributers are mentioned. The correspondence from the mailing list is a little more encouraging, and we receive pretty frequent updates, especially about ideas for contributing. I think ideally our group would be able to make our own Activity based on one of the yet-to-be-addressed curriculum goals on their site, but that could easily put us in over our heads, so it's probably better to try to contribute to an existing project (with easily-accessible and knowledgeable developers) first.
Presentations: All the other groups' presentations were interesting. I think our class is covering a wide variety of projects though the Flux Capacitors is most relevant to our own. Since we aren't focusing on Sugar Labs specifically, we didn't really look into its history, but the other team definitely gave us some good background information. We will also be addressing the same issues when installing the source code for the main Sugar Labs component so it might be a good idea for all of us to stay in touch during that process.
Other news: I successfully installed the Sugar Desktop Remix using Ubuntu 10.10 following simple instructions here, though the other SugarLabs team pointed out that a different installation method might be better for development purposes, but I guess we'll be finding out very soon. Installing specific Math4 Activities proved to be a bit more difficult since most do not have final releases. Most of the Activities seemed to be located in the git repositories, but I haven't had enough time to do a lot of the "diving in" that's so regularly encouraged.
Presentations: All the other groups' presentations were interesting. I think our class is covering a wide variety of projects though the Flux Capacitors is most relevant to our own. Since we aren't focusing on Sugar Labs specifically, we didn't really look into its history, but the other team definitely gave us some good background information. We will also be addressing the same issues when installing the source code for the main Sugar Labs component so it might be a good idea for all of us to stay in touch during that process.
Other news: I successfully installed the Sugar Desktop Remix using Ubuntu 10.10 following simple instructions here, though the other SugarLabs team pointed out that a different installation method might be better for development purposes, but I guess we'll be finding out very soon. Installing specific Math4 Activities proved to be a bit more difficult since most do not have final releases. Most of the Activities seemed to be located in the git repositories, but I haven't had enough time to do a lot of the "diving in" that's so regularly encouraged.
Wednesday, January 19, 2011
Day Four - Homework
IRC: I had already set up an IRC nickname for last semester's project Exaile, though I never really used it. I use Pidgin for all my instant-messaging needs and it allows easy setup of IRC stuff. I joined both the channels listed on the Math4Team wiki: #sugar and #fedora-olpc, but there's not much going on tonight. It doesn't look like the #sugar channel regularly logs its chats, so no history there, and the #fedora-olpc looks like it only logs meetings. The Math4Team indicates to use the mailing list for most conversations anyway.
Mailing List: Apparently the forwarding of our group gmail account worked (I hope) because I received multiple messages from the mailing list, mostly about new contributers joining, and what we have to offer to the project. I'm not sure how I feel about Brittany's response that we're all "pretty good programmers", but I know we'll each be able to find something valuable to contribute.
The Cathedral and the Bazaar: Eric Steven Raymond compares Linux to nuclear explosions (page 11) in this piece of work. I've never considered that analogy before, but I like it and I think it fits. He describes Linus Torvalds' development process and how it was so different from the earlier ones he had used that he didn't think it would work, but obviously it did (and pretty well). Raymond also stresses the importance of source being open, especially in the development and debugging processes because letting more people see the code (who actually WANT to see the code) greatly benefits the software and its users. Most of his ideas make a lot of sense, and you'd think a lot more people would follow them, but that could just be my biased opinion because I like his pro-Linux viewpoint.
Other news: I tried to install the Sugar desktop while running Ubuntu 10.04. Although successful and I could log in and even connect to the network, there was nothing usable in it, which is actually noted on the wiki: https://wiki.ubuntu.com/Sugar. Next steps are to either install the "appliances" from a USB stick as indicated or set up a virtual machine to run the environment. Or to just do the much simpler install on my other machine running Ubuntu 10.10. Either way, it will be nice to play around with the software first and get a better idea of where we're going with our involvement in this project.
Mailing List: Apparently the forwarding of our group gmail account worked (I hope) because I received multiple messages from the mailing list, mostly about new contributers joining, and what we have to offer to the project. I'm not sure how I feel about Brittany's response that we're all "pretty good programmers", but I know we'll each be able to find something valuable to contribute.
The Cathedral and the Bazaar: Eric Steven Raymond compares Linux to nuclear explosions (page 11) in this piece of work. I've never considered that analogy before, but I like it and I think it fits. He describes Linus Torvalds' development process and how it was so different from the earlier ones he had used that he didn't think it would work, but obviously it did (and pretty well). Raymond also stresses the importance of source being open, especially in the development and debugging processes because letting more people see the code (who actually WANT to see the code) greatly benefits the software and its users. Most of his ideas make a lot of sense, and you'd think a lot more people would follow them, but that could just be my biased opinion because I like his pro-Linux viewpoint.
Other news: I tried to install the Sugar desktop while running Ubuntu 10.04. Although successful and I could log in and even connect to the network, there was nothing usable in it, which is actually noted on the wiki: https://wiki.ubuntu.com/Sugar. Next steps are to either install the "appliances" from a USB stick as indicated or set up a virtual machine to run the environment. Or to just do the much simpler install on my other machine running Ubuntu 10.10. Either way, it will be nice to play around with the software first and get a better idea of where we're going with our involvement in this project.
Tuesday, January 18, 2011
Day Three
Today we presented and chose our team projects. We are doing Sugar Labs, more specifically Math4Team, which designs activities for 4th grade students to learn math. We created a dedicated team email account (after many tries with the image verification) to join the mailing list, but still need to figure out how to get the email to forward to all of our individual accounts.
Thursday, January 13, 2011
Day Two
Today was our second day of class and we did light research on possible projects to participate in for the semester. We decided to look further into three educational projects and hopefully find something we are all interested in and to which we can provide valuable contributions. These include One Laptop per Child, Sugar Labs, and Open Office for Kids.
I also registered for POSSCON today and should be attending Friday, March 25. Looking forward to some free food.
I also registered for POSSCON today and should be attending Friday, March 25. Looking forward to some free food.
Subscribe to:
Posts (Atom)