tcljava-dev — discuss implementation and post patches here

Re: [tcljava-dev] Jacl and JDBC

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

Hello,

> Before I start working from scratch on a JDBC interface in Jacl, has anyone
> done any work on something like this already? I couldn't find anything...

I once did.

But then I noticed that TclJava gives you everything at hand,
what you need to use JDBC in Tcl. No need for an extra interface.
You can access all and everything of JDBC almost as easy as from
inside Java. I hope the following lines will be a proof of this.

    package require java
    java::import -package java.sql DriverManager
    java::call Class forName "de.sag.jdbc.adabasd.ADriver"
    set logon [java::call DriverManager getConnection \
                    "jdbc:adabasd://$servernode/$serverdb" \
                    $account $password]
    set stmt [$logon createStatement]
    set res  [$stmt executeQuery "select date datum, user benutzer from dual"]
    $res next
    set out1 [$res {getString int} 1]
    set out2 [$res {getString int} 2]


Greetings, Krischan
-- 
Christian Krone

[tcljava-dev] Jacl and JDBC

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

Hi,

Before I start working from scratch on a JDBC interface in Jacl, has anyone 
done any work on something like this already? I couldn't find anything...

Cheers,
Bas.

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

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

Mo DeJong wrote:
> 
> On Tue, 29 Jan 2002 13:27:59 +0000
> Neil Madden <ne...@cs...> wrote:
> 
> > Hi all,
> >
> > OK - my exams are over, and I have some time to look again at my socket
> > code in Jacl. It needs some work. After the messages a while ago about
> > common functionality in the Channel class, is now a good time for me to
> > review the socket code and try and finish it off? i.e. - is the Channel
> > class in a finished state? Also, what is the model for integrating with
> > fconfigure, fileevent etc? Has work begun on fileevent?
> 
> Well, the socket code is a bit different now. I have rewritten much of
> it as part of the Channel rewrite. I don't think there is any reason for
> you to hold off on touching up the Socket classes.

Excellent. I'll start that now then.

> The fileevent stuff
> is going to have to wait until later since it will have to be part of
> the Channel rewrite (which is not yet done). If you are looking for
> something to do, there are always regression tests. Many current
> fail since the test suite was moved up the Tcl 8.3 and Jacl needs to
> be updated to match these test cases.

OK - I'll have a look. Any particular areas to focus on?

> 
> > PS - has anyone used my socket code? If so, could you send me feedback
> > on whether it works as expected, etc?
> 
> I tested it out for some simple things and it seems to work well. I also added
> some more error checks to act more like Tcl and pass more io tests.
> 
> cheers
> Mo
> 
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev

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

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

On Tue, 29 Jan 2002 13:27:59 +0000
Neil Madden <ne...@cs...> wrote:

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

Well, the socket code is a bit different now. I have rewritten much of
it as part of the Channel rewrite. I don't think there is any reason for
you to hold off on touching up the Socket classes. The fileevent stuff
is going to have to wait until later since it will have to be part of
the Channel rewrite (which is not yet done). If you are looking for
something to do, there are always regression tests. Many current
fail since the test suite was moved up the Tcl 8.3 and Jacl needs to
be updated to match these test cases.

> PS - has anyone used my socket code? If so, could you send me feedback
> on whether it works as expected, etc?

I tested it out for some simple things and it seems to work well. I also added
some more error checks to act more like Tcl and pass more io tests.

cheers
Mo

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

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

Hi all,

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

Cheers,

Neil.

PS - has anyone used my socket code? If so, could you send me feedback
on whether it works as expected, etc?

Re: [tcljava-dev] missing exec functionality

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

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

> >> P.S.
> >> I just checked in the first part of your reflection based exec patch.
> >>
> > Was the patch file ok? First time I ever did it.
> 
> Just saw your SourceForge comment. Do you really mean the background
> patch or the theads-based code? In the future, I'll try to break up my
> changes into smaller chunks ;)

