I'll insert an auto-responder for "tcljava@..." that
will alert you to the new list.

>>>Mo DeJong said:
  > Just an FYI here.
  >
  > The tcljava project has moved to sourceforge.
  > There are now two mailing lists, one for
  > users and one for developers. Sign up here:
  >
  > http://sourceforge.net/mail/?group_id=13005
  >
  > You will have to sign up yourself, I am not
  > going to sign folks automatically.
  >
  > The developers list will host more in depth
  > discussions while the user list will be
  > focused on user questions. The user list
  > should be very low bandwidth.
  >
  > cheers
  > Mo DeJong
  > Red Hat Inc
  >
  > ----------------------------------------------------------------
  > The TclJava mailing list is sponsored by Scriptics Corporation.
  > To subscribe:    send mail to TclJava-request@...
  >                  with the word SUBSCRIBE as the subject.
  > To unsubscribe:  send mail to TclJava-request@...
  >                  with the word UNSUBSCRIBE as the subject.
  > To send to the list, send email to 'TclJava@...'.
  > An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
  >

-- Brent Welch <welch@...>
	 http://www.ajubasolutions.com
	 Scriptics changes to Ajuba Solutions
	 scriptics.com => ajubasolutions.com


----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Just an FYI here.

The tcljava project has moved to sourceforge.
There are now two mailing lists, one for
users and one for developers. Sign up here:

http://sourceforge.net/mail/?group_id=13005

You will have to sign up yourself, I am not
going to sign folks automatically.

The developers list will host more in depth
discussions while the user list will be
focused on user questions. The user list
should be very low bandwidth.

cheers
Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Can I request that the method Interp.evalURL() be made public?  Perhaps
there's another way to accomplish the equivalent functionality or some
reason it's not already?

---
Thomas McKay

Manager, Software Development
Microcosm Technologies, Inc.
mailto:mckay@...

4001 Weston Parkway, Suite 200
Cary, NC  27513
919-854-7500 x103

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

I've been investigating the thread cleanup, and it appears that thread
cleanup handlers created with Tcl_CreateThreadExitHandler are only
called when tcl is shutting down. This is true at least for tcl8.3.2.
I haven't looked at tcl8.4.

There is an experimental tcl thread interface in tcl8.3.2 that allows
a user to control tcl threads from within tcl scripts.  I understand
that this interface will be included in tcl8.4, and threads created
with this interface will call the cleanup handlers created with
Tcl_CreateThreadExitHandler.  So there should be no problem for
threads created within tcl.

This is all well and fine, but the problem is that tclblends design
conflicts with the order of the cleanup handlers.  When a tcl thread
exits, it calls these registered cleanup handlers, and then it
deletes the interpreter for the thread.  The problem in the current
design is that the jvm thread is detached, before the interpreter is
destroyed.  When the intrepter is destroyed it cleans up all of the
remainined Tcl_Obj's which results in a call to FreeTclObject.
FreeTclObject then tries to call the release method for the TclObject
that it represents, and this results in a segfault, because the jvm
has already detached from the current thread.  I came this while
testing in aolserver, and from looking at the tcl source, it appears
that you will have the same problem with the regular version of
tclblend when using the thread interface in tcl8.4.

Threads created from java will not get segfaults, because the cleanup
routines will not be called.  Of course, you will then have memory
leaks.

-Dan

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

SWANK 0.7 has been released.  You can find it at
http://www.nmrview.com/swank/index.html

SWANK(tm) is a GUI toolkit written in Java(tm) that provides
functionality and programming interface that are similar to those of Tk.
It is meant to work as the Tk-like companion to Jacl (Tcl in Java).
The license is basically the same as the Tcl/Tk license.

2000-10-30  Bruce Johnson
         * Released SWANK 0.7
         * added tcl scripts and image (bitmap) files to swank.jar so
           that all files necessary to use SWANK (not including
           tcljava.jar and jacl.jar) to use SWANK are in the
           swank.jar file.
         * Added new and experimental Shell (called SwkShell) and
           Notifier to the system. The java source can be found in
           the tcl/lang directory. These are designed to queue all
           Tcl events onto the AWTevent-queue.  This avoids violating
           the Swing rule that one should only access Swing
           components from a single thread.  (see the INSTALL file
           for more info).  Much work and testing remains to be done.
         * Cleaned up some of the examples in the example directory.
         * Many small improvements and bug fixes in various widgets.
         * Fixed "pack forget" command.
         * Changed image command to look in jar files as well as
           normal file system for image files.
         * Started testing using the Tk test suite.  Some modified
           scripts are now included in the swktests directory.  These
           mostly run to completion, but don't necessarily run
           without errors

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Mon, 30 Oct 2000, Sai Geetha M N wrote:

> Hi

Hello.

> I am very new to JACL and TCL itself.

Don't worry, it is all rather easy to learn.

> My aim is to be able to call a TCL Script in a Java Program. I have figured
> out that I use the tcl.lang.Interp class to create a new instance of the
> jacl interpreter and use its eval method to evaluate any of the tcl commands
> But I want to execute a tcl script from the new interpreter.
> Something equivalent to the Tcl_EvalFile(Interp interp, String filename)
> that is available with the C version of TCL.
> I find there is a command interp.evalFile(String filename). But this is

But, you are not calling interp.evalFile() you are just calling
interp.eval(). If you want to just run the source command you
could also call interp.eval("source file.tcl").

> In short, I need to know how to pass a tcl script to a java program and run
> it? I may have parameters too that have to be pass to that tcl file
> executable.

You can't pass "parameters" to something like "source foo.tcl".
What you can do is set variables before you source the file.
For example, if you set argv and argv0 to something before
evaling the file, it would be like running the file from
the command line.

