tcljava-dev — discuss implementation and post patches here

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

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

OK, let me take a look at the patch manager...

I had made a couple other changes to 1.2.6 and Tcl 8.3.2(?) if you're
interested. The major change was to add an abortExecution() method from the
Java TclBlend Interp all the way through the JNI layer into the Tcl
interpreter's bytecode engine itself. This allows stopping the bytecode
engine "in it's tracks" and therefor abort an executing Tcl script.

Unfortunetly, that little trick causes 1.3.0 to assert() in the same place I
mentioned in previous email....

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] Latest 1.3.0 build and INterp.evalFile()

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

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


Yes, I can run multiple interps fine, but stopping/destroying them does not
seem to be working.

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

I'll try. Right now, my 'test case' is sitting in about 130K lines of code
;)

Basically what I'm doing is this:

	- Create a thread "N" to run "notifier.doOneEvent()" in a while( _run ){}
loop 	(i.e. if _run == false, the notifier thread will exit.)

	- From another thread "E", feed the notifier an event to eval() a String
full of Tcl.

	- When E completes (that is, the interp.eval() completes) it:

		- sets _run to false to let N exit.
		- feeds N an empty string to eval() so doOneEvent() will emerge.
		- join()'s N (waits for N to exit)

	- E then does an interp.destroy() and I get the assert.

Am I shutting down the interp/notifier correctly?

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

And take the fun away from you? ;)


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


I meant the Java thread(s) running the TclBlend Interp and it's Notifier.
See above for a (hopefully lucid) description of what I mean.


>
> Mo DeJong
> Red Hat Inc
>

john

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

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

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

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

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

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

-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Mo DeJong
Sent: Friday, March 23, 2001 1:11 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,
>
> OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
> changes we made to the 1.2.6 code and then integrated it into our
> application.
>
> While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we
discovered
> that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
> it boiled down to a native method that (I suspect) called Tcl_EvalFile().
>
> Is there a reason this was removed from 1.3.0?

Humm, I just looked at the Tcl Blend Interp.java file from 1.2.6
and the evalFile() method is defined as:

public void
evalFile(
    String s)                   // The name of file to evaluate.
throws
    TclException
{
    throw new TclRuntimeError("Not implemented yet.");
}

It is the same in 1.3.

Mo DeJong
Red Hat Inc

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

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

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

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

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

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

On Wed, 21 Mar 2001, W. John Guineau wrote:

> Hi Mo,
> 
> OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
> changes we made to the 1.2.6 code and then integrated it into our
> application.
> 
> While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we discovered
> that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
> it boiled down to a native method that (I suspect) called Tcl_EvalFile().
> 
> Is there a reason this was removed from 1.3.0?

Humm, I just looked at the Tcl Blend Interp.java file from 1.2.6
and the evalFile() method is defined as:

public void
evalFile(
    String s)                   // The name of file to evaluate.
throws 
    TclException
{
    throw new TclRuntimeError("Not implemented yet.");
}

It is the same in 1.3.

Mo DeJong
Red Hat Inc

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

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

Hi Mo,

You mentioned previously on this (or another) list that there were some
problems remaining in 1.3.0 to do with termination?

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

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

john


> -----Original Message-----
> From: tcl...@li...
> [mailto:tcl...@li...]On Behalf Of W. John
> Guineau
> Sent: Wednesday, March 21, 2001 10:45 AM
> To: tcl...@li...
> Subject: [tcljava-dev] Latest 1.3.0 build and INterp.evalFile()
>
>
> Hi Mo,
>
> OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
> changes we made to the 1.2.6 code and then integrated it into our
> application.
>
> While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we
> discovered
> that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
> it boiled down to a native method that (I suspect) called Tcl_EvalFile().
>
> Is there a reason this was removed from 1.3.0?
>
> thanks for all the help!
>
> john
>
>
>
> On Thu, 15 Mar 2001, W. John Guineau wrote:
>
> > Hi Mo,
> >
> > I'm starting to search around SourceForge.net. I found the TclBlend
> project,
> > and want to grab a copy to try.
> >
> > I'm trying to figure out how to access the CVS repository on
> SourceForge.
> It
> > seems I need something called pserver? I need access ('get'
> only is fine)
> > from a Windows PC...
> >
> > john
>
> In the future could you post to the user or dev mailing
> lists? That way folks could see your questions and
> the answer.
>
> To get the CVS code, you need a CVS client. Nothing
> else is required. You just set the CVSROOT env
> var and run "cvs co tcljava". I have not used
> Windows clients, I suggest you download and
> install Cygwin (www.cywin.com), it has a cmd
> line CVS client to works just fine.
>
> Mo
>
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> http://lists.sourceforge.net/lists/listinfo/tcljava-dev

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

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

Hi Mo,

OK, I installed cygwin, pulled the 1.3.0 source over, merged in the couple
changes we made to the 1.2.6 code and then integrated it into our
application.

While testing to make sure 1.3.0 works "as well as" :) 1.2.6, we discovered
that Interp.evalFile( String fileName ) is no longer implemented. In 1.2.6
it boiled down to a native method that (I suspect) called Tcl_EvalFile().

Is there a reason this was removed from 1.3.0?

thanks for all the help!

john



On Thu, 15 Mar 2001, W. John Guineau wrote:

> Hi Mo,
>
> I'm starting to search around SourceForge.net. I found the TclBlend
project,
> and want to grab a copy to try.
>
> I'm trying to figure out how to access the CVS repository on SourceForge.
It
> seems I need something called pserver? I need access ('get' only is fine)
> from a Windows PC...
>
> john

In the future could you post to the user or dev mailing
lists? That way folks could see your questions and
the answer.

To get the CVS code, you need a CVS client. Nothing
else is required. You just set the CVSROOT env
var and run "cvs co tcljava". I have not used
Windows clients, I suggest you download and
install Cygwin (www.cywin.com), it has a cmd
line CVS client to works just fine.

Mo

Re: [tcljava-dev] Re: [tcljava-user] incr Tcl support

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

On Thu, 15 Mar 2001, Christian Krone wrote:

> Hello,
> 
> Mo DeJong wrote:
> 
> > > Has anyone ported [incr Tcl] to Java / Jacl?
> > No. I looked into it, it would not be all that hard.
> 
> Hey, this sounds interesting.
> I just looked into the sources, too, and there are
> only 11 C files. And there are also test files!

It is easier than that. There a 2 backward compatibility
layers in the C code that are not really needed. If you
just focus on Itcl 3.X, it will be a lot easier. Just
ignore the 1.X and 2.X layers.
 
> Since I recently started to write some [Incr Tcl]
> code (and I really love it!), I could imagine to
> spend some weekend hours in porting the C stuff to Java.

Cool.

> But how will the new classes be loaded into Jacl?
> Does the package require stuff really works?

It works for loading packages off the filesystem.
What does not work is loading packages out of
a .jar file. It would not be all that tricky,
it just needs someone to do it.

> > There is one bit of the Tcl namespace
> > code that would need to be implemented to
> > support Itcl (external resolvers).
> 
> Do you mean, the current namespace implementation
> isn't complete? Do you mind to implement this
> missing stuff if the [Incr Jacl] classes need them?

The "external resolvers" thing in an internal namespace
API that is only used by Itcl. It would be trivial
to add it to NamespaceCmd.java.

Mo DeJong
Red Hat Inc

[tcljava-dev] Re: [tcljava-user] incr Tcl support

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

Hello,

Mo DeJong wrote:

> > Has anyone ported [incr Tcl] to Java / Jacl?
> No. I looked into it, it would not be all that hard.

Hey, this sounds interesting.
I just looked into the sources, too, and there are
only 11 C files. And there are also test files!

Since I recently started to write some [Incr Tcl]
code (and I really love it!), I could imagine to
spend some weekend hours in porting the C stuff to Java.

I think the best point to start with is the ensemble
command. I seems to be mostly unrelated to the
other commands and a comment in Itcl_Init says
that it is a prerequisite for the other stuff...

But how will the new classes be loaded into Jacl?
Does the package require stuff really works?

> There is one bit of the Tcl namespace
> code that would need to be implemented to
> support Itcl (external resolvers).

Do you mean, the current namespace implementation
isn't complete? Do you mind to implement this
missing stuff if the [Incr Jacl] classes need them?

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

Re: [tcljava-dev] Formatting Jacl Java code

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

On Wed, 28 Feb 2001, Johnson, Bruce wrote:

> Is there a standard set of options with indent, or some other program, for
> formatting Jacl's Java code?
> 
> Bruce

One should use the Tcl style guide, I think there is even a
Emacs mode for it. (4 spaces instead of a tab).