I think it makes sense to keep the bg and thread reading code together.
The reflection API call and the thread code were the two that I thought
did not mix. The reason this matters is because it really helps 1 year
down the road when you are trying to look at the history of a given
command. If patches for different things were all mixed together, it
would be really hard to track down exactly how the code got from one
point to another.

cheers
Mo

Re: [tcljava-dev] missing exec functionality

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

Shawn Boyce wrote:

>
>
> Mo DeJong wrote:
>
>> On Tue, 08 Jan 2002 11:24:05 -0500
>> Shawn Boyce <sh...@qc...> wrote:
>>
>>> The current exec command does not support the file redirections
>>> such as <, >, <<, >>, etc. I added support for '&' already. I'll
>>> work on adding some of these next.
>>>
>>
>> That would be great. This same functionality is needed in the open 
>> (pipe)
>> command as well. This functionality is a bit tricky because it depends
>>
> I was just realizing the open command had pipe also.
>
>>
>> on the IO subsystem which is currently in flux. Just be aware that
>> you may need to tweak you code a number of time before you are
>> done.
>>
>> P.S.
>> I just checked in the first part of your reflection based exec patch.
>>
> Was the patch file ok? First time I ever did it.

Just saw your SourceForge comment. Do you really mean the background
patch or the theads-based code? In the future, I'll try to break up my
changes into smaller chunks ;)

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

-- 
-Shawn

Re: [tcljava-dev] missing exec functionality

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

Mo DeJong wrote:

>On Tue, 08 Jan 2002 11:24:05 -0500
>Shawn Boyce <sh...@qc...> wrote:
>
>>The current exec command does not support the file redirections
>>such as <, >, <<, >>, etc. I added support for '&' already. I'll
>>work on adding some of these next.
>>
>
>That would be great. This same functionality is needed in the open (pipe)
>command as well. This functionality is a bit tricky because it depends
>
I was just realizing the open command had pipe also.

>
>on the IO subsystem which is currently in flux. Just be aware that
>you may need to tweak you code a number of time before you are
>done.
>
>P.S.
>I just checked in the first part of your reflection based exec patch.
>
Was the patch file ok? First time I ever did it.

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

-- 
-Shawn

Re: [tcljava-dev] How to run the tests

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

On Tue, 15 Jan 2002 09:00:34 -0500
Shawn Boyce <sh...@qc...> wrote:

> I see the tests directory but the README file seems to be from the
> Tcl distribution. How do you actually run the tests?

You are right, that README file was not very clear. I updated it
to make it seem more Tcl/Java oriented. Take a look and see if
that takes care of your question.

cheers
Mo

Re: [tcljava-dev] missing exec functionality

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

On Tue, 08 Jan 2002 11:24:05 -0500
Shawn Boyce <sh...@qc...> wrote:

> The current exec command does not support the file redirections
> such as <, >, <<, >>, etc. I added support for '&' already. I'll
> work on adding some of these next.

That would be great. This same functionality is needed in the open (pipe)
command as well. This functionality is a bit tricky because it depends
on the IO subsystem which is currently in flux. Just be aware that
you may need to tweak you code a number of time before you are
done.

P.S.
I just checked in the first part of your reflection based exec patch.

cheers
Mo

[tcljava-dev] How to run the tests

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

I see the tests directory but the README file seems to be from the
Tcl distribution. How do you actually run the tests?

-- 
-Shawn

Re: [tcljava-dev] PATCH: exec command patch posted

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

Patch is located at:
http://sourceforge.net/tracker/?group_id=13005&atid=313005

Shawn Boyce wrote:

> I have submitted a patch to sourceforge for the exec command.
> Details:
>
> The exec command has been modified to take advantage
> of JDK 1.3's new java.lang.Runtime.exec methods
> which have the directory as the argument.
>
> To support backward compatibility when using
> JDK 1.1/1.2, the code uses Reflection to see if
> the new exec method is available.
>
> Summary of changes:
> 1) For JDK1.3+, Eliminate Windows/UNIX hacks to use the shell to 
> change to the current directory before doing
> the exec.
> 2) Support background "&"
> 3) Use threads to read the stdout/stderr output of the
> exec'd process.
>