cheers
Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Hi
I am very new to JACL and TCL itself.
My aim is to be able to call a TCL Script in a Java Program. I have figured
out that I use the tcl.lang.Interp class to create a new instance of the
jacl interpreter and use its eval method to evaluate any of the tcl commands
But I want to execute a tcl script from the new interpreter.
Something equivalent to the Tcl_EvalFile(Interp interp, String filename)
that is available with the C version of TCL.
I find there is a command interp.evalFile(String filename). But this is
throwing an error
tcl.lang.TclException
         at tcl.lang.ReturnCmd.cmdProc(ReturnCmd.java, Compiled Code)
         at tcl.lang.Parser.evalObjv(Parser.java, Compiled Code)
         at tcl.lang.Parser.eval2(Parser.java, Compiled Code)
         at tcl.lang.Procedure.cmdProc(Procedure.java)
         at tcl.lang.Parser.evalObjv(Parser.java, Compiled Code)
         at tcl.lang.Parser.evalObjv(Parser.java, Compiled Code)
         at tcl.lang.Parser.eval2(Parser.java, Compiled Code)
         at tcl.lang.Interp.eval(Interp.java)
         at tcl.lang.Interp.eval(Interp.java)
         at CallTcl.evalScript(CallTcl.java:9)
         at CallTcl.main(CallTcl.java:17)

The program I have written is:
public class CallTcl {

	 Interp interp = new Interp();

	 public String evalScript(String s) throws TclException {
		 interp.eval(s);
		 return interp.getResult().toString();
	 }

	 public static void main(String args[]) throws Exception{
		 CallTcl callTcl = new CallTcl();
		 try {
			 callTcl.evalScript("tgrep.tcl");
		 } catch (TclException te) {
			 te.printStackTrace();
		 }
		 callTcl.interp.dispose();
	 }
}

CAN anyone help me with this?

In short, I need to know how to pass a tcl script to a java program and run
it? I may have parameters too that have to be pass to that tcl file
executable.

Thanking in advance
Sai

Sai Geetha M N
Web Technologist
Planetasia Research Lab
Planetasia Ltd.

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

I have just merged the changes needed to use Tcl Blend
in a multi-threaded environment back into the HEAD
of the CVS. These changes should finally fix ALL
of the strange problems people were having with
Tcl Blend and multiple threads. The "big global lock"
has been removed, so lock contention in a multi-threaded
environment should no longer be an issue.

These changes also make it possible to load
Tcl Blend into Java in a thread safe way.
These changes will also finally fix the bug
that was causing deadlock in the garbage collector.
The Windows makefile.vc was also updated. Note,
that Tcl Blend now requires a version of Tcl
that is built with thread support, so don't
forget to add the --enable-threads flag
when you configure Tcl.

Since, the source code is now hosted in sourceforge,
you will have to checkout a new module.

The CVS info is: (using csh)

setenv CVSROOT :pserver:anonymous@...:/cvsroot/tcljava

cvs login
(just hit return for the password)

cvs checkout tcljava


Happy Hacking.
Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>>>>> "Mo" == Mo DeJong <mdejong@...> writes:


     Mo> I ran the tests again, and it looks like everything is working
     Mo> just great. I can also run some multi-threaded tests that did
     Mo> not work in the past.

     Mo> Are there any remaining issues we need to look at before
     Mo> merging this branch back into the HEAD? We can't fix the ref
     Mo> count problem right now, we need to get this all merged back
     Mo> into the HEAD and then we can look at overhauling ref
     Mo> counting, perhaps on another branch.

This sounds promising.  As far as threading changes, there was the
issue of thread cleanup routine not being called.  Other than that
and the ref counting changes that you mentioned, I thinks that's it.
If I get a chance this weekend, I'll spend some time looking at the
thread cleanup issue.

-Dan

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Thu, 26 Oct 2000, Daniel Wickstrom wrote:

> >>>>> "Mo" == Mo DeJong <mdejong@...> writes:
>
>
>     Mo> Are you up to it? I am going to be working on this object ref
>     Mo> queue thing for some time, so if you could take a whack at the
>     Mo> Notifier it would really help. There is not going to be much
>     Mo> overlap in these changes, so they can be done in parallel.
>
> Ok here is a patch to make the notifier thread safe.  I've run the
> test cases on a solaris box, and it still fails with the same test
> cases that I posted earlier before I made the modifications.  Let me
> know what you think.

This patch looks great. I touched up a couple of little things
and checked it in (see the ChangeLog for the gory details).

I ran the tests again, and it looks like everything is working
just great. I can also run some multi-threaded tests that
did not work in the past.

Are there any remaining issues we need to look at before
merging this branch back into the HEAD? We can't fix
the ref count problem right now, we need to get this
all merged back into the HEAD and then we can look
at overhauling ref counting, perhaps on another branch.

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

David,
	 We are using JDK1.3 (Windows NT/95/98/2000) and Jacl 1.2.6 and they work
very well together.

Steve Carter

-----Original Message-----
From: David Gerstl/Pittsburgh/IBM [mailto:gerstl@...]
Sent: Friday, October 27, 2000 3:52 AM
To: TclJava@...
Subject: [Tcl Java] JDK versions and JACL versions


Hi all,

      Is there a list of JACL version numbers and the JDKs they work with?
I'm specifically interested in JDK 1.3 (J2 SDK 1.3) both Sun and IBM.

thanx

-dave

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Thu, 26 Oct 2000, David Gerstl/Pittsburgh/IBM wrote:

> Hi all,
>
>      Is there a list of JACL version numbers and the JDKs they work with?
> I'm specifically interested in JDK 1.3 (J2 SDK 1.3) both Sun and IBM.
>
> thanx
>
> -dave

