[Tcl Java] Interp.evalURL() made public

2000-10-31 Thread Thomas McKay

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] autoconf 2.14

2000-10-26 Thread Thomas McKay

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 jacl

2000-10-26 Thread Thomas McKay

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] compiling tcljava

2000-10-26 Thread Thomas McKay

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] Re: [Tcl Java] Small test case

2000-06-29 Thread Thomas McKay

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] RE: [Tcl Java] Re: [Tcl Java] exec command

2000-06-13 Thread Thomas McKay

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] External classloader for JACL

2000-03-02 Thread Thomas McKay

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] Jacl in applet

2000-01-17 Thread Thomas McKay

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

2000-01-17 Thread Thomas McKay

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] running jacl in an applet

1999-11-23 Thread Thomas McKay

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] redirecting jacl channels

1999-11-17 Thread Thomas McKay

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

1999-11-12 Thread Thomas McKay

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

1999-11-03 Thread Thomas McKay

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] namespace

1999-11-02 Thread Thomas McKay

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] RE: [Tcl Java] Re: [Tcl Java] more 1.2.4 questions

1999-10-28 Thread Thomas McKay

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: How fast is Jacl?

1999-08-20 Thread Thomas McKay

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?

1999-08-17 Thread Thomas McKay

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] ReflectObject questions

1999-04-21 Thread Thomas McKay


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] cd / pwd

1999-03-30 Thread Thomas McKay

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: [Tcl Java] more on redirecting stdin/stdout

1999-01-16 Thread Thomas McKay


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]'.