[Tcl Java] This tcljava mailing list is shutting down!

2000-11-01 Thread Mo DeJong
will host more in depth discussions while the user list will be focused on user questions. The user list should be very low bandwidth. cheers Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To

[Tcl Java] Re: Help on calling Tcl Scripts through a Java Program

2000-10-30 Thread Mo DeJong
ou set argv and argv0 to something before evaling the file, it would be like running the file from the command line. cheers Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send

[Tcl Java] Threaded Tcl Blend is ready for testing.

2000-10-29 Thread Mo DeJong
:pserver:[EMAIL PROTECTED]:/cvsroot/tcljava cvs login (just hit return for the password) cvs checkout tcljava Happy Hacking. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send

[Tcl Java] Re: possible memory.

2000-10-27 Thread Mo DeJong
On Thu, 26 Oct 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > > Mo> Are you up to it? I am going to be working on this object ref > Mo> queue thing for some time, so if you could take a whack a

[Tcl Java] Re: JDK versions and JACL versions

2000-10-26 Thread Mo DeJong
g out (they got out of the JVM biz). 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

[Tcl Java] Re: ajuba branch

2000-10-26 Thread Mo DeJong
On Thu, 26 Oct 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > > Mo> What version of Tcl are you using? This should not show up > Mo> with Tcl 8.3.2 or 8.4. At any rate, it does not matter. &

[Tcl Java] Re: ajuba branch

2000-10-26 Thread Mo DeJong
e either. Could this have something to do with your Notifier changes? If not, could you investigate it a bit more? Perhaps get a stack trace and print it to see where things are going wrong. Mo DeJong Red Hat Inc The TclJava mailing l

[Tcl Java] Re: compiling tcljava

2000-10-26 Thread Mo DeJong
lot easier to get working with the Cygwin based build. Tcl Blend is going to be a bit more work. There was a Cygwin tested build process for Tcl Blend in the 1.2 release, but it did not support Jacl and suffered a bit of code rot when compared to 1.3, so I had to kill it. I need to revive that sucker

[Tcl Java] Re: autoconf 2.14

2000-10-26 Thread Mo DeJong
autoconf configure.in > 2) configure > 3) make You don't need to. There is already a tcljava/configure file for just that reason (so you don't need to download autoconf). If you change the Tcl/Java configure.in file or other m4 files, you would need to rerun things. If you wanted t

[Tcl Java] Re: ajuba branch

2000-10-25 Thread Mo DeJong
On Wed, 25 Oct 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > >> > >> I'm running with the following: > >> > >> redhat 6.2 tcl8.3.2 tcljava from souceforge

[Tcl Java] Re: Error localiion

2000-10-25 Thread Mo DeJong
puts No > } > bash-2.04$ jaclsh /tmp/test.tcl > No > > So maybe, Frank is working on Windows and here the old > CR-LF error pops up again??? Yeah, that is most likely it. I should go put that up on the sourceforge task list for Jacl. Mo DeJong Red Hat Inc

[Tcl Java] Re: Error localiion

2000-10-25 Thread Mo DeJong
went wrong on, but that is about it. In C code, you can compile in things like the file a function is in, because a given function can't be defined more than once. Tcl (and any scripting language for that matter) is dynamic, so you can't really find this sort of thing out. Mo DeJong Red

[Tcl Java] Re: Package require java fails

2000-10-24 Thread Mo DeJong
bles should I > set for this? > Would appreciate if someone could help me on this. > Thanks > sai You should be starting a Java enabled Tcl shell using the jtclsh shell script. It gets installed into $INSTALL/bin when you run "make install". Mo DeJong Red Hat Inc -

[Tcl Java] Re: ajuba branch

2000-10-24 Thread Mo DeJong
ome/mo/project/tcl/unix/../generic/tclEvent.c:960 Since I do not see this is the IBM JDK, I am going to assume that it is a JDK 1.1.8 bug. I hear there is also a new JDK 1.2 and JDK 1.3 from blackdown, but I have not downloaded those for testing. Mo DeJong Red Hat Inc ---

[Tcl Java] Re: possible memory.

2000-10-24 Thread Mo DeJong
ression test suite, I think a --with-thread option that points to where the Thread extension is build is the only way to go. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscri

[Tcl Java] Re: List bug

