tcljava-dev — discuss implementation and post patches here

[tcljava-dev] What does one need to know to make the transition from C Tcl/Tk to Jacl?

[Larry W. V. <lv...@ca...>]

If one has non-technical users who are used to coding small Tcl/Tk scripts
to interact with the C Tcl interpreters embedded in their apps, what
are the kinds of changes they will need to be taught for interacting with
a Java app which instantiates via Jacl an interpreter?

Does anyone know of any freely distributable Java apps that make use of
Jacl?
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [tcljava-dev] JACL classloader bug & fix

[Sasvata (S. C. <sa...@ba...>]

Larry,

Thanks a bunch for that pointer, I was looking at the wrong place looks like.
 Maybe this page could get updated: http://www.tcl.tk/software/java/

> I visited http://sf.net/projects/tcljava today and found the
> tclblend and jacl 1.3.0 downloads listed in the released file section.

Thanks again,
Shash

Re: [tcljava-dev] JACL classloader bug & fix

[Larry W. V. <lv...@ca...>]

I visited http://sf.net/projects/tcljava today and found the
tclblend and jacl 1.3.0 downloads listed in the released file section.


   Latest File Releases
   Package Version Date Notes / Monitor Download
      jacl 1.3.0 March 17, 2003 [88]Release Notes - [89]Monitor This Package
                                [90]Download
     tclblend 1.3.0 March 17, 2003 [91]Release Notes - [92]Monitor This
                            Package [93]Download




Now, granted, today sf.net appears to be slow.
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [tcljava-dev] JACL classloader bug & fix

[Sasvata (S. C. <sa...@ba...>]

Mo,


> Are you using the 1.3.0 release of Jacl? The code in question looks like this
> in the current release:
> 
> 	stream = Interp.class.getResourceAsStream(resName);
> 
> I can only assume that you must be using an old release which is why you
> are running into this problem. If you switch to the 1.3.0 release does the
> problem go away?
> 

You are right, I went straight to the download page and grabbed 1.2.6.  I now
see mention of 1.3.0 available from CVS.  I will checkout a copy from CVS and
see how it works, but it certainly seems like the line of code you provided
shouldfix the issue.  Thanks for the message!

BTW, when is 1.3.0 slated for release?

Thanks,
Shash

Re: [tcljava-dev] JACL classloader bug & fix

[Mo D. <md...@un...>]

On Tue, 17 Jun 2003 14:16:11 -0600
"Sasvata (Shash) Chatterjee" <sa...@ba...> wrote:

> 
> Hi,
> 
> Found a classloader bug while using JACL under Jakarta-BSF under Keel
> Metaframework.  BSF was loaded with a custom classloader, found JACL classes
> but could not load init.tcl (unless jacl.jar was put in the $JRE/lib/ext).
>
> The problem is that instead of loading the resource from the classloader that
> loaded the "Interp", it is loading the resource from the classloader which
> loaded "Class".
> 
> The method evalResource(String resName) in tcl.lang.Interp.java, line 2394
> needs to change:
> 
> from: 	stream = Class.class.getResourceAsStream(resName);
> to  :	stream = getClass().getResourceAsStream(resName);

Are you using the 1.3.0 release of Jacl? The code in question looks like this
in the current release:

	stream = Interp.class.getResourceAsStream(resName);

I can only assume that you must be using an old release which is why you
are running into this problem. If you switch to the 1.3.0 release does the
problem go away?

Mo

[tcljava-dev] JACL classloader bug & fix

[Sasvata (S. C. <sa...@ba...>]

Hi,

Found a classloader bug while using JACL under Jakarta-BSF under Keel
Metaframework.  BSF was loaded with a custom classloader, found JACL classes
but could not load init.tcl (unless jacl.jar was put in the $JRE/lib/ext).

The problem is that instead of loading the resource from the classloader that
loaded the "Interp", it is loading the resource from the classloader which
loaded "Class".

The method evalResource(String resName) in tcl.lang.Interp.java, line 2394
needs to change:

from: 	stream = Class.class.getResourceAsStream(resName);
to  :	stream = getClass().getResourceAsStream(resName);

In a similar vein, TclJava's tcl.lang.JavaDefineClassCmd.java (lines 58-59)
and tcl.lang.JavaInvoke.java (line 384) have the same problem.

Shash

Re: [tcljava-dev] patch to fix C++ commenting

[Mo D. <md...@un...>]

On Thu, 29 May 2003 13:43:48 -0400
"Kenneth H. Cox" <tc...@at...> wrote:

> Hardly worth a post, but my build of 1.3.0 failed due
> to a c++ comment in a .c file.  This patch removes it.

Thanks for the patch Kenneth. Added to CVS.

Mo

[tcljava-dev] patch to fix C++ commenting

[Kenneth H. C. <tc...@at...>]

Hardly worth a post, but my build of 1.3.0 failed due
to a c++ comment in a .c file.  This patch removes it.


--- ./src/native/javaInterp.c~  Fri May 23 11:43:59 2003
+++ ./src/native/javaInterp.c   Fri May 23 11:58:26 2003
@@ -1864,7 +1864,7 @@
                Tcl_WrongNumArgs(interp, 2, objv, "obj");
                return TCL_ERROR;
            }
-           // refCount - 1 to account for the ref added for this method
+           /* refCount - 1 to account for the ref added for this method */
            Tcl_SetObjResult(interp, Tcl_NewIntObj(objv[2]->refCount - 1));
            break;
        }

Re: [tcljava-dev] TclBlend 1.3.0 does not works with the latest CVS head...

[Mo D. <md...@un...>]

On Thu, 22 May 2003 13:06:05 +0100 (BST)
George Petasis <pet...@ya...> wrote:

> Hi all,
> 
> I have problems running the latest tclBlend release
> (1.3.0) under the latest tcl CVS head.

This should be fixed in the CVS now.

cheers
Mo

Re: [tcljava-dev] Question for Tcl/Expect support for Java

[Mo D. <md...@un...>]

On Thu, 22 May 2003 07:03:10 -0400 (EDT)
"Larry W. Virden" <lv...@ca...> wrote:

> > If someone has convinced you that
> > you can do complex interprocess communication with plain Java, then
> > you have been mislead. If your goal is to remove all C code from
> > your product, then you really have a tough road ahead of you.
> 
> Interesting.  I've never thought about this issue.  I'm in a situation
> where there is indeed an effort to remove most, if not all, C code not
> only from one product, but most products.
> 
> Is there some references I can read to learn more about the challenges
> awaiting me?

Well, I was talking only about the specific challenge of replacing a expect
functionality (in C code) with Java code that does the same thing. The
reason this is such a problem is because Java's IPC API is really lacking.
If you would like to see an example of how bad thing can get, take a
look at the exec command implementation in Jacl. It is a bit ugly under
Unix, but the Windows version is just plain scary.

There are plenty of other cases where rewriting a C lib in Java would
likely be a good idea. Java code tends to have fewer crashing bugs
and wickedly complex memory code just because of the fact that
coders don't need to worry about memory. As far as references go,
I don't have any for you. I am just talking from personal experience here.

Mo

[tcljava-dev] TclBlend 1.3.0 does not works with the latest CVS head...

[<pet...@ya...>]

Hi all,

I have problems running the latest tclBlend release
(1.3.0) under the latest tcl CVS head.

The problem is that tclBlend crashes Tcl on
loading the tclBlend package. The crash
seems to happen while an object gets freed:

#15 0x406eca97 in FreeJavaCmdInternalRep ()
   from
/disk2a/users/petasis/Ellogon/lib/tclblend1.3.0/Linux/libtclblend.so
#16 0x4013aa70 in TclFreeObj () from
/disk2b/local/lib/libtcl8.5.so

It seems that there was a change in the
tclObj.c by Don Porter. From the Tcl's Changelog:

2003-05-12  Don Porter  <dg...@us...>
* generic/tclObj.c (tclCmdNameType):  Corrected
variable use of the
	otherValuePtr or the twoPtrValue.ptr1 fields to store
a
	(ResolvedCmdName *) as the internal rep.  [Bug
726018].

As tclBlend seems to somehow "override" the default
functions for the command objects, may this be the
cause?

tclBlend 1.3.0 (& 1.2.6) works fine until
this change happend to the core.

Thanks,

George

____________________________________________________________
Do You Yahoo!?
Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr

Re: [tcljava-dev] Question for Tcl/Expect support for Java

[Larry W. V. <lv...@ca...>]

From: Mo DeJong <md...@un...>

> If someone has convinced you that
> you can do complex interprocess communication with plain Java, then
> you have been mislead. If your goal is to remove all C code from
> your product, then you really have a tough road ahead of you.

Interesting.  I've never thought about this issue.  I'm in a situation
where there is indeed an effort to remove most, if not all, C code not
only from one product, but most products.

Is there some references I can read to learn more about the challenges
awaiting me?
-- 
Tcl - The glue of a new generation.  <URL: http://wiki.tcl.tk/ >
Larry W. Virden <mailto:lv...@ca...> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-

Re: [tcljava-dev] Question for Tcl/Expect support for Java

[Mo D. <md...@un...>]

On Tue, 20 May 2003 22:45:34 +0000
"Mohammad islam" <mis...@ho...> wrote:

> Hi:
> I am new in this field. I am also not sure whether I am in the right place 
> to ask this question.

Well, not really but there is no harm in asking.

> Can any of you please help me out in this regard. My question is  - we are 
> using libexpect (expect library for C) now in our product. Now we need to 
> port the code into Java. I am wandering whether there is any java package 
> equivalent to libexpect. I know there are some java packagaes to support Tcl 
> but no idea about expect support in Java.

No, there is nothing like expect for Java. If someone has convinced you that
you can do complex interprocess communication with plain Java, then
you have been mislead. If your goal is to remove all C code from
your product, then you really have a tough road ahead of you.

If you instead want to move the majority of code into Java while keeping
the expect code to handle interaction with other programs, then you
could use Tcl Blend. You could also just write some JNI wrappers for
expect C functions.

I hope that helps
Mo

[tcljava-dev] Question for Tcl/Expect support for Java

[Mohammad i. <mis...@ho...>]

Hi:
I am new in this field. I am also not sure whether I am in the right place 
to ask this question.
Can any of you please help me out in this regard. My question is  - we are 
using libexpect (expect library for C) now in our product. Now we need to 
port the code into Java. I am wandering whether there is any java package 
equivalent to libexpect. I know there are some java packagaes to support Tcl 
but no idea about expect support in Java.

Thanks --- Kamrul

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

Re: [tcljava-dev] Re: PATCH: Jacl

[Mo D. <md...@un...>]

On Mon, 14 Apr 2003 22:15:03 -0600
Tom Poindexter <tpo...@ny...> wrote:

> > > > > Here are some patches to Jacl
> > > > 
> > > > > 3. jaclsh: sets 'jacl.tcllibpath' property so that init.tcl can add the 
> > > > >    installed lib path to auto_path.
> > 
> > Just an FYI here, but I rejected this 'jacl.tcllibpath' patch because
> > the TCLLIBPATH property already provides this functionality.
> > 
> > Snip from current init.tcl:
>  
> > if {[info exists env(TCLLIBPATH)]} {
> >     lappend auto_path $env(TCLLIBPATH)
> > }
> 
> 
> This does not work in the CVS version.  I built the CVS version clean (none of
> my patches):

You need to pass it as a property, just like the jacl.tcllibpath property in your patch.

java -DTCLLIBPATH=/bar tcl.lang.Shell
% set env(TCLLIBPATH)
/bar
% set auto_path
resource:/tcl/lang/library /bar

cheers
Mo

[tcljava-dev] Re: PATCH: Jacl

[Tom P. <tpo...@ny...>]

> > > > Here are some patches to Jacl
> > > 
> > > > 3. jaclsh: sets 'jacl.tcllibpath' property so that init.tcl can add the 
> > > >    installed lib path to auto_path.
> 
> Just an FYI here, but I rejected this 'jacl.tcllibpath' patch because
> the TCLLIBPATH property already provides this functionality.
> 
> Snip from current init.tcl:
 
> if {[info exists env(TCLLIBPATH)]} {
>     lappend auto_path $env(TCLLIBPATH)
> }


This does not work in the CVS version.  I built the CVS version clean (none of
my patches):


[tpoindex@ct tcljava.clean]$ jaclsh
% parray env
env(CLASSPATH)                     = /usr/local/java/jre/lib/rt.jar:/usr/local/lib/tcljava1.3.0/tcljava.jar:/usr/local/lib/tcljava1.3.0/jacl.jar::
env(HOME)                          = /home/tpoindex
env(USER)                          = tpoindex
env(file.encoding)                 = ISO-8859-1
env(file.encoding.pkg)             = sun.io
env(file.separator)                = /
env(java.awt.fonts)                = 
env(java.awt.graphicsenv)          = sun.awt.X11GraphicsEnvironment
env(java.awt.printerjob)           = sun.awt.motif.PSPrinterJob
env(java.class.path)               = /usr/local/java/jre/lib/rt.jar:/usr/local/lib/tcljava1.3.0/tcljava.jar:/usr/local/lib/tcljava1.3.0/jacl.jar::
env(java.class.version)            = 47.0
env(java.ext.dirs)                 = /usr/local/jdk1.3.1_05/jre/lib/ext
env(java.home)                     = /usr/local/jdk1.3.1_05/jre
env(java.io.tmpdir)                = /tmp
env(java.library.path)             = /usr/local/jdk1.3.1_05/jre/lib/i386:/usr/local/jdk1.3.1_05/jre/lib/i386/native_threads/:/usr/local/jdk1.3.1_05/jre/lib/i386/client:/usr/local/jdk1.3.1_05/jre/../lib/i386:/usr/local/lib
env(java.runtime.name)             = Java(TM) 2 Runtime Environment, Standard Edition
env(java.runtime.version)          = 1.3.1_05-b02
env(java.specification.name)       = Java Platform API Specification
env(java.specification.vendor)     = Sun Microsystems Inc.
env(java.specification.version)    = 1.3
env(java.vendor)                   = Sun Microsystems Inc.
env(java.vendor.url)               = http://java.sun.com/
env(java.vendor.url.bug)           = http://java.sun.com/cgi-bin/bugreport.cgi
env(java.version)                  = 1.3.1_05
env(java.vm.info)                  = mixed mode
env(java.vm.name)                  = Java HotSpot(TM) Client VM
env(java.vm.specification.name)    = Java Virtual Machine Specification
env(java.vm.specification.vendor)  = Sun Microsystems Inc.
env(java.vm.specification.version) = 1.0
env(java.vm.vendor)                = Sun Microsystems Inc.
env(java.vm.version)               = 1.3.1_05-b02
env(line.separator)                = 

env(os.arch)                       = i386
env(os.name)                       = Linux
env(os.version)                    = 2.4.18-18.8.0
env(path.separator)                = :
env(sun.boot.class.path)           = /usr/local/jdk1.3.1_05/jre/lib/rt.jar:/usr/local/jdk1.3.1_05/jre/lib/i18n.jar:/usr/local/jdk1.3.1_05/jre/lib/sunrsasign.jar:/usr/local/jdk1.3.1_05/jre/classes
env(sun.boot.library.path)         = /usr/local/jdk1.3.1_05/jre/lib/i386
env(sun.cpu.endian)                = little
env(sun.cpu.isalist)               = 
env(sun.io.unicode.encoding)       = UnicodeLittle
env(user.dir)                      = /home/tpoindex/src/java/tcljava.clean
env(user.home)                     = /home/tpoindex
env(user.language)                 = en
env(user.name)                     = tpoindex
env(user.region)                   = US
env(user.timezone)                 = 


%  set auto_path
resource:/tcl/lang/library
% 



There is no env(TCLLIBPATH) defined.  Java doesn't even pass most environment
variables (that's an entirely different NIH problem):

[tpoindex@ct tcljava.clean]$ TCLLIBPATH=/usr/local/lib jaclsh
% puts $env(TCLLIBPATH)
can't read "env(TCLLIBPATH)": no such element in array
% 




-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/

Re: [tcljava-dev] Patch: java::import -classpath -resolve

[Tom P. <tpo...@ny...>]

On Mon, Apr 14, 2003 at 01:32:16PM -0700, Mo DeJong wrote:
> On Wed, 9 Apr 2003 08:39:10 -0600
> Tom Poindexter <tpo...@ny...> wrote:
> 
> > On Wed, Apr 09, 2003 at 01:14:00AM -0700, Mo DeJong wrote:
> > > On Tue, 8 Apr 2003 22:07:41 -0600
> > 
> > > I must admit, I don't like the idea of adding a -classpath option to the

> Sorry, I am going to have to reject this patch. I don't see how adding a path
> to the TCL_CLASSPATH is more "disturbing" than passing a flag to the
> import command.


This:
	set cp /usr/local/lib/tcljava-1.3.0/hyde/pizza/pizza-1.1.jar
	java::import -classpath $cp -package net.sf.pizzacompiler.compiler \
	    ByteArrayCompilerOutput \
    	    ClassReader CompilerOutput Main MapSourceReader Report SourceReader
	# do stuff with pizza classes

vs. this:

	global env
	if {[info exists env(TCL_CLASSPATH)]} {
	    set old_tcl_classpath $env(TCL_CLASSPATH)
	}
	set cp /usr/local/lib/tcljava-1.3.0/hyde/pizza/pizza-1.1.jar
	lappend env(TCL_CLASSPATH) $cp
	java::import ByteArrayCompilerOutput \
    	    ClassReader CompilerOutput Main MapSourceReader Report SourceReader
	# do stuff with pizza classes
	# now put TCL_CLASSPATH back the same way we found it
	if {[info exists old_tcl_classpath]} {
	    set env(TCL_CLASSPATH) $old_tcl_classpath
	} else {
	    unset env(TCL_CLASSPATH)
	}


you be the judge.


> Well, in that case perhaps the right fix is to always pass the extra resolve
> flag to the class loader. In any event, exposing this functionality as the
> script layer just does not sound like a good idea.


I'd argue that exposing more functionality *is* a good idea.  The 'java'
package is already incredibly powerful - no need to add training wheels to
a hotrod.

-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/

Re: [tcljava-dev] Patch: java::import -classpath -resolve

[Mo D. <md...@un...>]

On Wed, 9 Apr 2003 08:39:10 -0600
Tom Poindexter <tpo...@ny...> wrote:

> On Wed, Apr 09, 2003 at 01:14:00AM -0700, Mo DeJong wrote:
> > On Tue, 8 Apr 2003 22:07:41 -0600
> 
> > I must admit, I don't like the idea of adding a -classpath option to the
> > import command. The java::import command is meant to act like the
> > import statement in Java, in that it allows using a short name for
> > a class instead of the fully qualified name.
> > 
> > What is wrong with setting the CLASSPATH or the TCL_CLASSPATH env
> > var before running the java::import command?
> 
> I'd like to be able to specify from where to load a class in my Hyde package.
> I'm now using the Pizza compiler (pizzacompiler.sf.net) as an in-process
> compiler for Hyde.  I also would like to make Hyde as 'package friendly'
> as possible, not distrubing global environment's CLASSPATH or TCL_CLASSPATH.

Sorry, I am going to have to reject this patch. I don't see how adding a path
to the TCL_CLASSPATH is more "disturbing" than passing a flag to the
import command.

> > I also don't see how this -resolve flag fits in with the functionality
> > of the import command. In what situation would one want to
> > pass this -resolve flag, and in what situation would one not want
> > it passed? Why would we want to expose this feature at the script
> > level?
> > 
> > I read over the JDK docs but they were not very clear on exactly what
> > the resolve really does. It seems one needs to read the JVM book to
> > find out what "the class is linked" means.
> 
> It's certainly not clear to me either!  In working with Hyde, importing the
> main class for the Pizza compiler yielded protection errors on another
> Pizza compiler class when specifing the pizza jar on TCL_CLASSPATH, but 
> using the resolve flag seemed to fix those problems.  Java class loading seems
> to be more of a black art than it needs to be.  

Well, in that case perhaps the right fix is to always pass the extra resolve
flag to the class loader. In any event, exposing this functionality as the
script layer just does not sound like a good idea.

Mo

Re: [tcljava-dev] PATCH: Jacl

[Mo D. <md...@un...>]

On Thu, 13 Mar 2003 21:28:14 -0700
Tom Poindexter <tpo...@ny...> wrote:

...

> Mo, *thanks* for all of your hard work in the new IO package, etc.  Jacl is
> certainly due for a release to get it on the minds of users again.
> 
> There are a few things I been looking at since your announcement, and it boils
> done to one bug and several convenience factors.  First, the bug that I see.
> 
> This has to to with my Hyde package, still not generally released because I 
> never found a good work around for the binary file IO problem

This problem was fixed by the CVS checkin on 2003-03-18. The fix will be
included in the 1.3.1 release.

> Ok, on to the nice to haves, it boils down to two patches and a wishlist.
> The first patch is to jaclsh.in.  My version adds the following:
> -the ability to use some shell parameters set outside the shell
> -run jaclsh or wisk, by checking the $0 variable, and adding the 
>  swank.jar to CLASSPATH and using the correct Shell class.
> -set a JACL_LIBRARY path to use as the library.
> -use an alternate JDK/JRE than the one Jacl was built with.
> -pass additional -D properties to the JVM.

Well, I would rather not try to cram every possible option into
the existing jaclsh script. It is provided to get folks "up and running"
quickly. No way am I going to add code to launch in multiple
JDK/JRE envs. As far as the other options go, can't  you just edit
the jaclsh script or create your own script to launch with all of
these options?

> My patch file, which also includes the TCL.OK and allowExceptions() patches,
> is below.

I have been meaning to ask you to stop doing that. Having to filter out
these patches that I have already rejected just makes it harder to
evaluate what change you are actually suggesting.

> Ok, and now for my wish list, three things: 1. fileevent, 2. lset, 3. jacllib.
> 
> Adding fileevent might be ugly until Jacl is fully converted to use 1.4's
> NIO package.  Lset would be nice, keeping in pace with Tcl 8.4.2.  
> 'Jacllib' should be able to steal much of the same code has tcllib, at least
> the code that isn't doing socket things with fileevent.  I'm also looking for
> a home for my hyde pacakge, so I have ulterior motives.  I might be willing
> to invest some time to put together some code.

Someone has to sit down and write the code. The best way to get these
wishes implemented is to sit down and start implementing them. The
NIO package could make it easier to deal with non-blocking IO, but
there is lot of Tcl C code to port even if you just use a thread that
blocks.

cheers
Mo DeJong

Re: [tcljava-dev] PATCH: Jacl

[Mo D. <md...@un...>]

On Fri, 14 Mar 2003 09:11:30 -0700
Tom Poindexter <tpo...@ny...> wrote:

> > > Here are some patches to Jacl
> > 
> > > 3. jaclsh: sets 'jacl.tcllibpath' property so that init.tcl can add the 
> > >    installed lib path to auto_path.

Just an FYI here, but I rejected this 'jacl.tcllibpath' patch because
the TCLLIBPATH property already provides this functionality.

Snip from current init.tcl:

if {[info exists env(TCLLIBPATH)]} {
    lappend auto_path $env(TCLLIBPATH)
}

cheers
Mo

Re: [tcljava-dev] Patch: java::import -classpath -resolve

[Tom P. <tpo...@ny...>]

On Wed, Apr 09, 2003 at 01:14:00AM -0700, Mo DeJong wrote:
> On Tue, 8 Apr 2003 22:07:41 -0600

> I must admit, I don't like the idea of adding a -classpath option to the
> import command. The java::import command is meant to act like the
> import statement in Java, in that it allows using a short name for
> a class instead of the fully qualified name.
> 
> What is wrong with setting the CLASSPATH or the TCL_CLASSPATH env
> var before running the java::import command?


I'd like to be able to specify from where to load a class in my Hyde package.
I'm now using the Pizza compiler (pizzacompiler.sf.net) as an in-process
compiler for Hyde.  I also would like to make Hyde as 'package friendly'
as possible, not distrubing global environment's CLASSPATH or TCL_CLASSPATH.   

With this patch, along with my previous patches to set a Jacl library 
path and append that path in init.tcl, I can find the pizza jar file
and invoke the compiler fairly easily.


> I also don't see how this -resolve flag fits in with the functionality
> of the import command. In what situation would one want to
> pass this -resolve flag, and in what situation would one not want
> it passed? Why would we want to expose this feature at the script
> level?
> 
> I read over the JDK docs but they were not very clear on exactly what
> the resolve really does. It seems one needs to read the JVM book to
> find out what "the class is linked" means.

It's certainly not clear to me either!  In working with Hyde, importing the
main class for the Pizza compiler yielded protection errors on another
Pizza compiler class when specifing the pizza jar on TCL_CLASSPATH, but 
using the resolve flag seemed to fix those problems.  Java class loading seems
to be more of a black art than it needs to be.  


-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/

Re: [tcljava-dev] Patch: java::import -classpath -resolve

[Mo D. <md...@un...>]

On Tue, 8 Apr 2003 22:07:41 -0600
Tom Poindexter <tpo...@ny...> wrote:

> Here's a patch to java::import that adds -classpath and -resolve options.
> The -classpath option specifies a specific classpath and/or jar files from
> which to load the classes being imported.  The -resolve passes the
> 'resolve' flag to the class loader (see docs for 
> java.lang.ClassLoader.loadClass() ).

I must admit, I don't like the idea of adding a -classpath option to the
import command. The java::import command is meant to act like the
import statement in Java, in that it allows using a short name for
a class instead of the fully qualified name.

What is wrong with setting the CLASSPATH or the TCL_CLASSPATH env
var before running the java::import command?

I also don't see how this -resolve flag fits in with the functionality
of the import command. In what situation would one want to
pass this -resolve flag, and in what situation would one not want
it passed? Why would we want to expose this feature at the script
level?

I read over the JDK docs but they were not very clear on exactly what
the resolve really does. It seems one needs to read the JVM book to
find out what "the class is linked" means.

Mo

[tcljava-dev] Patch: java::import -classpath -resolve

[Tom P. <tpo...@ny...>]

Here's a patch to java::import that adds -classpath and -resolve options.
The -classpath option specifies a specific classpath and/or jar files from
which to load the classes being imported.  The -resolve passes the
'resolve' flag to the class loader (see docs for 
java.lang.ClassLoader.loadClass() ).  Updated docs included.

I'm using these options in my Hyde package that I hope to finally get
released RSN. 

-- 
Tom Poindexter
tpo...@ny...
http://www.nyx.net/~tpoindex/



diff -u -r tcljava.cvs/docs/TclJava/ClassLoading.html tcljava.tp/docs/TclJava/ClassLoading.html
--- tcljava.cvs/docs/TclJava/ClassLoading.html	2002-10-08 22:38:44.000000000 -0600
+++ tcljava.tp/docs/TclJava/ClassLoading.html	2003-04-08 21:21:04.000000000 -0600
@@ -44,7 +44,8 @@
 files specified by <I>pathList</I>.  (Available only for the <B>java::load</B> command.)
 <P><DT>[4]<DD>
 Search <I>pathList</I> again, inspecting all jar files found in
-each directory.  (Available only for the <B>java::load</B> command.)
+each directory.  (Available for the <B>java::load</B> and 
+<B>java::import</B>commands.)
 <P><DT>[5]<DD>
 Search the <B>env(TCL_CLASSPATH)</B> list, looking only in directories or jar
 files specified by <B>env(TCL_CLASSPATH)</B>.
@@ -103,4 +104,4 @@
 
 
 </BODY>
-</HTML>
\ No newline at end of file
+</HTML>
diff -u -r tcljava.cvs/docs/TclJava/JavaImportCmd.html tcljava.tp/docs/TclJava/JavaImportCmd.html
--- tcljava.cvs/docs/TclJava/JavaImportCmd.html	2003-03-12 20:15:00.000000000 -0700
+++ tcljava.tp/docs/TclJava/JavaImportCmd.html	2003-04-08 21:23:05.000000000 -0600
@@ -18,7 +18,7 @@
 Usage:
 </H3>
 
-<DD><B>java::import</B> ?<B>-forget</B>? ?<B>-package</B> <I>pkg</I>? ?<I>class ...</I>?
+<DD><B>java::import</B> ?<B>-forget</B>? ?<B>-resolve</B>? ?<B>-classpath</B> <I>pathList</I>? ?<B>-package</B> <I>pkg</I>? ?<I>class ...</I>?
 
 <P>
 
@@ -36,6 +36,13 @@
 specifier, meaning the '.' character must not appear in a <I>class</I> name.
 
 <P>
+The <B>-classpath</B> <I>pathList</I> argument specifies a Tcl list of
+directories and/or Jar files to search during class loading.  If 
+<B>-classpath</B> <I>pathList</I> is omitted, the class loader will
+search for the class on using <B>CLASSPATH</B> and 
+<B>env(TCL_CLASSPATH)</B>.  Refer to 
+<A HREF="ClassLoading.html">Class Loading</A> for additional information.
+<P>
 
 If the <B>java::import</B> command is invoked with no arguments it will return
 a list of all the currently imported classes. If the <B>java::import</B>
@@ -51,6 +58,11 @@
 
 <P>
 
+The <B>-resolve</B> argument will cause the class loader to perform
+resolution and linking steps for the classes being imported. 
+
+<P>
+
 </DL>
 
 <DL>
diff -u -r tcljava.cvs/src/tcljava/tcl/lang/JavaImportCmd.java tcljava.tp/src/tcljava/tcl/lang/JavaImportCmd.java
--- tcljava.cvs/src/tcljava/tcl/lang/JavaImportCmd.java	2003-03-12 20:15:27.000000000 -0700
+++ tcljava.tp/src/tcljava/tcl/lang/JavaImportCmd.java	2003-04-08 21:16:28.000000000 -0600
@@ -22,9 +22,20 @@
 
 import java.util.*;
 
-
 public class JavaImportCmd implements Command {
 
+static final private String validOpts[] = {
+    "-resolve",
+    "-forget",
+    "-package",
+    "-classpath"
+};
+
+static final private int RESOLVE	= 0;
+static final private int FORGET 	= 1;
+static final private int PACKAGE	= 2;
+static final private int CLASSPATH	= 3;
+
     /*
      *----------------------------------------------------------------------
      *
@@ -50,7 +61,7 @@
 	throws
 	    TclException			// A standard Tcl exception.
     {
-	final String usage = "java::import ?-forget? ?-package pkg? ?class ...?";
+	final String usage = "java::import ?-resolve? ?-forget? ?-package pkg? ?-classpath pathList? ?class ...?";
 
 	Hashtable classTable = interp.importTable[0];
 	Hashtable packageTable = interp.importTable[1];
@@ -61,6 +72,9 @@
 	Enumeration search, search2;
 	String elem, elem2;
 	int startIdx, i;
+	boolean resolve = false;
+	TclObject classPath = null;
+	int opt;
 
 	// If there are no args simply return all the imported classes
 	if (objv.length == 1) {
@@ -75,15 +89,61 @@
 	    interp.setResult(import_list);
 	    return;
 	}
-	
-	// See if there is a -forget argument
+
+	// process args
 	startIdx = 1;
 	elem = objv[startIdx].toString();
-	if (elem.equals("-forget")) {
-	    forget = true;
+	while (elem.charAt(0) == '-' && startIdx < objv.length) {
+	    try {
+	    	opt = TclIndex.get(interp, objv[startIdx], validOpts, "option", 0);
+	    } catch (TclException e) {
+		throw new TclException(interp, "bad option \"" + objv[startIdx]
+			+ "\": " + usage);
+	    }
+	    switch (opt) {
+	    case RESOLVE:
+		resolve = true;
+		break;
+	    case FORGET:
+		forget = true;
+		break;
+	    case PACKAGE:
+		if (startIdx + 1 < objv.length) {
+		    pkg = objv[startIdx + 1].toString();	
+	    	    if (pkg.length() == 0) {
+			throw new TclException(interp, 
+			"-package \"pkg\" not specified: " + usage);
+	    	    }
+		    startIdx++;
+		} else {
+		    throw new TclException(interp, 
+			"-package \"pkg\" not specified: " + usage);
+		}
+		break;
+	    case CLASSPATH:
+		if (startIdx + 1 < objv.length) {
+		    classPath = objv[startIdx + 1];
+		    startIdx++;
+		} else {
+		    throw new TclException(interp, 
+			" -classpath \"arg\" not specified: " + usage);
+		}
+		break;
+	    }
+
 	    startIdx++;
+	    if (startIdx < objv.length) {
+	    	elem = objv[startIdx].toString();
+	    }
 	}
 
+	// check for mutally exclusive -resolve -forget
+	if (forget && resolve) {
+	    throw new TclException(interp, 
+		"-forget and -resolve are mutually exclusive: " + usage);
+	}
+	
+
 	// When -forget is given with no arguments, we simply
 	// return. This is needed to support the following usage.
 	//
@@ -97,36 +157,13 @@
 	}
 
 
-	// Figure out if the "-package pkg" arguments are given
-	elem = objv[startIdx].toString();
-	if (elem.equals("-package")) {
-	    startIdx++;
-
-	    // "java::import -package" is not a valid usage
-	    // "java::import -forget -package" is not a valid usage
-	    if (startIdx >= objv.length) {
-		throw new TclException(interp, usage);
-	    }
-	    
-	    pkg = objv[startIdx].toString();
-	    if (pkg.length() == 0) {
-		throw new TclException(interp, usage);
-	    }
-	    startIdx++;
-	}
-
-
-	// No additional arguments means we have hit one of 
-	// two conditions.
-	//
-	// "java::import -forget -package pkg"
-	// "java::import -package pkg"
+	// No additional options, process class arguments
 
 	if (startIdx >= objv.length) {
 	    if (forget) {
 		// We must have "java::import -forget -package pkg"
 
-		// Ceck that it is not "java::import -forget" which is invalid!
+		// Check that it is not "java::import -forget" which is invalid!
 		if (pkg == null) {
 		    throw new TclException(interp, usage);
 		}
@@ -225,7 +262,7 @@
 	    operation = "forget";
 	}
 
-	TclClassLoader tclClassLoader = new TclClassLoader(interp, null);
+	TclClassLoader tclClassLoader = new TclClassLoader(interp, classPath);
 
 
 	// Start processing class arguments begining at startIdx.
@@ -275,6 +312,7 @@
 		fullyqualified = pkg + "." + elem;
 	    }
 	
+
 	    // split the fullyqualified name into a package and class
 	    // by looking for the last '.' character in the string.
 	    // If there is no '.' in the string the class is in the
@@ -307,7 +345,7 @@
 		boolean inGlobal = true;
 
 		try {
-		    tclClassLoader.loadClass(class_name);
+		    tclClassLoader.loadClass(class_name, resolve);
 		} catch (ClassNotFoundException e) {
 		    inGlobal = false;
 		    tclClassLoader.removeCache(class_name);
@@ -328,7 +366,7 @@
 			"\", it does not exist");
 
 		try {
-		    Class c = tclClassLoader.loadClass(fullyqualified);
+		    Class c = tclClassLoader.loadClass(fullyqualified, resolve);
 		    if (!PkgInvoker.isAccessible(c)) {
 		        throw new TclException(interp, "Class \"" + c.getName() +
 		                "\" is not accessible");

Re: [tcljava-dev] Problem with configure

[Mo D. <md...@un...>]

On Tue, 25 Mar 2003 07:20:49 -0600
"Wilson, Mark" <Mar...@us...> wrote:

> As I stated in my original message, I am using mingw to compile.  I am just
> using cygwin as a convenient shell.  Anyway, here is the config.log file.

Using Cygwin is not currently supported. The windows build has only been
tested using msys + mingw. If you want to get the build working under Cygwin,
feel free but just be aware that it does not work now. Follow the build instructions
and you should be able to build.

Mo

RE: [tcljava-dev] Problem with configure

[Wilson, M. <Mar...@us...>]

As I stated in my original message, I am using mingw to compile.  I am just
using cygwin as a convenient shell.  Anyway, here is the config.log file.

Thanks!
Mark



-----Original Message-----
From: Mo DeJong [mailto:md...@un...]
Sent: Monday, March 24, 2003 6:07 PM
To: tcl...@li...
Subject: Re: [tcljava-dev] Problem with configure


On Mon, 24 Mar 2003 14:37:45 -0600
"Wilson, Mark" <Mar...@us...> wrote:

Hi Mark.

> When I try to run configure (using tcl 8.4.2, thread 2.5, j2sdk1.4.1_02),
I
> get:

I assume you mean thread 2.5.1. You can't build under Windows with
the 2.5 release, but that does not seem to be related to the problem
you posted below.

> Using the following JNI include flags -I/cygdrive/c/j2sdk1.4.1_02/include
> -I/cygdrive/c/j2sdk1.4.1_02/include/win32
> checking to see if jni.h can be included... configure: error: could not
> compile file that includes jni.h
> 
> (I am using the MinGW gcc compiler).

Well, why is there that /cygdrive prefix on your paths? You are not
trying to build under Cygwin are you? The README file for Tcl Blend
says that the msys_mingw package is needed to compile Tcl Blend.

If this is not the cause of your problem, you might want to post the
generated config.log file, since it will contain more info about what
the exact compiler error is.

cheers
Mo


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev