[armedbear-devel] Re-organizing swing/awt included with ABCL

[Alessio Stalla]

On Wed, May 19, 2010 at 2:45 PM, Mark Evenson <evenson at panix.com> wrote:
> On 5/19/10 9:42 AM, Alessio Stalla wrote:
>
> […]
>
>>> 4.  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