-- 
-Shawn

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

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

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

This was not possible to implement in JDK1.1. In JDK 1.2,
the java.io.File.listRoots() method can be used. The
patch code uses Reflection to see if the method is available.
As before with JDK1.1, it will return an error.

Patch URL:
http://sourceforge.net/tracker/index.php?func=detail&aid=503836&group_id=13005&atid=313005


-- 
-Shawn



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

[tcljava-dev] missing exec functionality

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

The current exec command does not support the file redirections
such as <, >, <<, >>, etc. I added support for '&' already. I'll
work on adding some of these next.

Here's the full set of stuff that should be supported for exec:
 Arguments:
 *   -keepnewline    Do not discard trailing newline from the result 
(must be first argument)
 *   |               Pipes stdout from one process to another
 *   |&              Pipes both stdout & stderr output
 *   <   fileName    Takes input from named file
 *   <@  fileId      Takes input from the I/O channel identified by fileId
 *   <<  value       Takes input from the given value
 *   >   fileName    Overwrites fileName with stdout
 *   2>  fileName    Overwrites fileName with stderr output
 *   >&  fileName    Overwrites fileName with both stdout & stderr output
 *   >>  fileName    Appends stdout to the named file
 *   2>> fileName    Appends stderr to the named file
 *   >>& fileName    Appends both stdout & stderr to the named file
 *   >@  fileId      Directs stdout to the I/O channel identified by fileId
 *   2>& fileId      Directs stderr to the I/O channel identified by fileId
 *   >&@ fileId      Directs both stdout & stderr to the I/O channel 
identified by fileId
 *   &               Indicates pipeline should be run in background 
(last argument)
 

-- 
-Shawn

[tcljava-dev] PATCH: exec command patch posted

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

I have submitted a patch to sourceforge for the exec command.
Details:

The exec command has been modified to take advantage
of JDK 1.3's new java.lang.Runtime.exec methods
which have the directory as the argument.

To support backward compatibility when using
JDK 1.1/1.2, the code uses Reflection to see if
the new exec method is available.

Summary of changes:
1) For JDK1.3+, Eliminate Windows/UNIX hacks to use the shell to change 
to the current directory before doing
the exec.
2) Support background "&"
3) Use threads to read the stdout/stderr output of the
exec'd process.

-- 
-Shawn

Re: [tcljava-dev] exec change

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

On Tue, 08 Jan 2002 10:16:03 -0500
Shawn Boyce <sh...@qc...> wrote:

> Sorry I'm new to this. How do I add the ChangeLog entry? Include it with 
> my patch?

Yeah. Take a look at the existing ChangeLog for examples. You might end up
with something like so:

2002-01-08  Shawn Boyce <sh...@qc...>

        * src/jacl/tcl/lang/ExecCmd.java (FuncName): Did something
	or other.

Include a desc for each file you changed and what exactly you did. A ChangeLog
is the only way to really go back and figure out what happened to the code so
a patch really should include one.

cheers
Mo

Re: [tcljava-dev] exec change

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

Sorry I'm new to this. How do I add the ChangeLog entry? Include it with 
my patch?

Mo DeJong wrote:

>On Mon, 07 Jan 2002 23:05:53 -0500
>Shawn Boyce <sh...@qc...> wrote:
>
>>I have the exec changes. How do I submit them?
>>
>
>For quick little changes you can just post them to the list. If the patch is a bit larger (which I expect this one is) you could add a new patch to the sourceforge patch queue. Either way, post a note to the list nothing that you just added a patch, make sure there is a ChangeLog entry, and make sure the patch is in diff -u format.
>
>cheers
>Mo
>
>_______________________________________________
>tcljava-dev mailing list
>tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
>

-- 
-Shawn

Re: [tcljava-dev] exec change

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

On Mon, 07 Jan 2002 23:05:53 -0500
Shawn Boyce <sh...@qc...> wrote:

> I have the exec changes. How do I submit them?

