[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

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

2000-10-30 Thread Mo DeJong
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 mail to [EMAIL PROTECTED] with the

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

2000-10-29 Thread Mo DeJong
ver:[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 mail

[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 at the Mo Notifier it would really help. There is

[Tcl Java] Re: autoconf 2.14

2000-10-26 Thread Mo DeJong
.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 to do that, you would run the ./autogen.s

[Tcl Java] Re: compiling tcljava

2000-10-26 Thread Mo DeJong
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, but perhaps someone else who has done some autotools hacking would like to beat me t

[Tcl Java] Re: ajuba branch

2000-10-26 Thread Mo DeJong
ore? Perhaps get a stack trace and print it to see where things are going wrong. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED]

[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. I'm using tcl version 8.3.2. Strange, perhaps I

[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 ajuba contract branch blackdown jdk1.1.8_v1 Mo That really should work, ever

[Tcl Java] Re: possible memory.

2000-10-24 Thread Mo DeJong
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 subscribe:send mail to [EMAIL PROTECTED

[Tcl Java] Re: ajuba branch

2000-10-24 Thread Mo DeJong
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 The TclJava ma

[Tcl Java] Re: List bug

2000-10-23 Thread Mo DeJong
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 this in the bug tracker. cheers Mo DeJong Red Hat Inc The TclJava

[Tcl Java] Re: possible memory.

2000-10-22 Thread Mo DeJong
% of 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

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

2000-10-22 Thread Mo DeJong
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 subscribe:send mail

[Tcl Java] Re: possible memory.

2000-10-21 Thread Mo DeJong
one quick press of the delete button will finish it off. Are you up to it? I am going to be working on this object ref queue thing 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 pa

[Tcl Java] Re: possible memory.

2000-10-21 Thread Mo DeJong
it with some tests under JDK 1.1 and it is working (with one small exception). Could some folks to try this out and see if it makes the crash in the GC thread problem go away? There should be no more memory leaks. The patch is for src/tclblend/tcl/lang/CObject.java off of the contract branch. thanks Mo

[Tcl Java] Re: possible memory.

2000-10-20 Thread Mo DeJong
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 mail to [EMAIL PROTECTED

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

2000-10-17 Thread Mo DeJong
Flags.Flag DELETED] does not work, neither does [java::field javax.mail.Flags Flag.DELETED]. I think you want to use: java::field javax.mail.Flags\$Flag DELETED It is a wacky hack that the Java designers decided to throw into 1.1 so that they did not have to change the VM spec. Rather ugly if you a

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

2000-10-17 Thread Mo DeJong
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 Corporation. To subscribe

[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 started inside a JVM) is terminated. TclThreadCleanup will Mo

[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"? Are you not using: Mo (*javaVM)-AttachCurrentThread()

[Tcl Java] Re: leaking memory

2000-10-12 Thread Mo DeJong
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 The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL

[Tcl Java] Re: leaking memory

2000-10-11 Thread Mo DeJong
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 because it is going to get hosed in mail. Mo DeJong Red Hat Inc

[Tcl Java] Re: java::bind problem

2000-10-09 Thread Mo DeJong
d 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 had no "bean expert" on the team so it w

[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. There are Mo strange crashes when ru

[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

[Tcl Java] Re: Question in running tclBlend demo

2000-10-04 Thread Mo DeJong
e 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 The TclJav

[Tcl Java] Re: Accessing public parent fields

2000-09-14 Thread Mo DeJong
sg00490.html http://www.mail-archive.com/tcljava@scriptics.com/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@

[Tcl Java] Re: JACL on windows.

2000-09-12 Thread Mo DeJong
. 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 mailing list is sponsored by Scriptics Corporation

[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: Problems with TclBlend

2000-09-10 Thread Mo DeJong
ys 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 number of great new features. Mo DeJong R

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

2000-09-06 Thread Mo DeJong
urce 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 warned that the binary has its own troubles. M

[Tcl Java] Re: Installing and Building TclBlend

2000-09-05 Thread Mo DeJong
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 mailing list is sponsored

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

2000-08-28 Thread Mo DeJong
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 SUBSCRIBE as the subject. To unsubscribe: send mail

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

2000-08-27 Thread Mo DeJong
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 CVS mirror to update. Mo DeJong Red Hat Inc

[Tcl Java] Re: problem with instalation og jacl

2000-08-22 Thread Mo DeJong
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 unsubscribe: send mail to [EMAIL

[Tcl Java] Re: ReflectObject

2000-08-22 Thread Mo DeJong
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 2000/08/23 05:51:29 @@ -1,3 +1,10 @@ +2000-08-22 Mo DeJong [EMAIL PROTECTED] + +

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

2000-08-20 Thread Mo DeJong
ay, 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 SUBSCRIBE as t

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

2000-08-20 Thread Mo DeJong
tor 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 The TclJava mailing list is sponsored by Scriptics Corporati

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

2000-08-20 Thread Mo DeJong
er 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 mailing list is sponsored by Scriptics Corporation. To subscribe:

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

2000-08-20 Thread Mo DeJong
ar 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 require java" works, it is faked bec

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

2000-08-20 Thread Mo DeJong
t in a loop without increasing 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. M

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

2000-08-20 Thread Mo DeJong
-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:send mail to [EMAIL PROTECTED

[Tcl Java] Latest Interp patch.

2000-08-19 Thread Mo DeJong
f 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] with the word SUBS

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

2000-08-18 Thread Mo DeJong
al tests for this are in tests/tcljava/PkgInvoker.test. I hope that helps Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED]

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

2000-08-14 Thread Mo DeJong
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 the idea is doable. What do

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

2000-08-14 Thread Mo DeJong
onclusions. I wanted to take my own look at the problem and see if my solution matched yours. Now that I see we both think this is the right solution, I feel much better about it. Mo DeJong Red Hat Inc The TclJava mailing list is sp

[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
nterp 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 SUBSCRIBE as the sub

[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 this. As the threaded version of Tcl becomes

[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 Con: Non-thread safe extensions may have problems under

[Tcl Java] Possible patch: JavaGetEnv + threads

2000-08-08 Thread Mo DeJong
. The 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: Possible patch: JavaGetEnv + threads

2000-08-08 Thread Mo DeJong
)-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 mailing list is sponsored by Scriptics Corporation. To subscribe:send mail

[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. Mo DeJong Red Hat Inc

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-08 Thread Mo DeJong
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 The TclJava mailing list is sponsored

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-08 Thread Mo DeJong
s 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 The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:

[Tcl Java] Re: TclBlend Initialization Mutex

2000-08-08 Thread Mo DeJong
ed 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 being there. M

[Tcl Java] JavaGetEnv + Threads = mo going insane

2000-08-07 Thread Mo DeJong
aVM_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 code seems a bit more clean with the synchronization inside the methods. Mo DeJong Red Hat Inc ---

[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 the callback that was added to the queue

[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_lang_Interp_create() C function (b) ca

[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 this what you mean by doing a normal

[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 AppendEventQueueThread queueVwaitEvent [java::getinterp

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-06 Thread Mo DeJong
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. Mo DeJong Red Hat Inc -

[Tcl Java] Re: TclBlend Patch 8/5

2000-08-06 Thread Mo DeJong
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 from the event loop, but that seems to be all.

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

2000-08-01 Thread Mo DeJong
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 DeJong Red Hat Inc

[Tcl Java] Re: Problem Loading TclBlend

2000-08-01 Thread Mo DeJong
sing 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 The TclJava mailing list is sponsored by

[Tcl Java] Re: Problem Loading TclBlend

2000-08-01 Thread Mo DeJong
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 subject

[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 DeJong R

[Tcl Java] Re: Tcl Call Stack

2000-07-27 Thread Mo DeJong
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 The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to

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

2000-07-26 Thread Mo DeJong
. 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 mail to [EMAIL PROTECTED]

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

2000-07-25 Thread Mo DeJong
I am open to suggestions as to how we could help people to not make this mistake in the future. I think better documentation is the best approach, but writing docs is boring so folks do not seem to want to help with that. Mo DeJong R

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

2000-07-25 Thread Mo DeJong
to easily turn code on and off automatically (ala #ifdef) in Java. You can use final booleans to get the same behavior, but folks would need to go in and turn these extra checks on, so that kind of defeats the purpose. Mo DeJong R

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

2000-07-25 Thread Mo DeJong
pe the system in Jacl and move to Tcl Blend when the thread work is finished. Jacl does threads a lot better than Tcl Blend, at least for now. You should not have to rewrite anything, both Jacl and Tcl Blend support the same Tcl/Ja

[Tcl Java] Re: [Tcl Java] Test suites using Jacl

2000-07-21 Thread Mo DeJong
Rajeev, you are posting in HTML. That is not allowed on this list. Please disable HTML posting in your email client before posting again. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation

[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] calling Tcl from Java (starting Java first)

2000-07-21 Thread Mo DeJong
y to debug it? You might also want to try building tclexpat.so with stubs support. That might work a little better. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail

[Tcl Java] Re: [Tcl Java] calling Tcl from Java (starting Java first)

2000-07-20 Thread Mo DeJong
. The problems you describe sound like your env vars are not set correctly. Try running "make shell" and then invoke "java ..." from inside the shell, that should set up the env vars correctly. later Mo DeJong Red Hat Inc The

[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] tclBlend / tcl thread workaround

2000-07-18 Thread Mo DeJong
... A post written in HTML ... Please do not post to the tcljava list in HTML. People will text email clients can not read what you are posting! Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation

[Tcl Java] Re: [Tcl Java] RFC: changing the package name from java to tcljava?

2000-07-17 Thread Mo DeJong
, it would be no big deal, but I can't see the real benefits... I am not saying it would save the world, I just think it would make it easier to explain the "shared code" that is used by both Jacl and Tcl Blend. This has always been hard to explain to new users. Mo DeJong Red Hat Inc

[Tcl Java] Re: [Tcl Java] clock command in Jacl: Now 8.3 compliant

2000-07-16 Thread Mo DeJong
really should post a note to comp.lang.tcl about the new stardate support in Jacl. I am sure there are lots of people that are holding off using Jacl because of the lack of startdate support :) Mo DeJong Red Hat Inc The TclJava

[Tcl Java] Re: [Tcl Java] problems using tclBlend with Tcl threading

2000-07-14 Thread Mo DeJong
- 380 code = TCL_ERROR; - 381 goto done; 382 } - 383 } else { - 384 code = (*pkgPtr-initProc)(target); 385 } It seems to want to call Tcl_PakcageInitProc. Does anyone have any ideas on

[Tcl Java] Does Tcl Blend need to build with a shared Tcl?

2000-07-13 Thread Mo DeJong
? As long as Tcl is built with support for the load command, I don't think it would be a problem. Of course, you would not be able to load Tcl + Tcl Blend into a JVM if it was not build as a shared library, but that is fine. Mo DeJong Red Hat Inc

[Tcl Java] RE: [Tcl Java] Does Tcl Blend need to build with a shared Tcl?

2000-07-13 Thread Mo DeJong
-aware. David Gravereaux sent out an email to the TEA mailing list about a mechanism that would allow TclBlend to find the Tcl DLLs and load the stub table (when loading blend from the JVM). Sounds good. Could you repost that email to this list. Better yet, a patch to implement Davids approach. Mo

[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Small test case

2000-06-29 Thread Mo DeJong
On Thu, 29 Jun 2000, Dr Wes Munsil wrote: Mo DeJong wrote: There is no "compile time" in Tcl, it is all dynamic, ... Exactly my point. Consider these two code snippets, which I assume you agree are correct uses of newInstance(): B x = new C (); ReflectObject.newInstan

[Tcl Java] Re: [Tcl Java] Threading in tclblend.

2000-06-29 Thread Mo DeJong
Jacl and Tcl Blend for people to bang on. 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 subje

[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Small test case

2000-06-29 Thread Mo DeJong
yone called getClass() everywhere without realizing how it could hose things up, that would be bad. Mo DeJong Red Hat Inc The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail

[Tcl Java] Serious Tcl/Java error, need help testing JVMs

2000-06-29 Thread Mo DeJong
invalid entry, ... I tested this under JDK 1.1.8 from Blackdown and Kaffe and there was no problem with either of those JVMs (I ran the test for several hours). thanks Mo DeJong Red Hat Inc ReflectCrash.zip

[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend pr oblem?

2000-06-29 Thread Mo DeJong
r own "lock and unlock" on top of the existing reflection system. In fact, that is exactly what the java::lock and java::unlock commands are for. The only reason they were added was because of this exact problem. I think we need to change Tcl to support "loc

[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Small test case

2000-06-29 Thread Mo DeJong
On Thu, 29 Jun 2000, Jeff Sturm wrote: Mo DeJong wrote: Here is another example: import java.util.Hashtable; public class Hashtable2 extends Hashtable { public static Hashtable get() { return new Hashtable2(); } public void NEVER_CALL() { System.out.println

[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Small test case

2000-06-28 Thread Mo DeJong
On Wed, 28 Jun 2000, Dr Wes Munsil wrote: Mo DeJong wrote: Objects do not have types, references to objects determine what behavior the object will provide. In Tcl/Java you don't really have a reference but you "reflect" an object as a type. You need to pass in the java.

[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend pr oblem?

2000-06-28 Thread Mo DeJong
fix it Tcl would need to be extended so that it supported another sort of internal rep that could not be disposed of. I talked with Paul Duffin about this sort of thing at the last Tcl conference. He is doing something similar called "feather". It is an interesting area, but I have not had m

[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] preserve/release or use GC

2000-06-27 Thread Mo DeJong
is in the TclList class. I guess this was done so that a Tcl List would not need to get converted to a Java Vector if it was to be used from Java code. Are TclList internal reps the only area where we have a problem? I think that is the case but I am not sure. Mo DeJong Red Hat Inc tcllist.png

[Tcl Java] Re: [Tcl Java] Small test case

2000-06-27 Thread Mo DeJong
not do that! You really need to know the type of the object you are going to reflect. If you just call o.getClass() it could be anything. I don't know if this is related to the problem you are running into, but it is a really bad idea. Mo DeJong Red Hat Inc

[Tcl Java] Re: [Tcl Java] preserve/release or use GC

2000-06-27 Thread Mo DeJong
TclObject(TclString rep, String s) { internalRep = rep; stringRep = s; refCount = 0; } Seems like that might be the cause of some big problems. I think this was something that was changed in Tcl sometime after Tcl 8.0. Mo DeJong R

[Tcl Java] Re: [Tcl Java] Access to public baseclass data members via Jacl

2000-06-23 Thread Mo DeJong
ually breaks a couple of other things in the test suite so it is not going to be checked in, but you can use it on your own tree. The "real" fix is going to take some time to implement, and I am not going to be able to get to it for at least a month. Mo DeJong Red Hat Inc I

[Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?

2000-06-23 Thread Mo DeJong
a C pointer inside a Java long. It then converts this back to a pointer that is uses to find the actual object (yes it is scary and wrong, but JNI sucks so we are stuck with it). Also, that convert a pointer to a string and back again trick would not work if you were using a GC for your C code. Mo

[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] another deadlock

2000-06-19 Thread Mo DeJong
d by Tcl. Of course, this means we would need a thread enabled Tcl. 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: [Tcl Java] Re: [Tcl Java] another deadlock

2000-06-19 Thread Mo DeJong
On Mon, 19 Jun 2000, Jeff Sturm wrote: Mo DeJong wrote: I think this one is along the same lines. The finalizer thread seems to be called decrRefCount() which is calling FreeTclObject(). I think we need a more general solution to the problem of the finalizer thread walking

[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] another deadlock

2000-06-19 Thread Mo DeJong
On Mon, 19 Jun 2000, Jeff Sturm wrote: Mo DeJong wrote: What is a "thin lock"? Did you mean spin lock? I don't see what is wrong with a good old mutex, but putting one in means we would need to require a thread safe version of Tcl. I don't really like the "use the JV

[Tcl Java] New patch for loading of TclBlend from Java

2000-06-15 Thread Mo DeJong
o solve some other deadlocking problems, but at least it loads without a SIGSEGV now :) Mo Dejong Red Hat Inc. The TclJava mailing list is sponsored by Scriptics Corporation. To subscribe:send mail to [EMAIL PROTECTED]

[Tcl Java] Re: [Tcl Java] problem with creating a thread

2000-06-15 Thread Mo DeJong
{ mInterp = interp; } 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 uns

  1   2   >