Hello,
last weekend I started another try to implement the
InterpCmd class. It is still far from ready (right now
the Tcl8.3 interp.test runs quiet only until test 17.4).
But since I don't trust my hard disks any longer,
I will make the diffs public as soon as possible :-)
So here are some
Hello,
I am thinking that it might be good to change the name of
the Tcl package for Tcl/Java related things to tcljava
instead of java.
I like the package name "java".
IMHO the interfaces to other systems don't need to contain the
string Tcl, since as a Tcl-script writer I know that I'm
On Mon, 17 Jul 2000, Christian Krone wrote:
Hello,
I am thinking that it might be good to change the name of
the Tcl package for Tcl/Java related things to tcljava
instead of java.
I like the package name "java".
IMHO the interfaces to other systems don't need to contain the
string
Hi,
It now appears the bug is a problem in the JNI implementation -- see the
beginning of the stacktrace below:
(gdb) where
#0 0xfe29945c in __0fCosTget_native_priorityP6GThreadPiT () from
/usr/j2sdk1_3_0beta/jre/lib/sparc/server/libjvm.so
#1 0xfe294b94 in
so, I just had another idea:
I don't really need (or even want) more than 1 JVM for all the tcl threads.
On the Java side I have threads that allow concurrency among incoming
requests, so the structure I really want is:
- master tcl thread does 'package require java', which creates an
