tcljava-dev — discuss implementation and post patches here

Re: [tcljava-dev] Parsing Jacl

[<vm...@en...>]

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? 
What are your views regarding this?

Thank you.

Vishal


Quoting Mo DeJong <md...@un...>:

> On Fri,  4 Mar 2005 13:28:58 -0500
> vm...@en... wrote:
> 
> > Hi,
> > 
> > I'm new to both this mailing list as well as Tcl. I'm supposed to parse
> Jacl 
> > in order to convert it to Jython. After much effort, I came across
> tclparser 
> > extension to Tcl. However, I'm not sure if tclparser will be able to parse
> 
> > Jacl as well.
> 
> 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.
> 
> > Like I said, I'm new to even Tcl. I don't know how it works or how to make
> 
> > even the tclparser work. But, before I start to invest time in learning
> that, 
> > I want to make sure that it serves my purpose .i.e parsing Jacl. Will it
> parse 
> > Jacl inaccurately or will it hang altogether? 
> 
> Jacl is Tcl, so the tclparser extension should work with it just fine. I am
> going
> to be doing just this sort of thing in my project.
> 
> > If tclparser does not do the job, what is the best way to go about parsing
> 
> > Jacl? Is it possible to extend the tclparser to do that? Or, is there a
> Jacl 
> > tool similar to tclparser? Or, is it possible the access the jacl parser 
> > (maybe by picking the right fragments of the jacl source code and then 
> > building them)?
> 
> Well, tclparser is a C extension for the C version of Tcl. That is fine in
> my
> case, but keep in mind that you will not be able to run tclparser inside
> Jacl.
> Jacl does not support C extensions for Tcl. I hope that clears things up.
> 
> cheers
> Mo DeJong
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
> 




----------------------------------------
This mail sent through www.mywaterloo.ca

Re: [tcljava-dev] Parsing Jacl

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

On Fri,  4 Mar 2005 13:28:58 -0500
vm...@en... wrote:

> Hi,
> 
> I'm new to both this mailing list as well as Tcl. I'm supposed to parse Jacl 
> in order to convert it to Jython. After much effort, I came across tclparser 
> extension to Tcl. However, I'm not sure if tclparser will be able to parse 
> Jacl as well.

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.

> Like I said, I'm new to even Tcl. I don't know how it works or how to make 
> even the tclparser work. But, before I start to invest time in learning that, 
> I want to make sure that it serves my purpose .i.e parsing Jacl. Will it parse 
> Jacl inaccurately or will it hang altogether? 

Jacl is Tcl, so the tclparser extension should work with it just fine. I am going
to be doing just this sort of thing in my project.

> If tclparser does not do the job, what is the best way to go about parsing 
> Jacl? Is it possible to extend the tclparser to do that? Or, is there a Jacl 
> tool similar to tclparser? Or, is it possible the access the jacl parser 
> (maybe by picking the right fragments of the jacl source code and then 
> building them)?

Well, tclparser is a C extension for the C version of Tcl. That is fine in my
case, but keep in mind that you will not be able to run tclparser inside Jacl.
Jacl does not support C extensions for Tcl. I hope that clears things up.

cheers
Mo DeJong

[tcljava-dev] Parsing Jacl

[<vm...@en...>]

Hi,

I'm new to both this mailing list as well as Tcl. I'm supposed to parse Jacl 
in order to convert it to Jython. After much effort, I came across tclparser 
extension to Tcl. However, I'm not sure if tclparser will be able to parse 
Jacl as well.

Like I said, I'm new to even Tcl. I don't know how it works or how to make 
even the tclparser work. But, before I start to invest time in learning that, 
I want to make sure that it serves my purpose .i.e parsing Jacl. Will it parse 
Jacl inaccurately or will it hang altogether? 

If tclparser does not do the job, what is the best way to go about parsing 
Jacl? Is it possible to extend the tclparser to do that? Or, is there a Jacl 
tool similar to tclparser? Or, is it possible the access the jacl parser 
(maybe by picking the right fragments of the jacl source code and then 
building them)?

Any ideas would be highly appreciated.

Thank you

Vishal


----------------------------------------
This mail sent through www.mywaterloo.ca

Re: [tcljava-dev] Compiling TclJava with JBuilder

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

On Wed,  2 Mar 2005 17:05:00 -0300
"Fernando M. Dagostini" <fda...@uo...> wrote:

> Hi,
>  
> Is there a chance to use Jbuilder to compile TclJava package in the Windows environment?

Nope, no chance.

Mo DeJong

[tcljava-dev] Compiling TclJava with JBuilder

[Fernando M. D. <fda...@uo...>]

Hi,
 
Is there a chance to use Jbuilder to compile TclJava package in the Windo=
ws environment?
 
Sorry if this is a stupid question but a search for =93Jbuilder=94 in the=
 list didn=92t return any reference.
 
Regards,

Fernando M. Dagostini.=0A =0A____________________________________________=
______________________________=0AAcabe com aquelas janelinhas que pulam n=
a sua tela.=0AAntiPop-up UOL - =C9 gr=E1tis!=0Ahttp://antipopup.uol.com.b=
r/=0A

[tcljava-dev] Make problem with XP

[Mcgee, S. <sm...@ug...>]

All,

=20

I really need your help with compiling the Jacl 1.3.1 and tclBlend
1.3.1.

=20

I'm following the steps outlined at this site http://wiki.tcl.tk/9993.
When I get to the "make" statement of the tclblend  (step eight) I get
the following errors listed below.

=20

Could someone please let me know what I'm doing wrong?

=20

My operating system is XP, and I'm using j2sdk1.4.2_04.

=20

