tcljava-dev — discuss implementation and post patches here

Re: [tcljava-dev] TclList finalize

[Dan W. <dcw...@ea...>]

> Are you loading Tcl Blend into a running JVM or
> loading Tcl Blend and a JVM into Tcl? I think
> it works for the second case, but I don't
> know if it has ever worked in the first.

I've been loading Tcl Blend and a JVM into Tcl..  I can see that the
notifier has been alerted, but the notifier never seems to run.  I'm going
to try and trace down where it's failing.

> We really need to test this sort of thing.
> There is also a problems with threads.
> I was thinking that we could #define in
> some code when debugging that would
> maintain a table listing the threads
> that were initialized and those that
> were cleaned up. We could then check
> this "cleanup table" to make sure
> things were getting taken down properly.

I haven't seen this problem where only some of the threads are not taken
down properly.  That sounds really strange.

-Dan

Re: [tcljava-dev] TclList finalize

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

On Tue, 19 Dec 2000, Daniel Wickstrom wrote:

> Anyway I uncommented the debug statement that you had in
> CObject.processEvent to see if it is ever called, and I never see the
> debug output.  Did you see this working before?
> 
> -Dan

Are you loading Tcl Blend into a running JVM or
loading Tcl Blend and a JVM into Tcl? I think
it works for the second case, but I don't
know if it has ever worked in the first.

We really need to test this sort of thing.
There is also a problems with threads.
I was thinking that we could #define in
some code when debugging that would
maintain a table listing the threads
that were initialized and those that
were cleaned up. We could then check
this "cleanup table" to make sure
things were getting taken down properly.

Mo DeJong
Red Hat Inc

Re: [tcljava-dev] TclList finalize

[Daniel W. <da...@rt...>]

>>>>> "Mo" == Mo DeJong <md...@cy...> writes:

    Mo> On Mon, 18 Dec 2000, Daniel Wickstrom wrote:
    >> Looking at the latest sources, I noticed that the TclList class
    >> doesn't have a finalize method declared.  Since TclList is a
    >> subclass of CObject, shouldn't it have a finalize method for
    >> sending the TclList object as an event to the notifier for
    >> later cleanup?
    >> 
    >> -Dan

    Mo> Since TclList extends CObject, calling finalize() for the
    Mo> TclList should invoke CObject.finalize().

Duh ok.

Anyway I uncommented the debug statement that you had in
CObject.processEvent to see if it is ever called, and I never see the
debug output.  Did you see this working before?

-Dan

Re: [tcljava-dev] TclList finalize

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

On Mon, 18 Dec 2000, Daniel Wickstrom wrote:

> Looking at the latest sources, I noticed that the TclList class
> doesn't have a finalize method declared.  Since TclList is a subclass
> of CObject, shouldn't it have a finalize method for sending the
> TclList object as an event to the notifier for later cleanup?
> 
> -Dan

Since TclList extends CObject, calling finalize() for
the TclList should invoke CObject.finalize().

Mo DeJong
Red Hat Inc

[tcljava-dev] TclList finalize

[Daniel W. <da...@rt...>]

Looking at the latest sources, I noticed that the TclList class
doesn't have a finalize method declared.  Since TclList is a subclass
of CObject, shouldn't it have a finalize method for sending the
TclList object as an event to the notifier for later cleanup?

-Dan

Re: [tcljava-dev] CVS web access ?

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

On Sat, 9 Dec 2000, Ulf Dittmer wrote:

> Hi-
> 
> I'm trying to get the latest dev version of TCLBlend, and have
> some difficulties using the CVS web access at sourceforge. I can see
> the directories fine, but any in dir that would supposedly contain files
> (.e.g. dist), an error occurs, and no files are displayed. Is that a known
> problem, and if so, is there an alternative way to retrieve the files (short
> of running CVS directly)?

It looks like the CVS web browsing thing is hosed. I would just
run CVS directly if I were you. It would be far easier that
hosing around with the web client.

SF also has a page about getting a CVS snapshot:

http://sourceforge.net/docman/display_doc.php?docid=764&group_id=1

cheers
Mo DeJong
Red Hat Inc

