[Tcl Java] Interp.evalURL() made public
Can I request that the method Interp.evalURL() be made public? Perhaps there's another way to accomplish the equivalent functionality or some reason it's not already? --- Thomas McKay Manager, Software Development Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 4001 Weston Parkway, Suite 200 Cary, NC 27513 919-854-7500 x103 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
[Tcl Java] compiling tcljava
Hack... hack... hack... I plow on... Okay, I never could get configure to successfully run Test.java. Finally got it to compile after much hacking, but never run. So I took out the whole java test section of configure and finally got a Makefile. Several problems with the Makefile, though: 1) The classpath is being built with ':'s not ';'s. I'm on NT so this is a no-no. I assume that this is something I've set up wrong where? 2) There are places in the Makefile where paths are specified as "//e/App..." instead of "e:/App..." which causes failures. I'm using the cygnus tools. 3) The line in the Makefile @echo "# Making tcljava.build" gives me an error about an unterminated quoted string. Not sure why. Am I just being clueless here? That said, it appears that I have built jacl.jar and tcljava.jar successfully. --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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
[Tcl Java] compiling jacl
Okay, just using the configure script that existed already I get the following error about not being able to compile test program Test.java. Anyone have any pointers? caffeine:mckay://e/Applications/jacl/sourceforge/tcljava> configure --enable-jac l --without-jikes Makefile.in configure: WARNING: you should use --build, --host, --target srcdir is //e/Applications/jacl/sourceforge/tcljava checking for javac... //e/Applications/jdk1.3.0rc3/bin/javac checking for zip or jar files to include on CLASSPATH... //e/Applications/jdk1.3 .0rc3/jre/lib/rt.jar checking to see if the java compiler works... yes Java found in //e/Applications/jdk1.3.0rc3 checking type of jvm... jdk checking java API version... 1.3 checking for java... //e/Applications/jdk1.3.0rc3/bin/java checking for java_g... no checking for javah... //e/Applications/jdk1.3.0rc3/bin/javah checking for jar... //e/Applications/jdk1.3.0rc3/bin/jar checking for jdb... //e/Applications/jdk1.3.0rc3/bin/jdb checking for ddd... no checking for gdb... /Applications/cygnus/cygwin-b20/H-i586-cygwin32/bin/gdb checking the Java compiler... configure: error: Could not compile simple test pr ogram Test.java with //e/Applications/jdk1.3.0rc3/bin/javac caffeine:mckay://e/Applications/jacl/sourceforge/tcljava> --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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
[Tcl Java] autoconf 2.14
Can someone send me a pointer to where I can download autoconf 2.14. I just checked out tcljava from sourceforge and would like to make it. There aren't any instructions on doing this so I am assuming that I: 1) autoconf configure.in 2) configure 3) make --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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
[Tcl Java] tracing a proc
Is there a way to trace changes to a proc? I'm using Jacl and the Interp.traceVar() which seems to work fine for vars bug redefining a proc doesn't result in a call to the VarTrace class. --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Small test case
But let's assume that I do indeed want the most derived class.
I have written a generic database system, for example, which holds objects
of type DbObj. DbObj has a method in it like this:
public TclObject enableTclObject(Interp interp) {
if ( __tclObject == null ) {
try {
__tclObject = ReflectObject.newInstance( interp,
this.getClass(), this );
__tclObject.preserve();
} catch ( TclException e ) {
__tclObject = null;
}
}
return( __tclObject );
}
If I change this.getClass() to DbObj.getClass(), then the Tcl objects
returned from this method will only have DbObj's methods and fields exposed,
right?
This is, however, a utility method and I don't want to force every single
object that will eventually be added to the system to copy this code simply
to replace the "DbObj.getClass()" with "ExtendedDbObj.getClass()".
I *want* ExtendedDbObj's (and all other classes' derived from DbObj) methods
and fields exposed. Yes, even in the case of C -> D -> E -> F -> G.
Now, given that... what is fatal about this.getClass()? If it simply the
case that the user would have to explicitly use a method signature for
java::call, that's fine with me. If it means that their extension might
break my Tcl code, I see your point and agree... but is it programatically
*fatal*.
Let's say that I do change this.getClass() to DbObj.getClass(). Would this
mean that
% set obj [some-func-to-get-an-extended-object]
java0x8a
% $obj someExtendedFunc
would change to
% set obj [some-func-to-get-an-extended-object]
java0x8a
% set eobj [java::cast ExtendedDbObj $obj]
% $eobj someExtendedFunc
If that's the case, I agree with you completely that from a long-term
perspective it would be better for me to call DbObj.getClass(). Hmmm
sounds like I've convinced myself you're right.
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 29, 2000 8:41 AM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] Small test case
>
>
> On Thu, 29 Jun 2000, Thomas McKay wrote:
>
> > As you know, Mo, I have also had a tough time figuring out what is *bad*
> > about passing in obj.getClass().
> >
> > I can understand if there are methods that you don't want to
> expose to the
> > user in the derived class. In your example, if I wanted to
> prevent C.exit()
> > from being callable I should pass in B.getClass()... right? (Would
> > java::cast allow me to cast the object to type C anyway?)
>
> No, you don't ever want to call getClass(), just pass in B.class.
> That will resolve to the java.lang.Class object for the class B
> at compile time. If you have a class that implements an interface
> I, then you would pass in I.class.
>
> > Does the bad stuff happen because non-public methods and fields become
> > exposed? Is there something *fatal* about it though? Does it cause an
> > exception somewhere?
>
> Yup. All the additional fields on the subclass get exposed if you
> call getClass(). This can hose up the automated method resolver
> because your subclass could introduce a new ambigious method signature.
> As soon as I get around to adding an automated field resolver, it
> could break that too :)
>
> > That's what I don't understand. In all my usages of
> > ReflectObject.newInstance() I *want* the most derived class, I
> do not want
> > the class that it extends from.
>
> I doubt that very much. You don't even know what the most derived
> class might be. If someone comes along and extends C later on,
> do you really want that to break your code?
>
> (from the example)
> B -> C
>
> (now lets say I added a few more derived classes)
> C -> D -> E -> F -> G
>
> I could add some overloaded methods in F that
> cause all your method invocations to break.
> Then what would you do?
>
> > I *want* the most derived class
>
> Do you really want G in the above example? I
> suspect that what you mean is that you want
> C instead of B.
>
> If you want B, pass B.class
> If you want C, pass C.class
> Just don't call getClass()
>
> Make sense?
>
> 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
[Tcl Java] Re: [Tcl Java] Small test case
As you know, Mo, I have also had a tough time figuring out what is *bad*
about passing in obj.getClass().
I can understand if there are methods that you don't want to expose to the
user in the derived class. In your example, if I wanted to prevent C.exit()
from being callable I should pass in B.getClass()... right? (Would
java::cast allow me to cast the object to type C anyway?)
Does the bad stuff happen because non-public methods and fields become
exposed? Is there something *fatal* about it though? Does it cause an
exception somewhere?
That's what I don't understand. In all my usages of
ReflectObject.newInstance() I *want* the most derived class, I do not want
the class that it extends from.
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 28, 2000 8:06 PM
> To: Dr Wes Munsil
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Small
> test case
>
>
> On Wed, 28 Jun 2000, Dr Wes Munsil wrote:
>
> > Yes, in Java, I need to know the class of an object in a
> vector, so I can cast it back
> > to that class if I need to call any of that class's methods.
> getClass() tells me exactly
> > that. So if that is incorrect in TclBlend, there must be
> something else going on.
>
> That is incorrect. The Class returned by getClass() is not always
> going to be the same as the class you would cast to. You need
> to pass the class you would have done the cast to to newInstance().
>
> > I vaguely see what you're driving at, but this example doesn't call
> > ReflectObject.newInstance() at all, so I'm not clear on how it
> applies to the
> > discussion. If h is set, not by calling a static method that
> does a Java new, but by
> > calling a Tcl extension that does a
> ReflectObject.newInstance(), then I would in fact
> > expect exactly that NEVER_CALL should be accessible via h,
> since the class of h is
> > Hashtable2.
>
> Of course, you would need to subst your own call to some Java
> method for the java::call I put in. The point is that the
> method signature is "Hashtable get()" not "Hashtable2 get()",
> so you should not be able to call the NEVER_CALL() method via h.
>
> > Mo, I'm sure you are frustrated at having to explain this over
> and over again, and I
> > apologize for being dense, but I am just not getting it. I
> think part of the confusion
> > stems from your use of the phrase "its most derived type." The
> only type that is not
> > "derived" from some other (I assume you mean extended) is
> Object, so all the guidance I
> > can deduce from that is to always specify Object in the
> ReflectObject.newInstance()
> > call.
>
> It seems clear that I am not explaining this properly.
> Here is an example inheritance relationship.
>
> Object -> A -> B -> C
>
> If you put an object of type B into a Java Vector, you would
> need to cast it back up to B when you extract it from the
> vector.
>
> Vector v = ...
>
> B b = (B) v.elementAt(0);
>
>
> Now lets say that instead of a B, you put a C into the
> vector. You could extract an object of type C with
> the exact same code because C extends B.
>
> Note that in this scenerio you would never call
> getClass() for anything, you would always need
> to know the types of the Object you are extracting
> from a Vector.
>
> Now lets say that type C defined an exit() method.
> This exit() method would just call System.exit(-1).
>
> class C extends B {
> private C() {}
>
> B getInst() {return new C();}
>
> void exit() {System.exit(-1);}
> }
>
> In regular Java code, you would
> not be able to invoke the C.exit()
> method (unless you called getInst()
> and did a cast up to C, but that
> is another story).
>
>
> Now lets look at the right and wrong
> way to reflect this class.
>
> (Wrong)
>
> Object o = ...
>
> ReflectObject.newInstance(interp, o.getClass, o);
>
> The above code would reflect it as an instance
> of type C. That means you could invoke the
> exit command from inside Tcl with "$o exit".
>
>
> (Right)
>
> Object o = ...
>
> ReflectObject.newInstance(interp, B.class, o);
>
> With this version, the object would be reflected
> as an instance of type B not C. That means the
> method exit() could not be called from the instance.
>
> This is almost exactly the same as:
>
> B b = (B) v.elementAt(0);
>
> The only diff is that you pass B.class to
> ReflectObject.newInstance() instead of
> casting to the given type.
>
>
> Also, you should note that is the type
> you are adding to the reflect table is
> an interface, a call to getClass()
> will not return the interface class
> object, it would return the most
> derived type (like C in the example).
>
> 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]
>
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] exec command
I think, actually, that in 1.2 at least if the System property "user.dir" is
set appropriately that is where the Runtime.exec() takes place. I modified
Interp.setWorkingDir() appropriately (which is called by CdCmd.java):
if (dirObj.isDirectory()) {
workingDir = dirObj;
System.setProperty( "user.dir", dirObj.getPath() );
} else {
throw new TclException(this,
"couldn't change working directory to \""
+ dirObj.getName() + "\": no such file or directory");
}
If this was the only problem with the Runtime.exec() this should solve it.
If I remember correctly, however, it was more complicated than that in early
versions of 1.2. Didn't it hang due to the I/O thread hanging?
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 13, 2000 7:59 PM
> To: Levine Justin-p94702
> Cc: '[EMAIL PROTECTED]'
> Subject: [Tcl Java] Re: [Tcl Java] exec command
>
>
> On Tue, 13 Jun 2000, Levine Justin-p94702 wrote:
>
> > Hello,
> >
> > I was using JDK 1.3, but it still wasn't working properly. I
> gave up and
> > just started using the Runtime class.
> > Thanks.
>
> I have never tested it under 1.3. The exec class has this huge hack
> in it to get around the fact that the exec() did not let you
> tell the system what directory to run the command from. There
> is no chdir() in Java, so the combo of these things makes it
> next to impossible to exec() correctly from a JVM. The new
> exec() API in 1.3 should fix this. Why don't you fix up
> the ExecCmd.java file for Jacl and send in a patch?
>
> 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
>
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
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] New 1.3 version is in the CVS
I do have the files mentioned (I did a clean checkout). Perhaps the win/makefile.vc is old? That's where oro.jar is being referenced. > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 30, 2000 2:47 PM > To: [EMAIL PROTECTED] > Cc: Jacl > Subject: [Tcl Java] RE: [Tcl Java] New 1.3 version is in the CVS > > > The new regexp impl is already included in the CVS. I would be willing > to bet that if you blow away your old checkout and start over, the > new regexp classes will show up. CVS is a little funky about grabbing > new files, you can also add the -d option to an update to get the > same effect. > > You should get these files. > > % find tcljava/ | grep regexp > tcljava/src/jacl/sunlabs/brazil/util/regexp/Regexp.java > tcljava/src/jacl/sunlabs/brazil/util/regexp/Regsub.java > > Mo Dejong > Red Hat Inc. > > On Thu, 30 Mar 2000, Thomas McKay wrote: > > > I just did a 'cvs checkout tcljava' and it fails to build. The > > jacl/tcl/regex dir is empty(?). Is there a new regular > expression package I > > should be picking up somewhere? > > > 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 > 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
[Tcl Java] RE: [Tcl Java] New 1.3 version is in the CVS
I just did a 'cvs checkout tcljava' and it fails to build. The jacl/tcl/regex dir is empty(?). Is there a new regular expression package I should be picking up somewhere? > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 23, 2000 5:37 PM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] New 1.3 version is in the CVS > > > The new 1.3 version of the Tcl/Java tools is starting to show up in the > CVS. The 1.3 version is for developers only, it is not "stable". > > There are some cool new features that folks might want to try out > including new regexp and regsub commands and a history command. > > To check the 1.3 version out of the cvs just do a "cvs update" > or a "cvs checkout" and you will get the new stuff. > > If you want to keep using the 1.2 version you need to use the > branch-1_2 tag to a checkout or update command. > > setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot > > # This will get Tcl/Java 1.3 > cvs checkout tcljava > > # This will get the "stable" 1.2 branch > cvs checkout -r branch-1_2 tcljava > > I also switched to a ChangeLog instead of the old changes.txt file > because the Tcl core is also doing that. > > Enjoy. > 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 > 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
[Tcl Java] Re: [Tcl Java] External classloader for JACL
Agreed, backward compatibility is not a valid objection, but backward functionality should be? could be? Your proposal sounds like a good idea. > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 02, 2000 6:04 PM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] Re: [Tcl Java] External classloader for JACL > > > Perhaps I was not being clear. I am proposing two changes. > > 1. Remove the "search for .zip and .jar files" on env(TCL_CLASSPATH) >feature. The fact that a use might accidently get .class files >from a .jar or .zip file is just plain wrong. > 2. Make a new env var called env(TCL_JARPATH) which is a list of >directories that will be searched for jar and zip files. > > So to sum up, env(TCL_CLASSPATH) would no longer be searched for jars > and only the directories listed in env(TCL_JARPATH) would be searched. > Of course, if you wanted to put the full path name of a .jar file on > the env(TCL_CLASSPATH) that would still be supported. Does anyone > see a problem with that? This would be going into 1.3 so > backward compatibility is not a valid objection. > > Mo Dejong > Red Hat Inc. > > On Thu, 2 Mar 2000, Thomas McKay wrote: > > > I actually like the feature of looking for and loading classes > from the jar > > files. As long as I can still do this through an alternative > method (such > > as TCL_CLASSPATH) it'll work. I can see the benefit of such a system. > > > > > -Original Message- > > > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, March 02, 2000 4:06 PM > > > To: [EMAIL PROTECTED] > > > Subject: [Tcl Java] Re: [Tcl Java] External classloader for JACL > > > > > > > > > Both Jacl and Tcl Blend already use a class loader called > TclClassLoader. > > > Is there a feature that you would like to add added to the > TclClassLoader > > > or are you looking to bypass it completely? I do not really > see anything > > > wrong with adding something to the TclClassLoader or replacing it > > > completely with something better. I really do not like the > current design > > > because as a programmer, you need to use the TclClassLoader > explicitly, > > > when this type of thing really should be done behind the scenes. I was > > > also planning on stripping out the "feature" of the Tcl Class > Loader that > > > automatically looks inside .jar and .zip files that appear on the > > > env(TCL_CLASSPATH). This makes the "worst case" lookup time depend on > > > the number of .zip or .jar files on the file system, which is really > > > ugly. Perhaps we should add a env(TCL_JARPATH) var instead? > > > > > > Mo Dejong > > > Red Hat Inc. > > > > > > On Thu, 2 Mar 2000, Vladimir Zamiatin wrote: > > > > > > > Hello! > > > > > > > > I'm using JACL in web environment. I wrote engine > > > > similar to JSP, which allows to embed Tcl scripts > > > > in HTML pages. I want to make use of an > > > > advanced classloader, provided by servlet runner > > > > which has possibility to check for modification > > > > of class or source java files in web-applications, > > > > and recompile/reload them on-the-fly. > > > > > > > > I suppose one essential feature is missing in JACL: > > > > an ability to use external class loader in interp. > > > > It would be an easy change to add this feature to > > > > JACL: > > > > > > > > Interp.setClassLoader(ClassLoader loader); > > > > Interp.getClassLoader(); > > > > > > > > And TclClassLoader can use this loader (if > > > > present in Interp) to load classes. For > > > > performance reasons it would be great if > > > > this external loader has priority upon standard > > > > class loading mechanisms. > > > > > > > > I beleive that this feature will improve > > > > JACL ability to be embeded into different > > > > applications and environments. > > > > > > > > Best regards, > > > > Vladimir. > > > > > > > > > > > > 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]
[Tcl Java] Re: [Tcl Java] External classloader for JACL
I actually like the feature of looking for and loading classes from the jar files. As long as I can still do this through an alternative method (such as TCL_CLASSPATH) it'll work. I can see the benefit of such a system. > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 02, 2000 4:06 PM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] Re: [Tcl Java] External classloader for JACL > > > Both Jacl and Tcl Blend already use a class loader called TclClassLoader. > Is there a feature that you would like to add added to the TclClassLoader > or are you looking to bypass it completely? I do not really see anything > wrong with adding something to the TclClassLoader or replacing it > completely with something better. I really do not like the current design > because as a programmer, you need to use the TclClassLoader explicitly, > when this type of thing really should be done behind the scenes. I was > also planning on stripping out the "feature" of the Tcl Class Loader that > automatically looks inside .jar and .zip files that appear on the > env(TCL_CLASSPATH). This makes the "worst case" lookup time depend on > the number of .zip or .jar files on the file system, which is really > ugly. Perhaps we should add a env(TCL_JARPATH) var instead? > > Mo Dejong > Red Hat Inc. > > On Thu, 2 Mar 2000, Vladimir Zamiatin wrote: > > > Hello! > > > > I'm using JACL in web environment. I wrote engine > > similar to JSP, which allows to embed Tcl scripts > > in HTML pages. I want to make use of an > > advanced classloader, provided by servlet runner > > which has possibility to check for modification > > of class or source java files in web-applications, > > and recompile/reload them on-the-fly. > > > > I suppose one essential feature is missing in JACL: > > an ability to use external class loader in interp. > > It would be an easy change to add this feature to > > JACL: > > > > Interp.setClassLoader(ClassLoader loader); > > Interp.getClassLoader(); > > > > And TclClassLoader can use this loader (if > > present in Interp) to load classes. For > > performance reasons it would be great if > > this external loader has priority upon standard > > class loading mechanisms. > > > > I beleive that this feature will improve > > JACL ability to be embeded into different > > applications and environments. > > > > Best regards, > > Vladimir. > > > > 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 > 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
[Tcl Java] FW: New MEMS Development Tools Available
Hello all! The project I've been using Jacl for, Catapult, has just been released! It is a MEMS-specific design tool. If you, or someone you know, is doing any work w/ MEMS pass this on to them. Couldn't have done it w/o Jacl!! Thanks! -Original Message- From: Microcosm [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 08, 2000 8:16 PM To: [EMAIL PROTECTED] Subject: New MEMS Development Tools Available To: MEMS Designers - and - Managers or Developers Considering MEMS Microcosm Technologies, Inc (http://www.memcad.com) the leader in software and services for MEMS product development announces new, easy-to-use development tools. Catapult MEMS layout editor that simplifies MEMS construction for you. Handles true curves necessary for MEMS designs. Includes parameterized layout generators to simplify device construction. See http://www.memcad.com/datasheets/catapult_s.pdf Register for a free Catapult layout editor!! See http://www.memcad.com/catapult_offer.html MEMS Designer Catapult layout editor plus 3-D modeling, visualization, and automatic meshing to let you easily prepare a model for simulation. Export to Microcosm analysis, simulation, and manufacturing verification tools or to 3rd party tools such as ANSYS. See http://www.memcad.com/datasheets/designer.pdf JumpStart A software-to-silicon solution for rapid prototyping of your MEMS concepts. Includes Catapult layout editor, tutorial, design kit for MUMPS fabrication process, and a slot on a Cronos Integrated Microsytems MUMPS fabrication run yielding 15 prototype chips. See http://www.memcad.com/products/jumpstart/index.html For information about how we can support your specific MEMS development needs, contact [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]). To remove yourself from this e-mailing list, contact [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) with the word UNSUBSCRIBE in the subject of the message. 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
[Tcl Java] RE: [Tcl Java] RE: ReflectObject problems
I did search for bugs on the JDC related to identityHashCode() and saw only
one that might have been applicable. It had to do w/ the JIT. I disabled
this, however, and the problem still appeared.
I will attempt to reduce the problem to one that is reproducible in
"straight" Jacl.
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 01, 2000 8:01 PM
> To: Thomas McKay
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] RE: ReflectObject problems
>
>
> Humm, without knowing exactly what command it fails on
> or what object is puking out, it is going to be hard to
> track this down. We need to trim this down to a very
> small example that can be run from a single directory
> with only a couple of source files. Typically trimming
> Tcl code out of your example until it works and then
> hitting undo is the best way to get a small example.
> You should also try using "regular" Java objects like
> java.lang.String in place of your own Java objects to
> see if you can create a "Tcl only" example that crashes
> without needing your Java classes (that would really help).
>
> Here is some Tcl psudo code for how it should work.
>
> For a given object (java0x1) of class
> java.lang.String, map the object id
> and it's reflected class to an
> entry in the Reflect Table.
>
> set roRep [java::new ReflectObject]
>
> $interp createCommand java0x1 $roRep
>
> set reflectIDTable(java0x1) $roRep
> set reflectObjTable(java.lang.String.[identityHashCode]) $roRep
>
> So when we search the table in findInReflectTable(), we simple
> look for a table match for the string
> "java.lang.String.[identityHashCode]"
>
> The "table entry did not match arguments" error can happen
> when the given mapping does exist in the table but
> the $roRep value at the mapping does not match the
> values passed in to the search (which should never happen).
>
> The only thing I can think of off the top of my head is that
> if something was wrong with the identityHashCode() method
> that would produce a duplicate identity string. The
> string for each Class + Object combo needs to be unique.
>
> Mo Dejong
> Red Hat Inc.
>
>
>
> On Tue, 1 Feb 2000, Thomas McKay wrote:
>
> > Here's a log file from the run. Note that I had to modify the
> debug print
> > statements in ReflectObject.java or it would be huge! I
> included the source
> > for your reference.
> >
> > Not sure what to look for. Could be a problem with
> > System.indentityHashCode() or the reflect objects useCount?
> >
> > Here's what I'm doing to cause the error:
> >
> > % set cs [cellsList] <-- sets cs to a list of drawing designs
> > % foreach c $cs {
> > cellOpen $c <-- open the drawing
> > write-xpm $c <-- write out an x pixmap
> > cellQuit <-- close the drawing
> > }
> >
> >
> > Here's the script for writing the pixmap. This is how the
> commands map to
> > reflect objects:
> > layer catapult.db.xy.layout.LayoutLayer
> > objSelect catapult.db.xy.layout.LayoutObjPolygon
> >
> > proc write-xpm { name } {
> >
> > set layerNames [layers]
> >
> > set fp [open "$name.xpm" w]
> > puts $fp "! XPM2"
> > puts $fp "16 21 [llength $layerNames] 1"
> >
> > set abc "abcdefghijklmnopqrstuvwxyz"
> > foreach layerName $layerNames {
> > set l [layer $layerName]
> > set line "[string index $abc [lsearch $layerNames
> $layerName]] c #"
> >
> > set color [$l getColor]
> > set r [java::call Integer toHexString [$color getRed]]
> > if { $r == "0" } then {
> > set r "00"
> > }
> > set g [java::call Integer toHexString [$color getGreen]]
> > if { $g == "0" } then {
> > set g "00"
> > }
> > set b [java::call Integer toHexString [$color getBlue]]
> > if { $b == "0" } then {
> > set b "00"
> > }
> >
> > append line "$r$r$g$g$b$b"
> > puts $fp $line
> > }
> >
> > for {set y 0} {$y > -21} {incr y -1} {
> > set line ""
> > for {set x 0} {$x < 16} {incr x} {
> > set obj [objSelect -query $x $y]
> > set l [$obj getLayer]
> > append line
[Tcl Java] ReflectObject problems
While creating numerous ReflectObjects w/in a Java command, I inconsistently
get a message
"table entry did not match arguments"
The error is thrown in ReflectObject.java when
if (found.javaClass != cl || found.javaObj != obj || found.ownerInterp !=
interp) {
Any idea what could cause this?
I have a tcl proc that repeatedly calls the java-implemented tcl command, if
that makes a difference.
---
Thomas McKay
Project Leader
Microcosm Technologies, Inc.
mailto:[EMAIL PROTECTED]
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
[Tcl Java] Re: [Tcl Java] Jacl in applet
Sorry, I'm a little pressed for time at the moment and honestly don't know if I still have the original to diff against. The problem boiled down to a security exception. The class Class is in a jar file that did not have the proper policy set. By using getClass(), the result would be from the Jacl jar file which had the proper policy. > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 17, 2000 1:29 PM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Jacl in applet > > > What was the problem you were running into? Would the applet fail to run > without the patch you suggest? Could you post a diff -u style patch > for the change you suggest? > > Mo Dejong > Red Hat Inc. > > On Mon, 17 Jan 2000, Thomas McKay wrote: > > ... > > > + Changed Class.class.getResourceAsStream() in Interp.java to > > getClass().getResourceAsStream(). > > > > So, it's definitely possible. > > > 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 > 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
[Tcl Java] Re: [Tcl Java] Jacl in applet
Actually, you can use Jacl in an applet; at least in Netscape. By using the Java 2 plug-in there is a finer-grained security mechanism called "policies." By setting the correct policies, an applet can get permission to read files from jars (such as init.tcl) and examine classes (like using java::*). Now, I have no idea how to automagically set these policies during applet install, etc. Oh, I did have to make one tweak to Jacl in order to source files from a jar. From my notes... + Changed Class.class.getResourceAsStream() in Interp.java to getClass().getResourceAsStream(). So, it's definitely possible. > -Original Message- > From: Lubos Vrba [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 17, 2000 10:55 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Jacl in applet > > > Mo DeJong wrote: > > > On Thu, 6 Jan 2000, Lubos Vrba wrote: > > > > > Hello *, > > > > This is a tricky issue. Jacl (using Tcl commands in an applet) > > works but the java::* commands do not. > > > > > in jacl web pages I've read that Jacl 1.25 won't work in browsers. > > > > There is nothing wrong with Jacl that we could fix to "support" > > applets. The "problem" is that the JVM inside Netscape's browser > > is totally busted. I have not tested the Microsoft JVM so I > > can not speak about that. > > > > > Is there some plans for future to support Jacl in applet? > > > > > > > thanks for any help. > > > > > > Lubos Vrba > > > > Mo DeJong > > Cygnus Solutions > > Thanks for answer. I'm still trying to find some workaround. > In FAQ is written: > > 1.For remote applets, both Netscape and IE disallow the > introspection of class > members. This makes it impossible to use any of the following commands: > java::new, java::call, java::prop, java::field. > > 2.You can install Jacl as a local Java package on your machine to > get around the > > restriction mentioned in (a), but then Netscape won't read any of the Jacl > library > scripts, such as init.tcl, because it doesn't allow your applet > to read from > local > disks. > > Can anybody say to me what does it mean 'install Jacl as a local > Java package'? > If it means place it in CLASSPATH, than I sign it and enable > access to read > sources will > everything work? > I just don't understand how this can get around using NN JVM.. > Am I wrong? > > Lubos > > > 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 > 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
[Tcl Java] RE: [Tcl Java] running jacl in an applet
Specifically, what are the problems? With the Java2 plugin and the new finer granularity of security via the policy mechanism, at first glance it appears that the problem reading init.tcl is correctable. Any thoughts on this? I am a complete novice in the area of writing applets and security issues, so please feel free to correct my optimism. :-) This is a high priority issue for me and I've been given permission to devote a solid two weeks to this issue! Anything's possible with that kind of time... right? > -Original Message- > From: Moses DeJong [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 24, 1999 10:03 AM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] Re: [Tcl Java] running jacl in an applet > > > There are "some problems" running Jacl as an applet, but I do not > think that using Tcl Blend inside the plug-in works at all. I could > be wrong about that, but I do not know of anyone that is using > Tcl Blend in the plug-in. By the way, these "problems" running Jacl > in an applet are not fixable because they are caused by bugs in > the JVM included inside the web browser. Running code in a browser > really seems like a cool feature, but it is nothing but pain for > a developer. > > Mo DeJong > > On Tue, 23 Nov 1999, Thomas McKay wrote: > > > So I see in the readme and notes in the code that there are > some problems > > currently in running Jacl in an applet. Has anyone out there > tackled this > > problem? Maybe I should use tclblend? Isn't that available as > a plugin? > > Would my Jacl code run unmodified in tclblend? (I have done absolutely > > nothing with tclblend.) > > > > Thanks! > > > > --- > > Thomas McKay > > > 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]'. > 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]'.
[Tcl Java] running jacl in an applet
So I see in the readme and notes in the code that there are some problems currently in running Jacl in an applet. Has anyone out there tackled this problem? Maybe I should use tclblend? Isn't that available as a plugin? Would my Jacl code run unmodified in tclblend? (I have done absolutely nothing with tclblend.) Thanks! --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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]'.
[Tcl Java] more on redirecting stdin/stdout
Okay, I found the archive at http://www.mail-archive.com/tcljava@scriptics.com/ . Here's what I'm trying to do... Some of my custom command extensions to Jacl generate textual output. Now right now they simply print it in a console area of my application. My goal is to use the Jacl test framework to "catch" this output and compare it to what is expected. Now since the commands are effectively calling puts rather than returning a result, is there any standard way in Jacl (Tcl) to trap this? The one thought I had is to write a special command that forces stdin/stderr to a string which is then returned. Maybe eval can already do this? --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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]'.
[Tcl Java] redirecting jacl channels
There was a note posted a while ago on how to redirect stdout and stderr in Jacl. I thought I had saved it... Is there an archive of this list? Can someone forward me a copy if they have it? --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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]'.
[Tcl Java] versioning of Jacl commands
What are the costs associated w/ call Extension.loadOnDemand() for the same class but with different command names. Any? Here's what I'm up against: I have literally hundreds of commands in my application. I'd like to rework some of them but must keep backward compatibility. I see two possibilities: 1) Rework the commands. At the same time, produce a set of stub classes matching the old ones that simply call the new class. 2) Write a bunch of Tcl procs that accomplish the same thing. In general though, does anyone have any clever ideas for versioning commands? --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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]'.
[Tcl Java] RE: [Tcl Java] namespace
Gotcha. The book I have Tcl/Tk by Welch has examples of namespace w/o the
'eval'. Is the book wrong? It says it describes Tcl 8.0. I just want to
know what Tcl book to recommend to customers.
Here's what I'm trying to do with namespaces; maybe someone has an
alternative that would work better: The application I wrote allows users to
open multiple "documents" (I use the term generically here) that may contain
Tcl vars and procs specific to the document. Since there's only one interp
these vars can conflict leading to inconsistent results. I thought that
perhaps the namespace feature would be useful in this situation. However,
I'd like to avoid the user from having to understand namespaces by hiding
them as much as possible. Some questions then...
1) Can variables be exported from a namespace in addition to procs? This is
to avoid having to explicitly say "foo::var1".
2) Is there a way to switch to a namespace so that all evals after then take
place w/in that namespace? I suppose I could simply wrap all user input in
"namespace eval foo { }".
> -Original Message-
> From: Moses DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 02, 1999 8:47 PM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] namespace
>
>
> On Tue, 2 Nov 1999, Thomas McKay wrote:
>
> Nope, you need to use "namespace eval {...}"
>
> Try this.
>
> % namespace eval foo {
> variable x
> set x 12
> }
>
> % set foo::x
> 12
>
>
> You can create a namespace like this "namespace eval foo {}".
>
> If you run into problems, please check to see if you code
> works in Tcl 8.X. If you find code that does not work the
> same as Tcl 8.X, I want to hear about it.
>
> later
> mo
>
> > Should the following work?
> >
> > namespace foo {
> > variable x
> > set x 12
> >
> > proc y { a } {
> >puts $y
> > }
> > }
> >
> > I get an unrecognized arg foo, should be eval, etc. Looking at
> the code it
> > sure seems like this won't work.
> >
> > How do I create a namespace then?
> >
> > ---
> > Thomas McKay
> >
> > Project Leader
> > Microcosm Technologies, Inc.
> > mailto:[EMAIL PROTECTED]
> >
> >
> > 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]'.
> >
>
>
> 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]'.
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]'.
[Tcl Java] namespace
Should the following work?
namespace foo {
variable x
set x 12
proc y { a } {
puts $y
}
}
I get an unrecognized arg foo, should be eval, etc. Looking at the code it
sure seems like this won't work.
How do I create a namespace then?
---
Thomas McKay
Project Leader
Microcosm Technologies, Inc.
mailto:[EMAIL PROTECTED]
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]'.
[Tcl Java] RE: [Tcl Java] more 1.2.4 questions
Ahh, I remember hearing this from you in the past. However, as then, I still don't get why it's bad to use the "most derived" class. Why wouldn't you want to give the user access to the DerivedFromHashtable (to use the example in the docs)? What if there are methods or fields in this derived class that you'd like to provide for the user? Is it simply a matter of security or integrity of the object or what? The call to ReflectObject.newInstance() in my case is in a base class that is then extended by other similar classes. What would be the difference between putting ReflectObject.newInstance( interp, this.getClass(), this ); in the higher level class where this.getClass() resolved to the subclass and putting ReflectObject.newInstance( interp, SubClass.class ); calls in each of the subclasses? > ACK, NO! Do not call this.getClass() to get the second argument > to the ReflectObject.newInstance() method. You need to use the > actual Java Class object that the instance will be reflected as. > For instance if you want to reflect a java.lang.String object > you need to call it like the following example. Using getClass() > seems like a good idea but you will end up shooting yourself in the foot. > See the docs for ReflectObject.newInstance() if you want a > detailed example of why that is so very wrong. > > obj = ReflectObject.newInstance( interp, String.class, "my string" ); > > > > tclObject = ReflectObject.newInstance( interp, > > this.getClass(), this ); > > tclObject.preserve(); >> 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]'.
[Tcl Java] RE: [Tcl Java] loading classes dynamically as commands
I think you're right. If the reload feature to java::load is there, that would be a plus. I'll play around a little bit more with java::load too. I submitted the code snippets more for sharing purposes than to suggest that it should be in a Jacl release. I enjoy learning from other people's approaches and thought my code might spark some ideas out there. :-) > -Original Message- > From: Moses DeJong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 28, 1999 11:28 AM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] loading classes > dynamically as commands > > > On Thu, 28 Oct 1999, Thomas McKay wrote: > > > After I asked the question I had some more time to poke around > in the Jacl > > src. No, it was never a feature it just seemed natural to me > that it would > > be, though. > > Are you saying that this "autoload of commands implemented in Java" > feature should be added to Jacl? I am not really sure that is such > a good idea. I take the view the Jacl should try to do things just > like Tcl when possible. Having some snazzy feature that works in > Jacl but not Tcl (and therefore Tcl Blend), seems like a step > backwards. > > > I'll include some code snippets below to illustrate what I am > doing. This > > was my thought: When a user types a command, say "MyCommand," > the interp > > first checks internally for a definition. Not finding it, it calls the > > unknown proc. The unknown proc attempts to resolve the name by first > > attempting to load a class of this name. If found, the class must, of > > course, be an extension of Command. If it's not or the class > is not found, > > the unknown proc then treats the command as an executable name > and attempts > > to run it. (At this point we're in the original unknown proc > provided with > > Jacl.) > > So is the point just to avoid the call to java::load? Why do you need > your own Java code, is there something that java::load did not do that > you needed. You can provide a -classpath argument to java::load. > > > This works out great, by the way. My application has a > interactive command > > line (wish-like). I've named the majority of the commands through the > > Extension feature. However, the user may right their own > commands to extend > > the functionality of the application. By removing the need for > an Extension > > for every Command, a class name becomes a command name. > > The other problem I have with your idea is that it would give people > the impression that putting classes in the default package was OK. > Perhaps a better approach would be to set it up so that people could > indicate "if a command is unknown look for an implementation of > the command with the package prefix X" > > So an unknown command "foo" with a package prefix "com.mo.unknown" > would look for a class "com.mo.unknown.foo". You could also have > a list of package prefixes to check for. > > The bottom line is that this seems like a feature that you might > want to add to your app, but I do not think everyone would want > it. You can define your own unknown command for your own > application so I would think that would be the best approach > to take. If you define your own unknown and then default to the > system unknown, your feature would work in Tcl Blend too. > > Also, you comment about being able to reload a .class file was > a good one. I was already planning on adding something like that > to the 1.3 version. > > later > mo > > > 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]'. > 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]'.
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] more 1.2.4 questions
How would I do it in Java? This is what I have now...
tclObject = ReflectObject.newInstance( interp,
this.getClass(), this );
tclObject.preserve();
Would it be as simple as
interp.renameCommand( tclObject.toString(), "rect20" );
Would I have to do an equivalent "rename rect20 {}" when I called
tclObject.release();
>
> % set o [java::new Object]
> java0x1
> % $o toString
> java.lang.Object@80d05fd
> % rename $o rect20
> % rect20 toString
> java.lang.Object@80d05fd
>
> The catch is that you need to delete this renamed object like so.
> % rename rect20 {}
> % unset o
> > >
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]'.
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] more 1.2.4 questions
Well, I was hoping to be able to supply a prefix to use in place of the "java0x". My average user would understand it more if they saw "rect20" or "polygon34". I'll poke around a bit and see how hard this would be to add. I'll try out the namespace commands. I'm not an experienced traditional-Tcl user so it's doubtful I'd notice subtle things not working. > -Original Message- > From: Moses DeJong [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 27, 1999 9:43 PM > To: [EMAIL PROTECTED] > Cc: Jacl > Subject: [Tcl Java] Re: [Tcl Java] more 1.2.4 questions > > > On Wed, 27 Oct 1999, Thomas McKay wrote: > > Well, you can rename reflect objects now (like java0x1) > but it is a little tricky because you can not use the > variable in a way that changes the InternalRep and > then use it like a Java object again. This is > actually the same as using a typed null reference, you just > need to make sure you don't convert it's InternalRep > to something other than a ReflectObject. > > > I believe there is a way now to associate a name with ReflectObjects > > although I've long since forgotten what it is. Anyone help? > > I hope so, it passes all the regression tests directly related to > namespaces so I think it is 100% working. If you find a case where > something works in Tcl but not Jacl I would like to know about it. > > later > Mo DeJong > > > Second, does namespace work completely? > > > > Thanks! > > > > --- > > Thomas McKay > > > > Project Leader > > Microcosm Technologies, Inc. > > mailto:[EMAIL PROTECTED] > > > > > > 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]'. > > > > > 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]'. > 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]'.
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] loading classes dynamically as commands
After I asked the question I had some more time to poke around in the Jacl
src. No, it was never a feature it just seemed natural to me that it would
be, though.
I'll include some code snippets below to illustrate what I am doing. This
was my thought: When a user types a command, say "MyCommand," the interp
first checks internally for a definition. Not finding it, it calls the
unknown proc. The unknown proc attempts to resolve the name by first
attempting to load a class of this name. If found, the class must, of
course, be an extension of Command. If it's not or the class is not found,
the unknown proc then treats the command as an executable name and attempts
to run it. (At this point we're in the original unknown proc provided with
Jacl.)
This works out great, by the way. My application has a interactive command
line (wish-like). I've named the majority of the commands through the
Extension feature. However, the user may right their own commands to extend
the functionality of the application. By removing the need for an Extension
for every Command, a class name becomes a command name.
Here's my unknown proc:
rename unknown unknown_original
set tcl_interactive 1
proc unknown {args} {
global classpath
set name [lindex $args 0]
set rtn [catch {cmdLoad -classpath [set classpath] $name} result]
if { $rtn == 0 } {
return [uplevel $name [lrange $args 1 end]]
} else {
#return [uplevel [concat unknown_original $args]]
return -code error $result
}
}
Note that the call to unknown_original is commented out simply because of
the exec problems in the past. I have not tried it w/ 1.2.4.
Here's the relevant source for the 'cmdLoad' command. In order to get it to
work, I had to copy the entire TclLoadClass file into a local class since it
is not public. Those are the only changes. The cmdLoad also has a -reload
option which allows an already-loaded class (or command) to be updated
*while running*. This is pretty handy during development of the command
itself. I haven't used it in quite a while, though, so can't vouch for it's
functionality.
import tcl.lang.*;
import java.io.*;
import java.util.*;
import java.util.zip.*;
public class CatLoadCommand implements Command {
private Argv __argv;
private ArgvOpt __optReload;
private ArgvOpt __optPath;
private ArgvOpt __optClass;
private ArgvOpt __optCommand;
public void cmdProc( Interp tclInterp, TclObject[] args )
throws TclException {
CatInterp interp = (CatInterp) tclInterp;
String className;
String commandName;
if ( ! parse( interp, args ) ) {
interp.setResult( false );
return;
}
className = __optClass.value.getString();
if ( ! __optCommand.found ) {
commandName = className;
} else {
commandName = __optCommand.value.getString();
}
try {
TclObject path;
if ( __optPath.found ) {
path = TclList.newInstance();
try {
TclList.append( interp, path,
TclString.newInstance( __optPath.value.getString() ) );
} catch ( TclException e ) {
//empty
}
} else {
path = null;
}
LocalTclClassLoader classLoader =
new LocalTclClassLoader( interp, path );
if ( __optReload.found && __optReload.value.getBoolean() ) {
classLoader.removeCache( className );
}
Class c = classLoader.loadClass( className, true );
interp.createCommand( commandName, (Command) c.newInstance() );
interp.setResult( true );
} catch ( ClassNotFoundException e ) {
interp.setResult( false );
throw( new TclException( interp, "class not found" ) );
} catch ( InstantiationException e ) {
interp.setResult( false );
throw( new TclException( interp, "instantiation" ) );
} catch ( IllegalAccessException e ) {
interp.setResult( false );
throw( new TclException( interp, "illegal access" ) );
} catch ( IllegalArgumentException e ) {
interp.setResult( false );
throw( new TclException( interp, "illegal argument" ) );
}
interp.setResult( true );
return;
}
protected boolean parse( CatInterp interp, TclObject[] args ) {
if ( __argv == null ) {
__argv = new Argv( interp.getSystem(),
"CatLoadCommand", "$Id: CatLoadCommand.java,v 1.4
1999/09/03 15:20:14 mckay Exp $" );
__optReload = new ArgvOptNArgsOpt( "Reload", "-reload [on | off]",
"Reload", "-reload", new ArgvValueBoolean() );
__argv.addOpt( __optReload );
__optPath = new ArgvOptVarArgs( "Class path", "-classpath $path",
"Class path", "-classpath
[Tcl Java] more 1.2.4 questions
I believe there is a way now to associate a name with ReflectObjects although I've long since forgotten what it is. Anyone help? Second, does namespace work completely? Thanks! --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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]'.
[Tcl Java] loading classes dynamically as commands
Okay, I finally have some time to upgrade to v1.2.4 of Jacl. Since v1.0, I had been loading classes dynamically as commands by overriding the unknown proc and using a copy of TclClassLoader to load the appropriate class. I'm guessing that this was simply a workaround from long ago. The basic problem is this: When the user types in a command and it is not recognized, the interpreter will go search the user's classpath for this command as CommandName.class and load it using TclClassLoader. What is the proper way to do this? --- Thomas McKay Project Leader Microcosm Technologies, Inc. mailto:[EMAIL PROTECTED] 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]'.
[Tcl Java] RE: [Tcl Java] TclJava user feedback needed.
As someone using Jacl in a commercial MCAD application... it's great! Honestly, I have absolutely no complaints and only praise for all involved in such a useful application of Java. The only misperception that people have when I describe Jacl (and Tcl) to them is that they think Tk is part of it. Since Tcl/Tk are so often spoken together it's easy to understand this. If Tk's functionality could ever be wrapped it'd be a sure success. My opinion, of course. > -Original Message- > From: Moses DeJong [mailto:[EMAIL PROTECTED]] > Sent: Sunday, October 17, 1999 3:52 PM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] TclJava user feedback needed. > > > Hi all. > > Cameron Laird and I are writing up an article about tcljava, and > we could use your help. We need some feedback on what people do > not like about Jacl or Tcl Blend. This includes things that > currently do not work the way you would like them, or features > that are lacking in the current version. Everything is "fair game", > so please flame away. > > thanks > Mo DeJong > > > 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/ > > 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/
[Tcl Java] interrupting an infinite loop
Ahhh users... what can you do? A not-so-uncommon programming error is to write a for loop that loops forever. Is there any mechanism to force the interpreter to stop evaluating? Can I force an error to be thrown some how? I'm using 1.1a1 but am working on upgrading the latest-greatest. Thanks, Tom begin:vcard n:McKay;Thomas tel;work:919-854-7500 x103 x-mozilla-html:TRUE org:Microcosm Technologies, Inc. adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Project Leader fn:Thomas McKay end:vcard
[Tcl Java] tcl question
The following does not parse in 1.1a1
proc foo {a b}{
return
}
"extra character after curly brace" (or some such message).
It was due to there being no space between the "}{". Is this a Tcl
limitation?
begin:vcard
n:McKay;Thomas
tel;work:919-854-7500 x103
x-mozilla-html:TRUE
org:Microcosm Technologies, Inc.
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Project Leader
fn:Thomas McKay
end:vcard
[Tcl Java] Re: How fast is Jacl?
I just ran a test of Jacl 1.1a1, 1.2.3, and 1.2.4 and they all had nearly identical results (+/- 0.1 seconds). (I'll be happy to test 1.1 if I can get a pre-built version.) My only guess is that a change I made between now and the last time I tested against 1.1 (which was the version I saw the speed hit in). One thing that I was doing was calling ReflectObject.newInstance() followed by preserve() for many objects. Perhaps it's here that things were slower? Tom begin:vcard n:McKay;Thomas tel;work:919-854-7500 x103 x-mozilla-html:TRUE org:Microcosm Technologies, Inc. adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Project Leader fn:Thomas McKay end:vcard
[Tcl Java] Re: How fast is Jacl?
I noticed a problem when switch from 1.1a1 to the next version (which was...?) in that source'ing files was orders of magnitude slower. Now, I didn't take the time to determine if it was the file sourcing itself of calling all of the commands (which were java extensions loaded on-demand) or what. I hope to have the time (don't I always!) to download the latest-greatest and try things out again soon. begin:vcard n:McKay;Thomas tel;work:919-854-7500 x103 x-mozilla-html:TRUE org:Microcosm Technologies, Inc. adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Project Leader fn:Thomas McKay end:vcard
[Tcl Java] debugger for tcl usable w/ jacl?
Is there a 'gdb'-ish debugger that could be used for Jacl? It would be powerful to allow my users to debug (step through and print vars) a tcl proc within my application. Any ideas? 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/
[Tcl Java] 1.1a1 vs 1.2.2 performance
Sourcing files in 1.2.2 seems remarkably slower than in 1.1a1. Are there specific changes that would cause this? 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/
[Tcl Java] Re: ReflectObject questions
Yikes! I've been using v1.1a1 and am now trying to use 1.2.2: None of the "java::" commands are available. Do I need to do something with BlendExtension? Tom 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/
[Tcl Java] ReflectObject questions
Hi!
In my Jacl application, users may write Tcl scripts to manipulate database
objects:
prompt% set o [createRect 0 0 20 30]
java0xcf
However, if a script is to be written that is associated with a specific
object, then that objects id (the java0xcf name) must be persistent and
stored when the db is saved. What I envision working well is:
prompt% set o [createRect 0 0 20 30]
rect0x01
Where the Java code would be something like:
tclObject = ReflectObject.newInstance( interp,
obj.getClass(),
obj );
tclObject.setRefID( "rect" + getNextCounter() );
Thus when the rectangle object is saved to the db, the reflect object name
("rect0x01") could be saved with it. Is there a way to do this?
By setting the ReflectObject's name, different objects could be swapped
in and out for the same reflect name.
Any thoughts on how best to do this within the scope of Jacl?
Of course I can always make my own mapping for my objects, but I'd like
to first try to stay within Jacl.
Tom
[Tcl Java] Re: cd / pwd
Well, what I did as a workaround was to set the system property "user.dir" in the interp. Then in my Java portions of the application that needed to access a file was use: new File( "name" ).getCanonicalFile(). The 'canonical' methods use the current value of "user.dir" to resolve the file name. Seems to work well. This way I can run the Jacl 'cd' command and have it apply to the application's workings. Any reason not to set "user.dir" in the interp? I guess the multi-thread issue is one. However, in my app which is heavily threaded I only use one Interp. I guess I could wrap the system's cd command with one of my own which set the system property. Tom 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/
[Tcl Java] cd / pwd
Is there a reason that the 'cd' and 'pwd' commands use a value within Interp rather than setting and getting the system property "user.dir"? I haven't tried, but I assume that if the user.dir property is adjusted then attempting to open a file from within the Java portion of the application will look in the current user.dir location. Tom 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/
[Tcl Java] Re: VerifyError
Well after some more web searching, I started to investigate the nesting
of throw/catch/finally and return statements. Ouch! Very painful. I
can't pin down the specific sequence but by simply removing the 'return'
within "try { try { } catch { return } } finally { }" solved the
problem. I assume this is a bug either in the JVM or compiler. I
haven't tried a different compiler (just downloaded jikes yesterday) yet
so I can't say.
Sorry for cluttering the tcljava email list with this java-specific
problem...
Tom
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/
[Tcl Java] RE: [Tcl Java] more on redirecting stdin/stdout
In most cases I do try to use setResult(). However, there are places where,
for example, progress information is displayed. This info is for the user's
benefit while the command is being executed. To wait until the command has
finished would defeat this purpose.
Good idea, though.
> -Original Message-
> From: Shawn Boyce [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 18, 1999 8:06 AM
> To: [EMAIL PROTECTED]
> Cc: Jacl
> Subject: [Tcl Java] Re: [Tcl Java] more on redirecting stdin/stdout
>
>
> Instead of doing puts, you should use the setResult() method.
>
> e.g.
>
> interp.setResult( "Result of the command" );
>
> The Jacl interpreter will then write the string to the console.
> You can also save the output of the command like this:
>
> set ret [my_custom_cmd arg1 arg2]
> if { $ret == "expected result" } {
> puts "test passed"
> } else {
> puts "test failed"
> }
>
> -Shawn
>
> Thomas McKay wrote:
>
> > Okay, I found the archive at
> > http://www.mail-archive.com/tcljava@scriptics.com/ .
> >
> > Here's what I'm trying to do... Some of my custom command extensions to
> > Jacl generate textual output. Now right now they simply print it in a
> > console area of my application. My goal is to use the Jacl
> test framework
> > to "catch" this output and compare it to what is expected. Now
> since the
> > commands are effectively calling puts rather than returning a result, is
> > there any standard way in Jacl (Tcl) to trap this?
> >
> > The one thought I had is to write a special command that forces
> stdin/stderr
> > to a string which is then returned. Maybe eval can already do this?
> >
> > ---
> > Thomas McKay
> >
> > Project Leader
> > Microcosm Technologies, Inc.
> > mailto:[EMAIL PROTECTED]
> >
> >
> > 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]'.
>
> --
> Shawn Boyce
> QCOM Inc.
> Email: [EMAIL PROTECTED]
> Phone: (732) 617-1970 x11
> Fax: (732) 617-1975
> Web: http://www.qcominc.com/people/shawn
>
>
>
> 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]'.
>
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]'.
