tcljava-dev — discuss implementation and post patches here

[tcljava-dev] New ref count implementation for Tcl Blend checked into CVS

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

Greetings.

I just checked in a new ref count implementation for Tcl Blend.
This should fix the memory leaking and memory consumption
problems that people have reported. I can now run the test
suite without getting any memory leaks, which is a first for
Tcl Blend.

If you want to read up on the details, see the new documentation
file that was added:

docs/TclJava/JavaRefCount.html

If you have an application that makes use of Tcl Blend, could you
try out the current CVS version and see if these ref count related
changes have broken anything?

cheers
Mo

Re: [tcljava-dev] configure complains about threads

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

On Tue, 3 Sep 2002 15:31:40 +0200
"Tom Simonsen" <to...@in...> wrote:

> I get the following error.
> srcdir is /home/kringle/toms/eos/src/tcljava
> configuring for both jacl and tclblend
> checking for Tcl build in /home/kringle/toms/eos/src/tcl8.3.4
> configure: error: Thread directory /home/kringle/toms/eos/src/tcljava/../thread/unix could not be located.
> 
> I tried to change my options to this:
> 
> ./configure --prefix $HOME/eos/local \
> 		--with-tcl=../tcl8.3.4 \
> 		--with-java=/usr/java/jdk1.3.1_01 \
> 		--without-thread

I just fixed up the error message that is generated if you leave out the
--with-tcl or --with-thread option. It now prints:

% ./configure --with-tcl=/share/tcljava/build/threaded_tcl84
srcdir is /share/tcljava/orig_tcljava/tcljava
configuring for both jacl and tclblend
checking for Tcl build in /share/tcljava/build/threaded_tcl84
configure: error: Use the --with-thread=<dirName> configure flag to indicate where
the required Thread extension build directory is.

I hope that is more clear.

Mo

[tcljava-dev] configure complains about threads

[Tom S. <to...@in...>]

Hi,

I am trying to build the current tcljava tree on AIX and linux, but =
configure barfs.
Can yuo help me out ?

My command line on linux is like this:
./configure --prefix $HOME/eos/local \
		--with-tcl=3D../tcl8.3.4 \
		--with-java=3D/usr/java/jdk1.3.1_01

I get the following error.
srcdir is /home/kringle/toms/eos/src/tcljava
configuring for both jacl and tclblend
checking for Tcl build in /home/kringle/toms/eos/src/tcl8.3.4
configure: error: Thread directory =
/home/kringle/toms/eos/src/tcljava/../thread/unix could not be located.

I tried to change my options to this:

./configure --prefix $HOME/eos/local \
		--with-tcl=3D../tcl8.3.4 \
		--with-java=3D/usr/java/jdk1.3.1_01 \
		--without-thread

The error is now:
srcdir is /home/kringle/toms/eos/src/tcljava
configuring for both jacl and tclblend
checking for Tcl build in /home/kringle/toms/eos/src/tcl8.3.4
configure: error: Thread directory no could not be located.
Use the --with-thread=3D<dirName> configure flag to specify the =
location.

Comments:
* I am using the tcl 8.3.4 source that I found on ActiveState's site.
* the tcl configure command: ./configure --prefix $HOME/eos/local =
--enable-threads
* I have done make && make install in the tcl directory.

Kind Regards,
Tom

[tcljava-dev] PATCH: Swank

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

Here are some patches to Swank.  These only affect tcl/lang/SwkShell.java:

1.  Add support for ~/.wishrc to source code on startup
2.  Beginning support for tcl_prompt (per Shawn Boyce's earlier Jacl patch)
3.  Set default window title to filename sourced, or to 'wisk'
4.  Adds an event loop when running a file on the command line (*)
5.  Changes console I/O from System to using Tcl Channels.

(*) this was a major block for me, Swank1.0 with the stock Jacl CVS 1.3.x
source doesn't let you run:
	$ wisk somefile.tcl
Previously, wisk would startup, display the main window, and promptly
exit.  Adding the event loop allows normal wish-like behavior.

Also see my related Jacl patch that runs jaclsh or wisk from the same
startup shell.


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

[tcljava-dev] PATCH: Jacl

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

Here are some patches to Jacl, some of these patch are the same as the ones
I posted on 6/30/2002.

1. Unified jaclsh/wisk startup, checks $0 to determine if starting jaclsh or
   wisk.  To use this patch, place swank.jar in the same install directory
   as jacl.jar and tcljava.jar, and 'ln -s jaclsh wisk'.
2. jaclsh: runs 'tty(1)', and checks output if running on a tty device.  If so,
   set 'jacl.tty' property so that the Jacl interpreter can use the appropriate
   Channel flush behavior.
3. jaclsh: sets 'jacl.tcllibpath' property so that init.tcl can add the 
   installed lib path to auto_path.
4. Interp.java: check jacl.tty property, set interp isTty field.  Flush all
   open channels when exiting.  Makes allowExceptions() method public for
   use by Swank.
5. Shell.java: add processing of ~/.jaclshrc on shell startup, add support
   for custom tcl_prompt (per Shawn Boyce's earlier patch).
6. StdChannel.java: flush output on write if channel is stderr, or if channel
   is stdout and connected to a tty device.
7. init.tcl: add contents of system property jacl.tcllibpath to auto_path.
8. TCL.java: change scope of OK to public, for use by Swank.

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

[tcljava-dev] BUG: File I/O ignores fconfigure -encoding -translation

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

I finally traced what I believe to be a Jacl bug while working on my 'hyde'
package the last few days.  I had a situation where my code worked fine on
one machine, but didn't on another: same Linux OS release, same Java JDK !!

My hyde package reads Java *.class files after an on-the-fly compilation,
and writes out the byte codes as a hex string, converted by Tcl's 'binary'
command for subsequent loading in the JVM with java::defineclass.

It seems that Jacl/Java file I/O ignores 
	fconfigure $fd -encoding binary -translation binary 

instead, it appears to use the value of env(file.encoding) for treatment of
raw bytes on an input stream.  (Property file.encoding presumably set by
the JVM somewhere.)


Here's my test program, fc.tcl:
----------------------------------------------------------------------------
set in  [lindex $argv 0]
set out [lindex $argv 1]

set fd [open $in]
fconfigure $fd -encoding binary -translation binary -eofchar {}
set bytes [read $fd]
close $fd

set fd [open $out w]
fconfigure $fd -encoding binary -translation binary -eofchar {}
puts -nonewline $fd $bytes
close $fd
----------------------------------------------------------------------------

Jacl was built from yesterday's CVS checkout.

My test data is generated from /dev/random:
$ dd if=/dev/random of=rand1 bs=1 count=1000

Now, try a binary copy of rand1:
$ jaclsh fc.tcl rand1 rand2

$ ls -al rand1 rand2
-rw-rw-r--    1 tpoindex tpoindex     1000 Jul 24 22:09 rand1
-rw-rw-r--    1 tpoindex tpoindex     1000 Jul 24 22:14 rand2

But 'sum' shows that the bytes have been changed:
$ sum rand1 rand2
14321     1 rand1
29958     1 rand2

The culprit is /etc/sysconfig/i18n, which is where RedHat 7.3 stores locale
info:
LANG="en_US.iso885915"
SUPPORTED="en_US.iso885915:en_US:en"
SYSFONT="lat0-sun16"
SYSFONTACM="iso15"

This file is sourced by bash on login and those variables are exported.

Setting LANG=en_US, or just unsetting LANG, jaclsh reports env(file.encoding)
as 'ISO-8859-1'.

Running fc.tcl again:
$ jaclsh fc.tcl rand1 rand3
$ ls -al rand1 rand3
-rw-rw-r--    1 tpoindex tpoindex     1000 Jul 24 22:09 rand1
-rw-rw-r--    1 tpoindex tpoindex     1000 Jul 24 22:38 rand3
$ sum rand1 rand3
14321     1 rand1
14321     1 rand3

Ah ha! that did the trick!

I'm not familiar enough with src/jacl/tcl/lang/Channel.java, FileChannel.java,
Encoding.java, Fconfigure.java, TclIO.java etc. to spot the problem.  

I also tried using the 'encoding' command to 'undo' the coding on read, but
didn't have any luck; it's quite possible I am using 'encoding' incorrectly.

Clues?

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

[tcljava-dev] New Java thread shutdown code for Tcl Blend checked in

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

Hello.

I just checked in a set of tests along with a fix for the problem where the Java
cache was not being cleaned up when a Tcl Blend Interp is loaded into Java.
Now, when the last Tcl Blend interp in a given Java thread is dispose()'ed of, the
Tcl_FinalizeThread method will be invoked to cleanup any TSD that
the Tcl runtime had allocated. This should finally fix the last of the
threading issues that Tcl Blend was running into.

cheers
Mo DeJong

[tcljava-dev] FW: Jacl changes

[Jeff H. <Je...@Ac...>]

Got the list name wrong the first time ...  this is a forward from
another users.

-----Original Message-----
From: Laramie Crocker [mailto:la...@ve...]
Sent: July 11, 2002 10:59 AM
Subject: Jacl changes

	...
Anyway, I have some changes I'd like to propose.
These all relate to jacl

1) This file is incorrectly named.
    Rename it JaclLoadJavaCmd.java from source, and kill the old one.
    ${src}/jacl/tcl/lang/JaclLoadJava.java

2) Add an Ant build.xml file so people can build the java sources without
having to have the Microsoft build tool.  This won't build the native
sources.

