[Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL

2000-05-24 Thread Jiang Wu

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

2000-05-24 Thread Jeff Sturm

"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

2000-05-24 Thread W. John Guineau


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] Tcl Blend vs JACL

2000-05-24 Thread W. John Guineau

Ah, thank you for the document pointer! This looks to be the motherload of
Tcl Blend/JACL info!

john

 -Original Message-
 From: Jiang Wu [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, May 24, 2000 2:24 PM
 To: 'W. John Guineau'; [EMAIL PROTECTED]
 Subject: 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] RE: [Tcl Java] Tcl Blend vs JACL

2000-05-24 Thread Jiang Wu
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.

4. In the class Notifier, the method "deleteEvents()" has a bug that it does
not properly set the "lastEvent" and "markerEvent" pointers when an event
from the middle of the event list is removed.  The fix is to move the event
deletion code from "serviceEvent()" into "deleteEvents()".  "serviceEvent()"
now uses "deleteEvents()" to delete processed event.  This reduces the
chances of error by removing redundant codes.



-- Jennifer Hom on March 17, 2000 10:50 PM


Type Defect 
State New 
Severity Critical: Major defect, no workaround 
Priority Unknown - Not yet prioritized 
Category Other 
OS Windows NT Windows NT 4 Dell Pentium II 450 Mhz 
Found in Version 1.2.6 
Fixed Date 2000-03-17 00:00:00 



-Original Message-
From: W. John Guineau [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 24, 2000 5:49 PM
To: Mo DeJong
Cc: Jiang Wu; [EMAIL PROTECTED]
Subject: RE: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL

Hmm, this patch wouldn't happen to fix the following odd error I'm currently
chasing (below), would it?

=
C:\JTCCSRoot\ui\Automationset bld=debug

C:\JTCCSRoot\ui\Automationset
path=c:\jdk1.3\jre\bin;c:\jdk1.3\jre\bin\classic;C:\tcl\tcl8.3.1\win\debug;c
:\tcl\tcl8.3.1\lib\tclblend;.;C:\WINNT\system32;C:\WINNT;

C:\JTCCSRoot\ui\Automationset
cp=C:\jdk1.3\jre\lib\rt.jar;.\classes;c:\tcl\tcl8.3.1\lib\tcljava.jar;c:\tcl
\tcl8.3.1\lib\tclblend.jar

C:\JTCCSRoot\ui\Automationjava -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

C:\JTCCSRoot\ui\Automationjava -classpath
C:\jdk1.3\jre\lib\rt.jar;.\classes;c:
\tcl\tcl8.3.1\lib\tcljava.jar;c:\tcl\tcl8.3.1\lib\tclblend.jar
scriptmanager.Scr
iptManager
Exception in thread "main" java.lang.NullPointerException
at tcl.lang.Interp.create(Native Method)
at tcl.lang.Interp.init(Interp.java:130)
at scriptmanager.ScriptManager.main(ScriptManager.java:24)
EXP: tcl.lang.TclRuntimeError: could not find class java/lang/Object.
Check that your path includes the directory where tclblend.dll resides.
Try looking in the directories under the value of tcl_library,
currently: Currently, the CLASSPATH environment variable is not set.
=



 tclblend.patch