tcljava-dev

[tcljava-dev] Jacl Status Questions/Survey

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

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

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/

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

[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

[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/