[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] 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: 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] 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: [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] 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] 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 { user input }".
-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] 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] 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]'.
[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] 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] 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] 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] 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] 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]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at
[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] 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] 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
