http://sf.net/projects/tcljava/ is the home for [TclBlend] as well as Jacl. Jacl is an alternate implementation of [Tcl] 8.0, this time written entirely in [Java]. ---- According to this InfoWorld article[http://www.infoworld.com/article/03/06/12/HNsunscripting_1.html], Sun is thinking of introducing scripting to Java. Shouldn't they be encouraged to do this with Tcl? - ''[escargo] 12 Jun 2003'' (The linked page did not display well with IE, but did with Mozilla.) ---- See http://www.tcl.tk/man/java1.2.6/TclJava/contents.html for older online documentations. There is a mailing list at the web site which provides support for Jacl and [Tclblend] [mailto:tcljava-user@lists.sourceforge.net]. ---- As of September 2001, [Neil Madden] has what he calls a rudimentary implementation of [socket]. ---- Several Jacl-oriented stories have been published through the years, including "Extending [XML] tools with Jacl scripts" [http://www-106.ibm.com/developerworks/library/x-xjacl/?open&43,t=gr]. Also, recently mentioned on the mailing list were these articles: http://www.projectgalileo.org.uk/audela/quiveu7_en.htm (see "Tcl + Java = A match made for scripting" ), as well as http://www.javaworld.com/javaworld/jw-03-2001/jw-0323-tcl.html , http://www.javaworld.com/javaworld/jw-03-2000/jw-03-beans.html , http://www.javaworld.com/javaworld/jw-10-1999/jw-10-script.html , and http://javasim.cs.uiuc.edu/ref.script/tcljacl.htm . ---- Anyone know of any recent articles, tutorials, etc. - things dealing with Jacl 1.3.0 or newer? ---- [CL] occasionally updates a page [http://phaseit.net/claird/comp.lang.java/jacl.html] of information related to Jacl. ---- [Swank] is an interesting extension to Jacl. ---- [Neil Madden] writes, "To try out Jacl, make sure jacl.jar is in your classpath (it should be from what you say), and then open a command line and type: java tcl.lang.Shell after a second or so you should see the familiar % Tcl prompt and you can fire away. If you want to extend your Java application using Jacl, then just import tcl.lang.* and look at the docs which come with Jacl for some pointers at how to use the APIs." [LV] Neil, having little experience with Java, I got the jacl 1.3.0 tar file recently, ran configure and make, and then tried to run the command you mention. All I get is an error about the class not being found. Is there something else I need to know about to use this? [NEM] Larry, I'm not entirely sure what could be wrong here. A possibility is that jacl.jar isn't on the classpath - you need: export CLASSPATH=/path/to/jacl.jar:$CLASSPATH (on UNIX). Note that you actually put the full path to the .jar file, not just the containing directory. I think there is a script called "jaclsh" or something which sets the classpath correctly. [Vince] Where can one download a pre-compiled jacl.jar? ---- [Martin Lemburg] I'm experimenting the first time with Jacl and have following problem. I evaluate a tcl script inside the Jacl interpreter and the result is following: {"" "platform information:" {os {Windows 2000}} ...} I want to test if an object inside the list is a list or something else by this: 1 TclObject result, element; 2 TclList list, subList; 3 ReflectObject reflectObj; 4 5 result = ip.getResult(); 6 element = null; 7 list = (TclList) result.getInternalRep(); 8 subList = null; 9 reflectObj = null; 10 11 for ( int idx = 0 ; idx < list.getLength( ip, result ) ; ++idx ) 12 { 13 element = list.index( ip, result, idx ); 14 reflectObj = (ReflectObject) element.getInternalRep(); 15 16 if ( reflectObj.getClass == TclList.class ) 17 { 18 // ... use as list ... 19 } 20 else 21 { 22 // ... use as "not" list ... 23 } 24 } When casting from the internal representation of the first element of the list - here an empty string - to the ReflectObject type (in line 14) I get the exception "java.lang.ClassCastException" (detailMessage: "tcl.lang.TclString") So I experimented a bit and I tried just to get the ReflectObject of the internal representation of the interpreter result and I got the same exception "java.lang.ClassCastException", but with the detailMessage: "tcl.lang.TclList". I used the verbose option of javac ... javac loaded the class tcl.lang.ReflectObject. I used the verbose option of java ... java didn't loaded the class tcl.lang.ReflectObject. So what can I do? What goes wrong? Thanks for any hints, suggestions! Best regards Martin Lemburg ---- [Martin Lemburg] again ... I found the errors, many errors. Here my "new" and working version: 1 TclObject result, element; 2 3 result = ip.getResult(); 4 element = null; 5 6 for ( int idx = 0 ; idx < TclList.getLength( ip, result ) ; ++idx ) 7 { 8 element = TclList.index( ip, result, idx ); 9 10 if ( (element.getInternalRep()).getClass() == TclList.class ) 11 { 12 // ... use as list ... 13 } 14 else 15 { 16 // ... use as "not" list ... 17 } 18 } ---- See also [Java]. ---- At http://www.javaworld.com/javaworld/jw-04-2002/jw-0405-scripts_p.html is an article comparing Jacl with several other scripting environments for Java. ---- ''[escargo] 11 Apr 2003'' - Has anyone tried building or running Jacl in Eclipse? ---- Has anyone figured out a way for Jacl apps to communicate with tcl/tk apps via a [send] like mechanism? [TV] I never tried jacl, but sure tried such things with Java, where the bottom line was that the stream control mechanisms must continually be reverse engineered and worked with to get a working communication, even at typing speed, of the ground. I think when going to java 1.1 (or 2) some years ago that changed again. No language or [OS] I know of specifies the communication behaviour with respect to buffer use, flow control and scheduling of processes, except that at some point while at university and working (long) with HP UX, I had a fully verifiable working model of 2 of three, where process scheduling would be OK enough except when counting on it the some round-communication (on one machine) would be optimal in all cases, so that when some processes take part in sending eachother messages, they do so in the most efficient way, which of course is impossible to define in general when one doesn't know how the reordering of the possible communications will be optimal for various cases. But the bottom line, very much so with java applets communicating with eachother, on one or more machines and with eachother or with tcl scripts or C programs, is that computers in that area are machines with consistently missing or bad documentation: no OS I know of comes with a decent, accurate, professional manual with respect to communication flow control and scheduling, except that, on the other hand, most machines work in some way related to what I've come to know as unix like sockets (I'm not sure they were invented there, it's just the oldest reference I know well): a stream , with the concept of a First In First Out has some buffer space, which gets written to by some 'write' function until it is full or some seperation character is encountered or it flushed explicitly, the other end also has a buffer, and some mechanisms to read from it, and the whole machinery ticks because buffers cannot be more empty than empty or full than all filled, and writing can be done to a non full buffer and reading from a non empty one, and communication between the connected processes is possible and sensible when there is something in some buffer to be communicated. But that is an optimistic picture: things can deadlock easily, for instance when buffers are not flushed automitically, or when the mechanisms to push data in a stream and to figure out when to read it out on the other end are not made to always unlock in the end. When the receiving process only reads from a stream which contains certain out of band information for instance, the buffer can fill up without even getting read if such 'tick' is not given to the reader. Or the OS may decide it never passes the data in a buffer from the sending to the receiving process unless some seperator character is sent, which may never happen, or only after the buffer is overrun. Also, the two way communication sensitivity may be that communication between the two processes involved must always be of a certain pattern, for instance a,b,a,b instead of a,a,b or something. Such things I remember were the problem with some java code (simple code) I tried some time ago, and I known ms windows has various of such 'issues'. When I remember correctly the nice unix way to get around a lot of problems is to make sure that at some point, one makes sure all data is flushed with time, so that the whole communication mechanism never stalls when there is enough cpu time to handle them. In many cases, the lacking definition of communication mechanisms and the problems with them require heuristics to make all tick in many circumstances. ---- [PT] 16-Sep-2003: Following some discussion on the Tcl chat - [Building JACL with Msys] ---- See also [SQL JSP Tcl Responder]. ---- [Category Language] | [Category Java]