tcljava-dev — discuss implementation and post patches here

[tcljava-dev] Redirecting standard channels

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

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] Jacl Interp.dispose() made public again (FYI)

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

I just checked in a patch to make the Interp.dispose() method
public once again when compiling with Jacl. It was incorrectly
change to the default (package) protection earlier.

Mo DeJong
Red Hat Inc

Re: [tcljava-dev] Patch to fix bug SF 228954

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

On Wed, 9 May 2001, Christian Krone wrote:

> Hello,
> 
> attached you will find a patch, which will fix the
> bug SF 228954: "Nested list with \{ not parsed correctly".
> Also attached is a small testfile Braces.test, which
> demonstrates that the bug is really fixed now...
> 
> Greetings, Krischan

I made one little change and then added this patch, instead of
creating a new file I added this test to lindex.test.

test lindex-1.11 {Nested list with a backslashed brace} {
    lindex {{a \{}} 0
} {a \{}

I also added a patch to the Tcl patch queue for this
change, it is number 423617. I have closed tcljava patch
403267.

Thanks for working on a test case for this problem Krischan.

Mo DeJong
Red Hat Inc

Re: [tcljava-dev] Small improvements to Interp class and test

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

On Wed, 9 May 2001, Christian Krone wrote:

> Hello,
> 
> attached are two small improvements related to the Interp class.
> 
> The first replaces a call of Vector.remove() by Vector.removeElement().
> This way Interp.java can also be compiled with Java version 1.1, even
> with the new resolver related methods ;-)
> 
> The other patch added some forgotten braces to a test in jacl/Interp.test.
> These forgotten braces don't generate an error, since the additional
> argument cause the test command to omit this otherwise valid test.
> Instead it prints a very strange constraint at the end of the test run.
> 
> Greetings, Krischan

These two patches look great. I just did a commit for each of them.

Mo DeJong
Red Hat Inc

RE: [tcljava-dev] object instantiation failure

[Shazia B. <SB...@re...>]

blah blah blah

-----Original Message-----
From: Mo DeJong [mailto:md...@cy...]
Sent: 10 May 2001 06:30
To: tcl...@li...
Subject: Re: [tcljava-dev] object instantiation failure


On Thu, 10 May 2001 ver...@So... wrote:

> Hi,
> I am new to tclblend, I am stuck while try to load my java class through
> tcl code.
> Below is my example code, please help. Thanks

... (along with) ...

****************************************************************************
**
This email message (and attachments) may contain information that is 
confidential to Solution 6.  If you are not the intended recipient  you 
cannot use,  distribute or copy the message or attachments.  In such a 
case, please notify the sender by return email immediately and erase all 
copies of the message and attachments.  Opinions, conclusions and other 
information in this message and attachments that do not relate to the
official business of Solution 6 are neither given nor endorsed by it.
****************************************************************************
**


EULA announcements on emails are a bad joke. Posting things to
a public list puts the contents in the public domain. If
you would like to "protect" corporate trade secrets then
don't post them to a mailing list. Otherwise, post  
your question without the imaginative contract stipulations.

Mo DeJong
Red Hat Inc

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

Re: [tcljava-dev] object instantiation failure

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

Hello Vernon,

> I am new to tclblend, I am stuck while try to load my java class through
> tcl code.

Note, that questions like this better go to tcljava-user.

Without using your attachments :-), I would guess that you better should use
java::new instead of java::load, since you don't want to load an extension
but create a simple object. And you should specify an additional argument
(like "java::new MyClassName {Value Of Mandatory Argument}"), if your class
lacks of a parameterless constructor.

HTH, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH

Re: [tcljava-dev] object instantiation failure

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

On Thu, 10 May 2001 ver...@So... wrote:

> Hi,
> I am new to tclblend, I am stuck while try to load my java class through
> tcl code.
> Below is my example code, please help. Thanks

... (along with) ...

******************************************************************************
This email message (and attachments) may contain information that is 
confidential to Solution 6.  If you are not the intended recipient  you 
cannot use,  distribute or copy the message or attachments.  In such a 
case, please notify the sender by return email immediately and erase all 
copies of the message and attachments.  Opinions, conclusions and other 
information in this message and attachments that do not relate to the
official business of Solution 6 are neither given nor endorsed by it.
******************************************************************************


