[Tcl Java] This tcljava mailing list is shutting down!
Just an FYI here. The tcljava project has moved to sourceforge. There are now two mailing lists, one for users and one for developers. Sign up here: http://sourceforge.net/mail/?group_id=13005 You will have to sign up yourself, I am not going to sign folks automatically. The developers list will host more in depth discussions while the user list will be focused on user questions. The user list should be very low bandwidth. cheers 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
[Tcl Java] Re: possible memory.
On Thu, 26 Oct 2000, Daniel Wickstrom wrote: "Mo" == Mo DeJong [EMAIL PROTECTED] writes: Mo Are you up to it? I am going to be working on this object ref Mo queue thing for some time, so if you could take a whack at the Mo Notifier it would really help. There is not going to be much Mo overlap in these changes, so they can be done in parallel. Ok here is a patch to make the notifier thread safe. I've run the test cases on a solaris box, and it still fails with the same test cases that I posted earlier before I made the modifications. Let me know what you think. This patch looks great. I touched up a couple of little things and checked it in (see the ChangeLog for the gory details). I ran the tests again, and it looks like everything is working just great. I can also run some multi-threaded tests that did not work in the past. Are there any remaining issues we need to look at before merging this branch back into the HEAD? We can't fix the ref count problem right now, we need to get this all merged back into the HEAD and then we can look at overhauling ref counting, perhaps on another branch. 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
[Tcl Java] Re: autoconf 2.14
On Thu, 26 Oct 2000, Thomas McKay wrote: Can someone send me a pointer to where I can download autoconf 2.14. You would need to grab the autotools out of the CVS (Dont do this yet!). setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvs cvs login paswsd "" cvs checkout autoconf cvs checkout libtool setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvs/automake cvs login paswsd "anoncvs" cvs checkout automake I just checked out tcljava from sourceforge and would like to make it. There aren't any instructions on doing this so I am assuming that I: 1) autoconf configure.in 2) configure 3) make You don't need to. There is already a tcljava/configure file for just that reason (so you don't need to download autoconf). If you change the Tcl/Java configure.in file or other m4 files, you would need to rerun things. If you wanted to do that, you would run the ./autogen.sh script. 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
[Tcl Java] Re: compiling tcljava
On Thu, 26 Oct 2000, Thomas McKay wrote: Hack... hack... hack... I plow on... Okay, I never could get configure to successfully run Test.java. Finally got it to compile after much hacking, but never run. So I took out the whole java test section of configure and finally got a Makefile. Well, there should have been an error logged to config.log that would have shown why Test.java could not be compiled. Several problems with the Makefile, though: 1) The classpath is being built with ':'s not ';'s. I'm on NT so this is a no-no. I assume that this is something I've set up wrong where? 2) There are places in the Makefile where paths are specified as "//e/App..." instead of "e:/App..." which causes failures. I'm using the cygnus tools. 3) The line in the Makefile @echo "# Making tcljava.build" gives me an error about an unterminated quoted string. Not sure why. Am I just being clueless here? No, the autoconf based build has never been tested on NT. I know it works on Unix systems, but I have not gotten around to porting it to Window + Cygwin. There is an updated makefile.vc (the VC++ based build) that works for Tcl Blend 1.3 on the contract branch. It might be easier to get that working on NT. That said, it appears that I have built jacl.jar and tcljava.jar successfully. Cool. Yes, Jacl would be a lot easier to get working with the Cygwin based build. Tcl Blend is going to be a bit more work. There was a Cygwin tested build process for Tcl Blend in the 1.2 release, but it did not support Jacl and suffered a bit of code rot when compared to 1.3, so I had to kill it. I need to revive that sucker, but perhaps someone else who has done some autotools hacking would like to beat me to it :) 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
[Tcl Java] Re: ajuba branch
On Thu, 26 Oct 2000, Daniel Wickstrom wrote:
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo What version of Tcl are you using? This should not show up
Mo with Tcl 8.3.2 or 8.4. At any rate, it does not matter.
I'm using tcl version 8.3.2.
Strange, perhaps I was wrong and that only works for 8.4. Oh well.
tclblend/javaTimer.test
javaTimer-3.1 JavaTimerProc Contents of test case:
set t [java::new tests.TimerHandlerTest $notifier 100] set
result [java::field $t value] java::field $t err true lappend
result [catch {$notifier doOneEvent 0} msg] $msg [java::field
$t value]
Result was: 0 0 1 0 Result should have been: 0 1
{java.lang.NullPointerException: TimerHandlerTest} 1
javaTimer-3.1 FAILED
Mo Humm, I have not seen this error before either. Could this
Mo have something to do with your Notifier changes?
No these tests were run before I made the notifier changes. This is a
fresh checkout from cvs. Since making the notifier changes, I get the
same errors, so the notifier modifications didn't change anything with
regard to the test results.
It could be related to the event queue, I just don't see it on my box.
A printed stack trace would really help:
replace:
catch {$notifier doOneEvent 0} msg
with:
java::try {$notifier doOneEvent 0} catch {Exception e} {$e printStackTrace}
Mo If not, could you investigate it a bit more? Perhaps get a
Mo stack trace and print it to see where things are going wrong.
I'll see what I can do. I want to write some tests that will exercise
the enw notifer anyway.
Me thinks tcljava/tests/tcljava/JavaNotifier.test is in need of
writing. This could slurp up the Jacl specific and Tcl Blend
specific tests that are floating around too.
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
[Tcl Java] Re: ajuba branch
On Wed, 25 Oct 2000, Daniel Wickstrom wrote: "Mo" == Mo DeJong [EMAIL PROTECTED] writes: I'm running with the following: redhat 6.2 tcl8.3.2 tcljava from souceforge ajuba contract branch blackdown jdk1.1.8_v1 Mo That really should work, everything you are using is the same Mo as my install except I have the CVS version of Tcl. Are you sure that the sourceforge archive is up to date? I tried the same test with the following setup: solaris 2.7 sun jdk1.1.8 tcljava from ajuba branch This time I received an error because the all the files couldn't be found. It seems that there is quite a bit missing from the tests sub-directory. I just got a fresh CVS checkout from SF and ran the tests with IBM JDK 1.3 (on Linux) and it worked just fine. I don't know what to tell ya. You are using the branch tag: ajuba-tclblend-contract-2000-08-01-branch right? 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
[Tcl Java] Re: possible memory.
On Tue, 24 Oct 2000, Jiang Wu wrote: That may be true for your specific case. Though, it is not true in general. One could also potentially delete the interpreter without removing the thread. For example, one may be using a pool of Java threads to do some work. One thread is retrieved, creates a Tcl interp, do some work, delete the interp, goes back into the thread pool. The thread itself is never deleted, only the resources used by the thread. TclBlend allows a Tcl program to use Java. It also needs to work the other direction, which is allowing a Java program to use Tcl. -- Jiang Wu [EMAIL PROTECTED] Yeah, that is a nasty one. We really need to create a good document that details all of these create/destroy cases. In this case, the thread would hold the same notifier but the interp it was create in would be different. I am not sure if this would blow things up. It might be enough to put a call to System.gc() in the Interp destroy callback. Not only do we need to doc this, but we need regression tests for these edge cases too. I have been thinking about how to include thread tests in the existing regression test suite, I think a --with-thread option that points to where the Thread extension is build is the only way to go. 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
[Tcl Java] Re: ajuba branch
On Tue, 24 Oct 2000, Dan Wickstrom wrote:
I've finished the changes that I need to make for making the notifier
thread safe, and I want to generate a patch against the ajuba contract
branch, so I checked it out from sourceforge and built it. When I run
make test, I get an assertion failure. on tsdPtr-initalized. Is this
branch supposed to be able to run the tests, or do I need to wait for
other changes? I was hoping that the tests would pass before I made the
notifier changes, so that I could at least tell if the new notifier
changes would break anything.
I'm running with the following:
redhat 6.2
tcl8.3.2
tcljava from souceforge ajuba contract branch
blackdown jdk1.1.8_v1
That really should work, everything you are using is
the same as my install except I have the CVS version of Tcl.
When I run the "make test" on the contract
branch, it works just fine. Of course, I am using
IBM JDK 1.3. not the blackdown one. I know there
is a problem with a core dump during some of the
classloader tests when run with JDK 1.1.8 from
blackdown, but you never hit that assert. The
assertion is raised in the case where a JNI function
is called in a thread before the thread local class
cache and JNI thread attach have been done.
... (Time passes) ...
I just tried it with JDK 1.1.8 and now I am getting
a SIGILL in some pthreads code. Very strange.
#0 0xbfffa6ee in ?? ()
#1 0x400dbe05 in pthread_handle_sigrestart (sig=32, ctx={gs = 0, __gsh =
0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh = 0, edi = 0,
esi = 3221211404, ebp = 3221211844, esp = 3221211372, ebx = 3221211404,
edx = 1074683196, ecx = 0, eax = 0, trapno = 1, err = 0, eip =
1075407969, cs = 35, __csh = 0, eflags = 2097734, esp_at_signal =
3221211372, ss = 43, __ssh = 0, fpstate = 0xbfffc870, oldmask = 4, cr2 =
0}) at pthread.c:636
#2 signal handler called
#3 0x40196c61 in __libc_nanosleep () from /lib/libc.so.6
#4 0x400d8fee in pthread_cond_timedwait_relative_new (cond=0x8164d38,
mutex=0x804a0b0, abstime=0xbfffcaf8) at condvar.c:318
#5 0x400d9211 in pthread_cond_timedwait (cond=0x8164d38,
mutex=0x804a0b0, abstime=0xbfffcaf8) at condvar.c:381
#6 0x400b3190 in Tcl_ConditionWait (condPtr=0x804a0a0,
mutexPtr=0x400c92ac, timePtr=0x8049d38) at
/home/mo/project/tcl/unix/../unix/tclUnixThrd.c:686
#7 0x400b3ccc in Tcl_WaitForEvent (timePtr=0x8049d38) at
/home/mo/project/tcl/unix/../unix/tclUnixNotfy.c:742
#8 0x4008e090 in Tcl_DoOneEvent (flags=-3) at
/home/mo/project/tcl/unix/../generic/tclNotify.c:889
#9 0x40061949 in Tcl_VwaitObjCmd (clientData=0x0, interp=0x804de48,
objc=2, objv=0xbfffcc38) at
/home/mo/project/tcl/unix/../generic/tclEvent.c:960
Since I do not see this is the IBM JDK, I am going to
assume that it is a JDK 1.1.8 bug. I hear there is
also a new JDK 1.2 and JDK 1.3 from blackdown, but
I have not downloaded those for testing.
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
[Tcl Java] Re: List bug
On Mon, 23 Oct 2000, Jiang Wu wrote: I have this piece of code, which crashes TclBlend 1.2.6 using JDK 1.2. Can someone else try this and let me know if you can reproduce this behavior? package require java set a [list a b c] set interp [java::getinterp] set a1 [$interp getVar a 0] java::call tcl.lang.TclList append $interp $a1 $a1 $a1 toString java::call tcl.lang.TclList append $interp $a1 $a1 $a1 toString I get a stack overflow after the last command. SymcJIT Panic: Unhandled stack overflow in native code...cannot recover. Addr: 10037e63 I am seeing this bug even in the most recent CVS version. I would say this is a perfect time to try out the new bug DB on sourceforge. Go to: http://sourceforge.net/projects/tcljava The enter this in the bug tracker. cheers 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
[Tcl Java] Re: possible memory.
On Sun, 22 Oct 2000, Jiang Wu wrote: Let's not forget there is a problem with the putting object on a queue for deletion by the interpreter. As the GC may run at a random time, it is possible when a Cobject is being finalized, the associated interpreter is already deleted. 1. Create a thread, 2. Add a Tcl interpreter 3. Do some Tcl work 4. Delete the Tcl interpreter 5. Delete the thread 6. GC runs to finalize objects created in the above process I agree that the case you describe is a concern, but I don't see that we have a choice at this point. I would like to get this free with the queue thing and fixing up of the Notifier done, and then worry about overhauling the ref counting approach. We need to get these changes finished off and merged back into the HEAD very soon. Currently, we have no thread safe code to point people to. Something that works for 99.999% of the cases is better than something that works for 0% of them. 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
[Tcl Java] Tcl/Java project moves to sourceforge!
I did not see any objections to the thread cleanup patches I posted, so I checked them into the CVS along with a fix that adds a mutex to access some global variables. If you want to get these changes, you will have to check them out of the sourceforge CVS. As you may have heard, the Tcl project is moving over to sourceforge, so Tcl/Java is going along for the ride. The new project homepage is: http://sourceforge.net/projects/tcljava For CVS info, click on the "CVS Repository" link and then follow the instructions for anonymous CVS access. The CVS repo on sourceforge is the same as the old one, in fact it now has a couple of new patches. Moving to sourceforge is really going to improve the project, there are all sorts of nice tools that will make managing and participating in the development of Tcl/Java much more simple. There is a nice little bug database, a patch database, and lots of other nice tools. I created two mailing lists, tcljava-user and tcljava-dev. If you don't care to read about discussion of patches and other implementation details, you can subscribe to tcljava-user. If you only care about patches and you don't want to read a bunch of questions like: "Why do I get the class not found error?" then just subscribe to tcljava-dev. You can of course subscribe to both. I think these mailing lists are up and running, but I have not been able to get a test message through yet, so I can't be sure. In about 2 weeks, I am going to close down the [EMAIL PROTECTED] mailing list in favor of using the ones on SF. Same goes for the old CVS repo. cheers 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
[Tcl Java] Re: possible memory.
On Sat, 21 Oct 2000, Dan Wickstrom wrote:
What does your src/tclblend/tcl/lang/CObject.java finalize()
method look like? I thought the last round of patches left
that ptr dangling on purpose. I have not has time to
Yes the finalize method just calls the super class finalize method.
Well, that would be your memory leak :)
I finished an initial implementation of some code
that will put an object that needs to be decr'ed
into the event queue.
I have been getting some good results, the crashing
I was seeing with JDK 1.3 from IBM has now gone
away. I also ran it with some tests under JDK 1.1
and it is working (with one small exception).
Could some folks to try this out and see if it
makes the crash in the GC thread problem go away?
There should be no more memory leaks.
The patch is for src/tclblend/tcl/lang/CObject.java
off of the contract branch.
thanks
Mo DeJong
Red Hat Inc
Index: CObject.java
===
RCS file: /cvsroot/tcljava/tcljava/src/tclblend/tcl/lang/CObject.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 CObject.java
--- CObject.java1998/10/14 21:09:10 1.1.1.1
+++ CObject.java2000/10/22 02:25:36
@@ -24,11 +24,9 @@
class CObject extends InternalRep {
-/*
- * This long really contains a Tcl_Obj*. It is declared with package
- * visibility so that subclasses that define type specific functionality
- * can get to the Tcl_Obj.
- */
+// This long really contains a Tcl_Obj*. It is declared with package
+// visibility so that subclasses that define type specific functionality
+// can get to the Tcl_Obj. This field can be read from C code.
long objPtr;
@@ -51,8 +49,7 @@
CObject()
{
-this.objPtr = newCObject(null);
-incrRefCount(objPtr);
+this(newCObject(null));
}
/*
@@ -76,6 +73,9 @@
{
this.objPtr = objPtr;
incrRefCount(objPtr);
+
+Notifier notifier = Notifier.getNotifierForThread(Thread.currentThread());
+addTableRef(notifier, objPtr);
}
/*
@@ -97,6 +97,7 @@
public void
dispose()
{
+removeTableRef(objPtr);
decrRefCount(objPtr);
objPtr = 0;
}
@@ -180,6 +181,7 @@
* newInstance --
*
* Construct a new TclObject from a Tcl_Obj*. This routine is only
+ * called from C. It is also the only CObject method that can be
* called from C.
*
* Results:
@@ -218,11 +220,13 @@
{
if (objPtr != 0) {
/*
-* If the object is finalized while the reference is still valid,
-* we need to sever the connection to the underlying Tcl_Obj*.
+* If a CObject is finalized while the reference is still valid,
+* we need to send the reference back to the thread that created it.
+* We can then sever the connection to the underlying Tcl_Obj* by
+* calling decrRefCount() in that thread.
*/
- decrRefCount(objPtr);
+ finalizeTableRef(objPtr);
}
super.finalize();
}
@@ -329,6 +333,202 @@
makeRef(
long objPtr, // Pointer to Tcl_Obj.
TclObject object); // Object that Tcl_Obj should refer to.
+
+/*
+ *--
+ *
+ * CleanupTableEntry --
+ *
+ * This is a little helper class used to store the objPtr
+ * and to take on the role of the TclEvent that will be
+ * called after the event is queued.
+ *
+ * Results:
+ * None.
+ *
+ * Side effects:
+ * None.
+ *
+ *--
+ */
+
+static class CleanupTableEntry extends TclEvent {
+Notifier notifier;
+long objPtr;
+
+CleanupTableEntry(Notifier notifier, long objPtr) {
+ this.notifier = notifier;
+ this.objPtr = objPtr;
+}
+
+public int processEvent(int flags) {
+System.err.println("calling decrRefCount from processEvent for " + objPtr);
+CObject.decrRefCount(objPtr);
+return 1;
+}
+
+// This method will add this TclEvent to the
+// notifier for the Interp that created the
+// original Tcl_Obj ptr. This must be done
+// asyncronously, we can't block the GC
+// thread for any reason!
+
+void appendToNotifierQueue() {
+System.err.println("queueing cleanup for " + objPtr);
+ notifier.queueEvent(this, TCL.QUEUE_TAIL);
+}
+}
+
+/*
+ *--
+ *
+ * addTableRef --
+ *
+ * Create a ref in the global Tcl_Obj table. It is used to
+ * keep track of the interp where a given object was created
+ * so that we can queue up an event in that interp.
+ *
+ * Results:
+ * None.
+ *
+ * Side effects:
+ * None.
+ *
+ *--
+ */
+
[Tcl Java] Re: possible memory.
On Fri, 20 Oct 2000, Daniel Wickstrom wrote: The TclList.getLength method converts indexListObj to a TclList object which uses an underlying Tcl_Obj to hold the internal rep. At the end of this case statement, it returns leaving indexListObj with no references. The jvm garbage collects indexListObj, but the underlying Tcl_Obj is left stranded and results in a memory leak. -Dan What does your src/tclblend/tcl/lang/CObject.java finalize() method look like? I thought the last round of patches left that ptr dangling on purpose. I have not has time to look at the patches your guys are using so I am not sure what is going on. I think what we need to do in the short term is to implement a patch that will send a Tcl_Obj that gets freed back to the Tcl interp using the thread safe event queue. That way we can free the object up back in the Tcl thread and it will not core dump like it would if we freed it up in the JVM GC thread. After we have something (anything) working we can hack around with the various ref count solutions to see if we can find one that passes all the tests and does not leak memory. We also need to make the Tcl Blend Notifier thread safe. I think time would be better spent focusing on that right now instead of fighting ref counting. 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
[Tcl Java] Re: [Tclblend] accessing inner class?
On Tue, 17 Oct 2000, Jens Schliephacke wrote:
Good morning dear list!
Humm, I was just going to bed.
I'm having a problem using the javax.mail API directly from tcl.
I'm using tclblend 1.2.5 an I have to get this Java code done from tcl:
// Examine ALL system flags for this message
Flags flags = m.getFlags();
Flags.Flag[] sf = flags.getSystemFlags();
for (int i = 0; i sf.length; i++) {
if (sf[i] == Flags.Flag.DELETED)
System.out.println("DELETED message");
All works fine, except accessing the inner class fields!
[java::field javax.mail.Flags.Flag DELETED] does not work, neither does
[java::field javax.mail.Flags Flag.DELETED].
I think you want to use:
java::field javax.mail.Flags\$Flag DELETED
It is a wacky hack that the Java designers decided to
throw into 1.1 so that they did not have to change the
VM spec. Rather ugly if you ask me.
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
[Tcl Java] Re: thread cleanup - something that works
On Tue, 17 Oct 2000, Daniel Wickstrom wrote: I was never able to get Tcl_CreateThreadExitHandler to work for either the TclThreadCleanup or the JavaCacheCleanup routines. As a work-around I decided to call both of these cleanup routines at the end of the JavaInterpDeleted function. I've run this setup under load, and other than leaking memory, I've had no problems. If you create only one Tcl interp in a thread, the might work. It is not going to work in the more general case as multiple Tcl interps can exist in one thread. Just run: % interp create And you got two right there! Perhaps it is a problem with some init code that is not getting run in the Tcl interp. What part of Tcl calls those callbacks? 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
[Tcl Java] Re: leaking memory
On Thu, 12 Oct 2000, Daniel Wickstrom wrote: "Mo" == Mo DeJong [EMAIL PROTECTED] writes: Mo There are two cleanup cases. Mo TclThreadCleanup is called when a Tcl thread (one that was not Mo started inside a JVM) is terminated. TclThreadCleanup will Mo just call DetachCurrentThread() to disconnect the Tcl thread Mo from the JVM. Mo JavaCacheCleanup should be called when a Java or Tcl thread is Mo terminated, its job is to clean up the thread local cache or Mo classes. For me these two cases seem to be one in the same. At the end of a connection thread, I need to do both JavaCacheCleanup and DetachCurrentThread. That would be the case when you created the thread in Tcl (meaning the JVM did not create the thread). Mo I am not sure which of these you are using because the Mo description below says "Connection thread starts" and then Mo "jvm attach to the current connection thread", that would make Mo me think it is a thread created from Tcl. I think what you're saying is correct. I've always thought of it as aolserver starting a connection thread and allocating a tcl interpreter instance to run in that thread. The jvm attach is done at the start of the thread by a registered proc, and after the jvm is attached to the connection thread, tclblend is initialized. What do you mean by "The jvm attach is done at the start of the thread by a registered proc"? Are you not using: (*javaVM)-AttachCurrentThread() In JavaInitEnv() to attach the Tcl thread to the JVM? This is also the place where this is called. Tcl_CreateThreadExitHandler(TclThreadCleanup, NULL); Perhaps I am just not understanding what you mean. You really should not need to do your own JVM attach, at least that is not something I had considered (ugh, we don't really need another init case). 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
[Tcl Java] Re: leaking memory
On Thu, 12 Oct 2000, Daniel Wickstrom wrote: "Mo" == Mo DeJong [EMAIL PROTECTED] writes: Mo What do you mean by "The jvm attach is done at the start of Mo the thread by a registered proc"? Are you not using: Mo (*javaVM)-AttachCurrentThread() Mo In JavaInitEnv() to attach the Tcl thread to the JVM? This is Mo also the place where this is called. Mo Tcl_CreateThreadExitHandler(TclThreadCleanup, NULL); Mo Perhaps I am just not understanding what you mean. You really Mo should not need to do your own JVM attach, at least that is Mo not something I had considered (ugh, we don't really need Mo another init case). I should have elaborated. To use tclblend in aolserver, I basically had to tear apart javaCmd.c and re-implement it in the structure required by aolserver. aolserver provides functions outside of tcl to register a function at the start of a thread. I'm using this aolserver registered function to call AttachCurrentThread. I'm also calling Tcl_CreateThreadExitHandler(TclThreadCleanup, NULL) in my init routine. Other than javaCmd.c, the rest of the tclblend code is the same as what I pulled out of cvs. At some later time, when I understand everything, I'm going to try and restructure everything to use the code in javaCmd.c if possible. If not, I will have one extra 'c' file to support aolserver. If you ask me, you time would be better spent getting the current code into "shape" so that it can be dropped into aolserver as is. The code on the branch is not really set in stone, so if you can provide a reasonable way to add your stuff with only a minimal change (like #ifdef AOLSERVER perhaps), then we could add it in without lots of duplicated functionality. Of course, it is up to you, but in the long run 1 codebase is far far better. One thing that we really should do is document the init cases, we currently have three of four ways a thread can go through the init code. It would be nice to write each one down. 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
[Tcl Java] Re: leaking memory
On Thu, 12 Oct 2000, Dan Wickstrom wrote: If you ask me, you time would be better spent getting the current code into "shape" so that it can be dropped into aolserver as is. The code on the branch is not really set in stone, so if you can provide a reasonable way to add your stuff with only a minimal change (like #ifdef AOLSERVER perhaps), then we could add it in without lots of duplicated functionality. Of course, it is up to you, but in the long run 1 codebase is far far better. I'm all for having one code base. I'll see if I can't work towards merging completely with the tclblend code. When I asked you about this originally, I was under the impression that you didn't really want me to touch any of the tclblend 'c' code. I thought you were talking about code that would only apply to aol server stuff. If it is possible to cleanly merge in your Tcl Blend init case, then I am all for that. Of course, I would need to see the patch first :) 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
[Tcl Java] Re: leaking memory
On Wed, 11 Oct 2000, Daniel Wickstrom wrote:
Last weekend I ran the merged tclblend/aolserver combination using
apache-bench to make concurrent accesses of multiple urls, and I
noticed that the memory size was growing over time. I think this is
probably due in part to the java info cache not being cleaned up. It
seems that at the end of a thread, the DeleteGlobalRef should be
called for each of the items in the cache.
That does seem logical. It looks like the Class refs need to
be cleaned up. What do you think of the patch below? This
would tend to happen if you created a lot of Tcl or Java
threads and loaded Tcl Blend into them. Is that what
you are doing? This also sounds like that mem leak problem
from yesterday, do this patch help? The patch is for the
ajuba-tclblend-contract-2000-08-01-branch branch in the CVS.
Another thing that I've noticed is that the TclThreadCleanup routine
is not being called. I register this proc one time from the aolserver
startup routine, but I'm wondering if maybe it needs to be registered
at the start of each thread.
-Dan
That seems to happen to me too. It seems like the new cache
cleanup method is getting called when Tcl Blend is loaded into
Tcl, but I am not sure what is going on when you load
Tcl Blend and Tcl into a JVM. How could we test this
sort of thing?
Here is my proposed patch to cleanup the Class refs.
I am also going to attach it to this file because
it is going to get hosed in mail.
Mo DeJong
Red Hat Inc
Index: tcljava/src/native/javaCmd.c
===
RCS file: /home/cvs/external/tcljava/src/native/javaCmd.c,v
retrieving revision 1.9.2.7
diff -u -r1.9.2.7 javaCmd.c
--- javaCmd.c 2000/08/27 08:07:40 1.9.2.7
+++ javaCmd.c 2000/10/12 06:00:15
@@ -104,6 +104,7 @@
static int AddToFieldCache(JNIEnv *env, Tcl_Interp *interp, jfieldID
*addr,
char *name, jclass *class, char *sig);
static voidTclThreadCleanup(ClientData clientData);
+static voidJavaCacheCleanup(ClientData clientData);
/*
*--
@@ -206,7 +207,7 @@
#ifdef TCLBLEND_DEBUG
fprintf(stderr, "TCLBLEND_DEBUG: Tclblend_Init finished\n");
-fprintf(stderr, "TCLBLEND_DEBUG: JavaInitBlend() returned ");
+fprintf(stderr, "TCLBLEND_DEBUG: JavaInitBlend returned ");
if (result == TCL_ERROR) {
fprintf(stderr, "TCL_ERROR");
} else if (result == TCL_OK) {
@@ -393,6 +394,8 @@
* From this point on, deal with the case where Tcl Blend is loaded
from Tcl.
* Check to see if the current process already has a Java VM. If
so, attach
* the current thread to it, otherwise create a new JVM (automatic
thread attach).
+ * In the case where Tcl Blend is loaded into Java, the call to
+ * JNI_GetCreatedJavaVMs will fill in the javaVM pointer with the
JVM pointer.
*/
if (JNI_GetCreatedJavaVMs(javaVM, 1, nVMs) 0) {
@@ -558,7 +561,7 @@
goto error;
}
-} else {
+} else { /* (nVMs == 0) */
#ifdef TCLBLEND_DEBUG
fprintf(stderr, "TCLBLEND_DEBUG: JVM in process, attaching\n");
@@ -734,20 +737,66 @@
static void
TclThreadCleanup(ClientData clientData)
{
-JNIEnv* env;
-ThreadSpecificData *tsdPtr = TCL_TSD_INIT(dataKey);
-
#ifdef TCLBLEND_DEBUG
fprintf(stderr, "TCLBLEND_DEBUG: called TclThreadCleanup\n");
#endif /* TCLBLEND_DEBUG */
-env = tsdPtr-currentEnv;
(*javaVM)-DetachCurrentThread(javaVM);
}
/*
*--
*
+ * JavaCacheCleanup --
+ *
+ * This method will be called when a Tcl or Java thread is finished.
+ * It needs to remove any global cache references so that the
+ * classes and methods can be cleaned up by the JVM.
+ *
+ * Results:
+ * None.
+ *
+ * Side effects:
+ * None.
+ *
+ *--
+ */
+static void
+JavaCacheCleanup(ClientData clientData)
+{
+JNIEnv* env = JavaGetEnv();
+JavaInfo* jcache = JavaGetCache();
+
+/* FIXME: need to add code to check for case where TclThreadCleanup is
called first */
+
+#ifdef TCLBLEND_DEBUG
+fprintf(stderr, "TCLBLEND_DEBUG: called JavaCacheCleanup\n");
+#endif /* TCLBLEND_DEBUG */
+
+/* We need to delete any global refs to Java classes */
+
+(*env)-DeleteGlobalRef(env, jcache-Object);
+(*env)-DeleteGlobalRef(env, jcache-Interp);
+(*env)-DeleteGlobalRef(env, jcache-Command);
+(*env)-DeleteGlobalRef(env, jcache-TclObject);
+(*env)-DeleteGlobalRef(env, jcache-TclException);
+(*env)-DeleteGlobalRef(env, jcache-CommandWithDispose);
+(*env)-DeleteGlobalRef(env, jcache-CObject);
+(*env)-DeleteGlobalRef(env, jcache-Extension);
+(*env)-DeleteGlobalRef(env, jcach
[Tcl Java] Re: xputil bug with patch
On 22 Sep 2000, Jiang Wu wrote: xputil does not properly handle Windows environment variables. It interprets the "\" path separator and ";" that is to distinguish multiple paths in Windows environment as Tcl significant. I just checked a slightly modified version of your patch into the contract branch (I just added another list command to an uplevel). cheers 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
[Tcl Java] Re: Question in running tclBlend demo
On Sat, 30 Sep 2000, Yinghu Na wrote: Hi, I have a problem when I run the tclBlend demo "watchpkg". I don't know how to pass the parameters to the command "swSet", "swStop", "swResume", and "swDie". For example, when I type the command "swSet java0x1(the returned id# by command "swNew") 10", it said " invalid command name "java0x1"". How should I fix it? The trick to that is the need to keep a Tcl variable with a live ref to the Java object around. If you do not, the Java GC system will clean up the Java object behind your back. I updated the README file for that example, here is what is not looks like. To add the sw* Tcl procedures, after adding the StopWatchExtension (as shown above), type "source swCmd.tcl" at the Tcl command prompt. to create a new stop watch object and save a reference to the Tcl object, type: % set sw [swNew] To set the countdown time, type: % swSet $sw 10 Is that more clear? 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
[Tcl Java] Re: Accessing public parent fields
On Thu, 14 Sep 2000, Sandeep Tamhankar wrote:
I have the following two class definitions:
public class myclass {
private int priv;
public int f1;
public int f2;
public static int stat=5;
public myclass () {
f1=7;
}
public void setF2(int i) {
f2=i;
}
public int getF2() {
return f2;
}
}
public class mysubclass extends myclass {
public int sub1;
}
I execute the following Tcl code to introspect my two classes, and there
seems to be some kind of inconsistency. java::info on mysubclass
returns all of its fields as well as its parents; however it seems that
I can't use java::field to actually get/set the values of those fields:
% package require java
1.2.5
% java::info fields -type mysubclass
{int f1} {int f2} {int sub1}
% java::info fields -type -static mysubclass
{int stat}
% set obj [java::new mysubclass]
java0x1
% java::field $obj sub1
0
% java::field $obj f1
field "f1" doesn't exist
% java::field $obj stat
field "stat" doesn't exist
If I mess around with the parent class containing those fields, things
work out:
% java::field myclass stat
5
% set sobj [java::new myclass]
java0x2
% java::field $sobj stat
5
This seems to be a big bug to me. Am I doing something wrong, or is
there something wrong with Blend? Thanks.
-Sandeep
This is a known bug. You have a couple of options, there
is a "quick fix" that you can use (see below). There is
also a "less quick fix" that involves a small hack to
the source code. The real fix is of course much harder.
I know how to fix it, but I just have not had time to
do it. Of course, if someone wants to volunteer to write
some code and regression tests, I would be glad to
explain how to implement the fix.
Remember, the mailing list archive is your friend.
Use is, it has a nice search feature that can save
you time and heartache.
http://www.mail-archive.com/tcljava@scriptics.com/
The original problem:
http://www.mail-archive.com/tcljava@scriptics.com/msg00490.html
http://www.mail-archive.com/tcljava@scriptics.com/msg00040.html
The "quick fix" (where Quick != Correct)
http://www.mail-archive.com/tcljava@scriptics.com/msg00492.html
A discussion of the real fix, and why it is hard:
http://www.mail-archive.com/tcljava@scriptics.com/msg00806.html
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
[Tcl Java] Re: JACL on windows.
On Tue, 12 Sep 2000, Toga Hartadinata wrote: Hi, I have a question on running JACL. I am integrating JACL to script my gui, and was testing it on windows platform, using a Unix type shell (MKS Toolkit). When I was running JACL sometimes it stuck for a few seconds, before giving me a response. This case happens randomly, even with the same operation I requested. Is this machine dependable ??? I run the same program on Unix and it never stuck. Anyone ever encountered the same problem ? Or is my machine is just to slow ? Did this only happen when typing into the console? I have not tested Jacl on any console other than the regular cmd.exe type of dos console on windows. You might want to try turning on the debug options in src/jacl/tcl/lang/Shell.java and see what get printed, you would have to debug it yourself, but I do not see any other way of addressing this issue. You might also want to try another JVM and see if that does anything. By the way, why would you use that MKS Toolkit when you could be using Cygwin? 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
[Tcl Java] Re: [Tcl Java]
On Mon, 11 Sep 2000, Peter Geraghty wrote: ... Peter, you are posting in HTML. This makes it very hard to read your email. Please repost in plain text if you want help. 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
[Tcl Java] Re: Problems with TclBlend
On Thu, 31 Aug 2000, joseph freydlin wrote: Hi joseph. We are working on big telecommunication project. We have a lot of Tcl scripts which glue many Java applications talking to them using Corba. Now we would like to implement everything using TclBlend. Some of our scripts sometimes take 15 minutes of more to execute so we need multithreaded calls to interpreter. Our platform now is Solaris-Sparc. I have made little example to try tclBlend with multithreading in Java 1.2.2 and Tcl 8.3.2 environment. But whatever I do and whatever LD_LIBRARY_PATH I define my example always fails. Below is source in Java and messages. It looks like I am not able even create Interp object. I tried to create Interp in main thread. It fails with the same result. Some additional information: this test runs perfectly with Jacl. When I go to jtclsh for tclBlend I am able to create java::Interp and submit scripts and it works fine. I downloaded version tclBlend 1.2.6 and built version with gcc. I built Tcl also using gcc. It looks like you are trying to create Tcl interps from Java (as opposed to loading Java into Tcl). This is something that is not really supported in Tcl Blend 1.2. Tcl Blend 1.2 is just not designed for this sort of thing. The good news is that this is an area that is currently being addressed in version 1.3. I ran your example with the dev 1.3 version that has been rewritten to correctly support multiple threads (the CVS branch name is ajuba-tclblend-contract-2000-08-01-branch in case you want to take a look at the code). The good news is that it "almost" works, the threaded Interp init stuff is working properly, but getting the notifier working in a multithreaded way is work that still needs to be done. Once the notifier is fixed, there is still one other problem with garbage collection of Tcl Objects, but once that is fixed Tcl Blend should work with threads as well as Jacl. So, you have a couple of options: 1. Wait around until it is done. (You might want to just use Jacl until Tcl Blend is ready) 2. Pitch in. Help is always welcome. Tcl/Java is an open source project, so the more you pitch in the faster things will get done. A number of new folks have started to contribute to the project in recent months, and that has lead to a number of great new features. 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
[Tcl Java] Re: Problems Making TclBlend 1.2.6 on Windows 2000 (NT 5.0)
On Wed, 6 Sep 2000, Dan Schenck wrote: I have attempted to make TclBlend1.2.6 on Windows 2000 using Tcl8.3.2. I modified the make file according to the instructions, however, there are problems with the make file. First, it wants to delete files which are not there the first time you run nmake. When delete fails the script won't complete. I got around this by faking up the files it was looking for so it would have something to delete. There is also a quoting problem where the include path for Tcl needs to be enclosed in ""s if the Tcl path has blanks in a directory name, e.g., "C:\Program Files\Tcl\include". Now though I am stuck. Make is looking for tclInt.h and I don't have it anywhere. I recall that this used to be included with Tcl, but apparently it is not anymore. Is there a source for this file somewhere? You need to have the source code for Tcl so that it can find tclInt.h. I assume you just downloaded the binary of Tcl and you are trying to build Tcl Blend from that. You might just want to download the binary or Tcl Blend in that case, but be warned that the binary has its own troubles. 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
[Tcl Java] Re: Installing and Building TclBlend
On Thu, 31 Aug 2000, Yogindra Persaud wrote: Hi, can someone assist me in installing TclBlend 1.2.6. When I try to do a ./configure in the unix directory, it says that it can't find any zip or jar files to include on the classpath. I set the prefixes and the --with-tcl and the --with-jdk paths correctly...I think . I know the --with-jdk path is correct, because just before it gives me that error, it says that it found java. Please help. You need to include more info about what system you are running this on and provide the config.log file that gets generated. You might have some strange JDK version that the configure script does not yet know about. I also suggest that you use the 1.3 version in the CVS if you are using some strange new JDK. 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
[Tcl Java] Re: global JavaInfo structure in threaded tclblend.
On Mon, 28 Aug 2000, Daniel Wickstrom wrote: I would anticipate some changes to the autoconf files and makefile templates, and the addition of some aolserver specific 'c' files. That does not sound too bad. How about a src/aolserver subdirectory for your .c files? I don't expect a firm commitment from you to add support for aolserver integration, but I'm interested to know if you are open to the idea. Your openness to the idea would affect my approach to integrating tclblend in aolserver. If however, you don't want the additional complication to the tclblend distribution, I understand. Keep in mind that you are going to have to do your own testing. If (more like when) I change something that breaks the AOL build, you are going to have to fix it and send in a patch. If you are interested in taking responsibility for the AOL parts of the code then I am interested in adding the code. 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
[Tcl Java] Re: global JavaInfo structure in threaded tclblend.
On Wed, 23 Aug 2000, Daniel Wickstrom wrote: I'm curious about the JavaInfo structure in javaCmd.c. When I looked at this before, I assumed that you would need a seperate JavaInfo structure per thread. The code I'm looking at now seems to assume one global JavaInfo structure that can be used by all tcl threads. Am I missing something here, or is this part of the code still work in progress? I thought I read somewhere in the java docs that class and method ids can't be shared between java threads. -Dan Just a quick update, I moved the cache into thread local storage and reworked a bunch of stuff to support it. Things should be fully thread safe now. If you want to take another peek you are welcome to, of course you might have to wait until monday morning for the CVS mirror to update. 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
[Tcl Java] Re: problem with instalation og jacl
On Tue, 22 Aug 2000, Boyapati, Srinivas (IndSys) wrote: hi i have down loaded binray version of jacl. in that i got jacl.jar and tcljava.jar i set those jar files in my path enveron variable of my system( i am working on windows NT system). then i tryed to run jacl by typing java tcl.lang.Shell then i got error class tcl/lang/Shell not found. please give guideance to slove this problem( to install properly) thanks for ur support srinivas You need to put the jar file on the CLASSPATH, not the PATH. like so: set CLASSPATH=C:\jacl.jar;C:\tcljava.jar java tcl.lang.Shell 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
[Tcl Java] Re: ReflectObject
On Tue, 22 Aug 2000, Jiang Wu wrote:
% set a [java::new String foo]
java0x3
% [java::getinterp] {setVar java.lang.String java.lang.String int} b $a 0
java0x6
% set c $a
java0x3
% set a
java0x3
% set b
foo
% set c
java0x3
Can someone explain to me why 'b' and 'c' should be different? Is the
difference due to a feature, a bug, or a limitation?
Humm, there does seem to be something wrong here.
I would expect b to get set to "java0x3" (what a was set to).
Here is a really simple test case:
public class PrintString {
public static String foo(String s) {
return s;
}
}
package require java
set a [java::new String foo]
java::call PrintString foo $a
foo
It should not work like that. The method
should just return javax0x1.
I have also added a test case for this problem to
the HEAD branch. The patch is as follows.
Index: ChangeLog
===
RCS file: /home/cvs/external/tcljava/ChangeLog,v
retrieving revision 1.59
diff -u -r1.59 ChangeLog
--- ChangeLog 2000/08/21 04:48:11 1.59
+++ ChangeLog 2000/08/23 05:51:29
@@ -1,3 +1,10 @@
+2000-08-22 Mo DeJong [EMAIL PROTECTED]
+
+ * src/tests/tcljava/tests/JavaTest.java:
+ * tests/tcljava/JavaInvoke.test: Add identity
+ test case for passing of a java.lang.String
+ ReflectObject to a Java method.
+
2000-08-20 Christian Krone [EMAIL PROTECTED]
* src/jacl/tcl/lang/LreplaceCmd.java:
Index: src/tests/tcljava/tests/JavaTest.java
===
RCS file: /home/cvs/external/tcljava/src/tests/tcljava/tests/JavaTest.java,v
retrieving revision 1.2
diff -u -r1.2 JavaTest.java
--- JavaTest.java 1999/05/16 00:06:03 1.2
+++ JavaTest.java 2000/08/23 05:51:29
@@ -105,5 +105,12 @@
public void disposeCmd() {
istr = "disposed";
}
+
+// Returns the java.lang.String that was passed in
+// used to test argument conversion.
+
+public static String retStr(String str) {
+return str;
+}
}
Index: tests/tcljava/JavaInvoke.test
===
RCS file: /home/cvs/external/tcljava/tests/tcljava/JavaInvoke.test,v
retrieving revision 1.4
diff -u -r1.4 JavaInvoke.test
--- JavaInvoke.test 1999/05/16 00:15:38 1.4
+++ JavaInvoke.test 2000/08/23 05:51:30
@@ -419,6 +419,12 @@
jtest type [java::field $x iobj3]
} tcl.lang.ReflectObject
+set str [java::new String hello]
+test invoke-9.16 {convertJavaObject: Check passing of java.lang.String} {
+java::call tests.JavaTest retStr $str
+} $str
+unset str
+
#
# convertTclObject
#
Of course, the problem still needs to be fixed, but now
that we have a test case it should be easy.
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
[Tcl Java] Re: Error in (not yet published) Interp.java
On Wed, 16 Aug 2000, Christian Krone wrote:
Hello,
there is an error in the Interp.java file as you get it
when you applied the patch at
http://ME.IN-Berlin.de/~v12/krischan/Interp/other-files.patch
You should make the following change to get the correct version:
--- Interp.java.org Wed Aug 16 18:21:46 2000
+++ Interp.java Wed Aug 16 06:45:36 2000
@@ -3425,7 +3425,7 @@
// (that the user is not trying to do an expose and a rename
// (to another namespace) at the same time)
-if (hiddenCmdToken.indexOf("::") = 0) {
+if (cmdName.indexOf("::") = 0) {
throw new TclException(this, "can not expose to a namespace "
+ "(use expose to toplevel, then rename)");
}
Greetings, Krischan
I checked this patch in as part of the larger interp patch.
This interp command patch is awesome, it is right up there
with the clock patch for "patch of the year". Too bad we don't
have a prize or anything. Does anyone want to donate one?
I think I could swing a limited edition Source-Navigator
shirt :)
I just wish we could use the garbage collector instead
of keeping that nasty Tcl_Preserve() stuff around in Jacl.
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
[Tcl Java] Re: Jacl: improved string command (now 8.4 compatible)
On Mon, 14 Aug 2000, Christian Krone wrote: Hello, I uploaded a patch to my private homepage containing patches to some Jacl classes. It can be found here: http://ME.IN-Berlin.de/~v12/krischan/String/string8.4.patch The patch will contain the following improvements to Jacl: - 8.4 compatible string command. - No Exception, when parsing the following command: "set $a(foo" - A double, which is too small, will generate an ARITH UNDERFLOW. - 8.4 compatible error message for: = an invalid option with just two alternatives (no comma before the or); = bad octal numbers. - 0X123 will now be detected as valid hex number. - correct handling for \x123 characters with its 8th bit set (= \x80). I have committed most of this patch. I had to leave the patch for src/tcljava/tcl/lang/TclIndex.java out because it was causing a bunch of other regressions. Once we get the rest of the new tcltest package integrated and the tests updated, we can take another look at the TclIndex.java patch. I also added the string.test file from Tcl 8.4, which now passes without any failures (whooohooo). This string command was one of the most nasty bits, the other updates should be easy in comparison. I assume that some of these changes are tested by other tests and not just string.test. 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
[Tcl Java] Re: Jacl: improved string command (now 8.4 compatible)
On Mon, 14 Aug 2000, Christian Krone wrote: In the same location there is also another patch, which makes the Jacl test target using the tcltest package of Tcl8.4. It can be found here: http://ME.IN-Berlin.de/~v12/krischan/String/tcltest.patch http://ME.IN-Berlin.de/~v12/krischan/String/all.tcl This needs some more work: = there are currently only 14 test with the "package require tcltest" call instead of the old "source def". = TclBlend's test suite should use all.tcl, too. = it would be really cool to be able to do just a jaclsh xxx.test; currently the auto_path is not correct for such a usage. But it is a start. The other major problem with using a "package require tcltest" is that we current have no way of using a package inside a .jar file. This is something I thought about before. What we really need to do is get a list of the pkgIndex.tcl files that live in a .jar file so that they can be sourced to provide the "package ifneeded" statements. Currently, we have no way to look for these pkgIndex.tcl file in the same way that it does on disk because we can not glob for file names out of a .jar file. Does anyone feel up to hacking on this problem? It would not be very hard to implement and it would be really useful because folks could put their own packages into .jar files. Oh, by the way in case you are wondering how a "package require java" works, it is faked because of this exact problem. 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
[Tcl Java] Re: Last(?) steps for an InterpCmd in Jacl
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
[Tcl Java] Re: Improvements of Jacl's clock command
On Mon, 7 Aug 2000, Christian Krone wrote: Hello, yesterday I checked out the Tcl8.4 sources from the NetCVS and noticed, that the C implementation of the clock command had one improvement and one bug fix. The patch to incorporate these changes into Jacl can be found here: http://me.in-berlin.de/~v12/krischan/clock8.4.patch Greetings, Krischan Checked in. 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
[Tcl Java] Latest Interp patch.
I am currently reviewing the new interp impl, the one part
of this patch that bothers me are the changes in
src/jacl/tcl/lang/CatchCmd.java:
--- CatchCmd.java 1998/10/14 21:09:18 1.1.1.1
+++ CatchCmd.java 2000/08/19 22:21:19
@@ -38,11 +38,13 @@
TclObject result;
int code = TCL.OK;
+ interp.nestLevel++;
try {
interp.eval(argv[1], 0);
} catch (TclException e) {
code = e.getCompletionCode();
}
+ interp.nestLevel--;
result = interp.getResult();
@@ -55,6 +57,7 @@
}
}
+ interp.returnCode = TCL.OK;
interp.setResult(TclInteger.newInstance(code));
}
}
There C implementation (Tcl_CatchObjCmd) does not
have anything like this:
Tcl_CatchObjCmd(dummy, interp, objc, objv)
ClientData dummy; /* Not used. */
Tcl_Interp *interp; /* Current interpreter. */
int objc; /* Number of arguments. */
Tcl_Obj *CONST objv[]; /* Argument objects. */
{
Tcl_Obj *varNamePtr = NULL;
int result;
if ((objc != 2) (objc != 3)) {
Tcl_WrongNumArgs(interp, 1, objv, "command ?varName?");
return TCL_ERROR;
}
/*
* Save a pointer to the variable name object, if any, in case the
* Tcl_EvalObj reallocates the bytecode interpreter's evaluation
* stack rendering objv invalid.
*/
if (objc == 3) {
varNamePtr = objv[2];
}
result = Tcl_EvalObjEx(interp, objv[1], 0);
if (objc == 3) {
if (Tcl_ObjSetVar2(interp, varNamePtr, NULL,
Tcl_GetObjResult(interp), 0) == NULL) {
Tcl_ResetResult(interp);
Tcl_AppendToObj(Tcl_GetObjResult(interp),
"couldn't save command result in variable", -1);
return TCL_ERROR;
}
}
/*
* Set the interpreter's object result to an integer object holding the
* integer Tcl_EvalObj result. Note that we don't bother generating a
* string representation. We reset the interpreter's object result
* to an unshared empty object and then set it to be an integer object.
*/
Tcl_ResetResult(interp);
Tcl_SetIntObj(Tcl_GetObjResult(interp), result);
return TCL_OK;
}
Why incr the nest level?
I would also rather just call interp.resetResult()
instead of using TCL.OK, what would the implications
of that be?
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
[Tcl Java] Re: Problems with calling Java from TCL
On Fri, 18 Aug 2000, c.j.pulley wrote: Dear all, I'd be very grateful for any problems with this one! I'm running LinuxPPC (kernel 2.2.14 with glibc2.1.3) on a PowerMac 8600/250. I've installed, and have working, a Blackdown port of JDK1.2.2. Compiling tclBlend (version 1.2.6 built on top of TCL/TK 8.3.2) and running it (via jtclsh) is fine - no compile warnings or errors! The demos all work fine. The tclblend tests fail, complaining about not being able to find 'tcl.lang.NativeTestExtension'. Humm, that should not be. Could you try running "make test.build" and then "make test" to see if that fixes it? It might be a makefile problem. However, I'm interested in testing Java code from a TCL script. As I understand things (I may be wrong here?), if we launch jtclsh from the directory containing our compiled Java code (assuming that '.' is locatable on the relevant environment variables), we can then create instances of classes within the compiled code via 'java::new my class'. Yes, that is one of the ways TclBlend would work. The catch is that if your Tcl process does a cd, then a . on the CLASSPATH will not ref the same dir. This does not seem to be the case in your example as the JVM can find the class. Now, if this is so, then I've definitely got a problem since the JVM returns with the error: java.lang.IllegalAccessException my class catching the Java exception object and printing out the trace stack yields the following: java.lang.IllegalAccessException: my class at java.lang.reflect.Constructor.newInstance(Native Method) at tcl.lang.reflect.PkgInvoker.invokeConstructor(PkgInvoker.java:95) at tcl.lang.JavaInvoke.call(JavaInvoke.java:252) at tcl.lang.JavaInvoke.newInstance(JavaInvoke.java:69) at tcl.lang.JavaNewCmd.cmdProc(JavaNewCmd.java:103) at tcl.lang.Interp.callCommand(Interp.java:953) at tcl.lang.Interp.eval(Native Method) at tcl.lang.Interp.eval(Interp.java:794) at tcl.lang.JavaTryCmd.cmdProc(JavaTryCmd.java:74) at tcl.lang.Interp.callCommand(Interp.java:953) Attacking the problem the other way (ie. open the class file, load it into a string and then use java::defineclass etc. to manually load the classes bytecode into the JVM) results in the same error message. So, which is it: a faulty understanding of how to manipulate Java from TCL or do I have a bug in my build of tclBlend somewhere? Or is something else up? I am willing to bet that the class you are trying to access is not public. If the class is not public, then by default it can not be accessed from outside the package. If this is the problem, you do not have to make the class public. There is also a way to add a class to your package to make the internal classes visible to Tcl Blend. Take a look at src/tcljava/tcl/lang/reflect/PkgInvoker.java for an example of how you can add a "special" class to you package so that Tcl Blend can access private parts. The actual tests for this are in tests/tcljava/PkgInvoker.test. I hope that helps 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
[Tcl Java] Tcl Blend object refCount problems, seems like a design flaw.
a very good
long term solution. Java developers are just not used to
"freeing" memory, so that will forget to do it. It is
also going to be very hard to track down one of these
memory leaks once a developer knows about the problem.
(of course, it is just as bad in regular Tcl).
When you get right down to it, this problem can
be summed up as "that is just not right". I
am seriously thinking we need a much more
radical approach to really solve this problem.
First, lets just not call Tcl_IncrRefCount
on a new CObject. I think we need to just
require that a user incr the refCount
of the native Tcl_Obj to indicate that
they want to use it later. The user
would also be responsible for decrementing
the ref count later. This would fix
interp.getVar() so that it matched the
behavior of Tcl_ObjGetVar2.
Now you might be wondering, if the user
needs to incr and decr the Tcl_Obj ref
counts, how are they going to do that?
Good question, the TclObject class
has its own refCount, which is not
the same as the one in the Tcl_Obj.
The most radical approach would be to
just rip out the refCount stuff in
TclObject. You could then map a
TclObject.preserve() to Tcl_IncrRefCount
when the InternalRep was a CObject.
Java already has a GC system available,
so we really do not need to use
ref counting because we do not free
resources manually anyway. This would
mean that preserve() and release()
would be no-ops for every other
type of Internal rep.
While I kind of like that idea,
I am note sure if it could be
implemented all that quickly.
It might require some substantial
rewriting to both Tcl Blend and Jacl.
I may be possible to use a hybrid
approach when a call to
TclObject.preserve() uses the
existing implementation with
special code for the case
where the Internal rep is
a CObject. That way a
call to a TclObject.preserve()
for a wrapped CObject would
end up calling Tcl_IncrRefCount.
If we did that, and then removed
the automatic call to Tcl_IncrRefCount()
when the CObject is created, I think
our problem with Interp.getVar()
would go away.
I think this would still work the
way users would expect, and it
should not break existing code.
Take a look at the init()
method from BlendExtension.java
for a quick example.
TclObject plat = interp.getVar("tcl_platform", "platform",
TCL.GLOBAL_ONLY);
if (plat.toString().equals("java")) {
interp.setVar("tcljava", "tcljava",
TclString.newInstance("jacl"), TCL.GLOBAL_ONLY);
} else {
interp.setVar("tcljava", "tcljava",
TclString.newInstance("tclblend"), TCL.GLOBAL_ONLY);
}
Here we see that TclObject.toString() is called, if
we wrapped a Tcl_Obj without incrementing its ref count,
this should still work. The toString() call would
invoke Java_tcl_lang_CObject_getString which
would call Tcl_GetStringFromObj() (no problem there right).
I am sure there are cases I have overlooked,
but I think the idea is doable.
What do you think?
Are there some cases that will make this solution
impossible?
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
[Tcl Java] Re: TclBlend Ref Counting Bug (GC related)
On 8 Aug 2000, Jiang Wu wrote: Currently, there is a plan to make the Java GC perform some cleanup on Tcl_Obj in TclBlend. Looking at the root cause for the GC trouble, I think there is a problem with how TclBlend uses Tcl_Obj reference counting. Here is my analysis. I think if we fix the reference counting, we don't need to do anything in the GC. TclBlend does not follow the normal Tcl_Obj reference counting usage. In TclBlend, a Java TclObject is used as the handle to the underlining Tcl_Obj: TclObject CObject Tcl_Obj Both Tcl_Obj and TclObject have reference counting. However, when incrementing or decrementing the reference count on the TclObject, this incrementing or decrementing is proxied into the native Tcl_Obj. This doesn't seem correct. In addition, when a new TclObject is created to wrap around a Tcl_Obj, the reference count of the TclObject is 0, but implicitly, the reference count of Tcl_Obj is incremented by 1. This doesn't seem right either. For example, in C, a call to Tcl_GetVar2Ex(...) returns a Tcl_Obj, of which, "The ref count for the returned object is _not_ incremented to reflect the returned reference; if you want to keep a reference to the object you must increment its ref count yourself." In TclBlend, the corresponding call is "interp-getVar()", which uses Tcl_GetVar2Ex(...). However, the resulting Tcl_Obj does have its reference count incremented by 1 implicitly by TclBlend. The problem with this implicit increment of native Tcl_Obj's reference count is that someone, namely the GC thread, must decrement the reference count. This causes all sort of undesirable behaviors such as the GC thread deadlocking because Tcl_Obj's reference count can only be modified by the thread that first created the Tcl_Obj. I think we should fix the TclBlend reference counting behavior: 1. do not implicitly increment native Tcl_Obj reference count when creating a new TclObject that wraps around a Tcl_Obj 2. when incrementing or decrementing reference count on TclObject, also proxy the action into the native Tcl_Obj 3. when TclBlend code wants to keep a Tcl_Obj for the long term, the code must increment the reference count 4. the GC thread should do nothing regarding to the native Tcl_Obj 5. put an assert into the TclObject.finalize() to catch cases when the reference count is not decremented to 0 6. do not pass Tcl_Obj to other threads, this is not supported by Tcl anyway With this fix, I dont' think there is a need to make the GC free Tcl_Obj. -- Jiang Wu [EMAIL PROTECTED] Ahh, good. We came to the exact same conclusions. I wanted to take my own look at the problem and see if my solution matched yours. Now that I see we both think this is the right solution, I feel much better about it. 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
[Tcl Java] Locking down Tcl Blend so that it only works with threaded Tcl.
Here is that patch that I suggest we use to force Tcl Blend
into compiling only with threaded Tcl. This will only
appear in the contract branch for now. When that
work is merged back into the HEAD, everyone will
be forced to compile Tcl Blend with threaded Tcl.
Comments?
Mo DeJong
Red Hat Inc
Index: tcljava.m4
===
RCS file: /home/cvs/external/tcljava/tcljava.m4,v
retrieving revision 1.2
diff -u -r1.2 tcljava.m4
--- tcljava.m4 2000/07/13 18:26:02 1.2
+++ tcljava.m4 2000/08/13 21:38:47
@@ -874,8 +874,8 @@
# not, assume that its top-level directory is a sibling of ours.
#
-AC_ARG_WITH(tcl, [ --with-tcl=DIR build directory for Tcl
8.3.1 (or newer) source release from DIR],
- TCL_BIN_DIR=$withval, TCL_BIN_DIR="$srcdir/../tcl8.3.1/unix")
+AC_ARG_WITH(tcl, [ --with-tcl=DIR build directory for Tcl
8.3.2 (or newer) source release from DIR],
+ TCL_BIN_DIR=$withval, TCL_BIN_DIR="$srcdir/../tcl8.3.2/unix")
if test ! -d "$TCL_BIN_DIR"; then
AC_MSG_ERROR([Tcl directory $TCL_BIN_DIR could not be located.
@@ -946,7 +946,8 @@
# Check for the installed version of tclsh and wish. we need to use the
# one we compiled against because you can not compile with one version
# and then load into another. If you compiled Tcl Blend with Tcl
8.1 and
-# then load it into a Tcl 8.0 interp, it will segfault.
+# then load it into a Tcl 8.0 interp, it will segfault. Also make
+# sure that this shell was compiled with threads support.
#
# Arguments:
# NONE
@@ -966,7 +967,7 @@
AC_MSG_ERROR([Tcl was configued in $TCL_BIN_DIR, but it has not been
built, please build it and run configure again.])
fi
- # Double check that tclsh works and that it is tcl 8.3.1 or better
+ # Double check that tclsh works and that it is tcl 8.3.2 or better
# We need to set LD_LIBRARY_PATH and SHLIB_PATH so that Tcl can find its
# shared library in the build directory on a Unix or HP-UX system.
@@ -997,8 +998,28 @@
rm -f tcl_version.tcl
else
rm -f tcl_version.tcl
- AC_MSG_ERROR([$TCLSH_LOC is not version 8.3.1 or newer])
+ AC_MSG_ERROR([$TCLSH_LOC is not version 8.3.2 or newer])
fi
+
+ # Check that Tcl was compiled with thread support.
+
+ echo '
+if {! [[info exists tcl_platform(threaded)]]} {
+ puts stderr $err
+ exit -1
+}
+puts 1
+exit 0
+ ' tcl_threads.tcl
+
+ if test "`$TCLSH_LOC tcl_threads.tcl 2AC_FD_LOG`" = "1"; then
+ AC_MSG_RESULT([Tcl was compiled with Thread support])
+ rm -f tcl_threads.tcl
+ else
+ rm -f tcl_threads.tcl
+ AC_MSG_ERROR([Tcl must be compiled with Thread support
(--enable-threads)])
+ fi
+
# Now check to see if "make install" has been run in the tcl directory.
# The installed executable name is something like tclsh8.3.
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
[Tcl Java] Yet another reason CObject can not be GCed.
( This is on the contract branch ) Here is a nice little crash that is happening because the GC thread tries to call a JNI method in a thread that was not the initial thread or one that had been attached to the JVM. tclsh: /home/mo/project/tcljava_ajuba/tcljava/src/native/javaCmd.c:379: JavaGetEnv: Assertion `tsdPtr-initialized_currentEnv' failed. SIGABRT 6 (*) abort process stackpointer=0xbf1ff53c Full thread dump Classic VM (J2RE 1.3.0 IBM build cxdev-2502, native threads ): "Finalizer" (TID:0x403d8708, sys_thread_t:0x811b2a8, state:R, native ID:0x10 05) prio=8 at tcl.lang.CObject.decrRefCount(Native Method) at tcl.lang.CObject.finalize(CObject.java:225) at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:92) at java.lang.ref.Finalizer.access$1(Finalizer.java:84) The only good solution to this problem is to not call a JNI method from the GC thread. Of course, we still need to work out the right way to do that. Jiang rightly points out that putting a "free native object" into the thread safe event queue will not help if the Interp does not enter the event queue (like tclsh). 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
[Tcl Java] Re: TclBlend Initialization Mutex
On Wed, 9 Aug 2000, Scott Stanton wrote: Mo DeJong said: It sure would make life easier if we just required Tcl threads to use Tcl Blend. The notifier thing would go away because we could count on threads being there. I'm all in favor of this. As the threaded version of Tcl becomes more stable, I'd like to see it become the default, anyway. --Scott Lets see if we can list the pros and cons before we make a final decision. Pro: Tcl Blend would work, we would avoid strange edge cases. We would not need the notifier hacks Con: Non-thread safe extensions may have problems under Unix. Need to detect if Tcl is compiled with thread support. (not too hard) I am sure I have missed a few. 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
[Tcl Java] Re: TclBlend Initialization Mutex
On Wed, 9 Aug 2000, Jiang Wu wrote: -Original Message- From: Mo DeJong [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 09, 2000 1:34 PM To: [EMAIL PROTECTED] Subject: [Tcl Java] Re: TclBlend Initialization Mutex Con: Non-thread safe extensions may have problems under Unix. It seems that there are at least two reasons why non-thread safe extensions can have problems in a threaded process like Tcl or JVM. 1. access system level globals Hopefully, this can be fixed by compiling with -D_REENTRANT. 2. access Tcl globals What to do? Right now, I am experimenting with using -D_REENTRANT (but without -DTCL_THREADS) to compile a non-threaded Tcl. The Solaris problem did go away using this special Tcl compilation. But you would need to recompile Tcl and all the extensions with -D_REENTRANT. While I would agree that this is a neat hack, I am not sure it is a good solution. Folks that use a pre-compiled version will not be able to use this. There is lots of history that suggests that core patches are not a good solution (Itcl). We may end up having to do away with pre-compiled versions of Tcl Blend all together, just so that people do not make this mistake. 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
[Tcl Java] Possible patch: JavaGetEnv + threads
I have attached a patch with the rewrite of JavaGetEnv() and
the threads cleanup. I like this approach a lot better
because now there is only one synchronization point,
inside the JavaSetupJava function. I think this will
take care of all of the possible race conditions
during initilization. The old JavaGetEnv method is
now called JavaInitEnv.
Jiang, what do you think? I will check it into the
contract branch if you give me the thumbs up on
this patch.
Mo DeJong
Red Hat Inc
Index: src/native/java.h
===
RCS file: /home/cvs/external/tcljava/src/native/java.h,v
retrieving revision 1.6.2.2
diff -u -r1.6.2.2 java.h
--- java.h 2000/08/07 00:50:09 1.6.2.2
+++ java.h 2000/08/08 07:17:41
@@ -140,7 +140,7 @@
TCLBLEND_EXTERN void JavaAlertNotifier();
TCLBLEND_EXTERN void JavaDisposeNotifier();
-TCLBLEND_EXTERN JNIEnv * JavaGetEnv(Tcl_Interp *interp);
+TCLBLEND_EXTERN JNIEnv * JavaGetEnv();
TCLBLEND_EXTERN Tcl_Interp * JavaGetInterp(JNIEnv *env, jobject interpObj);
TCLBLEND_EXTERN char * JavaGetString(JNIEnv *env, jstring str,
int *lengthPtr);
Index: src/native/javaCmd.c
===
RCS file: /home/cvs/external/tcljava/src/native/javaCmd.c,v
retrieving revision 1.9.2.3
diff -u -r1.9.2.3 javaCmd.c
--- javaCmd.c 2000/08/07 08:50:16 1.9.2.3
+++ javaCmd.c 2000/08/08 07:17:42
@@ -10,7 +10,7 @@
* of this file, and for a DISCLAIMER OF ALL WARRANTIES.
*
*
- * RCS: @(#) $Id: javaCmd.c,v 1.9.2.3 2000/08/07 08:50:16 mo Exp $
+ * RCS: @(#) $Id: javaCmd.c,v 1.9.2.3 2000/08/07 00:50:09 mo Exp $
*/
/*
@@ -46,6 +46,7 @@
#include stdlib.h
#include stdarg.h
#include errno.h
+#include assert.h
/*
* Exported state variables.
@@ -94,6 +95,20 @@
static int initialized_javaVM = 0;
/*
+ * Declare a global mutex to protect the creation and initialization of the
+ * JVM from mutiple threads. This mutex is used in conjunction with the
+ * 'initialized_javaVM' flag. This mutex is used in javaCmd.c as well as
+ * javaInterp.c.
+ *
+ * FIXME: don't want to use the flag TCL_THREADS explicitly. This may be
+ * better if in the future the same TclBlend binary can be made to work with
+ * both threaded and non-threaded Tcl libraries. For now, we will use accessor
+ * functions lockJVMInitMutex() and unlockJVMInitMutex().
+ */
+TCL_DECLARE_MUTEX(javaVM_init_mutex)
+
+
+/*
* The following array contains the class names and jclass pointers for
* all of the classes used by this module. It is used to initialize
* the java structure's jclass slots.
@@ -179,6 +194,7 @@
*/
static int ToString(JNIEnv *env, Tcl_Obj *objPtr, jobject obj);
+static JNIEnv *JavaInitEnv(JNIEnv *env, Tcl_Interp *interp);
/*
*--
@@ -242,24 +258,11 @@
#endif /* TCLBLEND_DEBUG */
/*
- * The first time JavaGetEnv is called, it will create a JVM.
- * Later calls will just attach the current thread to the JVM.
+ * Init the JVM, the JNIEnv pointer, and any global data. Pass a
+ * NULL JNIEnv pointer to indicate Tcl Blend is being loaded from Tcl.
*/
-
-if ((env = JavaGetEnv(interp)) == NULL) {
-
-#ifdef TCLBLEND_DEBUG
-fprintf(stderr, "TCLBLEND_DEBUG: JavaGetEnv returned NULL\n");
-#endif /* TCLBLEND_DEBUG */
-
- return TCL_ERROR;
-}
-/*
- * Make sure the global VM information is properly intialized.
- */
-
-if (JavaSetupJava(env, interp) != TCL_OK) {
+if (JavaSetupJava(NULL, interp) != TCL_OK) {
return TCL_ERROR;
}
@@ -267,6 +270,7 @@
* Allocate a new Interp instance to wrap this interpreter.
*/
+env = JavaGetEnv();
*(Tcl_Interp**)lvalue = interp;
local = (*env)-NewObject(env, java.Interp,
java.interpC, lvalue);
@@ -349,28 +353,59 @@
vm_args.classpath, NULL);
#endif
}
+
/*
*--
*
* JavaGetEnv --
*
- * Retrieve the JNI environment for the current thread.
+ * Retrieve the JNI environment for the current thread. This method
+ * is concurrent safe.
*
* Results:
- * Returns the JNIEnv pointer for the current thread. Returns
- * NULL on error with a message left in the interpreter result.
+ * Returns the JNIEnv pointer for the current thread.
+ * This method must be called after JavaInitEnv has been called.
*
* Side effects:
- * May create or attach to a new JavaVM if this is the first time
- * the JNIEnv is fetched from outside of a Jav
[Tcl Java] Re: Possible patch: JavaGetEnv + threads
On 8 Aug 2000, Jiang Wu wrote:
There seems to be a bug in the patch.
In the beginning of JavaSetupJava(), it has:
if ((env = JavaInitEnv(env, interp)) == NULL) {
goto error;
}
then at error:
error:
...
(*env)-ExceptionClear(env);
return TCL_ERROR;
env can be NULL.
Doh!
Ok, I fixed that. Besides that, do you like the reorg?
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
[Tcl Java] Re: Possible patch: JavaGetEnv + threads
On 8 Aug 2000, Jiang Wu wrote: On Tue, 08 August 2000, Mo DeJong wrote: Ok, I fixed that. Besides that, do you like the reorg? It looks good to me. Let's commit it to the branch. Done and done. 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
[Tcl Java] Re: TclBlend Patch 8/5
On 8 Aug 2000, Jiang Wu wrote: OK. Back to the notifier patch. I am not sure if you got my last email on this subject last night. My mail server wasn't working properly. When I run your example using: java::call AppendEventQueueThread queueVwaitEvent [java::getinterp] update I get: numQueued = 9 numProcessed = 9 This is the desired result because the thread sleeps 1 second, then posts an event, then repeats. The vwait event waits for 10 seconds. So the thread can post a maximum of 9 events during this 10 seconds. Is this what you get also? Nope, I am only seeing 1 event getting processed in that 10 second delay. P.S. I am goign to write up a better test using the test command and a max number of queues in the second thread. 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
[Tcl Java] Re: TclBlend Initialization Mutex
On 8 Aug 2000, Jiang Wu wrote: After spending some hours in gdb tracing the program, it seems that the problem occurs in tclUnixChan.c:FileInputProc() line 380: *errorCodePtr = errno; 1 byte is written to a non-blocking Tcl file channel. Then 1 byte is successfully read from the channel. Then Tcl calls FileInputProc() again to read more. There is no more data in the channel, so the call at tclUnixChan.c, line 376 bytesRead = read(fsPtr-fd, buf, (size_t) toRead); returns -1. However, for some reason, the system variable "errno" is always 0, not EAGAIN as expected by the caller function. This causes the caller function (tclIO.c:GetInput(), line 4865) to loop forever calling FileInputProc() over and over again. I have not determined what caused the problem with "errno". The Tcl library is loaded into a JVM at this point. So the process is running in multi-threaded mode. The Tcl library used is non-threaded, version 8.3.1. Can there be something bad about using "errno" from multiple threads? Under Solaris, errno becomes a function that returns a thread local variable when you compile with -D_REENTRANT. You compiled this version of Tcl with threads support, right? Another strange thing if I run the same Java program on a smaller example, then it seems to work OK. When the error does happen, there are many threads in the process. Sounds like a race condition dealing with ERRNO. I wonder if Tcl is not getting compiled without -D_REENTRANT or something. That seems unlikely. Tcl Blend just uses the CFLAGS set by Tcl. 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
[Tcl Java] Re: TclBlend Initialization Mutex
On Tue, 8 Aug 2000, Jiang Wu wrote: Darn! With problems like this, does it mean that there is no safe way of using a non-threaded Tcl in a JVM because the JVM is threaded by default. The JVM is going to allocate one thread to execute non-threaded Tcl code. Tcl tries to access system globals. JVM also tries to access the same system globals. That does seem like a problem. If we require "special hacks" on Tcl itself, then there is no point in trying to support a pre-compiled version of Tcl Blend that gets loaded into Tcl. Users will just have to download and build a threaded version of Tcl or use our special hacks. A "core patch" seems like a bad idea if you ask me. It sure would make life easier if we just required Tcl threads to use Tcl Blend. The notifier thing would go away because we could count on threads being there. 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
[Tcl Java] JavaGetEnv + Threads = mo going insane
int i;
+/*
+ * Acquire the init lock, we do not care if it is slow to call
+ * JavaSetupJava, it is only called when an Interp is created
+ */
+Tcl_MutexLock(javaVM_init_mutex);
#ifdef TCLBLEND_DEBUG
fprintf(stderr, "TCLBLEND_DEBUG: called JavaSetupJava\n");
#endif /* TCLBLEND_DEBUG */
-
-/* FIXME : we need to put a mutex around this test/set */
if (initialized_javaVM) {
+Tcl_MutexUnlock(javaVM_init_mutex);
return TCL_OK;
}
@@ -858,10 +897,12 @@
JavaObjInit();
initialized_javaVM = 1;
+Tcl_MutexUnlock(javaVM_init_mutex);
return TCL_OK;
error:
(*env)-ExceptionClear(env);
+Tcl_MutexUnlock(javaVM_init_mutex);
return TCL_ERROR;
}
Any comments on this approach? I like it a bit better
than grabbing the lock before calling JavaGetEnv or
JavaSetupJava, the code seems a bit more clean with
the synchronization inside the methods.
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
[Tcl Java] Re: TclBlend Patch 8/5
On 7 Aug 2000, Jiang Wu wrote: On Sun, 06 August 2000, Mo DeJong wrote: If I do 2 vwaits, then a single event is processed from the event loop, but that seems to be all. How did you do 2 vwaits? -- Jiang Wu [EMAIL PROTECTED] Did a vwait in the callback that was added to the queue in Java (see source code). Then did a normal vwait on the command line. 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
[Tcl Java] Re: JavaGetEnv + Threads = mo going insane
On 7 Aug 2000, Jiang Wu wrote: On Mon, 07 August 2000, Mo DeJong wrote: From section 3.2 in blendchanges.txt: load "tclblend", "tcl" .dll or .so (a) call "new Interp()" in Java invoke Java_tcl_lang_Interp_create() C function (b) calls JavaSetupJava() invoke Java_tcl_lang_Interp_init() C function (c) We do need a mutex around the init of tsdPtr-currentEnv and tsdPtr-initialized_currentEnv. These are set the first time JavaGetEnv() is called, but JavaGetEnv() is not called when Tcl Blend is loaded from Java. Unless I am missing something about thread local storage, my understanding is that each thread can only access its own thread local storage. As a result, all access to thread local storage is serialized and it is not possible for two different threads to try to initialize tsdPtr-initialized_currentEnv. Hence, there is no need for synchronization. See item 4.3 in I was thinking that we needed to make the test/set of initialized_currentEnv atomic, but since the var is thread local, that should not matter. My bad. http://www-cs-students.stanford.edu/~jwu/blendchanges.txt 4.3 Calling JavaGetEnv() ... JavaGetEnv() does: a. creates a JVM if one does not exist b. saves the JVM environemnt in thread local storage if it is not saved already c. returns the JVM environment in thread local storage If the interpreter is created from Java using "new tcl.lang.Interp()", the JVM is already setup, but the thread local storage is not. The very first call to JavaGetEnv() will setup the thread local storage and subsequent calls to JavaGetEnv() will simply return the saved environment. In JavaGetEnv(), only step a requires synchronization. Step b and c do not require synchronization because they access the thread local storage. It looks like we might have another problem there. If we call JavaGetEnv() after Tcl Blend has been loaded into Java, the current thread (it is a Java created thread) would have already been attached to the JVM. Would calling env-AttachCurrentThread() do anything bad in this case? Any comments on this approach? I like it a bit better than grabbing the lock before calling JavaGetEnv or JavaSetupJava, the code seems a bit more clean with the synchronization inside the methods. Let's see what is the right logic first. The TclBlend intialization involves three major steps: 1. create JVM (Create JVM will auto-attach the current thread, in fact the current thread becomes the "main" thread) 2. setup and get JNIEnv in thread local storage. (This step also involves attaching the current thread to the JVM, assuming it is not the "main" thread) 3. setup JVM with TclBlend related class/method cache Steps 1, 2, and 3 are required for loading TclBlend into Tcl. Step 3 is required for loading TclBlend into Java. Therefore, synchronization should be placed around 1, 2, and 3 in TclBlend_Init. Synchronization should be placed around 3 in Interp_init. After initialization, only 2 is used. 2 does not require synchronization after initialization. In the case where Tcl Blend is loaded from Java, do we want to set the JNIEnv pointer during the call to JavaSetupJava? That way future calls to JavaGetEnv will not try to attach to the JVM again? tsdPtr-initialized_currentEnv = 1; tsdPtr-currentEnv; This is all getting a little wacky, perhaps we need to split JavaGetEnv up into JavaGetEnv and JavaInitEnv, that might make things more clear. 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
[Tcl Java] Re: TclBlend Patch 8/5
On 7 Aug 2000, Jiang Wu wrote:
On Mon, 07 August 2000, Mo DeJong wrote:
Did a vwait in the callback that was added to the queue
in Java (see source code). Then did a normal vwait on the
command line.
I am going to try your example tonight. Is this what you mean by doing a normal
vwait? Can you send me the exact commands used to produce the problem?
% source ... the Tcl script part of your source code ...
% set x 1
% after 2 {set x 2}
% vwait x
-- Jiang Wu
[EMAIL PROTECTED]
Here is the Tcl code.
package require java
set AQT [java::new AppendEventQueueThread [java::getinterp]]
$AQT start
set orig_numQueued [java::field $AQT numQueued]
java::call AppendEventQueueThread queueVwaitEvent [java::getinterp]
set numQueued [java::field $AQT numQueued]
set numProcessed [java::field $AQT numProcessed]
# Kill this other thread.
java::field $AQT killed 1
puts "orig_numQueued = $orig_numQueued"
puts "numQueued = $numQueued"
puts "numProcessed = $numProcessed"
Here is the Java code:
import tcl.lang.*;
public class AppendEventQueueThread extends Thread {
private Interp interpInOtherThread;
public int numQueued = 0;
public int numProcessed = 0;
public boolean killed = false;
private final boolean debug = true;
public AppendEventQueueThread(Interp i) {
interpInOtherThread = i;
}
public void run() {
if (debug) {
System.out.println("running AppendEventQueueThread");
}
while (! killed) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {}
TclEvent event = new TclEvent() {
public int processEvent (int flags) {
numProcessed++;
return 1;
}
};
// Add the event to the thread safe event queue
interpInOtherThread.getNotifier().queueEvent(event, TCL.QUEUE_TAIL);
numQueued++;
}
if (debug) {
System.out.println("done running AppendEventQueueThread");
}
}
public static void queueVwaitEvent(final Interp interp) {
TclEvent event = new TclEvent() {
public int processEvent (int flags) {
try {
interp.eval("after 1 {set wait 1}", 0);
interp.eval("vwait wait", 0);
} catch (TclException ex) {
ex.printStackTrace();
}
return 1;
}
};
// Add the event to the thread safe event queue
interp.getNotifier().queueEvent(event, TCL.QUEUE_TAIL);
}
}
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
[Tcl Java] Re: TclBlend Patch 8/5
On 7 Aug 2000, Jiang Wu wrote: On Mon, 07 August 2000, Mo DeJong wrote: package require java set AQT [java::new AppendEventQueueThread [java::getinterp]] $AQT start set orig_numQueued [java::field $AQT numQueued] java::call AppendEventQueueThread queueVwaitEvent [java::getinterp] Note: this will NOT block the C Tcl shell because you are just posting an event to be executed later. You have to use 'vwait' or 'update' here to force the event loop to run. The 'java::call AppendEventQueueThread queueVwaitEvent' does that. The point it to call vwait from the Notifier dispatch. 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
[Tcl Java] Re: TclBlend Patch 8/5
On Sun, 6 Aug 2000, Jiang Wu wrote:
This patch should be applied to the
"ajuba-tclblend-contract-2000-08-01-branch".
The patch includes the following:
- fix bugs in tcl.lang.Notifier
I want to check this all in a bit at a time.
You mention the original bug report:
http://www-cs-students.stanford.edu/~jwu/blendchanges.txt
The bug report is at:
http://dev.scriptics.com/ticket/issue-view.tcl?msg_id=4352
Here is the description from your bug report:
3. In the Java class Notifier, a synchronization deadlock
can happen between "serviceEvent()" and "queueEvent()".
If the main thread for the interpreter is executing a
"vwait" inside a "serviceEvent()", it will block any other
thread from calling "queueEvent()" because the two methods
are synchronized on the Notifier instance object.
The "vwait" command will cause the main
thread to wait inside TclBlend native code. As a result, it does not
relinquish the lock on the Notifier instance object. The fix is to
remove the use of the "synchronized" keyword. Instead, use a private
local mutex object to protect the access to the event list inside
the Nofier object. When the code synchronizes on the local mutex
object, never calls another other methods that may block or
uses other mutex. This prevents deadlock.
I need to create a test case for this Notifier
problem before adding the patch, that way I can
be sure that the patch worked and that it will
stay working in the future.
So it seems like I need to create another
thread that tries to queue up event while
the primary interp thread is stuck inside
a vwait. I tried that, but I was not able
to reproduce a problem with deadlocking
in the queueEvent() method.
Here is the example I tried:
import tcl.lang.*;
public class AppendEventQueueThread extends Thread {
private Interp interpInOtherThread;
public int numQueued = 0;
public int numProcessed = 0;
public boolean killed = false;
private final boolean debug = true;
public AppendEventQueueThread(Interp i) {
interpInOtherThread = i;
}
public void run() {
if (debug) {
System.out.println("running AppendEventQueueThread");
}
while (! killed) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {}
TclEvent event = new TclEvent() {
public int processEvent (int flags) {
numProcessed++;
return 1;
}
};
// Add the event to the thread safe event queue
interpInOtherThread.getNotifier().queueEvent(event, TCL.QUEUE_TAIL);
numQueued++;
}
if (debug) {
System.out.println("done running AppendEventQueueThread");
}
}
}
# The Tcl code to set this up.
package require java
set AQT [java::new AppendEventQueueThread [java::getinterp]]
$AQT start
set orig_numQueued [java::field $AQT numQueued]
after 1 "set wait 1"
vwait wait
set numQueued [java::field $AQT numQueued]
set numProcessed [java::field $AQT numProcessed]
# Kill this second thread.
java::field $AQT killed 1
When I ran this example, it did not deadlock in
the Notifier.queueEvent() method. Here is the
output I got:
% set orig_numQueued
0
% set numQueued
9
% set numProcessed
9
This shows that the other thread continued to
run when the main thread was inside a vwait.
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
[Tcl Java] Re: TclBlend Patch 8/5
On Sun, 6 Aug 2000, Jiang Wu wrote:
How are you running your example? Are you starting the JVM first, then load
TclBlend? If not, you are not using "serviceEvent()" when executing
"vwait".
The easy way to reproduce the problems related to the Notifier is to build a
Java based shell, e.g. using the Jacl shell, that uses TclBlend. Start this
shell, then:
cd tcl_source_dir/tests
source all.tcl
Some of the Tcl tests will pass, other will fail. But the test suite should
finish. The bugs in the Notifier will cause deadlock or busy wait.
-- Jiang Wu
[EMAIL PROTECTED]
I need to be able to reproduce this error in regular Tcl Blend.
Your note got me looking at my example again, I was using Tcl + Tcl Blend
without using the Notifier to queue the vwait event. I fixed my
test so that it now detects the deadlock case:
import tcl.lang.*;
public class AppendEventQueueThread extends Thread {
private Interp interpInOtherThread;
public int numQueued = 0;
public int numProcessed = 0;
public boolean killed = false;
private final boolean debug = true;
public AppendEventQueueThread(Interp i) {
interpInOtherThread = i;
}
public void run() {
if (debug) {
System.out.println("running AppendEventQueueThread");
}
while (! killed) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {}
TclEvent event = new TclEvent() {
public int processEvent (int flags) {
numProcessed++;
return 1;
}
};
// Add the event to the thread safe event queue
interpInOtherThread.getNotifier().queueEvent(event, TCL.QUEUE_TAIL);
numQueued++;
}
if (debug) {
System.out.println("done running AppendEventQueueThread");
}
}
public static void queueVwaitEvent(final Interp interp) {
TclEvent event = new TclEvent() {
public int processEvent (int flags) {
try {
interp.eval("after 1 {set wait 1}", 0);
interp.eval("vwait wait", 0);
} catch (TclException ex) {}
return 1;
}
};
// Add the event to the thread safe event queue
interp.getNotifier().queueEvent(event, TCL.QUEUE_TAIL);
}
}
package require java
set AQT [java::new AppendEventQueueThread [java::getinterp]]
$AQT start
set orig_numQueued [java::field $AQT numQueued]
java::call AppendEventQueueThread queueVwaitEvent [java::getinterp]
set numQueued [java::field $AQT numQueued]
set numProcessed [java::field $AQT numProcessed]
# Kill this other thread.
java::field $AQT killed 1
% set orig_numQueued
0
% set numQueued
0
% set numProcessed
0
So, that is good as I can now reproduce the problem.
The new problem is that this bad behavior does not
seem to go away after your Notifier patch.
If I do 2 vwaits, then a single event is
processed from the event loop, but that seems to be all.
Any ideas what might be up with this?
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
[Tcl Java] Re: [Fwd: Next steps to a Jacl interp command.]
I have a couple of questions about your Interp patch.
In Catch.java, your patched version looks like:
result = interp.getResult();
if (argv.length == 3) {
try {
interp.setVar(argv[2], result, 0);
} catch (TclException e) {
throw new TclException(interp,
"couldn't save command result in variable");
}
}
interp.returnCode = TCL.OK;
interp.setResult(TclInteger.newInstance(code));
In the C verison of Tcl, the following appears:
if (objc == 3) {
if (Tcl_ObjSetVar2(interp, varNamePtr, NULL,
Tcl_GetObjResult(interp), 0) == NULL) {
Tcl_ResetResult(interp);
Tcl_AppendToObj(Tcl_GetObjResult(interp),
"couldn't save command result in variable", -1);
return TCL_ERROR;
}
}
/*
* Set the interpreter's object result to an integer object holding the
* integer Tcl_EvalObj result. Note that we don't bother generating a
* string representation. We reset the interpreter's object result
* to an unshared empty object and then set it to be an integer object.
*/
Tcl_ResetResult(interp);
Tcl_SetIntObj(Tcl_GetObjResult(interp), result);
return TCL_OK;
Did you try just calling interp.resetResult() ?
Why not do that instead of interp.returnCode = TCL.OK ?
When I ran the test suite again, I noticed the following
error.
EventAdaptor-11.1 EventAdaptor._return_Object
Contents of test case:
set x [java::new tcl.lang.TesterBean]
set info ""
set errorInfo ""
java::bind $x tcl.lang.Tester1Listener.method_Object {
return [java::new {Integer int} 1234]
}
set msg [list [catch {[$x fire_Object [java::null]] toString} msg]
$msg $err
orInfo]
update
list [lindex $info 0] [lindex $info 2] $msg
Result was:
{unknown java object "java0x4a1"} {unknown java object "java0x4a1"
(attempting to return object from binding)} {1 {invalid command name
"java0x
0"} {invalid command name "java0x0"
while executing
"[$x fire_Object [java::null]] toString"}}
Result should have been:
{} {} {0 1234 {}}
EventAdaptor-11.1 FAILED
(11.2 failed like this too).
I am not sure if this was caused by your inter changes. Could
you double check to make sure nothing you did caused this?
I am too sleepy to do it right now. Once we get these issues
resolved, I can check in your patch, it is kind of large
so I don't want to rush on this one.
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
[Tcl Java] Re: Problem Loading TclBlend
On Tue, 1 Aug 2000, Dan Schenck wrote: All, Hope someone can assist with this. I am having trouble loading tclBlend. I am on Win NT 2000 using Tcl 8.3.1 and JDK 1.2.2. When I do a 'package require java' her is what I get. I think I have all of the debug setting turned on: currently, the PATH environment variable includes these directories: C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\ORANT\BIN C:\jdk1.2.2\jre\bin C:\jdk1.2.2\jre\bin\classic "C:\Program Files\Tcl\lib\tclblend" C:\ATF C:\jdk1.2.2\jre\bin AND C:\jdk1.2.2\jre\bin\classic AND C:\Program Files\Tcl\lib\tclblend on the PATH." "load C:/Program Files/Tcl/lib/tclblend/tclblend.dll" failed: java.lang.UnsatisfiedLinkError: init Your output worries me. Where are Tcl and Java installed on your system? The output your posted seems to indicate that the paths your are using are exactly the same as the example paths, which might just be by chance. This "init" error typically means it can not find a Java shared lib for some reason. 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
[Tcl Java] Tcl/Java reflect table memory usage cut in half.
Hello. I just did a commit of a patch that will reduce the amount of memory needed to reflect Java objects in Tcl. Before this patch, a Java object would require an entry in two hash tables. Now we only require an entry in one. If you are going to reflect a lot of Java objects in a Tcl interp, this fix should cut down the amount of memory your application requires by quite a bit. I don't know how much memory this will save in a "typical application", folks are welcome to report and positive or negative results they get after this change. cheers 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
[Tcl Java] Re: Tcl Call Stack
On Tue, 25 Jul 2000, Yogindra Persaud wrote:
Last email: How do I go about listing off things in a tcl call stack.
What I meant was the following:
I'm building a history tree for an application written in java, that has
an embedded tcl interpreter. Now when the user types something into the
command box, how do I see what the interpreter does behind the scenes.
For example, let's say I had a simple tcl script called "open.tcl", and
all that it had in it was:
proc foo {} { puts "opening file" }
The user will first of all type "source open.tcl" to create the command
"foo". Then the user types "foo" and the string 'opening file' is printed
to the screen.
My history would look something like the following:
source open.tcl
|
- proc foo
foo
|
- opening file
-Any help would be appreciated.
Well, there is a history command in Tcl, you can use that to find the
toplevel commands that the user typed in, but that will not record
what sub commands were called. You might want to look at TclX, it
has a set of "profile" commands that record each call made
and report them to you in an array. That might be your best
bet, but it will only work with Tcl Blend.
http://www.neosoft.com/tclx/
I hope that helps
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
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Multiple Tcl.lang.Interp in a single JVM
On Wed, 26 Jul 2000, Marc Saegesser wrote: Thanks. I'll use Jacl for now and switch to TclBlend when it's ready. If there is anything I can do to help, let me know. The best thing you can do as a "new user" is to keep a detailed log of what problems you run into and what insights you have. For example, if you just can't figure out how to put and event into the event queue, make a note of that. Jot down what docs you looked at and why you are still confused. When you figure the problem out, log that and make sure you write down what info helped you figure out what to do. This is really helpful because later you can look at the log and notice "gee, if there were better docs in that function or an example of X, I would not have been confused". Getting things into an "easy to understand" state is really hard, so we could really use you help on that. Don't be afraid to download the CVS tree and rewrite any documentation you find confusing. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads
On Tue, 25 Jul 2000, Mike Schwartz wrote: Hmm, I just realized that the issue is the Interp.eval code isn't thread safe, so it just needs to run in a single Java thread (not necessarily the Java main thread). So the code I suggested below won't work but you get the idea -- have the code sanity check the call and not silently allow someone to stumble on a known limitation in the code... thanks - Mike It is not a "known limitation". The fact that most of the methods in the interp class are not thread safe is by design. The thread safe event queue is the way to go. I am open to suggestions as to how we could help people to not make this mistake in the future. I think better documentation is the best approach, but writing docs is boring so folks do not seem to want to help with that. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from within Java threads
On Tue, 25 Jul 2000, Mike Schwartz wrote: Well, this is a matter of personal taste I suppose, but in my view making non-threadsafe code in this day-and-age, especially code that is intended to interoperate with a language (Java) that is designed to make it easy to build threaded apps, is problematic. Asking programmers to build event queues to avoid the problem seems like not a great solution, because (a) it represents a language non-orthogonality gotcha, and (b) it makes it more work for programmers to accomplish what they want. Tcl/Java is thread safe, it just does not synchronize on calls to Interp.eval(). This is a very good thing, even if it does not seem that way at first. When you first start playing with threads, it seems easy, just put a synchronized on every method and presto, thread safe code. Unfortunately, in the real world it does not really work that way. You can still end up with deadlocks and your code runs dog slow because of too much synchronization. Just take a look at the AWT for a great example of over-synchronization and deadlock prone code. Java has some nice synchronization primitives, but they are not a silver bullet. Tcl's use of event queues is the right way to do synchronization in a complex event based application, it is a bit more complex but it is worth it in the long run. Just look at how Sun fixed APIs in newer versions of Java, in many cases they removed synchronized blocks of code and basically said "it is up to you to be thread safe". I think if it's going to be non-thread safe then the code should sanity check for thread-crossing calls, perhaps with #ifdef's so performance concerns can be removed for people who don't want the sanity checks. I like this approach, but the problem is that there is no way to easily turn code on and off automatically (ala #ifdef) in Java. You can use final booleans to get the same behavior, but folks would need to go in and turn these extra checks on, so that kind of defeats the purpose. 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
[Tcl Java] Re: [Tcl Java] Multiple Tcl.lang.Interp in a single JVM
On Tue, 25 Jul 2000, Marc Saegesser wrote: I just noticed in Jiang Wu's excellent "Embedding a Tcl Interpretter in Java" article (http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html) the following paragraph in the "Other Issues" section: TclBlend 1.2 does not support multiple Tcl interpreters in a Java program. Do not try to create multiple "tcl.lang.Interp" instances. Future version of TclBlend may support multiple Tcl interpreters in multiple threads. In TclBlend, it is safe to create slave interpreters within the master interpreter as one could in any single threaded Tcl program. Is this still the case? I had hoped to create a pool of threads, each running a separate Tcl interpreter. A pool manager class would manage this collection of interpreters to create new ones when the pool gets low, harvest idle ones when the pool gets large. All of these threads would be running inside a single JVM inside a servlet engine. In response to HTTP requests, servlets could request an idle interpetter from the pool and ask it to run a script. There may be several scripts active any given time and the scripts may block for relatively long periods. There is no need for scripts executing in separate interpretters to communicate or even know about each other. The current Tcl Blend code does not work with multiple Tcl threads. There is a plan in place to remedy this situation, but we will not be able to post the details until the end of the week. If the paragraph quoted above still applies, then it looks like this approach won't work. What if I switched to the Jacl intead of TclBlend? Could I use Jacl to create mulitple Tcl interpretters on separate threads inside a single JVM? You can always prototype the system in Jacl and move to Tcl Blend when the thread work is finished. Jacl does threads a lot better than Tcl Blend, at least for now. You should not have to rewrite anything, both Jacl and Tcl Blend support the same Tcl/Java API. 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
[Tcl Java] Re: [Tcl Java] Test suites using Jacl
Rajeev, you are posting in HTML. That is not allowed on this list. Please disable HTML posting in your email client before posting again. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] calling Tcl from Java (starting Java first)
On Fri, 21 Jul 2000, Mike Schwartz wrote: Hi, I decided to give the patch Mo mentioned below a try. It works when I try it with Java executing some simple Tcl commands, but now I'm trying to use it with some pretty complex Tcl packages, and I get a tcl.lang.TclException that says: couldn't load file "/iw/tcl/current/lib/TclExpat-1.1/tclexpat.so": ld.so.1: /usr/java/bin/../bin/sparc/native_threads/java: fatal: relocation error: file /iw/tcl/current/lib/TclExpat-1.1/tclexpat.so: symbol Tcl_GetStringFromObj: referenced symbol not found Yikes. That is really odd. You might be running into some goofy junk related to how the JVM loads shared libs and how Tcl loads shared libs. For instance, you need to load libtclblend.so in Tcl and in Java (with System.loadLibrary()), but I do not know if that matters. Tcl_GetStringFromObj is a procedure defined in Tcl (in generic/tclObj.c), so somehow when I have Java invoke the Tcl interpreter it's not finding this routine. I thought it might be a problem with my LD_LIBRARY_PATH causing it to load a version of Tcl that doesn't define this routine, but I truss'd the Java process and found that the version of the library that it's opening is /iw/tcl/current/lib/libtcl8.3g.so, and then I did the following: % nm -og /iw/tcl/current/lib/libtcl8.3g.so | fgrep Tcl_GetStringFromObj [2873] |02275540|0300|FUNC |GLOB |0|8 |Tcl_GetStringFromObj Is there any chance that tclexpat.so is linked to another Tcl shared lib? Try running: % ldd tclexpat.so and see if that says something about libtcl8.3g.so in the link dep line. So, it seems the function *is* defined in the .so file it's accessing. Any ideas what might be going on, or how I might try to debug it? You might also want to try building tclexpat.so with stubs support. That might work a little better. 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
[Tcl Java] Re: [Tcl Java] calling Tcl from Java (starting Java first)
Does tclBlend require that Tcl be the first to start? If that's not the problem, does anyone know what the problem is? My LD_LIBRARY_PATH contains /usr/local/lib/tcljava1.3.0, which is where my libtclblend.so lives. That is something that should work, but it is rather new and untested and you will need the patch described in this post. http://www.mail-archive.com/tcljava@scriptics.com/msg00771.html There is also another set of patches written by Jiang Wu that fixes problems with deadlocks in the event queue. There is also an alternative impl of the patch I posted above. The problems you describe sound like your env vars are not set correctly. Try running "make shell" and then invoke "java ..." from inside the shell, that should set up the env vars correctly. later 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
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] tclBlend / tcl thread workaround
... A post written in HTML ... Please do not post to the tcljava list in HTML. People will text email clients can not read what you are posting! 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
[Tcl Java] Re: [Tcl Java] RFC: changing the package name from java to tcljava?
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 Tcl, since as a Tcl-script writer I know that I'm working with Tcl. (If Tom P. had asked me, OraTcl would be called Oracle, or at least the package command would go "package require oracle") I don't know about that. If someone wanted to load IncrTcl, I don't think "package require Incr" would be the first thing they would think of. I think this will make things easier to explain because we will not have this extra "The Java package" thing to explain. But there would be "The TclJava package" thing, wouldn't it? tcljava.jar - The home of the "tcljava" package jacl.jar - The code that implements Jacl. tclblend.jar tclblend.so - The code that implements Tcl Blend. You would have to change "package require java" to "package require tcljava", but I don't think that is too big a deal. Right, it would be no big deal, but I can't see the real benefits... I am not saying it would save the world, I just think it would make it easier to explain the "shared code" that is used by both Jacl and Tcl Blend. This has always been hard to explain to new users. 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
[Tcl Java] Re: [Tcl Java] clock command in Jacl: Now 8.3 compliant
On Thu, 13 Jul 2000, Christian Krone wrote: To fight my frustation I made some changes to the ClockCmd class, so that the Jacl clock now is capable of all the new 8.3 formats. Even the stardate format is implemented! Enjoy, Krischan I just did a CVS commit of these patches. Krischan, you really should post a note to comp.lang.tcl about the new stardate support in Jacl. I am sure there are lots of people that are holding off using Jacl because of the lack of startdate support :) 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
[Tcl Java] Re: [Tcl Java] problems using tclBlend with Tcl threading
372 if (Tcl_IsSafe(target)) {
- 373 if (pkgPtr-safeInitProc != NULL) {
- 374 code = (*pkgPtr-safeInitProc)(target);
- 375 } else {
- 376 Tcl_AppendResult(interp,
377 "can't use package in a safe
interpreter: ",
378 "no ", pkgPtr-packageName,
"_SafeInit procedure",
379 (char *) NULL);
- 380 code = TCL_ERROR;
- 381 goto done;
382 }
- 383 } else {
- 384 code = (*pkgPtr-initProc)(target);
385 }
It seems to want to call Tcl_PakcageInitProc. Does anyone
have any ideas on this one?
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
[Tcl Java] Does Tcl Blend need to build with a shared Tcl?
I was just trying to build Tcl Blend when I got this error: % /home/mo/project/tcljava/configure --prefix=/home/mo/project/install/tcljava --with-tcl=/home/mo/project/build/tcl srcdir is /home/mo/project/tcljava configuring for both jacl and tclblend checking for Tcl build in /home/mo/project/build/tcl configure: error: Tcl was not built correctly. Make sure Tcl was configured with --enable-shared. That check has been in there since version 1.0, but I can't say I know exactly why. Can anyone think of a reason that Tcl Blend can not be loaded into a statically compiled build of Tcl? As long as Tcl is built with support for the load command, I don't think it would be a problem. Of course, you would not be able to load Tcl + Tcl Blend into a JVM if it was not build as a shared library, but that is fine. 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
[Tcl Java] RE: [Tcl Java] Does Tcl Blend need to build with a shared Tcl?
On Thu, 13 Jul 2000, Scott Redman wrote: If TclBlend was built with Tcl stubs, then it would work fine. Otherwise, TclBlend needs to be linked against a dynamic build of Tcl and a dynamic JVM. The code in blend will do a LoadLibrary of itself, so TclBlend needs to be dynamic as well... Yeah, but Tcl still has that load stuff, I though it would only be dis-allowed if you passed --disable-load to configure. I tested it out with a static version of Tcl and it seemed to be able to load libtclblend.so just fine. Is that something that would break under windows? Let's make it stubs-aware. David Gravereaux sent out an email to the TEA mailing list about a mechanism that would allow TclBlend to find the Tcl DLLs and load the stub table (when loading blend from the JVM). Sounds good. Could you repost that email to this list. Better yet, a patch to implement Davids approach. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Small test case
On Thu, 29 Jun 2000, Dr Wes Munsil wrote: Mo DeJong wrote: There is no "compile time" in Tcl, it is all dynamic, ... Exactly my point. Consider these two code snippets, which I assume you agree are correct uses of newInstance(): B x = new C (); ReflectObject.newInstance (interp, B.class, x); C x = new C (); ReflectObject.newInstance (interp, C.class, x); The _exact same reference value_ is passed to newInstance() as its third argument, in each snippet. The only factor that determines the second argument is the type (not class) of x, which is a purely compile-time Java notion. It is surprising to me that this compile-time Java notion should find its way into the dynamic semantics of Tcl--but I accept that you probably have legitimate reasons for doing that. The same object is passed as the third argument, but two different entries in the reflect table are created. One for x referenced as type B and one for x referenced as type C. The semantics you describe is how Tcl/Java worked in version 1.0. It "seemed" to work most of the time, but there would be these edge cases that would break working code. The design problem was not easy to correct, it took a long time and required introducing a lot of new code (like the java::cast command). But--because each snippet is passing the same reference value to newInstance(), and because newInstance() has no way of knowing how x was actually declared in the Java program text, it still seems to me that either form could be used, AS LONG AS THE USAGE IS CONSISTENT, and TclBlend would be happy. In other words, if x is _always_ referred to as a C, and _never_ as a B, no harm should result. And the second form is equivalent to C x = new C (); ReflectObject.newInstance (interp, x.getClass (), x); It depends on how you define "no harm". You will always be able to come up with a specific example where nothing goes wrong, but that does not mean it should be done that way in general. As soon as you can access functions in the subclass C that would not have been accessible from type B, you increase the chances that something could ge really wrong. For example, this snippet of code: String s = "Foo"; ReflectObject.newInstance (interp, s.getClass(), s); Since java.lang.String is a final class there is no way it could have a subclass, so in this one case nothing would go wrong. This does not generalize out to all classes. Also, don't forget that calling getClass() means that you are unable to use interface types. 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
[Tcl Java] Re: [Tcl Java] Threading in tclblend.
On Thu, 29 Jun 2000, Daniel Wickstrom wrote:
I've been experimenting with integrating tclblend into aolserver, and
after looking at the tclblend code, I'm a little puzzled about
something. In javaCmd.c the variable java declared as type JavaInfo
and currentEnv are declared as global variables, yet I would think
that these two variables would be overwritten each time a new thread
starts up. Am I missing something? I've noticed using of java locks
throughout the code. Maybe only one thread can be executing c-code at
any given time? Any insights would be appreciated.
This is an area of ongoing discussion. Check out the online mainling
list archive for the history.
http://www.mail-archive.com/tcljava@scriptics.com/
The startup stuff is kind of tricky because we need to support
two different kinds of loading. Tcl Blend can be loaded from
Tcl, whick will then load the JVM. Tcl Blend can also be loaded
from a JVM, this means Tcl Blend will also need to load up Tcl.
In the case where Tcl Blend is loaded into Tcl, the JavaGetEnv()
method is called and this bit of code is executed.
if (currentEnv != NULL) {
return currentEnv;
}
That should only let you init the global once (minus any
race conditions, which I will cover in a second).
In the case where Tcl and Tcl Blend are loaded into a JVM,
Java_tcl_lang_Interp_create() is the first native method
that gets called.
Java_tcl_lang_Interp_create(
JNIEnv *env,/* Java environment. */
jobject interpObj) /* Handle to Interp object. */
{
jlong lvalue;
Tcl_Interp *interp;
JNIEnv *oldEnv;
int loadedFromJava = (currentEnv == NULL); /* true if Tcl Blend was
loaded into Java */
if (! loadedFromJava) {
PUSH_JAVA_ENV();
}
interp = Tcl_CreateInterp();
if (JavaSetupJava(env, interp) != TCL_OK) {
jclass err = (*env)-FindClass(env, "tcl/lang/TclRuntimeError");
In this case we don't do a Java lock (because that monitor
has not been init'ed yet), and we call JavaSetupJava().
Inside JavaSetupJava() we have some code like this:
if (initialized) {
return TCL_OK;
}
// Setup from inside a JVM
initialized = 1;
return TCL_OK;
So, the globals "initialized" and "currentEnv" should
only get init'ed once. That should work in almost
every case, but we still have some race conditions
to work out. For example, in the unlikely case that
two Interp() objects were created at the exact same
time, one might be half way into the init when
the second one noticed an init had not been done
and started another one.
The unresolved question about the race conditions is
how you are going to do the lock the resource. In the
case where Tcl Blend is loaded into Tcl, you need to
init the JVM before you can use a JVM monitor through
JNI. In the case where Tcl Blend and Tcl are loaded
into a JVM, you could use a Java monitor to do the lock.
The tricky part is how Tcl is compiled. If Tcl is compiled
with threads support enabled, then you could use a Tcl
mutex to protect the resources. Problem is, some people
might not want to use the thread enabled version of Tcl.
I am kind of leaning towards requiring the thread
enabled version of Tcl for Tcl Blend because I think
going for a simple solution and avoiding using JNI when
we can is a very good thing.
We would certainly welcome any suggestions or insights
you might have on the subject. I hope that we can
get all these threading issues ironed out in the next
3-4 weeks so that we can cut a 1.3.0 release of
Jacl and Tcl Blend for people to bang on.
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
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Small test case
On Thu, 29 Jun 2000, Thomas McKay wrote: But let's assume that I do indeed want the most derived class. Seems kind of dangerous, but Ok. If I change this.getClass() to DbObj.getClass(), then the Tcl objects returned from this method will only have DbObj's methods and fields exposed, right? Right. This is, however, a utility method and I don't want to force every single object that will eventually be added to the system to copy this code simply to replace the "DbObj.getClass()" with "ExtendedDbObj.getClass()". I *want* ExtendedDbObj's (and all other classes' derived from DbObj) methods and fields exposed. Yes, even in the case of C - D - E - F - G. Now, given that... what is fatal about this.getClass()? If it simply the case that the user would have to explicitly use a method signature for java::call, that's fine with me. If it means that their extension might break my Tcl code, I see your point and agree... but is it programatically *fatal*. Well, no there is nothing fatal about it, it just means your code could be broken by someone extending one of your classes in a way you did not expect. Let's say that I do change this.getClass() to DbObj.getClass(). Would this mean that % set obj [some-func-to-get-an-extended-object] java0x8a % $obj someExtendedFunc would change to % set obj [some-func-to-get-an-extended-object] java0x8a % set eobj [java::cast ExtendedDbObj $obj] % $eobj someExtendedFunc The java::cast call would do the same thing as passing ExtendedDbObj.class to ReflectObject.newInstance(). It is not exactly the same because in the case of a cast you know the name of the class you expect it to be. You do not know what getClass() will return unless you make your class final so that it can not be extended. If that's the case, I agree with you completely that from a long-term perspective it would be better for me to call DbObj.getClass(). Hmmm sounds like I've convinced myself you're right. You might be able to come up with a case where getClass() does what you want, but if everyone called getClass() everywhere without realizing how it could hose things up, that would be bad. 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
[Tcl Java] Serious Tcl/Java error, need help testing JVMs
Now don't panic, but it looks like we have uncovered a serious JVM bug in Sun derived JVMs = 1.2 that nukes the Tcl/Java reflect table. Lots of thanks go to Thomas McKay for tracking down and creating a test case for this bug (it took months). It looks like two different Java object are returning the exact same "unique id" from System.identityHashCode(). (this has nothing to do with the getClass() discussion that has been going on, so don't worry about that) I have been able to reproduce this error running IBM 1.3 on Linux, and I hear that it also happens with Sun JDK 1.2 under Windows. Could everyone please download and run the example code that is attached to this file? Just unzip the file (use jar if you don't have unzip) and source the mytest.tcl file. This problem should happen in either Jacl or Tcl Blend. If you get a fatal exception, please report what JVM version you are using and on what system. Don't worry about the details that are printed out, this problem can only be caused by one thing. (it should look like this) Exception in thread "main" tcl.lang.TclRuntimeError: (find) table entry "SomeObject.1512497281" mapped to an invalid entry, ... I tested this under JDK 1.1.8 from Blackdown and Kaffe and there was no problem with either of those JVMs (I ran the test for several hours). thanks Mo DeJong Red Hat Inc ReflectCrash.zip
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend pr oblem?
On Thu, 29 Jun 2000, Jiang Wu wrote: I just hope people realize that the reflected Java objects in Tcl are not the same as any other Tcl objects. The problem is that these reflected objects are presented as "normal Tcl objects". They are syntactically compatible with other Tcl objects. As a result, they are being used in the same way as other "normal Tcl objects". But the behavior of these are not "normal" leading to these seemingly unexplainable bugs. If you can explain the similarities and differences between the following three lines of code, then you see what I trying to say. The three lines are syntactically identical. Care to submit some docs patches? We could also use some "Tcl/Java in action" examples. Nice little examples that do something cool and show how to use the java::* commands would really be great. Would anyone be able to help with that? That is not the same thing. A file handle must be closed with the close command. The close command is like a destructor for an object. Java objects have no destructor, so there is no functional mapping. I don't think it matters if Java has destructor or not. It does matter whether the "Java object representation in Tcl" should have destructor. I was saying that there is no mapping from "close" to a Java operation (like a destructor). A file handle in Tcl is just a hash table mapping from the string name to the file descriptor. A "reflect object" in Tcl is just a hash table mapping from the string name to the "Java object". The difference is that file handle requires a manual "close", but reflect objects can auto destruct at inopportune times. Well, you can always use your own "lock and unlock" on top of the existing reflection system. In fact, that is exactly what the java::lock and java::unlock commands are for. The only reason they were added was because of this exact problem. I think we need to change Tcl to support "locked down" internal reps to really fix this. Everything else is just a work around. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Small test case
On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
Mo DeJong wrote:
Objects do not have types, references to objects determine what behavior
the object will provide. In Tcl/Java you don't really have a reference
but you "reflect" an object as a type. You need to pass in the
java.lang.Class object that a given java.lang.Object will be reflected
as, and it needs to be the correct class (which is not always the same
as the one returned by Object.getClass() ).
In general, what is "the correct class?"
In particular, what is the correct class in my example:
Object o = v.elementAt (i);
... ReflectObject.newInstance (interp, ???, o) ...
It depends on what you are doing. In regular Java, you need to know
what the type of the objects you put into a vector are because
you need to cast them back up to something when you pull them
out of the vector. TclJava is no different, you just put the
class you would cast to as the argument to newInstance().
I thought the docs were clear, but it sounds like they will need some
work. Would you like to help? I have tried writing them a couple
of times but it seems like the message is still not getting through.
...
2. If you call getClass() it will always return the most derived
type, this is wrong is many many ways. It can lead to problems
with method invocation and it will let you call methods that
would not be accessable in regular Java.
I would love to help, as soon as I understand what's going on. Could you provide a
small test case that erroneously uses getClass() and illustrates the problems that
can arise?
There is one in the documentaiton for ReflectObject.
http://dev.scriptics.com/man/java1.2.6/TclJavaLib/ReflectObject.htm
Note how the example class would be reflected as the wrong type.
Here is another example:
import java.util.Hashtable;
public class Hashtable2 extends Hashtable
{
public static Hashtable get() {
return new Hashtable2();
}
public void NEVER_CALL() {
System.out.println("NEVER_CALL");
}
}
% set h [java::call Hashtable2 get]
( Here is what would happen if you called getClass() )
% java::info class $h
Hashtable2
This means you would be able to invoke "$h NEVER_CALL"
which is not possible from regular Java code.
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
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend pr oblem?
On Wed, 28 Jun 2000, Jiang Wu wrote: But the script does work under Tcl 8.3.1. I need to point out that my 2nd script is NOT a "workaround". It is not a workaround because you can't convert all callback scripts into this list form; it is not the normal way of writing Tcl; and you can't change other people's code this way. It is there to demonstrate a more fundamental problem: "Java objects in Tcl should be treated as global system resources like file handles (explicit create/remove) rather than other normal Tcl objects (implicit create/duplicate/remove)." Well, if you really wanted a workaround, you could always unset the variable in the after command :) The real issue here is that Tcl does not have any support for a "locking down" the internal rep of an object. There is no "general" way to fix this problem because to really fix it Tcl would need to be extended so that it supported another sort of internal rep that could not be disposed of. I talked with Paul Duffin about this sort of thing at the last Tcl conference. He is doing something similar called "feather". It is an interesting area, but I have not had much time to spend on it lately. 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
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] preserve/release or use GC
A different solution is needed. What about never returning any CObjects in TclBlend? Methods such as interp.setVar, interp.getVar, interp.getResult still returns TclObject, but the resulting TclObject would not contain CObject as the internal rep. For example, any Tcl_Obj can be converted into a TclString representation. Then the TclString is returned inside a TclObject. TclString can be safely GC'ed because it has no link to any Tcl C data structures. Now there is an interesting idea. Check out the attached screen shot, the only place where CObject is actually extended is in the TclList class. I guess this was done so that a Tcl List would not need to get converted to a Java Vector if it was to be used from Java code. Are TclList internal reps the only area where we have a problem? I think that is the case but I am not sure. Mo DeJong Red Hat Inc tcllist.png
[Tcl Java] Re: [Tcl Java] preserve/release or use GC
Something has been bothering me about this ref counting stuff for
some time. It just seems like the TclJava ref counting does not
work like regular Tcl ref counting, but I could not put my
finger on exactly why.
I was just looking at the C code, and I noticed that "regular"
Tcl ref counts start at 1 while Tcl/Java ref counts start at 0.
(from tclBasic.c)
cmdPtr = (Command *) ckalloc(sizeof(Command));
Tcl_SetHashValue(hPtr, cmdPtr);
cmdPtr-hPtr = hPtr;
cmdPtr-nsPtr = nsPtr;
cmdPtr-refCount = 1;
cmdPtr-cmdEpoch = 0;
(from TclObject.java)
protected TclObject(TclString rep, String s) {
internalRep = rep;
stringRep = s;
refCount = 0;
}
Seems like that might be the cause of some big problems.
I think this was something that was changed in Tcl sometime
after Tcl 8.0.
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
[Tcl Java] Re: [Tcl Java] Access to public baseclass data members via Jacl
On Fri, 23 Jun 2000, Frank Krahmer wrote:
Dear Sir,
how can I access a public baseclass attribute in a Java class via Jacl,
when an object of derived class is instanciated ?
Java-class example :
public class baseClass
{ public String dummyAttribute;
}
public class derivedClass extends baseClass
{ // anything
}
Jacl-access example :
-
set theDerivedObj [java::new derivedClass]
java::field $theDerivedObj dummyAttribute "blabla" // RUNTIME ERROR
// brings error tcl.lang.TclException: field "name" doesn't exist
I did a detailed analysis of this problem, and it looks
like it is going to be very hard to solve properly. This
is basically the same problem that is solved by the
runtime method resolver I added to tcljava.
When you start walking up the inheritance tree looking
for fields that match, you also have to watch out for
all the strange edge cases like ambiguous field
signatures caused by an interface that also defines
a field with the same name and so on.
In the mean time, I have included a "quick and dirty"
patch that will make your test case work. This patch
actually breaks a couple of other things in the
test suite so it is not going to be checked in, but
you can use it on your own tree. The "real" fix
is going to take some time to implement, and I
am not going to be able to get to it for at least
a month.
Mo DeJong
Red Hat Inc
Index: src/tcljava/tcl/lang/FieldSig.java
===
RCS file: /home/cvs/external/tcljava/src/tcljava/tcl/lang/FieldSig.java,v
retrieving revision 1.2
diff -u -r1.2 FieldSig.java
--- FieldSig.java 1999/05/09 21:19:41 1.2
+++ FieldSig.java 2000/06/23 21:47:35
@@ -157,7 +157,7 @@
}
try {
- field = sigCls.getDeclaredField(fieldName);
+ field = sigCls.getField(fieldName);
} catch (NoSuchFieldException e) {
throw new TclException(interp, "field \"" + signature +
"\" doesn't exist");
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
[Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
...
I am encountering this problem right now in a different form. I am
constructing an asynchronous callback function inside Java using a TclList
object, {command_name java_obj_1 java_obj_2}. The list contains some Java
objects, which are the arguments to the callback function. However, when
the callback function is invoked, the function is getting the string
representation of the argument rather than the real Java objects. This is
not good because you can't easily find your Java object given a string
representation.
You mentioned that doing an after with a list object solved the problem,
but here you are using a TclList so it should incr the ref counts of
the objects in the list. Seems like that should work, I guess I
do not understand why your method arguments would be getting converted
to strings instead of TclObjects. Is this something that Interp.eval()
is doing?
I wonder if similar problem happens in the C world. But a C object can
always use a pointer address as its string representation. Then, given the
string representation, a valid C object can be found.
The problem is the mixing of GC and a type that can not be converted to
a string. You can not convert a Java reference into a string because
the GC system does not see that as a valid reference. You could convert
a C pointer into a string and then back to a pointer but you would
need to manage that memory on your own. In fact, Tcl Blend does this
sort of thing behind the scenes, it stores a C pointer inside a Java
long. It then converts this back to a pointer that is uses to find
the actual object (yes it is scary and wrong, but JNI sucks so we
are stuck with it).
Also, that convert a pointer to a string and back again trick
would not work if you were using a GC for your C code.
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
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] another deadlock
On Mon, 19 Jun 2000, Jiang Wu wrote: Would the GC problem still exist if the underlining Tcl is thread enabled? In other words, is it OK to call "FreeTclObject()" from any thread in the thread enabled Tcl? It may not be a good idea to block the GC thread. For this scheme to work, one needs to make some assumption about how the GC works, which may not apply to the various implementation of the JVM. I like the other approach. Tcl/TclBlend should clean up its own data in a Tcl safe manner. This probably means that the user of TclBlend needs to explicitly free Tcl objects using "TclObject.preserve()" and "TclObject.release()". Tcl Blend users should be doing this already. Then, when the Java GC is invoked to clean up the associated Java object, the GC need not access any Tcl stuff. Though, I am not sure about automatically creating a list of objects to be finalized. Perhaps if we let the GC thread access only 1 "Tcl thing", then we can make that single function thread safe so that both the GC thread and Tcl can call it at any time. This function could keep a linked list of Tcl internal reps that would need to be freed by Tcl. Of course, this means we would need a thread enabled Tcl. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] another deadlock
On Mon, 19 Jun 2000, Jeff Sturm wrote: Mo DeJong wrote: I think this one is along the same lines. The finalizer thread seems to be called decrRefCount() which is calling FreeTclObject(). I think we need a more general solution to the problem of the finalizer thread walking into an interp at some random time. My understanding of 1.1 finalizers is that calling anything that can allocate objects as a side effect is a very bad idea, since finalizers are often invoked in the first place because memory is exhausted. Yeah, you are right. Doing anything Java related in a finalizer is a bad idea. Also synchronization or anything that can cause the finalizer thread to block should be avoided if possible. Agreed, blocking the GC thread is so dangerous, we need to avoid this at all costs. Can we create a queue of objects that have been finalized? We could then clear this queue in a Tcl "after idle" call. Possibly. The concurrency is a little tricky to solve... you never know when finalization will be called or from what thread. It might be doable with `volatile' variables, but unfortunately volatile is not yet implemented in Sun's VM... that's a long story in its own right. I am not sure what volatile has to do with anything. I was under the impression those were for serialization. Should be make the gc thread block until a given Tcl event has finished? This would need to be done by adding an event to the Tcl event queue and then letting the GC thread go when Tcl was ready to process the event. Blocking a finalizer on 1.1 could be fatal... see above. Finalizers are evil, period. These are times I wish the Tcl core had garbage collection... not that I wish to start that thread (again)... but if it did, the finalizers could go away. GC in the Tcl core would be really cool. Lets face it, all those incr and decr ref counts are hard to use. If you forget one, BLAMO! You code dies and you need to go figure out where things got hosed. Lets focus on how we can implement a thread safe JNI method that will store a list of Tcl internal reps that need to be freed by the Tcl interp. We need to do this in such a way that all Java refs for that object are dropped from the Tcl side without calling any other JNI or Tcl methods. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] another deadlock
On Mon, 19 Jun 2000, Jeff Sturm wrote: Mo DeJong wrote: What is a "thin lock"? Did you mean spin lock? I don't see what is wrong with a good old mutex, but putting one in means we would need to require a thread safe version of Tcl. I don't really like the "use the JVM to do locking" hacks in there now. Using the JVM to do locking in a JVM finalizer seems like a really bad idea. Thin locks are usually performed in user space, i.e. without help from the OS kernel. Spin locks are an example. A mutex might work, but isn't really portable either... depends on the OS. Ahh, but Tcl provides a portable locking layer when compiled with threads support. That is what I am sugesting we use for the mutex. If we require Tcl thread support, we can get rid of the Java monitor used in JAVA_LOCK. Anything to avoid calling a JNI method is a plus in my book. 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
[Tcl Java] New patch for loading of TclBlend from Java
Hi all.
I have a new patch that adds support for loading of
TclBlend into a Java, it is a little less complex
than the solution Jiang proposed.
Here is the source file I am using.
% cat LoadTclBlend.java
import tcl.lang.*;
public class LoadTclBlend {
public static void main(String[] args) throws Exception {
Interp i = new Interp();
i.setVar("i", "1", 0);
i.eval("puts \"i is $i\"");
i.eval("package require java");
i.eval("set str [java::new String \"I am a Java String\"]");
i.eval("puts [$str toString]");
}
}
Here are the results with IBM JDK 1.3.
% java LoadTclBlend
i is 1
I am a Java String
Here is the patch I used:
Index: src/native/java.h
===
RCS file: /home/cvs/external/tcljava/src/native/java.h,v
retrieving revision 1.6
diff -u -r1.6 java.h
--- java.h 2000/06/15 09:47:06 1.6
+++ java.h 2000/06/15 13:37:18
@@ -133,7 +133,9 @@
jmethodID invokeTimer;
} JavaInfo;
+/* These are defined in javaCmd.c */
extern JavaInfo java;
+extern JNIEnv *currentEnv;
/*
* The following macros are used to enter and leave the global
Index: src/native/javaCmd.c
===
RCS file: /home/cvs/external/tcljava/src/native/javaCmd.c,v
retrieving revision 1.9
diff -u -r1.9 javaCmd.c
--- javaCmd.c 2000/06/15 09:47:06 1.9
+++ javaCmd.c 2000/06/15 13:37:18
@@ -62,7 +62,7 @@
* will contain the environment for the default thread.
*/
-static JNIEnv *currentEnv = NULL; /* JNI pointer for current thread. */
+JNIEnv *currentEnv = NULL; /* JNI pointer for current thread. */
/*
* The following variable contains the pointer to the current Java VM,
Index: src/native/javaInterp.c
===
RCS file: /home/cvs/external/tcljava/src/native/javaInterp.c,v
retrieving revision 1.6
diff -u -r1.6 javaInterp.c
--- javaInterp.c2000/06/15 09:47:07 1.6
+++ javaInterp.c2000/06/15 13:37:19
@@ -101,8 +101,11 @@
jlong lvalue;
Tcl_Interp *interp;
JNIEnv *oldEnv;
+int loadedFromJava = (currentEnv == NULL); /* true if Tcl Blend was
loaded into Java */
-PUSH_JAVA_ENV();
+if (! loadedFromJava) {
+PUSH_JAVA_ENV();
+}
interp = Tcl_CreateInterp();
if (JavaSetupJava(env, interp) != TCL_OK) {
@@ -116,7 +119,9 @@
*(Tcl_Interp**)lvalue = interp;
}
-POP_JAVA_ENV();
+if (! loadedFromJava) {
+POP_JAVA_ENV();
+}
return lvalue;
}
What do you think? We still need to solve some other deadlocking
problems, but at least it loads without a SIGSEGV now :)
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
[Tcl Java] Re: [Tcl Java] problem with creating a thread
class MyTclEvent extends TclEvent {
private Interp mInterp = null;
public MyTclEvent (Interp interp) {
}
public int processEvent (int flags) {
try {
hello(mIterp);
} catch (TclException e) {
e.printStackTrace();
}
return 1;
}
public void hello (Interp interp)
throws TclException
{
interp.eval("draw line");
interp.eval("puts {Hello, World}");
}
A quick glance at your code seems to indicate the you
never set interp (aka mInterp) to anything. I am
willing to bet that you put that "mInterp = null"
just to avoid a compiler warning.
Just save the value:
public MyTclEvent (Interp interp) {
mInterp = interp;
}
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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem with creating a thread
On Thu, 15 Jun 2000, Zhumei Wang wrote: Thanks Mo. You are right. But actually I have "mInterp = interp" in my program. When I sent you the mail somehow I deleted it. That means having that in program, still have the same problem. Could you please help me to find another problem? Thanks, Zhumei Well, you have a null pointer somewhere, hence the exception. I don't mean to be rude, but this list is not really a place to ask newbie Java questions. I would suggest that you break out a Java debugger and start hunting. If you have ddd installed, you can use the Java enabled ddd rule for Jacl by running "make ddd" in the build directory. 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
[Tcl Java] RE: [Tcl Java] New patch for loading of TclBlend from Java
On Thu, 15 Jun 2000, Jiang Wu wrote:
Your patch is a good start. There may be a few issues not addressed by this
patch:
1. Java_tcl_lang_Interp_create() may need a separate C mutex to prevent more
than one thread from creating the JVM when used in the threaded version of
Tcl. I don't think know the effect of trying to call JavaSetupJava() from
more than one thread at the same time.
That really depends on whether or not JAVA_LOCK is going to do anything.
In the call to create(), we would use the java monitor after the first
interp is loaded into Java.
jlong JNICALL
Java_tcl_lang_Interp_create(
JNIEnv *env,/* Java environment. */
jobject interpObj) /* Handle to Interp object. */
{
jlong lvalue;
Tcl_Interp *interp;
JNIEnv *oldEnv;
int loadedFromJava = (currentEnv == NULL); /* true if Tcl Blend was
loaded into Java */
if (! loadedFromJava) {
PUSH_JAVA_ENV();
}
JavaSetupJava() just does this:
if (initialized) {
return TCL_OK;
}
To be really safe, we would need to put another lock
around the code that sets up the env and
sets the initialized variable in JavaSetupJava().
Of course, that brings up the nasty case where Tcl is
compiled without thread support and yet multiple Java
threads could create an interp. I am really starting
to think Tcl Blend should just require Tcl threads
and be done with it.
2. Bugs in the Notifier class are not addressed. "update" or "vwait"
command will cause infinite loop. Events are not removed properly from the
event list. "vwait" can deadlock due to synchronization.
Yeah, we still need to get those fixed. I just want to get the loading
problems out of the way first.
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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
On Tue, 13 Jun 2000, Dr Wes Munsil wrote: I applied this patch and your other suggestion, and rebuilt, and now I cannot make it through the regression tests. tcljava/AutomaticSignature.test appears to deadlock. Can anyone help? My deadline is near, and I am close to having to abandon TclBlend as a solution, which I really do not want to have to do. Where is it getting stuck? Does it also get stuck in this same place if you load Tcl Blend into a running Tcl shell instead of loading both Tcl and Tcl Blend into a JVM? Is is a Tcl event loop problem or a JVM problem? If finalization is the problem, why don't you try taking the finalization methods out of the tcl.lang.Interp class? Try putting them into a free() method that you can just call from your app when you are done with the interp. 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] finalization deadlock under Solaris
When I started this project back in March, I could not get anything to work with JDK 1.1.8, Tcl 8.3, and TclBlend 1.2.5, so I used Tcl 8.2.3. I do not remember now what the symptom was, just that it didn't work. (I am using JDK 1.1.8 because of warnings about JDK 1.2 at http://dev.scriptics.com/software/java/faq.html#Q4.) Thats is odd, the only problem I know of is Tcl 8.2 and the whole vfork vs fork mess. Tcl 8.3 is the way to go if you ask me. That "warning" about JDK 1.2 only matters if you are using the TclClassloader to load new .class files without putting them on the CLASSPATH. Tcl, or TclBlend? I have not compiled Tcl... should I? (I'm using the binary distribution of Tcl.) I will see if I can get anywhere with this approach. Ok, the very first thing you need to do is nuke and precompiled code and compile Tcl 8.3.1 with debug symbols enabled. Then reconfigure and rebuild Tcl Blend, it will automatically notice that you compiled Tcl with debug and include debug info in libtclblend.so. This sort of thing is the exact reason there are only Windows binaries on the Tcl Blend 1.2.6 download site. It is safer to just build things by yourself. 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
[Tcl Java] Re: [Tcl Java] exec command
On Tue, 13 Jun 2000, Levine Justin-p94702 wrote: Hello, I was using JDK 1.3, but it still wasn't working properly. I gave up and just started using the Runtime class. Thanks. I have never tested it under 1.3. The exec class has this huge hack in it to get around the fact that the exec() did not let you tell the system what directory to run the command from. There is no chdir() in Java, so the combo of these things makes it next to impossible to exec() correctly from a JVM. The new exec() API in 1.3 should fix this. Why don't you fix up the ExecCmd.java file for Jacl and send in a patch? 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] RE: [Tcl Java] history command in TclBlend?
On Thu, 8 Jun 2000, Zhumei Wang wrote: Jiang, Thanks for answering my question so quickly. I was thinking that TclBlend should have all the Tcl commands, too. But After I embedded a Tcl interpreter in Java and tried to invoke "history" command in Java, it gave me the error message "tcl.lang.TclException: invalid command name "history" " I wonder why? I think Tcl must not be initing itself correctly when embedded in your application. the history command for Tcl in written in .tcl code while commands like puts and set are written in C code. If Tcl is having trouble finding its library of .tcl commands on startup, that might be the problem. I tried some other tcl commands, such as "puts" and "set ". These commands seem to work well in java. 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
[Tcl Java] Tcl/Java 1.2.6 is out the door
It is official now, you can grab the 1.2.6 release of Jacl and Tcl Blend from http://scriptics.com/java. The FAQ and download pages has been completely overhauled. The 1.2.6 "production" release contains about 6 months worth of bug fixes since the 1.2.5 release. This is a bug fix release, there are no new features. If you want new features grab the 1.3 "development" version. 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
[Tcl Java] Re: [Tcl Java] Extensions for Jacl
On Fri, 2 Jun 2000 [EMAIL PROTECTED] wrote:
I am a new user of Jacl and would like to write an extension. Is there some
documentation to explain how to define and add a package to the source
distribution, so that I can build my own .jar files. along with Jacl. Thanks.
This would help me greatly.
Kevin Gray
There is a tcljavaConfig.sh file in version 1.3 that makes
building an extension on top of Jacl or Tcl Blend really easy. I
have also attached a configure.in and Makefile.in that will
show you how it can be done. The example is from Swank, the
Tk interface extension build on top of Swing.
Mo Dejong
Red Hat Inc.
dnl This file is an input file used by the GNU "autoconf" program to
dnl generate the file "configure", which is run to configure the
dnl Makefile in this directory.
AC_INIT(swankgen/swkgen.tcl)
# RCS: @(#) $Id: configure.in,v 1.28 2000/02/23 22:15:16 mo Exp $
#
# Version identification info
#
SWANK_VERSION=0.1
SWANK_NODOT_VERSION=`echo $SWANK_VERSION | sed -e 's/\.//g'`
# Convert into full path name
srcdir=`cd $srcdir ; pwd`
MSG="srcdir is $srcdir"
echo $MSG 5
echo $MSG
BUILDDIR=`pwd`
AC_SUBST(BUILDDIR)
# Make a directory called "build" in the build directory,
# this will be the CLASSPATH root for swank .class files
SWANK_CLASSPATH_ROOT=${BUILDDIR}/build
AC_SUBST(SWANK_CLASSPATH_ROOT)
if test ! -d ${SWANK_CLASSPATH_ROOT} ; then
mkdir ${SWANK_CLASSPATH_ROOT}
fi
#
# See if there was a command-line option for where tcljava is.
#
AC_ARG_WITH(tcljava, [ --with-tcljava=DIRuse tcljava build directory from
DIR],
TCLJAVA_DIR=$withval, TCLJAVA_DIR=NONE)
if test "$TCLJAVA_DIR" = "NONE"; then
AC_MSG_ERROR([You must give the tcljava build directory using --with-tcljava])
fi
if test ! -f $TCLJAVA_DIR/tcljavaConfig.sh; then
AC_MSG_ERROR([Could not find $TCLJAVA_DIR/tcljavaConfig.sh,
Try --with-tcljava=DIR where DIR is the directory where you built tcljava])
fi
#
# Read in configuration information generated by tcljava
#
file=$TCLJAVA_DIR/tcljavaConfig.sh
. $file
AC_SUBST(TCLJAVA_PREFIX)
AC_SUBST(TCLJAVA_EXEC_PREFIX)
AC_SUBST(TCLJAVA)
AC_SUBST(TCLJAVA_VERSION)
AC_SUBST(TCLJAVA_NODOT_VERSION)
AC_SUBST(TCLJAVA_BUILD_DIR)
AC_SUBST(JAVA)
AC_SUBST(JAVA_G)
AC_SUBST(JAVAC)
AC_SUBST(JAVAH)
AC_SUBST(JAR)
AC_SUBST(JDB)
AC_SUBST(JAVA_FLAGS)
AC_SUBST(JAVA_G_FLAGS)
AC_SUBST(JAVAC_FLAGS)
AC_SUBST(JAVAC_D_FLAG)
AC_SUBST(JAVA_CLASSPATH)
AC_SUBST(JAR_EXTRACT_FLAGS)
AC_SUBST(JAR_COMPRESS_FLAGS)
AC_SUBST(JAR_NOCOMPRESS_FLAGS)
#
# Define the classpath swank will use
#
SWANK_CLASSPATH=${SWANK_CLASSPATH_ROOT}
#
# Get the tcljava build CLASSPATH, this path could be different
# depending on if you configured with Jacl or Tcl Blend
#
CP_PAIR=`cd $TCLJAVA_DIR ; make classpath | grep CLASSPATH`
# Set TCLJAVA_CLASSPATH to the second element in the space
# separated list, it is kind of a shell hack but oh well.
for i in $CP_PAIR;
do
TCLJAVA_CLASSPATH=$i ;
done;
SWANK_CLASSPATH=${SWANK_CLASSPATH}:${TCLJAVA_CLASSPATH}
AC_SUBST(SWANK_CLASSPATH)
#
# See if the compiler accepts -J-mx(num)M. This is needed to
# avoid "out of memory errors" with the JDK compiler
#
JAVAC_EXTRA_MEM=-J-mx35M
echo "public class testme {}" testme.java
echo "" 5
echo "Testing the ${JAVAC_EXTRA_MEM} option to the java compiler" 5
echo "CLASSPATH=${JAVA_CLASSPATH}" 5
echo "${JAVAC} ${JAVAC_FLAGS} ${JAVAC_EXTRA_MEM} testme.java" 5
CLASSPATH=${JAVA_CLASSPATH} \
${JAVAC} ${JAVAC_FLAGS} ${JAVAC_EXTRA_MEM} testme.java 2 5
if test ! -f testme.class; then
echo "Java compiler did not accept ${JAVAC_EXTRA_MEM}" 5
else
echo "Java compiler accepted ${JAVAC_EXTRA_MEM}" 5
JAVAC_FLAGS="${JAVAC_FLAGS} ${JAVAC_EXTRA_MEM}"
fi
rm -f testme.*
#--
# See if there was a command-line option for where a swing jar is.
#--
AC_ARG_WITH(swingjar, [ --with-swingjar=FILEuse this swing JAR file],
SWINGJAR=$withval, SWINGJAR=NONE)
if test "$SWINGJAR" = "NONE"; then
SWINGJAR=
fi
echo "import javax.swing.*;
public class swingme {}" swingme.java
ec
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] problem with creating Interp object
On Mon, 29 May 2000, W. John Guineau wrote: Am I confused here? I am currently loading Tcl Blend into Java in the sense that from a live Java VM, I call 'import tcl.lang.*; Interp tclInterp = new Interp()' etc. and I am able to interact with the C based Tcl interpreter, have dynamically loadable extensions (written in Java) that run in the context of, and have complete access to, all of my existing run-time Java code/data. The Tcl scripts, using an extension created on the Java side: Yes, but you are using Mr. Wu's patches. I was saying that the 1.2.6 release and the 1.3 version in the CVS does not currently work. One can "make it work" by adding the patches but I do not think that was what the poster was asking. I think he actually wanted to load Java code into a Tcl shell. The moral of this story is that Mr. Wu's patches need to get added into the CVS version. This is going to happen but I just have not had the time to do it yet. Current Tcl/Java Todo list. 1. Get the web pages at scriptics.com/java updated for the 1.2.6 release 2. Finish the new integrated build system. This will make it possible to build Tcl Blend and Jacl with the same ./configure ; make scripts under both windows and Unix. We can then remove unix/confgure.in and the horrid beast knows as win/makefile.vc. 3. Finish overhaul of the pyramidpkg demo to make it thread safe. 4. Merge the rest of Mr. Wu's patches for Tcl Blend. The current conclusion seems to be that we can also remove all uses of JAVA_LOCK in the native JNI code. If anyone would like to help with any of these items, it would really speed things up. 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
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] problem with creating Interp object
On Mon, 29 May 2000, W. John Guineau wrote: Mo, Since it's in my best interest, I can probably help with: 4. Merge the rest of Mr. Wu's patches for Tcl Blend. Is there a simple way for me to access the online CVS repository from Windows? I do have a dual-boot system with Linux (RedHat 6.2) but my impetus is for work, which has a Windows platform requirement. I could also do a sanity check on the JAVA_LOCK stuff as I've done a considerable amount of multi-threaded work and may have some insights (as an outsider) into the issues with Tcl Blend. john That would be great. I think both Jiang, Scott, and I are in agreement that the JAVA_LOCK stuff in the JNI methods do not do anything useful. I think they were originally added before the Notifier class was part of Jacl and Tcl Blend. The Notifier class should be the sole synchronization point for adding an event to the Tcl event queue. The event is then pulled off the queue by the dedicated "event thread" and all command invocations after that are unsynchronized. This is a good thing because you end up with really low synchronization overhead. Currently, both the Tcl Blend and Jacl versions of the notifier seem to be thread safe, so it looks like you can just strip out all of the code that has anything to do with JAVA_LOCK. This JAVA_LOCK thingy is a big global lock that seemed to be needed in the old days of Tcl 8.0, but the 1.3 version of Tcl Blend only supports Tcl 8.3 and Tcl 8.4 so that is no longer a concern. There is also global lock inside unix/unixNotifier.c and win/winNotifier.c that should only be used when Tcl is compiled without thread support. More detailed discussion of these issues can be found in the mailing list archive. The best way to get CVS access on a windows machine is to install Cygwin. You are going to need cygwin to build Tcl Blend on windows anyway, so you should just grab it now. Your best bet is to just get it from a mirror. Download the installer. ftp://ftp.freesoftware.com/pub/sourceware/cygwin/latest/setup.exe Run it and then point it at a mirror like ftp://ftp.freesoftware.com/pub/sourceware/cygwin/latest ftp://ftp.sunsite.utk.edu/pub/cygwin/latest/ Then grab the soure for CVS and run ./configure. It should just configure and compile out of the box. Of course, it might be easier to just use a regular Unix box running samba and just mount that over the network on windows. That is what we do at work. Actually trying to use windows to do any sort of development work is much harder than developing software to run on windows. 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
