Reworking Chapter 7

I had already made it through most of chapter 7 assignments over the weekend--well at least up to the problem one  in 7.8 with very little issues.  I was already rather familiar with diff from last semester and using it as described in 7.2 & 7.4 gave me the results that I expected it would.  I got tripped up a little in 7.5 with the subversion aspect of it, but I was able to back up and make sense of my error and move toward where I would eventually get stuck.  No it was not the patches in 7.6 or 7.7--which we've already finished, but with 7.8.  First of all, I was totally confused with the instructions.  After reading it several times, I looked through several of my classmate's blogs and saw that I was not the only one.  The whole first sentence throws me and the way I understand it, I'm supposed to have a file named "bar" with some data in it; then my patch file creates a file named "foo" which will have a copy of the contents in "bar."  I worked on this angle, but didn't have any success.  I could have two files "foo" and "bar" with contents in them and can combine them with the patch (and diff them of course) but really never was able to do what I think 7.8 is asking me to.  I'll pay close attention today to how other's handled this problem!

Patch Convention

Working through chapter 7 was interesting...and the major command "diff" was something that I was familiar with.  We used diff last semester when comparing our oracles with the newly created output to determine if there was a difference between the two.  It was nice to already have a foundation to build on with this.  Everything went along well with the experiments until I hit the “patches generated with subversion” section.  (Actually that went ok once I got a handle on it)  I toyed around within my subversion server until I was able to duplicate the results…an interesting experiment to be sure!

On our group note, Francis created our patch this past Thursday and we submitted it right away (we really wanted to be the ones to finish what we started) to the Sugar Lab’s bug tracker.  We were all pleasantly surprised when we received our email from them yesterday showing that the patch had been accepted and the bug was now closed.  While we are still enjoying our successful moment, we also have been working on ideas for the remaining of the semester.  If all goes well, we should have an agreement on that within another day or so….then we will all be looking forward to creating the next patch!

Sugar Lab's Features and Quirks

Much of what I've done this week (aside from the research paper I've been attempting to tackle) is to spend time exploring the different features that Sugar Labs offers.  I didn't realize until the other day that there are add-ons aside from the core offerings.  I had assumed that games were accessed under one of these core features that I had not explored yet; however, my experience from Freeciv has taught me to avoid contaminating my Sugar Lab's workspace...I've had quite enough experience installing Ubuntu and building the code for Sugar Labs already this semester.  It was interesting to know though...maybe after the semester is over and no harm can come to my project, I might consider exploring some of those add-ons.

Of all the standard features that come with Sugar Labs, Browse drives me crazy.  Although it does not have any bearing on the area that our project has us focused on, Browse simply will not work on our Ubuntu boxes.  The best we can determine is that one of the dependencies for Browse is an OLDER version than what comes with Ubuntu.  Browse does not recognize the newer version and Ubuntu gives you errors if you try to install the older version of the dependency.  Since we already have much to do, it doesn't make sense to keep beating this issue....but it is annoying!

Exploring Features of Sugar Labs

Last week was refreshing...the bug that Stephanie found had not been submitted before so we were able to get in on that process from the beginning.  We spent the time to create a model ticket (as we had learned from our bug tracker exercise) and carefully worded each step.  Once we were satisfied, we submitted our ticket and waited...which didn't take long to get a response.  The first email came probably 3 hours from an admin and the "acceptance" of our ticket came in less than 2 hours after that--so we are all happy.  The fix should be straightforward and we'll move on from this with a little confidence and experience under out belts.

For today, I'm looking forward to attending the Alumni Symposium...although I can't be there before normal class time because I don't get off work until 1...but I'll sneak in hopefully around 1:30 (depending on traffic and parking getting there).

Trudging forward