[tcljava-dev] CVS web access ?

[Ulf D. <di...@ca...>]

Hi-

I'm trying to get the latest dev version of TCLBlend, and have
some difficulties using the CVS web access at sourceforge. I can see
the directories fine, but any in dir that would supposedly contain files
(.e.g. dist), an error occurs, and no files are displayed. Is that a known
problem, and if so, is there an alternative way to retrieve the files (short
of running CVS directly)?

Thanks in advance,
Ulf

[tcljava-dev] Release Notice - nsjavablend

[Daniel W. <da...@rt...>]

This is a release announcement for an alpha release of nsjavablend-0.0.9.  
nsjavablend is a loadable c-modules for aolserver that merges nsjava
with tclblend.

This is an interim release for developement and testing. Mo DeJong,
the lead developer of the Tclblend project has given tenative approval
to adding aolserver support into the Tclblend distribution, so future
releases will probably be done as part of the Tclblend project hosted
at sourceforge.

The current release is available as nsjavablend-0.0.9.tar.gz at
http://nsjava.sourceforge.net.

With the inclusion of Tclblend this module now offers complete access
to the Java api for dynamic scripting of Java objects from within Tcl
scripts and Adp pages.  This module also retains the nsjava feature
which allows complete access to aolserver's Database api from within
user-defined java classes.

Features:

* Full access to aolserver database api from witin user-defined java classes.
* Create instances of Java objects from Tcl. 
* Invoke instance methods on a Java object from Tcl. 
* Invoke methods on array objects. 
* Invoke static Java methods from Tcl. 
* Get and Set Java Field values from Tcl. 
* Determine if a Tcl object is an instance of a Java Class. 
* Manipulate Java Bean properties from Tcl. 
* Introspect Java Objects from Tcl. 
* Load Tcl extensions defined in Java classes. 
* Throw and Catch Java exceptions from Tcl. 
* Import Java class names. 
* And more.

If anyone is interested in helping out with further development,
testing, or documentation of this module, please feel free to contact
me.


Dan Wickstrom - dcw...@ea...

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

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

On Tue, 14 Nov 2000, Christian Krone wrote:

> This applies to all channels which have more than one name.
> I believe this are just the standard channels.

...

> Nevertheless I think Jacl should behave the same as Tcl
> in this point (especially as it is so easy to achieve *and*
> as the incompatibility was introduced only recently as a
> side effect of the interp patch).
> 
> Greetings, Krischan

Ok, go ahead and check that patch in.

Mo DeJong
Red Hat Inc

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

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

Hello,

Mo DeJong wrote:
> > This way you would have the following:
> >   % read stdout
> >   channel "file1" wasn't opened for reading
> I don't get it, this already seems to work in Jacl.
> jacl from CVS % read stdout
> channel "stdout" wasn't opened for reading
[...]
> Does this only apply if you use channel name like "file1"?

This applies to all channels which have more than one name.
I believe this are just the standard channels.

Jacl from CVS doesn't have two names for the standard channels.
This is the incompatibiltity to Tcl which I complained about
in my bug report. Therefore the error messages in the Channel
class can give the (one and only) correct name.

My quoting was from a Jacl where the standard channels have
two names, but the error messages are still produced by the
Channel class. If the standard channels have more than one
name, you should have the user specified name available to
generate a nice error message; the Channel class don't have
this name available, thus the calling class should already
throw the error.

> Perhaps we need to move the ioCmd.test over into
> Jacl.

When we use all Tcl tests for Jacl (and I hope this moment
is not too far away in the future), this test will be run
by Jacl anyway :-)

> My point was, I would like to get some regression test
> for this stuff into Jacl. It seems like ioCmd.test
> is what we want.

I don't think that my patch is tested by ioCmd.test:
there are some channel names like file107 used, but only
to generate an error message about an unknown channel name. 

The fact that the first three channel numbers are reserved
for the standard channels really seems to be untested.

Nevertheless I think Jacl should behave the same as Tcl
in this point (especially as it is so easy to achieve *and*
as the incompatibility was introduced only recently as a
side effect of the interp patch).

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

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

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