3) Add a javadoc task to the build.xml file so that javadoc is created.  The
doc you have is very nice, but having javadoc is also essential.

I have a working implementation of steps 2 and 3, which I have attached.  It
works in the directory like so:

C:\install\jacl\jacl1.2.6\build.xml

where I unzipped jacl1.2.6.zip in the directory C:\install\jacl.
So you have a tree like

jacl1.2.6/
    build.xml
    src/
    docs/
etc.

Then you just
cd jacl1.2.6
ant

and you will get a ./build/ directory with
./build/jacl.jar
./build/tcljava.jar
./build/javadoc/
and the whole build tree.

thanks,
Laramie

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

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

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 modified 'jaclsh' to run the 'tty' program (on most Unix systems), which
sets a property.  The property is checked in the Interp() constructor.  The
StdChannel driver adds a flush if writing to stdout and the tty flag is set.
Also, in Interp.eventuallyDispose(), all open file channels are flushed.

My patch also includes the two minor fixes that are needed to run Swank
in the stock Jacl interpreter, making TCL.OK and Interp.allowExceptions()
public.   And my jaclsh adds JACL_PROPS on the java command line to allow
passing extra -Dxxxx=yyyy property values.


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


diff -c -r tcljava.cvs/jaclsh.in tcljava.tp/jaclsh.in
*** tcljava.cvs/jaclsh.in	Sun Jun 30 22:24:16 2002
--- tcljava.tp/jaclsh.in	Sun Jun 30 22:27:55 2002
***************
*** 30,35 ****
--- 30,39 ----
  # The arguments to the JAVA command
  JAVA_FLAGS="@JAVA_FLAGS@"
  
+ # Set jacl.tty property to 'tty' exit code, affects stdout flush behavior
+ tty -s >/dev/null 2>&1
+ JACL_TTY="-Djacl.tty=$?"
+ 
  # 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
***************
*** 38,41 ****
  CLASSPATH=${JACL_CLASSPATH}:${CLASSPATH}
  export CLASSPATH
  
! exec ${JAVA} ${JAVA_FLAGS} tcl.lang.Shell ${1+"$@"}
--- 42,45 ----
  CLASSPATH=${JACL_CLASSPATH}:${CLASSPATH}
  export CLASSPATH
  
! exec ${JAVA} ${JAVA_FLAGS} ${JACL_TTY} ${JACL_PROPS} tcl.lang.Shell ${1+"$@"}
diff -c -r tcljava.cvs/src/jacl/tcl/lang/Interp.java tcljava.tp/src/jacl/tcl/lang/Interp.java
*** tcljava.cvs/src/jacl/tcl/lang/Interp.java	Fri Apr 12 15:00:26 2002
--- tcljava.tp/src/jacl/tcl/lang/Interp.java	Sun Jun 30 22:29:15 2002
***************
*** 162,167 ****
--- 162,171 ----
  
  boolean isSafe;
  
+ // Is the standard output a tty?  Set via system property
+ 
+ boolean isTty;
+ 
  // Offset of character just after last one compiled or executed
  // by Parser.eval2().
  
***************
*** 327,332 ****
--- 331,337 ----
      scriptFile       = null;
      flags            = 0;
      isSafe           = false;
+     isTty            = false;
      assocData        = null;
  
  
***************
*** 404,409 ****
--- 409,425 ----
  		    TCL.GLOBAL_ONLY);
  	}
  
+ 	// Check system property if running on a tty, so that we know to flush
+ 	// stdout output on each write.  A "jacl.tty" property set to 
+ 	// "0" means running stdin is a tty.
+ 	// This allows the exit code from the Unix 'tty' program to be used.
+ 	// Windows or MacOS < 10 will need to manually set the property.
+ 	String jaclTtyProp = Util.tryGetSystemProperty("jacl.tty", "1");
+ 	if (jaclTtyProp.equals("0")) {
+ 		isTty = true;
+ 	}
+ 		
+ 
  	// Create the env array an populated it with proper
  	// values.
  
***************
*** 541,546 ****
--- 557,573 ----
  	}
      }
  
+ 	// Flush all channels
+ 	for (Enumeration e = interpChanTable.keys(); e.hasMoreElements();) {
+ 		Object key = e.nextElement();
+ 		Channel chan = (Channel) interpChanTable.get(key);
+ 		try {
+ 			chan.flush(this);
+ 		} catch (Exception ex) {
+ 		// Ignore flush error
+ 		}
+ 	}
+ 
      // Finish deleting the global namespace.
      
      // FIXME : check impl of Tcl_DeleteNamespace
***************
*** 3724,3730 ****
   *----------------------------------------------------------------------
   */
  
! void
  allowExceptions()
  {
      evalFlags |= Parser.TCL_ALLOW_EXCEPTIONS;
--- 3751,3757 ----
   *----------------------------------------------------------------------
   */
  
! public void
  allowExceptions()
  {
      evalFlags |= Parser.TCL_ALLOW_EXCEPTIONS;
diff -c -r tcljava.cvs/src/jacl/tcl/lang/StdChannel.java tcljava.tp/src/jacl/tcl/lang/StdChannel.java
*** tcljava.cvs/src/jacl/tcl/lang/StdChannel.java	Wed Jan 23 02:53:49 2002
--- tcljava.tp/src/jacl/tcl/lang/StdChannel.java	Sun Jun 30 22:29:22 2002
***************
*** 138,144 ****
          // 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);
      }
  
--- 138,145 ----
          // 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.
! 		// Also flush if stdout and interp is connected to a tty
!         if (stdType == STDERR || (stdType == STDOUT && interp.isTty))
              flush(interp);
      }
  
