tcljava-dev — discuss implementation and post patches here

[tcljava-dev] A new Tcl to Java compiler for Xmas

[Mo D. <md...@un...>]

Ho Ho Ho!

Tis the season for giving and because Jacl users have been
very good this year, the gift of a shiny new compiler is
now available via the tcljava CVS. The compiler is
named TJC, which stands for Tcl to Java Compiler.
The TJC compiler accepts Tcl source code as input and
compiles Tcl procs into executable Java code stored in a
Jar file. The compiler is accessed via a startup script
named tjc.

The TJC compiler is ready for evaluation by early adopters
looking for significant performance improvements for
Jacl scripts. Currently, scripts can be compiled ahead
of time but there is no support for compilation of
Tcl procs at runtime.

A simple example showing how to use the TJC compiler
is appended to this email. Many thanks got to AMD,
New Iron Systems, and One Moon Scientific for funding
this project.

cheers
Mo DeJong



SIMPLE TJC EXAMPLE:

In the following example, a TJC module containing a single
Tcl script file and a single compiled proc will be created
and loaded into the Jacl shell. This example makes use of
the tjc executable and the TJC::package command.

In this example, the Tcl source file used as input to the
TJC compiler is defined as follows:

$ cat simple.tcl
proc simple {} {
    return "SIMPLE"
}

The user will now need to create a TJC module file for the
TJC package. The name of the module file will be simple.tjc.
The name of the Java package will also be "simple", this is the
same package name that will later be passed to the TJC::package
command. The SOURCE and INIT_SOURCE declarations will list
only the simple.tcl file.

$ cat simple.tjc
PACKAGE simple

SOURCE simple.tcl
INIT_SOURCE simple.tcl

OPTIONS

Assuming that the tjc executable is already on the PATH, the TJC
compiler is invoke via:

$ tjc simple.tjc

If no error is generated, then nothing is printed and the files
simple.jar and simplesrc.jar are created in the current directory.

Note that simple.jar contains both the compiled version of the
proc simple and the script simple.tcl.

This TJC package can be loaded into a Jacl shell by adding
simple.jar to the CLASSPATH and invoking Jacl.

$ export CLASSPATH=${CLASSPATH}:`pwd`/simple.jar
$ java tcl.lang.Shell

At the Jacl shell prompt the following Tcl commands would be entered
to load the TJC package and init the simple package.

% package require TJC
1.0
% TJC::package simple
% simple
SIMPLE


The example above shows how a compiled version of the Tcl proc
named "simple" is loaded into the Jacl shell and executed.
The results returned by the compiled "simple" command are
the same as would be returned by the Tcl version of the command.

Re: [tcljava-dev] Prototype Jacl Runtime Compiler

[Bruce J. <nm...@ma...>]

I've found that when developing the code I just released that I had to 
rely on "artificial" benchmarks.  Because most of my real code uses 
constructs such as "foreach", for which the body is not yet compiled, I 
wouldn't see any performance change in "real" code.

Though ultimately any performance optimization scheme is irrelevant if 
it doesn't work well on real code, I'm not sure one can make 
substantial progress if one doesn't use simple benchmarks to understand 
where the performance bottlenecks are.

