SWT Error in Eclipse on Firefox 3 RC1 update

Apparently, Eclipse has this weird dependency on Firefox through the SWT library.  After upgrading to Firefox 3 RC1 on Ubuntu 8.04 due to Firebug not working, Eclipse started throwing an SWT error with the following log in <workspace>/.metadata/.log file:

org.eclipse.swt.SWTException:
Failed to execute runnable (org.eclipse.swt.SWTError:
No more handles (java.lang.UnsatisfiedLinkError:
no swt-mozilla-gtk-3349 or swt-mozilla-gtk in 
swt.library.path, java.library.path or the jar file))

Luckily, I’m not alone and bearfruit.org suggests solving the problem by typing:

sudo apt-get install xulrunner

or

sudo apt-get install xulrunner-gnome-support

on console, restart Eclipse, and problem solved.

Advertisements

June 18, 2008 at 5:34 pm Leave a comment

Blooming time!

First of all the python plugin for Web-CAT is ready to be tested!!!

(Luke will try to break it next week…)

A full feedback is generated including a colored html version of the student submissions!

Comments can be added to the files from the web browser by the TAs and instructors!

The html version of the student files is actually created so that Web-CAT will know how to refer to the data and  display it with all the inserted comments from the browser. That means that all the files submitted to Web-CAT servers will have to have the same structure.

Next week will be dedicated for research. I will need to learn more about how to sandbox python so that the files will be run in a secure environment on the servers.

Three major meetings had been held this week:

– The first one was with all the summer students/mentors and each one had 60 seconds to explain what he accomplished till know and what is his situation.

– The second meeting was with four TAs that used OLM in the past so that we could get a reasonable feedback for the usuability and interface problems.

– The third was with Gene Amdur, that generously came to give us some piece of advice. We figure out together a schedule for the rest of the project time so that we will be efficient as possible. In addition we got a lot of advice from the experience of a well known figure in the industry (As well stories about Gerg Wilson…).

June 13, 2008 at 9:07 pm 2 comments

Update: Spilling The Guts

Eran: trying to add syntax-coloured code view to python plugin, turns out it needs Web-CAT itself to generate the html page. 

Geofery: Generating ideas for Eclipse plugin’s GUI designs, and documenting the prospective API to talk to Web-CAT which Stephen is quick to implement,

Qi (me): Looking at the TODO list from last week’s meeting, going through a scavenger hunt inside Web-CAT’s two (currently buildable) components Core and Grader to see what we can do. So far we added a semi-working raw filebrowser on submission results page, and semi-fixed few UI annoyances in code viewer.

It would seem that things are picking up pace finally…

June 10, 2008 at 1:02 am Leave a comment

SVN, My best friend

(Swing, Moderate)

Sometimes I’m happy, sometimes I’m blue,

My disposition is depended on you.

 

I never mind regressions from the nightlies,

As long as I have, a version in your eyes.

 

Sometimes I love you, sometimes I hate you,

But when I hate you, it’s because I love you

That’s how I am, so what can I do?

I’m happy when I’m connected to you

 

SVN, My best friend,

You’re the reason I commit so often,

That’s how I work, so what can I do?

I’m happy when I’m connected to you.

 

(I’m not happy with the phrasing right now…any suggestions?)

June 4, 2008 at 5:52 am 1 comment

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…

(more…)

May 30, 2008 at 2:19 am 4 comments

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.

May 29, 2008 at 11:07 pm 1 comment

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?

May 27, 2008 at 8:15 pm Leave a comment

Older Posts Newer Posts


Time Machine

September 2017
M T W T F S S
« Aug    
 123
45678910
11121314151617
18192021222324
252627282930  

RSS Qi’s Utterances

  • An error has occurred; the feed is probably down. Try again later.