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...
> 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....
> 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...
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!).
Greetings, Krischan
--
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:[EMAIL PROTECTED]
----------------------------------------------------------------
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
