tcljava-dev — discuss implementation and post patches here

[tcljava-dev] jacl tests

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

Mo,

Some of the tests seem to be JDK specific (not expecting new methods
available in later JDK's) Which JDK should they be run
against? 1.1?

-Shawn

Re: [tcljava-dev] Problem using configure

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

Thanks very much! It seems to be working.

Sorry I didn't get a chance to look at 
tcljava.m4 myself. I don't have the build environment 
for this at work.

On Sun, 2002-04-14 at 06:59, Mo DeJong wrote:
> On Fri, 12 Apr 2002 04:40:42 -0700
> Mo DeJong <su...@ba...> wrote:
> 
> > On Thu, 11 Apr 2002 22:47:10 -0400
> > Shawn Boyce <sh...@bo...> wrote:
> > 
> > > I get the following error when using configure on RedHat Linux 7.2
> > > and Sun JDK 1.3.1.
> 
> ...
> 
> > > could not link file that includes jni.h
> > >         It is likely that your JVM install is broken or corrupted.
> 
> ...
> 
> > Could you open up tcljava.m4 in your editor and have a look at
> > the AC_JAVA_JNI_LIBS macro? Inside that macro there are
> > some lib location checks that end up setting the variable
> > ac_java_jvm_jni_lib_flags.
> 
> I just added support for Sun JDK 1.3 and 1.4 under Linux. It seems
> to work alright except that the tclblend/javaObj.test file makes the VM
> core dump.
> 
> cheers
> Mo
> 
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] [PATCH] Fix for Problem with loading package inside namespace

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

Great.

You can close the bugs I opened
#541613 and 541612


On Fri, 2002-04-12 at 09:07, Mo DeJong wrote:
> On Tue, 09 Apr 2002 10:59:13 -0400
> Shawn Boyce <sh...@qc...> wrote:
> 
> > I took a look at the Tcl sources and Jacl sources.
> > The Tcl code invokes Tcl_GlobalEval to evaluate package
> > scripts. The Jacl code invokes Interp.eval with the GLOBAL_ONLY
> > flag. However this flag is essentially ignored down inside of eval/eval2
> > To get the same type of functionality as Tcl_GlobalEval, the
> > EVAL_GLOBAL flag must be set. This fixes the problem.
> > 
> > The one-line patch is attached.
> 
> Ugh, you found quite a nasty bug there. I poked around and found a
> couple of additional places where this error shows up. I just checked
> in a patch that fixes them all. Thanks for looking into this.
> 
> Mo
> 
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] Problem using configure

[Mo D. <su...@ba...>]

On Fri, 12 Apr 2002 04:40:42 -0700
Mo DeJong <su...@ba...> wrote:

> On Thu, 11 Apr 2002 22:47:10 -0400
> Shawn Boyce <sh...@bo...> wrote:
> 
> > I get the following error when using configure on RedHat Linux 7.2
> > and Sun JDK 1.3.1.

...

> > could not link file that includes jni.h
> >         It is likely that your JVM install is broken or corrupted.

...

> Could you open up tcljava.m4 in your editor and have a look at
> the AC_JAVA_JNI_LIBS macro? Inside that macro there are
> some lib location checks that end up setting the variable
> ac_java_jvm_jni_lib_flags.

I just added support for Sun JDK 1.3 and 1.4 under Linux. It seems
to work alright except that the tclblend/javaObj.test file makes the VM
core dump.

cheers
Mo

Re: [tcljava-dev] [PATCH] Performance improvement

[Mo D. <su...@ba...>]

On Tue, 09 Apr 2002 16:52:32 -0400
Shawn Boyce <sh...@qc...> wrote:

> Using a Profiler, I found a hot spot in Expression.java.
> The code attempts to see if the parsed value is an integer (or double).
> Unfortunately, it is passing non-numbers into strtod which is throwing
> an expensive RuntimeException.
> 
> The attached fix was straightforward and borrows from the Tcl C code.

Nice work. Your patch was added to the CVS on 2002-04-13.

cheers
Mo

Re: [tcljava-dev] PATCH: file volumes command patch posted

[Mo D. <su...@ba...>]

On Tue, 15 Jan 2002 08:29:18 -0500
Shawn Boyce <sh...@qc...> wrote:

> I have submitted a patch to sourceforge for the file command.
> The "file volumes" command was not implemented. It should
> return the root volume names available on the system.

This patch was checked in on 2002-04-12.

cheers
Mo

Re: [tcljava-dev] [PATCH] Fix for Problem with loading package inside namespace

[Mo D. <su...@ba...>]