diff -c -r tcljava.cvs/src/tcljava/tcl/lang/TCL.java tcljava.tp/src/tcljava/tcl/lang/TCL.java
*** tcljava.cvs/src/tcljava/tcl/lang/TCL.java	Sun May 14 17:10:20 2000
--- tcljava.tp/src/tcljava/tcl/lang/TCL.java	Sun Jun 30 22:30:02 2002
***************
*** 59,65 ****
  // the completion code TCL.OK.  If the desired completion code is TCL.OK, no
  // exception should be thrown.
  
! 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.
--- 59,65 ----
  // the completion code TCL.OK.  If the desired completion code is TCL.OK, no
  // exception should be thrown.
  
! 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-dev] PATCH: Enhancement to Shell.java

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

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
       

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

[tcljava-dev] PATCH: no flush for PutsCmd

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

I just found a problem where using the puts command
does not flush its output.

It works fine in the Jacl Shell, because the Shell
automatically flushes the stdout output (in putLine method).

However, when using puts command from an Interp,
the output is not flushed!

I have attached a fix for PutsCmd.java to flush
the channel after writing the newline.

I wonder if the Channel should automatically flush itself
when it sees a new line?
ie. if I do "puts -nonewline "hello!\n"
The output is not flushed.

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

Re: [tcljava-dev] Re: [tcljava-user] Swank 1.0 (bugs)

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

On Fri, May 17, 2002 at 08:57:15PM -0400, Bruce Johnson wrote:

I tried mailing a bug report, but I think I sent it to an old address of
yours.  My report is attached below.


> Ooops,  I don't get this Exception because in my copy of tcljava I've 
> made the
>   allowExceptions method in the Interp class public.  This is necessary 
> for the
> bindings to allow breaks in bind scripts.  If anyone would like to 
> submit a patch for
> this that would be great.  Otherwise I'll try to get around to it.


I applied this patch to Jacl, and another to expose TCL.OK as public.  This
allows Swank to compile for me and allows 'bind' to work.   I'd vote to make
these public in Jacl unless there are some easy work-arounds.

I'm still having problems trying to invoke a script from the wisk command line,
e.g. "wisk widget".  

Great work!

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


Swank 1.0 report

Platform: Intel/Linux: $ uname -a
Linux xx.xx.xx 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i686 unknown

TclJava: 1.3.0 from cvs updated on 5/16/02, recompiled and reinstalled.

Java: Sun 1.3.1: $ java -showversion
java version "1.3.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)

I customized 'wisk', it gets invoked as:
$ sh -x /usr/local/bin/wisk
+ TCLJAVA_INSTALL_DIR=/usr/local/lib/tcljava1.3.0
+ SWANK_INSTALL_DIR=/usr/local/lib/swank1.0
+ JACL_CLASSPATH=/usr/local/lib/tcljava1.3.0/tcljava.jar:/usr/local/lib/tcljava1.3.0/jacl.jar
+ SWANK_CLASSPATH=/usr/local/lib/swank1.0/swank.jar:
+ JAVA=/usr/local/java/bin/java
+ JAVA_FLAGS= -ms5m -mx32m
+ CLASSPATH=/usr/local/lib/swank1.0/swank.jar::/usr/local/lib/tcljava1.3.0/tcljava.jar:/usr/local/lib/tcljava1.3.0/jacl.jar
+ export CLASSPATH
+ exec /usr/local/java/bin/java -ms5m -mx32m tcl.lang.SwkShell


------------------------------------------------------------------------------
Bug #1: Unable to run script from command line.

(Running prebuilt swank.jar, invoked with my customized 'wisk'.)

$ cd demos
$ wisk widget

Window appears briefly with "File" menu, title "Widget Demostration", 
then script exits.  

------------------------------------------------------------------------------
Bug #2: Unable to run "demos/widget" main window, bind problems.

(Running prebuilt swank.jar, invoked with my customized 'wisk'.)

$ cd demos
$ wisk
    ("." window appears, tcl prompt)

% source widget
    Widget Demonstration windows with text widget, moving mouse over 
    demo items yields:

Exception occurred during event dispatching:
java.lang.IllegalAccessError: try to access method tcl.lang.Interp.allowExceptions()V from class swank.BindCmd
        at swank.BindCmd.doCmd(BindCmd.java:435)
        at swank.SwkJTextPane.processMouse(SwkJTextPane.java:594)
        at swank.SwkJTextPane.processMouseMotion(SwkJTextPane.java:502)
        at swank.SwkJTextPane$2.mouseMoved(SwkJTextPane.java:180)
        at java.awt.AWTEventMulticaster.mouseMoved(AWTEventMulticaster.java:266)
        at java.awt.Component.processMouseMotionEvent(Component.java:3751)
        at javax.swing.JComponent.processMouseMotionEvent(JComponent.java:2294)
        at java.awt.Component.processEvent(Component.java:3543)
        at java.awt.Container.processEvent(Container.java:1159)
        at java.awt.Component.dispatchEventImpl(Component.java:2588)
        at java.awt.Container.dispatchEventImpl(Container.java:1208)
        at java.awt.Component.dispatchEvent(Component.java:2492)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2239)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120)
        at java.awt.Container.dispatchEventImpl(Container.java:1195)
        at java.awt.Window.dispatchEventImpl(Window.java:921)
        at java.awt.Component.dispatchEvent(Component.java:2492)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:334)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:126)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:80)



The "File" menu seems to work, "File->About..." brings up message dialog, "Ok" 
acknowledges the message; "File->Quit" exists script.
ends the script.





I continued widget testing by sourcing individual widget files:

% source lable.tcl      (ok)
% source button.tcl     (ok)
% source check.tcl      (ok)
% source radio.tcl      (ok)
% source puzzle.tcl     (ok)
% source icon.tcl       (ok)
% source image1.tcl     (ok)
% source image2.tcl     (dialog window loads, but clicking in "File:" listbox
                         yields same java.lang.IllegalAccessError as above)
% source states.tcl     (ok)
% source colors.tcl     (dialog window loads, single clicks on listbox ok,
                         double click yields java.lang.IllegalAccessError,
                         mouse wheel scrolls listbox)
% source sayings.tcl    (ok)
% source entry1.tcl     (ok, text inserts work)
% source entry2.tcl     (ok, text inserts work, scrollbars work)
% source form.tcl       (ok, tabs between entry widgets work)
% source text.tcl       (ok, could not insert selected text with button2,
                         ^C to copy, and ^V to paste works)
% source style.tcl      (ok)
% source bind.tcl       (dialog window loads, all mouse-overs yields
                         java.lang.IllegalAccessError)
% source twind.tcl      (dialog window loads, several bind errors throwing
                         java.lang.IllegalAccessError, no embedded windows)
% source search.tcl     (dialog window loads, load a file, enter search text,
                         pressing 'Return' causes same bind error, no action
                         when pressing "Highlight" button)
% source items.tcl      (dialog window appears, message "invalid option window"
                         no action)
% source plot.tcl       (dialog window loads, same bind errors)
% source ctext.tcl      (dialog window loads, same bind errors)
% source arrow.tcl      (dialog window loads, same bind errors)
% source ruler.tcl      (dialog window loads, same bind errors)
% source floor.tcl      (dialog window loads, same bind errors)
% source cscroll.tcl    (ok)
% source vscale.tcl     (dialog window loads, error dialog "Error: invalid
                         command name ".vscale.frame.canvas", slider appears to
                         work.)
% source hscale.tcl     (dialog window loads, content appears to be clipped,
                         resizing window makes most of it appears, slider works)
