On Mon, 7 Aug 2000, Christian Krone wrote:
> Hello,
>
> yesterday I finally finished the implementation of
> Jacl' interp command. The new classes to add and the
> patches to apply to the CVS sources of Jacl (as checked
> out yesterday) can be found here:
> http://ME.IN-Berlin.de/~v12/krischan/Interp
>
> Some notes to former mails of Mo to this topic:
>
> > The only thing I saw that seemed to be wrong was the refCount
> > test when closing the channel. I think the channel
> > should get closed when the refCount goes from 1 to 0.
> > You patch would only close the channel when the
> > count moved from 0 to -1, which seems wrong to me.
>
> Yes indeed, it should be: refCount <= 0
> I tried to create a test for this, but I couldn't imagine
> how to check. After calling the "close", the handle (file3)
> isn't valid anymore, so I cannot test, if the channel
> behind the handle is really closed...
I checked it in with the refCount <= 0 test.
> > In Catch.java, your patched version looks like:
> [...]
> > interp.returnCode = TCL.OK;
> [...]
> > Did you try just calling interp.resetResult() ?
> > Why not do that instead of interp.returnCode = TCL.OK ?
>
> I didn't try it. But I couldn't find an assignment to returnCode
> inside the source of resetResult(), when I read it. So I decide
> to better reset it myself....
I changed the implementation of Interp.resetResult() in Jacl
so that it set interp.returnCode = TCL.OK. The version of
CatchCmd.java that I checked in just calls Interp.resetResult().
Also, I did not check in the part that incr and then decrs
the interp nest level, I did not see the point of that and
it did not cause any tests to fail.
> > When I ran the test suite again, I noticed the following error.
> > ==== EventAdaptor-11.1 EventAdaptor._return_Object
> [...]
> > I am not sure if this was caused by your inter changes.
> > Could you double check to make sure nothing you did caused this?
>
> It was indeed an error in my patch of the Interp.eval() function.
> But as the Jacl test suite generates a lot of errors for the
> unmodified sources anyway, I did not recognise the new ones.
> Now I'm always making a diff of the two outputs of "make test"
> before and after my modifications...
Once all the tests are upgraded to Tcl 8.4, this problem should
go away. The Jacl suite has been a bad mix of 7.6 and 8.0 tests
for far too long.
> There is only one point remaining: The memory usage of an object
> of the Interp class is huge. So I need to increase the heap size
> for Jacl in the Makefile. Maybe we should try to make different
> Interps share some parts. But luckily it looks like the storage
> is freed when deleting an interp, since I can run the interp.test
> in a loop without increasing memory consumption (this wasn't the
> fact in my first implementation!).
One would think that the Java GC system would be a bit smarter
about this. Perhaps there is ref to a slave Interp that would
need to get set to null before it could be GCed.
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