2000-10-23 Thread Mo DeJong
nnot recover. > Addr: > 10037e63 I am seeing this bug even in the most recent CVS version. I would say this is a perfect time to try out the new bug DB on sourceforge. Go to: http://sourceforge.net/projects/tcljava The enter thi

[Tcl Java] Final try at improved CObject free patch.

2000-10-22 Thread Mo DeJong
sEvent(int flags) { +return 1; +} Any comments on changing InternalRep over to an interface or this approach to putting a CObject directly into the event queue? Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by

[Tcl Java] Tcl/Java project moves to sourceforge!

2000-10-22 Thread Mo DeJong
to close down the [EMAIL PROTECTED] mailing list in favor of using the ones on SF. Same goes for the old CVS repo. cheers Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscrib

[Tcl Java] Re: possible memory.

2000-10-22 Thread Mo DeJong
the cases is better than something that works for 0% of them. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word S

[Tcl Java] Re: possible memory.

2000-10-22 Thread Mo DeJong
ean that it would have to be possible to invoke a method on the object after the finalize() method had been run. cheers Mo DeJong Red Hat Inc Index: CObject.java === RCS file: /cvsroot/tcljava/tcljava/src/tclblend/tcl/lang/CObj

[Tcl Java] Re: possible memory.

2000-10-21 Thread Mo DeJong
tch is for src/tclblend/tcl/lang/CObject.java off of the contract branch. thanks Mo DeJong Red Hat Inc Index: CObject.java === RCS file: /cvsroot/tcljava/tcljava/src/tclblend/tcl/lang/CObject.java,v retrieving revision 1.1.1.1 diff -u

[Tcl Java] Re: possible memory.

2000-10-21 Thread Mo DeJong
hing for some time, so if you could take a whack at the Notifier it would really help. There is not going to be much overlap in these changes, so they can be done in parallel. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by

[Tcl Java] A new thread cache cleanup patch.

2000-10-21 Thread Mo DeJong
se the JNI->DestroyJavaVM method, but it is so chuck full of bugs that there really is no point in calling it at this time. JDK 1.2 added the ability to detach the main thread without calling DestroyJavaVM() so it really does not matter too much. Mo DeJong Red Hat Inc Ind

[Tcl Java] Re: possible memory.

2000-10-20 Thread Mo DeJong
thread safe. I think time would be better spent focusing on that right now instead of fighting ref counting. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mai

[Tcl Java] Re: thread cleanup - something that works

2000-10-17 Thread Mo DeJong
te And you got two right there! Perhaps it is a problem with some init code that is not getting run in the Tcl interp. What part of Tcl calls those callbacks? Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics

[Tcl Java] Re: [Tclblend] accessing inner class?

2000-10-17 Thread Mo DeJong
1 so that they did not have to change the VM spec. Rather ugly if you ask me. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] w

[Tcl Java] Re: leaking memory

2000-10-12 Thread Mo DeJong
ode. I thought you were talking about code that would only apply to aol server stuff. If it is possible to cleanly merge in your Tcl Blend init case, then I am all for that. Of course, I would need to see the patch first :) Mo DeJong Red Hat Inc --

[Tcl Java] Re: leaking memory

2000-10-12 Thread Mo DeJong
On Thu, 12 Oct 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > > > Mo> What do you mean by "The jvm attach is done at the start of > Mo> the thread by a registered proc"

[Tcl Java] Re: leaking memory