There is a file in the dist call known_issues.txt, it describes
where Jacl of Tcl Blend might be having some problems. For the
most part, Jacl will work on just about any JDK. It even works on
Kaffe. The only systems that I know don't work are GCJ
(I have been working to that fixed) and the JVMs Microsoft
was putting out (they got out of the JVM biz).

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Hi all,

      Is there a list of JACL version numbers and the JDKs they work with?
I'm specifically interested in JDK 1.3 (J2 SDK 1.3) both Sun and IBM.

thanx

-dave

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>>>>> "Mo" == Mo DeJong <mdejong@...> writes:

     Mo> On Thu, 26 Oct 2000, Daniel Wickstrom wrote:

     Mo> It could be related to the event queue, I just don't see it on
     Mo> my box.  A printed stack trace would really help:

     Mo> replace:

     Mo> catch {$notifier doOneEvent 0} msg

     Mo> with:

     Mo> java::try {$notifier doOneEvent 0} catch {Exception e} {$e
     Mo> printStackTrace}

     Mo> If not, could you investigate it a bit more? Perhaps get a
     Mo> stack trace and print it to see where things are going wrong.
     >>  I'll see what I can do.  I want to write some tests that will
     >> exercise the enw notifer anyway.

Here is the stacktrace:


% source tclblend/javaTimer.test


==== javaTimer-3.1 JavaTimerProc
==== Contents of test case:

     set t [java::new tests.TimerHandlerTest $notifier 100]
     set result [java::field $t value]
     java::field $t err true
     lappend result [java::try {$notifier doOneEvent 0} catch {Exception e} {$e
printStackTrace}] $msg  [java::field $t value]

==== Result was:
0 1 {unknown java object "java0x1"} 0
---- Result should have been:
0 1 {java.lang.NullPointerException: TimerHandlerTest} 1
---- javaTimer-3.1 FAILED
% source tclblend/javaTimer.test
java.lang.NullPointerException: TimerHandlerTest
         at tcl.lang.TclPkgInvoker.invokeMethod(TclPkgInvoker.java:81)
         at tcl.lang.JavaInvoke.call(JavaInvoke.java:254)
         at tcl.lang.JavaInvoke.callMethod(JavaInvoke.java:114)
         at tcl.lang.ReflectObject.cmdProc(ReflectObject.java:906)
         at tcl.lang.Interp.callCommand(Interp.java:983)
         at tcl.lang.Interp.eval(Interp.java:791)
         at tcl.lang.JavaTryCmd.cmdProc(JavaTryCmd.java:74)
         at tcl.lang.Interp.callCommand(Interp.java:983)


==== javaTimer-3.1 JavaTimerProc
==== Contents of test case:

     set t [java::new tests.TimerHandlerTest $notifier 100]
     set result [java::field $t value]
     java::field $t err true
     lappend result [java::try {$notifier doOneEvent 0} catch {Exception e} {$e
printStackTrace}] $msg  [java::field $t value]

==== Result was:
0 {} {unknown java object "java0x1"} 1
---- Result should have been:
0 1 {java.lang.NullPointerException: TimerHandlerTest} 1
---- javaTimer-3.1 FAILED
%

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Thu, 26 Oct 2000, Daniel Wickstrom wrote:

> >>>>> "Mo" == Mo DeJong <mdejong@...> writes:
>
>
>     Mo> What version of Tcl are you using? This should not show up
>     Mo> with Tcl 8.3.2 or 8.4. At any rate, it does not matter.
>
> I'm using tcl version 8.3.2.

Strange, perhaps I was wrong and that only works for 8.4. Oh well.

>     >> tclblend/javaTimer.test
>     >>
>     >>
>     >> ==== javaTimer-3.1 JavaTimerProc ==== Contents of test case:
>     >>
>     >> set t [java::new tests.TimerHandlerTest $notifier 100] set
>     >> result [java::field $t value] java::field $t err true lappend
>     >> result [catch {$notifier doOneEvent 0} msg] $msg [java::field
>     >> $t value]
>     >>
>     >> ==== Result was: 0 0 1 0 ---- Result should have been: 0 1
>     >> {java.lang.NullPointerException: TimerHandlerTest} 1 ----
>     >> javaTimer-3.1 FAILED
>
>     Mo> Humm, I have not seen this error before either. Could this
>     Mo> have something to do with your Notifier changes?
>
> No these tests were run before I made the notifier changes.  This is a
> fresh checkout from cvs.  Since making the notifier changes, I get the
> same errors, so the notifier modifications didn't change anything with
> regard to the test results.

It could be related to the event queue, I just don't see it on my box.
A printed stack trace would really help:

replace:

catch {$notifier doOneEvent 0} msg

with:

java::try {$notifier doOneEvent 0} catch {Exception e} {$e printStackTrace}

>     Mo> If not, could you investigate it a bit more? Perhaps get a
>     Mo> stack trace and print it to see where things are going wrong.
>
> I'll see what I can do.  I want to write some tests that will exercise
> the enw notifer anyway.

Me thinks tcljava/tests/tcljava/JavaNotifier.test is in need of
writing. This could slurp up the Jacl specific and Tcl Blend
specific tests that are floating around too.

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>>>>> "Mo" == Mo DeJong <mdejong@...> writes:


     Mo> What version of Tcl are you using? This should not show up
     Mo> with Tcl 8.3.2 or 8.4. At any rate, it does not matter.

