tcljava-dev — discuss implementation and post patches here

Re: [tcljava-dev] file copy and directories

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

On Sat, 8 Dec 2001 01:48:38 -0800
"Raffaele Sena" <ra...@ar...> wrote:

> Here are the changes that add support for directories to "file copy".
> I may be missing some check and some proper error message, but they
> work.
> 
> -- Raffaele

Need patch in -u format along with test cases. If you could also post a
ChangeLog entry that would be great.

Mo

Re: [tcljava-dev] Bug in FileCmd.java

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

On Fri, 7 Dec 2001 16:24:04 -0800
"Raffaele Sena" <ra...@ar...> wrote:

> I just found a small bug in FileCmd.java (small, but very bad ):
> 
> Don't know why, but the copy loop in copyRenameFile() is wrong and doesn't
> work at all. The "offset" parameters in reader.read and writer.write are
> referred to the offset in the buffer NOT in the file. So in this case the
> value should always be 0 (write at the beginning of the buffer) or you get
> an IndexOutOfBound exception.
> 
> Here is the fix:

First off, you will need to post patched in unidiff format (pass -u to diff).
You might want to add the following to your ~/.cvsrc file.

% cat ~/.cvsrc
cvs -q -z3
diff -uN
update -P

It would also be great if you could attach a test case for this problem.
The IO subsystem is in the middle of a rewrite just now so every test
case helps.

> Also, since "file copy" can be used to copy big binary files,
> wouldn't something that works with bytes be better than chars
> (just to avoid the possibility that Java would do something
> strange with character encoding).

Encodings don't work at all just now. The IO subsystem rewrite
should take care of this, and it will change a bunch of things.

cheers
Mo

[tcljava-dev] Java 1.4 - breaks TclBlend?

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

I've been playing with Java 1.4 recently, and it appears to break
TclBlend. The problem is that the classic VM is no longer shipped (there
is a "client" HotSpot VM instead - will this work in place?). Details
at:

http://java.sun.com/j2se/1.4/docs/relnotes/features.html#vm

Does this break TclBlend, or can it be made to work with the new setup.
It's quite irritating.

Neil.

[tcljava-dev] file copy and directories

[Raffaele S. <ra...@ar...>]

Here are the changes that add support for directories to "file copy".
I may be missing some check and some proper error message, but they
work.

-- Raffaele