As with Tom, I found a Java profiler useful  The goal wasn't to try to 
eke out every bit of performance, but just to get some sense of which 
parts of the code were most important to worry about.  I found the new 
profiler in NetBeans ( http://profiler.netbeans.org ) to work well.

Bruce

On Sep 19, 2005, at 4:30 PM, Tom Poindexter wrote:

> On Mon, Sep 19, 2005 at 11:32:15AM -0700, Mo DeJong wrote:
>
>> Tom, what kind of scripts/tools were you using to measure this 1.3 -> 
>> 1.5
>> speed improvement? I have not found much "demo code" that was easy
>> to use with Jacl for the testing runtime performance issues. One 
>> could always
>> write a small loop and use time {...} to measure it, but that does 
>> not really
>
>
> I must confess, most of my timings were mostly artificial.  Since my 
> goal
> was to cache TclParse (and thus TclToken) objects per proc, the tests 
> that
> I used defined one or more procs and invoked those procs in for loops.
> Certainly not real world examples, but good enough to get some 
> preliminary
> results.
>
> I did use a Java profiler, JMP, to get the idea of caching TclParse.  
> I ran
> the Jacl test suite, some of my real code, and some of my contrived
> examples under the profiler.  This gave me the idea for caching 
> TclParse
> objects.
>
> Perhaps TclBench has some tests we can use?
>
>
> -- 
> Tom Poindexter
> tpo...@ny...
> http://www.nyx.net/~tpoindex/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your 
> very
> own Sony(tm)PSP.  Click here to play: 
> http://sourceforge.net/geronimo.php
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
Bruce A. Johnson, President
One Moon Scientific, Inc.
EDC III
211 Warren St
Newark, NJ 07103

Phone 908 517-5105
Fax      908 517-5107
Email  br...@on...
Web    www.onemoonscientific.com

Re: [tcljava-dev] Jacl1.3.2 "make install" error in msys

[Mo D. <md...@un...>]

On Wed, 17 Aug 2005 14:52:48 -0400
"Chang Li" <cha...@ho...> wrote:

> The Jacl1.3.2 with JDK1.5 on msys Windows XP.
> make install generated errors:
> 
> Exception in thread "main" java.lang.NoClassDefFoundError: tcl/lang/Shell
> Exception in thread "main" java.lang.NoSuchMethodError: 
> tcl.lang.Interp.setVar(
> Ljava/lang/String; Ljava/lang/String;I)V at 
> tcl.lang.Shell.main(Shell.java:76)

Could this have been caused by running configure without a --prefix
argument? A user ran into the problem and posted a note about it
on tcljava-user recently. The fix is to pass --prefix=/usr/local or
whatever to the configure script.

Mo DeJong

Re: [tcljava-dev] Prototype Jacl Runtime Compiler

[Tom P. <tpo...@ny...>]

On Mon, Sep 19, 2005 at 11:32:15AM -0700, Mo DeJong wrote:

> Tom, what kind of scripts/tools were you using to measure this 1.3 -> 1.5
> speed improvement? I have not found much "demo code" that was easy
> to use with Jacl for the testing runtime performance issues. One could always
> write a small loop and use time {...} to measure it, but that does not really


I must confess, most of my timings were mostly artificial.  Since my goal
was to cache TclParse (and thus TclToken) objects per proc, the tests that
I used defined one or more procs and invoked those procs in for loops.   
Certainly not real world examples, but good enough to get some preliminary
results.  

I did use a Java profiler, JMP, to get the idea of caching TclParse.  I ran
the Jacl test suite, some of my real code, and some of my contrived 
examples under the profiler.  This gave me the idea for caching TclParse
objects.

Perhaps TclBench has some tests we can use?


-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/

Re: [tcljava-dev] Prototype Jacl Runtime Compiler

[Mo D. <md...@un...>]

On Mon, 19 Sep 2005 09:06:33 -0600
Tom Poindexter <tpo...@ny...> wrote:

> On Sun, Sep 18, 2005 at 10:34:58PM -0400, Bruce Johnson wrote:
> 
> > I'll be posting the code shortly at my web site, but if anyone would 
> > like it sooner just email me
> > and I'll send you a copy (the compressed code is only 46Kb).
> > It consists of 11 modified or new Java source files that can just be 
> 
> 
> Bruce, this looks cool!  Please send me a copy.
> 
> I started a small 'performance' project, trying to cache the parsed TclParse
> objects per each Procedure, mapping them to the character offset in each
> proc body.  This turned out not to have a great performance impact, only
> about 1.3 - 1.5 increase.  There's still quite a bit of overhead in
> Parser.evalTokens().  Oh well, nice experiment anyway.

Tom, what kind of scripts/tools were you using to measure this 1.3 -> 1.5
speed improvement? I have not found much "demo code" that was easy
to use with Jacl for the testing runtime performance issues. One could always
write a small loop and use time {...} to measure it, but that does not really
work like "real world" Jacl code. I guess what I am really looking for is some
number of Jacl examples that do more than just a simple loop and yet can
easily be used outside of other code to test the Jacl runtime impl.

Mo DeJong

Re: [tcljava-dev] Prototype Jacl Runtime Compiler

[Bruce J. <nm...@ma...>]

cheers,

Bruce


On Sep 19, 2005, at 11:06 AM, Tom Poindexter wrote:

> On Sun, Sep 18, 2005 at 10:34:58PM -0400, Bruce Johnson wrote:
>
>> I'll be posting the code shortly at my web site, but if anyone would
>> like it sooner just email me
>> and I'll send you a copy (the compressed code is only 46Kb).
>> It consists of 11 modified or new Java source files that can just be
>
>
> Bruce, this looks cool!  Please send me a copy.
>
> I started a small 'performance' project, trying to cache the parsed 
> TclParse
> objects per each Procedure, mapping them to the character offset in 
> each
> proc body.  This turned out not to have a great performance impact, 
> only
> about 1.3 - 1.5 increase.  There's still quite a bit of overhead in
> Parser.evalTokens().  Oh well, nice experiment anyway.
>
> -- 
> Tom Poindexter
> tpo...@ny...
> http://www.nyx.net/~tpoindex/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your 
> very
> own Sony(tm)PSP.  Click here to play: 
> http://sourceforge.net/geronimo.php
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
Bruce A. Johnson, President
One Moon Scientific, Inc.
EDC III
211 Warren St
Newark, NJ 07103

Phone 908 517-5105
Fax      908 517-5107
Email  br...@on...
Web    www.onemoonscientific.com

Re: [tcljava-dev] Prototype Jacl Runtime Compiler

[Tom P. <tpo...@ny...>]

On Sun, Sep 18, 2005 at 10:34:58PM -0400, Bruce Johnson wrote:

> I'll be posting the code shortly at my web site, but if anyone would 
> like it sooner just email me
> and I'll send you a copy (the compressed code is only 46Kb).
> It consists of 11 modified or new Java source files that can just be 


Bruce, this looks cool!  Please send me a copy.

I started a small 'performance' project, trying to cache the parsed TclParse
objects per each Procedure, mapping them to the character offset in each
proc body.  This turned out not to have a great performance impact, only
about 1.3 - 1.5 increase.  There's still quite a bit of overhead in
Parser.evalTokens().  Oh well, nice experiment anyway.

-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/

[tcljava-dev] Prototype Jacl Runtime Compiler

[Bruce J. <nm...@ma...>]

Dear Jacl folk,

I've been doing some work recently to prototype some methods for
increasing the performance of Jacl.  Originally I did a protoype
that  focussed on actually compiling Jacl code to Java byte codes.
While this looked feasible it was quite complicated and looked
like it would take quite a bit of effort to complete.  I've spent
some time recently looking at a different approach.  This consists
of compiling Jacl code to a series of Instruction objects
which are then executed by iterating through the list of
instructions and calling the "exec" method for each.  The code is
relatively simple and at present simple, artificial benchmarks are
sped up by about 2-10x.

For example:

proc tproc {} {
string length abc
string length abc
... repeat to a total of 30 lines
}

is sped up 10x, with a StringInstruction that  explicitly executes
the "string length" command.

proc tproc {} {
set a1 duck
set a2 $a1
set a3 $a2
set a4 $a3
set a5 $a4
set a6 $a5
set a7 $a6
set a8 $a7
set a9 $a8
set a10 $a9
}

is sped up about 3x, and is ultimately limited by the lack of
explicit optimization of local variable lookup.  Implementation
of a local variable table should substantially increase this 
performance.


Note that these calculations are done after first executing the
procedure multiple times.  The initial speed increase is lower.
I'm guessing this is an effect of the Java Hot Spot compiler.


My company has some money available to fund some work on Jacl
optimization and am currently considering the best way to proceed.  The
protoype work I describe here may not be the best solution and may not
be developed beyond this stage. There are certainly alternative 
approaches.
I thought I'd make this code available and get some feedback on it.
I'd welcome opinions on whether people think this approach is 
reasonable.

Note that the code is written simply to get a quick idea of the value 
in this
approach and could be substantially rewritten.  Also note that only the 
"if" and
"for" flow instructions are implemented.  Jacl code within loops such 
as the "foreach"
command is not yet compiled so no performance increase will be seen.

Running the test suite (with certain tests disabled) gives the 
following results:

all.tcl:        Total   4912    Passed  4565    Skipped 294     Failed  
53

I disabled about 5 test files that caused the testing to crash and have 
not yet
investigated the source of these problems.

Note: running the code gives the following message when procedures are 
created:

WARNING: This code running with experimental Jacl runtime compiler 
support!
It is not now ready, and may never be ready, for production use!


I'll be posting the code shortly at my web site, but if anyone would 
like it sooner just email me
and I'll send you a copy (the compressed code is only 46Kb).
It consists of 11 modified or new Java source files that can just be 
copied into
the Jacl 1.3.2 distribution that Mo recently released.

best regards,

Bruce

Bruce A. Johnson
One Moon Scientific, Inc.
EDC III
211 Warren St
Newark, NJ 07103

Phone 908 517-5105
Fax      908 517-5107
Email  br...@on...
Web    www.onemoonscientific.com



More details on the methodology follow:


Compilation proceedes by parsing Jacl scripts using code translated 
from the C version of Tcl.
During compilation, instructions are added to a list of instructions.  
Instructions consist of
Java objects that are instances of classes that extend an abstract 
Instruction class:

    static public abstract class Instruction {
         private String name = null;
         private int stackEffect = 0;
         Instruction(String name,int stackEffect) {
             this.name = name;
             this.stackEffect = stackEffect;
         }
         public String toString() {return name;}

         abstract int exec(CompileEnv env,Object instructions[], int iC) 
throws TclException;
     }

Each Instruction class provides a concrete implementation of the "exec" 
method.

For example, the PUSH Instruction:

         public static final Instruction PUSH =   new 
Instruction("push", 1) {
             int exec(CompileEnv env,Object instructions[],int iC) {
                 int index = ((Integer) instructions[iC+1]).intValue();
                 env.stack.push(env.literalsArray[index]);
                 return 1;
             }
         };


More complicated instructions, for example, those that implement flow 
control extend the
Instruction class.

For example, the If instruction is implemented as follows (note that at 
present the expressions in the If command
are not compiled, though the execution bodies are:

     class IfInstruction extends Instruction {
         IfInstruction(String name,int stackEffect) {
             super(name,stackEffect);
         }
         ArrayList branches = new ArrayList();
         ArrayList expressions = new ArrayList();
         void addInstructionBranch(ArrayList branch) {
             branches.add(branch);
         }
         void addExpression(String expression) {
             expressions.add(expression);
         }

         int exec(CompileEnv env,Object instructions[],int iC) throws 
TclException {
             int i = 0;
             for (i=0;i<expressions.size();i++) {
                 boolean value = interp.expr.evalBoolean(interp,(String) 
expressions.get(i));
                 if (value) {
                     break;
                 }
             }
             if (i < branches.size()) {
                 Object myInstructions[] = ((ArrayList) 
branches.get(i)).toArray();
                 execInstructionList(interp,myInstructions, false);
             } else {

             }
             return 1;
         }
     }

At present there are only about 16 instructions implemented.

Execution of a compiled script proceeds by incrementing through the 
list of instructions and calling
the "exec" method of each.  This relies on the simple use of Javas 
intrinsic method dispatch capabilities, rather
than complicated if/then or switch statements.


Actual Java source files used to implement the compiler/execution 
system are described below:


  src/jacl/tcl/lang/Procedure.java
       Modified to call compiler when procedure is created.
       If global Tcl variable CompileProc(procedureName) is present and 
set to false
           then the procedure will not be compiled.
       If procedure has been compiled, then when it is executed the 
compiled instructions will be executed.

src/jacl/tcl/lang/VarType.java
       Used by compiler in managing variables, Note: there is no 
optimized support yet for local variables

src/jacl/tcl/lang/Compiler.java
     Compiles procedures

src/jacl/tcl/lang/CompileEnvjava
     Compilation environemnt.
     Containts subclasses for an Execution stack and Instructions to 
execute.
     Current instructions are:
          Instructions for manipulating objects on stack
              PUSH, DISCARD, POP, DUP, CONCAT,
          Instructions for invoking execution
              INVOKE,
          Instructions for moving stack elements between stack and 
variables
              LOAD_SCALAR_STK, STORE_SCALAR_STK, STORE_ARRAY_STK, 
LOAD_ARRAY_STK, LOAD_SCALAR, LOAD_ARRAY
          Prototype of a math instruction:
              MULT
          Flow control execution
              IfInstruction, ForInstruction
          Compiled Tcl commands
              StringInstruction (only implements "string length" at 
present

src/jacl/tcl/lang/CTclParse.java
     Modified version of TclParse for use with Compiler

src/jacl/tcl/lang/CParser.java
     Translation of Parser for C version to parse scripts prior to 
compilation


the following are present, but not complete, functional or used yet

src/jacl/tcl/lang/OperatorDesc.java
    Math and Boolean operators for compiling expressions
src/jacl/tcl/lang/MathFunc.java
    Math functions for compiling expressions
src/jacl/tcl/lang/ParseExpr.java
     Used to parse expressions
src/jacl/tcl/lang/ParseExpr.java
     Used to compile expressions
src/jacl/tcl/lang/CompCommand.java
     Interface for commands that are compiled (this is not now used, and 
may not be used)

Re: [tcljava-dev] Itcl support added to Jacl!

[Tom P. <tpo...@ny...>]

On Wed, Sep 14, 2005 at 06:49:14PM -0700, Mo DeJong wrote:
> This message is to announce the availability of a
> new Itcl port for Jacl. Jacl is a 100% pure version
> of the Tcl scripting language. Itcl is an object

> This software was made possible thanks to:
> 
> AMD
> New Iron Systems


Most Excellent!  I'm eager to try out the new code.  
Thanks to both you and the benefactors.


-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/

[tcljava-dev] Itcl support added to Jacl!

[Mo D. <md...@un...>]

This message is to announce the availability of a
new Itcl port for Jacl. Jacl is a 100% pure version
of the Tcl scripting language. Itcl is an object
oriented extension for Tcl. Itcl users will now
be able to run Itcl code directly in Jacl.

The Itcl port was implemented by Mo DeJong as part
of a Jacl support and maintenance contract. Itcl 3.2.1
was ported from its original C source code to Java
source code. A version of Jacl that includes Itcl
support is available via the Sourceforge CVS. It can be
downloaded via CVS with the following commands:

CVSROOT=:pserver:ano...@cv...:/cvsroot/tcljava
cvs login
(press enter at password prompt)
cvs co tcljava

Build and install Jacl in the normal way and then run
"package require Itcl" to load Itcl commands into Jacl.


This software was made possible thanks to:

AMD
New Iron Systems

[tcljava-dev] Re: tcljava-dev digest, Vol 1 #142 - 2 msgs

[Patrick F. <pfi...@oz...>]

I am interested.  Send me the deets and I will try a Windows build.

Patrick.

>
>Hi Mo,
>
>Remember I asked about creating an Eclipse plugin for TclBlend? Well, 
>I've successfully
>created an Eclipse plugin. I was wondering if the TclJava developers 
>were interested in
>my changes?
>
>My changes required very little changes to the TclJava code.
>I also went ahead and updated the configure and Makefile.in files. Now 
>if a user uses
>the --enable-eclipseplugin --with-eclipse=<ECLIPSE_INSTALL_DIR> then 
>they should
>be able to build the Eclipse plugin.
>
>The Eclipse plugin requires that Tcl was built statically (i.e. 
>--disable-shared). This is so the
>plugin does not have to rely on Tcl being install on the users system in 
>order to use it. It makes
>is self-contained.
>
>The Eclipse plugin is two separate plugins:
>
>tcl.lang_1.3.2.jar
>-and-
>tcl.lang.<os>.<arch>_1.3.2/   <-- this is a fragment for the tcl.lang 
>plugin (platform specific).
>
>The fragment contains a lib/tcl8.4 directory and this is where the 
>init.tcl file wil be sourced
>when the pluginin is used.
>
>Let me know if you're interested in having my changes. I've only tested 
>building the plugin on
>Linux. However, I'm working on a Solaris test.
>
>Regards,
>
>Greg Pierce
>LSI Logic Corp.
>
>  
>

[tcljava-dev] Re: [tcljava-user] Creating an Eclipse plug-in for TclBlend

[Mo D. <md...@un...>]

On Wed, 31 Aug 2005 16:49:31 -0400
Gregory Pierce <gp...@ls...> wrote:

> Hi Mo,
> 
> I'm not familiar with the tcljava patch tool on Sourceforge. Can you 
> point me in the right direction?

See:
http://sourceforge.net/projects/tcljava/

Patches go here:

http://sourceforge.net/tracker/?atid=313005&group_id=13005&func=browse

cheers
Mo

[tcljava-dev] Re: [tcljava-user] Creating an Eclipse plug-in for TclBlend

[Gregory P. <gp...@ls...>]

Hi Mo,

Remember I asked about creating an Eclipse plugin for TclBlend? Well, 
I've successfully
created an Eclipse plugin. I was wondering if the TclJava developers 
were interested in
my changes?

My changes required very little changes to the TclJava code.
I also went ahead and updated the configure and Makefile.in files. Now 
if a user uses
the --enable-eclipseplugin --with-eclipse=<ECLIPSE_INSTALL_DIR> then 
they should
be able to build the Eclipse plugin.

The Eclipse plugin requires that Tcl was built statically (i.e. 
--disable-shared). This is so the
plugin does not have to rely on Tcl being install on the users system in 
order to use it. It makes
is self-contained.

The Eclipse plugin is two separate plugins:

tcl.lang_1.3.2.jar
-and-
tcl.lang.<os>.<arch>_1.3.2/   <-- this is a fragment for the tcl.lang 
plugin (platform specific).

The fragment contains a lib/tcl8.4 directory and this is where the 
init.tcl file wil be sourced
when the pluginin is used.

Let me know if you're interested in having my changes. I've only tested 
building the plugin on
Linux. However, I'm working on a Solaris test.

Regards,

Greg Pierce
LSI Logic Corp.



Mo DeJong wrote:

>On Mon, 22 Aug 2005 12:49:30 -0400
>Gregory Pierce <gp...@ls...> wrote:
>
>  
>
>>Hi,
>>
>>Does anyone know how I could create an Eclipse plug-in for TclBlend?
>>I would want this plug-in to contain any required native shared 
>>libraries so that
>>I could send this plug-in to anyone and they could use it without having 
>>to build
>>and install Tcl on their system first.
>>    
>>
>
>Really hard to do. You could build Tcl and Tcl Blend and zip up the
>install tree but the trouble is that Tcl Blend depends on runtime
>env vars to find the JDK that it is linked to. At runtime, it needs to
>find jvm.dll and that means the PATH has to be searched. If you
>knew the JVM location or the PATH that jvm dlls were found on,
>then you might be able to do it. The trick will be getting all the
>env vars setup correctly when the JVM process starts. The process
>under Unix is the same except that you set LD_LIBRARY_PATH instead
>of PATH (for Win32).
>
>You would have a much easier time setting up a Jacl plugin since
>all that is needed is to add tcljava.jar and jacl.jar to the CLASSPATH.
>
>cheers
>Mo DeJong
>
>
>  
>

[tcljava-dev] Jacl1.3.2 "make install" error in msys

[Chang L. <cha...@ho...>]

The Jacl1.3.2 with JDK1.5 on msys Windows XP.
make install generated errors:

Exception in thread "main" java.lang.NoClassDefFoundError: tcl/lang/Shell
Exception in thread "main" java.lang.NoSuchMethodError: 
tcl.lang.Interp.setVar(
Ljava/lang/String; Ljava/lang/String;I)V at 
tcl.lang.Shell.main(Shell.java:76)

....

What is wrong?

Chang

[tcljava-dev] New Jacl/Tcl Blend 1.3.2 release is online!

[Mo D. <md...@un...>]

This message is to announce the new 1.3.2 release of Jacl and
Tcl Blend.  These releases are the result of efforts by Mo DeJong
and the Jacl and Tcl Blend user community.

The 1.3.2 release of Jacl and Tcl Blend are available for
downloading at the following URL:

    http://sourceforge.net/project/showfiles.php?group_id=13005

The 1.3.2 version is a "production" ready release, it is
considered stable enough to be used on an everyday basis.
The code in this release is already being used by customers
in production environments on a daily basis.

What's New in the 1.3.2 Release?
----------------------------------

The 1.3.2 release includes a couple of minor new features
and some important bug fixes. Tcl Blend now includes the
file win/libjvm.dll.a, it is needed to build with some broken
JDKs in a Windows environment. Running Jacl and Tcl Blend in
a Windows environment is now easier as a batch file startup
script is now installed as part of the default build.
A pre-compiled Jacl release that includes only the files
needed to run Jacl is now available. The jaclsh startup script
now returns a non-zero exit status if some error was encountered
while processing a script. IO support in the Interp class
has been re-implemented so that it makes use of the new IO
layer. Jacl and Tcl Blend can now be compiled in a JDK 1.5
environment. A number of tricky expr command number parsing
bugs have been fixed in Jacl. Also, the classloader issues that
made it difficult to run Jacl in certain environments have
been resolved.

See the new_features.txt and changes.txt files for more info.

What is Jacl?
----------------

Jacl is a 100% Java implementation of Tcl 8.  This allows Tcl to run
in more environments and also brings the power of scripting to Java
developers.  Jacl implements almost all the features available in
the C version of Tcl and is well tested.

What is Tcl Blend?
------------------------

Tcl Blend is a Tcl Extension that allows you to have access to the
Java VM from the Tcl interpreter.  The goal here is to allow Tcl
developers to write new Tcl extensions in Java rather then C or C++
for better portability.  A developer can also load both Tcl and
Tcl Blend into an existing Java JVM. Tcl Blend is known to work on
Solaris, Windows 95/NT/XP, IRIX, and Linux. Other systems have not
been tested but it should be easy to port Tcl Blend to any system
that supports dynamic loading and the Java JNI interface.

For additional information:
---------------------------------

The primary website for Tcl/Java related information is:

    http://tcljava.sourceforge.net/

The README file included in the Jacl and Tcl Blend releases
includes lots or additional information including how
to sign up for the tcljava mailing lists.

Re: [tcljava-dev] Jacl 1.3.2 socket flush problem

[Neil M. <ne...@cs...>]

This is the same problem that I reported a few days ago. Mo posted a  
patch to the list which fixes the problem.

See http://sourceforge.net/mailarchive/forum.php? 
forum_id=3849&max_rows=25&style=flat&viewmonth=200507&viewday=21

Cheers,

-- Neil
On 26 Jul 2005, at 01:34, Martti Tienhaara wrote:

>>    1. Call for testers for Jacl/TclBlend 1.3.2 pre-release (Mo  
>> DeJong)
>>
>
> I get a problem with socket flush on the binary release version of  
> Jacl 1.3.2 on Fedora Core3, Sun Java jdk1.5.0_02. When I run the  
> identical sequence with Jacl 1.3.1 it runs fine.
>
> [martti@puppy jacl132]$ ./jaclsh
> % set chan [socket localhost 51002]
> sock0
> % puts $chan "hello"
> % flush $chan
> Exception in thread "main" tcl.lang.TclRuntimeError:  
> FlushCmd.cmdProc() Error: IOException when flushing sock0
>         at tcl.lang.FlushCmd.cmdProc(FlushCmd.java:50)
>         at tcl.lang.AutoloadStub.cmdProc(Extension.java:144)
>         at tcl.lang.Parser.evalObjv(Parser.java:818)
>         at tcl.lang.Parser.eval2(Parser.java:1221)
>         at tcl.lang.Interp.eval(Interp.java:2222)
>         at tcl.lang.Interp.eval(Interp.java:2306)
>         at tcl.lang.Interp.recordAndEval(Interp.java:2361)
>         at tcl.lang.ConsoleThread$1.processEvent(Shell.java:321)
>         at tcl.lang.Notifier.serviceEvent(Notifier.java:444)
>         at tcl.lang.Notifier.doOneEvent(Notifier.java:585)
>         at tcl.lang.Shell.main(Shell.java:151)
>
> -- 
> Martti Tienhaara (ma...@da...)
> DASH Software Ltd.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>

[tcljava-dev] Jacl 1.3.2 socket flush problem

[Martti T. <ma...@da...>]

>    1. Call for testers for Jacl/TclBlend 1.3.2 pre-release (Mo DeJong)

I get a problem with socket flush on the binary release version of Jacl 
1.3.2 on Fedora Core3, Sun Java jdk1.5.0_02. When I run the identical 
sequence with Jacl 1.3.1 it runs fine.

[martti@puppy jacl132]$ ./jaclsh
% set chan [socket localhost 51002]
sock0
% puts $chan "hello"
% flush $chan
Exception in thread "main" tcl.lang.TclRuntimeError: FlushCmd.cmdProc() 
Error: IOException when flushing sock0
         at tcl.lang.FlushCmd.cmdProc(FlushCmd.java:50)
         at tcl.lang.AutoloadStub.cmdProc(Extension.java:144)
         at tcl.lang.Parser.evalObjv(Parser.java:818)
         at tcl.lang.Parser.eval2(Parser.java:1221)
         at tcl.lang.Interp.eval(Interp.java:2222)
         at tcl.lang.Interp.eval(Interp.java:2306)
         at tcl.lang.Interp.recordAndEval(Interp.java:2361)
         at tcl.lang.ConsoleThread$1.processEvent(Shell.java:321)
         at tcl.lang.Notifier.serviceEvent(Notifier.java:444)
         at tcl.lang.Notifier.doOneEvent(Notifier.java:585)
         at tcl.lang.Shell.main(Shell.java:151)

-- 
Martti Tienhaara (ma...@da...)
DASH Software Ltd.

Re: [tcljava-dev] Call for testers for Jacl/TclBlend 1.3.2 pre-release

[Neil M. <ne...@cs...>]

Hi Mo,

On 22 Jul 2005, at 06:25, Mo DeJong wrote:

> On Thu, 21 Jul 2005 11:45:12 +0100
> Neil Madden <ne...@cs...> wrote:
>
>
>> % get wiki.tcl.tk 80 /4
>> Exception in thread "main" tcl.lang.TclRuntimeError: FlushCmd.cmdProc
>> () Error: IOException when flushing sock0
>>
>
> Neil, could you try out the attached patch and see if that fixes up  
> the
> problem for you?

Yup, that fixes the problem.

Cheers,

-- Neil

Re: [tcljava-dev] Call for testers for Jacl/TclBlend 1.3.2 pre-release

[Mo D. <md...@un...>]

On Thu, 21 Jul 2005 11:45:12 +0100
Neil Madden <ne...@cs...> wrote:

> % get wiki.tcl.tk 80 /4
> Exception in thread "main" tcl.lang.TclRuntimeError: FlushCmd.cmdProc 
> () Error: IOException when flushing sock0

Neil, could you try out the attached patch and see if that fixes up the
problem for you?

thanks
Mo DeJong

Re: [tcljava-dev] Call for testers for Jacl/TclBlend 1.3.2 pre-release

[Mo D. <md...@un...>]

On Thu, 21 Jul 2005 12:02:32 +0100
Neil Madden <ne...@cs...> wrote:

> Whoop,
> 
> Forgot to attach the file. Here it is.

Neil, thanks for sending this. Some of the jikes warnings can be
ignored, but your note got me looking at the binary command and
I found a couple of nastly format and scan bugs that needed to be
fixed. Those fixes are in the CVS now thanks to you.

cheers
Mo DeJong

Re: [tcljava-dev] Call for testers for Jacl/TclBlend 1.3.2 pre-release

[Neil M. <ne...@cs...>]

Whoop,

Forgot to attach the file. Here it is.

-- Neil

Re: [tcljava-dev] Call for testers for Jacl/TclBlend 1.3.2 pre-release

[Neil M. <ne...@cs...>]

Hi Mo,

I downloaded and built the jacl1.3.2.tar.gz on Mac OS X 10.4.2, with  
the Java 1.5 SDK installed. I get some "Semantic Warnings" on  
compilation. As there are a few, I've attached the output of "make",  
in case you want to look through them. When I run the resulting  
jaclsh, the only problem I notice is that any call to flush on a  
socket results in an error (same with close), e.g.:

% proc get {host port path} {
set s [socket $host $port]
puts $s "GET $path HTTP/1.0"
puts $s "Host: $host\n"
flush $s
return $s
}
% get wiki.tcl.tk 80 /4
Exception in thread "main" tcl.lang.TclRuntimeError: FlushCmd.cmdProc 
() Error: IOException when flushing sock0
         at tcl.lang.FlushCmd.cmdProc(FlushCmd.java:50)
         at tcl.lang.AutoloadStub.cmdProc(Extension.java:144)
         at tcl.lang.Parser.evalObjv(Parser.java:818)
         at tcl.lang.Parser.eval2(Parser.java:1221)
         at tcl.lang.Procedure.cmdProc(Procedure.java:161)
         at tcl.lang.Parser.evalObjv(Parser.java:818)
         at tcl.lang.Parser.eval2(Parser.java:1221)
         at tcl.lang.Interp.eval(Interp.java:2222)
         at tcl.lang.Interp.eval(Interp.java:2306)
         at tcl.lang.Interp.recordAndEval(Interp.java:2361)
         at tcl.lang.ConsoleThread$1.processEvent(Shell.java:321)
         at tcl.lang.Notifier.serviceEvent(Notifier.java:444)
         at tcl.lang.Notifier.doOneEvent(Notifier.java:585)
         at tcl.lang.Shell.main(Shell.java:151)

Cheers,

-- Neil

On 21 Jul 2005, at 02:55, Mo DeJong wrote:

> Hello all
>
> I have been working on a new 1.3.2 release for Jacl
> and Tcl Blend and it is at the point where some
> testing help from interested developers would really
> be useful.
>
> Here are the pre-release URLs, these urls will be
> valid for about a week (today is 7/20/05).
>
> http://www.dubiner.com/~mo/handoff/jacl1.3.2.tar.gz
> http://www.dubiner.com/~mo/handoff/jaclBinary132.zip
>
> http://www.dubiner.com/~mo/handoff/tclBlend1.3.2.tar.gz
>
> This 1.3.2 version includes a binary release of Jacl and
> startup .bat scripts. There have been a number of
> Tcl Blend fixes to get everything working with Tcl 8.4.11.
> Other than that, this is a bug fix release. Note that to
> build Tcl Blend you should use the cvs version of the
> Thread package.
>
> Please post a note to the list if you run into any
> problems.
>
> thanks much
> Mo DeJong

[tcljava-dev] Call for testers for Jacl/TclBlend 1.3.2 pre-release

[Mo D. <md...@un...>]

Hello all

I have been working on a new 1.3.2 release for Jacl
and Tcl Blend and it is at the point where some
testing help from interested developers would really
be useful.

Here are the pre-release URLs, these urls will be
valid for about a week (today is 7/20/05).

http://www.dubiner.com/~mo/handoff/jacl1.3.2.tar.gz
http://www.dubiner.com/~mo/handoff/jaclBinary132.zip

http://www.dubiner.com/~mo/handoff/tclBlend1.3.2.tar.gz

This 1.3.2 version includes a binary release of Jacl and
startup .bat scripts. There have been a number of
Tcl Blend fixes to get everything working with Tcl 8.4.11.
Other than that, this is a bug fix release. Note that to
build Tcl Blend you should use the cvs version of the
Thread package.

Please post a note to the list if you run into any
problems.

thanks much
Mo DeJong

Re: [tcljava-dev] Parsing Jacl

[Tom P. <tpo...@ny...>]

On Fri, Mar 04, 2005 at 03:26:15PM -0800, Mo DeJong wrote:
> Funny you should mention this now, I just started on a project to do something
> very much the same except that I am going to parse Jacl and write out .java
> source code.


Funny you should mention this, * 2.  I too started on a similar project, 
but it's been on the shelf for quite a while.  My idea was to write the
entire system in Tcl, using 'parsetcl' (http://wiki.tcl.tk/9649), as the
main parser, and a modified version of Nsync's (should ring a few bells, eh!)
LL(1) parser to parse 'expr' expressions.  Then compile the whole thing 
on the fly using my Hyde package.  I had thoughts on generating either Java
or C, depending on the actual runtime (using critcl to do the on-the-fly
compilation for C).  I had also modified Jacl to expose CallFrame and 
Namespace classes as public.  Yeah, I realize that writing the compiler system
in Tcl would be slow, but I was planning to write the compiler in a way to 
allow bootstrapping the compiler itself.

I was also planning to impose some limitations on the compiler to avoid
the sticky parts of compiling Tcl, such as assuming all builtin commands 
as immmutable, punting on 'trace', etc.  I never got that far to worry 
about the actual implementation.

Good luck, and keep us informed on your progress.  

-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/

Re: [tcljava-dev] Parsing Jacl

[Mo D. <md...@un...>]

On Mon,  7 Mar 2005 15:10:54 -0500
vm...@en... wrote:

> Thank you Mo DeJong for the reply. It helped a lot. However, I have a small 
> concern. What would happen to the tclparser when, in the process of parsing, 
> it comes across some Jacl constructs which are not found in Tcl (for example, 
> a command to access a Java library)? In that case, we might need to extend the 
> tclparser, right? 

The Tcl parser parses Tcl syntax. The Tcl commands defined in Tcl are not
part of the syntax. So, Jacl commands will be parsed just like any other
Tcl commands.
 
cheers
Mo DeJong