I'm using tcl version 8.3.2.

     >> tclblend/javaTimer.test
     >>
     >>
     >> ==== javaTimer-3.1 JavaTimerProc ==== Contents of test case:
     >>
     >> set t [java::new tests.TimerHandlerTest $notifier 100] set
     >> result [java::field $t value] java::field $t err true lappend
     >> result [catch {$notifier doOneEvent 0} msg] $msg [java::field
     >> $t value]
     >>
     >> ==== Result was: 0 0 1 0 ---- Result should have been: 0 1
     >> {java.lang.NullPointerException: TimerHandlerTest} 1 ----
     >> javaTimer-3.1 FAILED

     Mo> Humm, I have not seen this error before either. Could this
     Mo> have something to do with your Notifier changes?

No these tests were run before I made the notifier changes.  This is a
fresh checkout from cvs.  Since making the notifier changes, I get the
same errors, so the notifier modifications didn't change anything with
regard to the test results.

     Mo> If not, could you investigate it a bit more? Perhaps get a
     Mo> stack trace and print it to see where things are going wrong.

I'll see what I can do.  I want to write some tests that will exercise
the enw notifer anyway.

-Dan


----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Thu, 26 Oct 2000, Daniel Wickstrom wrote:

> Ok, I retried my fresh checkout on the solaris box, and it runs ok
> except for a few test failures:

> ==== java::lock-1.1 error checking
> ==== Contents of test case:
>
>     list [catch {java::lock} msg] $msg
>
> ==== Result was:
> 1 {no value given for parameter "javaObj" to "java::lock"}
> ---- Result should have been:
> 1 {wrong # args: should be "java::lock javaObj"}
> ---- java::lock-1.1 FAILED

What version of Tcl are you using? This should not
show up with Tcl 8.3.2 or 8.4. At any rate, it
does not matter.

> tclblend/javaTimer.test
>
>
> ==== javaTimer-3.1 JavaTimerProc
> ==== Contents of test case:
>
>     set t [java::new tests.TimerHandlerTest $notifier 100]
>     set result [java::field $t value]
>     java::field $t err true
>     lappend result [catch {$notifier doOneEvent 0} msg] $msg  [java::field $t
value]
>
> ==== Result was:
> 0 0 1 0
> ---- Result should have been:
> 0 1 {java.lang.NullPointerException: TimerHandlerTest} 1
> ---- javaTimer-3.1 FAILED

Humm, I have not seen this error before either. Could
this have something to do with your Notifier changes?

If not, could you investigate it a bit more? Perhaps
get a stack trace and print it to see where things
are going wrong.

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>>>>> "Mo" == Mo DeJong <mdejong@...> writes:


     Mo> Are you up to it? I am going to be working on this object ref
     Mo> queue thing for some time, so if you could take a whack at the
     Mo> Notifier it would really help. There is not going to be much
     Mo> overlap in these changes, so they can be done in parallel.



Ok here is a patch to make the notifier thread safe.  I've run the
test cases on a solaris box, and it still fails with the same test
cases that I posted earlier before I made the modifications.  Let me
know what you think.

How is it going with the object ref queue thing?

-Dan

On Thu, 26 Oct 2000, Thomas McKay wrote:

> Hack... hack... hack...  I plow on...
>
> Okay, I never could get configure to successfully run Test.java.  Finally
> got it to compile after much hacking, but never run.  So I took out the
> whole java test section of configure and finally got a Makefile.

Well, there should have been an error logged to config.log that
would have shown why Test.java could not be compiled.

> Several problems with the Makefile, though:  1)  The classpath is being
> built with ':'s not ';'s.  I'm on NT so this is a no-no.  I assume that this
> is something I've set up wrong.... where?  2) There are places in the
> Makefile where paths are specified as "//e/App..." instead of "e:/App..."
> which causes failures.  I'm using the cygnus tools.  3)  The line in the
> Makefile
>  @echo "# Making tcljava.build"
> gives me an error about an unterminated quoted string.  Not sure why.
>
> Am I just being clueless here?

No, the autoconf based build has never been tested on NT. I know
it works on Unix systems, but I have not gotten around to
porting it to Window + Cygwin. There is an updated makefile.vc
(the VC++ based build) that works for Tcl Blend 1.3 on the
contract branch. It might be easier to get that working on NT.

> That said, it appears that I have built jacl.jar and tcljava.jar
> successfully.

Cool. Yes, Jacl would be a lot easier to get working with
the Cygwin based build. Tcl Blend is going to be a bit more
work. There was a Cygwin tested build process for Tcl Blend
in the 1.2 release, but it did not support Jacl and suffered
a bit of code rot when compared to 1.3, so I had to kill it.
I need to revive that sucker, but perhaps someone else who
has done some autotools hacking would like to beat me to it :)

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Hack... hack... hack...  I plow on...

Okay, I never could get configure to successfully run Test.java.  Finally
got it to compile after much hacking, but never run.  So I took out the
whole java test section of configure and finally got a Makefile.

Several problems with the Makefile, though:  1)  The classpath is being
built with ':'s not ';'s.  I'm on NT so this is a no-no.  I assume that this
is something I've set up wrong.... where?  2) There are places in the
Makefile where paths are specified as "//e/App..." instead of "e:/App..."
which causes failures.  I'm using the cygnus tools.  3)  The line in the
Makefile
	 @echo "# Making tcljava.build"
gives me an error about an unterminated quoted string.  Not sure why.

Am I just being clueless here?

That said, it appears that I have built jacl.jar and tcljava.jar
successfully.

---
Thomas McKay

Project Leader
Microcosm Technologies, Inc.
mailto:mckay@...

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Thu, 26 Oct 2000, Thomas McKay wrote:

> Can someone send me a pointer to where I can download autoconf 2.14.

You would need to grab the autotools out of the CVS (Dont do this yet!).