% source menu.tcl       (menus seem to work, although many have no action,
                         cascade menus work)
% source menubu.tcl     (dialog window loads, menubutton works, but error
                         bad option ".menubutton.body.below": must be bbox, 
                         columnconfigure, configure, forget, info, location, 
                         propagate, rowconfigure, remove, size, or slaves
% source msgbox.tcl     (ok)
% source filebox.tcl    (ok, file dialogs work) 
% source clrpick.tcl    (dialog window loads, color dialogs work, but pressing
                         "Ok" on color dialog causes bind error
                         java.lang.IllegalAccessError:, color is set)
% source bitmap.tcl     (ok)
% source dialog1.tcl    (ok, didn't test local grab)
% source dialog2.tcl    (ok, didn't test global grab)





------------------------------------------------------------------------------
Bug #3: Rebuilding from source, unable to recompile:

$ configure --with-tcljava=/home/tpoindex/src/java/tcljava
creating cache ./config.cache
srcdir is /home/tpoindex/src/java/swank1.0
./configure: -ms5m: command not found
./configure: -Xrunjdwp:transport=dt_socket,address=8757,server=y,suspend=n: command not found
updating cache ./config.cache
creating ./config.status
creating Makefile

$ make
rm -rf /home/tpoindex/src/java/swank1.0/build
mkdir /home/tpoindex/src/java/swank1.0/build
mkdir /home/tpoindex/src/java/swank1.0/build/swank
mkdir /home/tpoindex/src/java/swank1.0/build/swank/library
mkdir /home/tpoindex/src/java/swank1.0/build/swank/library/images
CLASSPATH=/home/tpoindex/src/java/swank1.0/build:/usr/local/java/jre/lib/rt.jar:/home/tpoindex/src/java/tcljava/btests:/home/tpoindex/src/java/tcljava/jacl.jar:/home/tpoindex/src/java/tcljava/tcljava.jar \
/usr/local/java/bin/javac -g -J-mx35M -d /home/tpoindex/src/java/swank1.0/build /home/tpoindex/src/java/swank1.0/swank/BellCmd.java /home/tpoindex/src/java/swank1.0/swank/BindCmd.java /home/tpoindex/src/java/swank1.0/swank/DestroyCmd.java
(....)
ank1.0/swank/canvas/SwkSymbols.java /home/tpoindex/src/java/swank1.0/swank/print/PrintCmd.java /home/tpoindex/src/java/swank1.0/swank/print/PrintExt.java /home/tpoindex/src/java/swank1.0/tcl/lang/AWTTclEvent.java /home/tpoindex/src/java/swank1.0/tcl/lang/Notifier.java /home/tpoindex/src/java/swank1.0/tcl/lang/SwkShell.java

/home/tpoindex/src/java/swank1.0/swank/BindCmd.java:357: allowExceptions() is not public in tcl.lang.Interp; cannot be accessed from outside package
        interp.allowExceptions();
              ^
/home/tpoindex/src/java/swank1.0/swank/BindCmd.java:372: OK is not public in tcl.lang.TCL; cannot be accessed from outside package
    return TCL.OK;
              ^
/home/tpoindex/src/java/swank1.0/swank/BindCmd.java:435: allowExceptions() is not public in tcl.lang.Interp; cannot be accessed from outside package
        interp.allowExceptions();
              ^
/home/tpoindex/src/java/swank1.0/swank/BindCmd.java:449: OK is not public in tcl.lang.TCL; cannot be accessed from outside package
    return TCL.OK;
              ^
/home/tpoindex/src/java/swank1.0/swank/SwkTableModel.java:294: allowExceptions() is not public in tcl.lang.Interp; cannot be accessed from outside package
        interp.allowExceptions();
              ^
/home/tpoindex/src/java/swank1.0/swank/SwkTableModel.java:306: OK is not public in tcl.lang.TCL; cannot be accessed from outside package
    return TCL.OK;
              ^
/home/tpoindex/src/java/swank1.0/swank/SwkCell.java:163: OK is not public in tcl.lang.TCL; cannot be accessed from outside package
    return TCL.OK;
              ^
7 errors
make: *** [swank.jar] Error 1


------------------------------------------------------------------------------
Other general observations:  


- tk_messageBox - message text does not wrap without explicit \n characters
- widget demo scrolls text box to bottom 


-----------------------------------------------------------------------------
Update, based on your message about binding problems:
-changed Jacl Interp.allowExceptions() to public 
-changed TclJava TCL.OK to public

Jacl recompiled, Swank now compiles, bindings work.

Re: [tcljava-dev] Should-be made public most of methods in tcljava (was: Swank 1.0 bugs)

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

Maurice Diamantini wrote:
> 
> 
> Also, I'tried to make a personnalised shell based on
> tcl.lang.Shell
> But it doesn't worked until I make my personnalised MyShell
> as a class of the tcl.lang package (but letting it into
> my starting project. This is a very bad design for me to be
> constraint to modify the internal jacl packages).
> 
> So probably there is to much non public methods
> in tcljava ?
> Is there any inconvenient to make these public ?
> 

This is something I would also like to be addressed. I've run into problems a
couple of times with access control, for instance, I was looking at the
feasibility of implementing Itcl or similar for Jacl, but stopped when I ran up
against problems adding my own CallFrame object. Because of access control, you
had to create a new CallFrame object in tcl.lang, and also duplicate some of the
Interp code to get it to work. The problem is that while a lot of this may be
private in the C-tcl, it is easy to get around that, whereas in Java, it isn't
:-(

Neil.


-- 
package r Tkhtml;package r http;pack [scrollbar .v -o v -co {.h yv}] -s right\
-f y;pack [html .h -ys {.v set}] -f both -e 1;bind .h.x <1> {eval g [.h href %x\
%y]};proc g u {set t [http::geturl $u];.h cl;.h p [http::data $t];http::cleanup\
$t;.h co -base $u};g http://mini.net/tcl/976.html;proc bgerror args {};# NEM :-)

[tcljava-dev] Should-be made public most of methods in tcljava (was: Swank 1.0 bugs)

[Maurice D. <di...@ma...>]

Le samedi 18 mai 2002, =E0 02:57 , Bruce Johnson a =E9crit :

> Ooops,  I don't get this Exception because in my copy of tcljava I've=20=

> made the
>  allowExceptions method in the Interp class public.  This is necessary=20=

> for the
> bindings to allow breaks in bind scripts.  If anyone would like to=20
> submit a patch for
> this that would be great.  Otherwise I'll try to get around to it.
>
> Bruce

Also, I'tried to make a personnalised shell based on
tcl.lang.Shell
But it doesn't worked until I make my personnalised MyShell
as a class of the tcl.lang package (but letting it into
my starting project. This is a very bad design for me to be
constraint to modify the internal jacl packages).

So probably there is to much non public methods
in tcljava ?
Is there any inconvenient to make these public ?

Maurice Diamantini
http://www.ensta.fr/~diam

Re: [tcljava-dev] Re: [tcljava-user] Swank 1.0 (bugs)

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

Ooops,  I don't get this Exception because in my copy of tcljava I've=20
made the
  allowExceptions method in the Interp class public.  This is necessary=20=

for the
bindings to allow breaks in bind scripts.  If anyone would like to=20
submit a patch for
this that would be great.  Otherwise I'll try to get around to it.

Bruce


On Friday, May 17, 2002, at 07:32 AM, Maurice DIAMANTINI wrote:

> Bruce Johnson said :
>> Swank 1.0  is now available at http://www.nmrview.com/swank.html.
>
> I've done these tests an a linuxppc box with jdk1.3.1.
>
> At each caracter I hit the message is :
>
>  Exception occurred during event dispatching:
> java.lang.IllegalAccessError: try to access method=20
> tcl/lang/Interp.allowExceptions()V from class swank/BindCmd
>         at swank.BindCmd.doCmd(BindCmd.java:435)
>         at swank.SwkKeyListener.processKey(SwkKeyListener.java:125)
>         at swank.SwkKeyListener.keyPressed(SwkKeyListener.java:68)
>         at java.awt.Component.processKeyEvent(Component.java:3677)
>         at =
javax.swing.JComponent.processKeyEvent(JComponent.java:2014)
>         at=20
> javax.swing.JEditorPane.processKeyEvent(JEditorPane.java:1159)
>         at java.awt.Component.processEvent(Component.java:3553)
>         at java.awt.Container.processEvent(Container.java:1164)
>         at java.awt.Component.dispatchEventImpl(Component.java:2593)
>         at java.awt.Container.dispatchEventImpl(Container.java:1213)
>         at java.awt.Component.dispatchEvent(Component.java:2497)
>         at=20
> java.awt.LightweightDispatcher.processKeyEvent(Container.java:2155)
>         at=20
> java.awt.LightweightDispatcher.dispatchEvent(Container.java:2135)
>         at java.awt.Container.dispatchEventImpl(Container.java:1200)
>         at java.awt.Window.dispatchEventImpl(Window.java:926)
>         at java.awt.Component.dispatchEvent(Component.java:2497)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
>         at=20
> java.awt.EventDispatchThread.pumpOneEventForHierarchy
> (EventDispatchThread.java:131)
>         at=20
> =
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.ja=
va:
> 98)
>         at=20
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>         at =
java.awt.EventDispatchThread.run(EventDispatchThread.java:85)
>
>
>
> ------------------------------------------------------------
>> Within the week I'll post a notice
>> to comp.lang.tcl.
>
> Peharps the basic install/use features should work every-where
>
> Apart the fact that java is slow, I'm realy impressed by the work
> you have done !
> And I hope your wish of creating a sourceforge entry for swank
> will be involve that more poeple will use/developp swank
>
>
>> Bruce
>
> --
> Mau...@en...      -       ENSTA/LMA
> =C9cole Nationale Sup=E9rieure  de  Techniques Avanc=E9es
>  Laboratoire    de     Math=E9matiques    Appliqu=E9es
>      http://www.ensta.fr/~diam
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We=20
> supply
> the hardware. You get the recognition. Email Us:=20
> ban...@so...
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

[tcljava-dev] Re: [tcljava-user] Swank 1.0 (bugs)

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

I just tried your examples on my Mac (MacOS X) and they all worked=20
without any problems.  I'll try to run them on Linux soon and see what=20=

the difference is.

Bruce

On Friday, May 17, 2002, at 07:32 AM, Maurice DIAMANTINI wrote:

> Bruce Johnson said :
>> Swank 1.0  is now available at http://www.nmrview.com/swank.html.
>
> I've done these tests an a linuxppc box with jdk1.3.1.
>
>
>
> ------------------------------------------------------------
>> ... I'd appreciate any feedback on getting it running.
>
>
> I had made a custom "wisk" script which ends by the lines
>
>     # ...
>     # ... skip some auto-follow feature code I'll post when the
>     # tcljava/swank packages organisations are stables
>     # ...
>
>
>     # the -Xm... options  replace OBSOLETE java VM options
>     JAVA_FLAGS=3D" -Xms5m -Xmx32m"
>
>     # 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=3D${SWANK_CLASSPATH}:${JACL_CLASSPATH}:${CLASSPATH}
>     # CLASSPATH=3D${JACL_CLASSPATH}:${CLASSPATH}
>     export CLASSPATH
>
>     # java executable should be in the user path
>     #
>     # # exec ${JAVA} ${JAVA_FLAGS} tcl.lang.Shell ${1+"$@"}
>     exec java ${JAVA_FLAGS} tcl.lang.SwkShell ${1+"$@"}
>
>
> Now when I lauch wisk, there is a "wish like" window
>
>
> With standard wish
>     wish
>     % button .b1 -text "B1 =3D> Coucou" -command [list puts "Coucou!"]
>     .b1
>     % button .b2 -text "B2 =3D> exit"  -command exit
>     .b2
>     % pack .b1
>     % pack .b2
>
> It works as expected.
>
> Now when I lauch wisk, there is a "wish like" window so OK,
>     wisk
>     % button .b1 -text "B1 =3D> Coucou" -command [list puts "Coucou!"]
>     .b1
>     % button .b2 -text "B2 =3D> exit"  -command exit
>     .b2
>     % pack .b1
>     % pack .b2
>
> The main wisk windows is not adjusted (ok pack not yet implemented)
> But the .b1 button doesn't puts anything (puts stdout neither).
> The .b2 button does exit as expected
>
>
>
> ------------------------------------------------------------
>> (use "console show"), preliminary support for JInternalPane and
>> JDesktopPane,
>
> Now I test the console command :-)
>
>     wisk
>     % console show
>
> After diplaying a debug message
>     "wm protocol . WM_DELETE_WINDOW { wm withdraw . }"
> A new __very little__ windows appears.
> I resize the window and enter
>
>     set a 1
>
> At each caracter I hit the message is :
>
>  Exception occurred during event dispatching:
> java.lang.IllegalAccessError: try to access method=20
> tcl/lang/Interp.allowExceptions()V from class swank/BindCmd
>         at swank.BindCmd.doCmd(BindCmd.java:435)
>         at swank.SwkKeyListener.processKey(SwkKeyListener.java:125)
>         at swank.SwkKeyListener.keyPressed(SwkKeyListener.java:68)
>         at java.awt.Component.processKeyEvent(Component.java:3677)
>         at =
javax.swing.JComponent.processKeyEvent(JComponent.java:2014)
>         at=20
> javax.swing.JEditorPane.processKeyEvent(JEditorPane.java:1159)
>         at java.awt.Component.processEvent(Component.java:3553)
>         at java.awt.Container.processEvent(Container.java:1164)
>         at java.awt.Component.dispatchEventImpl(Component.java:2593)
>         at java.awt.Container.dispatchEventImpl(Container.java:1213)
>         at java.awt.Component.dispatchEvent(Component.java:2497)
>         at=20
> java.awt.LightweightDispatcher.processKeyEvent(Container.java:2155)
>         at=20
> java.awt.LightweightDispatcher.dispatchEvent(Container.java:2135)
>         at java.awt.Container.dispatchEventImpl(Container.java:1200)
>         at java.awt.Window.dispatchEventImpl(Window.java:926)
>         at java.awt.Component.dispatchEvent(Component.java:2497)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
>         at=20
> java.awt.EventDispatchThread.pumpOneEventForHierarchy
> (EventDispatchThread.java:131)
>         at=20
> =
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.ja=
va:
> 98)
>         at=20
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>         at =
java.awt.EventDispatchThread.run(EventDispatchThread.java:85)
>
>
>
> ------------------------------------------------------------
>> Within the week I'll post a notice
>> to comp.lang.tcl.
>
> Peharps the basic install/use features should work every-where
>
> Apart the fact that java is slow, I'm realy impressed by the work
> you have done !
> And I hope your wish of creating a sourceforge entry for swank
> will be involve that more poeple will use/developp swank
>
>
>> Bruce
>
> --
> Mau...@en...      -       ENSTA/LMA
> =C9cole Nationale Sup=E9rieure  de  Techniques Avanc=E9es
>  Laboratoire    de     Math=E9matiques    Appliqu=E9es
>      http://www.ensta.fr/~diam

[tcljava-dev] Re: [tcljava-user] Swank 1.0 (bugs)

[Maurice D. <di...@en...>]

Bruce Johnson said :
> Swank 1.0  is now available at http://www.nmrview.com/swank.html.

I've done these tests an a linuxppc box with jdk1.3.1.



------------------------------------------------------------
> ... I'd appreciate any feedback on getting it running.  


I had made a custom "wisk" script which ends by the lines

    # ...
    # ... skip some auto-follow feature code I'll post when the 
    # tcljava/swank packages organisations are stables
    # ...


    # the -Xm... options  replace OBSOLETE java VM options
    JAVA_FLAGS=" -Xms5m -Xmx32m"  
    
    # 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=${SWANK_CLASSPATH}:${JACL_CLASSPATH}:${CLASSPATH}
    # CLASSPATH=${JACL_CLASSPATH}:${CLASSPATH}
    export CLASSPATH
    
    # java executable should be in the user path
    # 
    # # exec ${JAVA} ${JAVA_FLAGS} tcl.lang.Shell ${1+"$@"}
    exec java ${JAVA_FLAGS} tcl.lang.SwkShell ${1+"$@"}


Now when I lauch wisk, there is a "wish like" window


With standard wish 
    wish
    % button .b1 -text "B1 => Coucou" -command [list puts "Coucou!"]
    .b1
    % button .b2 -text "B2 => exit"  -command exit
    .b2
    % pack .b1
    % pack .b2

It works as expected.

Now when I lauch wisk, there is a "wish like" window so OK,
    wisk
    % button .b1 -text "B1 => Coucou" -command [list puts "Coucou!"]
    .b1
    % button .b2 -text "B2 => exit"  -command exit
    .b2
    % pack .b1
    % pack .b2
    
The main wisk windows is not adjusted (ok pack not yet implemented)
But the .b1 button doesn't puts anything (puts stdout neither).
The .b2 button does exit as expected



------------------------------------------------------------
> (use "console show"), preliminary support for JInternalPane and 
> JDesktopPane,

Now I test the console command :-)

    wisk
    % console show

