Patrick Wright wrote:
> Per--sounds like Kawa's got some good code to build on top of. One
> question would be how to structure the console (whether GUI or CLI) in
> such a way that language implementors would not feel constrained, but
> rather welcome and interested in plugging in their own language (e.g.
> adaptor to a language's interpreter, context introspection, etc.).
The Kawa GUIConsole might well be of interest to other REPL-like
applications. The basic hook to the REPL is in this part of the code:
public class ReplDocument extends DefaultStyledDocument
implements DocumentListener, FocusListener
{
...
private ReplDocument (...)
{
...
// REPL's standard output and error PrintWriter objects.
// Note that "/dev/stdout" and "/dev/stderr" are just arbitrary
// names, for use by toString. There is no Unix dependency.
out_stream = new ReplPaneOutPort(this, "/dev/stdout", defaultStyle);
err_stream = new ReplPaneOutPort(this, "/dev/stderr", redStyle);
in_r = new gnu.text.QueueReader() {
public void checkAvailable() {
checkingPendingInput(); };
};
// REPL's standard input Reader.
in_p = new GuiInPort(in_r, Path.valueOf("/dev/stdin"),
out_stream, this);
// Create REPL thread, passing in out_stream, err_stream,
// and in_p.
thread = new Future (new kawa.repl() {
public Object apply0 ()
{
Shell.run(...);
// When REPL finishes, close windows.
SwingUtilities.invokeLater(new Runnable() {
public void run() {
ReplDocument.this.fireDocumentClosed(); }
});
return Values.empty;
}, in_p, out_stream, err_stream);
...
thread.start();
}
...
}
The main Kawa dependency is the Future call. That could be
moved to some kind of ReplThreadFactory. For experimentation
you can just hack the code as needed.
Another big dependency is that the REPL needs to set the
standard input, output and error to ones passed by the
ReplThreadFactory. It should probably set these to a
ThreadLocal.
GUIConsole does depend on the Kawa IO classes, which have
some other dependencies. Except for bloat this should be
harmless, as long as the REPL uses generic Readers and PrintWriters.
Later, if the experiment is successful, we can consider
how to refactor the code to reduce Kawa dependencies.
The Kawa readline-wrapper is probably not as interesting,
since most of what it does can be accomplished by a shell script
that calls rlwrap.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
