Friday, December 18, 2009

Developers workshop/code camp 18 January 2010 DLS

Sorry for the short notice but we would like to announce a plugin developers meeting for EDNA on the 18-20th of January at Diamond.

The schedule of the workshop will be more of an introductory level for new developers on the Monday then more of a code camp style where tasks for kernel developments and specific plugin developments (e.g. MXv1 and V2) will be undertaken in breakout groups for the remainder of the time.

We anticipate that the workshop will be very popular so expression of interest/commitment to attend early is recommended! We will try and organise accommodation at http://www.stfc.ac.uk/About/Conts/Find/Coseners/Introduction.aspx though all travel and accommodation expenses will be the responsibility of the attendee and their home institution.

Early expressions of interest would be very much appreciated! I hope you haven't all gone away for Christmas already, if you have, I hope your having a good time!

Alun

Tuesday, December 1, 2009

EDNA in Java

The idea of being able to call EDNA from within java has been discussed many times, and Olof has recently produced an eclipse plug-in which can make these calls. However the way this is done is by using the command line based launchers for EDNA, and hence there is some overhead involved.

The work that I have been doing extends this idea to using java embedded python (jepp) to make the calls to the EDNA plugins directly. This allows for the plugins to be called independently without the general overhead of the framework, and also removes the need to start up a separate shell for each plug-in.

Jep has some issues with being able to pass information between java and python, however as EDNA relies on XML to pass information between different plugins, Jep can be used quite effectively.

Initial work on this topic has now been completed, and this is now working well in a test environment. The next step is to create a full API which allows the Execution of various plugins easily in the Java environment.

However there were a few points which are worth pointing out, as they took a long time to fully get working.

1. Environment variables, It is important to set both the environment variables stated, if only the LD_LIBRARY_PATH is set, most things work completely fine however there are very obscure errors with imports which take a while to track down, a small typo in the LD_PRELOAD path can cause a lot of trouble. So, if there are any issues with import statements such as "import random" this is where to check first.

2. The biggest problem is with imports, if a problem occurs in an import, then jepp will always report the error as being that the first import that was called from the jepp environment cannot be found, even if the import that failed was way down a long list of dependencies, and the error was actually something completely different. Unfortunately there seems to be no way of retrieving the actual exception, either through Python or java, so you’re down to lots of print statements to find where the problem is.

3. The last issue which caused a lot of problems, especially as it was used in a class definition of one particular import, so the error was swallowed, is that as jepp is running on the embedded platform there is no sys.argv. This means that PySys.argv also doesn't exist. This however can be worked round by as one of the first things we do in Jep is to set sys.argv to basically a sensible set of values. This just needs to be a list of strings.

Basically that's then it. It’s then quite easy to call the plugins to be run, and give it an xml string input. And the main thing is that no changes are required in the EDNA code itself. This should be easily combined with the work that Olof has done to make it very easy to use the plugins. Plus the speed of execution is very high in comparison to launching the process externally. More updates to follow, when the full API is finished, and properly integrated into the Eclipse EDNA plugin.