On Wed, 8 Nov 2000, Christian Krone wrote:

> I you can give more than one distinct names for a channel,
> the methods in the subclasses of Channel have no idea which
> name they should print in the exception. This way you would
> have the following:
>   % read stdout
>   channel "file1" wasn't opened for reading

I don't get it, this already seems to work in Jacl.

tclsh8.4 % read stdout
channel "stdout" wasn't opened for reading

jacl from CVS % read stdout
channel "stdout" wasn't opened for reading

> Since I thought that an additional parameter "chanName" in
> the methods Channel.read() and Channel.write() class isn't
> a good idea, I did the same as Tcl does in tclIOCmd.c:
> Let the command implementations check the channel before they
> call the underlying channel operation, since they have the
> original channel name available.

Does this only apply if you use channel name like "file1"?

> > Surely these conditions have test cases in the
> > Tcl suite? If not, we really should
> > add them to Tcl first. That way
> > we can be sure Jacl and Tcl will
> > not diverge in the future.
> 
> I just did a grep through the Tcl test suite and there is no
> test which checks the name of a channel (as no good programmer
> should rely on this).

I was just looking around in ioCmd.test and it seems
like the conditions you mention are checked there.
Perhaps we need to move the ioCmd.test over into
Jacl.

> I still don't understand this point. Especially as the patch
> *removed* the overloaded StdChannel.getChanName() method.

My point was, I would like to get some regression test
for this stuff into Jacl. It seems like ioCmd.test
is what we want. It currently fails a bunch of
tests because fconfigure and -translation are
not implemented yet. How does that sound?

Mo

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

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

Good morning,

> Humm, well I am not sure it is all that critical
> but I guess I don't have a big problem with it.
I would also not say that this is critical; its just
an incompatibility to Tcl.
> I would feel a lot better about it if we could
> add some test cases to Tcl 8.4 and then to Jacl,
> so that we knew this previously untested feature
> was going to be tested in the future.

> I still don't get how this relates to the
> other bits of the patch that add new
> exceptions when the file was not opened
> for writing and so on.

I you can give more than one distinct names for a channel,
the methods in the subclasses of Channel have no idea which
name they should print in the exception. This way you would
have the following:
  % read stdout
  channel "file1" wasn't opened for reading

Since I thought that an additional parameter "chanName" in
the methods Channel.read() and Channel.write() class isn't
a good idea, I did the same as Tcl does in tclIOCmd.c:
Let the command implementations check the channel before they
call the underlying channel operation, since they have the
original channel name available.

> Surely these conditions have test cases in the
> Tcl suite? If not, we really should
> add them to Tcl first. That way
> we can be sure Jacl and Tcl will
> not diverge in the future.

I just did a grep through the Tcl test suite and there is no
test which checks the name of a channel (as no good programmer
should rely on this).

> > > It seem like your patch does away with the
> > > StdChannel.getChanName() method. Would
> > > you not want to call setChanName(String)
> > > perhaps in the StdChannel() constructor?
> > I think that this change will not implement
> > the feature that the standard channels can be
> > named by two different names (e.g. standard input
> > with stdin and file0)...
> No, but it would make it so that you would
> not need to overload the getChanName()
> method, right?

I still don't understand this point. Especially as the patch
*removed* the overloaded StdChannel.getChanName() method.

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

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

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

On Wed, 8 Nov 2000, Christian Krone wrote:

> Hello,
> 
> > About this patch, are there test cases from Tcl 8.3
> > that fail without this patch? I don't see any
> > failures in the tests Jacl runs, so I am
> > guessing that there must be some test failures in
> > the newer Tcl regression test suite. Perhaps
> > we need to add those failing tests before
> > doing a commit of this patch.
> 
> No, I don't know of any test from Tcl8.3 either.
> I detected this incompatibility to Tcl8.3, when
> I was working interactively with jaclsh, where
> something like the following happended:
>   % open /etc/passwd
>   file0
> Oops, normally this is file3!
> 
> Then I tested some stuff in tclsh8.3, where
> it seems to be asserted that file0 is an alias
> for stdin, file1 for stdout and file2 for stderr.
> This was the same in Jacl, *before* we add the
> method StdChannel.getChanName()!
> Due to the introduction of this method the
> standard channels no longer occupy the first three
> slots in the "filename table"...