After diplaying a debug message 
    "wm protocol . WM_DELETE_WINDOW { wm withdraw . }"
A new __very little__ windows appears.
I resize the window and enter

    set a 1
    
At each caracter I hit the message is :

 Exception occurred during event dispatching:
java.lang.IllegalAccessError: try to access method tcl/lang/Interp.allowExceptions()V from class swank/BindCmd
        at swank.BindCmd.doCmd(BindCmd.java:435)
        at swank.SwkKeyListener.processKey(SwkKeyListener.java:125)
        at swank.SwkKeyListener.keyPressed(SwkKeyListener.java:68)
        at java.awt.Component.processKeyEvent(Component.java:3677)
        at javax.swing.JComponent.processKeyEvent(JComponent.java:2014)
        at javax.swing.JEditorPane.processKeyEvent(JEditorPane.java:1159)
        at java.awt.Component.processEvent(Component.java:3553)
        at java.awt.Container.processEvent(Container.java:1164)
        at java.awt.Component.dispatchEventImpl(Component.java:2593)
        at java.awt.Container.dispatchEventImpl(Container.java:1213)
        at java.awt.Component.dispatchEvent(Component.java:2497)
        at java.awt.LightweightDispatcher.processKeyEvent(Container.java:2155)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2135)
        at java.awt.Container.dispatchEventImpl(Container.java:1200)
        at java.awt.Window.dispatchEventImpl(Window.java:926)
        at java.awt.Component.dispatchEvent(Component.java:2497)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:85)



