[Tcl Java] Re: [Tcl Java] Jacl: patch for tcl/lang/Interp.java (evalResource)
On Tue, 23 May 2000, Jeff Sturm wrote: I just tracked down an annoying bug in Jacl... the classloader could not found a /tcl/lang/library/init.tcl resource, so the interpreter refused to start. The Interp had been trying to load resources from the system classloader, not the classloader which loaded tcl.lang.Interp: Thanks for the bug report and patch. Your suggested change was committed to the CVS with one small modification. If you have any other problems running Jacl in applets please don't hesitate to report them. cvs diff -r 1.30 -r 1.31 src/jacl/tcl/lang/Interp.java diff -u -r1.30 -r1.31 --- Interp.java 2000/05/14 23:10:20 1.30 +++ Interp.java 2000/05/24 08:04:32 1.31 @@ -2441,7 +2441,7 @@ InputStream stream = null; try { - stream = Class.class.getResourceAsStream(resName); + stream = Interp.class.getResourceAsStream(resName); } catch (SecurityException e2) { // This catch is necessary if Jacl is to work in an applet // at all. Note that java::new will not work from within 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: [Tcl Java] Tcl Blend vs JACL
You are certainly "going against the grain" right now :) But I am hoping more people will use TclBlend this way. We are doing something similar right now with TclBlend (1.3 + some patches) with JDK 1.2. I am not sure what you mean by "single step the interpreter". You can certainly set/get/call Tcl variables and commands within the Java code. We also have a socket connection for the embedded Tcl interpreter. We use telnet to access the interpreter interactively for debugging. We can also use Visual Cafe to single step through any Java portion of the program. There are some potential threading problems. You also need to patch the existing TclBlend. You may want to take a look at: http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html which discuss how to embed Tcl in Java. -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: W. John Guineau [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 24, 2000 2:09 PM To: [EMAIL PROTECTED] Subject: [Tcl Java] Tcl Blend vs JACL We have a medium sized system (~250K lines of C++ and Java) that we want to graft Tcl scripting into. The place where we would integrate scripting is all Java code. I see the recommended solution in this case is to use JACL, but for performance reasons (and other factors) I would prefer to use Tcl Blend. We already have a fairly significant JNI interface to common C++ code, so I'm quite familiar with JNI at this point (I see Tcl Blend also uses JNI.) My plan is to load the Tcl interpreter from within Java, and then interact with it from Java. We would then write Tcl extensions that essentially wind thier way back into our Java code, and therefore have access to all the functionality we already have. We will also need to single step the interpreter and view/modify variables from within the Java code. Am I asking for trouble by "going against the grain" on this? john 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 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] Tcl Blend vs JACL
"W. John Guineau" wrote: My plan is to load the Tcl interpreter from within Java, and then interact with it from Java. We would then write Tcl extensions that essentially wind thier way back into our Java code, and therefore have access to all the functionality we already have. We will also need to single step the interpreter and view/modify variables from within the Java code. You can certainly write extensions this way, but why not use the java package, which is reflection based, instead? I find it easier to just invoke my methods directly from Tcl than to try to write a custom extension. -- Jeff Sturm [EMAIL PROTECTED] The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Well, if I use the Java package, then the Tcl code would not have access to the same run-time instance of the JVM that our code is running in, right? (starting our Java code from Tcl is, unfortunetly, not an option.) Or am I missing something here? My assumption was that starting a Tcl interpreter from within a given JVM would cause the Tcl Blend package on the Tcl side to use the existing JVM and not create a new one. My goal is to: 1. start n number of Tcl interpreters from a Java application (n usually 1 or 2) 2. load and execute a Tcl script from within Java 3. load and *debug* a Tcl script from within Java (i.e. "single step" the interpreter in trace mode, so the user can click a UI button (from a Java client running across a TCP/IP link to the JAVA server code mentioned above) to step through a Tcl script, examining variables along the way. 4. Write Tcl extensions in Java (or C/C++,) which can then access the JVM, and hence all the Java Server code. I suspect for 3. I will need to extend Tcl Blend's JNI implementation to provide Java side access to Tcl_CreateTrace et al. john -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Sturm Sent: Wednesday, May 24, 2000 2:45 PM To: W. John Guineau Cc: [EMAIL PROTECTED] Subject: Re: [Tcl Java] Tcl Blend vs JACL "W. John Guineau" wrote: My plan is to load the Tcl interpreter from within Java, and then interact with it from Java. We would then write Tcl extensions that essentially wind thier way back into our Java code, and therefore have access to all the functionality we already have. We will also need to single step the interpreter and view/modify variables from within the Java code. You can certainly write extensions this way, but why not use the java package, which is reflection based, instead? I find it easier to just invoke my methods directly from Tcl than to try to write a custom extension. -- Jeff Sturm [EMAIL PROTECTED] The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Here is the patch with the description of the problems solved in the patch. Without the patch, my Java program causes an access violation when loading TclBlend. -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Jiang Wu [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 04, 2000 3:26 PM To: [EMAIL PROTECTED] Subject: [Tcl Java] The Mythical TclBlend Patch Sorry folks, I never send the TclBlend patch to this mailing list. I just checked the Scriptics bug DB. My bug report is there now. It is number 4352. The report does not show the patch. I copied the bug report at the end of this email. The patch is also attached to the email. The patch allows one to write a Java based shell using native TCL through TclBlend. I will post my modified Jacl shell later this week that you can use to try out the patch. -- Jiang Wu [EMAIL PROTECTED] == TR#4352 Help | New Bug Report | Simple Search | Advanced Search | Product Summary | Component Summary | Settings Unable to start TclBlend from Java TclBlend Java Interface TclBlend Java Interface - TclBlend Java Interface Found in Version: 1.2.6 Subject: Unable to start TclBlend from Java Name: Jiang Wu ReproducibleScript: The following Java program will crash. -- Java program - import tcl.lang.*; public class Shell { public static void main (String args[]) { Interp interp = new Interp(); } }; ObservedBehavior: If one tries to start a native TCL interpreter inside a Java process using TclBlend, the program produces an access violation. Most of the TclBlend functions expect TclBlend_Init() to be called first before "new Interp()" can function properly. However, if a Java program tries to load TclBlend instead of a native TCL program trying to load TclBlend, TclBlend_Init() is never called. In particular, the above program will trigger an access violation in the following location in /tcljava/src/native/javaInterp.c: jlong JNICALL Java_tcl_lang_Interp_create( JNIEnv *env,/* Java environment. */ jobject interpObj) /* Handle to Interp object. */ { jlong lvalue; Tcl_Interp *interp; JNIEnv *oldEnv; JAVA_LOCK(); /* !!! this line triggers an access violation !! */ /* ... stuff to create the native TCL interpreter ... */ JAVA_UNLOCK(); return lvalue; } DesiredBehavior: One should be able to embed a native TCL interpreter inside a Java program. One should be able to write a tclsh like program in Java using TclBlend and the native TCL library. The embeded native TCL interpreter in a Java program should behave the same a native TCL interpreter running inside a C program. Patch: Look in /home/bugs/tclblend under this bug number. Patch files: java.h, javaCmd.c, javaInterp.c, Notifier.java Comments Comments on: Unable to start TclBlend from Java The changes in the patch was tested using JDK 1.2.2, Tcl 8.2.3 as well as the multi-threaded version of Tcl 8.2.3 on Windows NT 4. The changes fix the following 4 problems that prevented a native TCL interpreter from being embeded inside a Java program. 1. In javaInterp.c, if TclBlend is started inside a JVM, Java_tcl_lang_Interp_create() function uses an uninitialized global pointer, java.NativeLock. The fix is to use a separate TCL mutex instead of the Java mutex used in the JAVA_LOCK macro to protect TclBlend global data structures used to store JVM information during TclBlend initialization. The change touches java.h, javaCmd.h and javaInterp.c. TclBlend_Init() is also changed to use the new mutex when it sets up the globals. The TCL mutex should only be used if TclBlend is to be linked with the muti-threaded version of TCL. The modified code uses the macro "TCL_THREADS" to determine whether to use the TCL mutex or not. This macro should be define appropriately during the compilation process. For non-threaded TCL, no mutex is used. 2. In the Java class Notifier, the method "hasEvent()" always returns true if it is called within "serviceEvent()". This can happen if "Notifier.doOneEvent()" triggers a "serviceEvent()" to eval "vwait" or "update" TCL commands. When this senario happens, the program goes into a busy infinite loop calling "hasEvent(), doOneEvent(), hasEvent(), doOneEvent(), ...". "hasEvent()" is modified such that it skips all events on the event list that is currently being processed at the moment "hasEvent()" is invoked. 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