2000-10-12 Thread Mo DeJong
On Thu, 12 Oct 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > > Mo> There are two cleanup cases. > > Mo> TclThreadCleanup is called when a Tcl thread (one that was not > Mo&g

[Tcl Java] Re: leaking memory

2000-10-12 Thread Mo DeJong
On Thu, 12 Oct 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > > Mo> That does seem logical. It looks like the Class refs need to > Mo> be cleaned up. What do you think of the patch below?

[Tcl Java] Re: leaking memory

2000-10-11 Thread Mo DeJong
the new cache cleanup method is getting called when Tcl Blend is loaded into Tcl, but I am not sure what is going on when you load Tcl Blend and Tcl into a JVM. How could we test this sort of thing? Here is my proposed patch to cleanup the Class refs. I am also going to attach it to this file becaus

[Tcl Java] Re: xputil bug with patch

2000-10-09 Thread Mo DeJong
ersion of your patch into the contract branch (I just added another list command to an uplevel). cheers Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED

[Tcl Java] Re: Memory growth using Itcl and TclBlend

2000-10-09 Thread Mo DeJong
pp may just keep allocating memory without collecting it. In your Tcl example, nothing gets reparsed because the Tcl proc gets compiled and then called N number of times. Is the amount of memory used turning out to be a big problem? Have you profiled it with a Java memory tracing tool? Mo DeJon

[Tcl Java] Re: merge with aolserver

2000-10-09 Thread Mo DeJong
On Mon, 9 Oct 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > Mo> Humm, I think so but I can't remember off hand. The problem > Mo> with this "fix" is that it currently does not work.

[Tcl Java] Re: java::bind problem

2000-10-09 Thread Mo DeJong
ne is using Tcl/Java to access bean related info, but it would seem to be an area that may need some work. Would you be willing to invest some time improving the Java bean related documentation and perhaps add an example? There was an old bean example in version 1.0, but it was a pain and we ha

[Tcl Java] Re: merge with aolserver

2000-10-09 Thread Mo DeJong
talked about (like the free Tcl object enque thing) in the short term. After the notifier queue impl was fixed, things should be working well enough to be merged back into the HEAD branch. Then, the ref counting stuff could be worked on in isolation. Mo DeJong Red Hat Inc

[Tcl Java] Re: Question in running tclBlend demo

2000-10-04 Thread Mo DeJong
e Tcl command prompt. to create a new stop watch object and save a reference to the Tcl object, type: % set sw [swNew] To set the countdown time, type: % swSet $sw 10 Is that more clear? Mo DeJong Red Hat Inc --

[Tcl Java] Re: Accessing public parent fields

2000-09-14 Thread Mo DeJong
/msg00040.html The "quick fix" (where Quick != Correct) http://www.mail-archive.com/tcljava@scriptics.com/msg00492.html A discussion of the real fix, and why it is hard: http://www.mail-archive.com/tcljava@scriptics.com/msg00806.html Mo DeJong Red Hat Inc -

[Tcl Java] Bug report, Jacl's clock command

2000-09-12 Thread Mo DeJong
>From comp.lang.tcl: Submitted by: Oliver Springauf OperatingSystem: Windows NT Synopsis: Jacl clock command: integer overflow ReproducibleScript: % clock format [clock scan "10/02/1900"] Fri Nov 07 05:28:17 GMT+01:00 2036 ObservedBehavior: Jacl's (1.2.6) clock command returns the current

[Tcl Java] Re: JACL on windows.

2000-09-12 Thread Mo DeJong
not see any other way of addressing this issue. You might also want to try another JVM and see if that does anything. By the way, why would you use that MKS Toolkit when you could be using Cygwin? Mo DeJong Red Hat Inc The TclJava ma

[Tcl Java] Re: [Tcl Java]

2000-09-11 Thread Mo DeJong
On Mon, 11 Sep 2000, Peter Geraghty wrote: ... Peter, you are posting in HTML. This makes it very hard to read your email. Please repost in plain text if you want help. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored

[Tcl Java] Re: ANNOUNCE: SWANK 0.6 (Tcl/Tk ~= Jacl/SWANK)

2000-09-10 Thread Mo DeJong
JCheckBox.java:348: unreported exception tcl.lang.TclException; must be caught or declared to be thrown interp.untraceVar(getVarName(),commandListener,TCL.TRACE_WRITES| TCL.GLOBAL_ONLY); ^ 1 error make: *** [swank.jar] Error 1 Have you seen t

[Tcl Java] Re: Problems with TclBlend

2000-09-10 Thread Mo DeJong
acl until Tcl Blend is ready) 2. Pitch in. Help is always welcome. Tcl/Java is an open source project, so the more you pitch in the faster things will get done. A number of new folks have started to contribute to the project in recent months, and that has lead to a

[Tcl Java] Re: Tclblend..Trouble instantiating user defined java classes

2000-09-06 Thread Mo DeJong
or does NOT get generated. It sounds like you do not have the CLASSPATH set correctly. You can double check this by running "javap SampleClass" from the Tcl command line. If that prints something like "class not found" then you need to fix your CLASSP