Our group is finally recovering and getting back on track only a week after our Freeciv disaster.  This tragedy came just as we were starting to catch up (after switching projects) and were in the process of taking aim at bugs.  Now, while there is still one issue with Ubuntu yet to be resolved it seems that our team is again on solid ground—or at least we have a firm foothold of where we’re supposed to be.  At our last meeting, Stephanie brought up a potential bug that she had noticed (that was not listed in the bug tracker) and everyone agreed that it appeared to be a valid avenue to pursue.  None of us have been able to find this bug in any of the already listed bugs in Sugar Lab’s bug tracker—so not only do we have a bug that we can tackle, but it is one that hasn’t been reported before.  Now with our boxes finally somewhat stable, our source code built, and a solid direction to turn our attention towards, it appears that we’re ready to move ahead.

There is only one sad realization that I have had to accept this week.  I like using the virtual box for operating systems that I really don't want on my machine, and I was looking forward to figuring out the full screen add-on.  Since my group and I have been so busy putting out fires with our project I just couldn't justify investing the time in figuring out how to make my virtual box run in full screen.  Once I had ubuntu re-installed on my virtual box (for the umpteenth time it seems) and Sugar Labs built & running, I made a snapshot and began my attempt at installing the software required.  With very little effort I was pleased at the results of seeing my virtual box fill the screen--like it did when I had the dual boot system.  Then came what I was afraid of....when I ran the command to open up Sugar Labs, their emulator failed to open.  After looking it up and trying some suggestions I began to realize that it just wasn't worth the effort.  Evidently the Sugar Lab's emulator has a problem with the stretching that the Virtual Box does to make everything run full screen.  So, thankfully I reverted to my snapshot and everything runs as before (learned my lesson from Freeciv).  I also found a trick that does help when I run Sugar Labs in my box.  When I run the Sugar Lab's command, I can add dimensions for it to run in.  This allows me to force it to run in a smaller window than my box--allowing me to see what Sugar Labs was showing but my screen setting wouldn’t allow me to see.

So now we’ll settle down and tackle this bug and hopefully have a pleasant experience (especially after such a rocky start).

Continuing last post

Well I thought that I would sit down today and continue with the assignment from where I left off last.  So I go through and read Ubuntu's triage page and thought I would give this part of the assignment a try.  So first I went to set up an account with Ubuntu and waited a while for an approval.  What I didn't realize was how long it would take to receive my 6-digit confirmation code to actually submit anything (over 2hrs later and still no response) unlike the speedy response from the Sugar Labs bugs account.  While I waited, I went to their untriaged bug page to get a feel for what they had.

Ok...this was no where as clean as Sugar lab's page.  To start with, there were 23,600+ untriaged bugs--way more than Sugar Labs.  The next thing that struck me was that there were some with 3 word summaries (too little) and whole paragraphs (some of these you could feel the writer's emotions--and my little experience with ubuntu has cause me to empathize with them), but the format that the board has keeps things in an orderly fashion.  They must be assigned a ticket number automatically (makes it easier to come back to) and all those I looked at had use cases, platforms used, dependencies installed (and in some cases screenshots) all of which are very useful!  I even found one that related to a problem that I had...ticket#714688 I needed that Evolution plug-in for my phone to sync with Evolution, but when I couldn't get it to work I gave up & continued to sync with windows.

Without having my access code, there wasn't much that the system would allow me to do other than look through them--even marking one as a duplicate required a login.  So I picked a few and quickly did in notepad what I would  have done on their forms (well as best as I could have) just to get a feel for it.  Maybe sometime later today they'll actually send me an access code...of course with my feelings on ubuntu maybe they shouldn't :)

Recovering from Freeciv & beginning new assignment

I really had to laugh when starting this reading—bugs was a poignant topic after working on the Freeciv problem earlier in the week—not for what the assignment was about, but for what it caused.  Other members of my group had a worse experience in terms of the damage it inflicted on their machines so I really should not complain.  Evidently Freeciv must have changed some dependencies or settings because some of the functions of our build that were working—now were broken.  So the most important lesson that I learned from this experience, was to create a quarantine box for any work that is due outside the purview of our project…no sense in adding work that I’ve previously completed to an already hectic schedule!