The one diff to note is that you should NEVER NEVER use
/* ... */ for comments in Java code. Use // at all times.

Mo DeJong
Red Hat Inc

Re: [tcljava-dev] New port problems

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

On Wed, 28 Feb 2001, Pat Villani wrote:

> I just finished porting tcljava to Tru64 v5.1 with jdk 1.2.2.  Wasn't
> easy, but got it to build.  Now I'm running into an error when I try to
> invoke jtclsh.  I get an error from dlopen saying 'symbol
> "JNI_GetCreatedJavaVMs" unresolved.'
> 
> I found one in my java area.  I added it to the jtclsh ld preload, but
> it doesn't seem to work.  Any ideas of what .so this should be in and
> how to correctly get it to load?
> 
> Pat

First off, are you using 1.2.6 or the CVS version? You really
should be using the CVS version for new ports.

The JNI_GetCreatedJavaVMs thing means the JNI lib is not
getting resolved by the runtime linker. If Tru64 works
like the Soalris or Linux, then there should be a
way to view the shared libs that a given shared lib
depends on.

Can you run something like:

% ldd libtclblend.so

What does that print? It should include a patch
to your JNI libs in there somewhere. Also, double
check that the LD_LIBRARY_PATH is set correctly,
if the system does not know where to find the
JNI shared libs at runtime, that can cause this
error.

Mo DeJong
Red Hat Inc

[tcljava-dev] New port problems

[Pat V. <Pat...@co...>]

I just finished porting tcljava to Tru64 v5.1 with jdk 1.2.2.  Wasn't
easy, but got it to build.  Now I'm running into an error when I try to
invoke jtclsh.  I get an error from dlopen saying 'symbol
"JNI_GetCreatedJavaVMs" unresolved.'

I found one in my java area.  I added it to the jtclsh ld preload, but
it doesn't seem to work.  Any ideas of what .so this should be in and
how to correctly get it to load?

Pat

-- 
+--------------------------------+------------------------------------+
| Pat Villani                    | Email:      Pat...@co... |
| Compaq Computer Corporation    |                                    |
| UNIX Software Division         |                                    |
+--------------------------------+------------------------------------+
| "Eat dessert first.  You may end up gagging on the asparagus." --   |
| Dean Becca                                                          |
+---------------------------------------------------------------------+

[tcljava-dev] Formatting Jacl Java code

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

Is there a standard set of options with indent, or some other program, for
formatting Jacl's Java code?

Bruce

[tcljava-dev] A patch for exec and errorCode

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

This patch is adapted from one sent in earlier.

Here is the Tcl behavior we want to match:

% catch {exec false} err
1
% set err
child process exited abnormally
% set errorCode
CHILDSTATUS 25301 1

Here is what the patched Jacl does:

% catch {exec false} err
1
% set err
child process exited abnormally
% set errorCode
CHILDSTATUS ?PID? 1

We don't have any way to find the
childs PID so I just put the
string ?PID? in there.


Here are a pair of test cases that
pass in Tcl and the patched Jacl.

test exec-4.1 { setting of errorCode when exit value != 0 } {
    set abnormal {child process exited abnormally}

    if {![catch {exec false} err]} {
        set result "exception not raised"
    } elseif {$err != $abnormal} {
        set result "expected $abnormal got $err"
    } elseif {[lindex $errorCode 0] != "CHILDSTATUS" ||
        [lindex $errorCode 2] != "1"} {
        set result "expected {CHILDSTATUS ?PID? 1} got $errorCode"
    } else {
        set result ok
    }
} ok

test exec-4.2 { no error when exit value == 0 } {
    list [catch {exec true} err] $err
} {0 {}}


And here is the patch:

Index: src/jacl/tcl/lang/ExecCmd.java
===================================================================
RCS file: /cvsroot/tcljava/tcljava/src/jacl/tcl/lang/ExecCmd.java,v
retrieving revision 1.5
diff -u -r1.5 ExecCmd.java
--- src/jacl/tcl/lang/ExecCmd.java	1999/05/17 03:50:37	1.5
+++ src/jacl/tcl/lang/ExecCmd.java	2001/02/28 08:59:32
@@ -151,6 +149,24 @@
 	    sbuf.setLength(length - 1);
 	}
 
