Thread: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()

Hi Mo,

OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
changes we made to the 1.2.6 code and then integrated it into our
application.

While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we discovered
that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
it boiled down to a native method that (I suspect) called Tcl_EvalFile().

Is there a reason this was removed from 1.3.0?

thanks for all the help!

john



On Thu, 15 Mar 2001, W. John Guineau wrote:

> Hi Mo,
>
> I'm starting to search around SourceForge.net. I found the TclBlend
project,
> and want to grab a copy to try.
>
> I'm trying to figure out how to access the CVS repository on SourceForge.
It
> seems I need something called pserver? I need access ('get' only is fine)
> from a Windows PC...
>
> john

In the future could you post to the user or dev mailing
lists? That way folks could see your questions and
the answer.

To get the CVS code, you need a CVS client. Nothing
else is required. You just set the CVSROOT env
var and run "cvs co tcljava". I have not used
Windows clients, I suggest you download and
install Cygwin (www.cywin.com), it has a cmd
line CVS client to works just fine.

Mo

Hi Mo,

You mentioned previously on this (or another) list that there were some
problems remaining in 1.3.0 to do with termination?

Would that be the assert I'm seeing in the TclBlend.DLL at:

 src/native/javaCmd.c:

TCLBLEND_EXTERN JNIEnv *JavaGetEnv()
{
   ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
   assert(tsdPtr->initialized);
   return tsdPtr->currentEnv;
}


It seems to happen when calling Interp.destroy().

Also - if I have a notifier thread sitting in notifier.doOneEvent(), what's
the recomended way to get it out? Right now, I just send it an empty string
to eval() and that causes the notifier.doOneEvent() while() loop to exit
(taking the thread with it).

john


> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of W. John
> Guineau
> Sent: Wednesday, March 21, 2001 10:45 AM
> To: tcl...@li...
> Subject: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> Hi Mo,
>
> OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
> changes we made to the 1.2.6 code and then integrated it into our
> application.
>
> While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we
> discovered
> that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
> it boiled down to a native method that (I suspect) called Tcl_EvalFile().
>
> Is there a reason this was removed from 1.3.0?
>
> thanks for all the help!
>
> john
>
>
>
> On Thu, 15 Mar 2001, W. John Guineau wrote:
>
> > Hi Mo,
> >
> > I'm starting to search around SourceForge.net. I found the TclBlend
> project,
> > and want to grab a copy to try.
> >
> > I'm trying to figure out how to access the CVS repository on
> SourceForge.
> It
> > seems I need something called pserver? I need access ('get'
> only is fine)
> > from a Windows PC...
> >
> > john
>
> In the future could you post to the user or dev mailing
> lists? That way folks could see your questions and
> the answer.
>
> To get the CVS code, you need a CVS client. Nothing
> else is required. You just set the CVSROOT env
> var and run "cvs co tcljava". I have not used
> Windows clients, I suggest you download and
> install Cygwin (www.cywin.com), it has a cmd
> line CVS client to works just fine.
>
> Mo
>
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcljava-dev

On Wed, 21 Mar 2001, W. John Guineau wrote:

> Hi Mo,
> 
> You mentioned previously on this (or another) list that there were some
> problems remaining in 1.3.0 to do with termination?

Yeah, I think our multi-threaded startup stuff is ok.
It is the shutdown that seems to have problems.

> Would that be the assert I'm seeing in the TclBlend.DLL at:
> 
>  src/native/javaCmd.c:
> 
> TCLBLEND_EXTERN JNIEnv *JavaGetEnv()
> {
>    ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
>    assert(tsdPtr->initialized);
>    return tsdPtr->currentEnv;
> }
> 
> 
> It seems to happen when calling Interp.destroy().

Humm, that says to me that the JavaGetEnv() method is getting
called after the thread has been cleaned up. Could you provide
a nice little test case for this problem? If you really want
to lend a hand, designing some test cases that will check
the startup and shutdown cases would really help. They
are tricky because they are not like any of the other tests.
Startup and shutdown tests might need to be run as separate
programs before running the normal "make check" rule.

> Also - if I have a notifier thread sitting in notifier.doOneEvent(), what's
> the recomended way to get it out? Right now, I just send it an empty string
> to eval() and that causes the notifier.doOneEvent() while() loop to exit
> (taking the thread with it).

Do you mean you want to make another thread exit from one that
you are in? I think you would to use the Thread package for
that. I think you send a thread::exit command to your target
thread using the thread::send command. My memory is a little
fuzzy in this area so I could be way off.

http://dev.scriptics.com/ftp/thread//thread21.html

Mo DeJong
Red Hat Inc

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Mo DeJong
> Sent: Friday, March 23, 2001 1:36 AM
> To: tcl...@li...
> Subject: RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> On Wed, 21 Mar 2001, W. John Guineau wrote:
>
> > Hi Mo,
> >
> > You mentioned previously on this (or another) list that there were some
> > problems remaining in 1.3.0 to do with termination?
>
> Yeah, I think our multi-threaded startup stuff is ok.
> It is the shutdown that seems to have problems.


