tcljava-dev

[tcljava-dev] Tcl/Java 1.3.0 release is online.

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

The Tcl/Java 1.3.0 release is now available for download. There
is also a new project website that can be accessed at the following
URL:

http://tcljava.sourceforge.net/docs/website/index.html

There are so many new features and fixed bugs in the 1.3.0
release, I don't even know where to begin. This release was
about 3 years in the making, so it is by no means a minor
upgrade. Please download and test it out, just be aware that
this is not a production release. Significant evaluation and
testing are still needed before 1.3 is considered safe for
production systems.

Here is a short rundown of the new features:

(NEW REGULAR EXPRESSION PACKAGE FOR JACL)

A new implementation of the regexp and regsub commands has been
donated by Colin Stevens of Sun Labs fame. This replaces the
Oro regexp implementation. It was binary only and no longer supported.
Jacl is now 100% Open Source.

(NEW COMMAND FOR JACL)

An implementation of Tcl's binary command has been added to Jacl.
This new command passes all of the Tcl regression tests for the
binary command. Thanks go to Christian Krone for this command.

(NEW COMMAND FOR JACL)

An implementation of Tcl's history command has been added to Jacl.
This new command passes all of the Tcl regression tests for the
history command. Thanks go to Christian Krone for this command.

(JVM SUPPORT)

A completely new build system has been added. It now supports
the IBM Java-2 1.3 JVM. The new build system also adds
support for the Kaffe Open JVM with Tcl Blend. Jacl has worked
with Kaffe for some time, but now both Tcl Blend and Jacl can
be used with Kaffe.

(NEW COMMAND FOR JACL)

An implementation of Tcl's interp command has been added to Jacl.
This new command passes all of the Tcl regression tests for the
interp command. Thanks go to Christian Krone for this command.

(TCL BLEND NOW FULLY THREAD AWARE)

Earlier versions of Tcl Blend made use of a global lock that
serialized each Java method call. In the new version,
Tcl Blend's JNI code has been rewritten to get rid of this
global lock. This change significantly simplifies the code
and should increase performance when Java methods are invoked
from multiple threads.

(NEW COMMAND FOR JACL)

The fconfigure command has been added to Jacl. Thanks go to
Bruce Johnson for providing the initial implementation
of this command.

(NEW COMMAND FOR JACL)

The encoding command has been added to Jacl. Thanks go to
Bruce Johnson for providing the initial implementation
of this command.

(NEW COMMAND FOR JACL)

The socket command has been added to Jacl. Both client sockets
and server sockets are supported. Thanks go to Neil Madden
for providing the the initial implementation of this command.

(NEW COMMAND FOR JACL)

The file volumes subcommand has been added to Jacl. The
implementation makes use of the File.listRoots() method
introduced in JDK 1.2, so a newer JDK is required to
make use of this functionality. Thanks go to Shawn Boyce
for providing the initial implementation of this command.

(NEW REF COUNT SYSTEM FOR TCL BLEND)

A new reference counting system has been implemented for
Tcl Blend. A newly created CObject or TclList no longer
increments the ref count the native Tcl_Obj. Instead,
the ref count for a Tcl_Obj is incremented when
TclObject.preserve() is invoked and decremented
when TclObject.release() is invoked. If a TclList
created inside a Java method is never released,
it will be cleaned up when the Java method returns.
This new ref counting system does not depend on the
Java garbage collector and should not suffer from
the memory leaks or shutdown issues that plagued
the previous implementation.

(NEW REFLECTED METHOD/CONSTRUCTOR/FIELD ACCESS)

A new approach to reflected method, constructor, and field
access has been implemented. In the previous implementation,
package scoped entities were considered when accessing a field,
when attempting to resolve a method signature, or when choosing
a constructor. In the new implementation, these package scoped
entities are only considered when a custom package invoker
is defined for the package.

(PASSING MULTIPLE JVM OPTIONS)

The tclblend_init variable has provided a means to pass a single
JVM option to a JDK 1.2 or newer JVM. This support has been
improved so that multiple JVM options can now be passed.

(NEW REFLECTED OBJECT ACCESS)

A new approach to reflected object access has been implemented.
In the previous implementation, inaccessible objects could
be reflected in the interpreter. This type of access would
be illegal in Java code, so new Class accessibility checks
have been added to each of the java methods. An exception
will now be raised on any attempt to interact with an
inaccessible class.

(PASSING TCL OBJECTS TO JAVA)

It is now possible to pass a TclObject directly to a Java method.
In previous versions it was possible to pass a TclObject contained
in a ReflectObject, but it was not possible to pass the actual
TclObject that contained the ReflectObject. The new implementation
makes it possible to directly pass the containing TclObject assuming
it is not a ReflectObject that contains a TclObject.

(CHANGE TO TCL OBJECT API)

