Re: Embedding a REPL in a Java application

[Jamison Hope <jrh at theptrgroup dot com>]

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.

-Jamie

*Actually, I made copies in a separate package for ReplDocument and  
ReplPane, as well as GuiInPort and ReplPaneOutPort (which reference  
ReplPane and ReplDocument by name). I didn't want to get side-tracked  
by other issues trying to compile all of Kawa. I changed the class  
names slightly to make sure that I was using them and not the originals.

--
Jamison Hope
The PTR Group
www.theptrgroup.com