EULA announcements on emails are a bad joke. Posting things to
a public list puts the contents in the public domain. If
you would like to "protect" corporate trade secrets then
don't post them to a mailing list. Otherwise, post  
your question without the imaginative contract stipulations.

Mo DeJong
Red Hat Inc

[tcljava-dev] object instantiation failure

[<ver...@So...>]

Hi,
I am new to tclblend, I am stuck while try to load my java class through
tcl code.
Below is my example code, please help. Thanks


---- Simple.java  ----
public class Simple {
    public Simple(String s) {
    contents = s;
    }
    public String toString() {
    return contents;
    }
    public String contents = "default value";
}


----  tcl code ---

[catch {
     package require java
java::try {
     # Loads an extension stored in /export/home/vyeo/tcljava/Simple.class
     set load2 [java::load -classpath /export/home/vyeo/tcljava Simple]
} catch {TclException err} {
     SET message "Error in callCreateAccount: $err"
} catch {ProcessingErrorException pe} {
     SET message "Unexpected Processing Error: $pe"
} catch {Exception e} {
     SET message "************** UNEXPECTED ERROR *****************"
}

} ww ]
[IF {[SHOW ww]!=""} {
     ERROR: [SHOW ww]
}]z
<br>
message : [SHOW message]<br>

------------  end of tcl code -------------




------------- ERROR message --------------
0z
message : Error in callCreateAccount: load "Simple" failed: object
instantiation failure
connectionx :




******************************************************************************

visit http://www.solution6.com
visit http://www.eccountancy.com  -  everything for accountants


******************************************************************************
This email message (and attachments) may contain information that is confidential to Solution 6.  If you are not the intended recipient  you cannot use,  distribute or copy the message or attachments.  In such a case, please notify the sender by return email immediately and erase all copies of the message and attachments.  Opinions, conclusions and other information in this message and attachments that do not relate to the official business of Solution 6 are neither given nor endorsed by it.
******************************************************************************

[tcljava-dev] Small improvements to Interp class and test

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

Hello,

attached are two small improvements related to the Interp class.

The first replaces a call of Vector.remove() by Vector.removeElement().
This way Interp.java can also be compiled with Java version 1.1, even
with the new resolver related methods ;-)

The other patch added some forgotten braces to a test in jacl/Interp.test.
These forgotten braces don't generate an error, since the additional
argument cause the test command to omit this otherwise valid test.
Instead it prints a very strange constraint at the end of the test run.

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

[tcljava-dev] Patch to fix bug SF 228954

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

Hello,

attached you will find a patch, which will fix the
bug SF 228954: "Nested list with \{ not parsed correctly".
Also attached is a small testfile Braces.test, which
demonstrates that the bug is really fixed now...

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

Re: [tcljava-dev] [Incr Jacl] Almost done

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

On Tue, 24 Apr 2001, Christian Krone wrote:

> Hello,
> 
> > > I think the first step should be to integrate the needed
> > > changes of Jacl sources into the 1.3 CVS tree.
> 
> I have attached the diffs for the following java files:
> Interp.java, NamespaceCmd.java and Var.java.
> Also a patch for the startup script init.tcl is attached.
> And finally I modified Interp.test of the jacl test suite,
> where some forgotten braces used to mangle the test summary.

I just checked in the resolver related changes.

> > > Oh yes, and finally the class JaclLoadsItcl is new :-)
> > Humm, I am not sure about this "JaclLoadsItcl" thing.
> > Is it a just a hack like the way the java package
> > is provided by Jacl?
> 
> Yup, it was. But isn't needed anymore, since when the Java
> package is available, you can use an ordinary java::load
> to get the Itcl package (no bootstrapping problem as for
> the Java package).
> 
> I still have the feeling that it would be best to have
> this "package provide Itcl" line inside of a pkgIndex.tcl
> file somewhere, but I have no idea where I should put it...

Yeah, we need to come up with a way to let the Tcl class loader
know where the pkgIndex.tcl files for a given .jar file live.
Then we just look for a pkgIndex.tcl file in each .jar file
we find and source it.

> > Yeah, it would be better to fix the tcl.lang package to
> > export all the interfaces you need.
> 
> For the same goal we should tear off Namespace from the
> NamespaceCmd class. Most (or all) of the methods of
> NamespaceCmd, which should be public, are methods
> belonging to the Namespace class.