+	// Tcl supports lots of child status conditions.
+	// Unfortunately, we can only find the child's
+	// exit status using the Java API
+        
+	if (exit != 0) {
+	    TclObject childstatus = TclList.newInstance();
+	    TclList.append(interp, childstatus,
+	        TclString.newInstance("CHILDSTATUS"));
+
+            // We don't know how to find the child's pid
+	    TclList.append(interp, childstatus,
+	        TclString.newInstance("?PID?"));
+
+	    TclList.append(interp, childstatus,
+	        TclInteger.newInstance(exit));
+
+            interp.setErrorCode( childstatus );
+	}
 
 	//when the subprocess writes to its stderr stream or returns
 	//a non zero result we generate an error


Does anyone see any problems with this change?

Mo DeJong
Red Hat Inc

[tcljava-dev] Jacl IO status

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

Almost done!!

Listed below are the current results from running the Tcl 8.3.2 io.test
script with Jacl.   

io.test:	Total	435	Passed	303	Skipped	72	Failed	60
Number of tests skipped for each constraint:
	1	emptyTest
	1	macOnly
	1	nonPortable
	2	pcOnly
	58	stdio
	7	unixOnly
	2	unixOrPc

I'm not sure what the tests that are being skipped (especially stdio) are.
I haven't given any thought to them at all.  Of the 60 failures, 56 of them
are because one or more of the socket, fcopy, fileevent and testchannelevent
commands are not yet implemented.  The four other tests which fail are
listed below.

==== io-3.4 WriteChars: loop over stage buffer FAILED
==== io-3.5 WriteChars: saved != 0 FAILED
==== io-3.7 WriteChars: (bufPtr->nextAdded > bufPtr->length) FAILED
==== io-11.1 ReadBytes: want to read a lot FAILED

  Tests 3.4,3.5, and 3.7 fail not because of the error they are designed to
test for, but rather something to do with jis0208 encoding.  I haven't had a
chance to figure out what the problem is.

Test 11.1 appears to give the correct result, but fails anyway:

==== io-11.1 ReadBytes: want to read a lot FAILED
==== Contents of test case:

    # ((unsigned) toRead > (unsigned) srcLen)

    set f [open "test1" w]
    puts -nonewline $f abcdefghijkl
    close $f
    set f [open "test1"]
    fconfigure $f -encoding binary
    # here
    set x [read $f 1000]
    close $f
    set x
 
---- Result was:
abcdefghijkl
---- Result should have been:
abcdefghijkl
==== io-11.1 FAILED


I need to do some housekeeping with the code (renaming some variables,
getting rid of some debugging junk, etc.) and then I'll post it so Mo can
bless it (or not).

Bruce

RE: [tcljava-dev] Fconfigure status

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

My Login is "duckj2"

cheers,

Bruce


-----Original Message-----
From: Mo DeJong [mailto:md...@cy...]
Sent: Thursday, February 15, 2001 10:04 PM
To: tcl...@li...
Subject: RE: [tcljava-dev] Fconfigure status


On Thu, 15 Feb 2001, Johnson, Bruce wrote:

> Yes, I have a login.
> Bruce

Ok, so what is it? You need to tell me your user
name so that I can add it to the "developers list".
(that gives you CVS write access).

Mo DeJong
Red Hat Inc

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

RE: [tcljava-dev] Fconfigure status

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

On Thu, 15 Feb 2001, Johnson, Bruce wrote:

> Yes, I have a login.
> Bruce

Ok, so what is it? You need to tell me your user
name so that I can add it to the "developers list".
(that gives you CVS write access).

Mo DeJong
Red Hat Inc

RE: [tcljava-dev] Fconfigure status

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

Yes, I have a login.
Bruce

-----Original Message-----
From: Mo DeJong [mailto:md...@cy...]
Sent: Thursday, February 15, 2001 8:42 PM
To: tcl...@li...
Subject: RE: [tcljava-dev] Fconfigure status


On Thu, 15 Feb 2001, Johnson, Bruce wrote:

> I only suggested checking in the changes now because in your last message
> you suggested doing so, saying that ".. it's better than nothing".

I was talking about having some test cases that failed.
Patches need to be as clean as possible,
otherwise I will not understand the changes.

>  I'm happy to clean things up before posting it.
>
> Bruce

Great, do you have a SF login yet? You will need on to be
able to get write access to the tcljava CVS. You will
want to set that up sooner rather than later
because there are always "setup" problems.

later
Mo

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

RE: [tcljava-dev] Fconfigure status

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

On Thu, 15 Feb 2001, Johnson, Bruce wrote:

> I only suggested checking in the changes now because in your last message
> you suggested doing so, saying that ".. it's better than nothing".

I was talking about having some test cases that failed.
Patches need to be as clean as possible,
otherwise I will not understand the changes.

>  I'm happy to clean things up before posting it.
>
> Bruce

Great, do you have a SF login yet? You will need on to be
able to get write access to the tcljava CVS. You will
want to set that up sooner rather than later
because there are always "setup" problems.

later
Mo

RE: [tcljava-dev] Fconfigure status

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

I only suggested checking in the changes now because in your last message
you suggested doing so, saying that ".. it's better than nothing".  I'm
happy to clean things up before posting it.
Bruce

-----Original Message-----
From: Mo DeJong [mailto:md...@cy...]
Sent: Thursday, February 15, 2001 8:10 PM
To: tcl...@li...
Subject: RE: [tcljava-dev] Fconfigure status


On Thu, 15 Feb 2001, Johnson, Bruce wrote:


> As soon as I figure out how to check the changes in I'll do so.
> 
> Bruce Johnson

Woah, hold on there. You need to get patches approved
before checking them in. The best way to do that
is to break the changes up into small pieces that
can be easily understood. Post it to the list,
I will look it over and then give you the ok
to check that one patch in. Then, rinse and repeat.

I have been slacking off on Jacl lately cause
I have been working on the Jikes 1.13 release,
but after the first of the month I will have
more time to plan with Jacl.

Mo DeJong
Red Hat Inc


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

RE: [tcljava-dev] Fconfigure status

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

On Thu, 15 Feb 2001, Johnson, Bruce wrote:

> I'm just about ready to post the preliminary version.  I've got it to where
> it will read an unmodified io.test script all the way through without
> crashing.
> 
> Results at present
> 
> Total  435 Passed 202  Skipped 72 Failed 161

That is very cool. Soon Jacl will be able to run most
of the Tcl 8.3 suite unmodified (that will be a great
day).

> Most of the failures are in tests for commands like fileevent and socket
> which I haven't implemented yet.

Don't worry about those. I will most likely look into
fileevent is nobody beats me to it.

> As soon as I figure out how to check the changes in I'll do so.
> 
> Bruce Johnson

Woah, hold on there. You need to get patches approved
before checking them in. The best way to do that
is to break the changes up into small pieces that
can be easily understood. Post it to the list,
I will look it over and then give you the ok
to check that one patch in. Then, rinse and repeat.

I have been slacking off on Jacl lately cause
I have been working on the Jikes 1.13 release,
but after the first of the month I will have
more time to plan with Jacl.

Mo DeJong
Red Hat Inc

RE: [tcljava-dev] Fconfigure status

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

I'm just about ready to post the preliminary version.  I've got it to where
it will read an unmodified io.test script all the way through without
crashing.

Results at present

Total  435 Passed 202  Skipped 72 Failed 161

Most of the failures are in tests for commands like fileevent and socket
which I haven't implemented yet.

As soon as I figure out how to check the changes in I'll do so.

Bruce Johnson

mc...@ho...



-----Original Message-----
From: Mo DeJong [mailto:md...@cy...]
Sent: Tuesday, February 13, 2001 4:18 PM
To: tcl...@li...
Subject: Re: [tcljava-dev] Fconfigure status


On Tue, 13 Feb 2001, Johnson, Bruce wrote:

> I've continued working on fconfigure and the related read/write routines
in
> Jacl.  At this point I can pass 96 of the first 119 tests in the Tcl 8.3.2
> io.test script.

Wow, that sounds great.

>  Starting at test 14.1 I need the "testchannel" command
> working, which I haven't yet had a chance to implement.  In fact some of
the
> failures in the first 119 tests are because some of these also require the
> "testchannel" command.

Yeah, those test commands are a pain.

> There are some problems with encoding with some of
> the failed tests (my modified code supports Unicode encoding but I haven't
> checked it out much).  Others have to do with the "tell" command reporting
> where the actual file pointer is, rather than where the last character was
> read from (the difference being do to buffering).  The problem here is
that
> there is no simple way (that I can find) to tell how many bytes get
> converted to how many unicode characters).  The list below shows what
tests
> are currently failing.
> 
> cheers,
>
> Bruce

Do you want to check in what you have now or wait until
it is 100% done? I would go for the "check it in now"
option if I were you. It may not be perfect, but it
is better than the nothing that we have now :)