[Tcl Java] Re: Problems Making TclBlend 1.2.6 on Windows 2000 (NT 5.0)

2000-09-06 Thread Mo DeJong
rce for this file somewhere? You need to have the source code for Tcl so that it can find tclInt.h. I assume you just downloaded the binary of Tcl and you are trying to build Tcl Blend from that. You might just want to download the binary or Tcl Blend in that case, but be w

[Tcl Java] Re: Installing and Building TclBlend

2000-09-05 Thread Mo DeJong
ts generated. You might have some strange JDK version that the configure script does not yet know about. I also suggest that you use the 1.3 version in the CVS if you are using some strange new JDK. Mo DeJong Red Hat Inc The TclJava ma

[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-28 Thread Mo DeJong
AOL parts of the code then I am interested in adding the code. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word S

[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-28 Thread Mo DeJong
On Mon, 28 Aug 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > Mo> On Wed, 23 Aug 2000, Daniel Wickstrom wrote: > >> I'm curious about the JavaInfo structure in javaCmd.c. When I >

[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-27 Thread Mo DeJong
moved the cache into thread local storage and reworked a bunch of stuff to support it. Things should be fully thread safe now. If you want to take another peek you are welcome to, of course you might have to wait until monday morning for the CV

[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-24 Thread Mo DeJong
On Thu, 24 Aug 2000, Daniel Wickstrom wrote: > >>>>> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > > Mo> So it looks like you are right, we need to put the method > Mo> cache in thread local storage. The contract branch is clearly

[Tcl Java] Re: request

2000-08-23 Thread Mo DeJong
tware. if > so VC++ is currently required to build under Windows. The next release will instead require Cygwin. You could always build Jacl under UNIX, the same .class files will work with both. Mo DeJong Red Hat Inc The TclJav

[Tcl Java] Re: global JavaInfo structure in threaded tclblend.

2000-08-23 Thread Mo DeJong
right, we need to put the method cache in thread local storage. The contract branch is clearly not finished, there is a lot of work that still needs to be done. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Script

[Tcl Java] Re: proble with ruuning coomands

2000-08-22 Thread Mo DeJong
the source release. Please look at some of the examples, they show how you need to call "package require java" before using the java::* commands. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics C

[Tcl Java] Re: ReflectObject

2000-08-22 Thread Mo DeJong
or this problem to the HEAD branch. The patch is as follows. Index: ChangeLog === RCS file: /home/cvs/external/tcljava/ChangeLog,v retrieving revision 1.59 diff -u -r1.59 ChangeLog --- ChangeLog 2000/08/21 04:48:11 1.59 +++ ChangeLog

[Tcl Java] Re: problem with instalation og jacl

2000-08-22 Thread Mo DeJong
set CLASSPATH=C:\jacl.jar;C:\tcljava.jar java tcl.lang.Shell Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SU

[Tcl Java] Re: Improvements of Jacl's clock command

2000-08-20 Thread Mo DeJong
und here: > http://me.in-berlin.de/~v12/krischan/clock8.4.patch > > Greetings, Krischan Checked in. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:se

[Tcl Java] Re: Last(?) steps for an InterpCmd in Jacl

2000-08-20 Thread Mo DeJong
easing memory consumption (this wasn't the > fact in my first implementation!). One would think that the Java GC system would be a bit smarter about this. Perhaps there is ref to a slave Interp that would need to get set to null before it could be GCed. Mo DeJong Red Hat Inc --

[Tcl Java] Re: Jacl: improved string command (now 8.4 compatible)

2000-08-20 Thread Mo DeJong
e can not glob for file names out of a .jar file. Does anyone feel up to hacking on this problem? It would not be very hard to implement and it would be really useful because folks could put their own packages into .jar files. Oh, by the way in case you are wondering how a "package

[Tcl Java] Re: jacl-yaci: (JACL Yet Another Command Improved)

2000-08-20 Thread Mo DeJong
&&, || or ?: now accept boolean string values. > - No error for [lreplace {} end end]. > - lsearch is 8.4 compliant. Each of these patches has now been checked in along with the updated lsearch and lreplace test cases from Tcl 8.4. Mo DeJong Red Hat Inc --

[Tcl Java] Re: Jacl: improved string command (now 8.4 compatible)

2000-08-20 Thread Mo DeJong
ooo). This string command was one of the most nasty bits, the other updates should be easy in comparison. I assume that some of these changes are tested by other tests and not just string.test. Mo DeJong Red Hat Inc The TclJava mai

[Tcl Java] Re: Error in (not yet published) Interp.java

2000-08-20 Thread Mo DeJong
ing. Does anyone want to donate one? I think I could swing a limited edition Source-Navigator shirt :) I just wish we could use the garbage collector instead of keeping that nasty Tcl_Preserve() stuff around in Jacl. Mo DeJong Red Hat Inc ---

[Tcl Java] Re: Jacl: "file extension" now 8.4 compatible

2000-08-20 Thread Mo DeJong
ked the patch in anyway, but we should fix the problem in Tcl 8.4. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word

[Tcl Java] Latest Interp patch.

2000-08-19 Thread Mo DeJong
ust call interp.resetResult() instead of using TCL.OK, what would the implications of that be? Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED]

[Tcl Java] Re: Problems with calling Java from TCL

2000-08-18 Thread Mo DeJong
es visible to Tcl Blend. Take a look at src/tcljava/tcl/lang/reflect/PkgInvoker.java for an example of how you can add a "special" class to you package so that Tcl Blend can access private parts. The actual tests for this are in tests/tcljava/PkgInvoker.test. I hope that helps Mo DeJong

[Tcl Java] Re: TclBlend Ref Counting Bug (GC related)

2000-08-14 Thread Mo DeJong
mented to 0 > 6. do not pass Tcl_Obj to other threads, this is not supported > by Tcl anyway > > With this fix, I dont' think there is a need to make the GC free Tcl_Obj. > > -- Jiang Wu >[EMAIL PROTECTED] Ahh,

[Tcl Java] Tcl Blend object refCount problems, seems like a design flaw.

2000-08-13 Thread Mo DeJong
t.toString() is called, if we wrapped a Tcl_Obj without incrementing its ref count, this should still work. The toString() call would invoke Java_tcl_lang_CObject_getString which would call Tcl_GetStringFromObj() (no problem there right). I am sure there are cases I have overlooked, but I think th

[Tcl Java] Locking down Tcl Blend so that it only works with threaded Tcl.

2000-08-13 Thread Mo DeJong
Here is that patch that I suggest we use to force Tcl Blend into compiling only with threaded Tcl. This will only appear in the contract branch for now. When that work is merged back into the HEAD, everyone will be forced to compile Tcl Blend with threaded Tcl. Comments? Mo DeJong Red Hat Inc

[Tcl Java] Yet another reason CObject can not be GCed.

2000-08-12 Thread Mo DeJong
he Interp does not enter the event queue (like tclsh). Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-09 Thread Mo DeJong
the best approach is to just lock down Tcl Blend so that it only builds with a Thread enabled Tcl. People are going to need to download an build Tcl and Tcl Blend, there is just no way around it. It would be better to just work on the "Tcl SDK" idea, a comm

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-09 Thread Mo DeJong
> It only pushes the problem to the user. That may be the only solution, but > it is very good in my mind. Well, the -D_REENTRANT thing is going to require a recompile of the extension, so I don't see how it is such a big deal. Mo DeJong Red Hat Inc -

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-09 Thread Mo DeJong
On Wed, 9 Aug 2000, Jiang Wu wrote: > > -Original Message- > > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, August 09, 2000 1:34 PM > > To: [EMAIL PROTECTED] > > Subject: [Tcl Java] Re: TclBlend Initialization Mutex > > > >

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-09 Thread Mo DeJong
On Wed, 9 Aug 2000, Scott Stanton wrote: > Mo DeJong said: > > It sure would make life easier if we just required Tcl > > threads to use Tcl Blend. The notifier thing would go > > away because we could count on threads being there. > > I'm all in favor of t

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-08 Thread Mo DeJong
load and build a threaded version of Tcl or use our special hacks. A "core patch" seems like a bad idea if you ask me. It sure would make life easier if we just required Tcl threads to use Tcl Blend. The notifier thing would go away because we could count on threads

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-08 Thread Mo DeJong
ds in the process. Sounds like a race condition dealing with ERRNO. I wonder if Tcl is not getting compiled without -D_REENTRANT or something. That seems unlikely. Tcl Blend just uses the CFLAGS set by Tcl. Mo DeJong Red Hat Inc T

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-08 Thread Mo DeJong
uring this 10 seconds. > > Is this what you get also? Nope, I am only seeing 1 event getting processed in that 10 second delay. P.S. I am goign to write up a better test using the test command and a max number of queues in the second thread. Mo DeJong Red Hat Inc -

[Tcl Java] Re: Possible patch: JavaGetEnv + threads

2000-08-08 Thread Mo DeJong
On 8 Aug 2000, Jiang Wu wrote: > On Tue, 08 August 2000, Mo DeJong wrote: > > Ok, I fixed that. Besides that, do you like the reorg? > > It looks good to me. Let's commit it to the branch. Done and done. M

[Tcl Java] Re: Possible patch: JavaGetEnv + threads

2000-08-08 Thread Mo DeJong
t;... >(*env)->ExceptionClear(env); >return TCL_ERROR; > > env can be NULL. Doh! Ok, I fixed that. Besides that, do you like the reorg? Mo DeJong Red Hat Inc The TclJava mai

[Tcl Java] Possible patch: JavaGetEnv + threads

2000-08-08 Thread Mo DeJong
old JavaGetEnv method is now called JavaInitEnv. Jiang, what do you think? I will check it into the contract branch if you give me the thumbs up on this patch. Mo DeJong Red Hat Inc Index: src/native/java.h === RCS file: /home/cvs

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-07 Thread Mo DeJong
On Mon, 7 Aug 2000, Jiang Wu wrote: > > From: Mo DeJong <[EMAIL PROTECTED]> > >> > java::call AppendEventQueueThread queueVwaitEvent [java::getinterp] > >> > >> Note: this will NOT block the C Tcl shell because you are just posting an > >> even

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-07 Thread Mo DeJong
On 7 Aug 2000, Jiang Wu wrote: > On Mon, 07 August 2000, Mo DeJong wrote: > > > > package require java > > set AQT [java::new AppendEventQueueThread [java::getinterp]] > > $AQT start > > set orig_numQueued [java::field $AQT numQueued] > > java::call Appen

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-07 Thread Mo DeJong
On 7 Aug 2000, Jiang Wu wrote: > On Mon, 07 August 2000, Mo DeJong wrote: > > Did a vwait in the callback that was added to the queue > > in Java (see source code). Then did a normal vwait on the > > command line. > > I am going to try your example tonight. Is th

[Tcl Java] Re: JavaGetEnv + Threads = mo going insane

2000-08-07 Thread Mo DeJong
On 7 Aug 2000, Jiang Wu wrote: > On Mon, 07 August 2000, Mo DeJong wrote: > > It looks like we might have another problem there. If we call JavaGetEnv() > > after Tcl Blend has been loaded into Java, the current thread > > (it is a Java created thread) would have already bee

[Tcl Java] Re: JavaGetEnv + Threads = mo going insane

2000-08-07 Thread Mo DeJong
On 7 Aug 2000, Jiang Wu wrote: > On Mon, 07 August 2000, Mo DeJong wrote: > > > >From section 3.2 in blendchanges.txt: > > > > load "tclblend", "tcl" .dll or .so (a) > > call "new Interp()" in Java > > invoke Java_

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-07 Thread Mo DeJong
On 7 Aug 2000, Jiang Wu wrote: > On Sun, 06 August 2000, Mo DeJong wrote: > > If I do 2 vwaits, then a single event is > > processed from the event loop, but that seems to be all. > > How did you do 2 vwaits? > > -- Jiang Wu >[EMAIL PROTECTED] Did a vwait in

[Tcl Java] JavaGetEnv + Threads = mo going insane

2000-08-07 Thread Mo DeJong
mp;javaVM_init_mutex); return TCL_OK; error: (*env)->ExceptionClear(env); +Tcl_MutexUnlock(&javaVM_init_mutex); return TCL_ERROR; } Any comments on this approach? I like it a bit better than grabbing the lock before calling JavaGetEnv or JavaSetupJava, the

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-06 Thread Mo DeJong
0 % set numQueued 0 % set numProcessed 0 So, that is good as I can now reproduce the problem. The new problem is that this bad behavior does not seem to go away after your Notifier patch. If I do 2 vwaits, then a single event is processed

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-06 Thread Mo DeJong
ield $AQT killed 1 When I ran this example, it did not deadlock in the Notifier.queueEvent() method. Here is the output I got: % set orig_numQueued 0 % set numQueued 9 % set numProcessed 9 This shows that the other thread continued to run when the main thread was inside a vwait.