I don't have a problem with that approach. The catch is that
if we make Namespace a public class we need to also implement
that same API for Tcl Blend. In fact, we really need to do
that for these new Interp APIs so we can add then to the
docs. I am going to add a TODO for that right now just
do I don't forget.

> Would be tcljava/src/incrjacl then the correct place to use?

That sounds just fine.

Mo DeJong
Red Hat Inc

Re: [tcljava-dev] [Incr Jacl] Almost done

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

Hello,

> > I think the first step should be to integrate the needed
> > changes of Jacl sources into the 1.3 CVS tree.

I have attached the diffs for the following java files:
Interp.java, NamespaceCmd.java and Var.java.
Also a patch for the startup script init.tcl is attached.
And finally I modified Interp.test of the jacl test suite,
where some forgotten braces used to mangle the test summary.

> > [...] and there is a new source (Resolver.java)
> > containing the Resolver interface. Particularly the last
> > one still needs some polishing (copyright and comments
> > and maybe some docu), [...]

The new class is also attached, but for the docu you have
to wait until next time:-)

> > Oh yes, and finally the class JaclLoadsItcl is new :-)
> Humm, I am not sure about this "JaclLoadsItcl" thing.
> Is it a just a hack like the way the java package
> is provided by Jacl?

Yup, it was. But isn't needed anymore, since when the Java
package is available, you can use an ordinary java::load
to get the Itcl package (no bootstrapping problem as for
the Java package).

I still have the feeling that it would be best to have
this "package provide Itcl" line inside of a pkgIndex.tcl
file somewhere, but I have no idea where I should put it...

> Yeah, it would be better to fix the tcl.lang package to
> export all the interfaces you need.

For the same goal we should tear off Namespace from the
NamespaceCmd class. Most (or all) of the methods of
NamespaceCmd, which should be public, are methods
belonging to the Namespace class.

> > At least it would be great if I could use the SourgeForge
> > infrastructure of TclJava - I don't like the idea of creating
> > an own project and doing all the administration tasks. I would
> > like to have the [Incr Jacl] stuff belonging to TclJava.
> Well, I guess that would be ok. I can see your point about
> not wanting to admin another mailing list and CVS repo.

Would be tcljava/src/incrjacl then the correct place to use?
I noticed a directory tcljava/src/aolserver, which looks the same:
not needed by the core TclJava, but belonging to the peripherie...
And again: if one day [Incr Tcl] will belong to the Tcl Core,
we have the stuff already there.


-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

Re: [tcljava-dev] [Incr Jacl] Almost done

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

On Mon, 23 Apr 2001, Christian Krone wrote:

> Hello,
> 
> just to give you a quick update:
> 
> the porting of [Incr Tcl] (version 3.2) from C to Java
> is done. There are only a handful of tests of the itcl
> test suite still failing, and they fail due to missing
> Jacl features (e.g. the load command).

Wow! That sounds great.
 
> So how to continue?
> 
> I think the first step should be to integrate the needed
> changes of Jacl sources into the 1.3 CVS tree.
> IIRC the files Interp.java, NamespaceCmd and init.tcl
> were modified, and there is a new source (Resolver.java)
> containing the Resolver interface. Particularly the last
> one still needs some polishing (copyright and comments
> and maybe some docu), but I think tommorow I will be able
> to send the diffs to this list.
> Oh yes, and finally the class JaclLoadsItcl is new :-)

Humm, I am not sure about this "JaclLoadsItcl" thing.
Is it a just a hack like the way the java package
is provided by Jacl?

> The names of all [Incr Jacl] classes start with the Prefix
> Itcl (e.g. ItclObject) and the classes are located inside
> the tcl.lang package. My first idea with the tcl.incr package
> was dropped, since there are too many needed functions
> unaccesible from outside tcl.lang.
>
> As Mo already mentioned, it may be not so good an idea to
> add this new stuff into tcljava/src/jacl/tcl/lang.

Yeah, it would be better to fix the tcl.lang package to
export all the interfaces you need.
 