------------------------------------------------------------
> Within the week I'll post a notice
> to comp.lang.tcl.

Peharps the basic install/use features should work every-where

Apart the fact that java is slow, I'm realy impressed by the work
you have done !
And I hope your wish of creating a sourceforge entry for swank
will be involve that more poeple will use/developp swank


> Bruce

-- 
Mau...@en...      -       ENSTA/LMA
École Nationale Supérieure  de  Techniques Avancées
 Laboratoire    de     Mathématiques    Appliquées 
     http://www.ensta.fr/~diam

Re: [tcljava-dev] propoed patch for bug exec on MacOSX

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

On Wed, 8 May 2002 00:22:23 +0200
Maurice Diamantini <di...@ma...> wrote:

> 
> As suggested by Mo (on the user tcljava list), I've tried
> to make the first patch in my life!
> 
> This patch allowed me to compile jacl and use
> the "exec" command.

This patch has been added to the CVS.

cheers
Mo

Re: [tcljava-dev] propoed patch for bug exec on MacOSX

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

I now do all Swank development on a G4 with OS X so you shouldn't have 
any trouble
getting Swank to work on the Mac.

Bruce

On Tuesday, May 7, 2002, at 10:06 PM, Shawn Boyce wrote:

> Congratulations on your first patch. It appears
> that changes were easier than I thought.
>
> isMac() and isUnix() are used in many places in the
> code. From a quick look at the jacl code, it appears treating
> OSX Macs as UNIX boxes should be ok. Since you are the major
> OSX user at the moment, please try out the file and exec commands
> (which are the most OS dependent).
>
> I would also add a comment to the isMac() method
> to indicate that it only applies to OS9 and earlier.
> OS X and later will be treated as UNIX systems.
>
>
> On Tue, 2002-05-07 at 18:22, Maurice Diamantini wrote:
>>
>> As suggested by Mo (on the user tcljava list), I've tried
>> to make the first patch in my life!
>>
>> This patch allowed me to compile jacl and use
>> the "exec" command.
>> (for Shawn Boyce : I'm not sure this patch is well
>> formated )
>> I generate it with
>> 	cvs diff -u src/jacl/tcl/lang/Util.java
>> But I havn'tried to applay it (and I don't know hot to do
>> for the moment)
>>
>>
>>
>> ###########################
>> 2002-05-07  Maurice Diamantini (or the maintainer ???) <di...@en...>
>>
>> 	* src/jacl/tcl/lang/Util.java
>> 	Util.isMac() now return false if os is MacOS-X (which is an unix)
>> 	so that jacl commands like "exec" works
>>
>> ###########################
>>
>> cvs diff -u src/jacl/tcl/lang/Util.java
>>
>> Index: src/jacl/tcl/lang/Util.java
>> ===================================================================
>> RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Util.java,v
>> retrieving revision 1.9
>> diff -u -r1.9 Util.java
>> --- src/jacl/tcl/lang/Util.java 12 May 2001 23:13:16 -0000      1.9
>> +++ src/jacl/tcl/lang/Util.java 7 May 2002 22:01:32 -0000
>> @@ -1595,8 +1595,10 @@
>>
>>   final static boolean
>>   isMac() {
>> -    String os = System.getProperty("os.name");
>> -    if (os.toLowerCase().startsWith("mac")) {
>> +    String os = System.getProperty("os.name").toLowerCase();
>> +    String version = System.getProperty("os.version");
>> +    // if os is "Mac OS X" one should return false as for unix
>> +    if ( os.startsWith("mac") && !os.endsWith("x") ) {
>>          return true;
>>       }
>>       return false;
>>
>> ####################################
>>
>>
>> _______________________________________________________________
>>
>> Have big pipes? SourceForge.net is looking for download mirrors. We 
>> supply
>> the hardware. You get the recognition. Email Us: 
>> ban...@so...
>> _______________________________________________
>> tcljava-dev mailing list
>> tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We 
> supply
> the hardware. You get the recognition. Email Us: 
> ban...@so...
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

[tcljava-dev] Swank 1.0

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

Swank 1.0  is now available at http://www.nmrview.com/swank.html.

This version has a wide variety of general bug fixes and improvements, a 
console command
(use "console show"), preliminary support for JInternalPane and 
JDesktopPane,
complete implementation of the "place" command.  There is now a 
subdirectory "swktests" of
tests from Tk version 8.3.2.  I'm currently systematically working 
through these and fixing the
Swank code.  I'd appreciate any feedback on getting it running.  Within 
the week I'll post a notice
to comp.lang.tcl.

Bruce

[tcljava-dev] patch for jacl and MacOS-X

[Maurice D. <di...@ma...>]

Bonjour =E0 tous !

Here the patch for the Util.isMac() method.
It allows compiling jacl for MacOS-X (unix bsd like)

I tested (by hand) for the "file" and "exec" commands
They works partially : part of "file" subcommands are
not yet implemended and "exec" commands seems only accept
the basic feature (no &).
For the moment, this patch allows me to use
jacl the same way as for linux-ppc, so it's ok
for me.
As suggested by Shawn Boyce, I adapted the comment before
the method name (fell free to correct any typo!)


###########################
2002-05-07  Maurice Diamantini (or the real maintainer ???)=20
<di...@en...>

       * src/jacl/tcl/lang/Util.java
       Util.isMac() now return false if os is MacOS-X (which is an unix)
       so that jacl commands like "exec" works.

###########################


Index: src/jacl/tcl/lang/Util.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Util.java,v
retrieving revision 1.9
diff -u -r1.9 Util.java
--- src/jacl/tcl/lang/Util.java	12 May 2001 23:13:16 -0000	1.9
+++ src/jacl/tcl/lang/Util.java	13 May 2002 06:51:21 -0000
@@ -1582,7 +1582,8 @@
   *
   * isMac --
   *
- *	Returns true if running on a Mac platform.
+ *	Returns true if running on a Mac platform with MacOS-9 or =
earlier.
+ * MacOS-X and later will be treated as UNIX systems.
   *
   * Results:
   *	Returns a boolean.
@@ -1595,8 +1596,9 @@

  final static boolean
  isMac() {
-    String os =3D System.getProperty("os.name");
-    if (os.toLowerCase().startsWith("mac")) {
+    String os =3D System.getProperty("os.name").toLowerCase();
+    // if os is "Mac OS X": one should return false as for unix
+    if ( os.startsWith("mac") && !os.endsWith("x") ) {
  	return true;
      }
      return false;

####################################

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

[Mark T. <mar...@am...>]

Hello,

I hope I'm doing this correctly - I apologize if not.

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 (for
example,
-Djava.security.manager -Djava.security.policy=file:c:\\tmp\\java.policy).
Prior to
this, the number of args was limited to 2, with one being the CLASSPATH.
The changes (diff -u) are below.

Best wishes,

Mark Thornton

HMS Software
Phone: (847)854-8961
Fax:   (847)854-8986


############################################################################
########

diff -u -w /tcl/src/tclblend1.3.0/src/native/javaCmd.c
/tcl/src/tcljava/tcljava/src/native/javaCmd.c
--- /tcl/src/tclblend1.3.0/src/native/javaCmd.c	Wed May 08 11:18:37 2002
+++ /tcl/src/tcljava/tcljava/src/native/javaCmd.c	Sun Oct 29 20:22:29 2000
@@ -350,7 +350,7 @@
 {
     jsize nVMs;
     char *path, *newPath;
-    int oldSize, size;
+    int oldSize, size, maxOptions = 2;
 #ifdef JDK1_2
     JavaVMOption *options;
     JavaVMInitArgs vm_args;
@@ -359,9 +359,6 @@
 #else
     JDK1_1InitArgs vm_args;
 #endif /* JDK1_2 */
-	int	 i, n_jvm_args = 0;
-	char *tclblend_init, *token, *jvm_args;
-	char jvm_arg_sep[] = " ";

     ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);

@@ -419,52 +416,9 @@
 		fprintf(stderr, "TCLBLEND_DEBUG: No JVM, creating one\n");
 #endif /* TCLBLEND_DEBUG */

-		/* get the classpath */
-		path = getenv("CLASSPATH");
-
         memset(&vm_args, 0, sizeof(vm_args));
 #ifdef JDK1_2
-        /*
-         * If the global tcl_variable tclblend_init is set, then pass its
-         * value to the JVM.
-         * If the value of the string is "help", then initialization
-         * of the JVM does not occur and a usage string is returned.
-         */
-
-		if ((tclblend_init = (void *) Tcl_GetVar(interp, "tclblend_init",
-                            TCL_GLOBAL_ONLY)) != NULL) {
-            if ( !strcmp(tclblend_init, "help")) {
-                Tcl_AppendResult(interp,
-					"The value of the global tcl variable 'tclblend_init' is passed to
the\n "
-					"Java virtual machine upon initialization.\n "
-					"Example values include:\n"
-					"  -Djava.compiler=NONE   - disable Just In Time Compiler\n"
-					"  -Djava.library.path=c:\\jdk\\lib\\tools.jar - set native library
path\n"
-					"  -verbose:jni           - print debugging messages\n"
-					"\nFor -verbose, the value should be a string with one or\n"
-					"more comma separated names (i.e. class,jni).  In JDK1.2,\n"
-					"the standard names are: class, gc, jni\n"
-					"To see what other options are available, run 'java -help'.\n"
-					"Tcl Blend only: If the value is 'help', then JVM initialization
stop\n",
-					"and this message is returned.",
-					NULL);
-                goto error;
-        	}
-			jvm_args = ckalloc(strlen(tclblend_init + 1));
-			strcpy(jvm_args, tclblend_init);
-			token = strtok(jvm_args, jvm_arg_sep);
-			while(token != NULL) {
-				token = strtok(NULL, jvm_arg_sep);
-				n_jvm_args++;
-			}
-		}
-
-		/* if the classpath is set, allow for it */
-		if (path) {
-			n_jvm_args++;
-		}
-
-        options = (JavaVMOption *) ckalloc(sizeof(JavaVMOption) *
n_jvm_args);
+        options = (JavaVMOption *) ckalloc(sizeof(JavaVMOption) *
maxOptions);
         vm_args.version = 0x00010002;
         vm_args.options = options;
         vm_args.ignoreUnrecognized= 1;
@@ -495,6 +449,8 @@
 		 * 1.1, we need to append to the vm_args.classpath.
 		 */

+	path = getenv("CLASSPATH");
+
 #ifdef JDK1_2
 #define JAVA_CLASS_PATH_ARG "-Djava.class.path="
 		if (path) {
@@ -505,31 +461,6 @@
 			strcat(options[0].optionString, path);
 			options[0].extraInfo = (void *)NULL;
 		}
-
-		/* Now add any additional args */
-		i=1;
-		strcpy(jvm_args, tclblend_init);
-		token = strtok(jvm_args, jvm_arg_sep);
-		while(token != NULL) {
-			options[i].optionString = token;
-			options[i].extraInfo = (void *)NULL;
-			token = strtok(NULL, jvm_arg_sep);
-			i++;
-		}
-		ckfree(jvm_args);
-#ifdef TCLBLEND_DEBUG
-		fprintf(stderr, "TCLBLEND_DEBUG: tclblend_init set\n"
-						" vm_args.version: %x\n"
-						" vm_args.nOptions: %d\n",
-						vm_args.version, vm_args.nOptions);
-		for( i = 0; i < n_jvm_args; i++) {
-			fprintf(stderr,
-					" options[%d].optionString = '%s', "
-					" options.[%d].extraInfo = '%s'\n",
-					i, options[i].optionString, i,
-					options[i].extraInfo ? (char *)options[i].extraInfo : "NULL");
-		}
-#endif /* TCLBLEND_DEBUG */
 #else
 		if (path && vm_args.classpath) {
 			oldSize = strlen(path);
@@ -557,6 +488,58 @@
 #endif /* JDK1_2 */
 #endif /* TCLBLEND_DEBUG */

+
+#ifdef JDK1_2
+        /*
+         * If the global tcl_variable tclblend_init is set, then pass its
+         * value to the JVM.
+         * If the value of the string is "help", then initialization
+         * of the JVM does not occur and a usage string is returned.
+         */
+
+        if ((options[vm_args.nOptions].optionString =
+                 (void *) Tcl_GetVar(interp, "tclblend_init",
+                            TCL_GLOBAL_ONLY)) != NULL) {
+            if ( !strcmp((char *)options[vm_args.nOptions].optionString,
"help")) {
+                Tcl_AppendResult(interp,
+    "The value of the global tcl variable 'tclblend_init' is passed to
the\n "
+    "Java virtual machine upon initialization.\n "
+    "Example values include:\n"
+    "  -Djava.compiler=NONE   - disable Just In Time Compiler\n"
+    "  -Djava.library.path=c:\\jdk\\lib\\tools.jar - set native library
path\n"
+    "  -verbose:jni           - print debugging messages\n"
+    "\nFor -verbose, the value should be a string with one or\n"
+    "more comma separated names (i.e. class,jni).  In JDK1.2,\n"
+    "the standard names are: class, gc, jni\n"
+    "To see what other options are available, run 'java -help'.\n"
+    "Tcl Blend only: If the value is 'help', then JVM initialization
stop\n",
+    "and this message is returned.",
+                                NULL);
+                goto error;
+            }
+	    options[vm_args.nOptions].extraInfo = (void *)NULL;
+            vm_args.nOptions++;
+
+#ifdef TCLBLEND_DEBUG
+            {
+            int i;
+            fprintf(stderr, "TCLBLEND_DEBUG: tclblend_init set\n"
+                " vm_args.version: %x\n"
+                " vm_args.nOptions: %d\n",
+                vm_args.version, vm_args.nOptions);
+            for( i = 0; i < maxOptions; i++) {
+                fprintf(stderr,
+                    " options[%d].optionString = '%s', "
+                    " options.[%d].extraInfo = '%s'\n",
+                    i, options[i].optionString, i,
+                    options[i].extraInfo ? (char *)options[i].extraInfo :
"NULL");
+            }
+            }
+#endif /* TCLBLEND_DEBUG */
+
+        }
+#endif /* JDK1_2 */
+
 #ifdef TCLBLEND_DEBUG
 		fprintf(stderr, "TCLBLEND_DEBUG: JNI_CreateJavaVM\n");
 #endif /* TCLBLEND_DEBUG */

Re: [tcljava-dev] propoed patch for bug exec on MacOSX

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

Congratulations on your first patch. It appears
that changes were easier than I thought.

isMac() and isUnix() are used in many places in the
code. From a quick look at the jacl code, it appears treating
OSX Macs as UNIX boxes should be ok. Since you are the major
OSX user at the moment, please try out the file and exec commands
(which are the most OS dependent).

I would also add a comment to the isMac() method
to indicate that it only applies to OS9 and earlier.
OS X and later will be treated as UNIX systems.


On Tue, 2002-05-07 at 18:22, Maurice Diamantini wrote:
> 
> As suggested by Mo (on the user tcljava list), I've tried
> to make the first patch in my life!
> 
> This patch allowed me to compile jacl and use
> the "exec" command.
> (for Shawn Boyce : I'm not sure this patch is well
> formated )
> I generate it with
> 	cvs diff -u src/jacl/tcl/lang/Util.java
> But I havn'tried to applay it (and I don't know hot to do
> for the moment)
> 
> 
> 
> ###########################
> 2002-05-07  Maurice Diamantini (or the maintainer ???) <di...@en...>
> 
> 	* src/jacl/tcl/lang/Util.java
> 	Util.isMac() now return false if os is MacOS-X (which is an unix)
> 	so that jacl commands like "exec" works
> 
> ###########################
> 
> cvs diff -u src/jacl/tcl/lang/Util.java
> 
> Index: src/jacl/tcl/lang/Util.java
> ===================================================================
> RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Util.java,v
> retrieving revision 1.9
> diff -u -r1.9 Util.java
> --- src/jacl/tcl/lang/Util.java 12 May 2001 23:13:16 -0000      1.9
> +++ src/jacl/tcl/lang/Util.java 7 May 2002 22:01:32 -0000
> @@ -1595,8 +1595,10 @@
> 
>   final static boolean
>   isMac() {
> -    String os = System.getProperty("os.name");
> -    if (os.toLowerCase().startsWith("mac")) {
> +    String os = System.getProperty("os.name").toLowerCase();
> +    String version = System.getProperty("os.version");
> +    // if os is "Mac OS X" one should return false as for unix
> +    if ( os.startsWith("mac") && !os.endsWith("x") ) {
>          return true;
>       }
>       return false;
> 
> ####################################
> 
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

[tcljava-dev] propoed patch for bug exec on MacOSX

[Maurice D. <di...@ma...>]

As suggested by Mo (on the user tcljava list), I've tried
to make the first patch in my life!

This patch allowed me to compile jacl and use
the "exec" command.
(for Shawn Boyce : I'm not sure this patch is well
formated )
I generate it with
	cvs diff -u src/jacl/tcl/lang/Util.java
But I havn'tried to applay it (and I don't know hot to do
for the moment)



###########################
2002-05-07  Maurice Diamantini (or the maintainer ???) <di...@en...>

	* src/jacl/tcl/lang/Util.java
	Util.isMac() now return false if os is MacOS-X (which is an unix)
	so that jacl commands like "exec" works

###########################

cvs diff -u src/jacl/tcl/lang/Util.java

Index: src/jacl/tcl/lang/Util.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Util.java,v
retrieving revision 1.9
diff -u -r1.9 Util.java
--- src/jacl/tcl/lang/Util.java 12 May 2001 23:13:16 -0000      1.9
+++ src/jacl/tcl/lang/Util.java 7 May 2002 22:01:32 -0000
@@ -1595,8 +1595,10 @@

  final static boolean
  isMac() {
-    String os = System.getProperty("os.name");
-    if (os.toLowerCase().startsWith("mac")) {
+    String os = System.getProperty("os.name").toLowerCase();
+    String version = System.getProperty("os.version");
+    // if os is "Mac OS X" one should return false as for unix
+    if ( os.startsWith("mac") && !os.endsWith("x") ) {
         return true;
      }
      return false;

####################################

Re: [tcljava-dev] jacl tests

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

On Wed, 17 Apr 2002 00:00:52 -0400
Shawn Boyce <sh...@bo...> wrote:

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

Yes, lots of the test make bad assumptions about the signatures of things. The more simple fix would be to put in checks for the JDK version in the test. The more correct and therefore harder fix would be to rewrite the package reflection code in FuncSig.java so that it uses getDeclaredMethods and not getAllDeclaredMethods for class method searched where no special Tcl PkgInvoker class exist. I have been meaning to do the second task for some time but I never got around to it. Would you like to give it a shot?

Mo