On Mon, 26 Jul 1999 [EMAIL PROTECTED] wrote:
>
> Mo DeJong wrote:
> > This sounds like a good way to use Jacl.
There are examples included with the Jacl dist. Look in the demos
subdirectory. The demos come with a README file that tries to explain
what features the demos shows off. Those demos are really the best way
to learn about how things work (aside from just playing with your own
examples). There is also a lot of HTML documentation in the docs
subdirectory. The documentation describes the java::* commands and the
Java level API.
> Many thanks for the quick reply. I'm glad I'm on the right track
> here. One thing; most of the stuff, tutorials, etc, I've read seem to
> be about wrapping TCL around java objects (i.e. code the components in
> java, glue them together with TCL - a good approach, IMHO). Are there
> any tutorials/examples on the web that would cover embedding a JACL
> interpreter in a java application?
>
> > I am not sure what you mean by a "Tcl data structure", but I am assuming
> > you mean a hashtable (array).
>
> Well, an array of elements,
> one of which is an array of elements,
> one of which is an array of elements,
> one of which is an array of elements
That might be a good idea. You could avoid the overhead of calling
Java method by doing all of the conversion once at the begining.
You might also make users happier using a non-OO based scripting
interface. This is really a design issue so there is no "right" answer.
Keep in mind that there really is no "overhead" that you really need
to worry about on the processing side. Yes, Jacl might be "slow" in
the sense that it takes a lot of CPU cycles, but if your users can write
a custom script in 1/2 hour instead of 1/2 a day then who cares?
> Essentially, there's not much "object-ness" to the customer/info/
> detail/comments objects in this java program, and all of the data is
> strings, so it should be pretty easy to translate straight to TCL
> structures. I'm not sure how much overhead is involved in accessing
> java objects, from a JACL interp via the TCL/Java interface, which is
> why I asked which approach is desirable.
>
> > To be honest, I like the way the Tcl/Java interface gives me direct
> > access to an object using a script. [...] Keep in mind that you do
> > not need to pick one or the other, you can use both. You can make a
> > low level API that uses the Java objects directly and provide some
> > higher level Tcl wrappers for accessing the Java objects.
Well, no. The documentation and the demos are the only means to learn
how things work right now. Perhaps this should change in the future.
This might be a good way for Tcl/Java users to help out with the project.
If everyone wrote up a small example of how to do something and posted
it to a webpage, that might really help.
> I'm still learning my way around TCL (I foresee that changing in
> the near future :-). Is there any tutorial in particular you would
> suggest reading to get an overview of accessing java objects from a
> TCL script running inside an interp object instantiated in JACL?
>
> > Jacl does multithreading but only one interp per thread is allowed.
> > You can read up on some of the issues related to threading in the
> > paper I wrote for the 98 Tcl conference (See section 4.3.)
> >
> > http://www.cs.umn.edu/~dejong/tcl/paper.html (or)
> > http://www.cs.umn.edu/~dejong/tcl/paper.ps
Yup. That is the only really tricky part of Tcl/Java I have run into.
In Java, one needs to create a wrapper object and pass it into the Tcl
event queue in a thread safe way. There is also an example of the Java
code needed in the paper.
later
mo
> Hm... are you referring to this secton:
>
> "... The problem is that the interp.eval() method is not thread-safe. The
> only safe way to evaluate a Tcl command from a separate thread is to
> place that command into a thread-safe Tcl event queue. To do this,
> the synchronized method interp.getNotifier().queueEvent() should be
> invoked. This method uses the synchronization primitives provided by
> the JVM to ensure thread-safety within the Tcl event queue. The Tcl
> interpreter will then remove the event object from the queue and
> invoke its processEvent() method from the interpreter's main
> thread. Example 2 demonstrates how to safely evaluate a procedure from
> a separate thread."
>
> > I hope that helps.
>
> Most definitely.
>
> Steven J. Owens
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
----------------------------------------------------------------
The TclJava mailing list is sponsored by WebNet Technologies.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
A list archive is at: http://www.findmail.com/listsaver/tcldallas/
