On Wed, May 19, 2010 at 2:45 PM, Mark Evenson evenson@panix.com wrote:
On 5/19/10 9:42 AM, Alessio Stalla wrote:
[…]
- I think it would be useful to move the JPanel code into base ABCL for
a basic interactive REPL. This would facilitate embedding ABCL in many tools where the core functionality is maintained in central location. This would allow Netbeans, for example, to easily include a GUI to the ABCL REPL. I would not favor this being a full IDE effort at all, but would provide the base GUI element that others could customize. At the same time, maybe we should consider removing unused parts of the org.armedbear.lisp.java.{awt,swing}.* classes? Is this something used by J that could profitably moved over?
What is the JPanel code? As part of my "Snow" GUI library, I have a basic REPL, debugger and inspector available. The REPL is pure Java and does not depend on anything but Swing/AWT, so it could be included in ABCL as-is. There's room for improvement, but it's already usable as it is if you don't expect fancy things from it. The Lisp interface to the REPL, the debugger and the inspector instead are written in Lisp and depend on the Snow DSL. I know Alan successfully ran the Snow REPL with Protege (after some bugfixing).
The org.sciencecommons.protege.lisp plugin uses snow.swing.ConsoleDocument, so I would propose we move a version of this to org.armedbear.lisp.java.swing.Console more or less as-is. Any thoughts on how you want to maintain the dependence between this and the rest of Snow?
If the REPL is part of ABCL, Snow will just use it :) i.e. all I need to change is a package name. However, there's a little catch. Currently the REPL in ABCL is not supposed to run multiple times concurrently, because it relies on some global state. The visible part of it is the incrementing counter shown at the prompt, but I can't exclude that there's some more important state which should not be shared. In Snow I solved this running exclusively either the console REPL or the GUI one, but in ABCL probably it would make more sense to bind all the REPL state in a thread-local manner, if possible, to allow multiple REPLs to run happily together. That, and we will need a way to tell Main which REPL to launch.
For the rest of the classes under org.armedbear.lisp.java I would propose perhaps moving them to the examples hierarchy? It does not seem that J depends on them. Neither does Snow from what I could grep. Does anybody know of any consumers of these interfaces? And does it seem like a good idea to move them to the examples hierarchy? If we agree to such a move, I would agree to produce some amount of documentation for the use in examples.
org.armedbear.lisp.java.DialogPromptStream and its two subclasses, one in .awt and one in .swing, are stuff from Snow too. I didn't remember them to be ported to ABCL, and I doubt anyone is using them. The other classes seem to be related to J. I second your proposal of moving everything to the examples.
Regards, Alessio