> > So add it. Would something like this work? I am not sure where
> > you would get the executable name, perhaps you can just use "java".
>
> Well that is the problem. The executable is "java", which does not help
> because your Tcl lib is not in the jre distribution.
I guess I don't follow. Scott, do you know what is up with
this function? How and Why would I know where the Tcl executable
lives? Heck, there might not even be a Tcl executable. I might
only have the Tcl and Tcl Blend .dlls installed.
> > I don't follow. When the call to java::new returns a TclObject
> > it should have a ReflectObject internal rep. You then set the
> > variable x so that it holds the TclObject. At that point,
>
> It may not be that simple. "set x [...]" does not always translate to just
> two steps as you described.
>
> It is a text script being interpreted by Tcl. Tcl may compile it into some
> byte code or may interpret it as is. There can be many steps during the
> runtime in the C between "java::new" and "set x". One of these steps may
> turn the original ReflectObject into just a string.
>
> Before I gave on using the ReflectObjects, I ran into this type of problem.
> I was able to track down this behavior with the help of a C debugger on Tcl
> 8.3.1. Maybe it has something to do with how the byte compiler works. That
> may explain why people don't see this in Jacl or when run the command
> interactively.
Please provide an example where the internal rep get hosed inbetween
the call to java::new and the call to set. This should never happen.
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
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]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
