This time, my proposal focuses on Gython. I believe now I have a good understanding of the inner workings of Gython and I tried to expose my point of view of it on the proposal.
I propose to work on porting and implementing Gython's essential features like queries and the console user interface until mid-term evaluations deadline (for now, without the "mouse brushing" feature).
The remaining 5 weeks of the program are going to be used for implementing other Gython's features and documenting the scripting plug-in (I still don't know exactly which features are going to be implemented, I'd like some suggestions regarding this). Which features are considered of high priority?
If anyone's interested, I would like to work on a script editor for Gython in case there's enough time on the remaining of the program's timeline. The script editor would allow users to write and test algorithms on Gephi's graph structures.
Edit: I believe a lot more work can be done before mid-terms. Although, I still don't know which other features are considered as high priority for this project. Maybe working on dynamic graphs support with the rexact, rcontains, etc operators?
Statistics:Posted by luizribeiro — 12 Apr 2011 00:37
]]>
]]>
Although, I don't have enough time to rewrite my proposal so that it focuses on Gython before the submission deadline on Melange (which is due tomorrow).
I've heard from SRabbelier on the #gsoc IRC channel that mentors and organizations can allow proposal editing on Melange after the submission deadline. In case this really happens, is editing my proposal a possibility?
Should I submit another proposal or edit the one I've already submitted?
Statistics:Posted by luizribeiro — 07 Apr 2011 21:47
]]>
Read the 'GUESS' chi'06 paper, Is the implementation of Gython seems closely related to dynamic typing and console in Jython. The current implementation in GUESS requires a copy of Jython included and tested, and we may as well use that copy for the first deliverable for port. The Jython may be included to Gephi as a plugin to make it easier to maintain and upgrade.
I am also interested in how Gython is developed as a DSL in the future. Such as porting it to other platform (eg. processing) and implementation with other jvm based language (eg. Clojure)
Statistics:Posted by binarycrayon — 07 Apr 2011 20:16
]]>
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...
Statistics:Posted by eytanadar — 06 Apr 2011 16:18
]]>
taynaud wrote: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.Statistics:Posted by luizribeiro — 06 Apr 2011 15:00
]]>
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.
Statistics:Posted by taynaud — 06 Apr 2011 14:37
]]>
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.
Statistics:Posted by luizribeiro — 04 Apr 2011 05:28
]]>
]]>
Statistics:Posted by eduramiba — 01 Apr 2011 21:03
]]>
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.
Statistics:Posted by admin — 01 Apr 2011 10:54
]]>
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).
Statistics:Posted by luizribeiro — 01 Apr 2011 02:47
]]>
Sure modifying Jython is something that would be nice to avoid.
Statistics:Posted by admin — 31 Mar 2011 19:04
]]>
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?
Statistics:Posted by taynaud — 31 Mar 2011 10:55
]]>
]]>
As a side-note, about the alternative for the third item you wrote (the hack for iterating over the set of edges/vertices, setting the specified attribute), I see a way to do this: you can create a container class in Python (something like EdgesCollection) and just overload the __getattr__, __setattr__ and __delattr__ methods, so that they iterate over all elements in the set, setting the corresponding attribute (or getting a set of unique values for the attribute, in the case of __getattr__). This way, the queries would return an EdgesCollection object. Although, this is almost the same solution as yours, but it needs no modifications to Jython's core (which is good, in my opinion).
Sadly, after reading your post I see that upgrading Gython is even harder than I thought. I don't believe there's enough time for this during GSoC's three months timeline. However, porting the current source code of Gython to Gephi is completely viable.
Is there a real need for having backwards Gython-syntax portability? I mean, this might be a silly idea, but I'm pretty sure we could come up with a somewhat similar API that doesn't need modifications to Jython's core (and the whole documentation for it, of course) during a summer. In my mind, this API could do things like "(dept == 'HR').color = blue" in a way like this: "getVertices(dept = 'HR').color = blue". We could use the "hack" I mentioned above to achieve this (that's how I came up with this idea).
The upside of this is that we could have Jython 2.5.2 compatibility during the summer, which means ScriptEngines support.
I completely understand if you're not interested in modifying the API or having a different syntax from Gython's, since GUESS already has a established user-base that probably isn't interested in learning new commands. And please, don't get me wrong: I have no problems on porting Gython's current source code to Gephi, I'm just brainstorming here.
Statistics:Posted by luizribeiro — 28 Mar 2011 03:01
]]>
I guess I should have specified: I see no _theoretical_ reason why Gython could be integrated with MuTanT...
In answer to how Gython/GUESS are implemented:
1) As far as I know, there is no way to "extend" Jython by writing a module or something like that. Gython extends Jython by modifying the core language/implementation. So while it is backward compatible, it is still a branch from the Jython tree (which is why it is included with GUESS and also why it hasn't been upgraded to a newer version of Jython). Now, there might be a way to do this through patching so that it is also forward compatible with new releases, but I'm not sure how stable this is. I also don't know of any modern language that supports this style of extension (Lisp/ML probably don't count
), but if there is, I'd be happy to consider extending _those_ languages instead.2) Operators are added to Jython by modifying the JavaCC spec files. There aren't that many new operators but we do have a few that are useful (e.g. -> <-> <- 'like' and some range operators)
3) Jython "set" objects (e.g., PySequence) were also modified to support things like (dept == 'HR').color = red by iterating over all the objects in the set and "setting" things or "getting" (as appropriate). This part always felt like a hack to me, but it worked. (happy to consider alternatives)
4) The query functionality is implemented through the Field and Query objects and operator overloading. So "dept" is actually an instance of a Field object and when you do dept == 'HR', the == operator invokes .isEqual which is overloaded. So dept == 'HR' is actually dept.isEqual('HR'). Similarly, freq > 50 would be freq.gt(50) (or something similar). The trick is instead of returning a boolean we return a ComparisonQuery object which is basically a set. Query objects are also overloaded so that Query1 & Query2 returns a CompoundQuery. When you go to access whatever is in the Query object it will _then_ execute the query as appropriate. In the case of GUESS this means walking through the Query tree and transforming things into a text string suitable for SQL and then running it through the DBServer. In the case of Gephi, this might mean transforming the Query into the appropriate compound blueprint calls.
5) When running GUESS, the system pushes a bunch of variables into the interpreter namespace to make sure various objects are available. So all columns in the database get their own Field objects, nodes get added in, etc. Same thing happens when you create new objects. The interpreter was also extended a little bit (includes a setImmutable method) to support variables that can't be overwritten (we didn't want users overwriting the "g" object by mistake).
6) The console supports the mouseover stuff by keeping an interval tree that keeps track of where certain things were output (to the console). This is a little bit of a hack, but works mostly ok. I'd be happy to consider alternatives, but this was done based on the particular console implementation I used.
7) There's some other junk added to the Jython core that makes it so that GUESS can run in the browser as an applet with the interpreter (safely). This wasn't supported by Jython (and may still not be). This part isn't crucial. It's nice to be able to run things on the Web, but I don't know how often GUESS actually gets used in this mode (people have a hard time compiling or getting certificates or whatever).
Anyway, I can get into more specific details about where to look for/at things but maybe this is enough to get you thinking about it.
Statistics:Posted by eytanadar — 26 Mar 2011 14:57
]]>
taynaud wrote:Writting a console using one JSR 223 language is done(I use now jython), and after that changing the language is trivial. In my code, that I plan to release in a few days, changing the language is actually changing three variables in the java code.
This is good news! I've been also already experimenting on creating a prototype of a console UI for Gephi using Jython, to see how hard it would be to integrate Gython into it. I'm really looking forward to your release, I'm sure it will be very helpful.Actually, the problem isn't porting to MuTanT. The main problem with using ScriptEngines is that Gython seems to be currently using Jython 2.1.0, which lacks ScriptEngine support. If we're going to use a generic ScriptEngine, we first need to upgrade Gython to the latest Jython stable release.taynaud wrote:It seems to implement the jsr 223, so porting to mutant is very easy. But changing the exported api to script is more difficult and I think the student should focus on this. Another issue is that mutant documentation seems very limited.
I haven't experienced any problems with Jython 2.5 actually. When I say that Jython's JSR 223 support sems to have problems, I'm referring to this commit on MuTanT's git repository. The authors opted to disable Jython support because of it's "poor implementation of ScriptEngine" (although I have no idea on what kind of problems they've been experiencing).taynaud wrote:I have not experienced difficulty with jython so far, do you have precise example ?
Statistics:Posted by luizribeiro — 25 Mar 2011 23:50
]]>
Sorry to appear like that in the thread, I do not read gephi forum very regularly. I am currently writing a similar python plugin on my spare time and the main difficulty is clearly not the language of the console but the api.
Writting a console using one JSR 223 language is done(I use now jython), and after that changing the language is trivial. In my code, that I plan to release in a few days, changing the language is actually changing three variables in the java code.
The gephi api to transform the graph, apply layout and other stuff is a pain for a non java programmer. Model view controller is great for the full application, but in a script environnement it is just awfull. Every action requires at least three lines of complicated code, and netbeans is not behind
. Thus, I advise to focus first on one language, with one nice api, and gython api is excellent. Mutant can come after. I have looked to mutant that I did not knew. It seems to implement the jsr 223, so porting to mutant is very easy. But changing the exported api to script is more difficult and I think the student should focus on this. Another issue is that mutant documentation seems very limited.I have not experienced difficulty with jython so far, do you have precise example ?
Statistics:Posted by taynaud — 25 Mar 2011 18:46
]]>
After having a closer look at GUESS and the Blueprints API over the last couple of days, I have came up with some new observations that I'll try to expose on this post while commenting what you have said.
If we're really going to implement a MuTanT console + Gython, the student working on this would have to (aside from other more obvious tasks like working on the console's UI, etc):eytanadar wrote:I don't see any reason why Gython couldn't work under MuTanT.
- Create an implementation for Gephi on Blueprints;
- Upgrade Gython so that it's compatible with the latest Jython stable version (2.5.2), since it's the only version that seems to have decent JSR 223 support. Although, I'm not sure if MuTanT devs are going to re-enable Jython support anytime soon (they've removed it because they were experiencing crashes);
- Refactor Gython's source code so that it uses the Blueprints API to access the graph structure, not via the com.hp.hpl.guess.Graph object.
The second and third items are the ones that seem to demand much more work IMHO. After looking at GUESS' source code from the latest CVS revision, I still have no idea where to start the second item. It seems Jython 2.1.0 is unpacked inside GUESS' source tree, right? Also, I see that the Guess class exports the display, graph and other objects to the PythonInterpreter. But I still don't get how the queries like (dept == 'HR') are implemented. Could you give me some guidance with respect to this? I'm not yet familiar with how Jython extensions work at all and I'm trying to get to know GUESS' source code better, so that I'm familiar enough with it to know which classes and interfaces have to be exported to Gephi.
Also, I'm not sure if there's enough time during GSoC to work on all these mentioned tasks.
After using GUESS, I have to agree with you. Probably most users would prefer if the console language was less "programming-oriented". Also, since Gython is just a Jython extension, we still have all the power of Jython on the console, which is more than enough in my opinion.mbastian wrote:My experience with GUESS has been that people prefer a concise language for working with the graph structures.
With this in mind, I'm not sure if the genericity to other languages via MuTanT justifies the amount of work of upgrading and refactoring Gython's source code (and the risk of not being able to finish it during the project's timeline). I'll be submitting the first version of my GSoC proposal next week and I'm still unsure if we should give MuTanT a shot or not. What do you think?
Statistics:Posted by luizribeiro — 25 Mar 2011 17:20
]]>