[Tcl Java] Re: [Tcl Java] TclBlend for RH 6.0, JDK 1.2
You need the source release for Tcl and Tcl Blend. Untar them in a directory and then configure and build Tcl followed by Tcl Blend. Detailed build directions are located in the README files that come with Tcl Blend. I think you can use Tcl Blend in Tcl Pro (once you compile it), but I would stick with the source release if I were you (mixing precompiled binary files with new binaries is kind of tricky). Mo Dejong Cygnus Solutions On Tue, 7 Dec 1999, Brett Smith wrote: > What/where are the procedures for installing latest TclBlend onto > RH6.0? I have installed the Tcl 8.2 binaries (from TclPro1.3 eval) and > I have blackdown's 1.2 JDK. > > Do I have to build it? If so, are there any procedures to follow? > > thanks, > Brett Smith > [EMAIL PROTECTED] 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] tclblend.dll Loading problems
There were a bunch of folks having this same problem but I thought we fixed the last of them. Try right cliking on your tclblend.dll file and choosing "quick view". That should list the shared libs tclblend.dll depends on. Make sure they match the dlls in your JDK directories. Some patches to the tcljava cvs were made today so if you get the cvs tree tommorow you will be able to build from the source. You can also open up the pkgIndex.tcl file and set the debug var at the top to "1". That will print out extra debug info about the loading process. Oh yeah, watch out for 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 getting "load tclblend.dll failed: couldn't load file tclblend.dll": > invalid argument > > The path to the dll is on the Windows PATH environment variable, as is the > Java binaries location. > > Has anyone had similar problems or know how to resolve this one. > > regards > grant > > > 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 PROTECTED] > with the word UNSUBSCRIBE as the subject. > To send to the list, send email to '[EMAIL PROTECTED]'. > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] java::import problems
On Wed, 8 Dec 1999, Vince Darley wrote:
> Does anyone have an idea why the following might happen:
Woah, what is that? "java::import -medical" is totally wrong.
You could do a "java::import -package medical Simulation" or
you could do a "java::import medical.Simulation". These two
commands would do exactly the same thing in this case.
The "java::import -package pkg cls ..." is really designed
to avoid having to re-enter the package name for a bunch
of classes that are in the same package. It should be used
like this:
% java::import -package java.util Hashtable Vector
You can also query the current imports with this command.
% java::import
If you just want to query the imports from a given package
(java.util in this case), use this form of the command.
% java::import -package java.util
> % catch {java::import -medical Simulation}
> 1
> % catch {java::import medical.Simulation}
> 1
> % java::new medical.Simulation
> java0x1
> %
That should work with no problems. Double check that this
is actually the name of the class by running
"javap medical.Simulation" from your system shell.
> (I want to import the class and then do 'java::new Simulation')
When things go wacky like this, I take a 10 minute break,
and start over. Oh yeah, reboot your NT box too:)
> The first line used to work ok, but has suddenly stopped working today, for
> no reason I can understand. This is with tclBlend1.2.5, Windows NT, JDK
> 1.2.2, Tcl 8.2.2... and the very same code (I've been making small changes,
> for sure...) worked ok yesterday.
>
> The error messages above from the 'catch' statements are the empty string
> "".
>
> thanks for any suggestions,
>
> Vince.
Mo Dejong
Cygnus Solutions
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] binary Jacl command
Nice work. I am going to work on merging all the recent patches and I hope to have a new version in the CVS very soon (this weekend ??). The current list of new features is as follows. New Regexp implementation New binary command Fixes for the clock command Add bash shell scripts under windows Mo Dejong Cygnus Solutions On Thu, 9 Dec 1999, Christian Krone wrote: > Hello, > > in the attachment there is an implementation of the binary command > based on the sources of Jacl1.2.5: > > There are BinaryCmd.java and TclByteArray.java, both are new files > belonging into jacl1.2.5/src/jacl/tcl/lang. The former is the > implementation of the Command for binary, the latter is a new > InternalRep for byte arrays. > > Finally there is a patch for jacl1.2.5/src/jacl/tcl/lang/Interp.java, > which announces the new command to the interpreter, and a copy of the > tcl8.2 test file binary.test, which belongs into jacl1.2.5/tests/tcl. > > Have fun, Krischan > -- > Christian Krone, SQL Datenbanksysteme GmbH 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] solution to java::import problem
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 were all 100% fine. > (ii) I had a directory 'medical' full of my class files, BUT I also happened > to have created a .zip file 'medical.zip' which also contained all those > class files (just there temporarily to email to someone to run my software), > and both the 'medical' directory and the medical.zip file were in [pwd]. I don't know what you mean by this. The java::import does try to load a class with the given name to see if it exists, but it should not go loading things out of zip files if they are not on the CLASSPATH. If it is doing something strange like this, it might be a bug. Could you try to come up with a small test case that generates the error your were seeing? If you can get a nice little test case to generate this error, I will find out what caused it and fix the problem. > For whatever reason, the java::import -package medical looked first at the > medical.zip file, and ignored the 'medical' directory and failed with an "" > error. I have no idea whether this should be considered correct behaviour, > or whether tclBlend should have either (i) ignored the zip file and run my > code properly, or (ii) actually used the zip file (which, after all, > contained perfectly good .class files) and run properly. > > The solution of course was to delete the zip file. > > While I'm here, does anyone have any suggestions for: Tricky. The most simple way to do this is to use Jacl. Jacl is 100% Java and it should run your Tcl code. You can load Jacl into a jdb and set breakpoints in the code. Debugging JNI code is a problem all Java projects that use native code face, and I have not seen a good solution yet. > (i) best approach for debugging java code which is only called from Tcl. I have no idea. I do not know if anyone has ever tried. > (ii) can tclBlend/java be used in the tcl plugin (after special > compilation?)? > > cheers, > > Vince. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] java::bind questions
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 things like $l show
>
> * when I execute java::bind $l processLogin login I get a
> java.lang.NullPointerException
>
> where:
>
> proc login {} {
>do stuff
> }
>
> I am going to work my way through this, but if anyone has any helpful
> pointers I would appreciate hearing from you.
>
> Thanks -- Randy Kahle
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] New 1.3 version info (please read)
Hi all. My last post about new features was not very clear. Ongoing Jacl and Tcl Blend development will happen in the new 1.3 development tree. No new features will be added to the existing 1.2 version, but bug fixes may get added. For instance, there are currently some nice bug fixes to the 1.2.5 release in the CVS. If you are having ANY problems with the 1.2.5 release, please get the most recent CVS source and see if you can reproduce the problem. I want to see a rock solid 1.2.6 release in "about a week", so now is the time to get any bug fixes into the tree. The 1.3 development 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 Solutions 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] java::bind questions
Was it a bug in the tcljava code or your code? Could the java::bind command be improved in some way to avoid this type of problem in the future? Mo Dejong Cygnus Solutions On Thu, 9 Dec 1999, Randolph S. Kahle wrote: > Mo, > > Problem solved in very short order because of your help. > > Thank you *very* much for the prompt reply to my email. > > Regards, > > Randy Kahle > > > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] java::bind questions
The problem you describe sounds like the "bind freezes my app" mystery
bug that a few people seem to have run into. There are some detailed
problems reports in the CVS. Check out the tcljava CVS and look at these
files in the tcljava/bugs directory.
eventbug1
eventbug2
eventbug3
jbindbug.txt
There seems to enough info to track down the bug but I have
not found the time to find the cause. If you can find the
root of the problem, I would be happy to add a patch to 1.2.6.
Mo Dejong
Cygnus Solutions
On Thu, 9 Dec 1999, Randolph S. Kahle wrote:
> Mo,
>
> The problem was mine. The collection object that held listeners was null
> (never initialized). That was the null pointer problem.
>
> java::bind seems fine. I'm using it to do queries, etc. and it seems
> reasonable. I will be working over Jacl in the next couple of days as our
> team completes a prototype of a client-side architecture for building a new
> generation of applications. Jacl is really helping us pull this together.
>
> I am running into another block... Now that I can do this -->
>
> java::bind $l processLogin login
>
> where
>
> proc login {} {
> ...
> }
>
> When the event is fired from Java, it never returns from the method call on
> processLogin on the listener (the link to the tcl script).
>
> Any suggestions on how I can trace down where my thread went? Can any
> thread fire the event into Tcl? (I remember reading through the source code
> and seeing something about the event system keeps track of the
> interpreter's primary thread...)
>
> (Do I need to have a thread spinning on the interpreter?)
>
> Randy
>
> >Was it a bug in the tcljava code or your code? Could the java::bind
> >command be improved in some way to avoid this type of problem in
> >the future?
> >
> >Mo Dejong
> >Cygnus Solutions
> >
> >On Thu, 9 Dec 1999, Randolph S. Kahle wrote:
> >
> > > Mo,
> > >
> > > Problem solved in very short order because of your help.
> > >
> > > Thank you *very* much for the prompt reply to my email.
> > >
> > > Regards,
> > >
> > > Randy Kahle
> > >
> > >
> > >
> > >
> >
> >
> >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 PROTECTED]
> > with the word UNSUBSCRIBE as the subject.
> >To send to the list, send email to '[EMAIL PROTECTED]'.
>
>
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] JavaBean event is locking on evt.sync()
Run this same code in Jacl under jdb. When it locks up, interupt the code and see which threads are locked. You should then be able to get a backtrace for each of the threads to find out where the deadlock is. I think this bug in in the notifier somewhere, so it should deadlock both Jacl and Tcl 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 = new BeanEvent( interp, paramTypes, params, cmd ); > interp.getNotifier().queueEvent( evt, TCL.QUEUE_TAIL); > evt.sync(); > > When my JavaBean fires an event into the Adapter class created by Tcl (upon > registration using the java::bind command ), it locks up on the call to: > > evt.sync(); > > (I put in trace print out). > > and never returns. > > What occurs to me is that there must be a Thread running on interp > somewhere that fetches these events and processes them internally. I do not > have any such threads running. Can someone point me to the point where I > must be "spinning" a thread on the other side of this event queue? > > I guess I'm missing a fundamental step here... > > Thanks! > > Randy Kahle > > > > 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 PROTECTED] > with the word UNSUBSCRIBE as the subject. > To send to the list, send email to '[EMAIL PROTECTED]'. > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] TclBlend on HP-UX10
Short answer, you need a JDK with native threads. Long answer, you could try hacking around with the "custom" target in the unix/Makefile. The "custom" executable (it was called green.c in the past) will load Java before Tcl, so it "should" work with green threads. 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 Shaulski wrote: > Can anyone help me? > I want to run TclBlend on HP-UX10, but I believe this platform does not have > Native Threads on it (only "Green"). Does this mean TclBlend is not > available on HP-UX10? > Thanks a lot, > nimi. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] capturing output of stderr from java
Please check the mailing list archive at http://www.mail-archive.com/tcljava@scriptics.com before you post. This question was asked before and there is a great post by Christopher Hylands that details exactly how to do this. Here is a link to his posting. http://www.mail-archive.com/tcljava@scriptics.com/msg00149.html Mo Dejong Cygnus Solutions On Fri, 17 Dec 1999, Suvarna Ayyagari wrote: > Hi, > > How do I capture output directed to stderr in java from TclBlend. Can > someone help me with this? > > thanks > Suvarna 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'.
[Tcl Java] Re: [Tcl Java] Turning off JIT in TCLBlend and Java 1.1 (fwd)
You might be able to turn off the jit by setting the JAVA_COMPILER env var to "" or NONE. I know that works with Jacl (which uses the java executable), but I am not sure about Tcl Blend. Mo Dejong Cygnus Solutions 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] using java::defineclass
On Wed, 5 Jan 2000, Vince Darley wrote:
Off the top of my head, I would be willing to bet that the problem
you are having is because a class you want to define depends on
another class that can not be found.
Like so:
class A {
B b = new B();
}
class B {
}
Try loading B first, and then A. If that works but simply loading A
does not, then the lack of the B class is the problem.
> I'm trying to place all the class data from my package's .class files inside
> Tcl files as binary strings for loading when required. As a first step in
> that direction, I've created the following proc, which simply takes all
> .class files in a given directory, and tries to convert the binary data in
> those files into java.lang.Class objects:
This is kind of wacky because you will need to worry about the order
your classes are defined. In "regular" Java, this is all done behind the
scenes by searching the CLASSPATH. I would be willing to bet that you
could write a script to grep the output of "java -verbose CLASSNAME"
to see all the classes that are loaded when your class is loaded.
You might also want to play around with jikes. I think it has some fancy
deps tracking that 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:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] using java::defineclass
Perhaps you are going about this the wrong way. What you really want
to do here is wrap up your classfiles in some way that they can
be loaded by the JVM without putting them on the filesystem.
Perhaps what you need to do here is write your own classloader
like the TclClassLoader.
As for why 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 Solutions
On Wed, 5 Jan 2000, Vince Darley wrote:
> > -Original Message-----
> > From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> >
> > Off the top of my head, I would be willing to bet that the problem
> > you are having is because a class you want to define depends on
> > another class that can not be found.
> >
> > Like so:
> >
> > class A {
> > B b = new B();
> > }
> >
> > class B {
> > }
> >
> > Try loading B first, and then A. If that works but simply loading A
> > does not, then the lack of the B class is the problem.
>
> This doesn't seem to be the entire problem (I'm sure it's part of the
> problem, though). For instance the following test class won't load:
>
> package medical;
> import java.util.Random;
>
> public class Tests {
>
> double f[];
> double min;
> double max;
>
> public Tests(double min, double max) {
> this.min = min;
> this.max = max;
> }
>
> void set(double[] value) {
> f = new double[value.length];
> for (int i=0; i f[i] = value[i];
> if(value[i] < 0) {
> throw new RuntimeException("Probabilities must be
> positive!");
> }
> }
> }
>
> }
>
> If I delete the entire 'set' method then it will load. Otherwise, I get a
> java0x0 null object back from the java::defineclass command.
>
> However: from what you say below it seems as if java::defineclass cannot be
> used with classes which reference each other ( class A { B b; ... } class B
> { A a; ...} ). That will probably be problematic for me in any case. I
> guess this is a limitation of defineclass?
>
> cheers,
>
> Vince
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Jacl in applet
On Thu, 6 Jan 2000, Lubos Vrba wrote: > Hello *, This is a tricky issue. Jacl (using Tcl commands in an applet) works but the java::* commands do not. > in jacl web pages I've read that Jacl 1.25 won't work in browsers. There is nothing wrong with Jacl that we could fix to "support" applets. The "problem" is that the JVM inside Netscape's browser is totally busted. I have not tested the Microsoft JVM so I can not speak about that. > Is there some plans for future to support Jacl in applet? You can run Jacl applets that only use Tcl commands. You might want to check out these pages on Christopher Hylands site, they are a little dated but have some great info. http://ptolemy.eecs.berkeley.edu/~cxh/java/tclblend/ http://ptolemy.eecs.berkeley.edu/~cxh/java/jaclapplet/index.html > Is there some workaround? > I'm looking especially for support IE and NN. > Does older 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. > > Lubos Vrba Mo DeJong Cygnus Solutions 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Are you ready for a tcljava 1.2.6 release?
Hi all. I checked some recently posted bug fixes into the tcljava CVS and I think we are about ready for a 1.2.6 release. If you would like to test it out, please update your code from the CVS and try to build it. If anyone is still having problems with Tcl Blend or Jacl, please post now! If you 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 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Jacl in applet
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() in Interp.java to > getClass().getResourceAsStream(). > > So, it's definitely possible. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Jacl in applet
That is an easy one. Run these commands to check out tcljava from the cvs. % setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot % cvs login (password is cvs) % cvs checkout tcljava This will create a tcljava directory with all the src code in it. Copy your modified files into the tcljava/src/tcljava/tcl/lang or whatever sub dir they live in. Then just run this command from the main tcljava directory to get a diff of your changes. cvs diff > applet.patch It is just that easy! Mo Dejong Red Hat Inc. On Mon, 17 Jan 2000, Thomas McKay wrote: > Sorry, I'm a little pressed for time at the moment and honestly don't know > if I still have the original to diff against. > > The problem boiled down to a security exception. The class Class is in a > jar file that did not have the proper policy set. By using getClass(), the > result would be from the Jacl jar file which had the proper policy. > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Interrupting the interpreter
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 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Tcl Blend + java::bind problem, could you help test?
Hi all.
I seem to have run into a really big problem with the java::bind
command that I need some help with. The problem only seems to
show up in Tcl Blend, and I have only tested it on my RedHat 5.2
Linux box thus far. Could people on the list try out this example
and post the results they get? 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 implements a bindable object that will
// generate an event to a tcljava binding (java::bind)
import java.util.EventObject;
import java.util.EventListener;
public class Bind implements Runnable {
ActionListener actionListener = null;
Thread t = null;
boolean started;
boolean stopped;
int tnum = 0;
final boolean debug = true;
public void addActionListener(ActionListener l) {
actionListener = l;
}
public void removeActionListener(ActionListener l) {
actionListener = null;
}
public void doLater() {
// Create new thread that will invoke the call to
// actionListener.actionPerformed(ActionEvent)
// in another thread at a later time
started = false;
stopped = false;
tnum++;
t = new Thread(this);
t.setDaemon(true);
t.setName("Bind delay thread " + tnum);
t.start();
if (debug) {
System.err.println("Waiting to invoke action");
}
}
public void run() {
started = true;
// Go to sleep for some time
try {
Thread.sleep(3000);
}
catch (InterruptedException ie) {}
if (debug) {
System.err.println("Now to invoke action");
}
// Now invoke the callback (from a different thread)
actionListener.actionPerformed(new ActionEvent(this));
stopped = true;
t = null;
}
public boolean wasStarted() {
return started;
}
public boolean wasStopped() {
return stopped;
}
}
interface ActionListener extends EventListener {
public void actionPerformed(ActionEvent e);
}
class ActionEvent extends EventObject {
ActionEvent(Object source) {
super(source);
}
}
// End of file Bind.java
# Tcl code from this bind class
# Be sure to run "javac Bind.java" first
package require java
set env(TCL_CLASSPATH) .
set b [java::new Bind]
set action 0
java::bind $b actionPerformed {
set action 1
puts "Hi there"
#error NO
}
$b doLater
# Wait a little while and see what happened
after 4000 {
if {[$b wasStarted]} {
puts "Thread Was Started"
}
if {! [$b wasStopped]} {
puts "Thread Is Deadlocked"
}
if {! $action} {
puts "No Action Taken"
}
}
Results on Linux:
Jacl under JDK 1.1 from Blackdown:
Works
Tcl Blend under JDK 1.1 from Blackdown:
Hangs, call to Tcl event never made
Same seems to apply for JDK 1.2.
Here is the thread dump from Tcl Blend when the Java thread
is blocked.
Full thread dump:
"Bind delay thread" (TID:0x405ba390, sys_thread_t:0x807b178, state:CW, thread_t:
t@4100, sp:0xbf3ff840 threadID:0xef1, stack_base:0xbf3ffd68, stack_size:0x20)
prio=5
tcl.lang.TclEvent.sync(TclEvent.java:126)
tcl.lang.EventAdaptor._processEvent(EventAdaptor.java:334)
tcl.lang.Adaptor0.actionPerformed(Unknown Source)
Bind.run(Bind.java:91)
java.lang.Thread.run(Thread.java)
"SIGQUIT handler" (TID:0x405b32a0, sys_thread_t:0x80cdc80, state:R, thread_t:
t@3075, sp:0xbf5ff40c threadID:0xef0, stack_base:0xbf5ffd68, stack_size:0x20)
prio=0 *current thread*
"Finalizer thread" (TID:0x405b3088, sys_thread_t:0x80cdb60, state:CW, thread_t:
t@2050, sp:0xbf7ff984 threadID:0xeef, stack_base:0xbf7ffd68, stack_size:0x20)
prio=1
"main" (TID:0x405b30b0, sys_thread_t:0x80cd2d8, state:R, thread_t: t@1024,
sp:0xbfffef30 threadID:0xeec, stack_base:0x0, stack_size:0x20) prio=5
Monitor Cache Dump:
tcl.lang.BeanEvent@1079747800/1080198008:
Waiting to be notified:
"Bind delay thread" (0x807b178)
java.lang.Class@1079734352/1080109664: owner "main" (0x80cd2d8, 1 entry)
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] namespace of tcljava extension
On Wed, 26 Jan 2000, zhanglei wrote:
> Hi, everyone:
>
> I have a question about tcljava and namespace.
> I wrote Tcl extension using tcljava class lib
> (eg. public class Ext extends tcl.lang.Extension
> and add new commands using Interp.createCommand method)
> and made a tcl package index using pkg_mkIndex.
> After that, I load the extension using java::load
> in the package startup file.
> That's all right and i can use the new commands
> in the extension directly in the wish shell.
Just create the namespace and then use a namespace qualifier
for each of the commands you create.
Like so.
interp.eval("namespace eval ext {}");
interp.createCommand("ext::mycmd", cmd);
> But how can i make all the commands in the extension
> available in a package namespace? That is, i do not
> want them available in the wish shell directly, but
> with a package namespace prefix(eg. ext::someCommand ).
> Because i wrote the extension and all the commands
> in java. I don't know how to do it.
Gee, I hope nobody is going to die if you do not get
this demo working :)
> Can anyone help me? Because i have to make a demo
> two days later, I deadly need your advice.
> If you know the answer, pls reply ASAP.
> Thank you very much.
>
> zhanglei
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] defineclass vs new problems
Vince, I took a quick look at the example you posted, but I am a little confused about exactly where the problem is. The class you are trying to load with java::defineclass seems to implement an interface that you added to the tcl.lang package. Have you been able to recreate the problem with a single class that does not extend, implement, or include references to any classes other than the ones in the standard java.* packages? If so could you post just that .java file so that I can try loading that with java::defineclass? Mo Dejong Red Hat Inc. On Sat, 22 Jan 2000, Vince Darley wrote: > I'm only running on WinNT, and so far only with jdk1.2.2. This is with the > latest tcljava sources from cvs too. > > Vince. > > -Original Message- > From: Scott Redman > To: [EMAIL PROTECTED] > Sent: 1/22/00 4:09 PM > Subject: [Tcl Java] Re: [Tcl Java] defineclass vs new problems > > defineclass is known to be broken with JDK 1.2.x on Solaris only, > the bug in question does not occur with JDK 1.1.x on any platform > or on JDK 1.2.x on any platform other than Solaris. > > Which JDK are you using and on which platform? > > -- Scott > > > > > Vince Darley wrote: > > > > I'm still running into problems trying to use 'java::defineclass > $data' vs just using java::new. I have a very simple class > > which just fails to be loaded with defineclass, but is very happy with > new. I've been unable to track down exactly why it > > fails: seems as if internally 'DefineClass' just returns null. > > > > If anyone would like to have a look at this, I've put together a > simple test case at > > ftp://ftp.ucsd.edu/pub/alpha/tcl/defineclassbug.zip (15k) > > > > This fails with both Jacl and Tclblend... > > > > has anyone else noticed problems with defineclass (even on simple > classes which don't reference any other class not in > > tcl.lang or java.lang)? > > > > Vince. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] ReflectObject problems
Something is very wrong in the ReflectObject table. Try to create a
small test that reproduces this error and set the debug variable
on line 107 to true. That will print out extra info while adding
or searching in the reflect table.
Mo Dejong
Red Hat Inc.
On Tue, 25 Jan 2000, Thomas McKay wrote:
> While creating numerous ReflectObjects w/in a Java command, I inconsistently
> get a message
>
> "table entry did not match arguments"
>
> The error is thrown in ReflectObject.java when
>
>
> if (found.javaClass != cl || found.javaObj != obj || found.ownerInterp !=
> interp) {
>
> Any idea what could cause this?
>
> I have a tcl proc that repeatedly calls the java-implemented tcl command, if
> that makes a difference.
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] some progress with java::defineclass problem
I tested out the classes you sent, and they both load perfectly into my JDK 1.1.7 port from Blackdown on a Linux box. They DO NOT load into a Sun JDK 1.1.8 running on a Windows box. This looks like a Sun JVM bug to me. Could you try out the IBM JDK for windows and see if you get the same error there? If this is a Sun JDK bug, there is nothing I can do to fix it. You will have to email Sun asking them why they produce such buggy code. Mo Dejong Red Hat Inc. On Thu, 27 Jan 2000, Vince Darley wrote: > Attached are the Customer.java, Customer.class, and a reduced version > Cust.java, Cust.class which also seem to show the same problems (but I > haven't looked in any detail at Cust.*). I enclose the reduced versions > since you won't be able to recompile Customer.java. > > I'd really appreciate any ideas you have on this. > > thanks, > > Vince. > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] [Tcl Java] Tcl Blend + java::bind problem, could you help test?
Hello all. This is just an update on the java::bind dead-locking problems that I have run into on the Linux port of Blackdown JDK 1.1.7. It seems that Java threads are getting dead-locked when calling back Tcl code created by a java::bind command. I tried the example on Windows, and there were no problems. I then tried it with the IBM JDK 118 port for Linux and Sun's JDK on Solaris. There were no problems with deadlocking on those systems so this must be a JVM bug in the blackdown JDK. I am going to add this example as a test case and add a note to the known_issues.txt file, but because 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 as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] java::field problem
This sounds like a documentation problem. The HTML docs do indicate
that this is possible but there is no example of how to do it.
You should be able to get or set a shadowed value like this:
java::field $obj {FIELD BASECLASS}
java::field $obj {FIELD BASECLASS} NEWVALUE
I will have to add a short example to the docs about this problem.
Mo Dejong
Red Hat Inc.
On Tue, 1 Feb 2000, Trella Christopher-P28453 wrote:
> If I have a class that inherits from a base class, I cannot use the
> java::field command to get access to fields that are inherited from the base
> class. Why can't I look at fields that are inherited from the base class.
>
> Chris Trella
> 480-675-1347
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] configuring cgiexe on the JavaWebServer and swappingJRE for Jacl
On Tue, 1 Feb 2000, Soren C. Sorensen wrote: This is not the right place to ask Java Web Server questions. > I have two questions, both about using the Java Web Server (which I am running > on Windows NT): > > How do you configure the cgiexe servlet to use .tcl scripts from /cgi-bin/? I > already am able to execute them from the MS-DOS shell. There is no JRE shipped with Jacl. Jacl is a pure Java implementation of Tcl, not a JDK or Java Runtime Environment. You need to have Java installed on your system before you can use Jacl. You really should check out these URLs. http://www.scriptics.com/faq/java.html http://www.scriptics.com/java http://www.scriptics.com/products/java/man/contents.html > I am also wondering about swapping out the JRE the webserver shipped with for > one with Jacl... so would like to know if anyone has tried this. > > Also, are there any FAQs I should read before posting again? I just joined this > list yesterday :) > > Thanks, > > Soren 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: ReflectObject problems
Humm, without knowing exactly what command it fails on
or what object is puking out, it is going to be hard to
track this down. We need to trim this down to a very
small example that can be run from a single directory
with only a couple of source files. Typically trimming
Tcl code out of your example until it works and then
hitting undo is the best way to get a small example.
You should also try using "regular" Java objects like
java.lang.String in place of your own Java objects to
see if you can create a "Tcl only" example that crashes
without needing your Java classes (that would really help).
Here is some Tcl psudo code for how it should work.
For a given object (java0x1) of class
java.lang.String, map the object id
and it's reflected class to an
entry in the Reflect Table.
set roRep [java::new ReflectObject]
$interp createCommand java0x1 $roRep
set reflectIDTable(java0x1) $roRep
set reflectObjTable(java.lang.String.[identityHashCode]) $roRep
So when we search the table in findInReflectTable(), we simple
look for a table match for the string
"java.lang.String.[identityHashCode]"
The "table entry did not match arguments" error can happen
when the given mapping does exist in the table but
the $roRep value at the mapping does not match the
values passed in to the search (which should never happen).
The only thing I can think of off the top of my head is that
if something was wrong with the identityHashCode() method
that would produce a duplicate identity string. The
string for each Class + Object combo needs to be unique.
Mo Dejong
Red Hat Inc.
On Tue, 1 Feb 2000, Thomas McKay wrote:
> Here's a log file from the run. Note that I had to modify the debug print
> statements in ReflectObject.java or it would be huge! I included the source
> for your reference.
>
> Not sure what to look for. Could be a problem with
> System.indentityHashCode() or the reflect objects useCount?
>
> Here's what I'm doing to cause the error:
>
> % set cs [cellsList] <-- sets cs to a list of drawing designs
> % foreach c $cs {
> cellOpen $c <-- open the drawing
> write-xpm $c <-- write out an x pixmap
> cellQuit <-- close the drawing
> }
>
>
> Here's the script for writing the pixmap. This is how the commands map to
> reflect objects:
> layer catapult.db.xy.layout.LayoutLayer
> objSelect catapult.db.xy.layout.LayoutObjPolygon
>
> proc write-xpm { name } {
>
> set layerNames [layers]
>
> set fp [open "$name.xpm" w]
> puts $fp "! XPM2"
> puts $fp "16 21 [llength $layerNames] 1"
>
> set abc "abcdefghijklmnopqrstuvwxyz"
> foreach layerName $layerNames {
> set l [layer $layerName]
> set line "[string index $abc [lsearch $layerNames $layerName]] c #"
>
> set color [$l getColor]
> set r [java::call Integer toHexString [$color getRed]]
> if { $r == "0" } then {
> set r "00"
> }
> set g [java::call Integer toHexString [$color getGreen]]
> if { $g == "0" } then {
> set g "00"
> }
> set b [java::call Integer toHexString [$color getBlue]]
> if { $b == "0" } then {
> set b "00"
> }
>
> append line "$r$r$g$g$b$b"
> puts $fp $line
> }
>
> for {set y 0} {$y > -21} {incr y -1} {
> set line ""
> for {set x 0} {$x < 16} {incr x} {
> set obj [objSelect -query $x $y]
> set l [$obj getLayer]
> append line [string index $abc [lsearch $layerNames [$l
> getName]]]
> }
> puts $fp $line
> }
>
> close $fp
> }
> > -Original Message-
> > From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 31, 2000 10:36 PM
> > To: [EMAIL PROTECTED]
> > Subject: ReflectObject problems
> >
> >
> > Any news on those "table entry did not match arguments" asserts
> > you were getting? The error you describe is VERY bad, so I want
> > to make sure that this bug is killed sooner rather than later.
> > I want to get a 1.2.6 release out the door before the Tcl
> > conference (Feb 14th), but this problem is so bad that I would
> > not want to release a 1.2 "final" with the bug.
> >
> > 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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Problems building tclblend1.2.5
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 tclblend1.2.5 on Solaris 2.5.1 with jdk1.1.8 and tcl8.0 > > the make and make shell worked well. > While running make test, here is the error I get. > Can anyone help me? > make test > # > # Making test_tcljava.build > # > mkdir -p /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests > cd > /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/../src/tests/tcljava > ;\ > >CLASSPATH=/usr/test/tools/vendor/jdk1.1.8/lib/classes.zip:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tclblend.jar:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tcljava.jar > > \ > /usr/test/tools/vendor/jdk1.1.8/bin/javac -g \ > -d /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests > pkg1/*.java pkg2/*.java \ > tcl/lang/*.java tests/*.java tests/invoke/*.java \ > tests/javainfo/*.java tests/signature/*.java \ > tests/exec/*.java > mkdir -p > /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests/javaload > mkdir -p > >/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests/javaload/tests/javaload > cd > /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/../src/tests/tcljava > ;\ > >CLASSPATH=/usr/test/tools/vendor/jdk1.1.8/lib/classes.zip:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tclblend.jar:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tcljava.jar:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests/javaload > > \ > /usr/test/tools/vendor/jdk1.1.8/bin/javac -g \ > -d > /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests/javaload > javaload/*.java > cd /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests/javaload; > \ > CLASSPATH=/usr/test/tools/vendor/jdk1.1.8/lib/classes.zip \ > /usr/test/tools/vendor/jdk1.1.8/bin/jar -cf0M test9.jar > Test9Extension.class; \ > rm Test9Extension.class > cd /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests/javaload; > \ > CLASSPATH=/usr/test/tools/vendor/jdk1.1.8/lib/classes.zip \ > /usr/test/tools/vendor/jdk1.1.8/bin/jar -cf0M test10.jar > Test10Extension.class; \ > rm Test10Extension.class > # > # Making test_tclblend.build > # > cd > /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/../src/tests/tclblend > ;\ > >CLASSPATH=/usr/test/tools/vendor/jdk1.1.8/lib/classes.zip:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tclblend.jar:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tcljava.jar > > \ > /usr/test/tools/vendor/jdk1.1.8/bin/javac -g \ > -d /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests > tests/*.java tcl/lang/*.java > > pwd is /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/tests > CLASSPATH is > >/usr/test/tools/vendor/jdk1.1.8/lib/classes.zip:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tests:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tclblend.jar:/usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix/tcljava.jar > auto_path is /usr/test/tools/local/cte/tmp/suvarna/tclBlend1.2.5/unix > /usr/test/tools/local/cte/pub/tcl8.0/library /usr/test/tools/local/cte/lib > tcljava/ArrayObject.test > tcljava/AutomaticSignature.test > tcljava/BeanEvent.test > tcljava/BeanEventMgr.test > tcljava/ClassRep.test > tcljava/FieldSig.test > tcljava/FuncSig.test > tcljava/JavaBindCmd.test > tcljava/JavaCallCmd.test > tcljava/JavaCastCmd.test > tcljava/JavaDefineClassCmd.test > tcljava/JavaEventCmd.test > tcljava/JavaFieldCmd.test > tcljava/JavaImportCmd.test > tcljava/JavaInfoCmd.test > tcljava/JavaInstanceofCmd.test > tcljava/JavaInvoke.test > tcljava/JavaIsNullCmd.test > tcljava/JavaLoadCmd.test > tcljava/JavaLock.test > tcljava/JavaNewCmd.test > tcljava/JavaNullCmd.test > tcljava/JavaPropCmd.test > tcljava/JavaThrowCmd.test > tcljava/JavaTryCmd.test > tcljava/PkgInvoker.test > tcljava/PropertySig.test > tcljava/ReflectException.test > tcljava/ReflectObject.test > tcljava/TclEvent.test > tclblend/javaCmd.test > tclblend/javaIdle.test > tclblend/javaInterp.test > tclblend/javaObj.test > tclblend/javaTimer.test > tclblend/javaUtil.test > Tests done. > called Tcl_Close on channel with refCount > 0 > SIGA
[Tcl Java] Re: [Tcl Java] problem in installing tclblend1.2 in win32
You need to add the Java lib locations to your PATH. Tcl is trying to load tclblend.dll which needs java.dll. On JDK 1.2, java.dll also needs some other dlls that are not located in the same directory! You should be able to test this by running "nmake -f makefile.vc shell" and then typing "package require java". The Makefile rule will set the PATH up correctly, but you will need to add it by hand to your env. There are also lots of examples of how to fix this problem in then mailing list archives. Mo Dejong Red Hat Inc. On Sat, 5 Feb 2000, Subhrajyoti Moitra wrote: > i downloaded the latest tclblend1.2.5 for jdk1.2 ... > unzipped it in c:\program Files\Tcl\... > this is where i have tcl8.2 > i then tried to load it ... in the tclsh .. > % package require java > > it gave me the following error > > "load tclblend.dll" failed: > couldn't load file "tclblend.dll": invalid argument > > i even moved the .dll file to the lib directory ... > in this case case it gave me the following error > "load c:/Program Files/Tcl/lib/tclblend/tclblend.dll" failed: > couldn't load file "C:\Program Files\Tcl\lib\tclblend\tclblend.dll": > invalid argument > > now what ... i am using jdk1.2 installed in > c:\Program Files\jdk1.2 > i am using Tcl/Tk 8.2 for Windows, Binary Distribution > > > 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 PROTECTED] > with the word UNSUBSCRIBE as the subject. > To send to the list, send email to '[EMAIL PROTECTED]'. > An archive is available at http://www.mail-archive.com/tcljava@scriptics.com > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Problems compiling tclblend under Linux
Red Hat includes Kaffe as the default JVM. Your PATH is picking up Kaffe from /usr/bin/javac instead of the JDK. You need to use the --with-jdk=$SOMEPATH argument to indicate where your JDK is installed. You could also prepend the location of your JDK bin directory to your PATH, then configure would find javac in the JDK bin directory not the /usr/bin directory. P.S. You can actually use the Kaffe JVM with Jacl, but tclblend has not been tested with Kaffe because you need glibc 2.1.2 to use the pthreads version of Kaffe and I have glib 2.0 on my Linux box. If you want to do some hacking with Kaffe you can use the --with-kaffe argument to the configure script. Look for info at www.kaffe.org. Mo Dejong Red Hat Inc. On Tue, 8 Feb 2000, Mike Schneider wrote: > Hello, > I'm trying to compile tclblend under Redhat Linux. I have Kaffe and Sun's > jdk1.2.2 installed. CLASSPATH is set to nothing. Here's the error I get: > > > [mpschnei@peace unix]$ ./configure > loading cache ./config.cache > srcdir is /usr1/schneider/tclBlend1.2.5/unix > checking for javac... /usr/bin/javac > Java found at /usr > checking for zip or jar files to include on CLASSPATH... configure: error: > could not find zip or jar files to include on CLASSPATH. > > What's happening? 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] RE: [TclJava] Problems compiling tclblend under Linux
When you executed the "make install" rule did it run the test case correctly? It should print something like "Installed program is working correctly". If that worked but you can not load tclblend.so once it is installed, then you must be using the wrong tclsh. You can not just load Tcl Blend into any old tcl shell lying around on the system, it needs to be loaded into the one you just built and linked with. You are using the jtclsh script that gets installed into $exec_prefix/bin right? The jtclsh script will "do all the right things" to set up env vars and start the correct version of tclsh. You can also test out the version of Tcl Blend "in place" without having to install it by running the "make shell" rule. That rule will pop you into the correct tclsh with all the env vars correctly. Mo Dejong Red Hat Inc. On Tue, 8 Feb 2000, Mike Schneider wrote: > I added that to no avail, as per below. > > > > tcl>package require java > > called loadtclblend "/usr/local/lib/tclblend" > tclblend_shlib is libtclblend.so > found tclblend.jar at /usr/local/lib/tclblend/../tclblend.jar > found tcljava.jar at /usr/local/lib/tclblend/../tcljava.jar > found tcljava.jar on env(CLASSPATH) at > /usr/local/lib/tclblend/../tcljava.jar > found tclblend.jar on env(CLASSPATH) at > /usr/local/lib/tclblend/../tclblend.jar > before "load libtclblend.so", env(CLASSPATH) was > "/usr/local/lib/tclblend/../tcljava.jar:/usr/local/lib/tclblend/../tclblend. > jar:" > Attempting to figure out why "load libtclblend.so" failed > currently LD_LIBRARY_PATH is set to > "/usr1/schneider/tclBlend1.2.5/unix:/usr1/schneider/jdk1.2.2/jre/lib/i386:/u > sr/local/lib:/usr1/schneider/jdk1.2.2/jre/lib/i386/classic" > found duplicate libtclblend.so on LD_LIBRARY_PATH at > "/usr/local/lib/libtclblend.so", first was at > /usr1/schneider/tclBlend1.2.5/unix/libtclblend.so > found libtclblend.so on LD_LIBRARY_PATH at > "/usr1/schneider/tclBlend1.2.5/unix/libtclblend.so". > found libjava.so on LD_LIBRARY_PATH at > "/usr1/schneider/jdk1.2.2/jre/lib/i386/libjava.so". > Error: "load libtclblend.so" failed: > couldn't load file "libtclblend.so": libtclblend.so: cannot open shared > object file: No such file or directory > tcl> > tcl> > tcl>puts $auto_path > /usr/lib/tcl8.0 /usr/lib /usr/lib/tclX8.0.4 /usr/local/lib/tclblend > tcl> > tcl>puts $env(LD_LIBRARY_PATH) > /usr1/schneider/tclBlend1.2.5/unix:/usr1/schneider/jdk1.2.2/jre/lib/i386:/us > r/local/lib:/usr1/schneider/jdk1.2.2/jre/lib/i386/classic > tcl> > > > > At 12:49 PM 2/8/00 -0800, Scott Redman wrote: > >There is a "classic" directory for JDK 1.2 that also needs to > >be in your LD_LIBRARY_PATH. > > > >-- Scott > > > >-Original Message- > >From: Mike Schneider [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, February 08, 2000 12:15 PM > >To: [EMAIL PROTECTED] > >Subject: [Tcl Java] Re: [Tcl Java] RE: [Tcl Java] Problems compiling > >tclblend under Linux > > > > > >OK, fixed that one. (Actually figured it out myself ;) Now when I try to > >load the java package in tcl, I get the > >following (debug info turned on): > > > >% package require java > > > >called loadtclblend "/usr/local/lib/tclblend" > >tclblend_shlib is libtclblend.so > >found tclblend.jar at /usr/local/lib/tclblend/../tclblend.jar > >found tcljava.jar at /usr/local/lib/tclblend/../tcljava.jar > >found tcljava.jar on env(CLASSPATH) at > >/usr/local/lib/tclblend/../tcljava.jar > >found tclblend.jar on env(CLASSPATH) at > >/usr/local/lib/tclblend/../tclblend.jar > >before "load libtclblend.so", env(CLASSPATH) was > >"/usr/local/lib/tclblend/../tcljava.jar:/usr/local/lib/tclblend/../tclblend. > >jar:" > >Attempting to figure out why "load libtclblend.so" failed > >currently LD_LIBRARY_PATH is set to > >"/usr1/schneider/tclBlend1.2.5/unix:/usr1/schneider/jdk1.2.2/jre/lib/i386:/u > >sr/local/lib" > >found duplicate libtclblend.so on LD_LIBRARY_PATH at > >"/usr/local/lib/libtclblend.so", first was at > >/usr1/schneider/tclBlend1.2.5/unix/libtclblend.so > >found libtclblend.so on LD_LIBRARY_PATH at > >"/usr1/schneider/tclBlend1.2.5/unix/libtclblend.so". > >found libjava.so on LD_LIBRARY_PATH at > >"/usr1/schneider/jdk1.2.2/jre/lib/i386/libjava.so". > >"load libtclblend.so" failed: > > couldn't load file "libtclblend.so": libtclblend.so: cannot open shared &g
[Tcl Java] Re: [Tcl Java] TclBlend problem on AIX...
It might be a JIT bug. Try setting the env var JAVA_COMPILER to ""
and run it again. I have never heard of anyone getting Tcl Blend
running on AIX so it looks like you are charting new waters.
Mo Dejong
Red Hat Inc.
On Wed, 9 Feb 2000, Scott Redman wrote:
> Has anyone seen this error before? This is on AIX 4.2.1
> with IBM JDK 1.1.8.
>
> -- Scott
>
>
> tcljava/ArrayObject.test
> java.lang.AbstractMethodError: init
> at tcl.lang.Extension.init(Compiled Code)
> Unable to find the java package. Skipping entire test.:
> "load libtclblend.so" failed:
> java.lang.AbstractMethodError@600941c
> while executing
> "error "\"load $tclblend_shlib\" failed:\n $errMsg""
> (procedure "loadtclblend" line 390)
> invoked from within
> "loadtclblend /tmp_mnt/home/redman/ws/tcljava/aix-ppc"
> ("package ifneeded" script)
> invoked from within
> "package require java"
> Exception in thread "main" Target "test" is up to date.
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] More info on tclBlend problem on Solaris 2.5.1 ...
What happens if you set the env var JAVA_COMPILER to ""? If this is a Sun JIT bug that should work around the problem. I have never seen an error like this on Solaris but then again I have only tested with JDK 1.1 and a prerelease of JDK 1.2. Mo Dejong Red Hat Inc. On Wed, 9 Feb 2000 [EMAIL PROTECTED] wrote: > > > I reported a problem earlier about tclBlend 1.2.5 on Solaris 2.5.1 > running TCL 8.2.2 and Sun JDK 1.2.2 where TCL interpreters are being > created and deleted repeatedly. Under this environment, TclBlend only > seems to work in the first couple of TCL interpreter creation and > deletion cycles then it crashes the application. I've been able to > obtain a stack dump of the crash: > > [1] cacheAlloc(0x0, 0xca2, 0x1a0, 0xec14426c, 0x1a0, 0x178eff8), at > 0xec143b50 > [2] JITSupport_anewarray(0xe7098548, 0x65, 0x0, 0xe7098548, > 0xe70b0350, 0xee913f38), at 0xec0bb790 > [3] 0x18ab834(0xe70b0350, 0x65, 0x3f40, 0x2c40, 0xec13f680, > 0x178f164), at 0x18ab833 > [4] 0x18b2b14(0xe70b0350, 0x178eff8, 0xe7098570, 0x178f1a4, > 0x17900c4, 0x3), at 0x18b2b13 > [5] 0x1936878(0xe70b0340, 0x1336f8, 0x62767463, 0x0, 0x178f164, > 0xec1ac8cb), at 0x1936877 > [6] JITInvokeCompiledMethod(0xe70b0340, 0x192feb4, 0x3, 0x178eff8, > 0xec13f680, 0xeaf07580), at 0xec0de978 > [7] callmethod_1(0xeaf07578, 0x178eff8, 0x178f198, 0x178f124, > 0xeaf07580, 0x178f164), at 0xec193be4 > [8] jni_Invoke(0x178eff8, 0x178f164, 0x192feb4, 0xa, 0xe70b0340, > 0x100), at 0xec156594 > [9] jni_Construct(0x178eff8, 0x1790420, 0x192feb4, 0xec155fc4, > 0xeaf0764c, 0x178eff8), at 0xec15724c > [10] jni_NewObject(0x178eff8, 0x1790420, 0x192feb4, 0x1336f8, > 0x62767463, 0xee913f38), at 0xec1573a4 > =>[11] Tclblend_Init(interp = 0x1336f8), line 307 in "javaCmd.c" > > It's pretty clear that a null pointer is being passed into > cacheAlloc() which is in libjvm.so. Unfortunately, I have no > information on the parameters passed into cacheAlloc(). Does anyone > know this information and/or have a clue why a null pointer is being > passed ? > > > Thanks, > > George Wu 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Misuse of the java::import command
I was just looking at some Tcl/Java code that someone wrote and I noticed that they did not seem to understand how to use the java::import method. Here is a short snip of the code. package require java java::import -package java.sql I want to make sure that everyone knows that this bit of code does not do the same thing as the following java statement. import java.sql.*; In fact, the Tcl/Java code from above does nothing at all because [java::import -package java.sql] would just return the classes in the java.sql package that had been imported by an earlier call to java::import. Why you ask? Well because that is how it works. Also, there is no way to find the names of all the classes in a package using the Java 1.1 reflection API. There is also the fact that using a * pattern can lead to broken code if classes in a package are changed at a later date. I thought I made this clear in the docs, but perhaps adding a bit about how not to use the command would keep people from making this error in the future. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Tcl Blend and $errorCode
This is a followup to the next two postings. >We've been experiencing an intermittent error when trying to > reference the second object in the global variable $errorCode. > >In the case of a java exception, Tcl blend sets the second object in >errorCode to a reference to the java exception. Occaisionally, when >referencing the java exception to get a stack trace as in: > >set exception [lindex $errorCode 1] >$exception printStackTrace > >we experience the following error: > >invalid command "java0x12345" > >(the memory address of the exception) at the $exception printStackTrace >line. Sometimes we get the stack trace, sometimes we get the error. > >Thank you, >David Birtwell ... >On Thu, 17 Feb 2000 [EMAIL PROTECTED] wrote: > > > > Hi, > > I am not positive that this is the answer, but I have experienced a similar > thing. I was actually getting a tcl.lang.ReflectObject back and had to use > something like: > > set exception [lindex $errorCode 1] > [$exception get] printStackTrace > > Hope this helps. > Dan Munk Can this problem be reproduced with some small script? You could try running [java::info class $exception] and see what type the second element of the errorCode is getting set to. It should be the java.lang.Throwable or some type derived from Throwable (like Exception). It should not be a tcl.lang.ReflectObject! If it is a ReflectObject, than something is very wrong. You could also try running java::isnull to test the ref and make sure the internal 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:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] More info on tclBlend problem on Solaris 2.5.1 ...
You should be able to use Tcl Blend from multiple interps, but I am not sure how well tested that feature is. Is anyone else using multiple interps in different threads to access Tcl Blend? As for the crash you are seeing, what stack trace are you getting with the JIT disabled? Is should be different than the last one you posted. Mo Dejong Red Hat Inc. On Thu, 10 Feb 2000 [EMAIL PROTECTED] wrote: > > I've tried disabling the JIT and the crash still occurs. Here is the test > script I use: > > set tclblend_init "-native -Djava.compiler=NONE" > > package require java > > set jStrObj [::java::new String "This is a Java String ..."] > set tStrObj [$jStrObj toString] > puts $tStrObj > > > One thing I did not mention was that the application I am integrating > with tclBlend is a multi-threaded application. Would this cause problems ? > Also, is it possible to create instance of JVM and use it from multiple > interpreters in tclBlend ? > > > > George Wu > > > On Thu, 10 Feb 2000, Mo DeJong wrote: > > > Date: Thu, 10 Feb 2000 11:53:33 -0800 (PST) > > From: Mo DeJong <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Re: [Tcl Java] More info on tclBlend problem on Solaris 2.5.1 ... > > > > What happens if you set the env var JAVA_COMPILER to ""? If this is a Sun > > JIT bug that should work around the problem. I have never seen an error > > like this on Solaris but then again I have only tested with JDK 1.1 > > and a prerelease of JDK 1.2. > > > > Mo Dejong > > Red Hat Inc. > > > > On Wed, 9 Feb 2000 [EMAIL PROTECTED] wrote: > > > > > > > > > > > I reported a problem earlier about tclBlend 1.2.5 on Solaris 2.5.1 > > > running TCL 8.2.2 and Sun JDK 1.2.2 where TCL interpreters are being > > > created and deleted repeatedly. Under this environment, TclBlend only > > > seems to work in the first couple of TCL interpreter creation and > > > deletion cycles then it crashes the application. I've been able to > > > obtain a stack dump of the crash: > > > > > > [1] cacheAlloc(0x0, 0xca2, 0x1a0, 0xec14426c, 0x1a0, 0x178eff8), at > > > 0xec143b50 > > > [2] JITSupport_anewarray(0xe7098548, 0x65, 0x0, 0xe7098548, > > > 0xe70b0350, 0xee913f38), at 0xec0bb790 > > > [3] 0x18ab834(0xe70b0350, 0x65, 0x3f40, 0x2c40, 0xec13f680, > > > 0x178f164), at 0x18ab833 > > > [4] 0x18b2b14(0xe70b0350, 0x178eff8, 0xe7098570, 0x178f1a4, > > > 0x17900c4, 0x3), at 0x18b2b13 > > > [5] 0x1936878(0xe70b0340, 0x1336f8, 0x62767463, 0x0, 0x178f164, > > > 0xec1ac8cb), at 0x1936877 > > > [6] JITInvokeCompiledMethod(0xe70b0340, 0x192feb4, 0x3, 0x178eff8, > > > 0xec13f680, 0xeaf07580), at 0xec0de978 > > > [7] callmethod_1(0xeaf07578, 0x178eff8, 0x178f198, 0x178f124, > > > 0xeaf07580, 0x178f164), at 0xec193be4 > > > [8] jni_Invoke(0x178eff8, 0x178f164, 0x192feb4, 0xa, 0xe70b0340, > > > 0x100), at 0xec156594 > > > [9] jni_Construct(0x178eff8, 0x1790420, 0x192feb4, 0xec155fc4, > > > 0xeaf0764c, 0x178eff8), at 0xec15724c > > > [10] jni_NewObject(0x178eff8, 0x1790420, 0x192feb4, 0x1336f8, > > > 0x62767463, 0xee913f38), at 0xec1573a4 > > > =>[11] Tclblend_Init(interp = 0x1336f8), line 307 in "javaCmd.c" > > > > > > It's pretty clear that a null pointer is being passed into > > > cacheAlloc() which is in libjvm.so. Unfortunately, I have no > > > information on the parameters passed into cacheAlloc(). Does anyone > > > know this information and/or have a clue why a null pointer is being > > > passed ? > > > > > > > > > Thanks, > > > > > > George Wu > > > > -- > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] some progress with java::defineclass problem
On Tue, 15 Feb 2000, Vince Darley wrote: > Mo, > > Here's my latest progress: > > I've compiled tclblend against Tcl 8.3 and IBM's jdk 1.1.8, and > java::defineclass now works, BUT '$class newInstance' gives me: > > java.lang.VerifyError: Cust > > or > > java.lang.VerifyError: bios/Cust > > (depending on if I put the class in a package or not). > > Which I'm now looking into... The code does seem to get further than with > Sun's jdk 1.2, although I've had to make changes to the code to compile with > jdk 1.1, and now I can also kind of load the code into Sun's jdk, but with a > similar error: > > java.lang.VerifyError: (class: bios/Cust, method: initialise signature: ()V) > Illegal instruction found at offset 25 (although this is a 1.1 compiled > version of the code loading into a 1.2 jvm). > > I'm not entirely sure what conclusions to draw from this... > > Vince. Still sounds like a JVM bug to me. I remember you mentioned something about the class data getting hosed before it was sent to the java::defineclass command. Are you still seeing that problem? What happens if you recompile your source code with the compiler that comes with JDK 1.2? Do you still get those verify errors from the Sun JDK? This is all very strange. Another thing you could try would be to just take the same .class files and write a small Java class that does the loading. This would bypass Tcl/Java completely so you can be sure it is a JVM bug. If you can create a simple Java class that shows the JVM bug, post 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 Corporation. To subscribe:send mail to [EMAIL PROTECTED] with the word SUBSCRIBE as the subject. To unsubscribe: send mail to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] -1.#IO result from double->string
On Fri, 18 Feb 2000, Vince Darley wrote:
> I reported a problem with this some time ago, and have now tracked it down.
> Not sure if it's a bug or not (I certainly couldn't find -1.#IO documented
> anywhere as the java string representation of -infinity), but basically it's
> a result of divide by zero:
>
> public class Test {
> public static double test(int a, int b) {
> return ((double)a)/(480.0+(double)b);
> }
> }
>
> make Test available to tclblend
>
> % java::call Test test 1000 -480
> 1.#IO
> % java::call Test test -1000 -480
> -1.#IO
>
> Hope that helps someone else avoid the problem. In my case this means
> there's a bug in my code which leads to the wrong 'b' value above...
>
> cheers,
>
> Vince.
Yeah, this is one of those really nasty areas of the JVM that do
not seem to be documented. Different JVMs on different platforms
return different things. Check out this nasty test case from
tcljava/tests/tcljava/JavaFieldCmd.test.
test javaFieldCmd-6.7 {test -Inf} {
set result [java::field java.lang.Double NEGATIVE_INFINITY]
set result [string trim $result]
if {[string compare $result -Inf] == 0 || \
[string compare $result -Infinity] == 0 || \
[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.
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] New 1.3 version is in the CVS
The new 1.3 version of the Tcl/Java tools is starting to show up in the CVS. The 1.3 version is for developers only, it is not "stable". There are some cool new features that folks might want to try out including new regexp and regsub commands and a history command. To check the 1.3 version out of the cvs just do a "cvs update" or a "cvs checkout" and you will get the new stuff. If you want to keep using the 1.2 version you need to use the branch-1_2 tag to a checkout or update command. setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot # This will get Tcl/Java 1.3 cvs checkout tcljava # This will get the "stable" 1.2 branch cvs checkout -r branch-1_2 tcljava I also switched to a ChangeLog instead of the old changes.txt file because the Tcl core is also doing that. Enjoy. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] New 1.3 version is in the CVS
I tried to use some stuff on dev.scriptics.com but I had little luck. I could not figure out how to search for bugs. I ended up finding how to search for Jacl bugs, but the listings were read only so I could not update any of the bug reports. To be honest, I just did not think dev is all that easy to use right now, and it seems like more or an advert for Scriptics Connect than anything. I could be a little biased because I only played around with it for about 15 minutes, but I will have to stick with the tcljava mailing list for now. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] New 1.3 version is in the CVS
Oops, looks like this email spilled over onto the tcljava list. At any rate, I was not trying to rip on dev.scriptics.com, I was just saying that creating another place for people to post tcljava questions does not seem like a good idea to me. Folks can post to comp.lang.tcl without "much work". They do have to do a little more to sign up for the tcljava mailing list, but that is a good thing because random flamers might tend to stay off the list. We have this same problem with the bug database, it was only visible to people inside Scriptics so reports went in but I never saw them. I just do not feel like looking at a bunch of tcljava emails, then looking at comp.lang.tcl, then going to a Scriptics bug database, and then looking at a BBoards. It was hard enough to just get people to use the mailing list. As for the HTML stuff, yes we need that. It takes far to long 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 easier to use. The bug facilities need some work > (and we need to make it writable). But, the BBoards are working. > > It's meant to have a Scriptics branding, since we're sponsoring > it. Some feedback from the conference is being discussed by > our exec. staff. But, we tried to keep much more of the > Scriptics Connect on the www page rather than dev. Honestly, > the Connect product may provide a lot momentum for Tcl/Tk. > > Brent is also working on pages for custom projects. For > instance, you could have a whole set of web pages for Jacl > that you control (you write the HTML, etc.). Let him > know if you want that. > > -- Scott > > > -Original Message- > > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 23, 2000 4:08 PM > > To: [EMAIL PROTECTED] > > Subject: [Tcl Java] Re: [Tcl Java] New 1.3 version is in the CVS > > > > > > I tried to use some stuff on dev.scriptics.com but I had little luck. > > I could not figure out how to search for bugs. I ended up finding how > > to search for Jacl bugs, but the listings were read only so I could > > not update any of the bug reports. To be honest, I just did not think > > dev is all that easy to use right now, and it seems like more or an > > advert for Scriptics Connect than anything. I could be a little biased > > because I only played around with it for about 15 minutes, but I will > > have to stick with the tcljava mailing list for now. > > > > 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 PROTECTED] > > with the word UNSUBSCRIBE as the subject. > > To send to the list, send email to '[EMAIL PROTECTED]'. > > An archive is available at > > http://www.mail-archive.com/tcljava@scriptics.com > > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] binary command for Jacl has been added to the CVS
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 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] External classloader for JACL
Both Jacl and Tcl Blend already use a class loader called TclClassLoader. Is there a feature that you would like to add added to the TclClassLoader or are you looking to bypass it completely? I do not really see anything wrong with adding something to the TclClassLoader or replacing it completely with something better. I really do not like the current design because as a programmer, you need to use the TclClassLoader explicitly, when this type of thing really should be done behind the scenes. I was also planning on stripping out the "feature" of the Tcl Class Loader that automatically 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, 2 Mar 2000, Vladimir Zamiatin wrote: > Hello! > > I'm using JACL in web environment. I wrote engine > similar to JSP, which allows to embed Tcl scripts > in HTML pages. I want to make use of an > advanced classloader, provided by servlet runner > which has possibility to check for modification > of class or source java files in web-applications, > and recompile/reload them on-the-fly. > > I suppose one essential feature is missing in JACL: > an ability to use external class loader in interp. > It would be an easy change to add this feature to > JACL: > > Interp.setClassLoader(ClassLoader loader); > Interp.getClassLoader(); > > And TclClassLoader can use this loader (if > present in Interp) to load classes. For > performance reasons it would be great if > this external loader has priority upon standard > class loading mechanisms. > > I beleive that this feature will improve > JACL ability to be embeded into different > applications and environments. > > Best regards, > Vladimir. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] External classloader for JACL
Perhaps I was not being clear. I am proposing two changes. 1. Remove the "search for .zip and .jar files" on env(TCL_CLASSPATH) feature. The fact that a use might accidently get .class files from a .jar or .zip file is just plain wrong. 2. Make a new env var called env(TCL_JARPATH) which is a list of directories that will be searched for jar and zip files. So to sum up, env(TCL_CLASSPATH) would no longer be searched for jars and only the directories listed in env(TCL_JARPATH) would be searched. Of course, if you wanted to put the full path name of a .jar file 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 from the jar > files. As long as I can still do this through an alternative method (such > as TCL_CLASSPATH) it'll work. I can see the benefit of such a system. > > > -Original Message- > > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, March 02, 2000 4:06 PM > > To: [EMAIL PROTECTED] > > Subject: [Tcl Java] Re: [Tcl Java] External classloader for JACL > > > > > > Both Jacl and Tcl Blend already use a class loader called TclClassLoader. > > Is there a feature that you would like to add added to the TclClassLoader > > or are you looking to bypass it completely? I do not really see anything > > wrong with adding something to the TclClassLoader or replacing it > > completely with something better. I really do not like the current design > > because as a programmer, you need to use the TclClassLoader explicitly, > > when this type of thing really should be done behind the scenes. I was > > also planning on stripping out the "feature" of the Tcl Class Loader that > > automatically 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, 2 Mar 2000, Vladimir Zamiatin wrote: > > > > > Hello! > > > > > > I'm using JACL in web environment. I wrote engine > > > similar to JSP, which allows to embed Tcl scripts > > > in HTML pages. I want to make use of an > > > advanced classloader, provided by servlet runner > > > which has possibility to check for modification > > > of class or source java files in web-applications, > > > and recompile/reload them on-the-fly. > > > > > > I suppose one essential feature is missing in JACL: > > > an ability to use external class loader in interp. > > > It would be an easy change to add this feature to > > > JACL: > > > > > > Interp.setClassLoader(ClassLoader loader); > > > Interp.getClassLoader(); > > > > > > And TclClassLoader can use this loader (if > > > present in Interp) to load classes. For > > > performance reasons it would be great if > > > this external loader has priority upon standard > > > class loading mechanisms. > > > > > > I beleive that this feature will improve > > > JACL ability to be embeded into different > > > applications and environments. > > > > > > Best regards, > > > Vladimir. > > > > > > > > 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 PROTECTED] > > with the word UNSUBSCRIBE as the subject. > > To send to the list, send email to '[EMAIL PROTECTED]'. > > An archive is available at > > http://www.mail-archive.com/tcljava@scriptics.com > > > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Using native TCL in JVM
Here is a note from the original author of Tcl Blend on this subject. Mo Dejong Red Hat Inc. Jiang Wu said: > Then there is TclBlend, which does a nice job of linking a native TCL > interpreter with JVM. But TclBlend assumes that the TCL interpreter starts > first, then it creates a JVM to run the Java code. That is the reverse of > my setup, in which the JVM starts first, then loads the TCL interpreter. TclBlend can also be used from inside a preexisting JVM. TclBlend should only create a new JVM if it can't find one already running. You can use the tcl.lang.Interp class to create a new Tcl interpreter and then evaluate scripts in it. Your sample code seemed correct without any modifications to blend. The initialization code in Tclblend_Init is only needed if you are loading the package from C initially. It mostly just creates a new Interp object to wrap the already existing C interpreter. If you are creating the initial interpreter from Java, then it doesn't need to do this. > 1. What is the java.NativeLock monitor protecting? Is TclBlend using the > monitor to protect against multiple access to the C globals, access to the > JVM, access to the TCL Interp instance, all? The Tcl library uses an apartment model for threads where each interpreter hierarchy can only be used from a single thread during its lifetime. There is a lot of state stored in thread-local variables, so you can't use the same interp from multiple threads. When TclBlend was originally written Tcl didn't support threading at all, so it has probably not been modified to use the new Tcl threading mechanisms. It should be feasible to change TclBlend so it allows different threads to access independent interpreters. However, there is still the challenge of matching up the Java and Tcl thread libraries. You should be able to eliminate the monitor as long as you ensure that no Java thread ever attempts to access an interpreter that it didn't create. > 2. Does having the globals and a global monitor mean that there is no > benefit in using multiple TCL interp in Java in multiple threads? All calls > are serialized by the monitor. That is true. Currently all access to the Tcl library is serialized. > 3. When the TCL Interp is idling such as in the native code of a > tcl.lang.Notifier.doOneEvent(), TclBlend does not release the monitor. As a > result, any other Java thread trying to access any of the tcl.lang.* native > method will block due to the global monitor. Is this intended? Yes, this is intended because the TclBlend library has not been made thread aware. If you remove the monitor, then you need to ensure that a given Interp object is never used outside of the thread that created it. This goes for all of the classes in the tcl.lang package. The one exception to this rule is the tcl.lang.Notifier.alertNotifier() method which can be used to wake up a Tcl interpreter that is sitting in the event loop from a different thread. > BTW, the good news is that if I compile TclBlend without the synchronization > calls, my test Java program is able to load the native TCL interpreter and > execute TCL scripts in it. I tried out the gridDemo in the Jacl package and > it worked. This should be safe as long as you never use an interpreter outside of the thread that created it. --Scott 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] TclBlend problem on Solaris 2.5.1
Any news on this problem? Did you still get a core dump after turning the JIT off? Do you get the same error if you run it on another system (like Linux + the Blackdown JDK port)? You bug report is the only of its kind that I have seen, so I am fairly sure it is a JIT bug (trust me, it is almost always a JIT bug). Mo Dejong Red Hat Inc. On Thu, 3 Feb 2000 [EMAIL PROTECTED] wrote: > > I am trying to integrate TclBlend into an embedded TCL environment in my > application on Solaris 2.5.1 where TCL interpreters are being created > and deleted repeatedly. Under this environment, TclBlend only seems to > work in the first couple of TCL interpreter creation and deletion cycles then > it crashes the application. I've tracked it down to the call to create > java.Interp object in Tclblend_Init() in javaCmd.c. The function call is > as follows: > > local = (*env)->NewObject(env, java.Interp, > java.interpC, lvalue); > > I've verified that 'env' and 'lvalue' are both not NULL. Does anyone > know of another reason why this function call would crash ? > > Any help will be greatly appreciated. > > > George 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Proposal : a public tcl.lang.Interp.appendElement method
Hi all.
Here is a patch that implements a public tcl.lang.Interp.appendElement()
method for Jacl and Tcl Blend. The appendElement method is a mapping
of the Tcl_AppendElement function from the C implementation.
Does anyone see any problem with adding this to the 1.3 development
version? It adds a public API so I wanted to get some comments
on the change.
Mo Dejong
Red Hat Inc.
Index: diffs.txt
===
RCS file: /home/cvs/external/tcljava/diffs.txt,v
retrieving revision 1.6
diff -u -r1.6 diffs.txt
--- diffs.txt 2000/03/02 04:08:34 1.6
+++ diffs.txt 2000/03/14 01:22:41
@@ -105,6 +105,7 @@
setResult Tcl_SetObjResult
Tcl_SetResult
getResult Tcl_GetObjResult
+ appendElement Tcl_AppendElement
resetResult Tcl_ResetResult
backgroundError Tcl_BackgroundError
addErrorInfoTcl_AddErrorInfo
Index: src/jacl/tcl/lang/Interp.java
===
RCS file: /home/cvs/external/tcljava/src/jacl/tcl/lang/Interp.java,v
retrieving revision 1.26
diff -u -r1.26 Interp.java
--- Interp.java 2000/03/02 04:08:34 1.26
+++ Interp.java 2000/03/14 01:22:42
@@ -1995,7 +1995,7 @@
*--
*/
-void
+public void
appendElement(
String string) /* String to convert to list element and
* add to result. */
@@ -2008,7 +2008,7 @@
result.preserve();
result = result.takeExclusive();
TclList.append(this, result, TclString.newInstance(string));
-setResult(result.toString());
+setResult(result);
result.release();
}
Index: src/native/javaInterp.c
===
RCS file: /home/cvs/external/tcljava/src/native/javaInterp.c,v
retrieving revision 1.4
diff -u -r1.4 javaInterp.c
--- javaInterp.c1999/08/31 00:46:37 1.4
+++ javaInterp.c2000/03/14 01:22:42
@@ -419,6 +419,53 @@
/*
*--
*
+ * Java_tcl_lang_Interp_appendElement -> Tcl_AppendElement
+ *
+ * Convert a string to a valid Tcl list element and append it to the
+ * result (which is ostensibly a list).
+ *
+ * Class: tcl_lang_Interp
+ * Method:appendElement
+ * Signature: (Ljava/lang/String;)V
+ *
+ * Results:
+ * None.
+ *
+ * Side effects:
+ * None.
+ *
+ *--
+ */
+
+void JNICALL
+Java_tcl_lang_Interp_appendElement(
+JNIEnv *env, /* Java environment. */
+jclass interpObj, /* Handle to Interp class. */
+jstring valueStr) /* String to append to result */
+{
+const char * value;
+Tcl_Interp *interp = JavaGetInterp(env, interpObj);
+JNIEnv *oldEnv;
+
+if (!value) {
+ ThrowNullPointerException(env, NULL);
+ return;
+}
+
+JAVA_LOCK();
+value = (*env)->GetStringUTFChars(env, valueStr, NULL);
+Tcl_AppendElement(interp, value);
+(*env)->ReleaseStringUTFChars(env, valueStr, value);
+
+JAVA_UNLOCK();
+
+return;
+}
+
+
+/*
+ *--
+ *
* Java_tcl_lang_Interp_setVar --
*
* Set a variable to the given string.
Index: src/tclblend/tcl/lang/Interp.java
===
RCS file: /home/cvs/external/tcljava/src/tclblend/tcl/lang/Interp.java,v
retrieving revision 1.10
diff -u -r1.10 Interp.java
--- Interp.java 2000/02/23 22:16:27 1.10
+++ Interp.java 2000/03/14 01:22:42
@@ -741,6 +741,37 @@
public final native void
resetResult();
+
+
+/*
+ *--
+ *
+ * Tcl_AppendElement --
+ *
+ * Convert a string to a valid Tcl list element and append it to the
+ * result (which is ostensibly a list).
+ *
+ * Results:
+ * None.
+ *
+ * Side effects:
+ * The result in the interpreter given by the first argument is
+ * extended with a list element converted from string. A separator
+ * space is added before the converted list element unless the current
+ * result is empty, contains the single character "{", or ends in " {".
+ *
+ * If the string result is empty, the object result is moved to the
+ * string result, then the object result is reset.
+ *
+ *--
+ */
+
+public native void
+appendElement(
+String string) /* String to convert to list element and
+* add to result.
[Tcl Java] Re: [Tcl Java] EJB and TCL
I can not think of any reason EJB beans would not work with Jacl or Tcl Blend. Try it out and post your results. I think you will be surprised at how easy it is to regression test beans with Tcl/Java. Mo Dejong Red Hat Inc. On Tue, 14 Mar 2000, David Wasler wrote: > Hi I am new to TCL : > > I would like to is it possible to use EJB with TCL and how. > > My version of TCL is 8.3. > > > Thank You > David L. Wasler > [EMAIL PROTECTED] > > > 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 PROTECTED] > with the word UNSUBSCRIBE as the subject. > To send to the list, send email to '[EMAIL PROTECTED]'. > An archive is available at http://www.mail-archive.com/tcljava@scriptics.com > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] First time loading class from a jar file
Hi Roy. There are two likely causes. First, the .jar file must be created with the "proper" directory structure. For instance, the jacl.jar file looks like this. % jar -tf jacl.jar tcl/lang/AfterCmd.class tcl/lang/AppendCmd.class It looks like you might just be using the java::new command incorrectly. You would NOT want to do this: java::new x.y.z.class Instead, do it like this: set o [java::new x.y.z] Or use the really handy import command. java::import x.y.z set o [java::new z] I hope that helps. Mo Dejong Red Hat Inc. On Tue, 14 Mar 2000, Roy Terry wrote: > Can someome tell me if this is supposed to work? > > I've got an .jar file (produced inhouse). jar -t > can list the classes and jar -x can extract the .class > file I'm interested in. Problem is I haven't so far > been able to load a class from the file. > > After Package require java > I say > set env(TCL_CLASSPATH) ./nameofjar.jar > Then > java::new x.y.z.class > -or- > java::call x.y.z.class > -or- > java::methods x.y.z.class > > All fail with complaint that class can't be > found. > > What's missing? > > -Roy Terry 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Patch for Jacl unicode parser bug, need help testing it!
Hi all.
I think I have tracked down a nasty bug in the Jacl parser. It seems
that unicode backslash sequences were not getting substituted
correctly. If you have some spare time, could you test out the
patch? Apply it like so (from the toplevel dir in the Jacl dist).
--- src/jacl/tcl/lang/Parser.java 1999/08/03 02:33:08 1.7
+++ src/jacl/tcl/lang/Parser.java 2000/03/15 01:23:45
@@ -1756,7 +1756,7 @@
if (count == 0) {
result = 'u';
}
- return new BackSlashResult((char)result, script_index);
+ return new BackSlashResult((char)result, script_index+1);
case '\r':
case '\n':
if (c == '\r') {
patch -p 0 < unicode.patch
Then run the following test.
package require java
puts "doing full unicode replacement/conversion test, this can take
several minutes"
flush stdout
set max [expr {int(pow(2,16)) - 1}]
for {set i 0} {$i < $max} {incr i} {
set n [format %04x $i]
eval "set c \\u${n}"
if {[string length $c] != 1} {
error "incorrect conversion of \\u${n}, length [string length $c]"
}
set s [java::new String $c]
if {$c != [$s toString]} {
error "unicode value $max not passed through properly"
}
}
if {$i != 65535} {
error "not all tests were run"
} else {
puts "all tests passed"
}
thanks
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] q. re. evalResource in Interp.java
On Tue, 14 Mar 2000, Hamish Cunningham wrote: > hi > > I'm using Jacl 1.2.5 on Sun JDKs (1.2 and 1.3 on NT and 1.2 on Solaris). > > My question: Not that I can think of. Unless someone has a good reason not to make it accesable from outside, lets make it public. Grab the 1.3 version from the CVS, make your changes and post a patch. There are a couple of things to watch out for. 1. Do not forget to add a ChangeLog entry. 2. You will need to change this in src/jacl/tcl/lang/Interp.java, src/tclblend/jacl/tcl/lang/Interp.java, and src/empty/tcl/lang/Interp.java. Check out the README file in the empty directory to see how to regen the "empty" jar file. 3. You will also want to add notes about this change to the docs in docs/TclJavaLib. Grab the source from the CVS like so. setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot cvs login (passwd is cvs) cvs checkout tcljava Then make your changes and post the result of the following command to the list so that everyone can have a look at it. cvs diff > Interp.patch I hope that helps. Mo DeJong > Is there a good reason for Interp.evalResource being a package private > method? I'd like to use it... > > Thanks, and thanks for creating a great tool! > (If you're interested, the project I'm working on is at > http://gate.ac.uk, a Java rewrite/development of a C++/Tcl application.) > > Hamish Cunningham > Fellow in Computer Science, University of Sheffield > http://www.dcs.shef.ac.uk/~hamish/ 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] tclBlend: pyramidpkg possible path problem ?
It looks like you are trying to load Tcl Blend into an applet.
This is not possible because Java will not let you do it.
You should be able to run Jacl in an applet as long as you
do not load the java package, but Tcl Blend in an applet will not work.
Perhaps we should change the Makefile so that it does not include
the pyramid demo in the tclBlend source dist.
Mo DeJong
Red Hat Inc.
On Wed, 15 Mar 2000, Ian F. Graham wrote:
> C:\ian_home\java\TclBlendSrc125\tclBlend1.2.5\demos\pyramidpkg>
>
> As error text goes it is not one of the most helpful I have seen, and I am
> having great difficulty finding out what is wrong here. IÂ’m sure it is some
> sort of path/configuration problem. I have copied the tclblend.dll to the
> local directory to ensure that it is found, but this also fails. IÂ’m sure it
> some setting which I am overlooking. Can anyone help ?
>
> To try and isolate the problem, I also tried out the Java Plugin with
> Netscape and IE and got the following error (after I modified pyramid.html
> to accommodate the plugin):
>
> IE:
>
> Java(TM) Plug-in: Version 1.2.2.px
>
> Using JRE version 1.2.2
>
> JAR cache enabled.
> System.loadLibrary("tclblend") failed because of Unknown Throwable
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission loadLibrary.tclblend )
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java
> :195)
> at
> java.security.AccessController.checkPermission(AccessController.java:403)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkLink(SecurityManager.java:824)
> at java.lang.Runtime.loadLibrary0(Runtime.java:464)
> at java.lang.System.loadLibrary(System.java:778)
> at tcl.lang.Interp.(Interp.java:32)
> at Pyramid.init(Pyramid.java:52)
> at sun.applet.AppletPanel.run(AppletPanel.java:333)
> at java.lang.Thread.run(Thread.java:479)
> java.lang.UnsatisfiedLinkError: create
> at tcl.lang.Interp.(Interp.java:130)
> at Pyramid.init(Pyramid.java:57)
> at sun.applet.AppletPanel.run(AppletPanel.java:333)
> at java.lang.Thread.run(Thread.java:479)
>
> ==
>
>
> And Netscape:
>
>
> System.loadLibrary("tclblend") failed because of Unknown Throwable
>
> netscape.security.AppletSecurityException: security.checklink: tclblend
> at java.lang.Throwable.(Compiled Code)
> at java.lang.Exception.(Compiled Code)
> at java.lang.RuntimeException.(Compiled Code)
> at java.lang.SecurityException.(Compiled Code)
> at netscape.security.AppletSecurityException.(Compiled Code)
> at netscape.security.AppletSecurityException.(Compiled Code)
> at netscape.security.AppletSecurity.checkLink(Compiled Code)
> at java.lang.SecurityManager.checkLink(Compiled Code)
> * at java.lang.System.loadLibrary(Compiled Code)
> at tcl.lang.Interp.(Interp.java:32)
> at java.lang.UnsatisfiedLinkError: create
> at tcl.lang.Interp.(Compiled Code)
> at Pyramid.init(Compiled Code)
> * at netscape.applet.DerivedAppletFrame$InitAppletEvent.dispatch(Compiled
> Code)
> at java.awt.EventDispatchThread$EventPump.dispatchEvents(Compiled Code)
> at java.awt.EventDispatchThread.run(Compiled Code)
> at
> netscape.applet.DerivedAppletFrame$AppletEventDispatchThread.run(Compiled
> Code)
>
> So do I have to set some security somewhere other than in the Plugin-Control
> Panel ?
>
> I get the feeling that these messages could be red herrings. Has anyone had
> a similar experience or can see what my problem is ? Any help or hints
> taken.
>
> Ian
>
>
>
>
> Ian F Graham Tel: ++49 (0)611 1731-606
> Projekt-Management
> Patzschke + Rasp Software AG Fax: ++49 (0)611 1731-31
> Bierstadter Straße 7 mailto:[EMAIL PROTECTED]
> D-65189 WiesbadenWeb Site: http://www.prs.de
>
>
>
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] First time loading class from a jar file
On Wed, 15 Mar 2000, Roy Terry wrote: > Mo, > > My jar file looks like the tcl/lang sample > below except that it has a manifest included. Ok, back up and start over. First, extract the classes from the jar file into an empty directory. Then, add that directory to your env(TCL_CLASSPATH). Make sure the .jar file is not sitting in the directory you just created. Then call your java main method like so. java::call mypkg.myclass main If that works, jar up your files, remove the dir you just created and try it again. > However I've even built a new .jar containing > only the one class I'm wanting to work with > (sans manifest) and I still get the "unknown class" message in > all cases. Try running "javap -verify class" just to make sure the file is not hosed in some strange way. > FWIW, I can use the sun java 1.2.2 (on NT) to run the class from > the command line (the class has a main method). > > Any further clues or suggestions? This is > a roadblock to getting Tcl usage going in > the company. Humm, I am not sure what that means. If your class depends on another class that can not be found that might be part of the problem. The TclClassLoader should give you an error message in this case. Oh right, the improved TclClassLoader error message stuff has not been released yet. You could try grabbing the 1.2 branch from the CVS like so. The 1.2 branch includes only bug fixes for 1.2.5 that have yet to be released. setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot cvs login (password is cvs) cvs checkout -r branch-1_2 tcljava cd tcljava/unix autoconf mkdir Build_Jacl cd Build_Jacl ../configure --with-build=jacl --prefix=$your_prefix make make install > I've attached the single-class jar file in hopes > that will answer the mystery. Any java:: technique that > will execute the main method of the class would be > a big boost. I know the sample jar will just generate an > error due to missing class dependencies but just getting > to that point would be an improvement. > > Thanks, > Roy You are not still calling java::new like this, right? java::new x.y.z.class It needs to be like this: java::new x.y.z > PS: I know the java::new call wasn't proper for "real" code. I am just > trying anything to see if I can get access to the class (or any class)! I hope that helps Mo Dejong Red Hat Inc. Things likely to be overheard from a Klingon Programmer Specifications are for the weak and timid! Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM. A TRUE Klingon Warrior does not comment his code! Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] RE: [Tcl Java] tclBlend: pyramidpkg possible path problem ?
On Thu, 16 Mar 2000, Jiang Wu wrote: Thanks. I am sure this will help anyone who wants to do something similar in the future. > I will try to modify the Jacl Shell to work with Tcl and TclBlend. If this > is successful, the shell becomes a very good example on how Tcl can be > embedded into Java. Then, I can write up some documentation on how to use > Tcl and TclBlend from a Java application. > > I read over your paper regarding Tcl. I agree that the Notifier does > accomplish the job of protecting the interpreter from multi-threaded access. > I have no problem with the design of the Interp class and the Notifier > class. It does? How? Perhaps I did not pick up on that in your last email. I do not think the call to Interp.commandComplete() is wrong. It is a static method, so it should be thread safe because it does not touch any interp instance. > I was just thrown off course because the implementation of the Jacl > shell violated the rule on the usage of tcl.lang.Interp. I was not sure if > Jacl did that by design. > > -- Jiang Wu >[EMAIL PROTECTED] 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] How you can get a patch into tcljava!
Hi all. There has been some discussion on the list of late about how one would go about getting a patch applied to the development version of tcljava in the CVS. The process is very easy, just grab the CVS version from Scriptics, add your patch, run the regression tests to make sure your patch does not break anything, and send it to the tcljava mailing list. You can also submit a bug report to the Scriptics bug tracking system (and doing both is even better). To get the CVS archive you would run the following commands. % setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot (use "CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot ; export CVSROOT" for bash) % cvs login (password is cvs) % cvs checkout tcljava % cd tcljava/unix % autoconf % mkdir Build % cd Build (If you only want to build Jacl you would run) % ../configure --with-build=jacl (If you only want to build Tcl Blend you would run) % ../configure --with-build=tclblend --with-tcl=$SOMEWHERE Then you could test your tcljava shell out like so: % make shell You would then do your patching and run the following in the tcljava directory that you just checked out. Don't forget to add an entry to the tcljava/ChangeLog file! % cvs diff > mychanges.patch Then post the mychanges.patch file to the list, it is just that easy. Ok, well it may not be that easy. If your patch changes something that will need to be reflected in the documentation, then you should also take a look at the HTML docs in the tcljava/docs subdirectory. I think a "real" example will help folks understand what files might need changing. I am going to append the output of a "cvs diff" that I made for a change I just checked in today. This modification changes a public API of the TclInteger class, so it requires source and documentaiton fixes. It also adds the [lindex $l end-1] functionality from Tcl 8.3 to Jacl, so a number of regression tests are also updated by this patch. Now keep in mind that most patches will not be this large or complex, but I think this example will help people understand what might be required to get a patch into the tcljava CVS. Mo Dejong Red Hat Inc. Index: ChangeLog === RCS file: /home/cvs/external/tcljava/ChangeLog,v retrieving revision 1.8 diff -u -r1.8 ChangeLog --- ChangeLog 2000/03/15 04:30:35 1.8 +++ ChangeLog 2000/03/17 23:29:45 @@ -1,3 +1,31 @@ +2000-03-17 Mo DeJong <[EMAIL PROTECTED]> + + * docs/cFunctions.html: + * docs/TclJavaLib/TclInteger.htm: + * src/jacl/tcl/lang/LindexCmd.java: + * src/jacl/tcl/lang/LinsertCmd.java: + * src/jacl/tcl/lang/LrangeCmd.java: + * src/jacl/tcl/lang/LreplaceCmd.java: + * src/jacl/tcl/lang/LsortCmd.java: + * src/jacl/tcl/lang/StringCmd.java: + * src/jacl/tcl/lang/Util.java: + * src/tcljava/tcl/lang/TclInteger.java: + * tests/tcl/lindex.test: + * tests/tcl/linsert.test: + * tests/tcl/lrange.test: + * tests/tcl/lreplace.test: + * tests/tcl/string.test: + Renamed and moved the TclInteger.getForIndex() method + to Util.getIntForIndex(). It is a + mapping for the TclGetIntForIndex function + which is private, so it did not belong + in TclInteger. Along with this change, I + updated the implementation of getIntForIndex + so that it is compatible with Tcl 8.3, which + also required adding the Util.checkBadOctal() + method. A number of regression test were update + to account for these changes. + 2000-03-14 Mo DeJong <[EMAIL PROTECTED]> * demos/packDemo/StringSplitter.java: Removed file. Index: docs/cFunctions.html === RCS file: /home/cvs/external/tcljava/docs/cFunctions.html,v retrieving revision 1.2 diff -u -r1.2 cFunctions.html --- cFunctions.html 2000/02/23 22:14:16 1.2 +++ cFunctions.html 2000/03/17 23:29:45 @@ -4,7 +4,7 @@ Links from C Library Functions to Java Library Functions -TclGetIntForIndexTcl_GetBooleanFromObjTcl_ObjType.freeProc +Tcl_GetBooleanFromObjTcl_ObjType.freeProc TclObj.typePtr Tcl_GetCommandInfo Tcl_ObjType.updateStringProc Tcl_AddErrorInfo Tcl_GetDoubleFromObj Tcl_PkgProvide Tcl_AppendToObj Tcl_GetIndexFromObj Tcl_PkgRequire Index: docs/TclJavaLib/TclInteger.htm === RCS file: /home/cvs/external/tcljava/docs/TclJavaLib/TclInteger.htm,v retrieving revision 1.1 diff -u -r1.1 TclInteger.htm --- TclInteger.htm 1999/05/08 22:26:19 1.1 +++ TclInteger.htm 2000/03/17 23:29:45 @@ -9,7 +9,6 @@ METHODS static TclObject newInstance(int intValue) static int get(Interp interp, TclObject tobj) throws TclException -static i
[Tcl Java] Re: [Tcl Java] Using TclBlend with the Jacl Shell
On Thu, 16 Mar 2000, Jiang Wu wrote:
Yeah, you are right about that. The Shell class really should not be
calling those methods from other threads. I think it "just works" in
Jacl because Jacl uses lots of Hashtable objects in its implementation
and those are always thread safe (which is a bug not a feature). Tcl
Blend is much more likely to crash if threads are walking over each other.
> Looking over the Jacl's tcl.lang.Shell source code, there are several places
> where the ConsoleThread is accessing the tcl.lang.Interp object's method.
> For example, the ConsoleThread's run() method makes calls to:
>
> interp.getVar(...);
> interp.setVar(...);
> interp.updateReturnInfo();
> interp.getResult();
> interp.eval();
>
> These calls shouldn't be made by the ConsoleThread since the ConsoleThread
> is not the event loop thread running the interpreter.
>
> The interesting thing about this code is that it is convenient for a
> programmer to call the methods in the tcl.lang.Interp class directly from
> any thread without going through the process of queuing up a TclEvent on the
> Notifier.
This is an interesting idea. I think the "thread safe Interp" class
would need to be called something that would make it very clear that
each of the calls was "slow". I worry that if people read that
TclInterp is thread safe but Interp is not, they would just go using
TclInterp without thinking about some of the consequences (If java
have proven anything, it is that threads should not be used for most
general programming tasks).
Mo DeJong
Red Hat Inc.
> The Notifier class and the Interp class together make it possible to use Tcl
> from a multi-threaded Java environment using an event queue model. It may
> also be useful to have another class, or extending the existing Notifier
> class, to use the Notifier's event queue to provide a function call
> interface to the methods in the Interp class.
>
> For example:
>
> tcl.lang.Interp- used by a single thread only
> eval(),
> setAssocData(),
> deleteAssocData(),
> setVar(),
> getVar(),
> etc.
>
> tcl.lang.Notifier - used by multiple threads through "queueEvent()"
> queueEvent()
> serviceEvent()
> etc.
>
> tcl.lang.TclInterp - uses Notifier's event queue to invoke Interp's
> methods...
> eval(),
> setAssocData(),
> deleteAssocData(),
> setVar(),
> getVar(),
> etc.
>
> Then, the Jacl ConsoleThread can do something like:
>
> void methodFooBar (Interp interp) {
> Notifier notifier = interp.getNotifier();
> TclInterp tclInterp = notifier.getTclInterp();
>
> tclInterp.eval(...);
> tclInterp.setVar(...);
> }
>
> Of course, having this extra class is not absolute necessary. It is only a
> convenience.
>
> -- Jiang Wu
>[EMAIL PROTECTED]
>
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] tclBlend: pyramidpkg possible path problem ?
On Thu, 16 Mar 2000, Jiang Wu wrote: > TclBlend is very close to accomplish the task of using Tcl from a Java > application. TclBlend provides the ability to call TCL commands from Java, > and call Java methods from TCL. I am also trying to do a similar set up for > my project at work. In my setup, I want to embed the native TCL core into a > Java based application server process. Very cool. The ability to load Tcl Blend and Tcl into a running JVM would make a great addition to the 1.3 "development" version. > I had to write a patch to the TclBlend code to make this possible. After > patching the TclBlend code, I was able to write a tclsh like program using > Java. The shell drives the native Tcl interpreter using a Java thread. The > Java based shell is able to run and pass almost the same set of tests in the > Tcl core test suite as the regular C based "tclsh.exe". My simple Java > based shell lacks the ability to take in command line arguments so some of > the tests failed. The Java based shell can also run all tests in the > "tcljava" tests and "tclblend" tests in the TclBlend/Jacl suite. tcl.lang.Interp methods can NEVER be called directly from multiple threads. They can only be called from the event loop thread. This is by design, it is not a bug and it will not be changed! You can deliver events from multiple threads to a Tcl interp, but you can not call interp methods directly. > 1. tcl.lang.Interp methods for TclBlend cannot be called directly by any > threads other than the one running its event loop. The Jacl Shell's console > thread actually makes call to the tcl.lang.Interp.commandComplete() method. > If using TclBlend, this call will block. That sounds like a bug to me. Write up a patch and post it to the list. The method signatures in Jacl should be exactly the same as the ones in Tcl Blend. A good way to fix this problem "once and for all", is to write a regression test that uses the command "java::info methods tcl.lang.Interp" and checks each public signature against a known list of sigs. >In TclBlend, the Java String cannot be used directly for the value of the > variable. The value "tcl.lang.Shell" needs to be wrapped into a TclObject > first. This can be fixed in the TclBlend source code to add another > "setVar" method that matches the one in Jacl. This "wrapper layer" you describe is already written. It is called the Notifier. You might be interested in reading a paper about Tcl Blend and Jacl I wrote a couple of years ago. It describes the way one should put events into the event queue in a thread safe way. http://www.cs.umn.edu/~dejong/tcl/paper.html Section 4.3 describes the way you add thread safe events to the event queue. It sounds like the "real" problem here is one of documentation. We need to add some information to the docs about the event notifier and how multiple threads should interact with a Tcl interp. Jiang, do you have any time to break out the old writer's quil and help out with the documentation? A section on multi-threaded interaction with the Tcl interp and loading of Tcl from inside Java would really help. > Overall, the TclBlend stuff looks fairly good. However, to use it in a Java > program, one has to know its idiosyncrasies. Due to multi-threaded nature > of any Java application, one would need to write a wrapper layer on top of > TclBlend to hide the fact that many class methods in TclBlend are not thread > safe. The wrapper layer will be thread safe and delegate the work to > TclBlend. For example, I would probably write a TclInterp class to wrap > around the tcl.lang.Interp so that any thread can call thanks 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] TclBlend Core Dump
I just ran your example and got a core dump with Tcl Blend 1.2.5
and JDK-1.2.1_03 on a Solaris 5.6 box. This is a mighty strange
one. Why would the parent process lose the signal handler in a fork().
Mo Dejong
Red Hat Inc.
On Mon, 20 Mar 2000, Jiang Wu wrote:
> Can someone verify that the following scenario will cause a core dump on
> Solaris 2.7?
>
> Setup: Solaris 2.7, Tcl 8.2.3, TclBlend 1.2.6, JDK 1.2.2
> Steps: Start 'jtclsh' and type the following commands
>
> package require java
> catch {set x [exec whoami]}
> java::load -classpath foo bar
>
>
>
> In JDK 1.2.2, the JVM uses a signal handler to catch SIGSEGV. "package
> require java" sets up this signal handler in the process. However, after
> "exec whoami", the parent process loses the signal handler. I put debug
> printf in the code "TclpCreateProcess(...)" in "tclUnixPipe.c" file. It
> seems that after the "vfork()" call, only the child process is retaining the
> signal handler. The parent process no longer has the signal handler.
>
> // signal handler OK
> pid = vfork();
>
> // signal handler OK in child process
> // signal handler reverted to SIG_DFL in the parent process
>
> Losing the signal handler causes the process to core dump later on when
> accessing certain Java code.
>
> -- Jiang Wu
>[EMAIL PROTECTED]
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Is there a better way?
Hi Lee.
It sounds like you have uncovered a speed problem in the subst command
implementation. There is nothing at all wrong with implementing your
own commands to replace "standard" commands, but you might want to
think about optimizing the subst command before you give up and replace
it.
There are two main reasons why improving the subst implementation
might be a better way to go. First, your improvements would be
available to everyone. Second, you would not need to maintain
your special "hacked" version of subst. Coding for
"the good of everyone" is a nice concept, but I have found that
there is a much more selfish reason you should look at fixing the
subst command before you go off an implement your own. I have found
that one of the biggest "costs" of upgrading a project that depends
on an external library (like Java or Tcl/Tk itself) is updating the
"local hacks" that you made to the core. When the core changes, you
end up going back and fixing up your local hacks. This can take a
VERY long time! Much longer than it might have taken to just improve
the core in the first place.
For example, you mentioned that there were some string concatenations
in the source that could be replaced by StringBuffer.append() calls.
I took a quick look at the source, and you are right, there is some
code in there that is just plain wrong (Don't blame me, I didn't do it).
There is some code like this:
String result = "";
result = result + vres.value.toString();
This kind of thing is really wasteful and can be made much faster
using a StringBuffer as you suggest. If you want to fix the subst
implementation so that it uses a StringBuffer, create a patch
and post it to the list and I will check it into the CVS.
You will want to get the CVS version to make the patch.
You also mentioned "Since Interpret.evalFlags and Parser are only package
accessible". What were you trying to do that Jacl did not allow? Can
you do the same thing in the C version of Tcl? If so, how?
later
Mo DeJong
Red Hat Inc.
On Thu, 23 Mar 2000, Lee Hall wrote:
> It seems like what I had to do to implement a new version of the "subst"
> command was a hack. The new command is "weld". I would have preferred to
> stick with standard JACL on this, but the results of the "time" command
> justified the replacement:
>
> weld {242700 microseconds per iteration}
> subst {459500 microseconds per iteration}
> weld {243800 microseconds per iteration}
> subst {456400 microseconds per iteration}
> weld {242600 microseconds per iteration}
> subst {454600 microseconds per iteration}
>
> Each timing ran in sequence to eliminate any variances due to
> initialization. The input for each iterated 10 times, and the original
> script started as 2810 "source" bytes and resulted as 6369 bytes after
> substitutions. The "weld" command is identical to subst in function, but
> eliminates the options and uses StringBuffer.append() to accumulate the
> result instead of String concatenation.
>
> At first, I thought I could just write the new command in my own package.
> Since Interpret.evalFlags and Parser are only package accessible, I then
> thought that I could just relocate the command in tcl.lang and make WeldCmd
> public so that I could use Interp.createCommand to load it. This caused
> IllegalAccessException at runtime.
>
> I didn't want to build a new, non-standard JACL that included the command,
> so I changed the access back to package and tried using
> Extension.loadOnDemand() - which worked.
>
> Is this technique correct, or am I trying to do something that violates the
> design philosophy? Recommendations would be appreciated.
>
> - Lee
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] TclBlend Core Dump
Ok, I will put a "package require Tcl 8.3" check into the configure.in and pkgIndex.tcl files so that Tcl Blend 1.3 will only work on Tcl 8.3 and newer systems. If anyone wants to run Tcl Blend on older 8.0 -> 8.2 versions of Tcl they can use the stable release. Mo Dejong Red Hat Inc. On Thu, 23 Mar 2000, Jiang Wu wrote: > Tcl 8.2.3 uses "vfork" instead of "fork". Apparently, "vfork" produces a > child process that shares the parent process's signal handlers. Then the > Tcl code calls "RestoreSignals()" in the child process to make the signal > handlers back to defaults. But this also changed the parent process's > signal handlers. > > It looks like in Tcl 8.3, they stopped using "vfork" and just use a "fork", > which doesn't have this problem. Here is the part of the change log from > 8.3 mentioning this particular problem: > > * unix/configure.in: > * unix/tcl.m4: > * unix/tclUnixPipe.c: removed checking for compatible vfork > function and use of the vfork function. Modern VM systems rarely > suffer any performance degradation when fork is used, and it > solves multiple problems with vfork. Users that still want vfork > can add -Dfork=vfork to the compile flags. [Bug: 942 2228 1312] > > So to use Tcl 8.2.3 with JDK 1.2.2, we need to patch the unix/tclUnixPipe.c > to use "fork" instead of "vfork". After making this fix, everything worked > as expected. > > -- Jiang Wu >[EMAIL PROTECTED] 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] TclBlend Core Dump
The 1.2 "stable" version of Tcl Blend was tested with Tcl 8.0, Tcl 8.1, and Tcl 8.2. It should also work with Tcl 8.3 but more testing is needed. The 1.3 "development" version of Tcl Blend will only work with Tcl 8.3 and newer versions of Tcl. The 1.2 version of Tcl Blend is frozen, no new features will be added. Only bug fixes will be applied, and they need to fix really critical bugs to go in. The most recent 1.2 release was 1.2.5, but there will be an updated 1.2.6 release real soon now. New Tcl Blend patches will be applied to the 1.3 version in the CVS. You should not need to worry about any old Tcl 8.0 stuff. In fact, if you want to strip out all the Tcl 8.0 version checking code and submit a patch for that I would be happy to add it to the CVS. I could do it when I get some free time, but if you do it and post a patch it will get done much more quickly. Mo Dejong Red Hat Inc. On Thu, 23 Mar 2000, Jiang Wu wrote: > Is TclBlend 1.2.x supposed to also work with Tcl 8.0? There are seem to be > some stuff in the source code that tries to make TclBlend compatible with > Tcl 8.0. If I want to make a patch to TclBlend 1.2.x, do I need to worry > about Tcl 8.0? For example, I'd like to add support to do > "Interp.evalFile()". > > Having TclBlend 1.3 require Tcl 8.3 will simplify matters. > > -- Jiang Wu >[EMAIL PROTECTED] > > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 23, 2000 2:54 PM > To: Jiang Wu > Cc: [EMAIL PROTECTED] > Subject: RE: [Tcl Java] Re: [Tcl Java] TclBlend Core Dump > > > Ok, I will put a "package require Tcl 8.3" check into the configure.in > and pkgIndex.tcl files so that Tcl Blend 1.3 will only work on Tcl 8.3 > and newer systems. > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Jacl and Servlets
I have not heard of anyone doing that before, but there is no reason it should not work. Jacl and Tcl Blend are generic interfaces to Java, so you do not need "wrapper" code. Just about anything you can do in Java, can be done in TclJava with ease. A good way to learn how TclJava works is to take some Java code you already wrote and convert it over to TclJava code. If you need any help figuring out how to convert Java code to TclJava code, feel free to post a small code fragment to the list. Here is a little TclJava code fragment to get you started. package require java set s [java::new StringBuffer] $s append "Hello " $s append "there " $s append "Bob." # This will print "Hello there Bob." puts [$s toString] Mo Dejong Red Hat Inc. On Wed, 29 Mar 2000, Asim Jalis wrote: > Has anyone used Jacl to write Java servlet code? How > well does this work? Any experiences or pointers or URL > references? > > Asim > > > 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 PROTECTED] > with the word UNSUBSCRIBE as the subject. > To send to the list, send email to '[EMAIL PROTECTED]'. > An archive is available at http://www.mail-archive.com/tcljava@scriptics.com > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Jacl and Servlets
On Wed, 29 Mar 2000, Asim Jalis wrote:
> Asim Jalis wrote:
>
> > Has anyone used Jacl to write Java servlet code? How
> > well does this work? Any experiences or pointers or URL
> > references?
>
> Mo DeJong wrote:
>
> > I have not heard of anyone doing that before, but there is no reason
> > it should not work. Jacl and Tcl Blend are generic interfaces to
> > Java, so you do not need "wrapper" code. Just about anything you can
> > do in Java, can be done in TclJava with ease. A good way to learn
> > how TclJava works is to take some Java code you already wrote and
> > convert it over to TclJava code. If you need any help figuring out
> > how to convert Java code to TclJava code, feel free to post a small
> > code fragment to the list.
>
> I am appending a simple example servlet:
>
> --CUT--
> import java.io.*;
> import javax.servlet.*;
> import javax.servlet.http.*;
>
> public class Hello extends HttpServlet {
> public void doGet (HttpServletRequest request, HttpServletResponse response
> ) throws ServletException, IOException {
> PrintWriter out;
> response.setContentType("text/html");
> out = response.getWriter();
> out.println("Hello out.println("bgcolor=\"#FF\"> Hello World ");
> out.close();
> }
> }
> --CUT--
>
> Notice I have to extend HttpServlet. Based on the TclJava man-page
> (correct me if I am missing something) it does not seem to be possible
> to define or extend a Java class within TclJava.
>
> Is there a way to do this? How? Could you re-write this bit of code in
> TclJava? Or is there some way of organizing the code so that the
> servlet code (the stuff inside doGet) can call Tcl functions which I
> define somewhere else using Tcl language constructs?
>
> Thanks for your help.
>
>
> Asim
Well, yes extending a Java class is one of the things you can not
do with TclJava. For one thing, there is no concept of a "class"
in Tcl. Incr Tcl supports classes but plain Tcl does not. A very
cool project would be to provide a generic interface so that Incr Tcl
classes could extend Java classes. Another cool project would be
to port Incr Tcl over to Jacl (Jacl supports namespaces so it should
not be all that hard).
At any rate, here is a quick rundown of "most" of the things you
would need to do to get this code converted.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
Would become:
java::import -package java.io ...
java::import -package javax.servlet ...
java::import -package javax.servlet.http ...
The catch here is that you would need to replace ... with the names
of the classes you actually use. There are a couple of reasons for this.
First, it is not possible to query the names of all the classes in
a package using the Java reflection API (yeah, I know that sucks).
Second, it is actually better to only list the classes you use
because you are less likely to have a name clash later on as
the contents of packages are changed.
As for the doGet you could define a Tcl proc like so:
proc doGet { request response } {
$response setContentType "text/html"
set out [$response getWriter]
$out println "Hello Hello World "
$out close
}
Ok, so now you would just need to write a "wrapper" (I know, I know
I said you would not need to write a wrapper) for the HttpServlet
class.
import tcl.lang.Interp;
public class HttpServlet_TclWrapper {
Interp interp;
public HttpServlet_TclWrapper(Interp interp) {
this.interp = interp;
}
public void doGet (HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
// eval() the "doGet" Tcl proc. ( I will get back to this in a sec )
}
}
>From your Tcl code you could load up an instance of this class and
tell it to use the interp like so.
set serv [java::new HttpServlet_TclWrapper [java::getinterp]]
I assume you would also need to do something else to "register" it
with a web server.
Now the only bit left is to call Interp.eval() when you need
to process the doGet method. This is tricky because you need
to make sure that your eval() call is thread safe so that
the interp wont get hosed up. The way you do this is to use the
Notifier to add and event to the event queue.
Here is a quick cut and paste from a old paper I
wrote about Tcl Blend and Jacl that covers this.
(http://www.cs.umn.edu/~dejong/tcl/paper.html).
You would want to create an "event wrapper" for your
HttpServlet_TclWrapper class like this.
// File EventProcessor.java
import tcl.lang.ReflectObject;
import tcl.lang.Interp;
...
class EventProcessor
[Tcl Java] RE: [Tcl Java] New 1.3 version is in the CVS
The new regexp impl is already included in the CVS. I would be willing to bet that if you blow away your old checkout and start over, the new regexp classes will show up. CVS is a little funky about grabbing new files, you can also add the -d option to an update to get the same effect. You should get these files. % find tcljava/ | grep regexp tcljava/src/jacl/sunlabs/brazil/util/regexp/Regexp.java tcljava/src/jacl/sunlabs/brazil/util/regexp/Regsub.java Mo Dejong Red Hat Inc. On Thu, 30 Mar 2000, Thomas McKay wrote: > I just did a 'cvs checkout tcljava' and it fails to build. The > jacl/tcl/regex dir is empty(?). Is there a new regular expression package I > should be picking up somewhere? 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] New 1.3 version is in the CVS
On Thu, 30 Mar 2000, Thomas McKay wrote: > I do have the files mentioned (I did a clean checkout). Perhaps the > win/makefile.vc is old? That's where oro.jar is being referenced. Right, the makefile.vc is out of date. I am not really interested in maintaining the makefile.vc file for the 1.3 tree. The plan is to switch to a configure/Makefile based build for both unix and windows, but I have not yet finished fixing up build process for the 1.3.0 release. I am also waiting for the new "net release" of cygwin before checking in these changes. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Cool IBM BSF article (includes Jacl)
I just ran across this article. It's nice read. http://javaworld.com/javaworld/jw-03-2000/jw-03-beans.html 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Jacl Shell in TclBlend
You might want to do a quick "cvs update" because I just updated some of the "cruft" that had been sitting in the Shell.java class for some time. Oh wait, I take that back. I checked the "user" visible CVS at scriptics and last nights changes are not in there yet (you will have to wait until tommorow). I do not really think it is a good idea to reimplement the IO stuff from Jacl in Tcl Blend. Much of the Jacl IO stuff in the Shell class is just a bunch of ugly hacks that are needed because the Java IO libs do not support non blocking IO. If you really want to make the Shell class work in both Jacl and Tcl Blend, it might be better to abstract out the bits that do the IO from the bits that send the event to the interp. The bits that send to values to the interp is what you want to show off anyway. Mo Dejong Red Hat Inc. On Mon, 3 Apr 2000, Jiang Wu wrote: > I am trying to adapt the Jacl Shell to work in TclBlend. The changes > involve moving the command line processing logic from the ConsoleThread's > run() method into the ConsoleEvent class's processEvent() method so that > only the interpreter thread is calling any Interp class's methods. > > The Jacl Shell, tcl.lang.Shell, also uses the Channel, StdChannel, and TclIO > classes in Jacl to print characters to the screen. TclBlend does not have > those two classes. Now, I see three options to make this work: > > 1. add Channel, StdChannel, TclIO to TclBlend > 2. use the same Shell for both Jacl and TclBlend, make the Shell use > java.lang.System.out and java.lang.System.err instead of tcl.lang.StdChannel > 3. TclBlend use a separate Shell from Jacl, TclBlend Shell uses System.out, > Jacl Shell uses StdChannel. > > I don't like option 1 because those Jacl specific classes don't do anything > other than supporting the Shell in TclBlend. What do people think? Any > preferences? > > -- Jiang Wu >[EMAIL PROTECTED] > > > > 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 PROTECTED] > with the word UNSUBSCRIBE as the subject. > To send to the list, send email to '[EMAIL PROTECTED]'. > An archive is available at http://www.mail-archive.com/tcljava@scriptics.com > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Compilation problem with tclBlend1.2.5
We do not provide much support for pre-compiled binaries
for a number of reasons. We do give out Windows binaries,
but that is just because windows dev tools are not free
and they kind of suck (IMHO). It seems like binaries
would make things easier, but in fact the opposite is
true.
At any rate, the problems you are running into are
caused by one of two things.
1: The JDK you installed came with .h files that are
hosed in some way. The compiler errors you see seem
to indicate that jlong (A JNI type) is not defined
in the Sun .h files.
2: The JDK might be OK but Tcl Blend is failing to find
the right .h files to include.
It is much more likely to be #1, but I would not rule
#2 out if I were you. Sun has a history of wildly
changing the layout of files in the JDK from release
to release and platform to platform. It really is a
nightmare keeping it all working.
If I were you I would poke around in the
/usr/java1.2/include/jni.h file and see if you
can find out why it will not compile. Try to
create a simple program like this.
/* file jnitest.c */
#include
int main() {}
gcc -c -I/usr/java1.2/include -I/usr/java1.2/include/solaris jnitest.c
What would really help is if you could add a configure.in test
to see if you can compile the above program like so.
AC_TRY_COMPILE([#include ], , , 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 been trying to install tclBlend on an intel m/c running solaris.
> i have already
> installed jdk1.2 and tcl8.2.1 on my machine. i had to download the
> source code
> for tclBlend1.2.5 as binaries are not available for intel platform.
> otherwise installing
> binaries would have been a lot easier. anyways i followed the
> instructions as
> described in /unix subdirectory.
> first i ran the configure script. the exect syntax i used was :
>
> ./configure --with-tcl=/export/home/users/bthakur/tcl/tcl8.2.3
> --with-jdk=/usr/java1.2
> --enable-gcc --prefix=/export/home/users/bthakur/local/tclblend
> --exec-prefix=/export/
> home/users/bthakur/local/tclblend
>
> this worked fine. then i ran the make utility
>
> make
>
> this failed with an error ==> make: Fatal error: Command failed for
> target `javaCmd.o'.
> the log generated was :
> rm -rf /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava
> rm -f tcljava.jar
> #
> # Making tcljava.build
> #
> mkdir -p /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava
> cd /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/../src/tcljava ;\
>
>CLASSPATH=/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava:/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/../src/empty/empty.jar:/usr/java1.2/jre/lib/rt.jar
> \
> /usr/java1.2/bin/javac -g \
> -d /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava \
> tcl/lang/reflect/*.java
> cd /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/../src/tcljava ;\
>
>CLASSPATH=/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava:/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/../src/empty/empty.jar:/usr/java1.2/jre/lib/rt.jar
> \
> /usr/java1.2/bin/javac -g \
> -d /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava \
> tcl/lang/*.java
> cp -fr
> /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/../src/tcljava/tcl/lang/library
> \
> /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava/tcl/lang/library
>
> cd /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava ;\
> CLASSPATH=/usr/java1.2/jre/lib/rt.jar \
> /usr/java1.2/bin/jar -cf0M
> /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava.jar tcl
> rm -f *.o libtclblend.so custom javaNative.h
> rm -rf /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tclblend
> rm -f tclblend.jar
> rm -f pkgIndex.tcl
> #
> # Making tclblend.build
> #
> mkdir -p /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tclblend
> cd /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/../src/tclblend ;\
>
>CLASSPATH=/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava:/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tclblend:/usr/java1.2/jre/lib/rt.jar
> \
> /usr/java1.2/bin/javac -g \
> -d /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tclblend
> tcl/lang/*.java
> cd /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tclblend ;\
> CLASSPATH=/usr/java1.2/jre/lib/rt.jar \
> /usr/java1.2/bin/jar -cf0M
> /export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tclblend.jar tcl
>
>CLASSPATH=/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tcljava:/export/home/users/bthakur/tcl/tclBlend1.2.5/unix/tclblend:/usr/java1.2/jre/lib/rt.jar
> \
> /usr/java1.2/bin/javah -jni -o javaNative.h tcl.lang.CObject
> tcl.lang.IdleHandler tcl.lang.Interp tcl.lang.Notifier
> t
[Tcl Java] Should Tcl Blend 1.2.6 use Tcl 8.2 or Tcl 8.3?
Hi all. I am looking over my todo list for the next "stable" release of Tcl Blend (1.2.6) and I am wondering if we should move up to Tcl 8.3 for the pre-compiled Windows binaries. I am NOT saying that the source code for the 1.2 version would be changed to only support 8.3, just the pre-compiled Tcl Blend binaries. The source would still build with Tcl 8.0, 8.1, 8.2, and 8.3. As I am sure many of you know, Tcl Blend has a binary dep for a particular version of the JDK and a particular version of Tcl (stubs do not work in this case). 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Help, I can't find tcl.lang.JavaTestExtension (fwd)
If you want to run the regression tests you would typically run "make test" in the build directory. Under windows you need to run "nmake -f makefile.vc test". That will build the .class files like tcl.lang.JavaTestExtension and source each of the regression tests for you. If you want to run them by hand type "make test.build ; make shell" (use the nmake -f junk under windows). The test .class files will be created in a sub directory of the build dir called "tests". > I downloaded the Jacl source so that I could use the tests in > that package as a template. However, when I source any of the > tests, the following error is displayed: > > Unable to load tcl.lang.JavaTestExtension. Some tests may fail. > load "tcl.lang.JavaTestExtension" failed: > java.lang.SecurityException: > Java loader failed to load the class and the Tcl Java loader > is not permitted to load classes in the tcl or java package > at runtime, check your CLASSPATH. I am guessing this is because you loaded the tclblend.dll that was compiled for Tcl 8.2 into Tcl 8.3. > 2. In addition to using Jacl, I would _dearly_ love to get a > handle on TclBlend. However, I am unable to figure out the > proper configuration to get it running on NT4.0. If anybody > can detail the PATH OF LEAST RESISTANCE with respect to > installing Java, TCL, and TclBlend (in ANY directory), I will > be eternally grateful. > > If it is of any use, here is the output when I try to start > TclBlend. > > C:\Tcl\bin>tclsh83 > % package require java later 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Should Tcl Blend 1.2.6 use Tcl 8.2 or Tcl 8.3?
On Tue, 4 Apr 2000, Scott Redman wrote: I thought the other problem with stubs was that one tclblend.dll could not be loaded into both a JDK 1.1 and a JDK 1.2 JVM. > It's too bad that we can't make TclBlend stubs enabled, > that would fix this. The problem with stubs is that > the TclBlend DLL can also be used as a shell, and shells > cannot use stubs (unless they located and load the > Tcl DLL). I keep hearing stuff about this "fix" but I have yet to see a patch on the list. Perhaps it is still in development. > Since Jiang Wu seems to have fixed this feature > (using TclBlend as a shell from Java), then we shouldn't > break it with stubs. Unless, of course, someone writes > the code to located and load the Tcl DLL. Maybe in 1.3 > we can fix this by splitting up the DLL into separate > pieces? Nope, no "feature changes" are going into 1.2.6. I still have some error message improvements that I want to add before 1.2.6 will go out but there are no features that need to be changed (IMHO). A compiler switch for stubs might be a good thing to add to 1.3. > Maybe we should add a --disable-tclstubs option > to the TEA configure script so that Jiang can turn off > stubs (and we add them in for 1.2.6). The switch to > stubs should be pretty easy, I had it working fine in > an early 1.2.5 until I removed it. Anyone in their right mind would compile Tcl Blend from the source, it is just those poor windows folks with no compilers that I am worried about. I just don't see any reason to keep using Tcl 8.2 as the default for windows folks. later Mo > As far as 8.2 vs. 8.3 is concerned, I'm not too concerned > either way. We are using 8.3 internally for > Scriptics Connect 2.0 and probably won't need support > for 8.2 anymore. However, we build TclBlend every night, > so we're not going to be using the prebuilt binaries. > The real question is what version of Tcl everyone else > is using. Jeff would probably suggest switching to > 8.3 for the pre-built binaries and let anyone using > 8.2 either rebuild TclBlend or download 1.2.5. > > -- Scott 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Should Tcl Blend 1.2.6 use Tcl 8.2 or Tcl 8.3?
> > Nope, no "feature changes" are going into 1.2.6. I still have some > > error message improvements that I want to add before 1.2.6 > > will go out but there are no features that need to be changed (IMHO). > > A compiler switch for stubs might be a good thing to add to 1.3. It might be easy, but it is a feature change and it has to go in the 1.3 version. I hate to be the bad guy but that it the whole point of "stable" vs "development" releases (something Scriptics should really be doing by the way). > If we fix stubs in 1.2.5, we can easily (and should) add the > configure switch. > > > Anyone in their right mind would compile Tcl Blend from > > the source, it is just those poor windows folks with no > > compilers that I am worried about. I just don't see any > > reason to keep using Tcl 8.2 as the default for windows > > folks. There is a lot more, check out the changes.txt file on the branch-1_2 branch in the CVS for all the details. The worst of it is a really nasty bug in the ReflectObject table that causes Jacl and Tcl Blend to just stop working. It sounds like a JVM bug but I am not sure exactly what the cause is yet. Thomas McKay is working on creating 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 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] simple Java-Tcl callback
On Wed, 12 Apr 2000, Vince Darley wrote:
> I'm trying to have more heavy interaction between my Tcl code and Java. In
> particular I want to be able to pass in a Tcl command to the Java, and have
> it executed at certain intervals, where that command takes a Java object as
> a parameter:
>
> proc callback {javaobj} {
> puts stdout [java::info class $javaobj]
> }
>
>
> // TclCallback.java
>
>
>
> public class TclCallback {
> public TclCallback(String command, Interp interp) {
> this.command = command;
> this.interp = interp;
> }
> String command;
> Interp interp;
>
> public void call(MyJavaObject mjo) {
> try {
> interp.eval(command + " " + mjo, 0);
> } catch (TclException te) {
> Debug.bug("Tcl exception thrown: " +te);
> }
> }
> }
>
> However the callback proc doesn't receive a java-object, but rather a string
> looking like:
> MyJavaObject@d531bf4b
>
> So, I guess my 'interp.eval' statement is wrong. What should it look like?
>
> thanks,
>
> Vince.
You have two problems there. You can not just call interp.eval()
from random Java code because it is not thread safe (this is
by design). To make a thread safe call you need to create another
"event" object, add it to the interps event queue, and then
let it get done "later". Like so:
(from src/jacl/tcl/lang/Shell.java)
ConsoleEvent evt = new ConsoleEvent(interp, sbuf.toString());
interp.getNotifier().queueEvent(evt, TCL.QUEUE_TAIL);
evt.sync();
(from src/jacl/tcl/lang/ConsoleEvent.java)
public int
processEvent(
int flags) // Same as flags passed to Notifier.doOneEvent.
{
try {
interp.eval(script, 0);
} catch (TclException e) {
evalException = e;
} finally {
evalResult = interp.getResult();
evalResult.preserve();
}
return 1;
}
I will be the first to admit that this is kind of ugly.
I am looking to redesign this part of the interface in the 1.3
tree.
You other problem is that you need to create a "reflect object"
and pass that to your Tcl code.
MyJavaObject mjo = ...
ReflectObject ro = ReflectObject.newInstance(interp, MyJavaObject.class,
mjo);
The reflect object creating also needs to be done in the event
callback, not in the thread unsafe Java callback.
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Converting Interp.getResult TclObject to Java
On Fri, 14 Apr 2000, Paul Eng wrote:
> I am looking into using Jacl to call Tcl scripts. I can call interp.eval()
> and then interp.getResult() to get the return value, but the return value is
> a TclObject. What I would like to do is convert this TclObject result into
> it's appropriate java object, so that if it's a reflected object, I would
> get the java object, if it's a TclString, I would get java.lang.String, etc.
>
> I found the convertTclObject() method in JavaInvoke which looks like what I
> want, but the method is not public. Is there a way I can do this or am I
> missing something?
>
> Thanks,
> Paul Eng
The "trick" here is that Tcl objects have "internal representations",
that could be a float, a Java object, or whatever. Because a Tcl
object is a "wrapper" around an InternalRep, you need to "unwrap"
the TclObject in you Java code if you want to do something with it.
Lets say you invoke a Tcl proc that does some Java related stuff,
it sets the interp result to a ReflectObject, a Tcl "wrapper" for
a Java object.
interp.eval("some_java_func");
Now you can "unwrap" the Java object like so.
TclObject result = interp.getResult();
Object jobj = ReflectObject.get(interp, result);
If you want to know what the Java Class of the reflected
Java object is, you can find that out like this.
Class jcl = ReflectObject.getClass(interp, result);
(WARNING: YOU MUST GET THE REFLECTED CLASS TYPE LIKE THIS,
DO NOT CALL THE jobj.getClass() METHOD TO GET THE
REFLECTED CLASS TYPE, THEY ARE NOT THE SAME THINGS).
To get the "string rep" of a TclObject just call the
toString() method on the TclObject.
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]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] Converting Interp.getResult TclObjectto Java
You can test the "internal type" you get as a result of the eval().
TclObject tobj;
// Do a thread safe Tcl eval and set tobj to the interp result.
InternalRep rep = tobj.getInternalRep();
if (rep instanceof TclString) {
String s = rep.toString();
} else if (rep instanceof TclInteger) {
int i = TclInteger.get(interp, rep);
} else if (rep instanceof TclDouble) {
double d = TclDouble.get(interp, rep);
} else if (rep instanceof ReflectObject) {
Object o = ReflectObject.get(interp, rep);
Class cl = ReflectObject.getClass(interp, rep);
}
I hope that clears things up.
Mo Dejong
Red Hat Inc.
On Wed, 19 Apr 2000, Paul Eng wrote:
> Mo,
>
> Thanks for the reply.
>
> Suppose I want to use Jacl to process users' scripts so that I have no idea
> what the return type is going to be. I understand how I could check to see
> if the return object is a ReflectObject and how I could unwrap it to get the
> Java object if it was. But, let's say a proc simply has "return 1". This
> comes back from interp.getResult() as a TclObject, but what I really want is
> a java.lang.Integer. Can I somehow convert it or is my only choice to get
> it as a java.lang.String?
>
> I'm new to Tcl/Jacl, so forgive me if this doesn't make sense.
>
> Thanks,
> Paul Eng
>
>
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 14, 2000 3:29 PM
> To: Paul Eng
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Tcl Java] Converting Interp.getResult TclObject to Java
>
>
> On Fri, 14 Apr 2000, Paul Eng wrote:
>
> > I am looking into using Jacl to call Tcl scripts. I can call
> interp.eval()
> > and then interp.getResult() to get the return value, but the return value
> is
> > a TclObject. What I would like to do is convert this TclObject result
> into
> > it's appropriate java object, so that if it's a reflected object, I would
> > get the java object, if it's a TclString, I would get java.lang.String,
> etc.
> >
> > I found the convertTclObject() method in JavaInvoke which looks like what
> I
> > want, but the method is not public. Is there a way I can do this or am I
> > missing something?
> >
> > Thanks,
> > Paul Eng
>
> The "trick" here is that Tcl objects have "internal representations",
> that could be a float, a Java object, or whatever. Because a Tcl
> object is a "wrapper" around an InternalRep, you need to "unwrap"
> the TclObject in you Java code if you want to do something with it.
> Lets say you invoke a Tcl proc that does some Java related stuff,
> it sets the interp result to a ReflectObject, a Tcl "wrapper" for
> a Java object.
>
> interp.eval("some_java_func");
>
> Now you can "unwrap" the Java object like so.
>
> TclObject result = interp.getResult();
>
> Object jobj = ReflectObject.get(interp, result);
>
> If you want to know what the Java Class of the reflected
> Java object is, you can find that out like this.
>
> Class jcl = ReflectObject.getClass(interp, result);
>
> (WARNING: YOU MUST GET THE REFLECTED CLASS TYPE LIKE THIS,
> DO NOT CALL THE jobj.getClass() METHOD TO GET THE
> REFLECTED CLASS TYPE, THEY ARE NOT THE SAME THINGS).
>
> To get the "string rep" of a TclObject just call the
> toString() method on the TclObject.
>
> 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]
> with the word SUBSCRIBE as the subject.
> To unsubscribe: send mail to [EMAIL PROTECTED]
> with the word UNSUBSCRIBE as the subject.
> To send to the list, send email to '[EMAIL PROTECTED]'.
> An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
>
>
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Any objections to removing tcljava/configure for 1.2.6?
The 1.2 "stable" release has a TEA version of the configure script that is used to build Tcl Blend. This is provided with the Tcl Blend distro. Some folks have commented that they have been confused by the fact that there are two configure scripts in the tclblend dist. One is at the top level and the other is called unix/configure. Users really should be running the unix/configure script unless they want to build a TEA version of Tcl Blend (which should work under windows too, but this is untested). I really want to steer people away from the toplevel ./configure script because it is not as well tested as the unix/configure verison. So I suggest that the dist not include the toplevel configure script, it will still include the unix/configure script. That way if folks "really" want to use the TEA verison they will have to take the extra step of running autoconf 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. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] TclJava 1.2.6 is ready, please download and test.
I have just posted the source code and precompiled windows binaries for the final 1.2 release of Jacl and Tcl Blend. Please test these new releases before they go up on the official TclJava download page at Scriptics (they will "go live" on the Scriptics site in about a week). This is going to be the last release made on the 1.2 "stable" tree, so if you are having any problems with Jacl or Tcl Blend you need to report them NOW! There do not seem to be any actual bugs in the bug database for Jacl or TclBlend so I can only assume that folks are happy with the releases. If not, feel free to join the tcljava mailing list and voice your feelings. This 1.2.6 release contains no new features, only bug fixes for the 1.2.5 release are included. If you are looking for new features you need the 1.3 "development" tree in the CVS. You can download the files by going to the following URL. http://www.cs.umn.edu/~dejong/tcl/tcljava/prerelease.html 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: Using JACL in servlets
On Tue, 25 Apr 2000, Jeff Sturm wrote:
> Lee T Hall wrote:
> > WELD is an acronym for "Web Enabled Logic Documents" and performs
> > server parsing of HTML with JACL.
> [...]
>
> Very nice article you've written on your rationale for WELD. I've had
> many of the same thoughts about Web programming that you expressed so
> well.
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. A new paper on
the subject of multi-threaded interaction with a TclJava interp
is being authored by Jiang Wu <[EMAIL PROTECTED]>. I am sure
he will publish the URL on this list when he thinks it is ready
(If you want to help out, I am sure Jiang could always use another
pair of eyes to help review the paper).
> I have a few concerns about the WELD implementation. First, binding an
> interpreter to a servlet session doesn't guarantee that it won't be
> invoked concurrently, and JACL interpreters are not thread-safe
> (right?).
>
> Second, the TemplateCache class does not preserve newlines when it reads
> a file. The newlines are important to preserving the integrity of a
> document. Some tags (i.e. ) will not work correctly otherwise.
I was under the impression that Lee was running into some slowdowns
because of the lame way the subst command was implemented in Jacl.
This problem is easy to fix and I thought Lee said he was going to
send in some patches, but 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 subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: Thread safety (was: Using JACL in servlets)
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 safety" in TclJava. In fact, Java itself
never got "automatic thread safety" completely right. The AWT was
a great example of how not to write a GUI (with lots of "automatic"
thread locking).
> You could say the same about most Java code. But I agree the term
> "thread safe" is not very precise. I was referring to automatic thread
> safety... which, depending on the project, there may be good reasons to
> shun for performance reasons (Swing is a good example).
It does. The docs say that ALL methods that interact with an interp
instance and thread unsafe. For this reason, all interp interaction
needs to be done from the Tcl event queue thread. Here is a quick
example that call the "unsafe" eval() method using the Notifier
to queue up a "thread safe" event.
import tcl.lang.*;
public class EventExample {
// Interact with the Tcl interp (must be called from event loop thread)
void setXto1 (Interp interp)
throws TclException
{
interp.eval("set x 1");
}
// This method can be safely called from any thread
public void SAFE_setXto1(final Interp interp) {
TclEvent event = new TclEvent() {
public int processEvent (int flags) {
try {
setXto1(interp);
} catch (TclException ex) {
// Do seomthing to handle the error
}
return 1;
}
};
interp.getNotifier().queueEvent(event, TCL.QUEUE_TAIL);
}
}
Note how the setXto1() method is called from the interp event
queue thread (the paper does a better job of explaining this).
> The API docs should at least specify which calls are safe to use
> concurrently and which are not.
>
> > A new paper on
> > the subject of multi-threaded interaction with a TclJava interp
> > is being authored by Jiang Wu <[EMAIL PROTECTED]>. I am sure
> > he will publish the URL on this list when he thinks it is ready
> > (If you want to help out, I am sure Jiang could always use another
> > pair of eyes to help review the paper).
Cool, shoot Jiang an email, I am sure he would welcome the help.
> Good. I'd welcome a chance to review it.
>
> --
> Jeff Sturm
> [EMAIL PROTECTED]
>
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Use of JACL in JFC Actions
Why do Java folks always create a new term for every little bit of code they write? A "JFC Action" is nothing more than a callback on an interface. You can use these in Jacl directly with the java::bind command. If you really want to see a cool way to use JFC clases with Jacl check 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 demos and pizza. Mo Dejong Red Hat Inc. On Mon, 1 May 2000, Lee Hall wrote: > There is an interesting article at > http://www.javaworld.com/jw-04-2000/jw-0414-action.html?041800txt where the > author discusses the use of the Command pattern to separate GUI design from > implementation in a manner similar to the use of JACL described at > http://www.javafoundry.com/~lhall/weld/ > > Are there any white papers describing the use of JACL in JFC Actions? The > solution suggested in the referenced article stops short of mentioning a > standard command interpreter such as JACL, in favor of reinventing the wheel > using no scripting layer. > > - Lee 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Build Process
Are you using the 1.2.6 version that I posted a couple of days ago? If not, you need to be using that. Older versions had some build problems under Windows (and this looks like the one I fixed). http://x31.deja.com/[ST_rn=ps]/getdoc.xp?AN=617772045&CONTEXT=957396257.1027145745&hitnum=0 http://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 is: > -- > tcl83.lib(tcl83.dll) : error LNK2005: _Tcl_RestoreResult already defined in > tclResult.obj > tcl83.lib(tcl83.dll) : error LNK2005: _Tcl_SaveResult already defined in > tclResult.obj > tcl83.lib(tcl83.dll) : warning LNK4006: _Tcl_RestoreResult already defined > in tclResult.obj; second definition ignored > tcl83.lib(tcl83.dll) : warning LNK4006: _Tcl_SaveResult already defined in > tclResult.obj; second definition ignored > Creating library tclblend.lib and object tclblend.exp > tclblend.dll : fatal error LNK1169: one or more multiply defined symbols found > -- > > Any ideas as to how to resolve this issue? I also tried removing the old > version of tclResult.c from tcl's generic source folder. Had no luck > there...any ideas? > > Thanks > -sendur 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Build Process
The build was broken. It is a really long story that I am sure you do not want to hear (and I do not really want to rehash it). It was the old "too many cooks in the kitchen" problem. Mo Dejong Red Hat Inc. On Wed, 3 May 2000, Sendur Sellakumar wrote: > Mo, > > Thanks...that fixed the problem. > Do you remember what caused this problem? (Just curious =) ) > > Thanks > > -sendur > > At 04:25 PM 5/3/00 -0700, Mo DeJong wrote: > >Are you using the 1.2.6 version that I posted a couple of days ago? > >If not, you need to be using that. Older versions had some build > >problems under Windows (and this looks like the one I fixed). > > > >http://x31.deja.com/[ST_rn=ps]/getdoc.xp?AN=617772045&CONTEXT=957396257.102 > >7145745&hitnum=0 > > > >http://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 is: > > > -- > > > tcl83.lib(tcl83.dll) : error LNK2005: _Tcl_RestoreResult already > > defined in > > > tclResult.obj > > > tcl83.lib(tcl83.dll) : error LNK2005: _Tcl_SaveResult already defined in > > > tclResult.obj > > > tcl83.lib(tcl83.dll) : warning LNK4006: _Tcl_RestoreResult already defined > > > in tclResult.obj; second definition ignored > > > tcl83.lib(tcl83.dll) : warning LNK4006: _Tcl_SaveResult already defined in > > > tclResult.obj; second definition ignored > > > Creating library tclblend.lib and object tclblend.exp > > > tclblend.dll : fatal error LNK1169: one or more multiply defined > > symbols found > > > -- > > > > > > Any ideas as to how to resolve this issue? I also tried removing the old > > > version of tclResult.c from tcl's generic source folder. Had no luck > > > there...any ideas? > > > > > > Thanks > > > -sendur > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] How to initialise an ORB with TclBlend (fwd)
Sarita, you need to actually subscribe to the mailing list by sending
a "subscribe" mail to [EMAIL PROTECTED]
> Hi,
>
> I get the ambigous method signature error when I try
> to initialise an ORB thru TclBlend. Effectively
> I am doing the following in Java
>
> Porperties props = new Properties();
> props.put( "org.omg.CORBA.ORBClass", "com.sybase.CORBA.ORB")
> _orb = ORB.init( (String[]) null, props );
>
> ambiguous method signature, could not choose between {init
> java.applet.Applet java.util.Properties} {init {java.lang.String[]}
> java.util.Properties}
> while executing
> "java::call org.omg.CORBA.ORB init [java::cast java.lang.String[]
> [java::null]] $properties"
This one we can blame on Tcl. Tcl thinks that the following is legal.
% set var []
This would set the variable "var" to the empty string. (Frankly, this
seems like an error to me but I do not know how likely it would
be to get the core folks to change it).
In your case, you tried to cast to java.lang.String[], which is the
right idea except the [] gets replaced by "" so the cast was
actually to java.lang.String not java.lang.String[].
You could put an extra pair of {} around the java.lang.String[] so
the the [] would not get replaced by "", or you could use a fully
qualified method signature. You can also use the java::import
command the shorten up some of those long class names.
java::import org.omg.CORBA.ORB
java::call ORB init [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 sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Announce: Next SVTUG meeting
WHAT: Silicon Valley Tcl Users Group (SVTUG) WHERE: Cygnus, a Red Hat company SV offices 1325 Chesapeake Terrace Sunnyvale CA 94089. Folks will need to go around to the side entrance. The front door will not be open at 7:00, but if you go around to the left side 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 Jacl and Tcl Blend). This talk will cover what has been implemented over the last year and what will be done in the future. This talk will also include a demo of "Swank", the implementation of Tk written on top of Java's Swing widgets. 7:30 "An IDE that does Tcl and Itcl." Mo DeJong will present an overview of the recently GPLed Source Navigator IDE. The IDE has recently become an "Open Source" project thanks to Red Hat. We will focus on the IDE features specific to Tcl and Itcl and show you how this IDE can make a Tcl developers life a lot easier. 8:00 "Recent developments in Tcl optimization - 8.4" Jeff Hobbs will delve into recent developments that have been made to speed up Tcl that touch the most common commands of the language. 8.4 should see significant speedups for certain operations. Mo DeJong, Cygnus Solutions, A Red Hat company -- Jeffrey Hobbs The Tcl Guy jeffrey.hobbs at scriptics.com Scriptics Corp. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Tclblend and Perl
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, Suvarna Ayyagari wrote: > Hi All, > > I am running into some problems when tclblend and perl 5. I am using > Tclblend1.2.5 with tcl8.0.5 and on a solaris 2.5.1 and sometimes on solaris > 2.6. > > >From Tcl, I am calling a perl script. This perl script does a telnet to > another machine and does some sysread ans syswrite fns on a port on the > machine and returns to the tcl script. > > I have been using this script for over several years. Now when I am doing a > "package require java", I notice that when the perl script is called it > never returns and it just hangs. > > Any thoughts as to why this is happenning? > > Thanks > Suvarna 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] TclBlend and Threads
If you check the mailing list archive (link is in the scriptics Java FAQ) you will find lots of discussion and a patch that allows one to load Tcl Blend from Java. Tcl Blend is thread safe, but you need to use it correctly. See the archive for discussion. Mo Dejong Red Hat Inc. On Wed, 10 May 2000, Sendur Sellakumar wrote: > How safe is TclBlend being loaded inside NT threads? Am I right in assuming > that it is not thread safe? > > I am current spawning a Tcl Interp inside a Windows NT Thread. That > interp, as it executes tcl commands, also tries to load tclblend. But, the > whole shell locks up at the "package require java" command. > > Any ways I can get around this? Thoughts? > > Thanks > > -sendur > > > 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 PROTECTED] > with the word UNSUBSCRIBE as the subject. > To send to the list, send email to '[EMAIL PROTECTED]'. > An archive is available at http://www.mail-archive.com/tcljava@scriptics.com > > 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] TCLBlend on the Mac?
On Wed, 10 May 2000, Ulf Dittmer wrote: > Hi everyone- Well, the source code is up there so if you have a Mac and a compiler :) > I just joined this list, and am be VERY interested to see > TCLBlend on the Mac. Is someone already working on this? Not really, if the Mac JDK supports JNI then it should work like a charm. > If not, what are known issues that need to be addressed in > the Win/Unix source? I ported Jacl over to the mac way back at version 1.1, but nobody downloaded it or seemed to care so it died. > Are there any showstoppers or experiences > from previous abortive porting efforts? If you have compiled C code on that mac, that is all you should need. I think Tcl Blend will actually be easier to port to the mac because Tcl (the hard part) is already done (thanks to Jim). If you can get a Mac port of Tcl Blend up an running in the next couple of weeks I can see about putting it up on the scriptics site. > I'm versed in C, Java and (somewhat) TCL, and have CodeWarrior, > so I might just try to give it a shot myself. Any hints are welcome. later 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Linux version of the ILoveYou worm
Ok, this really has nothing to do with tcljava, but it is just so funny I had to send it to everone in my address book. Mo Dejong Red Hat Inc. >> This virus works on the honor system!! << * * If you're running a variant of unix or linux * * * * please forward this message to everyone you know * * * * and delete a bunch of your files at random. * * 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] tclBlend: pyramidpkg possible path problem ?
This problem is fixed in Tcl Blend 1.2.6 and in the CVS.
Mo Dejong
Red Hat Inc.
On Thu, 16 Mar 2000, Ian F. Graham wrote:
> Thanks for the reply. Actually I wasn't consciously trying to load tcl
> Blend, I was just trying to the demo to work. Now that you mention it, I
> realise why it cannot work (Java will not let you) but that then throw's up
> the question, how do I get the demo to work ? Following the instructions in
> the Readme doesn't really help me.
>
> I'm pretty sure I'm missing some crucial (but simple) point here - since the
> demo source (and I am trying to run it from the original source) doesn't
> contain any reference to tclblend where is the load coming from ?
>
> As to the source distribution I agree with you, if the pyramidpkg demo is
> not a TclBlend demo then it doesn't belong in the tclBlend source
> distribution.
>
> Maybe you (or someone in the list) give me some pointers on my problem. I
> have a large tcl app with an exported set of tcl commands. Some of these are
> implement in C, others are pure tcl procs (dependent on the level of access
> required by the user). What I need to do is provide an interface to this
> from Java. The first thought is JNI, but that excludes the commands written
> in Tcl, so that is where TclBlend comes in (I think). Can you confirm that
> my approach is correct and if not give me some pointers ?
>
> Thanks for the help,
>
> Ian
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 15, 2000 10:32 PM
> To: Ian F. Graham
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Tcl Java] tclBlend: pyramidpkg possible path problem ?
>
> It looks like you are trying to load Tcl Blend into an applet.
> This is not possible because Java will not let you do it.
> You should be able to run Jacl in an applet as long as you
> do not load the java package, but Tcl Blend in an applet will not work.
>
> Perhaps we should change the Makefile so that it does not include
> the pyramid demo in the tclBlend source dist.
>
> Mo DeJong
> Red Hat Inc.
>
>
> On Wed, 15 Mar 2000, Ian F. Graham wrote:
>
> > C:\ian_home\java\TclBlendSrc125\tclBlend1.2.5\demos\pyramidpkg>
> >
> > As error text goes it is not one of the most helpful I have seen, and I am
> > having great difficulty finding out what is wrong here. I'm sure it is
> some
> > sort of path/configuration problem. I have copied the tclblend.dll to the
> > local directory to ensure that it is found, but this also fails. I'm sure
> it
> > some setting which I am overlooking. Can anyone help ?
> >
> > To try and isolate the problem, I also tried out the Java Plugin with
> > Netscape and IE and got the following error (after I modified pyramid.html
> > to accommodate the plugin):
> >
> > IE:
> >
> > Java(TM) Plug-in: Version 1.2.2.px
> >
> > Using JRE version 1.2.2
> >
> > JAR cache enabled.
> > System.loadLibrary("tclblend") failed because of Unknown Throwable
> > java.security.AccessControlException: access denied
> > (java.lang.RuntimePermission loadLibrary.tclblend )
> > at
> >
> java.security.AccessControlContext.checkPermission(AccessControlContext.java
> > :195)
> > at
> > java.security.AccessController.checkPermission(AccessController.java:403)
> > at
> > java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> > at
> java.lang.SecurityManager.checkLink(SecurityManager.java:824)
> > at java.lang.Runtime.loadLibrary0(Runtime.java:464)
> > at java.lang.System.loadLibrary(System.java:778)
> > at tcl.lang.Interp.(Interp.java:32)
> > at Pyramid.init(Pyramid.java:52)
> > at sun.applet.AppletPanel.run(AppletPanel.java:333)
> > at java.lang.Thread.run(Thread.java:479)
> > java.lang.UnsatisfiedLinkError: create
> > at tcl.lang.Interp.(Interp.java:130)
> > at Pyramid.init(Pyramid.java:57)
> > at sun.applet.AppletPanel.run(AppletPanel.java:333)
> > at java.lang.Thread.run(Thread.java:479)
> >
> > ==
> >
> >
> > And Netscape:
> >
> >
> > System.loadLibrary("tclblend") failed because of Unknown Throwable
> >
> > netscape.security.AppletSecurityException: security.checklink: tclblend
> > at java.lang.Throwable.(Compiled Code)
> > at java.lang.Exception.(Compiled Code)
> > at java.lang.RuntimeException.(Compiled Code)
> > at java.lang.SecurityExc
[Tcl Java] Re: [Tcl Java] Tcl Java problems with make test
Thats odd, I just did a checkout from the anon CVS and it ran
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
script is not really supported in version 1.3. It "sort of" worked in
version 1.2 but only for Tcl Blend. One of the things on my todo list
is to replace the existing tcljava/configure script with
tcljava/unix/configure and make it build under cygwin. Then I can
remove the unix and win build systems and just have one, which will
make life a lot easier.
Mo Dejong
Red Hat Inc.
On Sun, 14 May 2000, Larry W. Virden wrote:
> Should I expect the make test suite to work if I fetch Tcl Java from
> Scriptics' Net CVS repository?
>
> Background:
>
> SPARC Solaris 2.6
> Sun Java 1.2.1_04
> Sun unbundled C compiler
> Tcl/Tk 8.3.1 from the Scriptics repository
> Tcl Java from the Scriptics repository
>
> The repository mirror is current as of 7am today.
>
>
> I configure with:
>
> $ $PWD/configure --prefix=/usr/tcl83
>
> I then do a make. Finally, I do a make test. Here's what I get-no working
> tests.
>
> cd /vol/tclsrcsol/tcl83/tcljava/src/tests/tcljava ;
>CLASSPATH="/vol/java1.2/lib/tools.jar":"/vol/java1.2/jre/lib/rt.jar":/vol/tclsrcsol/tcl83/tcljava/tests:/vol/tclsrcsol/tcl83/tcljava/tclblend.jar:/vol/tclsrcsol/tcl83/tcljava/tcljava.jar
> /vol/java1.2/bin/javac -d /vol/tclsrcsol/tcl83/tcljava/tests pkg1/*.java
>pkg2/*.java tcl/lang/*.java tests/*.java tests/invoke/*.java tests/javainfo/*.java
>tests/signature/*.java tests/exec/*.java
> /bin/sh /vol/tclsrcsol/tcl83/tcljava/mkinstalldirs
>/vol/tclsrcsol/tcl83/tcljava/tests/javaload
> mkdir /vol/tclsrcsol/tcl83/tcljava/tests/javaload
> /bin/sh /vol/tclsrcsol/tcl83/tcljava/mkinstalldirs
>/vol/tclsrcsol/tcl83/tcljava/tests/javaload/tests/javaload
> mkdir /vol/tclsrcsol/tcl83/tcljava/tests/javaload/tests
> mkdir /vol/tclsrcsol/tcl83/tcljava/tests/javaload/tests/javaload
> cd /vol/tclsrcsol/tcl83/tcljava/src/tests/tcljava ;
>CLASSPATH="/vol/java1.2/lib/tools.jar":"/vol/java1.2/jre/lib/rt.jar":/vol/tclsrcsol/tcl83/tcljava/tests:/vol/tclsrcsol/tcl83/tcljava/tclblend.jar:/vol/tclsrcsol/tcl83/tcljava/tcljava.jar
> /vol/java1.2/bin/javac -d /vol/tclsrcsol/tcl83/tcljava/tests/javaload
>javaload/*.java
> cd /vol/tclsrcsol/tcl83/tcljava/tests/javaload; \
> CLASSPATH="/vol/java1.2/lib/tools.jar":"/vol/java1.2/jre/lib/rt.jar" \
> /vol/java1.2/bin/jar -cf0M test9.jar Test9Extension.class; \
> rm Test9Extension.class
> cd /vol/tclsrcsol/tcl83/tcljava/tests/javaload; \
> CLASSPATH="/vol/java1.2/lib/tools.jar":"/vol/java1.2/jre/lib/rt.jar" \
> /vol/java1.2/bin/jar -cf0M test10.jar \
> Test10Extension.class; \
> rm Test10Extension.class
> touch /vol/tclsrcsol/tcl83/tcljava/tests/tcljava
> cd /vol/tclsrcsol/tcl83/tcljava/src/tests/tclblend ;
>CLASSPATH="/vol/java1.2/lib/tools.jar":"/vol/java1.2/jre/lib/rt.jar":/vol/tclsrcsol/tcl83/tcljava/tests:/vol/tclsrcsol/tcl83/tcljava/tclblend.jar:/vol/tclsrcsol/tcl83/tcljava/tcljava.jar
> /vol/java1.2/bin/javac -d /vol/tclsrcsol/tcl83/tcljava/tests tests/*.java
>tcl/lang/*.java
> touch /vol/tclsrcsol/tcl83/tcljava/tests/tclblend
> ( echo \
> set auto_path [concat [pwd] [set auto_path]]\; \
> cd \{"/vol/tclsrcsol/tcl83/tcljava"/tests\}\; \
> puts \"pwd is [pwd]\"\; \
> puts \"CLASSPATH is [set env\(CLASSPATH\)]\"\; \
> puts \"auto_path is [set auto_path]\"\; \
> source all\; \
> puts \"Tests done.\"\; \
> exit; ) | \
> LD_PRELOAD= \
> LD_BIND_NOW= \
>
>LD_LIBRARY_PATH=/vol/tclsrcsol/tcl83/tcljava:/vol/tclsrcsol/tcl83/tcl8.3.1/unix:/vol/java1.2/jre/lib/sparc:/lprod/cas/lib:/usr/dt/lib:/usr/openwin/lib:/usr/lib
> \
>
>PATH="/vol/tclsrcsol/tcl83/tcljava":"/vol/tclsrcsol/tcl83/tcl8.3.1/unix":"/vol/SUNWspro/bin:/ldatae/bin:/projects/sprs_lwv/sol26/bin:/projects/sprs_lwv/sol26/bin/mime:/projects/sprs_lwv/sol2/bin:/projects/sprs_lwv/bin:/projects/sprs_lwv/bin/mime:/home/lwv26/bin/D.news:/usr/perl5/bin:/projects/gnu/sparc-sun-solaris2.6/bin:/usr/tcl83/bin:/usr/tcl82/sun4/bin:/usr/tcl82/bin:/projects/xopsrc/sun4/bin:/projects/xopsrc/bin:/usr/atria/bin:/projects/intranet/bin:/projects/clearcase/bin:/vol/tclsrcsol/TclPro1.3/solaris-sparc/bin:/ldata2/teTeX/bin/sparc-sun-solaris2.6:/vol/adobe/Acrobat3/bin:/ldata/bin:/home/lwv26/bin/D.aws:/home/lwv26/bin/sol2:/home/lwv26/bin/D.frontend:/home/lwv26/bin/D.ksh:/cas/test/bin/sun4:/projects/sprs_lwv/bin/sol2:/usr/java1.2/bin:/home/lwv26/bin/sun4:/lprod/cas/bin:/usr/local/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/cas/bin/
[Tcl Java] Using an innerclass to process a thread safe Tcl event.
There has been a lot of interest in thread safety lately, so I
thought I would post a short little example that uses an
innerclass to safely add an event to the event queue.
import tcl.lang.*;
public class EventExample {
// Interact with the Tcl interp (must be called from event loop thread)
void setXto1 (Interp interp)
throws TclException
{
interp.eval("set x 1");
}
// This method can be safely called from any thread
public void SAFE_setXto1(final Interp interp) {
TclEvent event = new TclEvent() {
public int processEvent (int flags) {
try {
setXto1(interp);
} catch (TclException ex) {
// Do something to handle the error
}
return 1;
}
};
interp.getNotifier().queueEvent(event, TCL.QUEUE_TAIL);
//event.sync(); // sync will block the calling thread
// until the event has been processed
}
}
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Thread question in TclBlend
On Mon, 15 May 2000, Scott Redman wrote:
> I was reading Jiang Wu's paper on using Java and Tcl. I have
> a question for everyone:
Jiang's Wrapper Layer is a neat idea, but there are a couple of
problems with it. You can't really wrap individual Interp
calls because often you need to call other methods like
ReflectObject.get() or TclInteger.get(). Also, looking at
code like:
TclObject one = WrappedInterp.getVar("one");
TclObject two = WrappedInterp.getVar("two");
A user might expect that the value of two would be queried
right after the value for one, but that may not be true.
If getting the value of one calls some trace proc, then
it might do a bunch of stuff and put events into the event
loop before the wrapped call to get "Two" happens. What
is really needed is to wrap a series of generic API
calls in a block of code like so:
synchronized (SOMETHING) {
TclObject one = interp.getVar("one");
TclObject two = interp.getVar("two");
}
I suggested that using an inner class would be the way
to go, but that approach is still a little bit complex.
(see the current src/jacl/tcl/lang/Shell.java for an example).
> I want to create a single Tcl interp and access it from only
> one Java thread, as per Jiang's Wrapper Layer (sending events
> to the one "owner" thread). That Tcl interp will spawn
> threads in Tcl and have those interps do all of the work.
> As long as I'm using thread-enabled Tcl 8.3.1, this should
> all work fine.
Do you mean using java::* commands to access the Java objects
or just getting a Java ref to the objects in your code and
then passing those around? If you are just passing Java
object handles around in your native Java code, that would
work. If you intend to use java::* commands, it should work
but keep in mind that the java::* commands will be processed
on at a time because there is a "big global lock" that must
be grabbed before the JVM can be accessed (see JAVA_LOCK).
> Here is the problem. I want to access Java objects through
> TclBlend from each of the Tcl threads. It sounds like this
> will not work, but can someone explain to me the technical
> reason why?
You should be able to use multiple interps, they just need to
proccess events one at a time. I have not tested it, so
it is very likely that it is broken:)
> I believe this is because TclBlend doesn't
> allow Tcl interps in more than one thread (from Jiang's
> paper), or is this only when Tcl has not been built with
> threads?
Bring this up during the SVTUG tommorow night.
> I might be able to have someone (or myself) do some of the
> advance work in making this happen for tcljava 1.3. I'd
> like to make sure that the discussions happen earlier
> rather than later.
>
> -- Scott
Later
Mo DeJong
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Tcl Java problems with make test
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/configure, and win/makefile.vc is at the top of my TODO list. Having multiple ways to build will just confuse people. It should be fixed soon. > Whoops - no, I was using the top level configure. I was confused by seeing > two of them and assumed (obviously mistakenly) that the top level one would > be the one to use. later 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Tcl Java problems with make test
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, run ./tclsh and type the above package command? Mo Dejong Red Hat Inc. On Wed, 17 May 2000, Larry W. Virden wrote: > Okay, after seeing Mo's note about using the tcljava/unix configure I > attempted to use it. Here's what I am seeing: > > checking that the jar program did not corrupt the test file... it did not > checking for Tcl build in /vol/tclsrcsol/tcl83/tcl8.3.1/unix > configure: error: /vol/tclsrcsol/tcl83/tcl8.3.1/unix/tclsh is not version 8.3.1 or >newer > > I look in config.log and see: > > configure:2117: checking that the jar program did not corrupt the test file > Using CLASSPATH=/vol/java1.2/jre/lib/rt.jar:. > /vol/java1.2/bin/java Test > version conflict for package "Tcl": have 8.3, need 8.3.1 > > However, the code in the 8.3.1 directory is tcl 8.3.1. I did a > make clean and then a fresh make and get > > % puts $tcl_version > 8.3 > > even though > $ grep PATCH_LEVEL ../generic/tcl.h > #define TCL_PATCH_LEVEL "8.3.1" 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Tcl Java problems with make test
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, run ./tclsh and type
> > the above package command?
> >
> > Mo Dejong
> > Red Hat Inc.
>
> $ ./tclsh
> % package require Tcl 8.3.1
> version conflict for package "Tcl": have 8.3, need 8.3.1
> % info patchlevel
> 8.3.1
Have you ever been writing some Tcl code and you find something that
just does not work and think "I can't be the first person to run into
this"? This is a bug in Tcl, I have filed a bug report on it, but
I guess it is not going to get fixed until 8.4.
I "fixed" this problem by moving the version number in the
configure.in back to 8.3. You will need to update from the CVS
tommorow to get these changes. You could also just apply this patch
to unix/configure.in.
Index: configure.in
===
RCS file: /home/cvs/external/tcljava/unix/configure.in,v
retrieving revision 1.32
diff -u -r1.32 configure.in
--- configure.in2000/05/13 23:49:30 1.32
+++ configure.in2000/05/17 20:51:10
@@ -1329,7 +1329,7 @@
fi
echo '
-if {[[catch {package require Tcl 8.3.1} err]]} {
+if {[[catch {package require Tcl 8.3} err]]} {
puts stderr $err
exit -1
}
later
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 PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend
I have no problem with requiring that Tcl be compiled with --enable-threads in order to work with Tcl Blend. Keep in mind that this will be yet another nail in the coffin of a "pre built" binary version of Tcl Blend. Frankly, I think the 1.3 release should include no pre built binaries 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). > > -- Scott > > > -Original Message- > > From: Jiang Wu [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 16, 2000 11:59 AM > > To: 'Scott Redman' > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend > > > > > > In theory, JAVA_LOCK sounds like the right thing to do in protecting the > > notifier of a non-thread enabled Tcl interpreter. However, the > > JAVA_LOCK is > > not released while the Tcl interpreter is idling. The result is that any > > attempt to access the Tcl interpreter from any thread other than > > the "owner" > > thread causes deadlock. I don't think deadlock is the right level of > > protection. It is a bit too stringent :) > > > > It seems that we need to implement the "Calling doOneEvent from another > > thread will have no affect..." in the Java side of TclBlend regardless > > whether the underlining Tcl is thread-enabled or not. This way, > > there won't > > be any access to the Tcl interp from any thread other than the "owner" > > thread. Then there is no need for JAVA_LOCK at all, even for the > > non-threaded Tcl. > > > > What do you think? > > > > -- Jiang Wu > >[EMAIL PROTECTED] > > > > -Original Message- > > From: Scott Redman [mailto:[EMAIL PROTECTED]] > > Sent: Monday, May 15, 2000 6:45 PM > > To: [EMAIL PROTECTED] > > Subject: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend > > > > > > I think Problem 2 isn't a problem for what we're trying to > > do, but I think you're right that it's easy to fix. > > > > The JAVA_LOCK() is there to serialize calls to the Notifier. > > This is not necessary with a thread enabled Tcl library > > (--enable-threads), but is necessary for a non-thread > > enabled Tcl. > > > > The following statements are specific to Tcl 8.1+ built > > using --enable-threads: > > > > There are specific rules in threaded Tcl that we will need > > to follow. First, the thread that creates an interp (in C, > > but this should carry over to Java) owns the interp, and is > > the *only* thread that should talk to the interp. That > > thread has it's own notifier. The JAVA_LOCK() in the > > doOneEvent should go away. Calling doOneEvent from another > > thread will have no affect (the Notifier in C is stored > > in thread-local storage). The Java Notifier should be > > modeled after the C Notifier, in which there is one per > > thread. > > > > All of the C APIs are thread-safe, but you can only use > > an interp (Tcl_Interp in C) from the thread that created > > it. > > > > There are APIs at the C level to send events to other > > threads and optionally wait for the result. We should > > add that at some point. > > > > I think TclBlend creates a new TclInterp java object for > > every C interp that loads TclBlend (if not already created). > > If not, this is the way it should be. This allows any > > Tcl interp to talk to and register callbacks with the JVM. > > > > comments? > > > > -- Scott > > > > > > > > > It would be nice if the above two problems are solved for 1.3. I think > > > TclBlend is 95% complete. The last 5% is to fix the bugs that > > prevent one > > > from using multiple Tcl interpreters. I think "problem 2" is > > > easy to solve. > > > But I don't know about "problem 1" because I don't have a clear > > > idea on why > > > the global "JAVA_LOCK" mutex was used. My feeling is that the > > > global mutex > > > is not needed. Is it possible for someone at Scriptics to dig up the > > > original design doc to figure out purpose of the "JAVA_LOCK"? > > > > > > -- Jiang Wu > > >[EMAIL PROTECTED] > > > > > >
[Tcl Java] Re: [Tcl Java] TclBlend and Expect - exporting a java stream into tcl
On Thu, 18 May 2000, Peter wrote: > Hi, > > I've been using Tcl/Tk heavily for several yers, java to some extent, > and I'm Sounds like an interesting combination. I would love to read a paper about this project when you are finished. > currently investigating Expect for testing purposes. Since we will be > interfacing a bunch of simulators (separate Unix processes) and real > targets (dedicated hardware) from > the same test system as we also want to test bits and pices of java > code, > it sounds ideal to put Expect and TclBlend together (haven't tried it > yet, though). You are talking about two different things here. Expect is designed to work between processes. The Java stream you seem to be talking about would be used between two threads in the same process. > But even at this stage I forsee a problem: How do I make a stream (used > for > internal communication between two java threads) available in the tcl > environment > for Expect to listen on? Frankly, I do not understand what the "problem" is. Why don't you just split your Java process into two processes so that you can have expect interact with each of them? > As far as I understand, I really need the actaul stream in order to use > Expect. > If I do a work-around using, e.g., event generation in java, I can > implement > an Expect like behaviour within tcl. But I don't want to re-implement > Expect... > > I've tried to find similar questions in your archive, but they don't > adress > the actual exporting of a stream, thye propagate java stream output by > other means. > > Yours, > > Peter Loborg 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: Tcl Java problems with make test
On Thu, 18 May 2000, Larry W. Virden wrote: > Re: updated configure.in to get around Tcl package require bug > > Thanks Mo. I got the updated, manually re-executed the autoconf so that a new > configure is generated, and got significantly farther . Looks like you are running JDK 1.2 from Sun. These seem to be Sun bugs. There is really nothing I can do about bugs in the Sun JVM. You could report them to Sun but I doubt they will ever get fixed. You might be better off switching to a free JVM like Kaffe. Kaffe works under windows if you use cygwin, you would need to do some porting but it might be better in the long run. > Now, I have some make check problems to ask about. During the make check, > these are the only warning/error messages I see. 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 PROTECTED] with the word UNSUBSCRIBE as the subject. To send to the list, send email to '[EMAIL PROTECTED]'. An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