For quick little changes you can just post them to the list. If the patch is a bit larger (which I expect this one is) you could add a new patch to the sourceforge patch queue. Either way, post a note to the list nothing that you just added a patch, make sure there is a ChangeLog entry, and make sure the patch is in diff -u format.

cheers
Mo

Re: [tcljava-dev] exec change

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

I have the exec changes. How do I submit them?

Shawn Boyce wrote:

>
>
> Mo DeJong wrote:
>
>> There are not a lot of features left to implement, but the
>> ones that are left can be rather tricky. Perhaps a good
>> place to get started with the code would be in the
>> exec command. A new version of the exec() API was
>>
> Fine.
>
>>
>> added in JDK 1.3:
>>
>> http://java.sun.com/j2se/1.3/docs/api/java/lang/Runtime.html#exec(java.lang.String[], 
>> java.lang.String[], java.io.File)
>>
>> The current exec code in src/jacl/tcl/lang/ExecCmd.java does this really
>> scary/nasty hack that involves writing out tmp files and then execing
>> sh on them. It would be better if we could just make use of this new
>>
> How does the new API help? Is it really necessary for the code to 
> specify the command shell
> (command.com or sh)? For Windows, if I use the new API, do I need the 
> temporary files anymore?
>
>>
>> exec API. Trick is, Jacl needs to continue to run on a JDK 1.1 system
>> so one would need to invoke the method at runtime through an
>> interface and compile the class only when compiling with a newer
>> version of Java. It might be easier to try to invoke this method via
>> the reflection interface. How does that sound?
>>
> I'll look into it. I'm not sure about the compilation part. If I use 
> reflection on java.lang.Runtime
> to see if the new method exists, then the code will compile fine with 
> pre-1.3.
>
>>
>>
>> If you want a bigger challenge after that, the automated test cases
>> could use a lot of work.
>>
>> Mo
>>
>> _______________________________________________
>> tcljava-dev mailing list
>> tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>>
>>
>

-- 
-Shawn

Re: [tcljava-dev] exec change

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

On Thu, 03 Jan 2002 10:45:02 -0500
Shawn Boyce <sh...@qc...> wrote:

> >The current exec code in src/jacl/tcl/lang/ExecCmd.java does this really
> >scary/nasty hack that involves writing out tmp files and then execing
> >sh on them. It would be better if we could just make use of this new
> >
> How does the new API help? Is it really necessary for the code to 
> specify the command shell
> (command.com or sh)? For Windows, if I use the new API, do I need the 
> temporary files anymore?

If you use the new API then the temp files will no longer be needed. The whole
point of the hack was to work around the fact that you could not set the CWD
when execing.

> >exec API. Trick is, Jacl needs to continue to run on a JDK 1.1 system
> >so one would need to invoke the method at runtime through an
> >interface and compile the class only when compiling with a newer
> >version of Java. It might be easier to try to invoke this method via
> >the reflection interface. How does that sound?
> >
> I'll look into it. I'm not sure about the compilation part. If I use 
> reflection on java.lang.Runtime
> to see if the new method exists, then the code will compile fine with 
> pre-1.3.

That seems like the most simple approach to implement.

cheers
Mo

[tcljava-dev] exec change

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

Mo DeJong wrote:

>There are not a lot of features left to implement, but the
>ones that are left can be rather tricky. Perhaps a good
>place to get started with the code would be in the
>exec command. A new version of the exec() API was
>
Fine.

>
>added in JDK 1.3:
>
>http://java.sun.com/j2se/1.3/docs/api/java/lang/Runtime.html#exec(java.lang.String[], java.lang.String[], java.io.File)
>
>The current exec code in src/jacl/tcl/lang/ExecCmd.java does this really
>scary/nasty hack that involves writing out tmp files and then execing
>sh on them. It would be better if we could just make use of this new
>
How does the new API help? Is it really necessary for the code to 
specify the command shell
(command.com or sh)? For Windows, if I use the new API, do I need the 
temporary files anymore?