> Currently I have it in tcljava/src/incrjacl/tcl/lang.
> Due to the naming conventions with the starting Itcl there
> should be no naming problems with the normal Jacl sources.
> 
> I looked at Swank and I could try to write a configure as
> Bruce did, so that the [Incr Jacl] stuff could be distributed
> separately from Jacl. But I don't see the point in doing this.
> 
> At least it would be great if I could use the SourgeForge
> infrastructure of TclJava - I don't like the idea of creating
> an own project and doing all the administration tasks. I would
> like to have the [Incr Jacl] stuff belonging to TclJava.

Well, I guess that would be ok. I can see your point about
not wanting to admin another mailing list and CVS repo.

Mo

[tcljava-dev] [Incr Jacl] Almost done

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

Hello,

just to give you a quick update:

the porting of [Incr Tcl] (version 3.2) from C to Java
is done. There are only a handful of tests of the itcl
test suite still failing, and they fail due to missing
Jacl features (e.g. the load command).

So how to continue?

I think the first step should be to integrate the needed
changes of Jacl sources into the 1.3 CVS tree.
IIRC the files Interp.java, NamespaceCmd and init.tcl
were modified, and there is a new source (Resolver.java)
containing the Resolver interface. Particularly the last
one still needs some polishing (copyright and comments
and maybe some docu), but I think tommorow I will be able
to send the diffs to this list.
Oh yes, and finally the class JaclLoadsItcl is new :-)

The names of all [Incr Jacl] classes start with the Prefix
Itcl (e.g. ItclObject) and the classes are located inside
the tcl.lang package. My first idea with the tcl.incr package
was dropped, since there are too many needed functions
unaccesible from outside tcl.lang.

As Mo already mentioned, it may be not so good an idea to
add this new stuff into tcljava/src/jacl/tcl/lang.

Currently I have it in tcljava/src/incrjacl/tcl/lang.
Due to the naming conventions with the starting Itcl there
should be no naming problems with the normal Jacl sources.

I looked at Swank and I could try to write a configure as
Bruce did, so that the [Incr Jacl] stuff could be distributed
separately from Jacl. But I don't see the point in doing this.

At least it would be great if I could use the SourgeForge
infrastructure of TclJava - I don't like the idea of creating
an own project and doing all the administration tasks. I would
like to have the [Incr Jacl] stuff belonging to TclJava.

Okay, so I will prepare the patches for Jacl and come back tomorrow.
Stay tuned...

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

Re: [tcljava-dev] Channel mapping for stdin, stdout, etc.

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

Hello,

David L. Smith-Uchida wrote:

> Hmmm....Looking back through the mailing list archive there was a bug
> 221678 which asserts that the channels for standard in, out and err should
> have dual names stdin/file0 stdout/file1 stderr/file2.  It seems as though
> there's a problem with channels having dual names and error reporting.

Jup, that was exactly the problem: You have two names for the standard channels
(e.g. file0 and stdin for standard input), and Jacl always used the fileX name
in error messages, whereas Tcl uses exactly the name the user specified.
So the bug was simply that Jacl behaved differently from Tcl.

> Also, is there a requirement that stdin == file0, etc?  Is this an alias?

No such requirement is specified in any man page or test file of Tcl.
But as a long term user of Tcl (starting with version ~7.0) you are used to
get the answer "file3" when opening your first file interactivly, like this:
  # tclsh8.3
  % open /etc/passwd
  file3
And Jacl used to return file0...

Both effects (defects?) are unrelated to your problem with the hardwired
channel mapping of e.g. stdin to System.in.

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

[tcljava-dev] Channel mapping for stdin, stdout, etc.

[David L. Smith-U. <da...@ig...>]

Hmmm....Looking back through the mailing list archive there was a bug 
221678 which asserts that the channels for standard in, out and err should 
have dual names stdin/file0 stdout/file1 stderr/file2.  It seems as though 
there's a problem with channels having dual names and error reporting.

However, there's a deeper problem and that is that there is no way to have 
stdin, stdout and stderr attach to anything except System.in, System.out 
and System.err since the StdChannel implementation is hardwired into TclIO.