Back to the bugs….well the second part of our assignment (finding out how to set up a bug-tracker account) was extremely easy—thanks to Sugar Lab’s well organized wiki.  It was prominently displayed on their wiki—which only asked for me to create a username/password and to provide an email address in case I ever needed to reset the password.  This new “access” didn’t really change what I saw before, but presented it differently.  It showed where bugs had been assigned (without having to delve into the ticket) and ordered the tickets a little differently.

The first part of our assignment was to find the oldest bug that Sugar Labs has; well there are actually 3 of them at 2 years (no specific date given on the ticket only a general time frame) and all of these 3 are actually more of “enhancements” than bugs; for example, ticket #405 “Insufficient feedback on pressing of Keep button in non-optimal viewing conditions.”  This is only relevant to certain types of monitors (XO and SoaS with LCD screens) where a bit of a glare can cause the user to inadvertently hit the wrong button causing their harm to the project they were working on.  Bug #405 is one of the few tickets that do not have a lot of feedback posted and I think it just isn’t a priority.  I would assume with this only affecting a very limited number of monitors that it is hardly worth the effort to explore—(and to reproduce the “bug” one would have to have the specific type of monitor) which are two reasons I would  give as to why it has been around for 2 years.

Recreating a bug (the third part of our assignment) was the easiest of all.  Bug ticket #1997 states that “Read fails to start if Hal is not installed.”  I know for a fact that all my dependencies have been installed and Sugar Labs source code was successfully built on my box.  When I attempt to open “Read” it flashes then gives the message “Read failed to start.”  I read a little more in the ticket (updated 19 hours ago) that a patch for this problem has been created, but is waiting on approval from the activity maintainer before it can be integrated.  Hmm…a long approval process maybe?

The last part of the assignment is to work on triaging 5 new bugs.  After reading what goes into triaging, it would be too simple to take those from Sugar Lab’s site…they appear to already be organized and defined well beyond my abilities.  I went to the links for GNOME, Fedora and Ubuntu and think that’ll be where I start.  In fact since my disdain for Ubuntu is growing daily, I’ll make an account there and see how that turns out—there should be PLENTY of bugs for this OS.  I’ll work on that tomorrow…after at least a couple of hours sleep!

Both Builds Successful!!

Well there are several promising successes since my last update; the first being that Sugar Labs has been successfully built.  We stayed after class as a team and worked on getting the code installed on our machines...so far we have 2 of our 4 boxes running Sugar Labs, and we are confident that we can replicate it on our other two boxes.  I must say that I really like using the virtual box...it allows me to keep my windows environment up (instead of having to reboot several times each day to sync my phone to outlook--wonderful!) while still doing what I have to do in a different OS.  This wasn't the reason for using it, but (other than having to waste so much time setting ubuntu back up after its crash) it has been a worthwile endevor.  Just for fun I installed Debian virtually as well--had some password issues that Clay helped me overcome--although I still haven't been able to spend enough time to get Sugar Labs on it too (there are some hated dependency problems there too) but maybe over the weekend I'll get some time to tinker with it--just to have a backup in case ubuntu decides to crap out again.

Anyway, I started working through the Freeciv problem from our book and like the concept.  I always learn better doing things--especially with a model to follow or when there is help close by when I get overwhelmingly stuck.  So, I start following the directions and quickly realize that there are subtle differences in commands from linux to ubuntu; for example, in the early steps I was instructed use yum install....but in ubuntu (at the root) we use sudo apt-get install (or without the sudo if not something to be installed at the root).  I also noticed that some of the dependencies had names that were different in Ubuntu as well.  Overall I only got stuck once and after some much needed sleep I was able to overcome that road block as well.  Did kinda feel a little deflated afterwards when there weren't enough "human" players to see what happens.  I also gained a little more appreciation of windows in this too...I realize they install lots of things you don't always need, but chasing down all those dependencies can be time consuming and mentally taxing (but to each his/her own).