On Tue, 09 Apr 2002 10:59:13 -0400
Shawn Boyce <sh...@qc...> wrote:

> I took a look at the Tcl sources and Jacl sources.
> The Tcl code invokes Tcl_GlobalEval to evaluate package
> scripts. The Jacl code invokes Interp.eval with the GLOBAL_ONLY
> flag. However this flag is essentially ignored down inside of eval/eval2
> To get the same type of functionality as Tcl_GlobalEval, the
> EVAL_GLOBAL flag must be set. This fixes the problem.
> 
> The one-line patch is attached.

Ugh, you found quite a nasty bug there. I poked around and found a
couple of additional places where this error shows up. I just checked
in a patch that fixes them all. Thanks for looking into this.

Mo

Re: [tcljava-dev] PATCH: Fix for file copy command

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

That's fine. The code that was there had no chance of working!
One of our testers came across the copy problem while trying to write a 
Tcl script
to copy a file.

Mo DeJong wrote:

>On 27 Mar 2002 07:12:25 -0500
>Shawn Boyce <sh...@qc...> wrote:
>
>>The file copy command does not work. e.g.
>>% file copy a b
>>error copying: null
>>
>>Attached is the patch for FileCmd.java
>>
>
>Now that you mention it, I don't even see why the file data is being treated as
>encoded text here. How about this patch instead? It copies the data as binary
>while also including your fix for the array bounds.
>
>cheers
>Mo
>
>2002-04-12  Shawn Boyce  <sh...@qc...>
>
>	* src/jacl/tcl/lang/FileCmd.java (copyRenameOneFile):
>	Treat data copied via 'file copy' as binary. Fix
>	array bound bug that was causing the copy command
>	to fail.
>
>Index: src/jacl/tcl/lang/FileCmd.java
>===================================================================
>RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/FileCmd.java,v
>retrieving revision 1.6
>diff -u -r1.6 FileCmd.java
>--- src/jacl/tcl/lang/FileCmd.java	12 Apr 2002 18:13:37 -0000	1.6
>+++ src/jacl/tcl/lang/FileCmd.java	12 Apr 2002 19:18:05 -0000
>@@ -1161,24 +1164,21 @@
> 	// Perform the copy procedure.
> 
> 	try {
>-	    // Read source to "cbuf" char array one line at a time.
>-	    // For each line, Write cbuf to target.
>-
>-	    BufferedReader reader = 
>-		new BufferedReader(new FileReader(sourceFileObj));
>-	    BufferedWriter writer = 
>-		new BufferedWriter(new FileWriter(targetFileObj));
>-	    char cbuf[] = new char[256];
>-	    int currentIndex = 0;
>-	    int numChars = reader.read(cbuf, 0, 256);
>-	    while (numChars != -1) {
>-		writer.write(cbuf, currentIndex, numChars); 
>-		currentIndex += 256;
>-		numChars = reader.read(cbuf, currentIndex, 256);
>-	    }
>-	    reader.close();
>-	    writer.close();
>-	} catch (Exception e) {
>+            BufferedInputStream bin = new BufferedInputStream(
>+                new FileInputStream(sourceFileObj));
>+            BufferedOutputStream bout = new BufferedOutputStream(
>+                new FileOutputStream(targetFileObj));
>+
>+            final int bsize = 1024;
>+            byte[] buff = new byte[bsize];
>+            int numChars = bin.read(buff, 0, bsize);
>+            while (numChars != -1) {
>+                bout.write(buff, 0, numChars);
>+                numChars = bin.read(buff, 0, bsize);
>+            }
>+            bin.close();
>+            bout.close();
>+	} catch (IOException e) {
> 	    throw new TclException(interp, "error copying: " + e.getMessage());
> 	}
>     }
>
>_______________________________________________
>tcljava-dev mailing list
>tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
>

-- 
Shawn Boyce
QCOM, Inc.   
Quality Software is Our Business
http://www.qcominc.com

Re: [tcljava-dev] Problem using configure

[Mo D. <su...@ba...>]

On Thu, 11 Apr 2002 22:47:10 -0400
Shawn Boyce <sh...@bo...> wrote:

> I get the following error when using configure on RedHat Linux 7.2
> and Sun JDK 1.3.1.
> 
> checking whether cc accepts -g... yes
> Using the following JNI include flags -I/usr/java/jdk1.3.1_02/include
> -I/usr/java/jdk1.3.1_02/include/linux
> checking to see if jni.h can be included... yes
> Using the following JNI library flags
> Using the following runtime library path
> checking to see if we can link a JNI application... configure: error:
> could not link file that includes jni.h
>         It is likely that your JVM install is broken or corrupted.
> 
> -Shawn

