[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] what I now know about the deadlock

2000-06-14 Thread W. John Guineau


Without having looked into the innerds of TclBlend's JNI implementation
(though it looks quite clean at least) I'd say that removing the monitor
calls and JAVA_LOCK are probably fine.

I say this because we have a decent size app (~250K lines of C/C++/Java)
that uses a JNI layer I wrote. I never use locking in the JNI layer (in
general) and have multithreaded access without any apparent problems (the
JNI part is the backend of a Java based server that provides access to
common C code.)

john

 -Original Message-
 From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, June 14, 2000 7:40 AM
 To: [EMAIL PROTECTED]
 Subject: [Tcl Java] Re: [Tcl Java] what I now know about the deadlock


 I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't
 matter  in this
 context," because that seems to fix my problem.

 Dr Wes Munsil wrote:

  Please give me your advice.
 
  I've instrumented TclBlend to look for the pattern of execution of
  MonitorEnter/MonitorExit calls and have learned this. The deadlock seen
  in my code, and now in the TclBlend regression test
  AutomaticSignature.test on Solaris with native threads, has these
  characteristics:
 
  1) Tclblend_Init is never called. Consequently the call of MonitorEnter
  in that function is never executed.
 
  2) Although Jiang's patch removes the MonitorEnter and MonitorExit calls
  from JAVA_LOCK and JAVA_UNLOCK, there are still other calls of
  MonitorEnter and MonitorExit: they occur in Exit/Enter pairs in
  JavaIdleProc, JavaTraceProc, JavaCmdDeleteProc, JavaCmdProc,
  JavaEventProc, and JavaTimerProc.
 
  3) The sequence of events leading up to deadlock is the following:
 
  a) the main thread calls MonitorExit in JavaCmdProc
  b) the garbage collection thread calls MonitorExit in JavaCmdDeleteProc
  c) the garbage collection thread calls MonitorEnter in JavaCmdDeleteProc
 
  d) the main thread calls MonitorEnter in JavaCmdProc (and blocks)
 
  I can think of two solutions to this problem, but I don't know which is
  "right."
 
  SOLUTION 1. Simply remove all remaining calls of MonitorEnter and
  MonitorExit.
  SOLUTION 2. Replace all remaining calls of MonitorEnter and MonitorExit
  by invocations of JAVA_LOCK and JAVA_UNLOCK, respectively (which now
  have the MonitorEnter and MonitorExit calls removed, but which retain
  the fiddling with the Java environment).
 
  In either case, we should possibly discover why Tclblend_Init is not
  being called, and fix that.
 
  What do you think?
 
  Thank you.
 
  
  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




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