The TclObject.takeExclusive() method has a number of problems, and has
been deprecated in favor of the new TclObject.duplicate() method.
This new duplicate method works identically to Tcl_DuplicateObj.
Old code that makes used of the takeExclusive method will still
work, but it should be updated to use duplicate as time permits.
See the TclObject manual entry for an example of how to use this
new duplicate method.

(NEW COMMAND FOR JACL)

The array unset subcommand has been added to the Jacl's array command.

(NEW WINDOWS BUILD SUPPORT)

Both Tcl Blend and Jacl can now be built under Windows using the
msys_mingw package. Users no longer need to have VC++ installed
to build binaries of Jacl or Tcl Blend. See the supplied README
file for Jacl or Tcl Blend for more information about how to
build under Windows.

(NEW IO SUBSYSTEM FOR JACL)

The Tcl IO subsystem has been ported to Jacl. Encoding, buffering,
and line translations for channels now match Tcl semantics.
Non-blocking IO and the fileevent command are not implemented.

cheers
Mo DeJong

[tcljava-dev] Re: [tcljava-user] Tcl/Java 1.3.0 release is online.

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

On Tue, 18 Mar 2003 09:07:38 -0800
"Rob Ratcliff" <rr...@fu...> wrote:

> Hi Mo,

Hi Rob.
 
> ==== unicode-3.2 convert to encoded string FAILED
> ==== Contents of test case:
> 
>     set str "\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"
>     set enc [encoding convertto jis0208 $str]
>     string compare $enc "!)!)!)!)!)!)!)!)!)!)!)!)!)!)!)"
> 
> ---- Result was:
> 1
> ---- Result should have been:
> 0
> ==== unicode-3.2 FAILED

I have seen this failure before. Tcl does not seem to agree with
Java about how the jis0208 encoding should work.

> tcl/string.test
> 
> ==== string-6.14 string is alnum, unicode FAILED
> ==== Contents of test case:
> 
>     string is alnum abc?
> 
> ---- Result was:
> 0
> ---- Result should have been:
> 1
> ==== string-6.14 FAILED

Humm, this is strange. I do not see this, along with the other string
errors you are running into on my machine. 

The implementation inside jacl's StringCmd.java seems to just
call  Character.isLetterOrDigit(char) for each character in
the string.

You might try to execute this in you Jacl shell, it returns
{1 1 1 1} for me.

list \
[java::call Character isLetterOrDigit a] \
[java::call Character isLetterOrDigit b] \
[java::call Character isLetterOrDigit c] \
[java::call Character isLetterOrDigit \xfc]

The character is just written in the string.test file, it
is not escaped so perhaps that combined with some
encoding issue has something to do with this. You could
try pasting the string from the file into the test above,
instead of using the \xfc and see if that works.

> tcljava/JavaDefineClassCmd.test
> 
> ==== java::defineclass-2.1 loading a class FAILED
> ==== Contents of test case:
> 
>     set file  [open [file join $javaload_full_path Test1Cmd.class]]
>     fconfigure $file -translation binary
>     set bytes [read $file]
>     close $file
>     set class [java::defineclass $bytes]
>     java::isnull $class
> 
> ---- Result was:
> 1
> ---- Result should have been:
> 0
> ==== java::defineclass-2.1 FAILED

Strange, this one does not fail on my system. It is not
clear if this is the fault of the new IO layer or something
having gone wrong in the defineclass command. Could
you add some debug statements to see if the correct number
of bytes is being read in for this .class file?

cheers
Mo

Re: [tcljava-dev] Re: [tcljava-user] Tcl/Java 1.3.0 release is online.

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

On Tue, Mar 18, 2003 at 09:54:17AM -0800, Mo DeJong wrote:
> On Tue, 18 Mar 2003 09:07:38 -0800
> "Rob Ratcliff" <rr...@fu...> wrote:
> 
> > Hi Mo,
> 
> Hi Rob.
>  
> > ==== unicode-3.2 convert to encoded string FAILED
> > ==== Contents of test case:
> > 
> >     set str "\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"
> >     set enc [encoding convertto jis0208 $str]
> >     string compare $enc "!)!)!)!)!)!)!)!)!)!)!)!)!)!)!)"
> > 
> > ---- Result was:
> > 1
> > ---- Result should have been:
> > 0
> > ==== unicode-3.2 FAILED
> 


Yeah, I get this too.



> > tcljava/JavaDefineClassCmd.test
> > 
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev


I'm also failing on this test, but it is dependent on the value of the
LANG environment variable:

Running with:
	LANG=en_US.iso885915 make test_jacl.exec

fails on:

==== java::defineclass-2.1 loading a class FAILED
..
---- Result was:
1
---- Result should have been:
0
==== java::defineclass-2.1 FAILED





However, running with:
	LANG=en_US.iso885915 make test_jacl.exec

passes.