I am willing to bet the libs have been moved and the configure script
will need to be updated so that it knows how to detect them in the
new location. It is a real PITA but it needs to be done for just about
every JDK release because it changes every time. Just an FYI,
if you only plan on using Jacl you can pass --enable-jacl to the
configure script and it will skip these Tcl Blend checks.

Could you open up tcljava.m4 in your editor and have a look at
the AC_JAVA_JNI_LIBS macro? Inside that macro there are
some lib location checks that end up setting the variable
ac_java_jvm_jni_lib_flags. Your output seemed to indicate
that this var was not set and that it what caused the linker problem.
Note that you will need to regenerate the configure script with
autoconf 2.5X after making these changes.

cheers
Mo

Re: [tcljava-dev] PATCH: Fix for file copy command

[Mo D. <su...@ba...>]

On 27 Mar 2002 07:12:25 -0500
Shawn Boyce <sh...@qc...> wrote:

> The file copy command does not work. e.g.
> % file copy a b
> error copying: null
> 
> Attached is the patch for FileCmd.java

Now that you mention it, I don't even see why the file data is being treated as
encoded text here. How about this patch instead? It copies the data as binary
while also including your fix for the array bounds.

cheers
Mo

2002-04-12  Shawn Boyce  <sh...@qc...>

	* src/jacl/tcl/lang/FileCmd.java (copyRenameOneFile):
	Treat data copied via 'file copy' as binary. Fix
	array bound bug that was causing the copy command
	to fail.

Index: src/jacl/tcl/lang/FileCmd.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/FileCmd.java,v
retrieving revision 1.6
diff -u -r1.6 FileCmd.java
--- src/jacl/tcl/lang/FileCmd.java	12 Apr 2002 18:13:37 -0000	1.6
+++ src/jacl/tcl/lang/FileCmd.java	12 Apr 2002 19:18:05 -0000
@@ -1161,24 +1164,21 @@
 	// Perform the copy procedure.
 
 	try {
-	    // Read source to "cbuf" char array one line at a time.
-	    // For each line, Write cbuf to target.
-
-	    BufferedReader reader = 
-		new BufferedReader(new FileReader(sourceFileObj));
-	    BufferedWriter writer = 
-		new BufferedWriter(new FileWriter(targetFileObj));
-	    char cbuf[] = new char[256];
-	    int currentIndex = 0;
-	    int numChars = reader.read(cbuf, 0, 256);
-	    while (numChars != -1) {
-		writer.write(cbuf, currentIndex, numChars); 
-		currentIndex += 256;
-		numChars = reader.read(cbuf, currentIndex, 256);
-	    }
-	    reader.close();
-	    writer.close();
-	} catch (Exception e) {
+            BufferedInputStream bin = new BufferedInputStream(
+                new FileInputStream(sourceFileObj));
+            BufferedOutputStream bout = new BufferedOutputStream(
+                new FileOutputStream(targetFileObj));
+
+            final int bsize = 1024;
+            byte[] buff = new byte[bsize];
+            int numChars = bin.read(buff, 0, bsize);
+            while (numChars != -1) {
+                bout.write(buff, 0, numChars);
+                numChars = bin.read(buff, 0, bsize);
+            }
+            bin.close();
+            bout.close();
+	} catch (IOException e) {
 	    throw new TclException(interp, "error copying: " + e.getMessage());
 	}
     }

[tcljava-dev] Jacl Performance

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

First, thanks to Shawn for finding the hotspot in Expression.java.  I 
haven't yet tested this fix with my own code but I'm looking forward to 
seeing some improvement.

Longer term, however, I'd really love to see Jacl have a compiler 
analogous to the byte code compiler in Tcl.  I've done some 
experimentation with compiling Jacl to Java bytecodes using the bytecode 
package from Kawa ( http://www.gnu.org/software/kawa/ ). So far I've 
worked on compiling expressions and it looks very promising.  
Unfortunately, most of the time I have available for Jacl/Swank is 
currently devoted to working through the Tk tests with Swank.  Is 
anybody out there interested in working on the compiler?

cheers,

Bruce

[tcljava-dev] Problem using configure

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

I get the following error when using configure on RedHat Linux 7.2
and Sun JDK 1.3.1.

checking whether cc accepts -g... yes
Using the following JNI include flags -I/usr/java/jdk1.3.1_02/include
-I/usr/java/jdk1.3.1_02/include/linux
checking to see if jni.h can be included... yes
Using the following JNI library flags
Using the following runtime library path
checking to see if we can link a JNI application... configure: error:
could not link file that includes jni.h
        It is likely that your JVM install is broken or corrupted.

-Shawn

[tcljava-dev] [PATCH] Performance improvement

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

I ran the JavaWorld article's Tcl scripts and got similar (but slightly 
slower) results
for the four tests (JDK 1.3.1, Jacl CVS 1.3).

