How I Learned to Stop Worrying and Love Eclipse

How? I’m not here to tell you… because I don’t know yet, besides, this is not about Eclipse.

If you’ve spent the last week trying to make WebObjects+WOLips+Eclipse work on Ubuntu, like me, you’ve probably already tried following guides like this one, or this. After a while you find yourself staring at WOLips in Eclipse wondering why the frak does it not recognize all these delicious WebObjects frameworks you freshly extracted from XCode 2.5 with a 17″ Powerbook G4 that is still running good old 10.3.9. This might solve your problem…

Bitten by the Version Bug

For the past week, I’ve been struggling with getting OLM installed in Ubuntu, while Qi struggles with getting Web-CAT built. Every time we figure out what’s wrong, it seems that the culprit is always the same: versions.

OLM documentation isn’t that bad, except that they forgot to include some of the dependencies involved. And it turned out that this is very important to make it run. The first mistake that I made was blithefully ignoring the current version of python Ubuntu was hooked on (which was 2.5) and proceeded to install it on the older version 2.4. Once I got to the point of installing modules, I then realize that using ‘apt-get install’ (which was another mistake on its own) installs the modules on the latest version. Turns out that you can specify which version of python you want to use by editing debian-defaults file and specify the version to use. This is when I’ve also discovered easy_install which makes life a bit rosy when installing modules, especially on a specific version. Just execute ez_setup.py to install it on a specific version of python and voila! you got python modules at your fingertips.

Once I got out of the apt-get hell, I then ran into the problem of compiling one of the modules that I need: PyXML. Turns out that it needs another python module (python-dev) that I couldn’t figure out how to install on 2.4 Edit: turns out you can do this with python<version>-dev. After giving up, I finally decided to manage my own python installation (building from scratch) and installed everything in it. I then override my $PATH with my custom python installation. At the end of the day, I finally got OLM up and running (even took me a while to figure out the default authentication to log in), with one exception: nothing was running. This was frustrating after a few days of wrestling through it.

After some laborious debugging, I finally tracked down the error: the version of TurboJson I was using (1.1.1) was in conflict with OLM. Even if the OLM doc specified to use TurboGears 1.0.2.2, installing TurboGears have other module dependencies and that it automatically downloads all the latest versions. The worse part is that OLM hides the error with its AJAX front-end so there was no way to see what’s going on without debugging (firebug not working well with FF3 is another story). Turns out latest version of TurboJson is throwing some AmbiguousMethod that can only be resolved by either changing the OLM source or downgrading TurboJson. So I chose the latter, and everything seems to be working like it should be.

With all this, I think it’s safe to say that we programmers still have a long way to go in resolving dependencies that do not break on every upgrade. The terms design-by-contract and program-to-interface always comes to mind on these occasions. For now the best remedy is to document everything, until someone comes up with a solution to make dependencies resolve itself on its own and make them, as Greg always says, either famous or filthy rich.

Hard to see an Ant with all this sand…..

While trying to write an Ant script that will run python files, test them and return a coverage report I run into the following problems:

– Cannot pass a pattern of file types into exec task.

– Coverage report for the wanted file types return 0 percentage!

– Coverage execution of files can’t get a bunch of files in the command line but just one by one

– Nosetests coverage is not working

– Didn’t find a useful loop in ant (for, foreach are not recognized) for iterating over files passed to coverage.

Solution:

exec needs to be thrown away in favour of the apply task! Apply task can get a set of files as an external command (filsets). By removing the coverage.py file from /usr/bin the nosetests command with coverage (see nosetests -h for more details about options) works but give a different percentage result from the coverage tool. So by using the apply task with the coverage.py tool and -x as an argument the tests files are executed. After that command, coverage.py needs to be executed again with -r to gather all the reports saved before.

Now we have all the test results, all the coverage reports, Do we need something more or we found all the ants?

Brief Update: A New Hope

Building WebObjects: No significant progress, tried to switch back to 5.3.3 frameworks, Eclipse/WOLips doesn’t see all the frameworks (less that what’s working in 5.4). However, we do have a clearer idea on licensing terms, seems copies of OS X is what you need… Stephen Edwards might be able to help with his spare 5.2 license and install package, but that have to wait.

OLM: Trying to see how PinkHippo plugin works, no dice since the CSC209 account I have access to doesn’t really support the plugin. We need to get an account on a test OLM server to see what PinkHippo can do, then replicate those in Web-CAT plugin.

Stephen and his team are very helpful in that they agree to implement the APIs we want, now we have to figure out what exactly we need.

Right now the priority would be to give Stephen the specifics of what we need, WebObject build environment seems to be a more long-term goal…

p.s. “Indiana! Indiana, Let it go.”

Officially stuck

After last week’s eventful demo, Eran continued his work on the python plugin, while Geoffrey and I have been trying (fruitlessly) to setup a WebObejcts development environment and get Web-CAT to build. While our original goal of building just a plugin for Eclipse still stands, it seemed a “good” idea to breed ourselves a copy of the feline, in order to figure out how does the grading component talk to the WebObjects backend. Since we have few clues about the existence of a protocol to make database queries (pulling down student assignments + uploading grading info), such a mechanism may need to be added to the server if not already present. Furthermore, judging from the feedback we received from the demo, there are no shortage of rough edges in the system that we can certainly polish if there is time.

After two days, at this point, we are officially stuck. Numerous installation guides for Mac/PC were followed and my Eclipse crashed and restarted every 15 minutes, but in the end the WOLips plugin just can’t build and run a project properly. It’s likely that webObject installation on ubuntu is at fault, but no way to tell at the moment.

Looking forward to the meeting with Stephen Edwards.

p.s. if he has no idea then we are truly hopeless

So…what is Web-CAT?

In the spirit of preparation for our Web-CAT demonstration this Friday, I figure I’d try to sum up what we’re trying to do this summer to our non-existent readers out there. If you want the more official answer, then you should go here but succinctly put, Web-CAT (Web-based Center for Automated Testing) is a way for instructors to setup an automated marking portal for students to submit their assignment to.

What’s nice about it is that students get an almost instantaneous feedback as to whether their code is up to par with the expected test results.  We have only tested it for 5 stub users so far, so we have no idea how scalable it is, but apparently it is being used in several universities/colleges already.  Also, plug-ins are also available to submit assignments within popular IDEs such as Eclipse and BlueJ, which means students have less excuse to procrastinate while switching windows to submit through the browser (no more “Firefox made me do it” excuses).

So, why did we pick Web-CAT as a project to work on this summer? Well, a few years back, one of the course projects here at U of T was an Online Marking Tool (OLM), which is a way for students to get a more sophisticated feedback from instructors.  More importantly, it also allows easy marking for TAs by providing tools such as easy-to-click rubric, inline code comments, etc which helps them avoid throwing student code print-outs in the air and catching them to see who gets the A+ in the class.

As far as I know, the plan this summer is to pick out the features that are “best-of-both-worlds” and integrate them into this one supercool application that hopefully will take over the world someday.  Hopefully, we can start off this iteration with a bang and to see what we can come up with over the next several months.  And while we’re at it, maybe we’ll try to create an app that does the studen’ts assignments for them as well.

Let the game begin!!!

To projects that we are working on and will be blogged here during 2008 summer:

– Web-CAT plugin for supporting python programs

– Eclipse plugin to support grading on Web-CAT server

For now on we installed Web-CAT on our machines and checked out the repository so we could go over the source code. First of all we have to be expert on the program so that we would be able to understand all the problems and questions that could rise during the next weeks. For this reason we spent a lot of time figuring out how to handle the program and  prepared a presentation that will be presented to our mentors this week.