setenv CVSROOT :pserver:anoncvs@...:/cvs

cvs login
paswsd ""

cvs checkout autoconf

cvs checkout libtool

setenv CVSROOT :pserver:anoncvs@...:/cvs/automake

cvs login
paswsd "anoncvs"

cvs checkout automake

> I just checked out tcljava from sourceforge and would like to make it.
> There aren't any instructions on doing this so I am assuming that I:
> 1) autoconf configure.in
> 2) configure
> 3) make

You don't need to. There is already a tcljava/configure file for
just that reason (so you don't need to download autoconf). If you
change the Tcl/Java configure.in file or other m4 files, you
would need to rerun things. If you wanted to do that, you
would run the ./autogen.sh script.

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>>>>> "Thomas" == Thomas McKay <mckay@...> writes:

     Thomas> Can someone send me a pointer to where I can download
     Thomas> autoconf 2.14.  I just checked out tcljava from
     Thomas> sourceforge and would like to make it.  There aren't any
     Thomas> instructions on doing this so I am assuming that I: 1)
     Thomas> autoconf configure.in 2) configure 3) make


You can get autoconf at ftp://ftp.gnu.org, but you shouldn't need it.
The source that you checkout from sourceforge already has a valid
configure script.  You just need to run 1) configure and 2) make.


-Dan

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Okay, just using the configure script that existed already I get the
following error about not being able to compile test program Test.java.
Anyone have any pointers?

caffeine:mckay://e/Applications/jacl/sourceforge/tcljava>
configure --enable-jac
l --without-jikes Makefile.in
configure: WARNING: you should use --build, --host, --target
srcdir is //e/Applications/jacl/sourceforge/tcljava
checking for javac... //e/Applications/jdk1.3.0rc3/bin/javac
checking for zip or jar files to include on CLASSPATH...
//e/Applications/jdk1.3
.0rc3/jre/lib/rt.jar
checking to see if the java compiler works... yes
Java found in //e/Applications/jdk1.3.0rc3
checking type of jvm... jdk
checking java API version... 1.3
checking for java... //e/Applications/jdk1.3.0rc3/bin/java
checking for java_g... no
checking for javah... //e/Applications/jdk1.3.0rc3/bin/javah
checking for jar... //e/Applications/jdk1.3.0rc3/bin/jar
checking for jdb... //e/Applications/jdk1.3.0rc3/bin/jdb
checking for ddd... no
checking for gdb... /Applications/cygnus/cygwin-b20/H-i586-cygwin32/bin/gdb
checking the Java compiler... configure: error: Could not compile simple
test pr
ogram Test.java with //e/Applications/jdk1.3.0rc3/bin/javac
caffeine:mckay://e/Applications/jacl/sourceforge/tcljava>

---
Thomas McKay

Project Leader
Microcosm Technologies, Inc.
mailto:mckay@...

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>>>>> "Mo" == Mo DeJong <mdejong@...> writes:


     Mo> I just got a fresh CVS checkout from SF and ran the tests with
     Mo> IBM JDK 1.3 (on Linux) and it worked just fine. I don't know
     Mo> what to tell ya. You are using the branch tag:

     Mo> ajuba-tclblend-contract-2000-08-01-branch

     Mo> right?

Ok, I retried my fresh checkout on the solaris box, and it runs ok
except for a few test failures:

585 danw@satdsp14:/home/unix/wickstrom/web/tcljava>make test
pwd is /home/unix/wickstrom/web/tcljava/tests
CLASSPATH is
/usr/local/jdk/jdk1.1.8/lib/classes.zip:/home/unix/wickstrom/web/tcljava/tests:/\
home/unix/wickstrom/web/tcljava/tclblend.jar:/home/unix/wickstrom/web/tcljava/tc\
ljava.jar
auto_path is /home/unix/wickstrom/web/tcljava /usr/local/tcl/tcl8.3.2/library
/usr/local/tcl/tcl8.3.2 /usr/local/tcl/tcl8.3.2/lib /usr/local/lib
tcljava/ArrayObject.test
tcljava/AutomaticSignature.test
tcljava/BeanEvent.test
tcljava/BeanEventMgr.test
tcljava/ClassRep.test
tcljava/FieldSig.test
tcljava/FuncSig.test
tcljava/JavaBindCmd.test
tcljava/JavaCallCmd.test
tcljava/JavaCastCmd.test
tcljava/JavaDefineClassCmd.test
tcljava/JavaEventCmd.test
tcljava/JavaFieldCmd.test
tcljava/JavaImportCmd.test
tcljava/JavaInfoCmd.test
tcljava/JavaInstanceofCmd.test
tcljava/JavaInvoke.test
tcljava/JavaIsNullCmd.test
tcljava/JavaLoadCmd.test
tcljava/JavaLock.test


==== java::lock-1.1 error checking
==== Contents of test case:

     list [catch {java::lock} msg] $msg