You may want to get signed up as a sourceforge
developer so that you can check in code. Of
course, you can always post patches if
that would be easier for you. You are working
off the 1.3 tree, right? I just made a bunch
of test related changes that you should be
testing with.

Mo DeJong
Red Hat Inc

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

Re: [tcljava-dev] Fconfigure status

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

On Tue, 13 Feb 2001, Johnson, Bruce wrote:

> I've continued working on fconfigure and the related read/write routines in
> Jacl.  At this point I can pass 96 of the first 119 tests in the Tcl 8.3.2
> io.test script.

Wow, that sounds great.

>  Starting at test 14.1 I need the "testchannel" command
> working, which I haven't yet had a chance to implement.  In fact some of the
> failures in the first 119 tests are because some of these also require the
> "testchannel" command.

Yeah, those test commands are a pain.

> There are some problems with encoding with some of
> the failed tests (my modified code supports Unicode encoding but I haven't
> checked it out much).  Others have to do with the "tell" command reporting
> where the actual file pointer is, rather than where the last character was
> read from (the difference being do to buffering).  The problem here is that
> there is no simple way (that I can find) to tell how many bytes get
> converted to how many unicode characters).  The list below shows what tests
> are currently failing.
> 
> cheers,
>
> Bruce

Do you want to check in what you have now or wait until
it is 100% done? I would go for the "check it in now"
option if I were you. It may not be perfect, but it
is better than the nothing that we have now :)

You may want to get signed up as a sourceforge
developer so that you can check in code. Of
course, you can always post patches if
that would be easier for you. You are working
off the 1.3 tree, right? I just made a bunch
of test related changes that you should be
testing with.

Mo DeJong
Red Hat Inc

[tcljava-dev] Fconfigure status

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

I've continued working on fconfigure and the related read/write routines in
Jacl.  At this point I can pass 96 of the first 119 tests in the Tcl 8.3.2
io.test script.  Starting at test 14.1 I need the "testchannel" command
working, which I haven't yet had a chance to implement.  In fact some of the
failures in the first 119 tests are because some of these also require the
"testchannel" command.  There are some problems with encoding with some of
the failed tests (my modified code supports Unicode encoding but I haven't
checked it out much).  Others have to do with the "tell" command reporting
where the actual file pointer is, rather than where the last character was
read from (the difference being do to buffering).  The problem here is that
there is no simple way (that I can find) to tell how many bytes get
converted to how many unicode characters).  The list below shows what tests
are currently failing.

cheers,


Bruce



==== io-3.4 WriteChars: loop over stage buffer FAILED
==== io-3.5 WriteChars: saved != 0 FAILED
==== io-3.7 WriteChars: (bufPtr->nextAdded > bufPtr->length) FAILED
==== io-3.8 WriteChars: reset sawLF after each buffer FAILED
==== io-5.5 CheckFlush: none FAILED
==== io-6.3 Tcl_GetsObj: how many have we used? FAILED
==== io-6.30 Tcl_GetsObj: crlf mode: buffer exhausted FAILED
==== io-6.32 Tcl_GetsObj: crlf mode: buffer exhausted, more data FAILED
==== io-6.34 Tcl_GetsObj: crlf mode: buffer exhausted, not followed by \n
FAILED
==== io-6.47 Tcl_GetsObj: auto mode: \r at end of buffer, peek for \n FAILED
==== io-6.48 Tcl_GetsObj: auto mode: \r at end of buffer, no more avail
FAILED
==== io-6.49 Tcl_GetsObj: auto mode: \r followed by \n FAILED
==== io-6.50 Tcl_GetsObj: auto mode: \r not followed by \n FAILED
==== io-6.51 Tcl_GetsObj: auto mode: \n FAILED
==== io-6.52 Tcl_GetsObj: saw EOF character FAILED
==== io-6.55 Tcl_GetsObj: overconverted FAILED
==== io-7.1 FilterInputBytes: split up character at end of buffer FAILED
==== io-7.2 FilterInputBytes: split up character in middle of buffer FAILED
==== io-7.3 FilterInputBytes: split up character at EOF FAILED
==== io-8.1 PeekAhead: only go to device if no more cached data FAILED
==== io-11.1 ReadBytes: want to read a lot FAILED
==== io-11.4 ReadBytes: EOF char found FAILED
==== io-13.7 TranslateInputEOL: auto mode: naked \r FAILED