>
>exec API. Trick is, Jacl needs to continue to run on a JDK 1.1 system
>so one would need to invoke the method at runtime through an
>interface and compile the class only when compiling with a newer
>version of Java. It might be easier to try to invoke this method via
>the reflection interface. How does that sound?
>
I'll look into it. I'm not sure about the compilation part. If I use 
reflection on java.lang.Runtime
to see if the new method exists, then the code will compile fine with 
pre-1.3.

>
>
>If you want a bigger challenge after that, the automated test cases
>could use a lot of work.
>
>Mo
>
>_______________________________________________
>tcljava-dev mailing list
>tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
>

-- 
-Shawn

Re: [tcljava-dev] Jacl help offer

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

On Wed, 02 Jan 2002 14:05:42 -0500
Shawn Boyce <sh...@qc...> wrote:

> I'm willing to help out with Jacl 1.3. What are areas that need addressing?
> I didn't see major items in the diffs.txt file that were not being 
> worked on
> (ie. channel I/O and socket).

Well, some IO areas are being worked on but others could still use some work.
For example, async IO and pipes still need to be implemented. These are
not currently being targeted in the Channel rewrite.

> My main interest is reducing the number of differences
> with Tcl so that I can just point users to the "standard"
> Tcl books and not have to explain what's missing.

There are not a lot of features left to implement, but the
ones that are left can be rather tricky. Perhaps a good
place to get started with the code would be in the
exec command. A new version of the exec() API was
added in JDK 1.3:

http://java.sun.com/j2se/1.3/docs/api/java/lang/Runtime.html#exec(java.lang.String[], java.lang.String[], java.io.File)

The current exec code in src/jacl/tcl/lang/ExecCmd.java does this really
scary/nasty hack that involves writing out tmp files and then execing
sh on them. It would be better if we could just make use of this new
exec API. Trick is, Jacl needs to continue to run on a JDK 1.1 system
so one would need to invoke the method at runtime through an
interface and compile the class only when compiling with a newer
version of Java. It might be easier to try to invoke this method via
the reflection interface. How does that sound?

If you want a bigger challenge after that, the automated test cases
could use a lot of work.

Mo

[tcljava-dev] Jacl help offer

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

I'm willing to help out with Jacl 1.3. What are areas that need addressing?
I didn't see major items in the diffs.txt file that were not being 
worked on
(ie. channel I/O and socket).

My main interest is reducing the number of differences
with Tcl so that I can just point users to the "standard"
Tcl books and not have to explain what's missing.

These commands are listed as being not implemented.
Any votes?

>	auto_mkindex, fblocked, fcopy, fconfigure, fileevent
>	load, pkg_mkIndex, pid, socket
>

-- 
-Shawn

Re: [tcljava-dev] Java 1.4 - breaks TclBlend?

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

On Mon, 10 Dec 2001 06:19:21 +0000
Neil Madden <ne...@cs...> wrote:

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

Every release of the JDK breaks Tcl Blend. It is just a fact of life. The JNI
interface and the libs one needs to link in are always in flux. There is
only one solution. Someone will need to sit down and make sure Tcl Blend
works with whatever strange changes Sun decided to throw in the current
release.

Mo

[tcljava-dev] TclObject final?

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

I'm trying some preliminary investigation as to whether Feather [1]
would be feasible in Java for use in TclJava. However, I have
immediately run up against a problem. TclObject is declared final,
meaning that I can't subclass it or override its methods in any way.
Feather needs to change the behaviour of some of these methods for
opaque objects to work. Is there any chance of TclObject being changed
to non-final? I realise that declaring it final prevents anyone from
messing around with the implementation, but surely if somebody (like me)
wants to, then that person must take full responsibility for the
consequences of their actions - i.e. making sure any changes they make
don't break the interpreter the new object is passed to.

Any comments? As Paul managed to mock up a proof of concept of Feather
for the C version, I imagine that this can be done in normal Tcl.

Neil.

[1] "Feather - Teaching Tcl Objects to Fly" - Paul Duffin. Paper
presented at the 7th USENIX Tcl/Tk conference. Available from the USENIX
website somewhere.