or JDK 1.2,
you need more than one directory on the PATH for it to work.
Mo Dejong
Cygnus Solutions
On Thu, 9 Dec 1999, Grant Sayer wrote:
Hi
I've just installed, on Windows-NT, tcl8.2, Java JDK1.2.2, tclblend125
binary.
In a tclsh82 shell when I execute
%package require java
I'm gettin
On Wed, 8 Dec 1999, Vince Darley wrote:
Hope this stops someone else wasting a bunch of time.
My problem with 'java::import -package medical Simulation' not working when
it seemed it should (and when it worked yesterday) turned out to be the
following:
(i) my code, tclBlend, java etc
You might want to try this to get a stack trace. That might really
help track down the problem.
java::try {
java::bind $l processLogin login
} catch {NullPointerException e} {
$e printStactTrace
}
Mo Dejong
Cygnus Solutions
* set l [Login getObject] works, I get a ref that supports
pment tree will only exist in the CVS.
I am not going to create .tar or .zip snapshots, but
if someone else really wanted em they would be welcome
to host snapshots on an FTP or web server.
I hope that clears things up.
Mo Dejong
Cygnus
Blend.
Mo Dejong
Cygnus Solutions
On Thu, 9 Dec 1999, Randolph S. Kahle wrote:
I am making a lot of progress today understanding the JavaBean event
processing. But I am now stuck again.
In the class EventAdaptor.java the method _processEvent(...) has the
following code:
BeanEvent evt
s. Check out
the unix/custom.c file as well as the "cutom" and "custom_shell_green"
rules in the unix makefile for more info. This will require hacking,
so please do not expect this to work "out of the box".
Mo Dejong
Cygnus Solutions
On Mon, 13 Dec 1999, Nimrod Shaulsk
at you might be able to use to determine your load order.
(http://www10.software.ibm.com/developerworks/opensource/jikes/project)
I hope that helps
Mo DeJong
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:
the java::defineclass command is returning null, perhaps
you should fire up ddd with the java debug option inside Jacl and
see if you can figure out where things are going wrong. There is
already a rule in the Jacl makefile that does this for you, it is
called "make ddd".
Mo Dejong
Cygnus
Jacl work in applet?
You should be using Jacl 1.2.5. There will be a new 1.2.6
release in the next couple of weeks. There is no reason
to wait for the new release unless you need one of the bug
fixes in it.
Which is the newest one?
A lot of questions and no answer,
thanks for any help.
L
have patches, please post them
now! After the 1.2.6 release, all new code will be added on
the new 1.3 development version. Unless there is a really critical
bug found and fixed in the 1.2.6 release, I do not think there
will be any more releases on the 1.2 tree.
Mo Dejong
Cygnus Solutions
What was the problem you were running into? Would the applet fail to run
without the patch you suggest? Could you post a diff -u style patch
for the change you suggest?
Mo Dejong
Red Hat Inc.
On Mon, 17 Jan 2000, Thomas McKay wrote:
...
+ Changed Class.class.getResourceAsStream
Nope.
Mo Dejong
Red Hat Inc.
On Tue, 18 Jan 2000, Trella Christopher-P28453 wrote:
In jacl, is there anyway to interrupt the interpreter while it is executing
(say an infinite loop is being executed)?
Chris Trella
480-675-1347
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED
? The problem seems to be that when
another Java thread invokes a callback created with the java::bind
command, the Tcl callback never gets invoked and the other thread
gets deadlocked. This same code works just fine in Jacl.
Mo Dejong
Red Hat Inc.
// Start of file Bind.java
// This class
this
is a JVM bug there is nothing I can do to fix it.
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
This is a bug in Tcl 8. If you upgrade to Tcl 8.0.5 it should fix
the crash you are seeing. You can read about this and other known
bugs in the known_issues.txt file that comes with your Tcl Blend
distro.
Mo Dejong
Red Hat Inc.
On Fri, 4 Feb 2000, Suvarna Ayyagari wrote:
Hi
I was building
ternal
rep is a Java object type. If this problem is caused by
the catch command, would switching to the java::try
command fix it?
Mo DeJong
Red Hat Inc.
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:
a note the the IBM JDK newsgroup right away.
The IBM folks really seem to want to fix problems in
the JDK port while Sun seems to just want 1.1.X to die.
Mo DeJong
Red Hat Inc.
The TclJava mailing list is sponsored by Scriptics
|| \
[string compare $result -inf] == 0 || \
[string compare $result -1.#INF] == 0} {
set result pass
} else {
set result [list fail $result]
}
set result
} pass
Yuk!
Mo Dejong
Red Hat Inc
ong to
get a "Scriptics Blessed" release because of the web site and FTP
site updates. The Web Pages really should be in the tcljava CVS
modules.
Mo Dejong
Red Hat Inc.
On Wed, 23 Feb 2000, Scott Redman wrote:
Brent is still working on it, you can give him feedback so he
can make it eas
Just an FYI.
An implementation of the binary command for Jacl has
been added to the 1.3 version in the CVS. Many thanks go to
Christian Krone for donating the implementation.
Mo Dejong
Red Hat Inc.
The TclJava mailing list
ally looks inside .jar and .zip files that appear on the
env(TCL_CLASSPATH). This makes the "worst case" lookup time depend on
the number of .zip or .jar files on the file system, which is really
ugly. Perhaps we should add a env(TCL_JARPATH) var instead?
Mo Dejong
Red Hat Inc.
On Thu,
on
the env(TCL_CLASSPATH) that would still be supported. Does anyone
see a problem with that? This would be going into 1.3 so
backward compatibility is not a valid objection.
Mo Dejong
Red Hat Inc.
On Thu, 2 Mar 2000, Thomas McKay wrote:
I actually like the feature of looking for and loading classes fr
is if you could add a configure.in test
to see if you can compile the above program like so.
AC_TRY_COMPILE([#include jni.h], , , AC_MSG_ERROR([Can not compile file
that depends on jni.h]))
I hope that helps
Mo DeJong
Red Hat Inc.
On Tue, 4 Apr 2000, Bhupinder Thakur wrote:
hello friends,
i have
g a test
case for this problem. It is the only issue holding up
a 1.2.6 release at this point.
Mo DeJong
Red Hat Inc.
Let them use 1.2.5, especially if you're only tweaking
error messages (or is there more than that?).
-- Scott
---
before
using it. How does that sound?
By the way, this whole mess will be fixed in the 1.3 version, I
am going to get rid of the build stuff in the win and unix subdirs
and just use on TEA ./configure and Makefile for both Jacl and
Tcl Blend.
M
ut nothing ever came of it.
Third, why rely on a custom command ("weld") when the Tcl subst command
does about the same?
later
Mo Dejong
Red Hat Inc.
The TclJava mailing list is sponsored by Scriptics Corporation.
To sub
On Mon, 1 May 2000, Jeff Sturm wrote:
Mo DeJong wrote:
The term "thread safe" is very misleading. Jacl interps are safe
if you use them properly. The problem is that the documentaiton
about how to use them properly is a little thin.
There is no "automatic thread saf
k out http://www.nmrview.com/swank/index.html. The "swank"
project is Tk implemented on top of Swing. By the way, I am
going to be doing a Swank demo at the next SVTUG meeting.
It will be at the Red Hat offices in Sunnyvale CA on
the 16th of this month. Everyone is welcome to stop by for
cool
://www.deja.com/[ST_artlink=www.cs.umn.edu,ST_rn=ps]/jump/http://www.cs.umn.edu/~dejong/tcl/tcljava/prerelease.html
Mo Dejong
Red Hat Inc.
On Wed, 3 May 2000, Sendur Sellakumar wrote:
Hi.
I am getting this linking error when building TclBlend on JDK 1.1.6 w/Tcl
8.3 (on NT) Here
it [java::cast {String[]} [java::null]] $properties
or
java::import org.omg.CORBA.ORB
java::call ORB {init String[] Properties} [java::null] $properties
I hope that helps
Mo Dejong
Red Hat Inc.
The TclJava mailing list is sp
of the building there is a door there. Further
directions will be sign-posted (look for big kitchen).
WHEN: Tuesday, May 16th from 7:00pm to ~8:30pm.
TOPICS:
7:00 "The state of Tcl/Java."
Mo DeJong will present an overview of the
current state of Tcl and Java integration
(aka Ja
Well, I am not sure what Perl has to do with Tcl Blend. If you
are having problmes with Tcl and Tcl Blend I suggest that you
upgrade to Tcl 8.3.1 and Tcl Blend 1.2.6 and see if the problem
goes away. Perhaps I am not understanding your question.
Mo Dejong
Red Hat Inc.
On Wed, 10 May 2000
On Wed, 17 May 2000, Larry W. Virden wrote:
From: Mo DeJong [EMAIL PROTECTED]
the test cases just fine for me. You are using the tcljava/unix/configure
script and not the tcljava/configure script, right? The tcljava/configure
Yeah, sorry about that. Merging the configure, unix
On Wed, 17 May 2000, Larry W. Virden wrote:
From: Mo DeJong [EMAIL PROTECTED]
Boy that is strange. The ./configure test just runs
"package require Tcl 8.3.1"
and makes sure that does not return an error. What do you get
if you just go into the Tcl build dir, r
es for any
paltforms. If folks want to build on windows they will need to install
Cygwin and or Mingwin.
Mo Dejong
Red Hat Inc.
On Tue, 16 May 2000, Scott Redman wrote:
I think we should just require Tcl to be thread-enabled
(as long as Tk will work with it, which is being looked
into for 8.4).
uses Jacl)
http://www.nmrview.com/swank/index.html
(Scriptics Connect uses Tcl Blend)
http://scriptics.com/products/connect/
Any others?
Mo Dejong
Red Hat Inc.
On Thu, 18 May 2000, Larry W. Virden wrote:
Hi. I maintain a Tcl software catalog on the internet at
URL: http://www.purl.org/NET/Tcl
I thought the whole point you were making was that if we require that
Tcl be built with threads then we could remove the JAVA_LOCK stuff.
How do you suggest we implement locking in a non thread enabled version
of Tcl if we are not going to use the current JAVA_LOCK approach?
Mo Dejong
Red Hat
need
one global lock, we could use on Java monitor for each
Notifier.
Mo DeJong
Red Hat Inc
On Thu, 18 May 2000, Jiang Wu wrote:
My opinion is that there is no need for any locking for non-threaded version
of Tcl in TclBlend. There is no need for any locking for threaded version
of Tcl
t did. The write() call should be thread
safe and the windows port has its own global mutex.
Scott, could you extract a comment from Scott S. on this one?
Is JAVA_LOCK designed to only let one thread access the JVM
at a time?
Mo Dejong
Red Hat Inc.
On Thu, 18 May 2000, Jiang Wu wrote:
You are right
. Something to think about
in the near future is moving the Shell.java file from the jacl
dir to the tcljava dir so that the same tcl.lang.Shell program
can be accessed in Jacl and Tcl Blend.
Mo Dejong
Red Hat Inc.
On Wed, 5 Apr 2000, Jiang Wu wrote:
This is related the last email I sent regarding
so there is no "bug" to fix in the demo.
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
ames of the programs that should be used to actually run
Jacl or Tcl Blend.
Mo Dejong
Red Hat Inc.
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
wit
);
} catch (SecurityException e2) {
// This catch is necessary if Jacl is to work in an applet
// at all. Note that java::new will not work from within Jacl
Mo Dejong
Red Hat Inc.
The TclJava mailing list is sponsored
e can also remove all uses of
JAVA_LOCK in the native JNI code.
If anyone would like to help with any of these items, it would
really speed things up.
Mo Dejong
Red Hat Inc.
The TclJava mailing list is sponsored by Scriptics C
that over
the network on windows. That is what we do at work.
Actually trying to use windows to do any sort of
development work is much harder than developing
software to run on windows.
Mo Dejong
Red Hat Inc.
The TclJava ma
on top of Swing.
Mo Dejong
Red Hat Inc.
dnl This file is an input file used by the GNU "autoconf" program to
dnl generate the file "configure", which is run to configure the
dnl Makefile in this directory.
AC_INIT(swankgen/swkgen.tcl)
# RCS: @(#) $Id: configure.
ix release, there are no new features.
If you want new features grab the 1.3 "development" version.
Mo DeJong
Red Hat Inc.
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail
is
having trouble finding its library of .tcl commands on startup,
that might be the problem.
I tried some other tcl commands, such as "puts" and "set ". These commands
seem to work well in java.
Mo DeJong
Red Hat Inc
is the problem, why don't you try taking the finalization
methods out of the tcl.lang.Interp class? Try putting them into a
free() method that you can just call from your app when you
are done with the interp.
Mo Dejong
Red Hat Inc
econfigure and rebuild Tcl Blend, it will automatically notice that you
compiled Tcl with debug and include debug info in libtclblend.so.
This sort of thing is the exact reason there are only Windows
binaries on the Tcl Blend 1.2.6 download site. It is safer
to just build things by yourself.
Mo DeJong
R
in a patch?
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
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]
{
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
d ddd rule for Jacl by running "make ddd" in the
build directory.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
wit
vwait"
command will cause infinite loop. Events are not removed properly from the
event list. "vwait" can deadlock due to synchronization.
Yeah, we still need to get those fixed. I just want to get the loading
problems out of the way
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
? 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
-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
- 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
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
, 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
... 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
.
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
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
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
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
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
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
.
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]
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
,
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
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
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
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
-
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.
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
---
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
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
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
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
. 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
)-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
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
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
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:
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
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
1 - 100 of 143 matches
Mail list logo
