Porting of Gython

[taynaud]

Hello,

First release of the plugin!

Documentation and examples: http://wiki.gephi.org/index.php/Script_plugin

nbm: http://perso.crans.org/aynaud/software/ ... onsole.nbm
sources: http://perso.crans.org/aynaud/software/sources.zip

These are temporary. I use this because the gephi website does not
like my plugin


I will not work a lot on this more, but I would be pleased to answer questions and provide help.


To continue the discussion, my main concern with modifying jython is that it is a lot of code to maintain, and I am not sure that Gephi devs can/want handle this. Gsoc is nice, but temporary and student would be the only one to know the jython code and its modification?

[admin]

Great job!

Sure modifying Jython is something that would be nice to avoid.

[luizribeiro]

This is awesome, taynaud! Thank you very much for this amazing contribution. I'm not sure if the plugin that would be developed during GSoC would be based on yours, but I'm sure this is going to be very helpful during this summer, in case this proposal is accepted.

I believe the API could have some improvements, to make it easier to use by non-programmers. I'm focusing my proposal on this: creating an easier and more intuitive API (probably something like I've described on my previous posts), writing an extensive documentation of the API and probably giving MuTanT support, so that we can use any JSR 223 compliant language on the console.

I also agree with you on the fact that maintaining Jython's source code on Gephi's source tree would demand a lot of [probably unwanted] work. That's why I'm mentioning Gython as a "nice to have" feature, not a required deliverable.

By the way, is anyone interested in reading my proposal before I submit it to GSoC? I see that previous participating students have sent a pdf version of the proposal to other people, and I also would like to do that if possible. (I expect to have my proposal finished by sunday).

[admin]

Hi,

Sure you can sent the first draft to gsoc@gephi.org! Note that it doesn't require to be complete, because we'll have until April 22 to review and refine them with students (check the GSoC timeline).

I confirm that the Gython is one of our priority, because it is something that want a large part of researchers.

[eduramiba]

This is great! Thank you

[mbastian]

This is amazing work! It is greatly boosting the scripting project. I'm curious how this work, could you give a bit of details how this is implemented? Thanks a lot

[luizribeiro]

The plugin written by taynaud seems to use the Java Scripting APIs (there is a nice article about these APIs here). The current workspace's GraphModel object is exposed to the scripting language, which has a library of global functions that make it easier to work with the model (since working with GraphModel itself would be a pain in a scripting language). (I hope I didn't say anything wrong here, these are just my impressions after some minutes analyzing the source code)

It seems to be basically the same approach I'm suggesting in my proposal. By the way, the first draft of my proposal is publicly available on melange and I've also sent a pdf version to the gsoc@gephi.org email. Any feedback will be more than welcome.

Edit: the pdf version of the first draft is also publicly available here.

[taynaud]

It is as Luizibeiro said. The plugin uses java scripting api and jython to execute the script. It builds one object of type ScriptExporter and push it into the script with the name gephi. This object gives access to Lookup and models API of gephi to the script, and thus the script can do almost everything. There is also a small preload.py python file that is executed before any script and that export the "simple api". It was faster to develop it inside the scripting environnement instead of reloading gephi again and again.

The java scripting api is excellent and very easy to use. See http://java.sun.com/developer/technical ... scripting/ if you want detail. It is in its own thread to avoid blocking the UI and to allow script stoping.

Changing the language should be easy but will requires a rewritting of the API (if mutant is not used). Basically, it is changing the 5 variables that contains reference to python.

[luizribeiro]

Changing the language should be easy but will requires a rewritting of the API (if mutant is not used). Basically, it is changing the 5 variables that contains reference to python.

MuTanT works by sharing the ScriptContext object between the ScriptEngines, so it wouldn't be too hard to implement MuTanT-like functionality in our scripting plug-in. Although, I've tried to share the ScriptContext object between Jython and Groovy and didn't have any success, there seems to be some problems with Jython's implementation of JSR 223 (functions created within Jython can't be seen under Groovy's scripting engine), I believe this is why MuTanT doesn't support Jython. Sharing functions and variables between JRuby and Groovy works fine, though.

[eytanadar]

@taynaud @luizribeiro: I think the script API looks great, but I'd still like to push a little more for a DSL. I do agree that it would be nice to have a consistent set of APIs that would work in plain vanila Jython or JRuby or Groovy or whatever script language you'd choose. However, I do think that by over-relying on off-the-shelf components we're limiting innovation and usefulness to users. For example, I don't think MuTanT could support things like the mouse-brushing that is available in GUESS or that raw Jython will ever have as simple of a syntax to perform simple operations like finding all directed edges between two groups.

I realize that it may require a branch from the jython core and thus may require more maintenance, but I think the benefits (_much_ easier to interact with graph structures in Gephi) outweigh the costs (keeping up with the latest jython improvements). My experience with GUESS is that it's been extremely rare that there has been some demand for having access to the latest Jython features... users were happy with a good strong core of features WITH the ease of access to the graph. Jython is relatively stable so bugs are infrequent, and once built, the Jython branch has worked effectively for years (though I do think that a design that makes clever use of patching might ensure an easier upgrade path in the future).

Ok, that's my continued pitch for a summer-of-code project that does the basic scripting API which I think is relatively easy (i.e., plugging in standard Jython) _and_ doing Gython...