Day 5

This post may be unfinished. My research has since ended and I decided that the benefits of this blog did not outweigh the time required to continue writing posts. I have decided to post the unfinished posts for continuity's sake.

Today I went back to working on getting GraspIt to compile using Visual Studio 2008.
No matter what we tried, we seemed to get various compiling errors, popping up in different libraries that GraspIt uses.

We first experimented with reverting to an older version of Coin that was known to work with GraspIt. We then upgraded to a newer version of SoQt that supposedly fixed one of the issues we were having. None of this however fixed all of the compiling issues.

We then decided to revert back to an older version of Visual Studio (2005), which was known to work with GraspIt. We no longer ran into the same compiling errors, but now ran into a new linking error with MKL.

Day 4

This post may be unfinished. My research has since ended and I decided that the benefits of this blog did not outweigh the time required to continue writing posts. I have decided to post the unfinished posts for continuity's sake.

Today I came in on Friday and worked half a day.
My primary goal was getting the bitten slave to run properly on the virtualized machine.
While I could get the slave to connect to bitten properly, and pull the build recipe from the server, the slave refused to connect properly to the svn repository and continually gave me an authentication error along the lines of

... authorization failed: Could not authenticate to server: rejected Basic challenge ...


Although bitten allows you to pass a username and password to the slave at run time on the command line, this username and password seem to be used specifically by bitten and trac, but not for svn.

The solution: Using a slave configuration file. Slave configuration files sit on the local machine where the slave is running and are passed to the server when the slave connects. They basically give the server information about who the slave is and what configuration it is using (name, operating system etc.) In bitten's own words:

When a build slave registers with a build master, it sends information about the machine the slave is running on, and what software it has available. The build master uses this information for matching the slave against target platform rules. While some of this information can be automatically discovered by the slave, other information may need to be configured explicitly. Also, a slave instance may want to override some of the automatically computed attributes, for example to enable cross-compilation.

How does this help us? Well, you can pass information about anything in the configuration file (as long as it's a short text string that you can put in the .ini file that is the configuration file). Some values passed in the configuration file are automatically used by the build master, such as machine name and operating system. The big benefit though, is that in a bitten build recipe, you can use these passed values to parametrize your recipe. For example if I include the following code in my configuration file:

[foo]
bar= baz


in my recipe I can then refer to this as ${foo.bar} which will be replaced by baz when the recipe is run.

It's clear how useful to us this can be. If we can pass the svn username/password information we want to use, then we can tell the slave to use those details for the check out. This extends beyond just the username/password combination, we can use this to determine the local directory to which we want to save the files checked out the from the repository- especially useful for being compatible on multiple operating systems.

I also worked on writing a script that runs the bitten client on startup and makes sure that the bitten client is running at all times. It's a short python script that checks if the bitten client is listed in the task list, and if not, it runs it. This is linked to a system task that runs every few minutes, every day, thus ensuring the client is always running on this computer.

Day 3

There is a blizzard in New York this week and so the lab is empty. All CUNY schools and public schools are canceled, as well as JTS and Teachers College. Columbia has canceled classes from 3pm onwards due to the weather.

I started off today playing around with the bitten slave again. My first goal was to get the slave to check out the GraspIt! code to a directory that is accessible. Jon figured out a few days ago that if you pass it an absolute directory, rather than a relative directory as we had been doing, the bitten slave actually checks out the code to the right place.

I adapted last week's recipe given the new knowledge and successfully checked out the code into my directory on the server. I then adapted the code for a second recipe meant for Windows boxes (of little help without the windows slave working).

I then returned to working on getting Python and the bitten slave for windows to play nicely together. I stumbled on this little site which got me up and running on my main Windows XP box. It would appear that the issue was a combination of Windows not knowing where Python was, Python not knowing where the slave program (script?) was and the lack of "Setuptools" which I got here:

http://peak.telecommunity.com/dist/ez_setup.py

I successfully got the Bitten slave to connect to the server from the Windows XP box, and after installing subversion, successfully checkout out the GraspIt! source on the XP box.

Unfortunately, these steps didn't seem to translate directly to the virtualized XP box. After some hair pulling, I realized the issue was a stray space in the path variable. It connects fine from the virtualized box now, but is still having issues with authenticating my user with the repository. I think I can get it working if I play around with the slave configuration file. Saving that for next week.

Final note: Did a little research into using gtest, the Google test framework.

Day 2

Today I started off the day by installing SP2 on the virtual machine. While it was installing I transferred all of the files I downloaded last week onto the virtual machine, and extracted the libraries. Once SP2 was installed, I installed Visual Studio 2008.

GraspIt! uses the Qt library and according to the manual, works better with the source code, so I stated to build Qt from the source (which is apparently a very long and slow process). While Qt was building I decided to start experimenting with Bitten.

After gaining access to the trac and bitten sites, as well as ssh to the server I logged into the admin area of bitten. Bitten allows you to write "recipes" in XML, that tell a bitten client or "slave" what actions to take. The slave connects to the server, checks which recipes are waiting for it to run and then runs each recipe in its cue.

My first goal was to write a basic "Hello world" recipe, and to get a slave running on the server to connect to itself and run. The next stage was to get the slave on the server box to check our the GraspIt! code from subversion. This is where I hit a small roadblock.

The recipe would run, and you could follow the checkout process in the console but the files didn't seem to actually get saved anywhere. I realized that you can specify a path for where to check out the files, but still no luck.

I decided to move back to working on the virtual machine and attempt to connect with the slave from the virtualized WinXP box to the bitten server. Unfortunately, I know nothing about Python and this is all based on Python so I'm going to have to do some reading.

I installed Python and the bitten slave on both the virtualized WinXP box and a standard WinXP box but I haven't had any luck getting them to run or connect to the server yet. I'll need to play around with this next week.