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
Thanks. I'll use Jacl for now and switch to TclBlend when it's ready. If
there is anything I can do to help, let me know.
The current Tcl Blend code does not work with multiple Tcl threads.
There is a plan in place to remedy this situation, but we
will not be able to post the details until
On Wed, 26 Jul 2000, Marc Saegesser wrote:
Thanks. I'll use Jacl for now and switch to TclBlend when it's ready. If
there is anything I can do to help, let me know.
The best thing you can do as a "new user" is to keep a detailed log
of what problems you run into and what insights you have.
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Resent-From: [EMAIL PROTECTED]
X-Mailing-List: [EMAIL PROTECTED] archive/latest/1044
X-Loop: [EMAIL PROTECTED]
Resent-Sender: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls from
within
Java threads
Hi
On Tue, 25 Jul 2000, Mike Schwartz wrote:
Hmm, I just realized that the issue is the Interp.eval code isn't thread
safe, so it just needs to run in a single Java thread (not necessarily the
Java main thread). So the code I suggested below won't work but you get the
idea -- have the code
: Mo DeJong [EMAIL PROTECTED]
To: Mike Schwartz [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: [Tcl Java] Re: [Tcl Java] problem invoking tclBlend calls
from within Java threads
On Tue, 25 Jul 2000, Mike Schwartz wrote:
Hmm, I just realized that the issue is the Interp.eval
On Tue, 25 Jul 2000, Mike Schwartz wrote:
Well, this is a matter of personal taste I suppose, but in my view
making non-threadsafe code in this day-and-age, especially code that is
intended to interoperate with a language (Java) that is designed to
make it easy to build threaded apps, is
I think if it's going to be non-thread safe then the code should sanity
check for thread-crossing calls, perhaps with #ifdef's so performance
concerns can be removed for people who don't want the sanity checks.
I like this approach, but the problem is that there is no way to
easily
, and returns the Interp.
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 25, 2000 3:58 PM
To: Mo DeJong
Cc: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] problem invoking
tclBlend calls from within
-Original Message-
From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
I thought it was the JNI / C code side that wasn't thread
safe. You're
saying it's the Interp pure Java code that's the problem? In
that case
you could define an abstract class with all the Interp interfaces
On Tue, 25 Jul 2000, Marc Saegesser wrote:
I just noticed in Jiang Wu's excellent "Embedding a Tcl Interpretter in
Java" article
(http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html) the
following paragraph in the "Other Issues" section:
TclBlend 1.2 does not support multiple
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.
To
Hi,
I decided to give the patch Mo mentioned below a try. It works when I
try it with Java executing some simple Tcl commands, but now I'm trying
to use it with some pretty complex Tcl packages, and I get a
tcl.lang.TclException that says:
couldn't load file
On Fri, 21 Jul 2000, Mike Schwartz wrote:
Hi,
I decided to give the patch Mo mentioned below a try. It works when I
try it with Java executing some simple Tcl commands, but now I'm trying
to use it with some pretty complex Tcl packages, and I get a
tcl.lang.TclException that says:
I decided to give the patch Mo mentioned below a try. It works when I
try it with Java executing some simple Tcl commands, but now I'm trying
to use it with some pretty complex Tcl packages, and I get a
tcl.lang.TclException that says:
couldn't load file
Does tclBlend require that Tcl be the first to start? If that's not the
problem, does anyone know what the problem is? My LD_LIBRARY_PATH contains
/usr/local/lib/tcljava1.3.0, which is where my libtclblend.so lives.
That is something that should work, but it is rather new
and untested and
You can do:
Tcl Thread A - package require java - start JVM ...
Tcl Thread B - send request to Tcl thread A for Java work using
message passing on the event queue of A
Tcl Thread C - send request to Tcl thread A for Java work ...
...
To share a single JVM using a
... 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
1:21 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] RE: [Tcl Java] tclBlend /
tcl thread
workaround
... A post written in HTML ...
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe
Hmm, that sounds like it would work. Let me think some
more about using an approach like this.
Thanks for the suggestion
- Mike
(I have enclosed Jiang's msg below, for the non-HTML-groking emailers on
this list)
At 12:48 PM 07/18/2000, Jiang Wu wrote:
You are correct that the code can block if
Hello,
I am thinking that it might be good to change the name of
the Tcl package for Tcl/Java related things to tcljava
instead of java.
I like the package name "java".
IMHO the interfaces to other systems don't need to contain the
string Tcl, since as a Tcl-script writer I know that I'm
On Mon, 17 Jul 2000, Christian Krone wrote:
Hello,
I am thinking that it might be good to change the name of
the Tcl package for Tcl/Java related things to tcljava
instead of java.
I like the package name "java".
IMHO the interfaces to other systems don't need to contain the
string
On Thu, 13 Jul 2000, Christian Krone wrote:
To fight my frustation I made some changes to the ClockCmd
class, so that the Jacl clock now is capable of all the
new 8.3 formats. Even the stardate format is implemented!
Enjoy, Krischan
I just did a CVS commit of these patches. Krischan, you
Sorry Mo, I should have remembered this from the last time. Unfortunately,
because the Sun JDK comes with Solaris, that's what I am resigned to using.
--
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden mailto:[EMAIL PROTECTED] URL: http://www.purl.org/NET/lvirden/
Would it be worthwhile for these tests to generate a msg when the test case
sees what it is using that marks the test case as a known problem?
--
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden mailto:[EMAIL PROTECTED] URL: http://www.purl.org/NET/lvirden/
Unless
On Fri, 14 Jul 2000, Mike Schwartz wrote:
Hi,
Hi Mike.
I am using Tcl 8.3.0 with tclBlend 1.3.0 (with the code for the testthread
command compiled in) and Java JS2E v1.3 beta. When my software first
starts, I need to invoke a static Java method, and then later I need to
spawn a Tcl
If TclBlend was built with Tcl stubs, then it would
work fine. Otherwise, TclBlend needs to be linked
against a dynamic build of Tcl and a dynamic JVM.
The code in blend will do a LoadLibrary of itself,
so TclBlend needs to be dynamic as well...
Let's make it stubs-aware.
David Gravereaux sent
On Thu, 13 Jul 2000, Scott Redman wrote:
If TclBlend was built with Tcl stubs, then it would
work fine. Otherwise, TclBlend needs to be linked
against a dynamic build of Tcl and a dynamic JVM.
The code in blend will do a LoadLibrary of itself,
so TclBlend needs to be dynamic as well...
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.newInstance (interp,
On Thu, 29 Jun 2000, Daniel Wickstrom wrote:
I've been experimenting with integrating tclblend into aolserver, and
after looking at the tclblend code, I'm a little puzzled about
something. In javaCmd.c the variable java declared as type JavaInfo
and currentEnv are declared as global
usages of
ReflectObject.newInstance() I *want* the most derived class, I do not want
the class that it extends from.
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 8:06 PM
To: Dr Wes Munsil
Cc: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl
On Thu, 29 Jun 2000, Thomas McKay wrote:
But let's assume that I do indeed want the most derived class.
Seems kind of dangerous, but Ok.
If I change this.getClass() to DbObj.getClass(), then the Tcl objects
returned from this method will only have DbObj's methods and fields exposed,
right?
"Mo" == Mo DeJong [EMAIL PROTECTED] writes:
Mo The startup stuff is kind of tricky because we need to support
Mo two different kinds of loading. Tcl Blend can be loaded from
Mo Tcl, whick will then load the JVM. Tcl Blend can also be
Mo loaded from a JVM, this means Tcl Blend
Test ran to completion with Sun's JDK 1.1.8 on Solaris, no errors.
Mo DeJong wrote:
Now don't panic, but it looks like we have uncovered
a serious JVM bug in Sun derived JVMs = 1.2 that
nukes the Tcl/Java reflect table. Lots of
thanks go to Thomas McKay for tracking down and
creating a
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("NEVER_CALL");
}
}
% set h [java::call
On Thu, 29 Jun 2000, Jiang Wu wrote:
I just hope people realize that the reflected Java objects in Tcl are not
the same as any other Tcl objects. The problem is that these reflected
objects are presented as "normal Tcl objects". They are syntactically
compatible with other Tcl objects. As
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Care to submit some docs patches? We could also use some "Tcl/Java
in action" examples. Nice little examples that do something
cool and show how to use the java::* commands would really
be great. Would anyone be able to
Am I missing something? I do not see this behavior in the 8.2.3 Tcl shell:
% proc fern {} {
set x [java::new String foo]
after 1 "$x toString"
unset x
update
}
% fern
bgerror failed to handle background error.
Original error: invalid command name "java0x1"
Error in bgerror: invalid
To: Jiang Wu
Cc: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
Am I missing something? I do not see this behavior in the
8.2.3 Tcl shell:
% proc fern {} {
set x [java::new String foo]
after 1 "$x toString"
unset x
update
}
% f
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Yes, but if you read on you will see that I also tried your proposed
workaround, and it gave the same error.
But the script does work under Tcl 8.3.1. I need to point out that my 2nd
script is NOT a "workaround". It
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.lang.Class
Mo DeJong wrote:
It depends on what you are doing. In regular Java, you need to know
what the type of the objects you put into a vector are because
you need to cast them back up to something when you pull them
out of the vector. TclJava is no different, you just put the
class you would cast
On Wed, 28 Jun 2000, Jiang Wu wrote:
But the script does work under Tcl 8.3.1. I need to point out that my 2nd
script is NOT a "workaround". It is not a workaround because you can't
convert all callback scripts into this list form; it is not the normal way
of writing Tcl; and you can't
I converted all TclList.index(..).toString() into a safer manner using
preserve/release. Then I ran through the tclblend test suite. The bad news
is that there are still hundreds of Tcl_Obj's being leaked.
The tcljava code uses many temporary TclObjects. A few examples of how
these temporary
A different solution is needed. What about never returning any CObjects in
TclBlend? Methods such as interp.setVar, interp.getVar, interp.getResult
still returns TclObject, but the resulting TclObject would not contain
CObject as the internal rep. For example, any Tcl_Obj can be converted
ECTED]
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 27, 2000 3:46 PM
To: Jiang Wu
Cc: '[EMAIL PROTECTED]'
Subject: Re: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] preserve/release
or use GC
Now there is an interesting idea. Check out the attached
scre
Something has been bothering me about this ref counting stuff for
some time. It just seems like the TclJava ref counting does not
work like regular Tcl ref counting, but I could not put my
finger on exactly why.
I was just looking at the C code, and I noticed that "regular"
Tcl ref counts start
Jiang Wu wrote:
TclObject listElement = TclList.index(...);
listElement.preserve();
listElement.toString();
listElement.release();
This doesn't seem too horrible...
Or we can try to fix the CObject finalize. I propose something like this:
[...]
Any
So far, I have not been able to do so. I see it in StoryServer, but have not even
been able to reproduce it under the Tcl shell yet. And the StoryServer template is
many thousands of lines, after processing INCLUDEs.
Mo DeJong wrote:
Could you create a small script and a .java file that
Hello Frank,
how can I access a public baseclass attribute in a Java class via Jacl,
when an object of derived class is instanciated ?
public class baseClass { public String dummyAttribute; }
public class derivedClass extends baseClass { /* anything */ }
set theDerivedObj [java::new
PROTECTED] mailto:[EMAIL PROTECTED]
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 23, 2000 1:19 PM
To: Frank Krahmer
Cc: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] Access to public baseclass data
members via Jacl
On Fri, 23 Jun 2000, Frank
On Fri, 23 Jun 2000, Frank Krahmer wrote:
Dear Sir,
how can I access a public baseclass attribute in a Java class via Jacl,
when an object of derived class is instanciated ?
Java-class example :
public class baseClass
{ public String dummyAttribute;
}
public
...
I am encountering this problem right now in a different form. I am
constructing an asynchronous callback function inside Java using a TclList
object, {command_name java_obj_1 java_obj_2}. The list contains some Java
objects, which are the arguments to the callback function. However,
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 23, 2000 3:15 PM
To: Jiang Wu
Cc: [EMAIL PROTECTED]
Subject: Re: [Tcl Java] A Tcl or TclBlend problem?
You mentioned that doing an after with a list object solved
the problem,
but here you are
Dr Wes Munsil wrote:
Thoughts, opinions, wild guesses encouraged.
More debug info would be nice. Any chance you can send a SIGKILL to
this process and capture stderr? If not, you might be able to find the
address of the signal handler function and invoke it from gdb.
--
Jeff Sturm
[EMAIL
On Mon, 19 Jun 2000, Jiang Wu wrote:
Would the GC problem still exist if the underlining Tcl is thread enabled?
In other words, is it OK to call "FreeTclObject()" from any thread in the
thread enabled Tcl?
It may not be a good idea to block the GC thread. For this scheme to work,
one
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 into an
Mo DeJong wrote:
I am not sure what volatile has to do with anything. I was under the
impression those were for serialization.
Volatiles are potentially useful because loads/stores are guaranteed to
occur in order (if the VM is implemented correctly). There are certain
idioms based on
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 JVM to do locking" hacks in there now. Using
the JVM to do locking
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 JVM to do locking"
Mo DeJong wrote:
Ahh, but Tcl provides a portable locking layer when compiled with
threads support. That is what I am sugesting we use for the mutex.
OK, I hadn't thought of that. (I am trying to augment my Java code with
Tcl, not the other way around... that colors my viewpoint a bit.)
If
So, pardon my desperation, but are you gentlemen going to save my job and give
me a TclBlend 1.2.5 patch to try out?
Jeff Sturm wrote:
Mo DeJong wrote:
Ahh, but Tcl provides a portable locking layer when compiled with
threads support. That is what I am sugesting we use for the mutex.
OK,
thanks for your help, i've tried what you've suggested and it helped a bit
now i don't seem to get tclblend to load.
i saw someone else struggled with it, and the remedy was
"JRE/bin/classic directory in your PATH."
i've had that already.
i think my major problem is in working out where things
class MyTclEvent extends TclEvent {
private Interp mInterp = null;
public MyTclEvent (Interp interp) {
}
public int processEvent (int flags) {
try {
hello(mIterp);
} catch
Thanks Mo. You are right. But actually I have "mInterp = interp" in my
program. When I sent you the mail somehow I deleted it. That means having
that in program, still have the same problem. Could you please help me to
find another problem?
Thanks,
Zhumei
On Thu, 15 Jun 2000, Mo DeJong wrote:
On Thu, 15 Jun 2000, Zhumei Wang wrote:
Thanks Mo. You are right. But actually I have "mInterp = interp" in my
program. When I sent you the mail somehow I deleted it. That means having
that in program, still have the same problem. Could you please help me to
find another problem?
Thanks,
Sorry, Mo. I didn't know that was a pure java question. I thought that was
a question related to Tclblend. Thank you for your time anyway.
zhumei
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:
Your patch is a good start. There may be a few issues not addressed by this
patch:
1. Java_tcl_lang_Interp_create() may need a separate C mutex to prevent more
than one thread from creating the JVM when used in the threaded version of
Tcl. I don't think know the effect of trying to call
On Thu, 15 Jun 2000, Jiang Wu wrote:
Your patch is a good start. There may be a few issues not addressed by this
patch:
1. Java_tcl_lang_Interp_create() may need a separate C mutex to prevent more
than one thread from creating the JVM when used in the threaded version of
Tcl. I don't
I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't matter in this
context," because that seems to fix my problem.
Dr Wes Munsil wrote:
Please give me your advice.
I've instrumented TclBlend to look for the pattern of execution of
MonitorEnter/MonitorExit calls and have learned
14, 2000 7:40 AM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] what I now know about the deadlock
I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't
matter in this
context," because that seems to fix my problem.
Dr Wes Munsil wrote:
Please give me y
A small correction. My patch does NOT remove the monitor calls in
JAVA_LOCK/JAVA_UNLOCK. The patch fixes problems encountered if you load Tcl
into a running JVM, which is the opposite way of using TclBlend comparing
how you are using TclBlend.
I also think removing all instances of
Sorry, you are quite correct; I was not clear. When I refered to "Jiang's
patch," I actually meant "the patch at
http://www.mail-archive.com/tcljava@scriptics.com/msg00598/tclblend.patch, plus
Jiang's suggestion to remove the monitor calls from JAVA_LOCK and JAVA_UNLOCK."
Thank you for allowing
Mo DeJong wrote:
On Tue, 13 Jun 2000, Dr Wes Munsil wrote:
1) Tclblend_Init is never called. Consequently the call of MonitorEnter
in that function is never executed.
That does not seem right. The Tclblend_Init method should be
invoked by Tcl during the load command (like load
On Tue, 13 Jun 2000, Dr Wes Munsil wrote:
I applied this patch and your other suggestion, and rebuilt, and now I cannot
make it through the regression tests. tcljava/AutomaticSignature.test appears to
deadlock. Can anyone help? My deadline is near, and I am close to having to
abandon
Thank you for your response. I am running "make test". (I don't know who loads whom,
but I
infer from your comments that that means I am loading a JVM into Tcl.) I had removed
the
MonitorEnter calls from JAVA_LOCK and JAVA_UNLOCK in response to an earlier suggestion
from
Jiang Wu.
The history
I am not sure about how well JDK 1.1.8 work with TclBlend. I have not
tested TclBlend with JDK 1.1.8. Are you unable to upgrade to JDK 1.2?
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 13, 2000 11:31 AM
To:
I repeated the test of the patch, with JDK 1.2 on Solaris. Same result...
hanging in AutomaticSignature.test.
Jiang Wu wrote:
I am not sure about how well JDK 1.1.8 work with TclBlend. I have not
tested TclBlend with JDK 1.1.8. Are you unable to upgrade to JDK 1.2?
-- Jiang Wu
[EMAIL
When I started this project back in March, I could not get anything to work with JDK
1.1.8, Tcl
8.3, and TclBlend 1.2.5, so I used Tcl 8.2.3. I do not remember now what the symptom
was, just
that it didn't work. (I am using JDK 1.1.8 because of warnings about JDK 1.2 at
Sigh. I can do that for my testing, certainly. But you may recall that my constraint
in production is
that I am not the one that is invoking Tcl--Vignette's StoryServer product is invoking
Tcl. And they are
using Tcl 8.2.0. Not even 8.2.3. (At least that's what [info patchlevel] says.)
Mo
Sorry, it was unintentional. This was my transmission:
Well, JavaCmdProc() is just calling EnterMonitor. Here's the code:
/*
* Invoke the command by calling Interp.callCommand(). Be sure to
* leave the monitor since we are assuming nothing about the state
* of the world
]'
Subject: [Tcl Java] Re: [Tcl Java] exec command
It depends on what JDK you are using. If you are having problems
with a JDK 1.1 release from Sun, forget about it. JDK 1.2 seems
to work better, but that is still not great. Have you tried the
IBM JDK? That might work better than the Sun one. Sun does
On Tue, 13 Jun 2000, Levine Justin-p94702 wrote:
Hello,
I was using JDK 1.3, but it still wasn't working properly. I gave up and
just started using the Runtime class.
Thanks.
I have never tested it under 1.3. The exec class has this huge hack
in it to get around the fact that the exec()
une 13, 2000 7:59 PM
To: Levine Justin-p94702
Cc: '[EMAIL PROTECTED]'
Subject: [Tcl Java] Re: [Tcl Java] exec command
On Tue, 13 Jun 2000, Levine Justin-p94702 wrote:
Hello,
I was using JDK 1.3, but it still wasn't working properly. I
gave up and
just started using the Runtime class.
Th
On Thu, 8 Jun 2000, Zhumei Wang wrote:
Jiang,
Thanks for answering my question so quickly.
I was thinking that TclBlend should have all the Tcl commands, too. But
After I embedded a Tcl interpreter in Java and tried to invoke "history"
command in Java, it gave me the error message
I am setting this variable prior to calling "package
require java".
When I try to set the system variable, the following
error message is sent to STDERR:
class javax.naming.NoInitialContextException Cannot instantiate class:
com.sun.jndi.rmi.registry.RegistryContextFactory
Dr Wes Munsil wrote:
MAIN THREAD
#4 0xee99acc8 in condvarWait ()
#5 0xee998cc0 in sysMonitorWait ()
#6 0xee96638c in runFinalization0 ()
#7 0xee968d44 in manageAllocFailure ()
#8 0xee96749c in realObjAlloc ()
Looks here like the heap is exhausted, so the VM tries to run finalizers
Re heap exhaustion: either or both may be true, although the code is
incorrect if it deadlocks under those conditions. While increasing the
initial heap allocation may certainly be desirable, I am afraid that it
would not fix the incorrect code, but only make its effects felt less often.
Re
On Fri, 2 Jun 2000 [EMAIL PROTECTED] wrote:
I am a new user of Jacl and would like to write an extension. Is there some
documentation to explain how to define and add a package to the source
distribution, so that I can build my own .jar files. along with Jacl. Thanks.
This would help me
On Mon, 29 May 2000, W. John Guineau wrote:
Am I confused here?
I am currently loading Tcl Blend into Java in the sense that from a live
Java VM, I call 'import tcl.lang.*; Interp tclInterp = new Interp()' etc.
and I am able to interact with the C based Tcl interpreter, have dynamically
On Mon, 29 May 2000, W. John Guineau wrote:
Mo,
Since it's in my best interest, I can probably help with:
4. Merge the rest of Mr. Wu's patches for Tcl Blend.
Is there a simple way for me to access the online CVS repository from
Windows? I do have a dual-boot system with Linux (RedHat
On Tue, 23 May 2000, Jeff Sturm wrote:
I just tracked down an annoying bug in Jacl... the classloader could not
found a /tcl/lang/library/init.tcl resource, so the interpreter refused
to start.
The Interp had been trying to load resources from the system
classloader, not the classloader
You are certainly "going against the grain" right now :) But I am hoping
more people will use TclBlend this way.
We are doing something similar right now with TclBlend (1.3 + some patches)
with JDK 1.2. I am not sure what you mean by "single step the interpreter".
You can certainly
"W. John Guineau" wrote:
My plan is to load the Tcl interpreter from within Java,
and then interact with it from Java. We would then write
Tcl extensions that essentially wind thier way back into
our Java code, and therefore have access to all the
functionality we already have. We will
Well, if I use the Java package, then the Tcl code would not have access to
the same run-time instance of the JVM that our code is running in, right?
(starting our Java code from Tcl is, unfortunetly, not an option.) Or am I
missing something here?
My assumption was that starting a Tcl
y Other
OS Windows NT Windows NT 4 Dell Pentium II 450 Mhz
Found in Version 1.2.6
Fixed Date 2000-03-17 00:00:00
-Original Message-
From: W. John Guineau [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 24, 2000 5:49 PM
To: Mo DeJong
Cc: Jiang Wu; [EMAIL PROTECTED]
Subject: RE: [Tcl Java] R
On Tue, 23 May 2000, Larry W. Virden wrote:
Now I want to try the demos.
I did the make demos. Then I do this:
...
$ cd demos/gluepkg
$ source glue.tcl
Creating the AWT threads...
...
"/vol/tclsrcsol/tcl83/tcljava/unix/A_Jar_File.jar" is not a valid jar file
while evaluating {source
From: Mo DeJong [EMAIL PROTECTED]
"/vol/tclsrcsol/tcl83/tcljava/unix/A_Jar_File.jar" is not a valid jar file
while evaluating {source glue.tcl}
Strange, I have not seen this error before. Try opening another
.jar file and see if that works. I suggest tcljava.jar, I know
for a fact that it is
On Tue, 23 May 2000, Larry W. Virden wrote:
Unfortunately, I'm still Java-deficit so I am uncertain what you mean
when you say "Try opening another .jar file".
Just open the tcljava.jar file that was created in the build directory.
A Jar file is nothing more than a .zip file with a new
From: Mo DeJong [EMAIL PROTECTED]
On Tue, 23 May 2000, Larry W. Virden wrote:
Unfortunately, I'm still Java-deficit so I am uncertain what you mean
when you say "Try opening another .jar file".
Just open the tcljava.jar file that was created in the build directory.
A Jar file is nothing more
1 - 100 of 217 matches
Mail list logo