Since I want to imbed Tcl inside of my shell and control where the I/O goes 
(and I'd like to be able to have it go different places for each Tcl 
instance so simply setting System.in, etc. doesn't work for me) I'd like to 
undo the hardwiring inside of TclIO and let the channel assignment be 
overriden.

Also, is there a requirement that stdin == file0, etc?  Is this an alias?

Cheers,
Dave

David L. Smith-Uchida
Head Geek
iGeek, Inc.
Japan voice/fax: +81-3-5701-0955
US voice/fax: +1-877-384-7509
da...@ig...
http://www.igeekinc.com

Re: [tcljava-dev] TCL/Java and integration into a gui based shell

[David L. Smith-U. <da...@ig...>]

>
> > I'm currently working with jacl1.2.6 - is this the right code to be 
> working
> > with?
>
>You really should be using the 1.3 version in the CVS.
>
>...

Hmm...looks like lots of changes between 1.2.6 and 1.3.  I'll go through 
and re-integrate my code with the 1.3 stuff.


David L. Smith-Uchida
Head Geek
iGeek, Inc.
Japan voice/fax: +81-3-5701-0955
US voice/fax: +1-877-384-7509
da...@ig...
http://www.igeekinc.com

Re: [tcljava-dev] TCL/Java and integration into a gui based shell

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

On Fri, 20 Apr 2001, David L. Smith-Uchida wrote:

> The ideas are fairly half-baked at the moment, but some of the things I'm 
> working towards are:
> 
> Command history in a separate window

That should be easy, there is a histroy command that should make
that easy.

> Cross platform compatibility.  I want to be able to run the same shell on 
> Windows, Linux, Solaris, Mac OS, whatever and have a basic command set that 
> I can rely on.

Mac OS might be a little tricky. Mac OS X is going to work, but Mac OS
is a hard environment to develop in.

> I've run into some problems getting the Tcl/Java code integrated into a GUI 
> environment.  I've been able to hack together fixes but I don't have a deep 
> understanding of the Tcl/Java code yet so I'd like to discuss what I'm 
> seeing as deficiencies and see if others agree or if there are some points 
> I'm just missing.
> 
> I'm currently working with jacl1.2.6 - is this the right code to be working 
> with?

You really should be using the 1.3 version in the CVS.

...

> 2) TclEvents do not have a mechanism for polling or notification - there is 
> a sync() method which will block execution but no way to ask "is it done 
> yet" or to be notified when it is done (I think)

There is a notification system, you just subclass TclEvent. Perhaps
we just need better examples to explain this. Care to help create
some examples for the docs?

> 3) TclIO appears to be half finished.  One of the problems that I found was 
> that TclIO always returned a Channel that was attached to System.out for 
> stdout.  It also bypasses the interpreter's channel table when asked for 
> stdin/out/err which makes it impossible to substitute a different channel 
> for any of those three.  Also, the Channel interface and classes are not 
> public so once again you have to add things to the tcl.lang package to add 
> new types of Channels.

Yup, they are half based. There is some work going on to fully implement
Tcl channels. Perhaps you would be interested in helping with that.
Check that mailing list archives for more info.

Mo DeJong
Red Hat Inc

[tcljava-dev] TCL/Java and integration into a gui based shell

[David L. Smith-U. <da...@ig...>]

Hi all,

I'm starting on a project to create a hybrid GUI/command line shell and I'm 
currently planning to integrate TCL/Java as the command language.  The 
project will be released under an Open Source license.

The basic idea I'm working from is that the command line is the most 
efficient way of issuing commands to the computer but a graphical display 
is the most efficient way of displaying the results back to the user.  My 
goal is to create an interface where once you have your hands on the 
keyboard you don't need to shift to the mouse unless you are doing 
something where the mouse would give a significant benefit; also, once you 
are using the mouse you do not have to shift back to the keyboard until 
there's a real benefit.

The ideas are fairly half-baked at the moment, but some of the things I'm 
working towards are:

Command history in a separate window

Ability to index output with command history (select the command, and then 
have the output of that command displayed also)