Using a Profiler, I found a hot spot in Expression.java.
The code attempts to see if the parsed value is an integer (or double).
Unfortunately, it is passing non-numbers into strtod which is throwing
an expensive RuntimeException.

The attached fix was straightforward and borrows from the Tcl C code.

The performance improvement is significant:

Test 1 - For loop counting from 1 to 1,000,000
Before: 180 seconds
After:   50 seconds

Test 2 - Compare 1,000,000 integers for equality
Before:  368 seconds
After:    94 seconds

-- 
Shawn Boyce
QCOM, Inc.   
Quality Software is Our Business
http://www.qcominc.com

[tcljava-dev] Poor performance of Jacl

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

This article compares various Java scripting languages.
http://www.javaworld.com/javaworld/jw-04-2002/jw-0405-scripts.html

In all cases, Jacl had the worst performance. It also notes that Jacl has
not had an official release in two years.

-- 
Shawn Boyce
QCOM, Inc.   
Quality Software is Our Business
http://www.qcominc.com

[tcljava-dev] [PATCH] Fix for Problem with loading package inside namespace

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

I took a look at the Tcl sources and Jacl sources.
The Tcl code invokes Tcl_GlobalEval to evaluate package
scripts. The Jacl code invokes Interp.eval with the GLOBAL_ONLY
flag. However this flag is essentially ignored down inside of eval/eval2
To get the same type of functionality as Tcl_GlobalEval, the
EVAL_GLOBAL flag must be set. This fixes the problem.

The one-line patch is attached.

Shawn Boyce wrote:

> I ran into this problem when loading the java package
> inside of a namespace. The java package procedures are
> only visible inside of the namespace. e.g. java::call is
> not visible globally. It must be prefixed by the namespace name.
>
> This does not match the Tcl 8.3 behaviour.
>
> Attached is a test script (and sample package) which exhibits the 
> problem.
>

-- 
Shawn Boyce
QCOM, Inc.   
Quality Software is Our Business
http://www.qcominc.com

Re: [tcljava-dev] Building with cygwin

[Mo D. <su...@ba...>]

On Wed, 27 Mar 2002 10:13:06 -0500
Shawn Boyce <sh...@qc...> wrote:

> Can tcljava be built using cygwin?
> Looks like no.

Not currently.

Mo

[tcljava-dev] Building with cygwin

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

Can tcljava be built using cygwin?
Looks like no.

-- 
Shawn Boyce
QCOM, Inc.   
Quality Software is Our Business
http://www.qcominc.com

[tcljava-dev] PATCH: Fix for file copy command

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

The file copy command does not work. e.g.
% file copy a b
error copying: null

Attached is the patch for FileCmd.java

-Shawn

-- 
-Shawn Boyce
 QCOM, Inc.
 http://www.qcominc.com

Re: [tcljava-dev] Socket stuff - good time to improve?

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

Neil Madden wrote:

>Neil Madden wrote:
>
>>Hi all,
>>
>>OK - my exams are over, and I have some time to look again at my socket
>>code in Jacl. It needs some work. After the messages a while ago about
>>common functionality in the Channel class, is now a good time for me to
>>review the socket code and try and finish it off? i.e. - is the Channel
>>class in a finished state? Also, what is the model for integrating with
>>fconfigure, fileevent etc? Has work begun on fileevent?
>>
>
>I've looked at the new async I/O in Java 1.4, and I think it will be
>much more useful than the current synchronous Java I/O (reminds me quite
>a lot of a long-winded way of doing what Jacl does for I/O anyway).
>However, the calls and classes involved are completely different (for
>both async and synchronous I/O). So, how should I go about this? I think
>I'm going to try and implement asynchronous I/O just using the current
>stuff and Threads for the time being, and then I can think about 1.4. I
>think the best way to get 1.4 IO would be to use conditional execution
>to decide which SocketChannel implementation to load, as it would
>probably have to go into a separate class (it's a rewrite of the entire
>
Agreed. You have to maintain compatibility with Java 1.1/1.2/1.3.

>
>thing for the new APIs). Is anyone thinking of using the new APIs for
>file IO?
>
>Thoughts?
>
>>Cheers,
>>
>>Neil.
>>

-- 
-Shawn Boyce
 QCOM, Inc.   
 Quality Software is Our Business
 http://www.qcominc.com

