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 have spent some time, and have come up empty. I'm currently using Jacl to
try to run batch files on an NT system. However, no matter what I do with
that exec command, it merely flips up a cmd.exe window for a moment, and
then disposes of it. I tried CALLing and STARTing, and all other sorts
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
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.
- Justin
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 13, 2000 1:43 PM
To: Levine Justin-p94702
Cc: '[EMAIL PROTECTED]'
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()
I think, actually, that in 1.2 at least if the System property "user.dir" is
set appropriately that is where the Runtime.exec() takes place. I modified
Interp.setWorkingDir() appropriately (which is called by CdCmd.java):
if (dirObj.isDirectory()) {
workingDir = dirObj;
11 matches
Mail list logo