Yes, I can run multiple interps fine, but stopping/destroying them does not
seem to be working.

>
> > Would that be the assert I'm seeing in the TclBlend.DLL at:
> >
> >  src/native/javaCmd.c:
> >
> > TCLBLEND_EXTERN JNIEnv *JavaGetEnv()
> > {
> >    ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
> >    assert(tsdPtr->initialized);
> >    return tsdPtr->currentEnv;
> > }
> >
> >
> > It seems to happen when calling Interp.destroy().
>
> Humm, that says to me that the JavaGetEnv() method is getting
> called after the thread has been cleaned up. Could you provide
> a nice little test case for this problem?

I'll try. Right now, my 'test case' is sitting in about 130K lines of code
;)

Basically what I'm doing is this:

	- Create a thread "N" to run "notifier.doOneEvent()" in a while( _run ){}
loop 	(i.e. if _run == false, the notifier thread will exit.)

	- From another thread "E", feed the notifier an event to eval() a String
full of Tcl.

	- When E completes (that is, the interp.eval() completes) it:

		- sets _run to false to let N exit.
		- feeds N an empty string to eval() so doOneEvent() will emerge.
		- join()'s N (waits for N to exit)

	- E then does an interp.destroy() and I get the assert.

Am I shutting down the interp/notifier correctly?

> If you really want
> to lend a hand, designing some test cases that will check
> the startup and shutdown cases would really help. They
> are tricky because they are not like any of the other tests.
> Startup and shutdown tests might need to be run as separate
> programs before running the normal "make check" rule.

And take the fun away from you? ;)


> > Also - if I have a notifier thread sitting in
> notifier.doOneEvent(), what's
> > the recomended way to get it out? Right now, I just send it an
> empty string
> > to eval() and that causes the notifier.doOneEvent() while() loop to exit
> > (taking the thread with it).
>
> Do you mean you want to make another thread exit from one that
> you are in? I think you would to use the Thread package for
> that. I think you send a thread::exit command to your target
> thread using the thread::send command. My memory is a little
> fuzzy in this area so I could be way off.
>
> http://dev.scriptics.com/ftp/thread//thread21.html


I meant the Java thread(s) running the TclBlend Interp and it's Notifier.
See above for a (hopefully lucid) description of what I mean.


>
> Mo DeJong
> Red Hat Inc
>

john

Mo,

Here's the stack if it helps:

_assert(void * 0x0e808054, void * 0x0e808010, unsigned int 293) line 256
JavaGetEnv() line 293 + 29 bytes
FreeTclObject(Tcl_Obj * 0x000c68f8) line 185 + 5 bytes
DeleteArray(Interp * 0x000bd048, char * 0x000a6c28, Var * 0x000b2c28, int
321) line 4631 + 93 bytes
TclDeleteVars(Interp * 0x000bd048, Tcl_HashTable * 0x000cd0f8) line 4442 +
50 bytes
TclTeardownNamespace(Namespace * 0x000cd068) line 736 + 18 bytes
DeleteInterpProc(Tcl_Interp * 0x000bd048) line 963 + 12 bytes
Tcl_EventuallyFree(int * 0x000bd048, void (char *)* 0x0e826995
DeleteInterpProc(Tcl_Interp *)) line 313 + 7 bytes
Tcl_DeleteInterp(Tcl_Interp * 0x000bd048) line 901 + 14 bytes
Java_tcl_lang_Interp_doDispose(const JNINativeInterface_ * * 0x08a2d884,
_jobject * 0x0e7bfcf4, __int64 1044831918095061064) line 208 + 10 bytes
0082b871()
0082939a()
0082939a()
0082939a()
JVM! 504d4eae()
JVM! 5040e87a()
JVM! 50430987()
JVM! 5040e77f()
JVM! 5040e4fd()
JVM! 5041b998()
JVM! 50447ba3()
JVM! 50447b74()
MSVCRT! 7800a3c0()
KERNEL32! 77db2c18()






> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Mo DeJong
> Sent: Friday, March 23, 2001 1:36 AM
> To: tcl...@li...
> Subject: RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> On Wed, 21 Mar 2001, W. John Guineau wrote:
>
> > Hi Mo,
> >
> > You mentioned previously on this (or another) list that there were some
> > problems remaining in 1.3.0 to do with termination?
>
> Yeah, I think our multi-threaded startup stuff is ok.
> It is the shutdown that seems to have problems.
>
> > Would that be the assert I'm seeing in the TclBlend.DLL at:
> >
> >  src/native/javaCmd.c:
> >
> > TCLBLEND_EXTERN JNIEnv *JavaGetEnv()
> > {
> >    ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
> >    assert(tsdPtr->initialized);
> >    return tsdPtr->currentEnv;
> > }
> >
> >
> > It seems to happen when calling Interp.destroy().
>
> Humm, that says to me that the JavaGetEnv() method is getting
> called after the thread has been cleaned up. Could you provide
> a nice little test case for this problem? If you really want
> to lend a hand, designing some test cases that will check
> the startup and shutdown cases would really help. They
> are tricky because they are not like any of the other tests.
> Startup and shutdown tests might need to be run as separate
> programs before running the normal "make check" rule.
>
> > Also - if I have a notifier thread sitting in
> notifier.doOneEvent(), what's
> > the recomended way to get it out? Right now, I just send it an
> empty string
> > to eval() and that causes the notifier.doOneEvent() while() loop to exit
> > (taking the thread with it).
>
> Do you mean you want to make another thread exit from one that
> you are in? I think you would to use the Thread package for
> that. I think you send a thread::exit command to your target
> thread using the thread::send command. My memory is a little
> fuzzy in this area so I could be way off.
>
> http://dev.scriptics.com/ftp/thread//thread21.html
>
> Mo DeJong
> Red Hat Inc
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcljava-dev

On Wed, 21 Mar 2001, W. John Guineau wrote:

> Hi Mo,
> 
> OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
> changes we made to the 1.2.6 code and then integrated it into our
> application.
> 
> While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we discovered
> that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
> it boiled down to a native method that (I suspect) called Tcl_EvalFile().
> 
> Is there a reason this was removed from 1.3.0?

Humm, I just looked at the Tcl Blend Interp.java file from 1.2.6
and the evalFile() method is defined as:

public void
evalFile(
    String s)                   // The name of file to evaluate.
throws 
    TclException
{
    throw new TclRuntimeError("Not implemented yet.");
}

It is the same in 1.3.

Mo DeJong
Red Hat Inc

Oops - yup. That was code I had added to the 1.2.6 version *before*
commiting it to our "cvs" (vss) and so missed it in the diffs ;)

Would you like an implementation for the 1.3.0 code? ;)

john

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Mo DeJong
Sent: Friday, March 23, 2001 1:11 AM
To: tcl...@li...
Subject: Re: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()


On Wed, 21 Mar 2001, W. John Guineau wrote:

> Hi Mo,
>
> OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
> changes we made to the 1.2.6 code and then integrated it into our
> application.
>
> While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we
discovered
> that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
> it boiled down to a native method that (I suspect) called Tcl_EvalFile().
>
> Is there a reason this was removed from 1.3.0?

Humm, I just looked at the Tcl Blend Interp.java file from 1.2.6
and the evalFile() method is defined as:

public void
evalFile(
    String s)                   // The name of file to evaluate.
throws
    TclException
{
    throw new TclRuntimeError("Not implemented yet.");
}

It is the same in 1.3.

Mo DeJong
Red Hat Inc

_______________________________________________
tcljava-dev mailing list
tcl...@li...
http://lists.sourceforge.net/lists/listinfo/tcljava-dev

On Mon, 26 Mar 2001, W. John Guineau wrote:

> Oops - yup. That was code I had added to the 1.2.6 version *before*
> commiting it to our "cvs" (vss) and so missed it in the diffs ;)
> 
> Would you like an implementation for the 1.3.0 code? ;)
> 
> john

Sure. Patches are always welcome. Add them via the SF patch
manager interface.

Mo

OK, let me take a look at the patch manager...

I had made a couple other changes to 1.2.6 and Tcl 8.3.2(?) if you're
interested. The major change was to add an abortExecution() method from the
Java TclBlend Interp all the way through the JNI layer into the Tcl
interpreter's bytecode engine itself. This allows stopping the bytecode
engine "in it's tracks" and therefor abort an executing Tcl script.

Unfortunetly, that little trick causes 1.3.0 to assert() in the same place I
mentioned in previous email....

john

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Mo DeJong
> Sent: Monday, March 26, 2001 8:39 AM
> To: tcl...@li...
> Subject: RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> On Mon, 26 Mar 2001, W. John Guineau wrote:
>
> > Oops - yup. That was code I had added to the 1.2.6 version *before*
> > commiting it to our "cvs" (vss) and so missed it in the diffs ;)
> >
> > Would you like an implementation for the 1.3.0 code? ;)
> >
> > john
>
> Sure. Patches are always welcome. Add them via the SF patch
> manager interface.
>
> Mo
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcljava-dev

Mo,

Did the stack traces I sent make any sense? Am I shutting Tcl/Blend down
improperly or is this the shutdown bug you mentioned?

thanks!
john

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Mo DeJong
> Sent: Monday, March 26, 2001 8:39 AM
> To: tcl...@li...
> Subject: RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> On Mon, 26 Mar 2001, W. John Guineau wrote:
>
> > Oops - yup. That was code I had added to the 1.2.6 version *before*
> > commiting it to our "cvs" (vss) and so missed it in the diffs ;)
> >
> > Would you like an implementation for the 1.3.0 code? ;)
> >
> > john
>
> Sure. Patches are always welcome. Add them via the SF patch
> manager interface.
>
> Mo
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcljava-dev