Wednesday, February 23, 2011
The cost of boredom
Tuesday I decided to do the exercises for TOS Chapter 7 because I was at a loss for something else to do. Now today I'm finding myself without anything about which to blog. I updated our team's wiki page to reflect our decisions regarding our "bug" and semester contribution to the OpenKinect project. Briefly, we need to figure out the USB Control Command structure, write a USB control command for the OpenKinect libfreenect library, and then use it to manipulate the RGB camera in the Kinect controller. Hopefully, it'll be as easily done as said, but I'm doubtful it'll be simple.
Tuesday, February 22, 2011
TOS Chapter 7
Chapter 7 of the Teaching Open Source book is about patches. In short, patches involve running the diff command on a file that has been changed.
Exercise 7.2.2
The -u option to the diff command makes for a much more readable output, and it even includes some context (which isn't strictly necessary since "hunks" of code are labeled with line numbers.) The diff command without the -u option is still useful, it's just not as easy to read.
In the initial, simplistic example, only one file was modified and patched. A more comprehensive example followed which made a change to two files in a directory and a diff was applied recursively to the directories. This captured the changes to all files within the directory, which will be much more useful when working with huge source code directories.
Both the individual file and the directory diff patch methods are not using an SCM. Using an SCM to create a patch is almost identical, except, instead of using two different files/directories, the SCM compares changes in the current working copy against the most recent revision. The latest HEAD code should always be used when making a patch, so that the development team can more easily integrate the patched changes.
Applying a patch is a simple matter. It's similar to the shell redirect described in the initial diff section, only instead of redirecting the output of a command to a file, a file is redirected to the input of a command. That command is, shockingly, patch. Running patch from the directory in which to make changes seems easiest. The option exists to run the command from root, but I don't fully understand the -p flags. From the text it sounded like I could strip off x number of directories from the paths listed in the patch, but if I'm running the patch from the root directory, wouldn't those files then exist in the root directory? I'll have to remember to ask about this in class.
I think I missed the point of Exercise 7.8. Creating an empty file called foo, and then running diff on that new file against /dev/null resulted in no output from the diff. I imagine that's because both files are empty and there's no difference between them.
So I asked about the exercise in class; turns out, the fonts on my screen look too similar to tell apart. I was supposed to create an empty file called foo and put "bar" as the contents of the file. This would have yielded some output from diff -u when run against /dev/null.
Exercise 7.9 was almost identical to the example for running diff on a single file from the very beginning of the chapter. The only difference was the file was located at the end of a path, instead of in the working directory. The patch file was formatted exactly the same.
Exercise 7.10 tells us to make a patch for our selected project. We're steadily working on that, and I'm convinced we'll have this feature request completed "soon."
Exercise 7.2.2
The -u option to the diff command makes for a much more readable output, and it even includes some context (which isn't strictly necessary since "hunks" of code are labeled with line numbers.) The diff command without the -u option is still useful, it's just not as easy to read.
In the initial, simplistic example, only one file was modified and patched. A more comprehensive example followed which made a change to two files in a directory and a diff was applied recursively to the directories. This captured the changes to all files within the directory, which will be much more useful when working with huge source code directories.
Both the individual file and the directory diff patch methods are not using an SCM. Using an SCM to create a patch is almost identical, except, instead of using two different files/directories, the SCM compares changes in the current working copy against the most recent revision. The latest HEAD code should always be used when making a patch, so that the development team can more easily integrate the patched changes.
Applying a patch is a simple matter. It's similar to the shell redirect described in the initial diff section, only instead of redirecting the output of a command to a file, a file is redirected to the input of a command. That command is, shockingly, patch. Running patch from the directory in which to make changes seems easiest. The option exists to run the command from root, but I don't fully understand the -p flags. From the text it sounded like I could strip off x number of directories from the paths listed in the patch, but if I'm running the patch from the root directory, wouldn't those files then exist in the root directory? I'll have to remember to ask about this in class.
So I asked about the exercise in class; turns out, the fonts on my screen look too similar to tell apart. I was supposed to create an empty file called foo and put "bar" as the contents of the file. This would have yielded some output from diff -u when run against /dev/null.
Exercise 7.9 was almost identical to the example for running diff on a single file from the very beginning of the chapter. The only difference was the file was located at the end of a path, instead of in the working directory. The patch file was formatted exactly the same.
Exercise 7.10 tells us to make a patch for our selected project. We're steadily working on that, and I'm convinced we'll have this feature request completed "soon."
Saturday, February 19, 2011
5th Annual CofC CS Alumni Symposium
Tuesday, February 15th, 2011. A series of computer science alumni present various topics ranging from getting hired after graduation to advice on how to be a successful graduate student. I enjoyed seeing people I actually had classes with presenting at the alumni symposium. Clearly, the CofC CS department prepares us for success.
Some tidbits of useful tips I gleaned from the presentation: have an interest outside the computer science field, play a musical instrument, have a wide breadth of knowledge in a small company and a large depth of knowledge in a small company, have a specific interest within the computer science field, get involved in a project in that interest, have excellent communication skills, read about CS current events, and my favorite, get enough sleep.
Some tidbits of useful tips I gleaned from the presentation: have an interest outside the computer science field, play a musical instrument, have a wide breadth of knowledge in a small company and a large depth of knowledge in a small company, have a specific interest within the computer science field, get involved in a project in that interest, have excellent communication skills, read about CS current events, and my favorite, get enough sleep.
Thursday, February 10, 2011
The bug you know
Ashley found a bug that he feels we will be able to fix. "Bug" in this sense is actually a feature request, but we feel that qualifies. The gist of the bug is that the RGB camera has autoexposure, and at least one user wants to have manual control of gain and exposure. There's documentation related to this problem.
I noticed in Ashley's blog a comment from Drew Fisher, one of the people who reverse engineered the camera protocol. He's currently working on unlocking the camera in the Kinect, including features that the Xbox doesn't currently use. He's offered to help us with questions involving libfreenect, and the Kinect controller.
I noticed in Ashley's blog a comment from Drew Fisher, one of the people who reverse engineered the camera protocol. He's currently working on unlocking the camera in the Kinect, including features that the Xbox doesn't currently use. He's offered to help us with questions involving libfreenect, and the Kinect controller.
Monday, February 7, 2011
Building OpenKinect and TOSS Ch6
Building OpenKinect
Thankfully, our new project is being developed on the current release of Ubuntu. The instructions for downloading the OpenKinect source code and building it are quite accurate, as of today. There is a note that says the instructions are subject to change, but with the project only being a few months old, I guess there haven't been many drastic dependency changes yet. All told, this project took about 3 minutes to download and build.
TOSS Ch 6
4. One problem I have with our new project is that the only bug-tracker I've found is Github issues, a sub-page of the project's github site. There are only 2 bugs listed there, and they're both 2 months old. That's two-thirds of the project's life to date. The oldest is related to packet loss in the depth view.
5. Creating a github account was a simple task. Click login, select pricing options, select free for open-source, input the data, and you're done.
6. I don't personally have a Kinect controller, so I will have to rely on Ashley to reproduce the bugs we find.
7. Another severe limitation with github issues is that it's not really a bug-tracker. According to FOSS chapter 6, a bug-tracker should have a Summary, a Description, Comments, a Reporter, an Owner, a Version, a Severity and Priority, a Status, and a Resolution. Github allows Reporters to tag their issues as bugs and they can write a description of the bug. Other users are able to leave comments on those bugs. Unless the Reporter has foresight, the Version could be completely left out, and Owner, Severity/Priority, Status, and Resolution aren't even addressed at all. With these limitations, performing triage on our project's bug list would require porting all the information to a real bug tracker, like Bugzilla for instance.
Despite the failings of Github as a bug-tracker, we can at least build the source, and with Ashley's Kinect controller, we can attempt to replicate and test the reported bugs.
Thankfully, our new project is being developed on the current release of Ubuntu. The instructions for downloading the OpenKinect source code and building it are quite accurate, as of today. There is a note that says the instructions are subject to change, but with the project only being a few months old, I guess there haven't been many drastic dependency changes yet. All told, this project took about 3 minutes to download and build.
TOSS Ch 6
4. One problem I have with our new project is that the only bug-tracker I've found is Github issues, a sub-page of the project's github site. There are only 2 bugs listed there, and they're both 2 months old. That's two-thirds of the project's life to date. The oldest is related to packet loss in the depth view.
5. Creating a github account was a simple task. Click login, select pricing options, select free for open-source, input the data, and you're done.
6. I don't personally have a Kinect controller, so I will have to rely on Ashley to reproduce the bugs we find.
7. Another severe limitation with github issues is that it's not really a bug-tracker. According to FOSS chapter 6, a bug-tracker should have a Summary, a Description, Comments, a Reporter, an Owner, a Version, a Severity and Priority, a Status, and a Resolution. Github allows Reporters to tag their issues as bugs and they can write a description of the bug. Other users are able to leave comments on those bugs. Unless the Reporter has foresight, the Version could be completely left out, and Owner, Severity/Priority, Status, and Resolution aren't even addressed at all. With these limitations, performing triage on our project's bug list would require porting all the information to a real bug tracker, like Bugzilla for instance.
Despite the failings of Github as a bug-tracker, we can at least build the source, and with Ashley's Kinect controller, we can attempt to replicate and test the reported bugs.
Wednesday, February 2, 2011
Building Freeciv
I'm happy and sad all at once. Building Freeciv was so easy as to be almost mindless. Certainly, there were some bugs to be found, but compared to trying to build Empathy from the source available, Freeciv was simple.
There were some dependencies missing from my system, but the Package Manager was more than able to take care of finding them. I tried using apt-get, but they had some odd names compared to the clues the autogen.sh script gave. Also, I think many of the packages I had to install for Empathy were ones required by Freeciv, so I had a lot less to search for during this build process.
Problems aside, this build process was how I was hoping Empathy would have gone. Perhaps it makes sense that the homework assignment, meant for only a couple days of effort, would take so much less time/effort to compile and run than the semester-long project did.
As a small update to the Empathy problem, it's still a problem. As yet, I've been unable to get Ubuntu 11.04 to install, even on a virtual machine. I've not yet given up hope, but success is looking less and less likely.
There were some dependencies missing from my system, but the Package Manager was more than able to take care of finding them. I tried using apt-get, but they had some odd names compared to the clues the autogen.sh script gave. Also, I think many of the packages I had to install for Empathy were ones required by Freeciv, so I had a lot less to search for during this build process.
Problems aside, this build process was how I was hoping Empathy would have gone. Perhaps it makes sense that the homework assignment, meant for only a couple days of effort, would take so much less time/effort to compile and run than the semester-long project did.
As a small update to the Empathy problem, it's still a problem. As yet, I've been unable to get Ubuntu 11.04 to install, even on a virtual machine. I've not yet given up hope, but success is looking less and less likely.
Tuesday, February 1, 2011
Building Empathy
Downloading Empathy was a breeze. Using Github was no different from using the command line with Subversion.
Building Empathy from that downloaded source has proven to be most infuriating. The source depends on libraries that aren't released yet, so in order to develop the code, one must first find the as yet unreleased libraries. The up-side to finding these libraries is they're part of the alpha release of Ubuntu 11.04. The downside is, to get them, you have to use an alpha release of an operating system.s
It's possible to get Empathy from the Ubuntu Software Center and run it from there; however, this won't help us see our changes once we start adjusting the code. Unless one of my teammates has found success in the build/install process, we may have to change our project.
Building Empathy from that downloaded source has proven to be most infuriating. The source depends on libraries that aren't released yet, so in order to develop the code, one must first find the as yet unreleased libraries. The up-side to finding these libraries is they're part of the alpha release of Ubuntu 11.04. The downside is, to get them, you have to use an alpha release of an operating system.s
It's possible to get Empathy from the Ubuntu Software Center and run it from there; however, this won't help us see our changes once we start adjusting the code. Unless one of my teammates has found success in the build/install process, we may have to change our project.
Subscribe to:
Posts (Atom)