Index: src/jacl/tcl/lang/FileCmd.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/FileCmd.java,v
retrieving revision 1.5
diff -b -r1.5 FileCmd.java
99a100,101
> private static final int COPYBUFFER_SIZE = 4096;
>
1088a1091
>     if (targetFileObj.exists()) {
1100a1104
>     }
1109a1114,1116
>     } else
>     if (sourceFileObj.isDirectory()) {
>       copyDirectory(interp, sourceName, targetName, force);
1114,1115c1121,1122
<      // Read source to "cbuf" char array one line at a time.
<      // For each line, Write cbuf to target.
---
>      // Read source to "buf" byte array one block at a time.
>      // For each block, Write buf to target.
1117,1123c1124,1129
<      BufferedReader reader =
<   new BufferedReader(new FileReader(sourceFileObj));
<      BufferedWriter writer =
<   new BufferedWriter(new FileWriter(targetFileObj));
<      char cbuf[] = new char[256];
<      int currentIndex = 0;
<      int numChars = reader.read(cbuf, 0, 256);
---
>      BufferedInputStream reader =
>   new BufferedInputStream(new FileInputStream(sourceFileObj));
>      BufferedOutputStream writer =
>   new BufferedOutputStream(new FileOutputStream(targetFileObj));
>      byte buf[] = new byte[COPYBUFFER_SIZE];
>      int numChars = reader.read(buf, 0, COPYBUFFER_SIZE);
1125,1127c1131,1132
<   writer.write(cbuf, currentIndex, numChars);
<   currentIndex += 256;
<   numChars = reader.read(cbuf, currentIndex, 256);
---
>   writer.write(buf, 0, numChars);
>   numChars = reader.read(buf, 0, COPYBUFFER_SIZE);
1133a1139,1207
>     }
> }
>
> 
> /*
>
*-----------------------------------------------------------------------------
>  *
>  * copyDirectory --
>  *
>  * Create the target directory and copy each file in the source
>  * directory.
>  *
>  *      If there are any subdirectories, copyDirectory will be called
>  *      recursively (by copyRenameOneFile).
>  *
>  * Results:
>  * None.
>  *
>  * Side effects:
>  * See user documentation.
>  *
>
*-----------------------------------------------------------------------------
>  */
>
> private static void
> copyDirectory(
>     Interp interp,     // Current interpreter.
>     String sourceName,    // Name of source file.
>     String targetName,    // Name of target file.
>     boolean force)    // Flag tells whether to overwrite.
> throws
>     TclException    // Thrown as a result of bad user input.
> {
>     boolean madeDir = false;
>
>         // we already checked this before
>     File sourceDirObj = FileUtil.getNewFileObj(interp, sourceName);
>     File targetDirObj = FileUtil.getNewFileObj(interp, targetName);
>
>         // the output directory doesn't exist
>     try {
>         madeDir = targetDirObj.mkdir();
>         if (!madeDir) {
>             madeDir = targetDirObj.mkdirs();
>         }
>     } catch (SecurityException e) {
>         throw new TclException(interp, e.getMessage());
>     }
>     if (!madeDir) {
>         throw new TclPosixException(interp, TclPosixException.EACCES, true,
>                 "can't create directory \"" + targetName +
>                 "\":  best guess at reason");
>     }
>
>         // scan the source directory and copy each file
>     String fileList[] = sourceDirObj.list();
>     for (int i = 0; i < fileList.length; i++) {
>
>         TclObject joinArrayObj[] = new TclObject[2];
>
>         joinArrayObj[0] = TclString.newInstance(sourceName);
>         joinArrayObj[1] = TclString.newInstance(fileList[i]);
>         String sourcePath = FileUtil.joinPath(interp, joinArrayObj, 0, 2);
>
>         joinArrayObj[0] = TclString.newInstance(targetName);
>         joinArrayObj[1] = TclString.newInstance(fileList[i]);
>         String targetPath = FileUtil.joinPath(interp, joinArrayObj, 0, 2);
>
>         copyRenameOneFile(interp, sourcePath, targetPath, true, force);

[tcljava-dev] Bug in FileCmd.java

[Raffaele S. <ra...@ar...>]

I just found a small bug in FileCmd.java (small, but very bad ):

Don't know why, but the copy loop in copyRenameFile() is wrong and doesn't
work at all. The "offset" parameters in reader.read and writer.write are
referred to the offset in the buffer NOT in the file. So in this case the
value should always be 0 (write at the beginning of the buffer) or you get
an IndexOutOfBound exception.

Here is the fix:

Index: FileCmd.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/FileCmd.java,v
retrieving revision 1.5
diff -b -r1.5 FileCmd.java
1122d1121
<           int currentIndex = 0;
1125,1127c1124,1125
<               writer.write(cbuf, currentIndex, numChars);
<               currentIndex += 256;
<               numChars = reader.read(cbuf, currentIndex, 256);
---
>               writer.write(cbuf, 0, numChars);
>               numChars = reader.read(cbuf, 0, 256);


Also, since "file copy" can be used to copy big binary files,
wouldn't something that works with bytes be better than chars
(just to avoid the possibility that Java would do something
strange with character encoding).

The classes BufferedInputStream/BufferedOutputStream work like
BufferedReader and BufferedWriter, but on a stream of bytes instead
of chars.

One more thing: maybe the buffer size can be increased to something
like 4Kb, to limit the number of calls.


Another problem I found in the "file copy" is that copying of directories
is not implemented. I am working on it. I'll send in the changes once I am
done.

-- Raffaele

-----------------------------------------------------
ra...@ar... (::) http://www.aromatic.org/~raff/

When I say artist I mean the man who is building things
 -- creating molding the earth -- whether it be the plains of the west
 -- or the iron ore of Penn. It's all a big game of construction
 -- some with a brush -- some with a shovel -- some choose a pen.

                             Jackson Pollock

RE: [tcljava-dev] Jacl and stdout channel

[Raffaele S. <ra...@ar...>]

>Humm, this one seems a little tricky. It was caused by the recent Channel
>rewrite. The problem is that we are writing to our own buffer before sending
>the data to System.out and that buffer is not getting flushed when the
>interp exits. I would have though the Writer classes would have a finalize()
>method that would flush the buffer, but it seems that is not implemented.
What
>do you think of the following patch? The patch turns on finalization at exit
>time and adds a finalize method to the Channel class.

Thanks Mo, I will try the changes.

The only problems I can see with this approach is that you don't
know when finalizers are called (when objects are garbage-collected)
and the runFinalizerOnExit() method is deprecated.

Also, this method works only when running the Shell and if the shell
really exists. I actually am thinking of running the interpreter from
inside a "server" environment, either by creating my own interpreter
or by "calling" the Shell main method and catching the System.exit()
(and so making the runFinalizerOnExit() quite ineffective.


Anyway, I'll play with it and see what I can come up with.

Thanks,

    Raffaele

Re: [tcljava-dev] Jacl and stdout channel

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

On Wed, 5 Dec 2001 02:01:32 -0800
"Raffaele Sena" <ra...@ar...> wrote:

> Hi,
> 
> I downloaded the latest sources from CVS and started playing with it.
> 
> One thing I noticed is the following:
> 
> - if I run jacl in interactive mode, everything works fine.
>   I can write to standard output with "puts" and get my string printed out.
> 
> - if I run jacl non interactive (with a script), print to standard output
>   don't... get printed.
>   The problem seems to be a missing flush() somewhere (if I end my script
>   with "flush" the missing messages appear), but I cannot find a good place
>   where to flush the stdout channel. I tried do add a "finally" clause to
>   the try/catch block in Shell.java, but while a simple test worked find,
>   a more complex test didn't.
> 
> -- Raffaele

Humm, this one seems a little tricky. It was caused by the recent Channel
rewrite. The problem is that we are writing to our own buffer before sending
the data to System.out and that buffer is not getting flushed when the
interp exits. I would have though the Writer classes would have a finalize()
method that would flush the buffer, but it seems that is not implemented. What
do you think of the following patch? The patch turns on finalization at exit
time and adds a finalize method to the Channel class.


Index: src/jacl/tcl/lang/Channel.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Channel.java,v
retrieving revision 1.15
diff -u -r1.15 Channel.java
--- src/jacl/tcl/lang/Channel.java	2001/11/27 18:05:25	1.15
+++ src/jacl/tcl/lang/Channel.java	2001/12/06 17:43:08
@@ -87,6 +87,22 @@
     protected String encoding = "iso8859-1";
 
     /**
+     * A finalizer is invoked before the Object is cleaned up by the
+     * garbage collector. Channel requires one so that the output
+     * buffers are properly flushed.
+     *
+     */
+
+    protected void finalize()
+    {
+        try {
+            close();
+        } catch (IOException ex) {
+            ex.printStackTrace(System.err);
+        }
+    }
+
+    /**
      * Read data from the Channel.
      * 
      * @param interp is used for TclExceptions.  
Index: src/jacl/tcl/lang/Shell.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/Shell.java,v
retrieving revision 1.10
diff -u -r1.10 Shell.java
--- src/jacl/tcl/lang/Shell.java	2001/11/18 06:29:37	1.10
+++ src/jacl/tcl/lang/Shell.java	2001/12/06 17:43:10
@@ -50,6 +50,12 @@
 {
     String fileName = null;
 
+    // Inform system that Object.finalize() methods need to be
+    // run before exiting. This is required so that the Interp
+    // can clean itself up and flush buffers before exiting.
+
+    System.runFinalizersOnExit(true);
+
     // Create the interpreter. This will also create the built-in
     // Tcl commands.


Any reactions?
Mo DeJong

[tcljava-dev] Jacl and stdout channel

[Raffaele S. <ra...@ar...>]

Hi,

I downloaded the latest sources from CVS and started playing with it.

One thing I noticed is the following:

- if I run jacl in interactive mode, everything works fine.
  I can write to standard output with "puts" and get my string printed out.

- if I run jacl non interactive (with a script), print to standard output
  don't... get printed.
  The problem seems to be a missing flush() somewhere (if I end my script
  with "flush" the missing messages appear), but I cannot find a good place
  where to flush the stdout channel. I tried do add a "finally" clause to
  the try/catch block in Shell.java, but while a simple test worked find,
  a more complex test didn't.

-- Raffaele

-----------------------------------------------------
ra...@ar... (::) http://www.aromatic.org/~raff/

When I say artist I mean the man who is building things
 -- creating molding the earth -- whether it be the plains of the west 
 -- or the iron ore of Penn. It's all a big game of construction 
 -- some with a brush -- some with a shovel -- some choose a pen.

                             Jackson Pollock     

RE: [tcljava-dev] Channel drivers and fconfigure command for Jacl

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

On Fri, 23 Nov 2001 19:56:41 -0500
"Johnson, Bruce A" <bru...@me...> wrote:

> Mo,
> 
> I've uploaded a tar file (modfiles.tar.gz) of the changed java source files
> and a text file listing the files and summarizing the changes.  You can find
> them both by 
> ftp'ing to www.nmrview.com and looking in /pub/tcljava.

Bruce, looking at the code for Channel.java, I notice the following:

    /**
    * Translation mode for end-of-line character
    */
    
    protected int translation[] = {0, 0};

And also:

    /**
    * EOF character 0: for input 1: for output
    */
    
    protected Character eofChar[] = {null, null};



But in the Tcl source code, the following is used:

    Tcl_EolTranslation inputTranslation;
				/* What translation to apply for end of line
				 * sequences on input? */    
    Tcl_EolTranslation outputTranslation;
				/* What translation to use for generating
				 * end of line sequences in output? */
    int inEofChar;		/* If nonzero, use this as a signal of EOF
				 * on input. */
    int outEofChar;             /* If nonzero, append this to the channel
				 * when it is closed if it is open for
				 * writing. */

Why should we use an array instead of two variables?

cheers
Mo

RE: [tcljava-dev] Channel drivers and fconfigure command for Jacl

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

Hi Mo,

I've been looking over the file code this weekend and thinking about the
changes you suggested.  I'm not sure it would be so easy now to simply
extend a Reader and Writer class  to incorporate the Tcl style stuff.  The
problem comes because Tcl IO requires random access to the files with both
read and write access.  To properly manage a buffer for both the reading and
writing in a way that will pass all the tcl io tests that my current
implementation passes would be difficult.  Since you've already added some
concrete methods to the Channel class, and the end-of-line stuff will only
likely be used with Channels, I'm not sure of the problem with having it as
a concrete implementation in Channel.  At this point it seems easier to
merge the socket stuff and your other changes into my file changes, which
I'm happy to do.  This may involve moving some stuff between my FileChannel
and Channel implementation, in some way to best share it as necessary with
the socket requirements.  I'm certainly open to suggestions as well, part of
the problem is that I don't want to have to deal with breaking to many
things that pass the io tests now, because I'm short of time to fix them.

Bruce


-----Original Message-----
From: Mo DeJong [mailto:su...@ba...]
Sent: Friday, November 23, 2001 2:55 PM
To: tcljava-dev
Subject: [tcljava-dev] Channel drivers and fconfigure command for Jacl


On Fri, 23 Nov 2001 19:56:41 -0500
"Johnson, Bruce A" <bru...@me...> wrote:

> Mo,
> 
> I've uploaded a tar file (modfiles.tar.gz) of the changed java source
files
> and a text file listing the files and summarizing the changes.  You can
find
> them both by 
> ftp'ing to www.nmrview.com and looking in /pub/tcljava.
> 
> cheers,

This looks great, but I am noticing a couple of problems right off the bat.
I just finished up a bunch of work to refactor all of the subclasses of
Channel
as part of adding the socket command. The current CVS has these changes.
Trouble is, your changes are kind of like the ones I made only different.
This means we will have to work out how to merge the two in the best way
we can. Could you take a look at the current CVS and your code and let
me know what you think?

I also noticed that you also turned some methods in the Channel class
into a concrete implementation instead of an abstract method. One thing I
am not sure I like is the way you do the EOL conversion and buffering inside
the Channel class. Don't you think it would be easier to create a pair of
classes that extend Reader and Writer and provide Tcl style buffering,
EOL conversion, and Tcl style encoding names (if needed).

let me know what you think
Mo




_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev

RE: [tcljava-dev] Channel drivers and fconfigure command for Jacl

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

I'll take a look at it all this weekend.  It shouldn't be hard to move the
EOL stuff out of Channel.

Bruce

Bruce A. Johnson, PhD
Sr. Research Fellow
Merck & Co., Inc.
RY80Y-103
PO Box 2000
Rahway, NJ  07065-0900
 
732 594-3166 (voice)
732 594-2991 (fax)
bru...@me... 


-----Original Message-----
From: Mo DeJong [mailto:su...@ba...]
Sent: Friday, November 23, 2001 2:55 PM
To: tcljava-dev
Subject: [tcljava-dev] Channel drivers and fconfigure command for Jacl


On Fri, 23 Nov 2001 19:56:41 -0500
"Johnson, Bruce A" <bru...@me...> wrote:

> Mo,
> 
> I've uploaded a tar file (modfiles.tar.gz) of the changed java source
files
> and a text file listing the files and summarizing the changes.  You can
find
> them both by 
> ftp'ing to www.nmrview.com and looking in /pub/tcljava.
> 
> cheers,

This looks great, but I am noticing a couple of problems right off the bat.
I just finished up a bunch of work to refactor all of the subclasses of
Channel
as part of adding the socket command. The current CVS has these changes.
Trouble is, your changes are kind of like the ones I made only different.
This means we will have to work out how to merge the two in the best way
we can. Could you take a look at the current CVS and your code and let
me know what you think?

I also noticed that you also turned some methods in the Channel class
into a concrete implementation instead of an abstract method. One thing I
am not sure I like is the way you do the EOL conversion and buffering inside
the Channel class. Don't you think it would be easier to create a pair of
classes that extend Reader and Writer and provide Tcl style buffering,
EOL conversion, and Tcl style encoding names (if needed).

let me know what you think
Mo




_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev

[tcljava-dev] Channel drivers and fconfigure command for Jacl

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

On Fri, 23 Nov 2001 19:56:41 -0500
"Johnson, Bruce A" <bru...@me...> wrote:

> Mo,
> 
> I've uploaded a tar file (modfiles.tar.gz) of the changed java source files
> and a text file listing the files and summarizing the changes.  You can find
> them both by 
> ftp'ing to www.nmrview.com and looking in /pub/tcljava.
> 
> cheers,

This looks great, but I am noticing a couple of problems right off the bat.
I just finished up a bunch of work to refactor all of the subclasses of Channel
as part of adding the socket command. The current CVS has these changes.
Trouble is, your changes are kind of like the ones I made only different.
This means we will have to work out how to merge the two in the best way
we can. Could you take a look at the current CVS and your code and let
me know what you think?

I also noticed that you also turned some methods in the Channel class
into a concrete implementation instead of an abstract method. One thing I
am not sure I like is the way you do the EOL conversion and buffering inside
the Channel class. Don't you think it would be easier to create a pair of
classes that extend Reader and Writer and provide Tcl style buffering,
EOL conversion, and Tcl style encoding names (if needed).

let me know what you think
Mo

RE: [tcljava-dev] How much alive is jacl ?

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

Mo,

I've uploaded a tar file (modfiles.tar.gz) of the changed java source files
and a text file listing the files and summarizing the changes.  You can find
them both by 
ftp'ing to www.nmrview.com and looking in /pub/tcljava.

cheers,

Bruce

Bruce A. Johnson, PhD
Sr. Research Fellow
Merck & Co., Inc.
RY80Y-103
PO Box 2000
Rahway, NJ  07065-0900
 
732 594-3166 (voice)
732 594-2991 (fax)
bru...@me... 


-----Original Message-----
From: Mo DeJong [mailto:su...@ba...]
Sent: Friday, November 16, 2001 5:32 PM
To: tcljava-dev
Subject: Re: [tcljava-dev] How much alive is jacl ?


On Fri, 16 Nov 2001 15:58:38 -0500
"Johnson, Bruce A" <bru...@me...> wrote:

> I just want to second Mo's statement that Jacl is still alive.  I use it
> every day and am still working on SWANK (Tk-like companion to Jacl).  I've
> also got a lot of file code I need to get worked into the main
distribution.
> Unfortunately, I've been swamped with things that are more directly
related
> to work.
> 
> Bruce

Hi Bruce.

Could you repost a link to that io code you wrote? I just did a commit of a
first
revision of the socket command for Jacl, so it seems now would be a good
time
to get the channel code finished up.

thanks
Mo

_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev

[tcljava-dev] Checking validity of interpreter.

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

Please ignore my previous post on CallFrames - I've solved that
particular problem. But now I have a new one. How can I check whether an
interpreter is still valid - i.e. that it hasn't been deleted? In some
code, I store a reference to an Interp object. At some later stage, I
need to evaluate some Tcl code in the interpreter. I need first, though,
to check that the reference I have is still valid. If it isn't then I
can clean up my code and throw an exception. However, there doesn't seem
to be any way to tell if an Interp object is still valid. I noticed in
the sources that there is a "deleted" flag in the Interp object, which
is set when the interpreter is disposed. Could a isValid() method be
added to the Interp object to check this flag? Something along the lines
of:

public boolean isValid() {
	return deleted;
}

would do the trick. Is this a bad idea, or is there another way to do
this? If there are no objections, could this be added?

Cheers,

Neil Madden.

PS - I notice that a lot of the code in the Jacl source imports whole
packages, but only uses some of the classes in that package (e.g.
java.util.*, java.io.* etc). Does this load all the classes of that
package into the virtual machine, or does it wait until they are
actually used? I'm a bit sketchy on this point. If the former, then
could a script be written to traverse the source and replace these with
imports of only the classes that were actually used, to save some
startup time, and memory usage? The script could have a threshold so
that if more than x classes from a package were imported, then do an
'import package.*', to prevent massive lists of imports at the top of
source files. Another alternative would be to use fully qualified names
in the code, and get load-on-demand, but this would make the source a
bit unreadable. Any thoughts?

[tcljava-dev] [Fwd: CallFrame and interp.newCallFrame() questions.]

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

Hmm... lost my permission to post this, but hopefully it should make it
through this time.

-------- Original Message --------
Subject: CallFrame and interp.newCallFrame() questions.
Date: Tue, 20 Nov 2001 21:45:36 +0000
From: Neil Madden <ne...@cs...>
Organization: University of Nottingham (Computer Science Undergrad)
To: tcl...@li...

Looking through the source code for Jacl, I notice that the CallFrame
class starts with the message "This class can be overridden to provide
new variable scoping rules for the Tcl interpreter.". Similarly, the
Interp.newCallFrame() method has the message "This method can be
overridden to provide debugging support". Who are these comments meant
for? The CallFrame class has package-only access, and
Interp.newCallFrame() is protected, so you could only subclass them (and
override their behaviour) if your class is in the tcl.lang package. So,
is this functionality for overriding the default behaviour meant only
for people building their own private Jacl distro, or is there some
other way to register your own CallFrame class with Jacl? I ask because
I am playing around with writing a simple OO extension for Jacl (with
some neat features though), and it would be useful for me to define a
new CallFrame for use with methods on my objects. I don't want to put
any of my classes in the tcl.lang package, as that would just be messy.
Anyone know?

Neil

Re: [tcljava-dev] How much alive is jacl ?

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

On Fri, 16 Nov 2001 15:58:38 -0500
"Johnson, Bruce A" <bru...@me...> wrote:

> I just want to second Mo's statement that Jacl is still alive.  I use it
> every day and am still working on SWANK (Tk-like companion to Jacl).  I've
> also got a lot of file code I need to get worked into the main distribution.
> Unfortunately, I've been swamped with things that are more directly related
> to work.
> 
> Bruce

Hi Bruce.

Could you repost a link to that io code you wrote? I just did a commit of a first
revision of the socket command for Jacl, so it seems now would be a good time
to get the channel code finished up.

thanks
Mo

RE: [tcljava-dev] How much alive is jacl ?

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

I just want to second Mo's statement that Jacl is still alive.  I use it
every day and am still working on SWANK (Tk-like companion to Jacl).  I've
also got a lot of file code I need to get worked into the main distribution.
Unfortunately, I've been swamped with things that are more directly related
to work.

Bruce

-----Original Message-----
From: Mo DeJong [mailto:su...@ba...]
Sent: Friday, November 02, 2001 1:40 AM
To: tcljava-dev
Subject: Re: [tcljava-dev] How much alive is jacl ?


On Wed, 31 Oct 2001 23:25:50 -0800
"Raffaele Sena" <ra...@ar...> wrote:

> Hello there!

Hi Raffaele.

> I am looking for a scripting language to use
> for the (java based) application server I
> am working on.
> 
> I knew of the exiestence of Jacl but never really
> looked into it until now. Today I finally decided
> to give it a try and actually it does do pretty much
> everything I need.
> 
> My only concern is, is Jacl still alive ? And how
> alive is it ?

It is alive, but there has not been any active development
recently. That does not mean there is anything wrong
with it. It just means folks don't have time to donate
right now.

> Today while playing with it I found a small problem
> with the exec command ( sh, at least on linux, doesn't
> like the redirection tokens to be quoted and because of
> this things like "exec ls -l > /tmp/out" does not work.
> Also the redirect to fileid - >@ and such - is not implemented).

Redirection is not really supported by the Jacl exec command.
I think this is mentioned in the docs. It might work with some
shell tricks but you would be using sh redirection not redirects
done by Tcl.

> No big deal. The code is very readable and some of these
> things can be easily fixed. I am just wondering how many
> of these problems I am going to find (what I found today
> doesn't seem to be reported anywhere) and how much support
> will I get to fix them. I'll be happy to contribute to the
> project, but I wouldn't want to spend more time working on
> jacl than on my project.

Jacl is *most* of Tcl, but there are some things that are not implemented.
The diffs.txt file that comes with Jacl describes most of the diffs. More
features are implemented in the CVS development version as well, so
that is something to keep in mind. Feel free to ask questions if you
can't find the info you need in the docs.

cheers
Mo DeJong




_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] How much alive is jacl ?

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

On Wed, 31 Oct 2001 23:25:50 -0800
"Raffaele Sena" <ra...@ar...> wrote:

> Hello there!

Hi Raffaele.

> I am looking for a scripting language to use
> for the (java based) application server I
> am working on.
> 
> I knew of the exiestence of Jacl but never really
> looked into it until now. Today I finally decided
> to give it a try and actually it does do pretty much
> everything I need.
> 
> My only concern is, is Jacl still alive ? And how
> alive is it ?

It is alive, but there has not been any active development
recently. That does not mean there is anything wrong
with it. It just means folks don't have time to donate
right now.

> Today while playing with it I found a small problem
> with the exec command ( sh, at least on linux, doesn't
> like the redirection tokens to be quoted and because of
> this things like "exec ls -l > /tmp/out" does not work.
> Also the redirect to fileid - >@ and such - is not implemented).

Redirection is not really supported by the Jacl exec command.
I think this is mentioned in the docs. It might work with some
shell tricks but you would be using sh redirection not redirects
done by Tcl.

> No big deal. The code is very readable and some of these
> things can be easily fixed. I am just wondering how many
> of these problems I am going to find (what I found today
> doesn't seem to be reported anywhere) and how much support
> will I get to fix them. I'll be happy to contribute to the
> project, but I wouldn't want to spend more time working on
> jacl than on my project.

Jacl is *most* of Tcl, but there are some things that are not implemented.
The diffs.txt file that comes with Jacl describes most of the diffs. More
features are implemented in the CVS development version as well, so
that is something to keep in mind. Feel free to ask questions if you
can't find the info you need in the docs.

cheers
Mo DeJong

[tcljava-dev] How much alive is jacl ?

[Raffaele S. <ra...@ar...>]

Hello there!

I am looking for a scripting language to use
for the (java based) application server I
am working on.

I knew of the exiestence of Jacl but never really
looked into it until now. Today I finally decided
to give it a try and actually it does do pretty much
everything I need.

My only concern is, is Jacl still alive ? And how
alive is it ?

Today while playing with it I found a small problem
with the exec command ( sh, at least on linux, doesn't
like the redirection tokens to be quoted and because of
this things like "exec ls -l > /tmp/out" does not work.
Also the redirect to fileid - >@ and such - is not implemented).

No big deal. The code is very readable and some of these
things can be easily fixed. I am just wondering how many
of these problems I am going to find (what I found today
doesn't seem to be reported anywhere) and how much support
will I get to fix them. I'll be happy to contribute to the
project, but I wouldn't want to spend more time working on
jacl than on my project.

Any comment is appreciated.

-- Raffaele

-----------------------------------------------------
ra...@ar... (::) http://www.aromatic.org/~raff/

When I say artist I mean the man who is building things
 -- creating molding the earth -- whether it be the plains of the west 
 -- or the iron ore of Penn. It's all a big game of construction 
 -- some with a brush -- some with a shovel -- some choose a pen.

                             Jackson Pollock     

[tcljava-dev] Test (Please Ignore)

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

Testing tcljava-dev.

[tcljava-dev] Errors compiling for Windows from CVS

[Donle, R. <RD...@un...>]

I'm trying to compile TclBlend on Windows by using the source from CVS
(which currently appears to be 1.3).  In the end, I'd like to use Sun's JDK
1.4, but I get the following compilation errors regardless of the JDK I
compile with:

        "D:\Programs\DevStudio\vc\bin\cl.exe"  /c /W3 /nologo /YX /D_X86_=1
-I"D:\Programs\DevStudio\vc\include" -ID:\Tcl\include
-ID:\Programs\Tcl8.0.5\generic -ID:\Public\ExpectReplace\tcljava\win
-ID:\Public\ExpectReplace\tcljava\src\native -ID:\Programs\jdk1.4\include
-ID:\Programs\jdk1.4\include\win32  -DWIN32 -D_WIN32 -D_MT -D_DLL
/FoD:\Public\ExpectReplace\tcljava\win\
D:\Public\ExpectReplace\tcljava\src\native\javaCmd.c
javaCmd.c
D:\Public\ExpectReplace\tcljava\src\native\javaCmd.c(80) : error C2282:
'Tcl_ThreadDataKey' is followed by 'dataKey' (missing ','?)
D:\Public\ExpectReplace\tcljava\src\native\javaCmd.c(291) : warning C4013:
'Tcl_GetThreadData' undefined; assuming extern returning int
D:\Public\ExpectReplace\tcljava\src\native\javaCmd.c(291) : error C2065:
'dataKey' : undeclared identifier
D:\Public\ExpectReplace\tcljava\src\native\javaCmd.c(568) : warning C4013:
'Tcl_CreateThreadExitHandler' undefined; assuming extern returning int
D:\Public\ExpectReplace\tcljava\src\native\javaCmd.c(1335) : warning C4013:
'Tcl_UniCharToUtfDString' undefined; assuming extern returning int
NMAKE : fatal error U1077: '"D:\Programs\DevStudio\vc\bin\cl.exe"' : return
code '0x2'
Stop.

I'm using MS Visual C++ 5.0.

I've looked around for Tcl_ThreadDataKey and can't find it in .h files for
tcljava nor Tcl.

Any ideas?  Thanks very much.

--
Rob Donle             rd...@un...
SQA Tools Engr                  phone 978-589-0782
Unisphere Networks, Inc.              Westford, MA

Re: [tcljava-dev] Building latest jacl from CVS

[Neil M. <NM...@uk...>]

Well, I'm getting a _bit_ further with compiling Jacl from CVS. I managed
to get autoconf to build, but now running autoconf in the tcljava directory
results in the error:

configure.in:17: error: possibly undefined macro: AC_MSG_LOG
configure.in:132: error: possibly undefined macro: AC_MSG_ERROR

I feel like I'm getting somewhere at least. Anyone know anything about
these macros, and where they might be defined?

The version of autoconf is:
$ autoconf -V
autoconf (GNU Autoconf) 2.52c
Written by David J. MacKenzie.

Which is a much bigger version jump (from 2.13) than I was expecting. Have
I gone too far?

Is it just me, or does the ./configure; make; make install system rarely
work without quite a lot of tweaking?

___________________________________________________
Neil Madden/UK/Contr/IBM         nm...@uk...
Internal: 248724             External: 01962 818724
MP 183, Hursley               Manager: Beth Roberts


                                                                                                                   
                    "Neil Madden"                                                                                  
                    <NMADDEN@uk.ib       To:     tcl...@li...                                 
                    m.com>               cc:                                                                       
                                         Subject:     [tcljava-dev] Building latest jacl from CVS                  
                    20/08/2001                                                                                     
                    11:27                                                                                          
                    Please respond                                                                                 
                    to tcljava-dev                                                                                 
                                                                                                                   
                                                                                                                   



I'm having quite a bit of trouble building jacl from CVS. I'm trying to
build under cygwin, but the configure script refused to work, because it
wants autoconf to be run, and I didn't have version 2.14 (which it asks
for). I got the latest CVS autoconf (as the latest release seems to be
2.13), but that steadfastly refuses to build, either. Trying to compile
jacl manually using javac results in a whole heap of errors. Anyone have a
build, or can provide me with details of how to compile this properly.

Also, I have put up a version of jacl (1.2.6) with sockets support, at
http://tallniel.port5.com/cgi-bin/index.cgi/JaclSockets.html
You can get a jar file (containing jacl, tcljava, and the new sockets class
files and source) at http://tallniel.port5.com/jacl-sockets.jar

The new files needed for sockets are:

SocketCmd.java   - actually implemented.
SocketChannel.java - client side, extends Channel
ServerSocketChannel.java - server side, extends Channel
SocketConnectionEvent.java - event added to event queue when a client
connects to a server socket, extends TclEvent.

It seems to work ok for me, albeit somewhat limited (see my previous post).
One other question - someone had written some comments in the
SocketCmd.java file about setting up server sockets. I didn't fully
understand what was being said. I think the gist of it was to somehow get
the interpreter to inform us when it was being deleted so that socket
events wouldn't try and execute callbacks in an invalid interpreter. I
didn't know how to do this, but socket events deal with the interpreter
being an invalid reference anyway.

Any comments, code improvements (I'm sure there are many), gratefully
received.

Neil.
___________________________________________________
Neil Madden/UK/Contr/IBM         nm...@uk...
Internal: 248724             External: 01962 818724
MP 183, Hursley               Manager: Beth Roberts


_______________________________________________
tcljava-dev mailing list
tcl...@li...
http://lists.sourceforge.net/lists/listinfo/tcljava-dev

[tcljava-dev] Building latest jacl from CVS

[Neil M. <NM...@uk...>]

I'm having quite a bit of trouble building jacl from CVS. I'm trying to
build under cygwin, but the configure script refused to work, because it
wants autoconf to be run, and I didn't have version 2.14 (which it asks
for). I got the latest CVS autoconf (as the latest release seems to be
2.13), but that steadfastly refuses to build, either. Trying to compile
jacl manually using javac results in a whole heap of errors. Anyone have a
build, or can provide me with details of how to compile this properly.

Also, I have put up a version of jacl (1.2.6) with sockets support, at
http://tallniel.port5.com/cgi-bin/index.cgi/JaclSockets.html
You can get a jar file (containing jacl, tcljava, and the new sockets class
files and source) at http://tallniel.port5.com/jacl-sockets.jar

The new files needed for sockets are:

SocketCmd.java   - actually implemented.
SocketChannel.java - client side, extends Channel
ServerSocketChannel.java - server side, extends Channel
SocketConnectionEvent.java - event added to event queue when a client
connects to a server socket, extends TclEvent.

It seems to work ok for me, albeit somewhat limited (see my previous post).
One other question - someone had written some comments in the
SocketCmd.java file about setting up server sockets. I didn't fully
understand what was being said. I think the gist of it was to somehow get
the interpreter to inform us when it was being deleted so that socket
events wouldn't try and execute callbacks in an invalid interpreter. I
didn't know how to do this, but socket events deal with the interpreter
being an invalid reference anyway.

Any comments, code improvements (I'm sure there are many), gratefully
received.

Neil.
___________________________________________________
Neil Madden/UK/Contr/IBM         nm...@uk...
Internal: 248724             External: 01962 818724
MP 183, Hursley               Manager: Beth Roberts

[tcljava-dev] Sockets in Jacl...

[Neil M. <NM...@uk...>]

OK - I have hacked away at the weekend, and have come up with an
implementation of sockets in Jacl. Both client and server sockets work
(although I haven't run the socket tests on them yet). The error
messages aren't what Tcl gives yet, and there are some limitations:
* There is no fileevent command, so you can't handle more than one
connection at a time on a server socket (at least, I couldn't figure out
how).
* The -async flag to client sockets is not implemented.
* fconfigure doesn't do anything in current CVS jacl (apart from parse
its arguments). I haven't updated it to add the socket-specific options.
* Jacl seems to behave wrongly in terms of events. In the shell,
TCL.ALL_EVENTS flag is passed when doing Notifier.doOneEvent(), which
causes me to process socket connection events, even though these
shouldn't be processed unless an event loop has been entered (with
[vwait]). This is different behaviour to tclsh.

Anyway, I'm gonna clean up the code, and then create a patch for anyone
who wants a try. And if someone who has developer access to the TclJava
project wants to add this, they're more than welcome (might need a bit
of polishing first, though).
PS - I've only tested so far on 1.2.6, so some of these issues may have
gone away in CVS latest.

"D. J. Hagberg" wrote:
>
> In article <9jpgqa$6jk$1...@ne...>, "Ilia says...
> >Hello developers of Jacl!
> >Is there any alpha version of Jacl that implements
> >socket command?
>
> Not that I know of.  It would certainly be a *nice* feature
> to add to the lang, if someone has the time to do so.
>
>                         -=- D. J.

___________________________________________________
Neil Madden/UK/Contr/IBM         nm...@uk...
Internal: 248724             External: 01962 818724
MP 183, Hursley               Manager: Beth Roberts

Re: [tcljava-dev] Redirecting standard channels

[Neil M. <NM...@uk...>]

OK, just tracked down a simliar item in the archives about stdin etc being
hardwired to System.in. Is there any chance of this being changed?

___________________________________________________
Neil Madden/UK/Contr/IBM         nm...@uk...
Internal: 248724             External: 01962 818724
MP 183, Hursley               Manager: Beth Roberts


                                                                                                                   
                    "Neil Madden"                                                                                  
                    <NMADDEN@uk.ib       To:     tcl...@li...                                 
                    m.com>               cc:                                                                       
                                         Subject:     [tcljava-dev] Redirecting standard channels                  
                    31/07/2001                                                                                     
                    10:33                                                                                          
                    Please respond                                                                                 
                    to tcljava-dev                                                                                 
                                                                                                                   
                                                                                                                   



Hi all,

Is there any way to redirect the standard channels in Jacl, other than by
redirecting the System.out etc for the entire process?

Also, has anybody started work on adding socket support to Jacl? I would be
willing to at least have a look, and see how much work would be required. I
don't know my way around the code very well at the moment, but I'd be
willing to have a go.

___________________________________________________
Neil Madden/UK/Contr/IBM                   nm...@uk...
Internal: 248724                                            External: 01962
818724
MP 183, Hursley                                         Manager: Beth
Roberts


_______________________________________________
tcljava-dev mailing list
tcl...@li...
http://lists.sourceforge.net/lists/listinfo/tcljava-dev