[Tcl Java] Re: problems using javax.swing.Dialog classes in tcljava

2000-08-02 Thread Mo DeJong
at shows a dialog. The "fix" is to call the show command with the unsupported::jdetachcall command. It will spawn another thread that will block in the dialog show call. This might seem like a hack, but it is the same one the AWT uses. cheers Mo DeJong Red Hat Inc

[Tcl Java] Re: Problem Loading TclBlend

2000-08-01 Thread Mo DeJong
iled me, but binary distros have a lot of problems. 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

[Tcl Java] Re: Problem Loading TclBlend

2000-08-01 Thread Mo DeJong
t your posted seems to indicate that the paths your are using are exactly the same as the example paths, which might just be by chance. This "init" error typically means it can not find a Java shared lib for some reason. Mo DeJong Red Hat Inc

[Tcl Java] Re: [Fwd: Next steps to a Jacl interp command.]

2000-08-01 Thread Mo DeJong
too). I am not sure if this was caused by your inter changes. Could you double check to make sure nothing you did caused this? I am too sleepy to do it right now. Once we get these issues resolved, I can check in your patch, it is kind of large so I don't want to rush on this one. Mo DeJon

[Tcl Java] Re: Jacl: Very first steps to a new interp command

2000-07-31 Thread Mo DeJong
.getChanName()); + + if (--chan.refCount <= 0) { 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

[Tcl Java] Threaded Tcl Blend to become a reality.

2000-07-30 Thread Mo DeJong
cl Blend building on windows. I have removed all the JAVA_LOCK calls and implemented the JNIEnv as thread local storage. Further developments will be posted to the tcljava mailing list as they happen. cheers Mo DeJong Red Hat Inc The

[Tcl Java] Tcl/Java reflect table memory usage cut in half.

2000-07-29 Thread Mo DeJong
, this fix should cut down the amount of memory your application requires by quite a bit. I don't know how much memory this will save in a "typical application", folks are welcome to report and positive or negative results they get after this change. cheers Mo DeJ

[Tcl Java] Re: Tcl Call Stack

2000-07-27 Thread Mo DeJong
d. You might want to look at TclX, it has a set of "profile" commands that record each call made and report them to you in an array. That might be your best bet, but it will only work with Tcl Blend. http://www.neosoft.com/tclx/ I hope that helps Mo DeJong Red Hat Inc -

[Tcl Java] Re: Interrupting a Interp.eval()

2000-07-27 Thread Mo DeJong
dd an API that would let you kill a thread from another thread, but it was later removed because it was a disaster. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:sen

[Tcl Java] Re: Multiple Tcl.lang.Interp in a single JVM

2000-07-27 Thread Mo DeJong
On Thu, 27 Jul 2000, Mo DeJong wrote: > On Thu, 27 Jul 2000, Brent Welch wrote: > > > > > >>>Mo DeJong said: > > > > > Could you guys make a couple of changes to the tcljava mailing list? > > > For one thing, it rewrites the headers when it

[Tcl Java] Re: Multiple Tcl.lang.Interp in a single JVM

2000-07-27 Thread Mo DeJong
On Thu, 27 Jul 2000, Brent Welch wrote: > > >>>Mo DeJong said: > > > Could you guys make a couple of changes to the tcljava mailing list? > > For one thing, it rewrites the headers when it should not. This leads > > to really long subject lines when peopl

[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Multiple Tcl.lang.Interp in a single JVM

2000-07-26 Thread Mo DeJong
use you help on that. Don't be afraid to download the CVS tree and rewrite any documentation you find confusing. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send ma

[Tcl Java] Re: [Tcl Java] problem invoking tcl Blend calls from within Java threads

2000-07-25 Thread Mo DeJong
. If not, create the interpreter, assigns > it a thread, starts the event listener, and returns the Interp. I am not sure I like this one as much. The interp class should really only contain APIs that work with both Jacl and Tcl Blend. Mo DeJong Red Hat Inc ---

  1   2   3   4   >