http://sf.net/projects/tcljava/ is the home for [TclBlend] as well as Jacl. Jacl is an alternate implementation of [Tcl] 8.x, this time written entirely in [Java]. ---- [[Is it safe to assume that the Jacl mentioned here is unrelated to http://jacl.sf.net/ - or are they in fact the same thing?]] [NEM] Looks like something completely different to me. ---- What: Jacl Where: http://tcljava.sourceforge.net/docs/website/ http://www.tcl.tk/software/java/ http://ptolemy.eecs.berkeley.edu/%7Ecxh/java/tclblend http://www.cs.umn.edu/%7Edejong/tcl/tcljava/ http://www.nmrview.com/swank/ Description: Jacl is a Tcl 8.x interpreter written in Java. Demos, etc. are available on the web page. Also available is Tcl Blend, a Tcl extension that allows you access to the Java VM from the Tcl interpreter. This is to allow a developer to write new Tcl extensions in Java. SWANK is a graphical interface designed to be used with Jacl to give the programmer the feel of programming in Tk. Currently at version 1.3.1 . Updated: 03/2003 Contact: mailto:tcljava@tcl.activestate.com mailto:jacl-subscribe@MakeList.com mailto:jacl-unsubscribe@MakeList.com ---- 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.) [LV] Sun has nothing to do with Tcl ... it has been long enough that the people still working there may not even remember that there was ever a Tcl and Sun connection. It'd be great however if some of the Java heavies got on the Jacl band-wagon. ---- 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]. ([NEM] - I should probably mention that this implementation - polished by Mo, and possibly others - has been in Jacl since end of 2001 time). ---- 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. It was just updated during 2004. ---- [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. [WJR] I was having the same problem as [LV], also on Solaris, until I added ''both'' jacl.jar and tcljava.jar to my class path. Now it's working properly. [Vince] Where can one download a pre-compiled jacl.jar? [Paul Snow] I could not find a pre-compiled jar for jacl 1.3.1, but it isn't too tough to compile yourself under Linux. (I could not get it to compile under cygwin :( ) ---- [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] ---- If there is anyone out there who is an active Jacl developer, you might take a look at this online discussion [http://www.javalobby.org/thread.jspa?forumID=61&threadID=10736] and talk to people about Jacl. ---- For an informal comparison of how Jacl fared in a 2003 vote for favorite Java scripting language, check http://viva.sourceforge.net/republic/2004/01/scripting_language_of_the_year_2003_award_and_the_winner_is.html [schlenk] With only 480 votes this can be hardly seen as relevant, perhaps we should hold such votings for Tcl too... ---- [RLH]: Is Jacl still being actively developed? Or has another project supplanted it? There's been CVS activity during 2005. ---- See also [SQL JSP Tcl Responder], [Jacl and Swank Advocacy] ---- Summer 2004: "[Tom Poindexter] is working on a companion to Jacl (called Hyde) that compiles Java on the fly ..." ---- Mo has apparently worked a bit on [Jacl.NET] (and davidw does [Hecl], but that's another subject). ---- Jacl was also ported to C# by [tclcsharp] ---- See also [JFeather], [Hyde], [LAPIS], [WELD], [OO], ---- [Category Language] | [Category Java] | [Category Tcl Implementations]