tcljava-dev — discuss implementation and post patches here

Re: [tcljava-dev] Problem with configure

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

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

[tcljava-dev] Problem with configure

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

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


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).

The jni files are in the correct path...

Help!

Thanks,

Mark E. Wilson
The Document Company, Xerox
800 Phillips Rd.
Webster, NY 14580

mar...@us...
(585) 231-5544

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;
     }
 }
 

[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")) {

[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

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/

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.

[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.

[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/

[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

[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

Re: [tcljava-dev] PATCH: Jacl

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

On Thu, Mar 13, 2003 at 02:39:54PM -0800, Mo DeJong wrote:
> On Sun, 4 Aug 2002 14:06:28 -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.
> 
> Tom, could you explain why this patch is needed, in ChangeLog format?

Without it, Jacl doesn't have a standard directory from which to 
load external packages, e.g., without patch:
	% set auto_path
	resource:/tcl/lang/library

with:
	% set auto_path
	resource:/tcl/lang/library /usr/local/lib/tcljava1.3.0


This is sort of like TCL_LIBRARY in C based Tcl, but doesn't allow overriding
init.tcl as easily.  I want a standard place to put Jacl packages like my
Hyde and proposed jacllib without requiring each Jacl script lappend'ing
to auto_path.


In ChangeLog format:

	
	*  src/jacl/tcl/lang/library/init.tcl:  Append to auto_path
	the value of property jacl.tcllibpath.  This allows Jacl to have
	a standard library directory outside of the internal jar
	resources.
	

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

Re: [tcljava-dev] PATCH: Jacl

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

On Thu, Mar 13, 2003 at 02:35:48PM -0800, Mo DeJong wrote:
> On Sun, 4 Aug 2002 14:06:28 -0600
> Tom Poindexter <tpo...@ny...> wrote:
> 
> ...
> 
> > 8. TCL.java: change scope of OK to public, for use by Swank.
> 
> I still don't get why folks keep asking for this change. The TCL.OK
> value should not be needed outside the Jacl package.
> 


Well, I understand the design principles involved, but for me, it boils down
to a choice: being right, or running Swank.  I'd rather run Swank. 

Also required is the patch to src/jacl/tcl/lang/Interp.java, making 
allowExceptions() public, also used by Swank.

I think Swank is too important NOT to make run 'out of the box' with Jacl.
Bruce, perhaps you can update us all on any Swank changes that we might be
so lucky to see in the near term?  Bruce and Mo - perhaps there is another
resolution that amiable to all?  I confess that I haven't studied Swank 
internals much, so I can't make suggestions at this point.

Here are the few 'trouble' spots I see:
TCL.OK:
BindCmd.java:    return TCL.OK;
BindCmd.java:    return TCL.OK;
SwkCell.java:    return TCL.OK;
SwkTableModel.java:    return TCL.OK;

allowExceptions():
BindCmd.java:   interp.allowExceptions();
BindCmd.java:   interp.allowExceptions();
SwkTableModel.java:        interp.allowExceptions();


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 (see my message
to the list on 2002-07-24.)  It looks like the binary-ness for fconfigure
is working to expectation now.  The remaining problem seems to be in
the actual 'binary' command.  Here's some test code:


---- cut here -----------------------------------------------------------------
package require java

puts "system encoding is $env(file.encoding)"

array set cacheCode  [list multtwoCmd [binary format H* cafebabe0000002e000f0a0003000c07000d07000e0100063c696e69743e010003282956010004436f646501000f4c696e654e756d6265725461626c650100076d756c7474776f010005284949294901000a536f7572636546696c6501000f6d756c7474776f436d642e6a6176610c0004000501000f687964652f6d756c7474776f436d640100106a6176612f6c616e672f4f626a656374002100020003000000000002000100040005000100060000001d00010001000000052ab70001b100000001000700000006000100000002000900080009000100060000002200020003000000061a1b683d1cac0000000100070000000a000200000008000400090001000a00000002000b]]

set byteCode $cacheCode(multtwoCmd)
set defobj [java::defineclass $byteCode]
if {[string equal $defobj [java::null]]} {
  puts "failed defineclass"
} else {
  proc multtwo {a b} {return [java::call hyde.multtwoCmd multtwo $a $b]}
  puts "int result: multtwo 4 11 = [multtwo 4 11]"
}

---- cut here -----------------------------------------------------------------


This bit of code is the basis for my Hyde package.  Compile a class on the fly,
read the byte codes back in, save in a cache (a Tcl string converted back to
binary), use the java::defineclass to give it to the JVM, then a little
extra glue to make it look like a Tcl procedure.

Here's the code as it looks with hyde:
hyde::jproc int multtwo {int x int y} {
        int result;
        result = x * y;
        return result;
}
puts stderr "int result: multtwo 4 11 = [multtwo 4 11]"


To demostrate the bug, try running:

$ LANG=en_US jaclsh testbinary.tcl
system encoding is ISO-8859-1
int result: multtwo 4 11 = 44

$ LANG=en_US.iso885915  jaclsh testbinary.tcl
system encoding is ISO-8859-15
failed defineclass


I put some debugging code in src/tcljava/tcl/lang/JavaDefineClassCmd.java:

line 47: 
    if (argv.length != 2) {
        throw new TclNumArgsException(interp, 1, argv,
                "classbytes");
    }

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

// print out the bytes codes as ints
for (int i = 0; i < classData.length; i++) {
    Byte b = new Byte(classData[i]);
    System.out.print( b.intValue() );
    System.out.print(" ");
    if ((i % 16) == 0 && i > 0) {
        System.out.println("");
    }
}

    tclClassLoader = new TclClassLoader(interp, null);
    result = tclClassLoader.defineClass(null, classData);




It turns out the with the LANG=en_US.iso885915, the fourth byte in the
class 'cafebabe' signature gets corrupted.  If the class file was
longer, there would probably be additional mangling.


With LANG=en_US, the first 16 bytes are:
-54 -2 -70 -66 0 0 0 46 0 15 10 0 3 0 12 7 0

With LANG=en_US.iso885915:
-54 -2 -70 63 0 0 0 46 0 15 10 0 3 0 12 7 0


To note, the LANG=en_US.iso885915 was set on some Linux machine, for some
version of RedHat.  I shorten it to 'en_US' in the /etc/sysconfig/i18n
file.

Perhaps there is some magic to coerce the bytes to be in the right order with
the 'encoding' command, but I haven't found it yet.



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.


The companion patch is to init.tcl to add the JACL_LIBRARY to auto_path.
My shell script does several things I find invaluable, the first and 
foremost is using alternate JDK and Jacl flag settings.  I'm doing a lot of
EJB testing with Jacl.  Running IBM WebSphere is happiest when using the
IBM JDK.  I also need to pass other -Dxx=yy properties to make Jacl connect
as an EJB client, e.g.:

# run test script under WebSphere
JAVA_HOME=$WAS_HOME/java
CLASSPATH=<way long class path omitted>
WAS_PROPS="-Dws.ext.dirs=$WAS_HOME/classes:$WAS_HOME/lib/ext:$WAS_HOME/lib:$WAS_
HOME/web/help:$WAS_HOME/properties:$DBDRIVER_PATH:$WAS_USER_DIRS -Dserver.root=$
WAS_HOME"
export JACL_FLAGS="-ms5m -mx22m"
export JACL_PROPS="$WAS_PROPS"
jaclsh blah.tcl



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



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.


My current patch:


--- ../tcljava.cvs/jaclsh.in	2002-07-23 09:07:17.000000000 -0600
+++ jaclsh.in	2003-03-12 13:20:08.000000000 -0700
@@ -11,6 +11,13 @@
 # Copyright (c) 1998, 1999, 2000 Moses DeJong
 # All Rights Reserved, see license.terms for license information.
 
+# User environment variables that affect this script:
+#  JAVA_HOME      path to java home, in order to use alternate jvm
+#  CLASSPATH      additional classpaths
+#  JACL_LIBRARY   path to package library dir, defaults to Jacl jar library dir
+#  JACL_FLAGS     java jvm flags for jacl
+#  JACL_PROPS     extra -Dxxx=yyy properties to pass to jvm
+
 # Install prefix for jacl package, defaults to /usr/local
 prefix=@prefix@
 
@@ -21,21 +28,43 @@
 # includes the .jar files and any .tcl files
 XP_TCLJAVA_INSTALL_DIR=${prefix}/lib/tcljava${TCLJAVA_VERSION}
 
+# Directory where swank jar lives
+XP_SWANK_INSTALL_DIR=${XP_TCLJAVA_INSTALL_DIR}
+
+# Set jacl.tcllibpath from JACL_LIBRARY or default
+JACL_LIBPATH="-Djacl.tcllibpath=${JACL_LIBRARY:-$XP_TCLJAVA_INSTALL_DIR}"
+
 # Add the .jar library files to the CLASSPATH
-JACL_CLASSPATH=@JAVA_CLASSPATH@:${XP_TCLJAVA_INSTALL_DIR}/tcljava.jar:${XP_TCLJAVA_INSTALL_DIR}/jacl.jar:
+# Check if running jaclsh or wisk, use the corresponding shell and classpath
+if [ `basename $0` = "wisk" ] ; then
+   JACL_SHELL=tcl.lang.SwkShell
+   JACL_CLASSPATH=@JAVA_CLASSPATH@:${XP_SWANK_INSTALL_DIR}/swank.jar:${XP_TCLJAVA_INSTALL_DIR}/tcljava.jar:${XP_TCLJAVA_INSTALL_DIR}/jacl.jar
+else
+   JACL_SHELL=tcl.lang.Shell
+   JACL_CLASSPATH=@JAVA_CLASSPATH@:${XP_TCLJAVA_INSTALL_DIR}/tcljava.jar:${XP_TCLJAVA_INSTALL_DIR}/jacl.jar
+fi
+
 
 # Fully qualified path name of JVM executable
-JAVA=@JAVA@
+if [ "$JAVA_HOME" -a -x $JAVA_HOME/bin/java ] ; then
+    JAVA=$JAVA_HOME/bin/java
+else
+    JAVA=@JAVA@
+fi
+
 
 # The arguments to the JAVA command
-JAVA_FLAGS="@JAVA_FLAGS@"
+DEFAULT_JACL_FLAGS="@JAVA_FLAGS@"
+JACL_FLAGS="${JACL_FLAGS:-$DEFAULT_JACL_FLAGS}"
 
 # Run java with the args passed in from the calling environment
 # We must set the CLASSPATH env var instead of using the -classpath
 # argument because jacl might want to exec a program that also
 # depends on the CLASSPATH setting and Java can not export env vars
 
-CLASSPATH=${JACL_CLASSPATH}:${CLASSPATH}
+CLASSPATH=${JACL_CLASSPATH}${CLASSPATH:+:${CLASSPATH}}
 export CLASSPATH
 
-exec ${JAVA} ${JAVA_FLAGS} tcl.lang.Shell ${1+"$@"}
+# Allow other user specified properties to be passed via JACL_PROPS env variable
+
+exec ${JAVA} ${JACL_FLAGS} ${JACL_LIBPATH} ${JACL_PROPS} ${JACL_SHELL} ${1+"$@"}
--- ../tcljava.cvs/src/tcljava/tcl/lang/TCL.java	2002-07-23 09:07:17.000000000 -0600
+++ src/tcljava/tcl/lang/TCL.java	2003-03-12 11:47:01.000000000 -0700
@@ -59,7 +59,7 @@
 // the completion code TCL.OK.  If the desired completion code is TCL.OK, no
 // exception should be thrown.
 
-static final int OK = 0;
+public static final int OK = 0;
 
 // The following value is used by the Interp::commandComplete(). It's used
 // to report that a script is not complete.
--- ../tcljava.cvs/src/jacl/tcl/lang/Interp.java	2003-03-10 16:35:39.000000000 -0700
+++ src/jacl/tcl/lang/Interp.java	2003-03-12 11:46:31.000000000 -0700
@@ -3749,7 +3749,7 @@
  *----------------------------------------------------------------------
  */
 
-void
+public void
 allowExceptions()
 {
     evalFlags |= Parser.TCL_ALLOW_EXCEPTIONS;
--- ../tcljava.cvs/src/jacl/tcl/lang/library/init.tcl	2002-07-23 09:07:17.000000000 -0600
+++ src/jacl/tcl/lang/library/init.tcl	2003-03-12 12:04:08.000000000 -0700
@@ -34,6 +34,12 @@
 #    }
 #}
 
+# include jacl/tcljava library path if passed as a system property
+
+if {[info exists env(jacl.tcllibpath)]} {
+	lappend auto_path $env(jacl.tcllibpath)
+}
+
 if {[lsearch -exact $auto_path [info library]] < 0} {
     lappend auto_path [info library]
 }






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

Re: [tcljava-dev] PATCH: Enhancement to Shell.java

[Shawn B. <sh...@qc...>]

Mo,

Your recent email regarding Shell.java changes reminded me of my Shell 
patch.
Any thoughts?

-Shawn

Shawn Boyce wrote:

> I have attached some enhancements I've made to Shell.java
> in the hope that they can be incorporated into the source tree.
> I've been using these changes in our Tcl-based simulators for
> awhile now.
>
> The purpose of these changes are to allow the Shell to
> be used by an application, but with
> * a custom command prompt instead of "% "
> * a custom interpreter,
> * support tcl_rcFileName
>
> The changes keep the same API with a new method
> called startShell
> public static void startShell( Interp interp, String[] args, String 
> prompt );
>
> ChangeLog:
> 2002-06-12  Shawn Boyce <sh...@qc...>
>    *  src/jacl/tcl/lang/Shell.java
>    new method startShell which accepts an Interp and prompt String
>    main(): modified to use invoke the startShell method
>        support tcl_rcFileName Tcl var by evaluating the named file if set
>      
>
>------------------------------------------------------------------------
>
>Index: src/jacl/tcl/lang/Shell.java
>===================================================================
>RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Shell.java,v
>retrieving revision 1.11
>diff -u -r1.11 Shell.java
>--- src/jacl/tcl/lang/Shell.java	12 Apr 2002 21:00:27 -0000	1.11
>+++ src/jacl/tcl/lang/Shell.java	12 Jun 2002 20:57:27 -0000
>@@ -48,13 +48,23 @@
> main(
>     String args[]) 	// Array of command-line argument strings.
> {
>-    String fileName = null;
>-
>     // Create the interpreter. This will also create the built-in
>     // Tcl commands.
> 
>     Interp interp = new Interp();
> 
>+    startShell( interp, args, "% " );
>+}
>+	
>+
>+public static void 
>+startShell(
>+    Interp interp,
>+    String args[], 	// Array of command-line argument strings.
>+    String prompt )
>+{
>+    String fileName = null;
>+
>     // Make command-line arguments available in the Tcl variables "argc"
>     // and "argv".  If the first argument doesn't start with a "-" then
>     // strip it off and use it as the name of a script file to process.
>@@ -94,6 +104,36 @@
>     // Normally we would do application specific initialization here.
>     // However, that feature is not currently supported.
> 
>+    // Source the RCfile
>+    try
>+    {
>+	    TclObject rc_obj = interp.getVar("tcl_rcFileName", TCL.GLOBAL_ONLY);
>+	    if ( rc_obj != null )
>+	    {
>+		    try 
>+		    {
>+			    interp.evalFile( rc_obj.toString() );
>+		    }
>+		    catch ( TclException e )
>+		    {
>+			    int code = e.getCompletionCode();
>+			    if (code == TCL.RETURN) {
>+				    code = interp.updateReturnInfo();
>+				    if (code != TCL.OK) {
>+					    System.err.println("command returned bad code: " + code);
>+				    }
>+			    } else if (code == TCL.ERROR) {
>+				    System.err.println(interp.getResult().toString());
>+			    } else {
>+				    System.err.println("command returned bad code: " + code);
>+			    }
>+		    }
>+	    }
>+    }
>+    catch ( TclException ee )
>+    {
>+    }
>+    
>     // If a script file was specified then just source that file
>     // and quit.
> 
>@@ -131,7 +171,7 @@
> 	// We are running in interactive mode. Start the ConsoleThread
> 	// that loops, grabbing stdin and passing it to the interp.
> 
>-	ConsoleThread consoleThread = new ConsoleThread(interp);
>+	ConsoleThread consoleThread = new ConsoleThread(interp, prompt);
> 	consoleThread.setDaemon(true);
> 	consoleThread.start();
> 
>@@ -180,6 +220,8 @@
> private Channel out;
> private Channel err;
> 
>+protected String _prompt = "% ";
>+
> // set to true to get extra debug output
> private static final boolean debug = false;
> 
>@@ -240,6 +282,16 @@
> 
>     out = TclIO.getStdChannel(StdChannel.STDOUT);
>     err = TclIO.getStdChannel(StdChannel.STDERR);
>+
>+}
>+	
>+
>+ConsoleThread(
>+    Interp i,			// Initial value for interp.
>+    String prompt)              // prompt to be used
>+{
>+    this( i );
>+    _prompt = prompt;
> }
> 
> /*
>@@ -267,7 +319,7 @@
>     }
> 
> 
>-    put(out, "% ");
>+    put(out, _prompt);
> 
>     while (true) {
> 	// Loop forever to collect user inputs in a StringBuffer.
>@@ -383,10 +435,10 @@
> 			try {
> 			    interp.eval(prompt.toString(), TCL.EVAL_GLOBAL);
> 			} catch (TclException e) {
>-			    put(out, "% ");
>+			    put(out, _prompt);
> 			}
> 		    } else {
>-			put(out, "% ");
>+			put(out, _prompt);
> 		    }
> 
> 		    return 1;
>  
>

Re: [tcljava-dev] Ready for a tcljava 1.3.0 release?

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

On Thu, 13 Mar 2003 12:21:04 -0500
"Johnson, Bruce A" <bru...@me...> wrote:

> An official 1.3.0 release would be excellent (and thanks Mo for the work on
> the new IO!).
> I would like to check and see if the new version of SWANK works without any
> changes needed in Jacl.  I'll try to check it tonight.

Be sure to take a look at the other note I posted today, about removing TCL.OK
from user code.

cheers
Mo

Re: [tcljava-dev] PATCH: Jacl

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

On Sun, 4 Aug 2002 14:06:28 -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.

Tom, could you explain why this patch is needed, in ChangeLog format?

--- tcljava/src/jacl/tcl/lang/library/init.tcl	Sat May  5 16:38:13 2001
+++ tcljava.tp/src/jacl/tcl/lang/library/init.tcl	Fri Jul 12 14:28:19 2002
@@ -34,6 +34,12 @@
 #    }
 #}
 
+# include jacl/tcljava library path if passed as a system property
+
+if {[info exists env(jacl.tcllibpath)]} {
+	lappend auto_path $env(jacl.tcllibpath)
+}
+
 if {[lsearch -exact $auto_path [info library]] < 0} {
     lappend auto_path [info library]
 }

cheers
Mo

Re: [tcljava-dev] PATCH: Jacl

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

On Sun, 4 Aug 2002 14:06:28 -0600
Tom Poindexter <tpo...@ny...> wrote:

...

> 8. TCL.java: change scope of OK to public, for use by Swank.

I still don't get why folks keep asking for this change. The TCL.OK
value should not be needed outside the Jacl package.

...

So, after a bit of poking around it seems that Shell.java should not
even be calling updateReturnInfo() or checking to see if the value
is TCL.OK since this is already taken care of in interp.eval(). I just
checked the following into the CVS, it removes the refs to TCL.OK.
Other shells that do the same, like Swank should make this
change too.

2003-03-13  Mo DeJong  <md...@us...>

	* extras/GuiShell/GuiShell.java (processCommand):
	Remove call to interp.updateReturnInfo() and
	check for TCL.OK. This is already handled by
	the interp.eval() method.
	* src/jacl/tcl/lang/Shell.java (processEvent):
	Remove call to interp.updateReturnInfo() and
	check for TCL.OK. This is already handled by
	the interp.eval() method.

Index: extras/GuiShell/GuiShell.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/extras/GuiShell/GuiShell.java,v
retrieving revision 1.1
diff -u -r1.1 GuiShell.java
--- extras/GuiShell/GuiShell.java	8 May 1999 05:19:00 -0000	1.1
+++ extras/GuiShell/GuiShell.java	13 Mar 2003 22:26:05 -0000
@@ -225,16 +225,7 @@
     } else {
       TclException e = evt.evalException;
       int code = e.getCompletionCode();
-      
-      check_code: {
-	if (code == TCL.RETURN) {
-	  code = interp.updateReturnInfo();
-	  if (code == TCL.OK) {
-	    break check_code;
-	  }
-	}
-	
-	switch (code) {
+      switch (code) {
 	case TCL.ERROR:
 	  append(interp.getResult().toString());
 	  append("\n");
@@ -247,7 +238,6 @@
 	  break;
 	default:
 	  append("command returned bad code: " + code + "\n");
-	}
       }
     }
     
Index: src/jacl/tcl/lang/Shell.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Shell.java,v
retrieving revision 1.12
diff -u -r1.12 Shell.java
--- src/jacl/tcl/lang/Shell.java	8 Mar 2003 03:42:44 -0000	1.12
+++ src/jacl/tcl/lang/Shell.java	13 Mar 2003 22:26:07 -0000
@@ -322,16 +322,7 @@
 			}
 
 			int code = e.getCompletionCode();
-
-		    check_code: {
-			    if (code == TCL.RETURN) {
-				code = interp.updateReturnInfo();
-				if (code == TCL.OK) { // FIXME : TCL.OK not accessable outside!!
-				    break check_code;
-				}
-			    }
-
-			    switch (code) {
+			switch (code) {
 			    case TCL.ERROR:
 				// This really sucks. The getMessage() call on
 				// a TclException will not always return a msg.
@@ -346,7 +337,6 @@
 				break;
 			    default:
 				putLine(err, "command returned bad code: " + code);
-			    }
 			}
 		    } finally {
 			commandObj.release();

RE: [tcljava-dev] Ready for a tcljava 1.3.0 release?

[Johnson, B. A <bru...@me...>]

An official 1.3.0 release would be excellent (and thanks Mo for the work on
the new IO!).
I would like to check and see if the new version of SWANK works without any
changes needed in Jacl.  I'll try to check it tonight.

Bruce



-----Original Message-----
From: Shawn Boyce [mailto:sh...@qc...]
Sent: Thursday, March 13, 2003 12:03 PM
To: Mo DeJong
Cc: tcl...@li...
Subject: Re: [tcljava-dev] Ready for a tcljava 1.3.0 release?


Mo,

Mo DeJong wrote:

>So, I have been doing quite a bit of hacking on Jacl and Tcl Blend recently
>and I think it is about time to put a 1.3.0 release together. I have looked
over
>my TODO lists and I think most of the big problems are now fixed. The
>current CVS is so much better than 1.2.6, I don't even know where to
>begin.
>  
>
Yes, we've been using an "unofficial" 1.3.0 version. Its definitely a 
good time for an official release.

>I want to ask folks what problems they think still remain in the
>current codebase. I am looking for things serious enough that
>they should be fixed now, before pushing this code out to lots of
>users. Any feedback you folks could provide would be great.
>  
>
We don't have any specific problems that require fixing. They have all 
been addressed to date.

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





-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev


------------------------------------------------------------------------------
Notice:  This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message.  If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it.

==============================================================================

Re: [tcljava-dev] Ready for a tcljava 1.3.0 release?

[Shawn B. <sh...@qc...>]

Mo,

Mo DeJong wrote:

>So, I have been doing quite a bit of hacking on Jacl and Tcl Blend recently
>and I think it is about time to put a 1.3.0 release together. I have looked over
>my TODO lists and I think most of the big problems are now fixed. The
>current CVS is so much better than 1.2.6, I don't even know where to
>begin.
>  
>
Yes, we've been using an "unofficial" 1.3.0 version. Its definitely a 
good time for an official release.

>I want to ask folks what problems they think still remain in the
>current codebase. I am looking for things serious enough that
>they should be fixed now, before pushing this code out to lots of
>users. Any feedback you folks could provide would be great.
>  
>
We don't have any specific problems that require fixing. They have all 
been addressed to date.

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

[tcljava-dev] Ready for a tcljava 1.3.0 release?

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

So, I have been doing quite a bit of hacking on Jacl and Tcl Blend recently
and I think it is about time to put a 1.3.0 release together. I have looked over
my TODO lists and I think most of the big problems are now fixed. The
current CVS is so much better than 1.2.6, I don't even know where to
begin.

I want to ask folks what problems they think still remain in the
current codebase. I am looking for things serious enough that
they should be fixed now, before pushing this code out to lots of
users. Any feedback you folks could provide would be great.

cheers
Mo

[tcljava-dev] New IO subsystem for Jacl checked in

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

Hey all.

It took quite some doing, but I finally managed to get a port of the
Tcl IO subsystem working in Jacl. I just checked it into the CVS.
It supports binary IO as well as encoded IO and all the normal
fconfigure options should be working now. Jacl now does all
its own buffering and character conversion. Jacl should now
do IO exactly the same as Tcl, except that fileevent is not
yet implemented so you can't do async IO.

This implementation is not optimized yet, there are still some
things that could be done to avoid some buffer allocation but
it does pass almost all of the test cases. The only real bummer
is the fact that I had to use the sun.io.CharToByteConverter
and sun.io.ByteToCharConverter classes because there is no
Java API that supports character conversion. There are some
new character conversion classes in JDK 1.4, but adding
that support is still on the TODO list.

cheers
Mo

Re: [tcljava-dev] PATCH: stdout flushing, mods for Swank

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

On Sun, 30 Jun 2002 23:00:21 -0600
Tom Poindexter <tpo...@ny...> wrote:

> Here's a patch that is similar in function to Shawn Boyce's recent
> patch, but works by only causing a flush on stdout when it is attached
> to a tty.  Shawn's patch causes a flush for every puts on every file, which
> seems a little heavy handed.

I ended up doing the following:

1. Flush stdout when in line buffering mode and a \n is the last char of the data.
2. Invoke close() for each channel when tearing down an interp.
3. Invoke flush() one last time from the close method for StdChannel
4. Remove the extra buffering for stderr and stdout

The following two patches implement these changes.

Index: ChangeLog
===================================================================
RCS file: /cvsroot/tcljava/tcljava/ChangeLog,v
retrieving revision 1.224
diff -u -r1.224 ChangeLog
--- ChangeLog	14 Feb 2003 23:26:56 -0000	1.224
+++ ChangeLog	5 Mar 2003 22:54:32 -0000
@@ -1,3 +1,12 @@
+2003-03-05  Mo DeJong  <md...@us...>
+
+	* src/jacl/tcl/lang/StdChannel.java (open, write):
+	Avoid wrapping a buffered IO object around the
+	stdio and stderr streams since this was causing
+	problems where stdout was not being flushed.
+	Instead, explicitly handle flushing in the
+	write method.
+
 2003-02-14  Mo DeJong  <md...@us...>
 
 	* Makefile.in: Build a jar file named hello.jar
Index: src/jacl/tcl/lang/StdChannel.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/StdChannel.java,v
retrieving revision 1.16
diff -u -r1.16 StdChannel.java
--- src/jacl/tcl/lang/StdChannel.java	23 Jan 2002 09:53:49 -0000	1.16
+++ src/jacl/tcl/lang/StdChannel.java	5 Mar 2003 22:54:32 -0000
@@ -97,19 +97,11 @@
 	        mode = TclIO.WRONLY;
 	        setBuffering(TclIO.BUFF_LINE);
 	        setChanName("stdout");
-		if (writer == null) {
-		    writer = new BufferedWriter(
-                        new OutputStreamWriter(System.out)); 
-		}
 		break;
 	    case STDERR:
 	        mode = TclIO.WRONLY;
 	        setBuffering(TclIO.BUFF_NONE);
 	        setChanName("stderr");
-		if (writer == null) {
-		    writer = new BufferedWriter(
-                        new OutputStreamWriter(System.err)); 
-		}
 		break;
 	    default:
 		throw new RuntimeException(
@@ -133,13 +125,18 @@
     void write(Interp interp, TclObject outData) 
             throws IOException, TclException {
 
-        super.write(interp, outData);
+        checkWrite(interp);
 
-        // The OutputStreamWriter class will buffer even if you don't
-        // wrap it in a BufferedWriter. The stderr file object must
-        // not require an explicit flush so we just hack a flush in.
-        if (stdType == STDERR)
-            flush(interp);
+        if (stdType == STDERR) {
+            System.err.print(outData.toString());
+        } else {
+            String s = outData.toString();
+            System.out.print(s);
+            if (buffering == TclIO.BUFF_NONE ||
+                    (buffering == TclIO.BUFF_LINE && s.endsWith("\n"))) {
+                System.out.flush();
+            }
+        }
     }
 
     String getChanType() {


Index: ChangeLog
===================================================================
RCS file: /cvsroot/tcljava/tcljava/ChangeLog,v
retrieving revision 1.225
diff -u -r1.225 ChangeLog
--- ChangeLog	5 Mar 2003 22:57:54 -0000	1.225
+++ ChangeLog	5 Mar 2003 23:18:21 -0000
@@ -1,3 +1,14 @@
+2003-03-05  Tom Poindexter  <tpo...@ny...>,
+            Mo DeJong  <md...@us...>
+
+	* src/jacl/tcl/lang/Interp.java (eventuallyDispose):
+	* src/jacl/tcl/lang/StdChannel.java (close): Invoke
+	the close() method for any remaining channel
+	when the interp is being disposed of. The close
+	method in the StdChannel class will invoke flush
+	one final time for stdout in case there was output
+	that had not yet been flushed.
+
 2003-03-05  Mo DeJong  <md...@us...>
 
 	* src/jacl/tcl/lang/StdChannel.java (open, write):
Index: src/jacl/tcl/lang/Interp.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Interp.java,v
retrieving revision 1.41
diff -u -r1.41 Interp.java
--- src/jacl/tcl/lang/Interp.java	9 Jan 2003 02:15:39 -0000	1.41
+++ src/jacl/tcl/lang/Interp.java	5 Mar 2003 23:18:23 -0000
@@ -542,6 +542,18 @@
 	}
     }
 
+    // Close any remaining channels
+
+    for (Enumeration e = interpChanTable.keys(); e.hasMoreElements();) {
+	Object key = e.nextElement();
+	Channel chan = (Channel) interpChanTable.get(key);
+	try {
+	    chan.close();
+	} catch (IOException ex) {
+	    // Ignore any IO errors
+	}
+    }
+
     // Finish deleting the global namespace.
     
     // FIXME : check impl of Tcl_DeleteNamespace
Index: src/jacl/tcl/lang/StdChannel.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/StdChannel.java,v
retrieving revision 1.17
diff -u -r1.17 StdChannel.java
--- src/jacl/tcl/lang/StdChannel.java	5 Mar 2003 22:57:59 -0000	1.17
+++ src/jacl/tcl/lang/StdChannel.java	5 Mar 2003 23:18:23 -0000
@@ -139,6 +139,18 @@
         }
     }
 
+    /**
+     * Check for any output that might still need to be flushed
+     * when the channel is closed.
+     */
+
+    void close() throws IOException {
+        super.close();
+
+        if (stdType == STDOUT)
+            System.out.flush();
+    }
+
     String getChanType() {
         return "tty";
     }


cheers
Mo DeJong

[tcljava-dev] New Jacl and Tcl Blend build system for Windows checked in

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

Hello all

I just finished an initial implementation of Windows build support for
Jacl and Tcl Blend. This implementation uses msys+mingw and the
toplevel configure/make to build under Windows. All those folks that
complained about needing VC++ to build Tcl Blend or Jacl should
be much happier now. Please test it out, just note that you will need
to use CVS versions of Tcl and the Thread package for now.

cheers
Mo

Re: [tcljava-dev] Proposed patch for passing multiple args to JVM

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

On Wed, 8 May 2002 12:01:27 -0500
"Mark Thornton" <mar...@am...> wrote:

> I have made a change to the JavaInitEnv() method in javaCmd.c
> that allows multiple arguments to be passed to the JVM
> (via tclblend_init) when initialized

Hi Mark.

I just checked a modified version of this patch into the CVS.
It treats tclblend_init as a Tcl list so that arguments with spaces
in them will be passed correctly.

Thanks for the patch.
Mo

[tcljava-dev] Request for eyes, can anyone figure out what this code is for?

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

Hello all

While looking at the JNI code for Tcl Blend, I ran into a very strange
thing in SetJavaCmdFromAny in javaObj.c. As far as I can tell, there
is no reason to handle a Tcl_Obj of type tclObjectType from one that
has a cmdTypePtr with a non-NULL ptr2. The existing code
will increment the TclObject.refCount and create a new global
JNI ref and then let it get deleted while freeing up the old object
internal rep. I just can't figure out for the life of me why this is
being done. I decided to remove the code to see if that broke anything,
and it did not cause any failures in the test suite.

I feel like I might just be missing something, so I was wondering if
someone else could take a look at this issue and see what you come
up with. I am planning on applying the appended patch.

cheers
Mo



Here is a test case:

package require java
append env(TCL_CLASSPATH) .

namespace eval foo {
    proc test {obj} {
        $obj nothing
    }
}

set obj [java::new JT]

$obj nothing

foo::test $obj



% cat JT.java 
import tcl.lang.*;

public class JT {
    public void nothing() {}
    public String toString() {return "JT";}
}





And the patch for javaObj.c:

Index: src/native/javaObj.c
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/native/javaObj.c,v
retrieving revision 1.13
diff -u -r1.13 javaObj.c
--- src/native/javaObj.c	21 Dec 2002 04:02:53 -0000	1.13
+++ src/native/javaObj.c	23 Dec 2002 01:34:26 -0000
@@ -873,45 +875,22 @@
 
     /*
      * Invoke the normal command type routine, but make sure
-     * it doesn't free the java object.  Note that we have to
-     * restore the ptr2 value after the conversion, since it gets
-     * set to NULL by the setFromAnyProc.
+     * it doesn't free the java object by setting the typePtr
+     * to NULL. Note that we have to restore the ptr2 value after
+     * the conversion, since it gets set to NULL by setFromAnyProc.
      */
 
-    if (objPtr->typePtr == &tclObjectType) {
+    if ((objPtr->typePtr == &tclObjectType) ||
+	    ((objPtr->typePtr == cmdTypePtr) &&
+	    (objPtr->internalRep.twoPtrValue.ptr2 != NULL))) {
 	VOID *ptr2;
 	if (objPtr->bytes == NULL) {
-	    UpdateTclObject(objPtr);	
+	    UpdateTclObject(objPtr);
 	}
 	objPtr->typePtr = NULL;
 	ptr2 = objPtr->internalRep.twoPtrValue.ptr2;
 	result = (oldCmdType.setFromAnyProc)(interp, objPtr);
 	objPtr->internalRep.twoPtrValue.ptr2 = ptr2;
-    } else if ((objPtr->typePtr == cmdTypePtr)
-	    && (objPtr->internalRep.twoPtrValue.ptr2 != NULL)) {
-	jobject object = (jobject)(objPtr->internalRep.twoPtrValue.ptr2);
-	JNIEnv *env = JavaGetEnv();
-	JavaInfo* jcache = JavaGetCache();
-
-	/*
-	 * If we are converting from something that is already a java command
-	 * reference we need to preserve the object handle so that it doesn't
-	 * get freed as a side effect of updating the command cache.  Note
-	 * that the new command may not refer to a java object, but we will
-	 * maintain the extra reference anyway since it is difficult to
-	 * detect this case.  The object reference will still be cleaned up
-	 * when the Tcl object is free.
-	 */
-
-	object = (*env)->NewGlobalRef(env, object);
-	(*env)->CallVoidMethod(env, object, jcache->preserve);
-	result = (oldCmdType.setFromAnyProc)(interp, objPtr);
-	if (result != TCL_OK) {
-	    (*env)->CallVoidMethod(env, object, jcache->release);
-	    (*env)->DeleteGlobalRef(env, object);
-	} else {
-	    objPtr->internalRep.twoPtrValue.ptr2 = (VOID*) object;
-	}
     } else {
 	result = (oldCmdType.setFromAnyProc)(interp, objPtr);
 
@@ -919,9 +898,8 @@
 	 * Ensure that the ptr2 is null for non-java commands.
 	 */
 
-	if (result == TCL_OK) {
-	    objPtr->internalRep.twoPtrValue.ptr2 = NULL;
-	}
+	if (objPtr->internalRep.twoPtrValue.ptr2 != NULL)
+	    panic("post setFromAnyProc, ptr2 is not NULL");
     }
     return result;
 }