==== Result was:
1 {no value given for parameter "javaObj" to "java::lock"}
---- Result should have been:
1 {wrong # args: should be "java::lock javaObj"}
---- java::lock-1.1 FAILED


==== java::lock-1.2 error checking
==== Contents of test case:

     list [catch {java::lock a b} msg] $msg

==== Result was:
1 {called "java::lock" with too many arguments}
---- Result should have been:
1 {wrong # args: should be "java::lock javaObj"}
---- java::lock-1.2 FAILED


==== java::unlock-1.1 unlock error messages
==== Contents of test case:

     list [catch {java::unlock} msg] $msg

==== Result was:
1 {no value given for parameter "javaObj" to "java::unlock"}
---- Result should have been:
1 {wrong # args: should be "java::unlock javaObj"}
---- java::unlock-1.1 FAILED


==== java::unlock-1.2 unlock error checking
==== Contents of test case:

     list [catch {java::unlock a b} msg] $msg

==== Result was:
1 {called "java::unlock" with too many arguments}
---- Result should have been:
1 {wrong # args: should be "java::unlock javaObj"}
---- java::unlock-1.2 FAILED
tcljava/JavaNewCmd.test
tcljava/JavaNullCmd.test
tcljava/JavaPropCmd.test
tcljava/JavaThrowCmd.test
tcljava/JavaTryCmd.test
tcljava/PkgInvoker.test
tcljava/PropertySig.test
tcljava/ReflectException.test
tcljava/ReflectObject.test
tcljava/TclEvent.test
tclblend/javaCmd.test
tclblend/javaIdle.test
tclblend/javaInterp.test


tclblend/javaObj.test
tclblend/javaTimer.test


==== javaTimer-3.1 JavaTimerProc
==== Contents of test case:

     set t [java::new tests.TimerHandlerTest $notifier 100]
     set result [java::field $t value]
     java::field $t err true
     lappend result [catch {$notifier doOneEvent 0} msg] $msg  [java::field $t
value]

==== Result was:
0 0 1 0
---- Result should have been:
0 1 {java.lang.NullPointerException: TimerHandlerTest} 1
---- javaTimer-3.1 FAILED
tclblend/javaUtil.test
Tests done.

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Can someone send me a pointer to where I can download autoconf 2.14.

I just checked out tcljava from sourceforge and would like to make it.
There aren't any instructions on doing this so I am assuming that I:
1) autoconf configure.in
2) configure
3) make


---
Thomas McKay

Project Leader
Microcosm Technologies, Inc.
mailto:mckay@...

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>
> I just got a fresh CVS checkout from SF and ran the tests
> with IBM JDK 1.3 (on Linux) and it worked just fine. I don't
> know what to tell ya. You are using the branch tag:
>
> ajuba-tclblend-contract-2000-08-01-branch

I just got a fresh checkout from the ajuba branch (used cut and paste from your
email), and now I get:

1184 nsadmin@localhost:~/sourceforge/tcljava >make test
make[1]: Entering directory `/home/nsadmin/sourceforge/tcljava'
make[2]: Entering directory `/home/nsadmin/sourceforge/tcljava'
#
# Making test_tcljava.build
#
mkdir -p /home/nsadmin/sourceforge/tcljava/tests
cd /home/nsadmin/sourceforge/tcljava/src/tests/tcljava ;\
CLASSPATH=/usr/local/jdk/jdk118_v1/lib/classes.zip:/home/nsadmin/sourceforge/tcl\
java/tests:/home/nsadmin/sourceforge/tcljava/tc

lblend.jar:/home/nsadmin/sourceforge/tcljava/tcljava.jar \
/usr/bin/jikes -g \
         -d /home/nsadmin/sourceforge/tcljava/tests pkg1/*.java pkg2/*.java \
         tcl/lang/*.java tests/*.java tests/invoke/*.java \
         tests/javainfo/*.java tests/signature/*.java \
         tests/javabind/*.java tests/exec/*.java
mkdir -p /home/nsadmin/sourceforge/tcljava/tests/javaload
mkdir -p /home/nsadmin/sourceforge/tcljava/tests/javaload/tests/javaload
cd /home/nsadmin/sourceforge/tcljava/src/tests/tcljava ;\
CLASSPATH=/usr/local/jdk/jdk118_v1/lib/classes.zip:/home/nsadmin/sourceforge/tcl\
java/tests:/home/nsadmin/sourceforge/tcljava/tc

lblend.jar:/home/nsadmin/sourceforge/tcljava/tcljava.jar:/home/nsadmin/sourcefor\
ge/tcljava/tests/javaload
\
/usr/bin/jikes -g \
         -d /home/nsadmin/sourceforge/tcljava/tests/javaload javaload/*.java
cd /home/nsadmin/sourceforge/tcljava/tests/javaload; \
CLASSPATH=/usr/local/jdk/jdk118_v1/lib/classes.zip \
/usr/local/jdk/jdk118_v1/bin/jar -cf0M test9.jar Test9Extension.class; \
rm Test9Extension.class
cd /home/nsadmin/sourceforge/tcljava/tests/javaload; \
CLASSPATH=/usr/local/jdk/jdk118_v1/lib/classes.zip \
/usr/local/jdk/jdk118_v1/bin/jar -cf0M test10.jar Test10Extension.class; \
rm Test10Extension.class
make[2]: Leaving directory `/home/nsadmin/sourceforge/tcljava'
#
# Making test_tclblend.build
#
cd /home/nsadmin/sourceforge/tcljava/src/tests/tclblend ;\
CLASSPATH=/usr/local/jdk/jdk118_v1/lib/classes.zip:/home/nsadmin/sourceforge/tcl\
java/tests:/home/nsadmin/sourceforge/tcljava/tc

lblend.jar:/home/nsadmin/sourceforge/tcljava/tcljava.jar \
/usr/bin/jikes -g \
         -d /home/nsadmin/sourceforge/tcljava/tests tests/*.java tcl/lang/*.java

make[1]: Leaving directory `/home/nsadmin/sourceforge/tcljava'
pwd is /home/nsadmin/sourceforge/tcljava/tests
CLASSPATH is
/usr/local/jdk/jdk118_v1/lib/classes.zip:/home/nsadmin/sourceforge/tcljava/tests\
:/home/nsadmin/sourceforge/tcljava

/tclblend.jar:/home/nsadmin/sourceforge/tcljava/tcljava.jar
auto_path is /home/nsadmin/sourceforge/tcljava /usr/local/tcl/tcl8.3.2/library
/usr/local/tcl/tcl8.3.2 /usr/local/tcl/tcl8.3.2/
lib /usr/local/lib
tcljava/ArrayObject.test
tcljava/AutomaticSignature.test
tcljava/BeanEvent.test
tcljava/BeanEventMgr.test
tcljava/ClassRep.test
tcljava/FieldSig.test
tcljava/FuncSig.test
tcljava/JavaBindCmd.test
SIGILL    4*   illegal instruction
         stackbase=0, stackpointer=BFFFD218

Full thread dump:
     "Bind delay thread 1" (TID:0x40634960, sys_thread_t:0x81c62a0, state:CW,
thread_t: t@4101, sp:0x0 threadID:0x1823, stack_ba
se:0xbf1ffcf4, stack_size:0x200000) prio=0
         tcl.lang.TclEvent.sync(TclEvent.java:126)
         tcl.lang.EventAdaptor._processEvent(EventAdaptor.java:334)
         tcl.lang.Adaptor2.actionPerformed(Unknown Source)
         tests.javabind.Bind.run(Bind.java:60)
ze:0x200000) prio=-1073753914 *current thread*


This is different than what I saw yesterday, but it's still not good.  I guess,
I'll try and download the ibm jdk.

-Dan

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Wed, 25 Oct 2000, Daniel Wickstrom wrote:

> >>>>> "Mo" == Mo DeJong <mdejong@...> writes:
>
>     >>
>     >> I'm running with the following:
>     >>
>     >> redhat 6.2 tcl8.3.2 tcljava from souceforge ajuba contract
>     >> branch blackdown jdk1.1.8_v1
>
>     Mo> That really should work, everything you are using is the same
>     Mo> as my install except I have the CVS version of Tcl.
>
>
> Are you sure that the sourceforge archive is up to date?  I tried the
> same test with the following setup:
>
> solaris 2.7
> sun jdk1.1.8
> tcljava from ajuba branch
>
> This time I received an error because the all the files couldn't be found.
> It seems that there is quite a bit missing from the tests
> sub-directory.

I just got a fresh CVS checkout from SF and ran the tests
with IBM JDK 1.3 (on Linux) and it worked just fine. I don't
know what to tell ya. You are using the branch tag:

ajuba-tclblend-contract-2000-08-01-branch

right?

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

>>>>> "Mo" == Mo DeJong <mdejong@...> writes:

     >>
     >> I'm running with the following:
     >>
     >> redhat 6.2 tcl8.3.2 tcljava from souceforge ajuba contract
     >> branch blackdown jdk1.1.8_v1

     Mo> That really should work, everything you are using is the same
     Mo> as my install except I have the CVS version of Tcl.


Are you sure that the sourceforge archive is up to date?  I tried the
same test with the following setup:

solaris 2.7
sun jdk1.1.8
tcljava from ajuba branch

This time I received an error because the all the files couldn't be found.
It seems that there is quite a bit missing from the tests
sub-directory.  After copying the tests sub-directory from 1.2.6, I
get the following:

557 danw@satdsp14:/home/unix/wickstrom/web/tcljava>make test
pwd is /home/unix/wickstrom/web/tcljava/tests
CLASSPATH is
/usr/local/jdk/jdk1.1.8/lib/classes.zip:/home/unix/wickstrom/web/tcljava/tests:/\
home/unix/wickstrom/web/tcljava/tclblend.jar:/home/unix/wickstrom/web/tcljava/tc\
ljava.jar
auto_path is /home/unix/wickstrom/web/tcljava /usr/local/tcl/tcl8.3.2/library
/usr/local/tcl/tcl8.3.2 /usr/local/tcl/tcl8.3.2/lib /usr/local/lib
tcljava/ArrayObject.test
tcljava/AutomaticSignature.test
Assertion failed: tsdPtr->initialized, file
/home/unix/wickstrom/web/tcljava/src/native/javaCmd.c, line 293
SIGABRT   6*   abort (generated by abort(3) routine)
     si_signo [6]: SIGABRT   6*   abort (generated by abort(3) routine)
     si_errno [0]: Error 0
     si_code [-1]: SI_LWP [pid: 24502, uid: 1103]
         stackbase=FE7C1D5C, stackpointer=FE7C0CE4

Full thread dump:
     "SIGQUIT handler" (TID:0xfd7002a0, sys_thread_t:0xb3310, state:R, thread_t:
t@6, sp:0xfe791a80 threadID:0xfe791dc8, stack_base:0xfe791d5c,
stack_size:0x20000) prio=0
     "Finalizer thread" (TID:0xfd700088, sys_thread_t:0xb3280, state:R, thread_t:
t@5, sp:0xfe7c1a80 threadID:0xfe7c1dc8, stack_base:0xfe7c1d5c,
stack_size:0x20000) prio=1 *current thread*
         tcl.lang.CObject.finalize(CObject.java:225)
     "main" (TID:0xfd7000b0, sys_thread_t:0xbcd80, state:R, thread_t: t@1,
sp:0xffbedd40 threadID:0x20d88, stack_base:0xffbec080, stack_size:0x800000)
prio=5
         java.lang.StringBuffer.expandCapacity(StringBuffer.java)
         java.lang.StringBuffer.insert(StringBuffer.java)
         tcl.lang.JavaInfoCmd.getNameFromClass(JavaInfoCmd.java:655)
         tcl.lang.FuncSig.getMethodDescription(FuncSig.java:1328)
         tcl.lang.FuncSig.sortMethods(FuncSig.java:1255)
         tcl.lang.FuncSig.getAllDeclaredMethods(FuncSig.java:1104)
         tcl.lang.FuncSig.lookupMethod(FuncSig.java:274)
         tcl.lang.FuncSig.get(FuncSig.java:241)
         tcl.lang.JavaInvoke.callStaticMethod(JavaInvoke.java:158)
         tcl.lang.JavaCallCmd.cmdProc(JavaCallCmd.java:74)
         tcl.lang.Interp.callCommand(Interp.java:983)
Monitor Cache Dump:
     java.lang.StringBuffer@FD733308/FD7F59F8: owner "main" (0xbcd80, 1 entry)
Registered Monitor Dump:
     Thread queue lock: <unowned>
     Name and type hash table lock: <unowned>
     String intern lock: <unowned>
     JNI pinning lock: <unowned>
     JNI global reference lock: <unowned>
     BinClass lock: <unowned>
     Class loading lock: <unowned>
     Java stack lock: <unowned>
     Code rewrite lock: <unowned>
     Heap lock: owner "main" (0xbcd80, 1 entry)
     Has finalization queue lock: owner "main" (0xbcd80, 1 entry)
     Finalize me queue lock: <unowned>
     Monitor registry: owner "Finalizer thread" (0xb3280, 1 entry)
Abort
make: *** [test_tclblend.exec] Error 134


Have you tried doing a clean checkout and build since you started
using sourceforge?

-Dan

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Wed, 25 Oct 2000, Christian Krone wrote:

> Hello,
>
> > Frank Krahmer wrote:
>
> > > After calling a Jacl script I get an exception and examine this by
> [...]
> > > tcl.lang.TclException: syntax error in expression "([info level] == 1) &&
> > > ([info script] == "") \
> > >             && [info exists tcl_interactive] && $tcl_interactive"
> > >         at tcl.lang.Expression.SyntaxError(Expression.java:258)
>
> The expression looks perfectly valid for me, and even my jaclsh
> doesn't complain about a syntax error:
>
> bash-2.04$ cat /tmp/test.tcl
> if {([info level] == 1) &&
>     ([info script] == "") \
>         && [info exists tcl_interactive] && $tcl_interactive} {
>     puts Yes
> } else {
>     puts No
> }
> bash-2.04$ jaclsh /tmp/test.tcl
> No
>
> So maybe, Frank is working on Windows and here the old
> CR-LF error pops up again???

Yeah, that is most likely it. I should go put that up
on the sourceforge task list for Jacl.

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

On Wed, 25 Oct 2000, Frank Krahmer wrote:

>
> After calling a Jacl script I get an exception and examine this by
> 	 catch (Exception e)
> 	 {
> 		 e.printStackTrace();
> 	 }
>
> The result on stdout stream is :
>
> tcl.lang.TclException: syntax error in expression "([info level] == 1) &&
> ([info script] == "") \
>             && [info exists tcl_interactive] && $tcl_interactive"
>         at tcl.lang.Expression.SyntaxError(Expression.java:258)
>         at tcl.lang.Expression.ExprGetValue(Expression.java:550)
>         at tcl.lang.Expression.ExprGetValue(Expression.java:581)
>         at tcl.lang.Expression.ExprTopLevel(Expression.java:236)
>         at tcl.lang.Expression.evalBoolean(Expression.java:151)
>         at tcl.lang.IfCmd.cmdProc(IfCmd.java:46)
>         at tcl.lang.Parser.evalObjv(Parser.java:810)
>         at tcl.lang.Parser.eval2(Parser.java:1209)
>         at tcl.lang.Procedure.cmdProc(Procedure.java:161)
>         at tcl.lang.Parser.evalObjv(Parser.java:810)
>         at tcl.lang.Parser.evalObjv(Parser.java:796)
>         at tcl.lang.Parser.eval2(Parser.java:1209)
>         at tcl.lang.Procedure.cmdProc(Procedure.java:161)
>         at tcl.lang.Parser.evalObjv(Parser.java:810)
>         at tcl.lang.Parser.eval2(Parser.java:1209)
>         at tcl.lang.Interp.eval(Interp.java:2042)
>         at TMFSimulator.Jacl.JaclMgr.executeJaclProc(JaclMgr.java:431)
>         at
> TMFSimulator.Jacl.JaclMgr.initializeJaclTestNetwork(JaclMgr.java:473)
>         at TMFSimulator.Jacl.JaclMgr.initialize(JaclMgr.java:178)
>         at
> TMFSimulator.TMFSimulatorServer.initializeJaclMgr(TMFSimulatorServer.java:443)
>         at
> TMFSimulator.TMFSimulatorServer.initialize(TMFSimulatorServer.java:258)
>         at TMFSimulator.TMFSimulatorServer.main(TMFSimulatorServer.java:185)
>
> How can I get the location (file, linenumber) where the syntaxerror occurred ?
>
> Regards


In the general case, there is no way to know. Tcl only knows
about a file when sourcing a file. If you call interp.evalFile("foo"),
it will add "error ... line x in file foo". If you just call
a proc then there is no way to know where the proc came from.

% proc p { args } {
expr {1 == "}
}

% p d
missing "

% set errorInfo
missing "
     while compiling
"expr {1 == "}"
     (compiling body of proc "p", line 2)
     invoked from within
"p d"
%

It can tell you what line of the proc something went wrong
on, but that is about it. In C code, you can compile in
things like the file a function is in, because a given
function can't be defined more than once. Tcl (and any
scripting language for that matter) is dynamic, so
you can't really find this sort of thing out.

Mo DeJong
Red Hat Inc

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to TclJava-request@...
                  with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to TclJava-request@...
                  with the word UNSUBSCRIBE as the subject.
To send to the list, send email to 'TclJava@...'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com