As I reported earlier, I believe it has to do with various .toString()
methods.

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

Re: [tcljava-dev] Re: [tcljava-user] Tcl/Java 1.3.0 release is online.

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

On Tue, 18 Mar 2003 14:48:59 -0700
Tom Poindexter <tpo...@ny...> wrote:

> > > tcljava/JavaDefineClassCmd.test
>
> I'm also failing on this test, but it is dependent on the value of the
> LANG environment variable:
> 
> Running with:
> 	LANG=en_US.iso885915 make test_jacl.exec
> 
> fails on:
> 
> ==== java::defineclass-2.1 loading a class FAILED
> ..
> ---- Result was:
> 1
> ---- Result should have been:
> 0
> ==== java::defineclass-2.1 FAILED

...

> As I reported earlier, I believe it has to do with various .toString()
> methods.

How very odd. I would think that a toString() would not get called here
since we are dealing with binary data. Doh! I just opened up the src
for JavaDefineClassCmd.java and found this:

public void
cmdProc(
    Interp interp,			// Current interpreter.
    TclObject argv[])			// Argument list.
throws
    TclException			// A standard Tcl exception.
{
    byte[] classData;
    Class  result;
    TclClassLoader tclClassLoader;
    
    if (argv.length != 2) {
	throw new TclNumArgsException(interp, 1, argv,
		"classbytes");
    }

    classData = argv[1].toString().getBytes();

    tclClassLoader = new TclClassLoader(interp, null);
    result = tclClassLoader.defineClass(null, classData);
    
    interp.setResult(ReflectObject.newInstance(interp,
            Class.class, result));
}


The code is calling argv[1].toString() on the ByteArray and then
calling getBytes() to convert that to an array of bytes. That is just
wrong, but it is not clear to me how to make it right. The Jacl
package defines the TclByteArray object, so that class can't be used
in this code since it lives in the tcljava subdir. Perhaps the right
approach is to create a TclByteArray object for TclBlend, that
way the same TclByteArray API could be used in both Jacl and
Tcl Blend code. Anyone feel like coding this up? I am a bit busy
right now so I may not be able to get to this for some time.

Mo

Re: [tcljava-dev] Re: [tcljava-user] Tcl/Java 1.3.0 release is online.

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

On Tue, 18 Mar 2003 14:25:07 -0800
Mo DeJong <md...@un...> wrote:

> On Tue, 18 Mar 2003 14:48:59 -0700
> Tom Poindexter <tpo...@ny...> wrote:
> 
> > > > tcljava/JavaDefineClassCmd.test
> >
> > I'm also failing on this test, but it is dependent on the value of the
> > LANG environment variable:
> > 
> > Running with:
> > 	LANG=en_US.iso885915 make test_jacl.exec
> > 
> > fails on:
> > 
> > ==== java::defineclass-2.1 loading a class FAILED
> > ..
> > ---- Result was:
> > 1
> > ---- Result should have been:
> > 0
> > ==== java::defineclass-2.1 FAILED
> 
> ...
> 
> > As I reported earlier, I believe it has to do with various .toString()
> > methods.
> 
> How very odd. I would think that a toString() would not get called here
> since we are dealing with binary data. Doh! I just opened up the src
> for JavaDefineClassCmd.java and found this:

Well, I could not resist trying one simple thing. Does this patch fix the
problem for you?

Index: src/tcljava/tcl/lang/JavaDefineClassCmd.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/tcljava/tcl/lang/JavaDefineClassCmd.java,v
retrieving revision 1.2
diff -u -r1.2 JavaDefineClassCmd.java
--- src/tcljava/tcl/lang/JavaDefineClassCmd.java        30 Dec 2002 02:30:54 -0000    1.2
+++ src/tcljava/tcl/lang/JavaDefineClassCmd.java        18 Mar 2003 23:19:52 -0000
@@ -43,17 +43,22 @@
     byte[] classData;
     Class  result;
     TclClassLoader tclClassLoader;
-    
+
     if (argv.length != 2) {
        throw new TclNumArgsException(interp, 1, argv,
                "classbytes");
     }
 
-    classData = argv[1].toString().getBytes();
+    String str = argv[1].toString();
+    final int str_length = str.length();
+    classData = new byte[str_length];
+    for (int i=0; i < str_length; i++) {
+        classData[i] = (byte) str.charAt(i);
+    }
 
     tclClassLoader = new TclClassLoader(interp, null);
     result = tclClassLoader.defineClass(null, classData);
-    
+
     interp.setResult(ReflectObject.newInstance(interp,
             Class.class, result));
 }


cheers
Mo

Re: [tcljava-dev] Re: [tcljava-user] Tcl/Java 1.3.0 release is online.

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

On Tue, Mar 18, 2003 at 03:24:25PM -0800, Mo DeJong wrote:
> On Tue, 18 Mar 2003 14:25:07 -0800
> Mo DeJong <md...@un...> wrote:


