This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Embedding a REPL in a Java application
On 11/16/2009 12:59 PM, Jamison Hope wrote:
On Nov 16, 2009, at 3:42 AM, Per Bothner wrote:
On 11/16/2009 12:28 AM, Per Bothner wrote:
On 11/15/2009 01:43 PM, Jamison Hope wrote:
I tried that, actually. It led to a stream of
ArrayIndexOutOfBoundsExceptions like this:
Exception in thread "AWT-EventQueue-0"
java.lang.ArrayIndexOutOfBoundsException: 24387
at gnu.lists.StableVector.allocPositionIndex(StableVector.java:111)
at gnu.lists.StableVector.createPos(StableVector.java:123)
at gnu.lists.SeqPosition.<init>(SeqPosition.java:55)
at gnu.kawa.swingviews.GapPosition.<init>(SwingContent.java:116)
at
gnu.kawa.swingviews.SwingContent.createPosition(SwingContent.java:104)
These appear to be thread contention between the AWT thread and the
finalizer thread. Adding "synchronized" before every method in
StableVector "fixes" the problem.
A better solution would be avoid thread contention in the first place.
That would seem to require changing gnu.lists.SeqPosition to use
weak references rather than finalizers. I haven't looked into
what would be involved.
It may be best to replace the use of SwingContent by
standard GapContent. Not a completely trivial fix, but
doesn't look too difficult. Could you try that? The
non-trivial part is changing checkingPendingInput to use
GapContent.getChars and a Segment.
I've changed* ReplDocument so that content is an instance of
javax.swing.text.GapContent instead of gnu.kawa.swingviews.SwingContent.
Then I edited ReplDocument.checkingPendingInput() and ReplPane.enter()
so that
gnu.lists.CharBuffer b = content.buffer;
became
String b = content.getString(0, content.length());
but still no go. With shared=true in the first ReplDocument created, the
ReplPane remains unresponsive until I get an OutOfMemoryError on the
EDT; with shared=false, then it works fine. So SwingContent isn't the
issue, or at least it isn't the entire issue.
Not sure what's going on. What happens with a shared repl is that
it creates a (thread-specific) environment, and then sets that to
share (indirect to) the parent environment. I suspect the problem is
that the "parent environment" in our case ends up being something
unsuitable (for a reason I'm not clear on).
Perhaps creating a fresh environment before you start, and then
passing that for each shared REPL would work. Right now I'm a
bit swamped with my day job, but I'll try to look at it when
I get a chance.
--
--Per Bothner
per@bothner.com http://per.bothner.com/