Re: [tcljava-dev] Socket stuff - good time to improve?

[Neil M. <ne...@cs...>]

Neil Madden wrote:
> 
> Hi all,
> 
> OK - my exams are over, and I have some time to look again at my socket
> code in Jacl. It needs some work. After the messages a while ago about
> common functionality in the Channel class, is now a good time for me to
> review the socket code and try and finish it off? i.e. - is the Channel
> class in a finished state? Also, what is the model for integrating with
> fconfigure, fileevent etc? Has work begun on fileevent?

I've looked at the new async I/O in Java 1.4, and I think it will be
much more useful than the current synchronous Java I/O (reminds me quite
a lot of a long-winded way of doing what Jacl does for I/O anyway).
However, the calls and classes involved are completely different (for
both async and synchronous I/O). So, how should I go about this? I think
I'm going to try and implement asynchronous I/O just using the current
stuff and Threads for the time being, and then I can think about 1.4. I
think the best way to get 1.4 IO would be to use conditional execution
to decide which SocketChannel implementation to load, as it would
probably have to go into a separate class (it's a rewrite of the entire
thing for the new APIs). Is anyone thinking of using the new APIs for
file IO?

Thoughts?

> 
> Cheers,
> 
> Neil.
> 
-- 
package require Tkhtml;package require http;pack [scrollbar .vsb \
-orient vertical -command {.html yview}] -side right -fill y;pack \
[html .html -bg white -yscrollcommand {.vsb set}] -fill both -expand 1
set t [http::geturl http://mini.net/tcl/976.html];.html parse \
[http::data $t];http::cleanup $t

Re: [tcljava-dev] string is *

[Bas S. <ba...@sc...>]

Thanks Christian,

I'll check out the CVS version and start developing with that that way if
I come acros something that doesn't work for me I can make sure it is in
the next version!

Cheers,
Bas.

> The CVS version of Jacl includes a Tcl8.4 compatible string command
> since August 2000:

Re: [tcljava-dev] string is *

[Christian K. <chr...@so...>]

Hello,

Bas Scheffers schrieb:
> Just noticed that in 1.2.6 [string is boolean/integer/etc] is not
> supported, is anyone working on that for 1.3, or do I have to make that my
> project? ;-) The code I want to port can't live without it!

The CVS version of Jacl includes a Tcl8.4 compatible string command
since August 2000:
: Revision 1.4 / Sun Aug 20 08:37:47 2000 UTC (17 months, 3 weeks ago) by mo 
: update string to 8.4 compatible impl, update some misc hex and double misc stuff too
You can find this info also in the ChangeLog.

Greetings, Krischan
-- 
Christian Krone

[tcljava-dev] string is *

[Bas S. <ba...@sc...>]

Hi,

Just noticed that in 1.2.6 [string is boolean/integer/etc] is not 
supported, is anyone working on that for 1.3, or do I have to make that my 
project? ;-) The code I want to port can't live without it!

Bas.

Re: [tcljava-dev] Jacl and JDBC

[Mo D. <su...@ba...>]

On Wed, 6 Feb 2002 16:25:56 +0100 (CET)
"Bas Scheffers" <ba...@sc...> wrote:

> > But then I noticed that TclJava gives you everything at hand,
> > what you need to use JDBC in Tcl. No need for an extra interface.
> > You can access all and everything of JDBC almost as easy as from
> > inside Java. I hope the following lines will be a proof of this.
>
> Makes sense. What is generaly a higher performance method, doing it all in 
> Java and adding your own commands to the interpreter, or using ::java::* 
> calls? For what I am working on, I have a pool of interpreters in a 
> servlet, so every milliseconds counts.

Using the java::* commands would likely be the slowest. It is hard to pin down
exactly what the diff between the other two options is, it would depend on how
you implemented things.

cheers
Mo DeJong

P.S.
Just an FYI, it might have been better to ask your question on tcljava-user
instead of tcljava-dev. The dev list is for discussion of implementation
details of tcljava itself.

Re: [tcljava-dev] Jacl and JDBC

[Bas S. <ba...@sc...>]

> But then I noticed that TclJava gives you everything at hand,
> what you need to use JDBC in Tcl. No need for an extra interface.
> You can access all and everything of JDBC almost as easy as from
> inside Java. I hope the following lines will be a proof of this.
Makes sense. What is generaly a higher performance method, doing it all in 
Java and adding your own commands to the interpreter, or using ::java::* 
calls? For what I am working on, I have a pool of interpreters in a 
servlet, so every milliseconds counts.

Cheers,
Bas.