> > So add it. Would something like this work? I am not sure where
> > you would get the executable name, perhaps you can just use "java".
>
> Well that is the problem. The executable is "java", which does not help
> because your Tcl lib is not in the jre distribution.
I guess I don't follow. S
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
>
> So add it. Would something like this work? I am not sure where
> you would get the executable name, perhaps you can just use "java".
Well that is the problem. The executable is "java", which does not help
because you
On Thu, 29 Jun 2000, Jiang Wu wrote:
>
> > -Original Message-
> > From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> >
> > You are using Tcl blend and Tcl loaded into a JVM right? I get the
> > feeling Tcl does not know how to find its startup scripts. What
> > happens when you do a "package
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
>
> You are using Tcl blend and Tcl loaded into a JVM right? I get the
> feeling Tcl does not know how to find its startup scripts. What
> happens when you do a "package require java"? This is strange
I have to set the TC
> > Care to submit some docs patches? We could also use some "Tcl/Java
> > in action" examples. Nice little examples that do something
> > cool and show how to use the java::* commands would really
> > be great. Would anyone be able to help with that?
>
> Well, I won't be the right person to writ
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
>
> Care to submit some docs patches? We could also use some "Tcl/Java
> in action" examples. Nice little examples that do something
> cool and show how to use the java::* commands would really
> be great. Would anyone be a
On Thu, 29 Jun 2000, Jeff Sturm wrote:
> Mo DeJong wrote:
> > Here is another example:
> >
> > import java.util.Hashtable;
> > public class Hashtable2 extends Hashtable
> > {
> > public static Hashtable get() {
> > return new Hashtable2();
> > }
> > public void NEVER_CALL() {
> > S
On Thu, 29 Jun 2000, Jiang Wu wrote:
> I just hope people realize that the reflected Java objects in Tcl are not
> the same as any other Tcl objects. The problem is that these reflected
> objects are presented as "normal Tcl objects". They are syntactically
> compatible with other Tcl objects.
I just hope people realize that the reflected Java objects in Tcl are not
the same as any other Tcl objects. The problem is that these reflected
objects are presented as "normal Tcl objects". They are syntactically
compatible with other Tcl objects. As a result, they are being used in the
same
On Thu, 29 Jun 2000, Jeff Sturm wrote:
> Interesting discussion... it seems as though TclJava tries to enforce
> type safety on Java objects. Other scripting add-ons I've seen and used
> for Java make no such attempt. For example, the default COM bindings on
> the MS VM permit invoking any publ
> > Well, if you really wanted a workaround, you could always unset the
> > variable in the after command :)
>
> 'unset' is there to simulate a local variable or temporary variable. It
> can't be moved into the after command. You don't need to 'unset' if you
> just put the whole thing inside a
I get a crash with
"Exception in thread "main" tcl.lang.TclRuntimeError: table entry did not
match arguments"
on Windows NT with Java version 1.3.0rc3
Bruce
> --
> From: Mo DeJong[SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 29, 2000 11:34 AM
> To: [EMAIL PROTECTED]
>
Interesting discussion... it seems as though TclJava tries to enforce
type safety on Java objects. Other scripting add-ons I've seen and used
for Java make no such attempt. For example, the default COM bindings on
the MS VM permit invoking any public method on a particular object, and
doesn't ha
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 29, 2000 8:58 AM
> To: Daniel Wickstrom
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Threading
> in tclblend.
>
> Do you mean each Tcl thread is going to need its own
Mo DeJong wrote:
> Here is another example:
>
> import java.util.Hashtable;
> public class Hashtable2 extends Hashtable
> {
> public static Hashtable get() {
> return new Hashtable2();
> }
> public void NEVER_CALL() {
> System.out.println("NEVER_CALL");
> }
> }
>
> % set h [java:
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 28, 2000 6:51 PM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] A Tcl
> or TclBlend pr oblem?
>
> Well, if you really wanted a workaround, you could alway
Test ran to completion with Sun's JDK 1.1.8 on Solaris, no errors.
Mo DeJong wrote:
> Now don't panic, but it looks like we have uncovered
> a serious JVM bug in Sun derived JVMs >= 1.2 that
> nukes the Tcl/Java reflect table. Lots of
> thanks go to Thomas McKay for tracking down and
> creating
On Thu, 29 Jun 2000, Daniel Wickstrom wrote:
> > "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> The startup stuff is kind of tricky because we need to support
> Mo> two different kinds of loading. Tcl Blend can be loaded from
> Mo> Tcl, whick will then load the JVM. Tcl Bl
Now don't panic, but it looks like we have uncovered
a serious JVM bug in Sun derived JVMs >= 1.2 that
nukes the Tcl/Java reflect table. Lots of
thanks go to Thomas McKay for tracking down and
creating a test case for this bug (it took months).
It looks like two different Java object are returnin
Thanks for the dialog. Changing o.getClass() to Object.class in my example made no
difference... the
occasional "invalid command name" error still occurred. (In changing an arbitrary Java
Vector to a
Tcl list, there is no other information that justifies identifying a specific class
other than
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> The startup stuff is kind of tricky because we need to support
Mo> two different kinds of loading. Tcl Blend can be loaded from
Mo> Tcl, whick will then load the JVM. Tcl Blend can also be
Mo> loaded from a JVM, this means Tc
On Thu, 29 Jun 2000, Thomas McKay wrote:
> But let's assume that I do indeed want the most derived class.
Seems kind of dangerous, but Ok.
> 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,
> rig
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 {
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 prev
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.
On Thu, 29 Jun 2000, Daniel Wickstrom wrote:
> I've been experimenting with integrating tclblend into aolserver, and
> after looking at the tclblend code, I'm a little puzzled about
> something. In javaCmd.c the variable java declared as type JavaInfo
> and currentEnv are declared as global var
I've been experimenting with integrating tclblend into aolserver, and
after looking at the tclblend code, I'm a little puzzled about
something. In javaCmd.c the variable java declared as type JavaInfo
and currentEnv are declared as global variables, yet I would think
that these two variables wou
On Thu, 29 Jun 2000, Dr Wes Munsil wrote:
> Mo DeJong wrote:
>
> > There is no "compile time" in Tcl, it is all dynamic, ...
>
> Exactly my point. Consider these two code snippets, which I assume you agree are
>correct uses
> of newInstance():
>
> B x = new C ();
> ReflectObject.newInstance (
28 matches
Mail list logo