Thanks,

=20

Scott

=20

Error Message ...

=20

rm -rf /home/x_mulert/jacl1.3.1/tcljava

rm -f  tcljava.jar

#

# Making tcljava.build

#

mkdir -p /home/x_mulert/jacl1.3.1/tcljava cd
/home/x_mulert/jacl1.3.1/src/tcljava ;\
CLASSPATH=3D/home/x_mulert/jacl1.3.1/tcljava:/home/x_mulert/jacl1.3.1/src=
/
empty/empty.jar:/c/j2sdk1.4.2_06/jre/lib/rt.jar \
/c/j2sdk1.4.2_06/bin/javac -g \

      -d /home/x_mulert/jacl1.3.1/tcljava \

      tcl/lang/reflect/*.java

cd /home/x_mulert/jacl1.3.1/src/tcljava ;\
CLASSPATH=3D/home/x_mulert/jacl1.3.1/tcljava:/home/x_mulert/jacl1.3.1/src=
/
empty/empty.jar:/c/j2sdk1.4.2_06/jre/lib/rt.jar \
/c/j2sdk1.4.2_06/bin/javac -g \ -d /home/x_mulert/jacl1.3.1/tcljava \

      tcl/lang/*.java

tcl/lang/ReflectObject.java:185: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

      Vector conflicts =3D (Vector) =
interp.reflectConflictTable.get(hash);

                                          ^

tcl/lang/ReflectObject.java:189: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

          interp.reflectConflictTable.put(hash, conflicts);

                  ^

tcl/lang/ReflectObject.java:235: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

        Vector conflicts =3D (Vector)
interp.reflectConflictTable.get(hash);

                                            ^

tcl/lang/ReflectObject.java:242: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

              interp.reflectConflictTable.remove(hash);

                        ^

tcl/lang/ReflectObject.java:258: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

        Vector conflicts =3D (Vector)
interp.reflectConflictTable.get(hash);

                                            ^

tcl/lang/ReflectObject.java:281: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

            interp.reflectConflictTable.remove(hash);

                    ^

tcl/lang/ReflectObject.java:296: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

    Vector conflicts =3D (Vector) interp.reflectConflictTable.get(hash);

                                      ^

tcl/lang/ReflectObject.java:371: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

    System.out.println("interp.reflectConflictTable.size() =3D " +
interp.reflectConflictTable.size());

                                                                       ^

tcl/lang/ReflectObject.java:407: cannot resolve symbol symbol  :
variable reflectConflictTable

location: class tcl.lang.Interp

      Vector conflicts =3D (Vector) =
interp.reflectConflictTable.get(hash);

                                          ^

tcl/lang/ReflectObject.java:454: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (cl !=3D null && !PkgInvoker.isAccessible(cl)) {

                                 ^

tcl/lang/TclObject.java:239: cannot resolve symbol symbol  : method
incrRefCount ()

location: class tcl.lang.CObject

          ((CObject) internalRep).incrRefCount();

            ^

tcl/lang/TclObject.java:266: cannot resolve symbol symbol  : method
decrRefCount ()

location: class tcl.lang.CObject

          ((CObject) internalRep).decrRefCount();

            ^

tcl/lang/TclObject.java:308: cannot resolve symbol symbol  : method
getCObjectPtr ()

location: class tcl.lang.CObject

          return ((CObject) internalRep).getCObjectPtr();

                   ^

tcl/lang/FieldSig.java:165: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

      if (!PkgInvoker.isAccessible(sigCls)) {

                       ^

tcl/lang/FieldSig.java:207: cannot resolve symbol symbol  : method
usesDefaultInvoker (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (PkgInvoker.usesDefaultInvoker(cls)) {

                  ^

tcl/lang/FieldSig.java:216: cannot resolve symbol symbol  : method
isAccessible (java.lang.reflect.Field)

location: class tcl.lang.reflect.PkgInvoker

          if (PkgInvoker.isAccessible(f)) {

                          ^

tcl/lang/FieldSig.java:255: cannot resolve symbol symbol  : method
usesDefaultInvoker (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (PkgInvoker.usesDefaultInvoker(cls)) {

                  ^

tcl/lang/FieldSig.java:259: cannot resolve symbol symbol  : method
isAccessible (java.lang.reflect.Field)

location: class tcl.lang.reflect.PkgInvoker

      if (!PkgInvoker.isAccessible(f)) {

                       ^

tcl/lang/FuncSig.java:221: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if ((isConstructor || isStatic) && !PkgInvoker.isAccessible(cls)) {

                                                  ^

tcl/lang/FuncSig.java:1102: cannot resolve symbol symbol  : method
usesDefaultInvoker (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (PkgInvoker.usesDefaultInvoker(cls)) {

                  ^

tcl/lang/FuncSig.java:1111: cannot resolve symbol symbol  : method
isAccessible (java.lang.reflect.Constructor)

location: class tcl.lang.reflect.PkgInvoker

          if (PkgInvoker.isAccessible(c)) {

                          ^

tcl/lang/FuncSig.java:1150: cannot resolve symbol symbol  : method
usesDefaultInvoker (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (PkgInvoker.usesDefaultInvoker(cls)) {

                  ^

tcl/lang/FuncSig.java:1155: cannot resolve symbol symbol  : method
isAccessible (java.lang.reflect.Constructor)

location: class tcl.lang.reflect.PkgInvoker

      if (!PkgInvoker.isAccessible(constructor)) {

                       ^

tcl/lang/FuncSig.java:1265: cannot resolve symbol symbol  : method
isAccessible (java.lang.reflect.Method)

location: class tcl.lang.reflect.PkgInvoker

      if (Modifier.isStatic(m.getModifiers()) &&
PkgInvoker.isAccessible(m)) {

                                                             ^

tcl/lang/FuncSig.java:1312: cannot resolve symbol symbol  : method
isAccessible (java.lang.reflect.Method)

location: class tcl.lang.reflect.PkgInvoker

              !PkgInvoker.isAccessible(newMeth)) {

                           ^

tcl/lang/JavaCastCmd.java:60: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (!PkgInvoker.isAccessible(cast_to)) {

                   ^

tcl/lang/JavaImportCmd.java:332: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

                if (!PkgInvoker.isAccessible(c)) {

                                   ^

tcl/lang/JavaInfoCmd.java:132: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

      if (!PkgInvoker.isAccessible(c)) {

                       ^

tcl/lang/JavaInfoCmd.java:181: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

          if (!PkgInvoker.isAccessible(c)) {

                           ^

tcl/lang/JavaInfoCmd.java:207: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

          if (!PkgInvoker.isAccessible(c)) {

                           ^

tcl/lang/JavaInfoCmd.java:221: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

          if (!PkgInvoker.isAccessible(c)) {

                           ^

tcl/lang/JavaInfoCmd.java:245: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

          if (!PkgInvoker.isAccessible(c)) {

                           ^

tcl/lang/JavaInstanceofCmd.java:55: cannot resolve symbol symbol  :
method isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (!PkgInvoker.isAccessible(cls)) {

                   ^

tcl/lang/JavaInvoke.java:115: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (!PkgInvoker.isAccessible(method.getReturnType())) {

                   ^

tcl/lang/JavaInvoke.java:170: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (!PkgInvoker.isAccessible(method.getReturnType())) {

                   ^

tcl/lang/JavaInvoke.java:394: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

      if (!PkgInvoker.isAccessible(cls)) {

                       ^

tcl/lang/JavaInvoke.java:423: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

    if (!PkgInvoker.isAccessible(field.getType())) {

                   ^

tcl/lang/JavaNewCmd.java:283: cannot resolve symbol symbol  : method
isAccessible (java.lang.Class)

location: class tcl.lang.reflect.PkgInvoker

      if (!PkgInvoker.isAccessible(componentType)) {

                       ^

38 errors

make: *** [tcljava.build] Error 1

=20

=20

Re: [tcljava-dev] JSR-000223 Scripting for the JavaTM Platform

[Larry W. V. <lv...@ca...>]

Wow - basing a java servlet scripting language on PHP 5 rather than
python or tcl.  Weird.
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

[tcljava-dev] JSR-000223 Scripting for the JavaTM Platform

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

Jacl developers may be interested in checking out this.

http://jcp.org/aboutJava/communityprocess/pr/jsr223/index.html


Bruce (aka swankguy)

Re: [tcljava-dev] Re: [tcljava-user] JACL - Urgent help to make a design decision!

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

On Tue, 14 Dec 2004 14:17:09 -0700
D.J.Hagberg <dha...@mi...> wrote:

> It sounds to me like what you really want is the TclJava package, not 
> Jacl.

Just to clear up the confusion here. The "Tcl/Java" package is a Tcl
package of Tcl commands that is supported by both Jacl and Tcl Blend.
Tcl Blend is the JNI based layer that supports loading a Java VM into
a Tcl process or loading Tcl into an existing JVM. Jacl is a set of 100%
pure Java code that implements a Tcl interpreter.

> Jacl is also a bit dated, supporting only up to around Tcl 8.0 features.
> You definitely do not want to use 
> Jacl if a major part of your code base uses Expect.

It is true that Jacl can't load C based Tcl extensions like Expect. It is
a bit misleading to say that Jacl supports only Tcl 8.0 features.
Jacl supports most but not all the Tcl commands. The features Jacl
does not support typically can't be implemented using the existing Java API.

cheers
Mo DeJong

Re: [tcljava-dev] JACL - Urgent help to make a design decision!

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

On Tue, 14 Dec 2004 17:34:51 -0200
"Fernando M. Dagostini" <fda...@uo...> wrote:

> We currently have a relatively large (12 Kloc) application 
> coded in Tcl/Tk/Expect or Expectix.
...
> Now, we are migrating parts of this larger system into a 
> newer one which is Java Client/Server based architecture _ 
> including Java/RMI for Client/Server communication.
...
> So, Jacl would be extremely useful in the sense that:
> 
> - Would save a  lot of effort w/o having to port the backend 
> code.
> - Clean design.
> - Would fit as a glove into the new Server system.

My take on this is that you will need to keep some of the
existing functionality in a C based Tcl shell. The kinds
of things that Expect does are not possible using the Java
API. Most of your application logic can be run inside your
Java environment using Jacl. As far as the GUI goes, you
might want to look into the Swank project, it implements
Tk style commands on top of Swing.

> 5 _ What are the licensing restrictions that may apply to 
> using Jacl in such a project?

No, see the license.terms file for the details.

> 6 _ Are there other implications that I should care about?

Well, Jacl code will run about 10x slower than Tcl code in
a C based interp because the C based interp has a built in
compiler. The big upside to using Jacl is that you can
easily do anything that can be done in Java and your
application will not crash.

I would read about Tcl Blend if I were you, but it seems
like this is a case where you want to move to an all Java
solution. The cool thing about Tcl Blend is that both
the Java interp and the Tcl interp exist in the same
process space, so communication is fast. The downside
is that loading Tcl Blend means you are no longer in
a 100% Java environment.

hope that helps
Mo DeJong

Re: [tcljava-dev] JACL - Urgent help to make a design decision!

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

On 14 Dec 2004, at 21:31, Georgios Petasis wrote:
> Why not loading a Tcl interp inside Java? I suppose you can write
> a small C extension that does basic stuff (like creating an interp &
> evaluating a string as code) and use swig to generate a JNI wrapper?

This is basically what TclBlend does, IIRC. Whether you load a Tcl 
interp into Java or load a JVM into Tcl you end up with the same 
situation - two interpreters communicating via some C glue.

Cheers,

Neil.

Re: [tcljava-dev] JACL - Urgent help to make a design decision!

[Georgios P. <pet...@ya...>]

Why not loading a Tcl interp inside Java? I suppose you can write
a small C extension that does basic stuff (like creating an interp &
evaluating a string as code) and use swig to generate a JNI wrapper?

George

----- Original Message -----=20
From: "Neil Madden" <ne...@cs...>
To: <tcl...@li...>
Cc: "TclJavaUsers SourceForge" <tcl...@li...>
Sent: Tuesday, December 14, 2004 10:00 PM
Subject: Re: [tcljava-dev] JACL - Urgent help to make a design decision!


Hello,

Some answers below

On 14 Dec 2004, at 19:34, Fernando M. Dagostini wrote:
   [...]
> Needless to say that our first thought was to port the GUI
> part of the application to the Java Client and reuse the
> backend part entirely, with little adjustments, in the
> Server. To accomplish this we would like to implement a
> collection of simple Java/RMI classes =96 basically to map
> remote client calls directly into Tcl procedures - and glue
> them to via Jacl.
>
> So, Jacl would be extremely useful in the sense that:
>
> - Would save a  lot of effort w/o having to port the backend
> code.
> - Clean design.
> - Would fit as a glove into the new Server system.
>
> --- Questions/Problems:
>
> 1 =96 Is this really an approach that Jacl can support.
>
> 2 =96 I=92ve noticed that the =93package=94 command =93=85completely
> implemented in Jacl.=94  as stated in the DIFFS.TXT file so, I
> am assuming that I can load the Expect extension by issuing
> the command =93package require Expect=94, is this correct?

I'm afraid not. Expect is a compiled extension for C-based Tcl. It
won't work with the pure-Java Jacl. You could use C Tcl/Expect as
before and use the TclBlend extension (part of the same project as
Jacl) which will allow you to load extensions written in Java into a
normal Tcl shell. This is essentially the reverse of the situation you
describe - instead of embedding Jacl into your application, structure
the Java parts of your application into packages which can be loaded
into Tcl via TclBlend.

Another alternative is to try and port the parts of your app that use
Expect to use Java or pure-Tcl/Jacl scripts. Depending on what you use
Expect for this could range from trivial to insanely
difficult/impossible. I don't know of any attempt to port Expect to
Java/Jacl, and I doubt it is even possible. From what I gather, Expect
does some very low-level magic, and it is quite likely that this sort
of control isn't available in Java.

[tcljava-dev] Re: [tcljava-user] JACL - Urgent help to make a design decision!

[D.J.Hagberg <dha...@mi...>]

It sounds to me like what you really want is the TclJava package, not=20
Jacl.

TclJava is a "normal" extension to the C-based Tcl, extending it with a=20=

set of java::* commands like java::new, java::call, etc.  It can be=20
used from Tcl to make calls on classes in Java libraries, e.g. to use=20
JDBC drivers from Tcl (or make RMI calls in your example below), mixed=20=

in with calls to other C-based Tcl extensions such Expect.

Jacl is a complete re-implementation of Tcl in Java.  It cannot use=20
C-based extensions such as Expect.  It is also a bit dated, supporting=20=

only up to around Tcl 8.0 features.  You definitely do not want to use=20=

Jacl if a major part of your code base uses Expect.

That said, the Tcl-level (calling Java from Tcl) commands and=20
Java-level library (calling Tcl from Java) is nearly identical between=20=

the two packages, thus the confusion, perhaps.

That said, you might consider *not* doing a direct binding between the=20=

Tcl back-end and the Java front-end.  You could run your Tcl back-end=20
in a separate process, exposing its set of functionality as a set of=20
SOAP interfaces (see the TclSOAP package), or a simple line-oriented=20
command socket.  Then create a small Java library that makes calls on=20
your Tcl back-end process, either over SOAP or the simple line-oriented=20=

command socket.

                             -=3D- D. J.

On Dec 14, 2004, at 12:34 PM, Fernando M. Dagostini wrote:
> I am about to make a high level design decision for a project
> in the company I work for.
>
> --- Brief:
>
> We currently have a relatively large (12 Kloc) application
> coded in Tcl/Tk/Expect or Expectix. The application provides
> a whole bunch of functionalities to the user via Tk widgets
> and accesses system resources in the backend including
> Socket, File Handling, Spawning external executables, etc.
>
> All this is part of a larger system in the Wireless CDMA
> network management.
>
> Then environment is Sun Solaris.
>
> --- Objective:
>
> Now, we are migrating parts of this larger system into a
> newer one which is Java Client/Server based architecture =96
> including Java/RMI for Client/Server communication.
>
> We have estimated that the application as is today is
> balanced between:
>
> - 1.5 Kloc of Tk front end code (GUI)
> - 10.5 Kloc of Tcl/Expect back end code
>
> in a single script file =96 yes, total of 12 Kloc in a single
> program file!...
>
> Needless to say that our first thought was to port the GUI
> part of the application to the Java Client and reuse the
> backend part entirely, with little adjustments, in the
> Server. To accomplish this we would like to implement a
> collection of simple Java/RMI classes =96 basically to map
> remote client calls directly into Tcl procedures - and glue
> them to via Jacl.
>
> So, Jacl would be extremely useful in the sense that:
>
> - Would save a  lot of effort w/o having to port the backend
> code.
> - Clean design.
> - Would fit as a glove into the new Server system.
>
> --- Questions/Problems:
>
> 1 =96 Is this really an approach that Jacl can support.
>
> 2 =96 I=92ve noticed that the =93package=94 command =93=85completely
> implemented in Jacl.=94  as stated in the DIFFS.TXT file so, I
> am assuming that I can load the Expect extension by issuing
> the command =93package require Expect=94, is this correct?
>
> 3 =96 I=92ve gone through all the commands mentioned in the
> DIFFS.TXT and found that, at least based on what is stated
> there, I can get around those commands listed in =93What
> Partially Works=94 with minor changes in the Tcl code.
>
> 4 - I=92ve tried step 2 above in a Jacl shell command line but
> it didn=92t work. If it should work what am I doing wrong?
>
> 5 =96 What are the licensing restrictions that may apply to
> using Jacl in such a project?
>
> 6 =96 Are there other implications that I should care about?
>
> Sorry for the long posting - we are really interested in
> using Jacl but the project is large enough to take high risks
> at this point.
>
> We appreciate your opinions/suggestions.

Re: [tcljava-dev] JACL - Urgent help to make a design decision!

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

Hello,

Some answers below

On 14 Dec 2004, at 19:34, Fernando M. Dagostini wrote:
   [...]
> Needless to say that our first thought was to port the GUI
> part of the application to the Java Client and reuse the
> backend part entirely, with little adjustments, in the
> Server. To accomplish this we would like to implement a
> collection of simple Java/RMI classes =96 basically to map
> remote client calls directly into Tcl procedures - and glue
> them to via Jacl.
>
> So, Jacl would be extremely useful in the sense that:
>
> - Would save a  lot of effort w/o having to port the backend
> code.
> - Clean design.
> - Would fit as a glove into the new Server system.
>
> --- Questions/Problems:
>
> 1 =96 Is this really an approach that Jacl can support.
>
> 2 =96 I=92ve noticed that the =93package=94 command =93=85completely
> implemented in Jacl.=94  as stated in the DIFFS.TXT file so, I
> am assuming that I can load the Expect extension by issuing
> the command =93package require Expect=94, is this correct?

I'm afraid not. Expect is a compiled extension for C-based Tcl. It=20
won't work with the pure-Java Jacl. You could use C Tcl/Expect as=20
before and use the TclBlend extension (part of the same project as=20
Jacl) which will allow you to load extensions written in Java into a=20
normal Tcl shell. This is essentially the reverse of the situation you=20=

describe - instead of embedding Jacl into your application, structure=20
the Java parts of your application into packages which can be loaded=20
into Tcl via TclBlend.

Another alternative is to try and port the parts of your app that use=20
Expect to use Java or pure-Tcl/Jacl scripts. Depending on what you use=20=

Expect for this could range from trivial to insanely=20
difficult/impossible. I don't know of any attempt to port Expect to=20
Java/Jacl, and I doubt it is even possible. =46rom what I gather, Expect=20=

does some very low-level magic, and it is quite likely that this sort=20
of control isn't available in Java.

>
> 3 =96 I=92ve gone through all the commands mentioned in the
> DIFFS.TXT and found that, at least based on what is stated
> there, I can get around those commands listed in =93What
> Partially Works=94 with minor changes in the Tcl code.
>
> 4 - I=92ve tried step 2 above in a Jacl shell command line but
> it didn=92t work. If it should work what am I doing wrong?
>
> 5 =96 What are the licensing restrictions that may apply to
> using Jacl in such a project?

Jacl, like Tcl, is BSD-licensed, so you can do pretty much whatever you=20=

like with it. There should be a license.terms or similar in the=20
distribution which gives the full license details. It's quite short :-)

>
> 6 =96 Are there other implications that I should care about?
>
> Sorry for the long posting - we are really interested in
> using Jacl but the project is large enough to take high risks
> at this point.

Somebody else might be able to fill in any gaps I've left in the above.

Cheers,

-- Neil
Neil Madden (ne...@cs...)
PhD Student, Intelligent Agents Group,
School of Computer Science & IT,
University of Nottingham. NG8 1BB. UK.=

[tcljava-dev] JACL - Urgent help to make a design decision!

[Fernando M. D. <fda...@uo...>]

Hi! All,

I am about to make a high level design decision for a project 
in the company I work for.

--- Brief:

We currently have a relatively large (12 Kloc) application 
coded in Tcl/Tk/Expect or Expectix. The application provides 
a whole bunch of functionalities to the user via Tk widgets 
and accesses system resources in the backend including 
Socket, File Handling, Spawning external executables, etc.

All this is part of a larger system in the Wireless CDMA 
network management.

Then environment is Sun Solaris.

--- Objective:

Now, we are migrating parts of this larger system into a 
newer one which is Java Client/Server based architecture =96 
including Java/RMI for Client/Server communication.

We have estimated that the application as is today is 
balanced between:

- 1.5 Kloc of Tk front end code (GUI)
- 10.5 Kloc of Tcl/Expect back end code

in a single script file =96 yes, total of 12 Kloc in a single 
program file!...

Needless to say that our first thought was to port the GUI 
part of the application to the Java Client and reuse the 
backend part entirely, with little adjustments, in the 
Server. To accomplish this we would like to implement a 
collection of simple Java/RMI classes =96 basically to map 
remote client calls directly into Tcl procedures - and glue 
them to via Jacl.

So, Jacl would be extremely useful in the sense that:

- Would save a  lot of effort w/o having to port the backend 
code.
- Clean design.
- Would fit as a glove into the new Server system.

--- Questions/Problems:

1 =96 Is this really an approach that Jacl can support.

2 =96 I=92ve noticed that the =93package=94 command =93=85completely 
implemented in Jacl.=94  as stated in the DIFFS.TXT file so, I 
am assuming that I can load the Expect extension by issuing 
the command =93package require Expect=94, is this correct?

3 =96 I=92ve gone through all the commands mentioned in the 
DIFFS.TXT and found that, at least based on what is stated 
there, I can get around those commands listed in =93What 
Partially Works=94 with minor changes in the Tcl code.

4 - I=92ve tried step 2 above in a Jacl shell command line but 
it didn=92t work. If it should work what am I doing wrong?

5 =96 What are the licensing restrictions that may apply to 
using Jacl in such a project?

6 =96 Are there other implications that I should care about?

Sorry for the long posting - we are really interested in 
using Jacl but the project is large enough to take high risks 
at this point.

We appreciate your opinions/suggestions.

Regards,

Fernando M. Dagostini

Brazil Technology Center - Finatel
E-mail: fd...@no...

=0A =0A__________________________________________________________________=
________=0AAcabe com aquelas janelinhas que pulam na sua tela.=0AAntiPop-=
up UOL - =C9 gr=E1tis!=0Ahttp://antipopup.uol.com.br/=0A

[tcljava-dev] Request for Tutorials

[Fernando M. D. <fda...@uo...>]

Hi!

Yes, I=92m very interested in any tutorials.

Thanks and regards,

Fernando M. Dagostini
=0A =0A__________________________________________________________________=
________=0AAcabe com aquelas janelinhas que pulam na sua tela.=0AAntiPop-=
up UOL - =C9 gr=E1tis!=0Ahttp://antipopup.uol.com.br/=0A

Re: [tcljava-dev] TclBlend Core Dump

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

On Wed, 25 Aug 2004 14:06:25 -0700 (PDT)
Bruce Chidester <bru...@ya...> wrote:

> 
> Thank you for your response and willingness to help.
> 
> I have this problem in a very small box. 
> 
> Behavior:
> 
> When making a Tcl "package" and a command extension using an outside SNMP implementation, the command causes a core dump. The same implementation in JACL works fine. I reduced the problem to a few dependencies in the Java made package. They are:

Here is the crash I got when I tried your example:

Exception in thread "main" java.lang.NoClassDefFoundError: snmp/SNMPsample
JavaCmdProc : unexpected pending exception
SIGABRT 6 (*) abort process
        stackpointer=0xbfffe48c

Full thread dump Classic VM (J2RE 1.3.0 IBM build cxdev-20000502, native threads):
    "Finalizer" (TID:0x40408708, sys_thread_t:0x829a9d0, state:CW, native ID:0x1005) prio=8


The problem in this example is that the class should be defined in a dir named snmp
not in the same dir. I assume you built with "javac *.java" and it put the class files
in the current dir.

You can work around the crash like so:

% javac -d tmp PTLCommands.java SayhelloCmd.java SNMPsample.java
% find tmp
tmp
tmp/PTLCommands.class
tmp/SayhelloCmd.class
tmp/snmp
tmp/snmp/SNMPsample.class

Then change the a.tcl file to:

java::load -classpath tmp PTLCommands

That should avoid the crash, getting the code to not crash in the first place
is another issue, one that I will have to look into more.

cheers
Mo

[tcljava-dev] TclBlend Core Dump

[Bruce C. <bru...@ya...>]

Thank you for your response and willingness to help.

I have this problem in a very small box. 

Behavior:

When making a Tcl "package" and a command extension using an outside SNMP implementation, the command causes a core dump. The same implementation in JACL works fine. I reduced the problem to a few dependencies in the Java made package. They are:

Use the package command in Java

Throw an exception



Files:

Filename: PTLCommands.java

import tcl.lang.*; 

public class PTLCommands extends Extension {

public void init(Interp interp) {

interp.createCommand("sayhello", new SayhelloCmd());

}

}

Filename: SayhelloCmd.java

import tcl.lang.*;

import snmp.*;

class SayhelloCmd implements Command {

public void cmdProc(Interp interp, TclObject argv[]) {

try {

SNMPsample comInterface = new SNMPsample();

}

catch(Exception e) {

}

}

}

Filename: SNMPsample.java

package snmp;

import java.net.*;

public class SNMPsample {

public SNMPsample() 

throws SocketException {

}

}

Filename: a.tcl

package require java

java::load -classpath . PTLCommands

Steps:

Get to the tclsh prompt

%source a.tcl

%exit

A core dump is produced. I suspect that the Tcl package command and the Java package command are conflicting. I am under the impression that the TclBlend environment allows for Java and tcl commands to co-exist.


		
---------------------------------
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.

[tcljava-dev] Swank 2.1.3

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

Swank 2.1.3 is now available and is generally running much better than 
previous versions.  You can now directly execute Swank via Java Web 
Start.  I've put up a few example scripts and the tkcon console of 
examples of running Tcl scripts via Java Web Start.  I think this is a 
fairly cool way to deliver applications.


http://www.onemoonscientific.com/swank/index.html

Major changes are summarized here (more detail in the ChangeLog):

Now supports a slightly modified version of tkcon.
Java Web Start version now available at the swank site
Shear and Rotate affine transforms added to most canvas items
Added support for "-state" attribute of canvas items
Added smooth capability to canvas lines
Added "search" subcommand to text widget
Added support for bindtags  and event command and virtual events.

Getting tkcon to work also required a few changes in Jacl.  I'll post 
these changes within a few days.  The jacl.jar and tcljava.jar that 
come with the Swank download have these changes, as do the versions 
installed by Java Web Start.



Bruce A. Johnson, President
One Moon Scientific, Inc.
839 Grant Ave.
Westfield, NJ 07090

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

[tcljava-dev] Request for Tutorials

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

Forward from Gerald W. Lester <Ger...@co...>

We've received some requests for a "Using Java and Tcl together" (i.e. 
JACL and TclBlend) tutorial for the 2004 conference.

Anyone interested?

[tcljava-dev] Re: [tcljava-user] Jacl Status Questions/Survey

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

On Thu, May 13, 2004 at 11:12:07PM -0400, Jeff Sturm wrote:

> Performance was a key consideration.  Our local Jacl build runs typical
> tcl scripts about 2-3 times slower than a native tclsh (and about 20x
> faster than an unmodified Jacl release).  To achieve this we replaced all
> of the parser and expression processor.  Consequently it is not 100%
> compatible with the released Jacl.

Wow, that's quite a performance boost.  What's incompatible with the 
stock release?  Any chance of your code being released?

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

Re: [tcljava-dev] Jacl Status Questions/Survey

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

On May 13, 2004, at 5:41 PM, Tom Poindexter wrote:

>
>
> 	
> I remember that you were doing some compiler work, any progress on 
> that?
> My compiler will require some minor changes to the core, simply making
> package level or private classes & methods public instead.  Otherwise, 
> I'm
> trying to write all of mine in Tcl, borrowing on others' nifty work.
>

I haven't had much time (no surprise) to do much more work on it 
lately.  I did enough to convince myself that it probably could be made 
to work.  I use BCEL (byte code engineering library, 
http://jakarta.apache.org/bcel ) to generate  a Java class with a 
method which implements the Jacl proc.  Fundamentally, it works, but 
there is a lot of work that needs to be done.  While I may hack a way 
at it a bit more, it's really a project that would benefit from someone 
that actually knew what they were doing.

On the other hand, the potential speed improvements are  great.
For example, see comments in Jeff Sturms message:

     "Our local Jacl build runs typical tcl scripts about 2-3 times 
slower
      than a native tclsh (and about 20x faster than an unmodified
     Jacl release)."

I really wonder if given the potential value in doing this if the 
companies involved (including my own) in using Jacl couldn't get 
together and coordinate among themselves to get this done.  Perhaps 
this could be done by jointly hiring a contractor to do this (any 
volunteers with the skills?).  Alternatively, I wonder if this would be 
a good project for an academic group interested in Java and compilers.  
This might make a good project for someone working on a masters degree.

Bruce






> -- 
> Tom Poindexter
> tpo...@ny...
> http://www.nyx.net/~tpoindex/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>

Re: [tcljava-dev] Jacl Status Questions/Survey

[Larry W. V. <lv...@ca...>]

From: "Steve Carter" <st...@su...>

> So Guido is actually a suite of new commands that we have added to Jacl to
> create Swing UI components.  in a niche product.

Mr. Carter, has any of your staff compared your Guido with 
Bruce Johnson's Swank project ( http://www.onemoonscientific.com/ ).

-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

RE: [tcljava-dev] Jacl Status Questions/Survey

[Steve C. <st...@su...>]

Bruce,
	I guess you are trying to get a feel for the usage profile of Jacl so I
thought I should respond.

I work for Surpac Minex Group (SMG - www.surpac.com). We develop and sell
technical software used by Surveyors, Geologists and Mining engineers. The
software is used for orbody modelling, mine design and engineering,
surveying applications and other matters related to the earth resource
industries. If you want more info visit our web site at the above address.

Since 2000 our software has used Jacl as a key component of user interface
development, which probably seems very strange I'll admit. I'll explain a
little so it makes sense, I hope.

A major re-engineering exercise took place from 1998 to 2000 implement major
architectural changes to implement a client/server model to modernise the
sofwtare which began life in 1982 but has been through a number of previous
rewrites to 'keep up with the competition'. Notable among these was the
implementation of a client/server model so the application servers could be
hosted on a platform independent of the client user interface. This was
successful and we now have a teamwork model, admittedly still not being
actively used, that permits a 3D shared workspace for editing and viewing by
any number of users connected to a single application server. Connections to
the application server are across a TCP/IP connection.

Of course the software also works (and is actually used almost exclusively
in this mode at present) in a standalone single client configuration where
the application server and user interface client are hosted on the same
platform and in this mode of operation it appears like any other piece of
dektop productivity software, even though the client/server model is still
used to communicate and pass data between application server and UI client.

Jacl fits in to the UI client component which by now you must have guessed
is implemented in Java. Java of course was chosen for the write once run
anywhere capability, even though we only support M$ operating systems at
this time. We felt it insulated us somewhat from the sometimes unpredictable
decision making process at M$ as well as providing the capability to deploy
it to any platform that supported Java.

The UI is developed using Swing components. Rather than require our
development team to code directly in Swing, which can be nasty, and also
because the majority of development is in C++, we wanted to insulated
application development as much as possible from the vagaries of Swing. For
perhaps 80% of application development this is feasible because the UI
components are relatively static dialogues that simply obtain a number of
input parameters from users.

Most dialogues are therefore reasonably simple and static in design. At the
core of the UI module is a piece of technology that we call Guido.
Apparently it stands for Graphical User Interface Design Objects, or so
someone claims.

Insulating the majority of our development team from the nitty gritty of
Java/Swing has been achieved (and has been very successful) by implementing
a Guido as a scripting solution. This is where Jacl comes in to play.

So Guido is actually a suite of new commands that we have added to Jacl to
create Swing UI components. At teh back of this is a module that deals with
client/server communication so that when the "Apply/OK"  button is pressed
on forms the entered parameters are packed up and transmitted to teh server
where there is a nice clean API for applications to retrieve parameters and
pass them on to the processing modules.

Examples of commands added to Jacl include:
- GuidoField
- GuidoComboBox
- GuidoPanel
- GuidoCheckBox
- GuidoPanel
- GuidoMenu
- GuidoMenuItem
- GuidoToolbar
- GuidoExecServer (to execute a server side function and return parameters
to the client)
- there are many, many more.

Mostly the Guido commands are a thing layer on top of Swing components and
permit probably 95% of user interface components to be defined using
scripts. This seems to have reduced overheads substantially in the
development of user interface components. It also provides a third party
development environment for users and other software developers to write
product extensions to teh core software using the same UI and make them
appear indistinguishable from core components developed by SMG.

Hopefully this gives an idea of how we are using Jacl. You could argue that
there are other ways we could have achieved this but at the time 1998-2000
there was no viable UI that could be driven from Jacl so we came uo with
this solution and it has stood up remarkably well. The fact that you can
call Java methods directly from Jacl permits us to code in Java/Swing
directly when it is expedient.

We aren't doing any development on the core of Jacl at all. Over teh last 4
years even though it has been static, we've found it to be perfectly
adequate for our needs. It is unlikely that we will need to do any work
directly on Jacl in the forseeable future. We will probably continue to
extend the Guido commands that we added as circumstances require it.

It would be good to see Jacl used some more but I don't know that we have
anything to offer other than an example of how it can be used to good effect
in a niche product.

If you have any further question please email me and I'll do my best to
answer them.

Regards,
Steve Carter
Director, Research & Development
Surpac Minex Group
PH +61 7 49261995



-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Bruce
Johnson
Sent: Friday, 14 May 2004 6:27 AM
To: tcl...@li...;
tcl...@li...
Subject: [tcljava-dev] Jacl Status Questions/Survey



I'm curious about the state of Jacl.  I myself think it's the best
thing since sliced bread and am fairly committed to using it in some of
my projects.  On the other hand, there doesn't seem to be much activity
on the mailing list or cvs repository these days.  I thought I'd see if
people would actually respond to a few questions.

1) Is anyone doing active development on Jacl itself?

2) Is anyone planning on doing development on Jacl in the future?

3) Is anyone actively using Jacl in projects?

4) Would anyone be interested in having some Jacl/Swank presence at the
upcoming Tcl/Tk 2004 conference (talks, tutorials, BOFS)?

5) Any thoughts on promoting the use of Jacl?


Thanks for any feedback.

Bruce





-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] Jacl Status Questions/Survey

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

On Thu, May 13, 2004 at 04:27:21PM -0400, Bruce Johnson wrote:
> 
> I'm curious about the state of Jacl.  I myself think it's the best 
> thing since sliced bread and am fairly committed to using it in some of 

Agreed.  I seem to use Jacl quite a bit, but mostly in a testing and 
support role.  It's invaluable for me in prototyping some Java code on
the fly before committing the effort to solidify in Java.


> my projects.  On the other hand, there doesn't seem to be much activity 
> on the mailing list or cvs repository these days.  I thought I'd see if 
> people would actually respond to a few questions.
> 
> 1) Is anyone doing active development on Jacl itself?
> 

I've posted a few fixes, and some feature 'improvements'.  I think a few of 
fixes got in, but not my 'improvements'.  My most recent patch, several months
old now for a exception raising bug, is still not in CVS.  


> 2) Is anyone planning on doing development on Jacl in the future?
> 

I'm not doing much 'core' work other than fixing bugs when I find them.
I also pretty much finished up my 'hyde' extension, but haven't yet 
published the current version.  

Some other things I'd like to do are:

 - implement 'fileevent', 'lset', other newer Tcl commands.
 - port as much of tcllib to a 'jacllib' as possible.
 - drop in a new regexp engine, likely the apache/oro one with extended RE's.
 - experiment with a Tcl to Java compiler, I've started on some initial code.
 - profiling to find and hopefully fix some interperter hot spots.
 - create a 'Jaclkit' environment, that bundles Jacl jars + application source
   into a single .jar file, so you can 'java -jar foo.jar' to run your app.
	
I remember that you were doing some compiler work, any progress on that?
My compiler will require some minor changes to the core, simply making 
package level or private classes & methods public instead.  Otherwise, I'm
trying to write all of mine in Tcl, borrowing on others' nifty work.


> 3) Is anyone actively using Jacl in projects?
> 

Only internal projects, one with Swank :-).  I mostly use Jacl for 
testing (JUnit is the wrong tool IMHO, but hard to convince the Java only
crowd at my office.)  I've built a set of Jacl scripts that drive 
performance testing of my company's J2EE product.


> 4) Would anyone be interested in having some Jacl/Swank presence at the 
> upcoming Tcl/Tk 2004 conference (talks, tutorials, BOFS)?
> 

I'd just like to make it to N.O. for the conference, it's a slim chance 
at the moment.  Having a Jacl presence might make a slightly easier sell to
my company to send me, but that's still a stretch for me at the moment.

> 5) Any thoughts on promoting the use of Jacl?
> 

In the open source world, releasing early and often seem to be one of the keys
to exposure.  Of course that means having a fair amount of time to devote to
it, fixing bugs, adding features.  I can't fault anyone else at this, 
as I myself can't devote much time.  Not enough hours in the day to do
it all.  

Perhaps some more noise on comp.lang.tcl from the Jacl folks.  


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