Thread: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
Brought to you by:
mdejong
Menu
▾
▴
tcljava-dev
|
From: W. J. G. <gu...@ea...> - 2001-03-21 18:44:39
|
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 |
|
From: W. J. G. <gu...@ea...> - 2001-03-22 02:19:58
|
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
|
|
From: Mo D. <md...@cy...> - 2001-03-23 09:35:43
|
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
|
|
From: W. J. G. <gu...@ea...> - 2001-03-26 16:44:58
|
> -----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
|
|
From: W. J. G. <gu...@ea...> - 2001-03-26 18:37:23
|
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
|
|
From: Mo D. <md...@cy...> - 2001-03-23 09:10:34
|
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
|
|
From: W. J. G. <gu...@ea...> - 2001-03-26 16:34:57
|
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
|
|
From: Mo D. <md...@cy...> - 2001-03-26 16:38:39
|
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 |
|
From: W. J. G. <gu...@ea...> - 2001-03-26 16:55:03
|
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 |
|
From: W. J. G. <gu...@ea...> - 2001-03-30 18:13:54
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X