XML output of commands with pipeline processing done via XML/XSL/Java/Tcl, 
output in XML could be piped through XSL to create HTML or into a Java 
bean.  (How many times have you written scripts that dissect the output of 
ps or ls?  Why don't we just tag the output properly?)

Cross platform compatibility.  I want to be able to run the same shell on 
Windows, Linux, Solaris, Mac OS, whatever and have a basic command set that 
I can rely on.

At the moment, I have a very rudimentary version of this hacked together 
and over the next month or so I hope to get some more features 
in.  Currently I'm trying to reconcile scripts/programs that ask for more 
input or use curses with my original (half-baked) enter command - execute - 
view results - enter next command model.

I've run into some problems getting the Tcl/Java code integrated into a GUI 
environment.  I've been able to hack together fixes but I don't have a deep 
understanding of the Tcl/Java code yet so I'd like to discuss what I'm 
seeing as deficiencies and see if others agree or if there are some points 
I'm just missing.

I'm currently working with jacl1.2.6 - is this the right code to be working 
with?

1) The structure of public/private classes and methods.  For example, 
ConsoleEvent is a private class to tcl.lang.  This forced me to either make 
it public or put my command executive into tcl.lang so that it could issue 
ConsoleEvents ala Shell.java.  Does anyone have an understanding of the 
public/non-public class structure and what classes/methods need to be 
protected from other code (like plug-ins) and which may have wound up 
non-public by accident?

2) TclEvents do not have a mechanism for polling or notification - there is 
a sync() method which will block execution but no way to ask "is it done 
yet" or to be notified when it is done (I think)

3) TclIO appears to be half finished.  One of the problems that I found was 
that TclIO always returned a Channel that was attached to System.out for 
stdout.  It also bypasses the interpreter's channel table when asked for 
stdin/out/err which makes it impossible to substitute a different channel 
for any of those three.  Also, the Channel interface and classes are not 
public so once again you have to add things to the tcl.lang package to add 
new types of Channels.

In my version, I've changed the way TclIO works with Channels.  Stdin, 
stdout and stderr are named channels in the interpreter's Channel table and 
can be retrieved by their name.

I've also added a ByteArrayOutputChannel class.

Comments and suggestions?

Thanks!
Dave

David L. Smith-Uchida
Head Geek
iGeek, Inc.
Japan voice/fax: +81-3-5701-0955
US voice/fax: +1-877-384-7509
da...@ig...
http://www.igeekinc.com

RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()

[W. J. G. <gu...@ea...>]

Mo,

Did the stack traces I sent make any sense? Am I shutting Tcl/Blend down
improperly or is this the shutdown bug you mentioned?

thanks!
john

> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Mo DeJong
> Sent: Monday, March 26, 2001 8:39 AM
> To: tcl...@li...
> Subject: RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> On Mon, 26 Mar 2001, W. John Guineau wrote:
>
> > Oops - yup. That was code I had added to the 1.2.6 version *before*
> > commiting it to our "cvs" (vss) and so missed it in the diffs ;)
> >
> > Would you like an implementation for the 1.3.0 code? ;)
> >
> > john
>
> Sure. Patches are always welcome. Add them via the SF patch
> manager interface.
>
> Mo
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcljava-dev

Re: [tcljava-dev] [Incr Jacl]: How to proceed?

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

On Tue, 27 Mar 2001, Christian Krone wrote:

> > I don't know if we should even put the incr Jacl code
> > in the same tree as Jacl. Why not have another tree
> > with its own ./configure and so on? That is what
> > Bruce did with Swank (Tk via Swing).
> 
> I think it is less effort to populate the existing tree
> instead of creating a new one. And when some day IncrTcl
> will be integrated into the Tcl language, we have the
> stuff already there :-)

Well, it is less effort for you. But what about the
next person that wants to extend Jacl? Are we going
to put every extension in the tcljava CVS module?
 
> Anyway, does the Swank sources belong to tcljava? Or do
> they have their own project? Or do they have their
> own tree below tcljava/src and you can give a
> command line option --enable-swank to configure?

Swank uses its own tree and ./configure script.
You pass a --with-tcljava=DIR option to the
swank configure script and it pulls info
like where javac lives out of tcljavaConfig.sh.

> > > But how would the new classes be loaded into the Jacl interpreter?
> > >From the users point of view, it should be as easy as
> > "package require IncrTcl".
> 
> You mean "package require Itcl", don't you?

Yup.
 
> > Your implementation would most likely extend
> > src/tcljava/tcl/lang/Extension.java.[...] The hard part
> > might be getting "package require ..." to work
> > when the ... package is in a .jar like incrtcl.jar.
> > I think the best way to implement that is to use
> > the manifest file to list what Tcl packages are
> > available in a given .jar file and the java class
> > name.
> 
> This looks like I should take a break on the Incr sources
> and should spend some time on the package command...
> I had some hopes that I can work around it, but they
> are gone now.

You can work around it as long as you don't put the
files into a .jar. As long as a pkgIndex.tcl for
your "Itcl" package can be found, it will get loaded
by a "package require Itcl". Just make sure that
dir appears on the auto_path Tcl variable. For a
nasty example of how I hacked "package require java"
support into Jacl, see src/jacl/tcl/lang/JaclLoadJava.java
(be warned, it is a bit ugly). Don't worry about the
finished product yet, the package in a .jar stuff is
just how to code is delivered. Getting code to deliver
in the first place is more important.

Mo

Re: [tcljava-dev] [Incr Jacl]: How to proceed?

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

Hello,

> > A nice package name could be "tcl.incr", so the sources would
> > be put into .../src/jacl/tcl/incr. The jar file containing
> > all the Incr classes should probably be called incr.jar.
> > And the loadOnDemand() inside Interp should be removed again.
> 
> I don't know if we should even put the incr Jacl code
> in the same tree as Jacl. Why not have another tree
> with its own ./configure and so on? That is what
> Bruce did with Swank (Tk via Swing).

I think it is less effort to populate the existing tree
instead of creating a new one. And when some day IncrTcl
will be integrated into the Tcl language, we have the
stuff already there :-)

Anyway, does the Swank sources belong to tcljava? Or do
they have their own project? Or do they have their
own tree below tcljava/src and you can give a
command line option --enable-swank to configure?

> > But how would the new classes be loaded into the Jacl interpreter?
> >From the users point of view, it should be as easy as
> "package require IncrTcl".

You mean "package require Itcl", don't you?

> Your implementation would most likely extend
> src/tcljava/tcl/lang/Extension.java.[...] The hard part
> might be getting "package require ..." to work
> when the ... package is in a .jar like incrtcl.jar.
> I think the best way to implement that is to use
> the manifest file to list what Tcl packages are
> available in a given .jar file and the java class
> name.

This looks like I should take a break on the Incr sources
and should spend some time on the package command...
I had some hopes that I can work around it, but they
are gone now.

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

Re: [tcljava-dev] [Incr Jacl]: How to proceed?

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

On Tue, 27 Mar 2001, Christian Krone wrote:

> Hello,
> 
> yesterday evening it finally happended: the ensemble.test
> of [IncrTcl] was processed by Jacl without any failure,
> and I had even added one test case...

Ohhh, cool.

> But before I will look for the next command to implement,
> I want to reorganize the layout of the sources. Since
> I don't know, what the best way would be, I seek for your
> help. Let me first explain my current solution, which is
> really a temporary hack.
> 
> I extend the Interp class, to load on demand the EnsembleCmd
> if "itcl::ensemble" is needed. This class is defined inside
> the tcl.lang package and the sources are put into
> .../src/jacl/tcl/lang. The compiled classes will thus go
> into jacl.jar.

Yuk. We need to be able to support extensions in Jacl.
 
> In other words: IncrTcl is no loadable package at all.
> I think, beside the name EnsembleCmd all of the above should
> be changed...
> 
> A nice package name could be "tcl.incr", so the sources would
> be put into .../src/jacl/tcl/incr. The jar file containing
> all the Incr classes should probably be called incr.jar. 
> And the loadOnDemand() inside Interp should be removed again.

I don't know if we should even put the incr Jacl code
in the same tree as Jacl. Why not have another tree
with its own ./configure and so on? That is what
Bruce did with Swank (Tk via Swing).