> Well, I could not resist trying one simple thing. Does this patch fix the
> problem for you?
> 
> Index: src/tcljava/tcl/lang/JavaDefineClassCmd.java

Yes, it does appear that this fixes the problem.  I'm going to do a little
more testing, but it certainly looks to fix the lingering problems I've
had with Hyde (and other binary access).  I was trying to modify the same
class to checkfor TclByteArray, and just call .getBytes() directly 
without .toString() first, but didn't seem to get the right 
combination.  Your patch works.

Thanks!

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

[tcljava-dev] Swank and Jacl 1.3.0

[Bruce J. <nm...@ma...>]

I'm currently working on getting Swank to work with Jacl 1.3.0.
I think I've got rid of all references to TCL.OK and 
Interp.allowExceptions.

I've got some more testing to do then I'll post it.

Bruce

[tcljava-dev] Jacl and MacOSX with Java 1.4.1_01-39

[Bruce J. <nm...@ma...>]

Since upgrading to the latest Java on MacOSX I've found that doing a 
"source -url resource:/file" which results in reading from a compressed 
jar file no longer works.  Enabling (by just making the if statement 
always true) the fix below (from Interp.java) solves the problem.  
Anyone else using MacOSX with Java and having this problem?

Bruce

        // FIXME : ugly JDK 1.2 only hack
         // Ugly workaround for compressed files BUG in JDK1.2
         // this bug first showed up in  JDK1.2beta4. I have sent
         // a number of emails to Sun but they have deemed this a 
"feature"
         // of 1.2. This is flat out wrong but I do not seem to change 
thier
         // minds. Because of this, there is no way to do non blocking IO
         // on a compressed Stream in Java. (mo)

         if (System.getProperty("java.version").startsWith("1.2") &&
             
stream.getClass().getName().equals("java.util.zip.ZipFile$1")) {

Re: [tcljava-dev] Re: [tcljava-user] Tcl/Java 1.3.0 release is online.

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

On Tue, 18 Mar 2003 09:54:17 -0800
Mo DeJong <md...@un...> wrote:

> > tcl/string.test
> > 
> > ==== string-6.14 string is alnum, unicode FAILED
> > ==== Contents of test case:
> > 
> >     string is alnum abc?
> > 
> > ---- Result was:
> > 0
> > ---- Result should have been:
> > 1
> > ==== string-6.14 FAILED

I have been thinking about this one and I think it is an encoding
issue with the source command. Could you try this patch and
see if it fixes the problem? As I said, I don't see this error on
my system so I need others to test this.

Index: src/jacl/tcl/lang/Interp.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Interp.java,v
retrieving revision 1.43
diff -u -r1.43 Interp.java
--- src/jacl/tcl/lang/Interp.java	13 Mar 2003 22:28:10 -0000	1.43
+++ src/jacl/tcl/lang/Interp.java	23 Mar 2003 02:04:41 -0000
@@ -2352,7 +2352,7 @@
 throws 
     TclException
 {
-    String fileContent;		// Contains the content of the file.
+    TclObject fileContent;		// Contains the content of the file.
 
     fileContent = readScriptFromFile(s);
 
@@ -2439,32 +2439,36 @@
  *----------------------------------------------------------------------
  */
 
-private String
+private TclObject
 readScriptFromFile(
     String s)			// The name of the file.
 {
-    File sourceFile;
-    FileInputStream fs;
+    FileChannel file;
+    TclObject result;
+    int charactersRead = -1;
+
+    file = new FileChannel();
+    if (file.getEncoding() == null) {
+        result = TclByteArray.newInstance();
+    } else {
+        // FIXME: set default buffer size to about the
+        // size of the file?
+        result = TclString.newInstance(new StringBuffer(64));
+    }
     try {
-	sourceFile = FileUtil.getNewFileObj(this, s);
-	fs = new FileInputStream(sourceFile);
-    } catch (TclException e) {
-	resetResult();	
-	return null;
-    } catch (FileNotFoundException e) {
-	return null;
-    } catch (SecurityException sec_e) {
-	return null;
+        file.open(this, s, TclIO.RDONLY);
+        charactersRead = file.read(this, result, TclIO.READ_ALL, 0);
+        TclIO.unregisterChannel(this, file);
+    } catch (TclException ex) {
+        // FIXME: Catch Tcl error in open
+    } catch (IOException ex) {
+	// FIXME: do something with this.
     }
 
-    try {
-	byte charArray[] = new byte[fs.available()];
-	fs.read(charArray);
-	return new String(charArray);
-    } catch (IOException e) {
-	return null;
-    } finally {
-	closeInputStream(fs);
+    if (charactersRead >= 0) {
+        return result;
+    } else {
+        return null;
     }
 }