Humm, well I am not sure it is all that critical
but I guess I don't have a big problem with it.
I would feel a lot better about it if we could
add some test cases to Tcl 8.4 and then to Jacl,
so that we knew this previously untested feature
was going to be tested in the future.

I still don't get how this relates to the
other bits of the patch that add new
exceptions when the file was not opened
for writing and so on. Surely these
conditions have test cases in the
Tcl suite? If not, we really should
add them to Tcl first. That way
we can be sure Jacl and Tcl will
not diverge in the future.

> > It seem like your patch does away with the
> > StdChannel.getChanName() method. Would
> > you not want to call setChanName(String)
> > perhaps in the StdChannel() constructor?
> 
> I think that this change will not implement
> the feature that the standard channels can be
> named by two different names (e.g. standard input
> with stdin and file0)...

No, but it would make it so that you would
not need to overload the getChanName()
method, right?
 
> Greetings, Krischan
> 
> P.S.: Your latest mail has a timestamp of 2:33.
> Are you working around the clock? Or do you have
> a computer next to your bed?

Even better, I have a laptop on the bed with
DSL no less (dang, we are spoiled). I did not
realize it was getting so late, time to sleep.

later
Mo

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

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

Hello,

> About this patch, are there test cases from Tcl 8.3
> that fail without this patch? I don't see any
> failures in the tests Jacl runs, so I am
> guessing that there must be some test failures in
> the newer Tcl regression test suite. Perhaps
> we need to add those failing tests before
> doing a commit of this patch.

No, I don't know of any test from Tcl8.3 either.
I detected this incompatibility to Tcl8.3, when
I was working interactively with jaclsh, where
something like the following happended:
  % open /etc/passwd
  file0
Oops, normally this is file3!

Then I tested some stuff in tclsh8.3, where
it seems to be asserted that file0 is an alias
for stdin, file1 for stdout and file2 for stderr.
This was the same in Jacl, *before* we add the
method StdChannel.getChanName()!
Due to the introduction of this method the
standard channels no longer occupy the first three
slots in the "filename table"...

> It seem like your patch does away with the
> StdChannel.getChanName() method. Would
> you not want to call setChanName(String)
> perhaps in the StdChannel() constructor?

I think that this change will not implement
the feature that the standard channels can be
named by two different names (e.g. standard input
with stdin and file0)...

Greetings, Krischan

P.S.: Your latest mail has a timestamp of 2:33.
Are you working around the clock? Or do you have
a computer next to your bed?
-- 
Christian Krone, SQL Datenbanksysteme GmbH
Mail mailto:chr...@so...

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

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

On Wed, 8 Nov 2000 tcl...@li... wrote:

> Hello,
> 
> Mo wrote:
> > What we will do is post the patches to the dev list one at
> > a time.
> Okay, I've done this with my last mail.

About this patch, are there test cases from Tcl 8.3
that fail without this patch? I don't see any
failures in the tests Jacl runs, so I am
guessing that there must be some test failures in
the newer Tcl regression test suite. Perhaps
we need to add those failing tests before
doing a commit of this patch.

It seem like your patch does away with the
StdChannel.getChanName() method. Would
you not want to call setChanName(String)
perhaps in the StdChannel() constructor?

I guess I am just not sure what problem(s)
your patch fixes.

Mo DeJong
Red Hat Inc

[tcljava-dev] How to write a ChangeLog entry (was: Patch for bug 121678)

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

On Wed, 8 Nov 2000 tcl...@li... wrote:

> Hello,
> 
> > Be sure to include a ChangeLog entry too :)
> And here are my questions: What is the best tool
> to work with ChangeLog (Emacs most probably)?
> Should the patch contain the ChangeLog diff, too?

Working with ChangeLog entries is really easy.
You can use emacs if you like, it kind of helps
as it does some formatting for you.

You don't need to send a diff of the ChangeLog
entry. Just paste it in at the top as regular
text.

Just start with the date:

2000-11-08

Then add 2 spaces and your name:

2000-11-08  Christian Krone

Then 2 more spaces and your email address:

2000-11-08  Christian Krone  <kri...@sq...>

Finally: skip a line and then indent with a TAB
followed by a * a space and the file name:

2000-11-08  Christian Krone  <kri...@sq...>

	* filexyz.c

At this point you need to decide if the changes you
made could have more to do with a given function
or if they are just sort of generic to the file.

If the changes are not really focused on a single
function, just add a : and the description of
the change. Like so:

2000-11-08  Christian Krone  <kri...@sq...>
  
        * filexyz.c: Fix some comments.

Now, if you changed some things that have to do
with a function or a set of functions, then
you would list those functions in parens. Like so:

2000-11-08  Christian Krone  <kri...@sq...>

        * filexyz.c (func1, func2): Change return
	values of func1 and func2, negative numbers
	should no longer be returned.

Also, if you have a whole bunch of changes that
are the same, you don't need to list them for
every single file. Just make a comment for
a set of files, like so:

2000-11-08  Christian Krone  <kri...@sq...>
  
        * file1:
	* file2:
	* file3: Update copyright text.


It is not hard, one just needs to get into the habit
of doing it. It really helps 6 months down the road
when you have forgotten what you did earlier. There
is no better way to track down when a bug was
introduced.

Mo DeJong
Red Hat Inc

[tcljava-dev] Test (please ignore)

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

just testing.

Mo

Re: [tcljava-dev] How to submit a code change (was: Patch for bug 121678)

[<tcl...@li...>]

Hello,

Mo wrote:
> What we will do is post the patches to the dev list one at
> a time.
Okay, I've done this with my last mail.

> When/If you get the ok for a patch, it can be
> checked into the CVS.
Okay, I will wait.

> Whatever you do, don't check a
> patch in without getting the ok first.
No, I will never ever do something like this...

> Also, lets make sure the
> patches only focus on one thing at a time. Don't
> send in a patch for 15 unrelated items at the same
> time.
Okay, I recognize that some of my last patches has
a lot of different items - this should not happen again...

> Be sure to include a ChangeLog entry too :)
And here are my questions: What is the best tool
to work with ChangeLog (Emacs most probably)?
Should the patch contain the ChangeLog diff, too?

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH

Re: [tcljava-dev] Patch for bug 121678

[<tcl...@li...>]

On Tue, 7 Nov 2000 tcl...@li... wrote:

> Hello,
> 
> as you may problably suspect, I already had the bug fixed,
> before I submitted it to SourceForge :-)
> 
> So what to do?
> Will Mo do anything to integrate the patch and close the bug?
> Will Mo assign the bug to me and I close it and check in the
> diffs myself?
> Anything between?

What we will do is post the patches to the dev list one at
a time. When/If you get the ok for a patch, it can be
checked into the CVS. Whatever you do, don't check a
patch in without getting the ok first. In practice,
it should not be hard to get the ok, I just want to
make sure everyone knows what is going on so that
folks get a chance to object if something is blatantly
wrong with a given patch. Also, lets make sure the
patches only focus on one thing at a time. Don't
send in a patch for 15 unrelated items at the same
time. Be sure to include a ChangeLog entry too :)

cheers
Mo DeJong
Red Hat Inc

[tcljava-dev] Patch for bug 121678

[<tcl...@li...>]

Hello,

as you may problably suspect, I already had the bug fixed,
before I submitted it to SourceForge :-)

So what to do?
Will Mo do anything to integrate the patch and close the bug?
Will Mo assign the bug to me and I close it and check in the
diffs myself?
Anything between?

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH

[tcljava-dev] Location of old mailing list archive.

[<tcl...@li...>]

Here is a quick note for any new users that
are looking for the old mailing list archive.

http://www.mail-archive.com/tc...@sc...

All new mail should go to either the tcljava-user
or tcljava-dev lists on sourceforge.

cheers
Mo DeJong
Red Hat Inc

[tcljava-dev] Just a test, please ignore...

[<tcl...@li...>]

the subject is telling all, isn't it?

[tcljava-dev] Test dev list

[<tcl...@li...>]

Test dev list.