> But how would the new classes be loaded into the Jacl interpreter?
> Currently I have no idea:-(

From the users point of view, it should be as easy as
"package require IncrTcl". Your implementation would
most likely extend src/tcljava/tcl/lang/Extension.java.

I think most of the tricky stuff related to creating
your own ./configure is already done. The hard part
might be getting "package require ..." to work
when the ... package is in a .jar like incrtcl.jar.
I think the best way to implement that is to use
the manifest file to list what Tcl packages are
available in a given .jar file and the java class
name.

Mo

[tcljava-dev] [Incr Jacl]: How to proceed?

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

Hello,

yesterday evening it finally happended: the ensemble.test
of [IncrTcl] was processed by Jacl without any failure,
and I had even added one test case...

But before I will look for the next command to implement,
I want to reorganize the layout of the sources. Since
I don't know, what the best way would be, I seek for your
help. Let me first explain my current solution, which is
really a temporary hack.

I extend the Interp class, to load on demand the EnsembleCmd
if "itcl::ensemble" is needed. This class is defined inside
the tcl.lang package and the sources are put into
.../src/jacl/tcl/lang. The compiled classes will thus go
into jacl.jar.

In other words: IncrTcl is no loadable package at all.
I think, beside the name EnsembleCmd all of the above should
be changed...

A nice package name could be "tcl.incr", so the sources would
be put into .../src/jacl/tcl/incr. The jar file containing
all the Incr classes should probably be called incr.jar. 
And the loadOnDemand() inside Interp should be removed again.

But how would the new classes be loaded into the Jacl interpreter?
Currently I have no idea:-(

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()

[W. J. G. <gu...@ea...>]

Mo,

Here's the stack if it helps:

_assert(void * 0x0e808054, void * 0x0e808010, unsigned int 293) line 256
JavaGetEnv() line 293 + 29 bytes
FreeTclObject(Tcl_Obj * 0x000c68f8) line 185 + 5 bytes
DeleteArray(Interp * 0x000bd048, char * 0x000a6c28, Var * 0x000b2c28, int
321) line 4631 + 93 bytes
TclDeleteVars(Interp * 0x000bd048, Tcl_HashTable * 0x000cd0f8) line 4442 +
50 bytes
TclTeardownNamespace(Namespace * 0x000cd068) line 736 + 18 bytes
DeleteInterpProc(Tcl_Interp * 0x000bd048) line 963 + 12 bytes
Tcl_EventuallyFree(int * 0x000bd048, void (char *)* 0x0e826995
DeleteInterpProc(Tcl_Interp *)) line 313 + 7 bytes
Tcl_DeleteInterp(Tcl_Interp * 0x000bd048) line 901 + 14 bytes
Java_tcl_lang_Interp_doDispose(const JNINativeInterface_ * * 0x08a2d884,
_jobject * 0x0e7bfcf4, __int64 1044831918095061064) line 208 + 10 bytes
0082b871()
0082939a()
0082939a()
0082939a()
JVM! 504d4eae()
JVM! 5040e87a()
JVM! 50430987()
JVM! 5040e77f()
JVM! 5040e4fd()
JVM! 5041b998()
JVM! 50447ba3()
JVM! 50447b74()
MSVCRT! 7800a3c0()
KERNEL32! 77db2c18()






> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of Mo DeJong
> Sent: Friday, March 23, 2001 1:36 AM
> To: tcl...@li...
> Subject: RE: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> On Wed, 21 Mar 2001, W. John Guineau wrote:
>
> > Hi Mo,
> >
> > You mentioned previously on this (or another) list that there were some
> > problems remaining in 1.3.0 to do with termination?
>
> Yeah, I think our multi-threaded startup stuff is ok.
> It is the shutdown that seems to have problems.
>
> > Would that be the assert I'm seeing in the TclBlend.DLL at:
> >
> >  src/native/javaCmd.c:
> >
> > TCLBLEND_EXTERN JNIEnv *JavaGetEnv()
> > {
> >    ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
> >    assert(tsdPtr->initialized);
> >    return tsdPtr->currentEnv;
> > }
> >
> >
> > It seems to happen when calling Interp.destroy().
>
> Humm, that says to me that the JavaGetEnv() method is getting
> called after the thread has been cleaned up. Could you provide
> a nice little test case for this problem? If you really want
> to lend a hand, designing some test cases that will check
> the startup and shutdown cases would really help. They
> are tricky because they are not like any of the other tests.
> Startup and shutdown tests might need to be run as separate
> programs before running the normal "make check" rule.
>
> > Also - if I have a notifier thread sitting in
> notifier.doOneEvent(), what's
> > the recomended way to get it out? Right now, I just send it an
> empty string
> > to eval() and that causes the notifier.doOneEvent() while() loop to exit
> > (taking the thread with it).
>
> Do you mean you want to make another thread exit from one that
> you are in? I think you would to use the Thread package for
> that. I think you send a thread::exit command to your target
> thread using the thread::send command. My memory is a little
> fuzzy in this area so I could be way off.
>
> http://dev.scriptics.com/ftp/thread//thread21.html
>
> Mo DeJong
> Red Hat Inc
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcljava-dev