tcljava-dev Mailing List for Tcl/Java (Page 20)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Please do not post in HTML!

Mo DeJong
Red Hat Inc



Hello there.

I am using jacl and trying to get my interpreter to read a script. However,
I keep on getting TCL.Error "couldn't read file". I have no idea why and am
not having much luck looking on the Net. Please help! I am coding in Java
using XEmacs. My code is as follows:

	try
        {    
	    this.interp.evalFile(this.filename);
	    this.result  = this.interp.getResult().toString();
	    if (this.result.length() > 0)
	    {
	        display.displayResult(result);
	        display.displayResult("Script completed ok.");
		return;
	    }
	}
	catch (TclException e)
	{
	    int error;
	    error = e.getCompletionCode();
	    if (error == TCL.ERROR)
	    {
		display.displayResult(interp.getResult().toString());
		display.displayResult("Evaluation of script returned
TCL_ERROR");
		return;
	    }
            else
	    {
		display.displayResult("command returned bad code: " +
error);
		return;
	    }	
	}

I think it may not be the code, but the shell I am using. Any ideas will be
warmly received!

Thank you
Shazia


I'm so overloaded at the moment that I can't commit to doing this.  But I
will do what I can, starting with EOL stuff.  The fileevent stuff may be
beyond what I can either understand or handle at the moment.

Bruce

-----Original Message-----
From: Mo DeJong [mailto:md...@cy...]
Sent: Friday, February 02, 2001 12:59 PM
To: tcl...@li...
Subject: Re: [tcljava-dev] Fconfigure


On Fri, 2 Feb 2001, Johnson, Bruce wrote:

> Hi All,
> 
> I just added the ability to read and write binary data (activating
> fconfigure's binary argument, adding a read and write binary (to & from
> TclByteArray objects)  to Channel, FileChannel and StdChannel).

Cool.

> Before I did any more work on this I wanted to make sure no one
> else is currently working on it ( I need to get this working
> quickly for my own use).  If not I may plug away at some of
> the other fconfigure modes.
> 
> Bruce

Nobody else is working on it. I would really like to get
Tcl file IO working before doing a 1.3 release of Jacl.
The basics are not that hard, but they would take
some time to implement properly. The reall tricky bit
is the fileevent API. It would need to be implemented
like the fileevent impl under Windows since Java
does not support async IO.

Do you want to take over as the "owner" of this
SF task id?

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=20698&gro
up_id=13005&group_project_id=4999

Mo DeJong
Red Hat Inc

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



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

    Mo> On Wed, 7 Feb 2001, Daniel Wickstrom wrote:
    >>  Mo,
    >> 
    >> So what did you decide on this patch?  I sent you a response to
    >> your questions, but I never heard anything back.
    >> 
    >> -Dan

    Mo> I remember we had talked about some changes to the patch that
    Mo> would make it more acceptable, did you want to implement
    Mo> those?  I suppose I could code them up but I am not going to
    Mo> have any free time until after the end of this month.


I must have misunderstood, as I don't remember agreeing on any changes
to the patch.  You asked some questions, and I responded but I didn't
think we agreed to anything.  

I there are going to be changes to the patch, I would rather do it
myself, so I can make sure that the aolserver side works.

-Dan



On Wed, 7 Feb 2001, Daniel Wickstrom wrote:

> 
> Mo,
> 
> So what did you decide on this patch?  I sent you a response to your
> questions, but I never heard anything back.
> 
> -Dan

I remember we had talked about some changes to the patch that
would make it more acceptable, did you want to implement those?
I suppose I could code them up but I am not going to have
any free time until after the end of this month.

Mo



Mo,

So what did you decide on this patch?  I sent you a response to your
questions, but I never heard anything back.

-Dan



On Mon, 5 Feb 2001 cs...@ma... wrote:

> 
> To Mo DeJung, ref. your comments on my test case, a modified "test
> filecmd-17.2 {cmdProc: mtime}":
> 
> I have to admit that I don't se any way to make a simple regression test
> case that proves my correction right. But there is no doubt that we got a
> problem.

Ok, you have convinced me. I checked your patch into the CVS
without a test case.

Mo DeJong
Red Hat Inc



On Tue, 6 Feb 2001, Gary Baranzini wrote:

> Hi,
> 
> Where can I get/find Tcl Blend 1.3?
> 
> Gary

It is in the CVS. The SF page has info about how to
set the CVS root and download. The module name is
"tcljava". Note that Tcl Blend 1.3 is not released
yet, but I think it works better than 1.2.6 in
many ways (but still, it is "for developers only").

Mo DeJong
Red Hat Inc



Hi,

Where can I get/find Tcl Blend 1.3?

Gary





To Mo DeJung, ref. your comments on my test case, a modified "test
filecmd-17.2 {cmdProc: mtime}":

I have to admit that I don't se any way to make a simple regression test
case that proves my correction right. But there is no doubt that we got a
problem.

We need to look into some theory: The TCL documentation says that "file
mtime" returns seconds since "the epoch". The Jacl implementation is
File.lastModified(), which, according to its documentation, returns
milliseconds since "the epoch". By looking at "now" in the latter terms, we
find that the number of milliseconds is just too large to put into a 32-bit
integer, which is TCL's concept of an integer. What happens is that the
(int) casting on the long result simply cuts off whatever is to the left of
the first 32 bits.

Then the "file mtime" result will jump up and down in a cyclus of 8-9
months where the results will be negative, zero and then positive.
Comparison of the age of two files made within a shorter interval (days)
will most often come out right, although the "file mtime" results always
are wrong. Let me illustrate:

Day 2001-02-03 16:53:26, I produced a file. Day 2001-02-05 20:07:08
(approximately), I ran my version of the "filecmd-17.2" test, which changed
the timestamp of the file.

          Decimal            Hexadecimal
Stamp 1   981215606 * 1000 = 0xe47501f4f0
Stamp 2   981400028 * 1000 = 0xe480000360

Running this test with the un-corrected Jacl gives this trace print:

  old / new: 1963062512 / -2147166784

Looking at the time stamps chopped down to 32-bit signed integers makes
sense:

0x7501f4f0 = 1963062512
0x80000360 = 2147484512

The reason day 2001-02-05 20:07:08 is interesting is that this is one of
these times where bit 32 turns on (from 0xe47ffffffff to 0xe480000000) and
the the result from the un-corrected version turns negative. The next time
this will happen must be when the clock turns 0xe580000620, which is  Mar
27 14:09:56. You can try this out:

981400028 * 1000 = e480000360
985694996 * 1000 = e580000620

% clock format 981400028
Mon Feb 05 20:07:08 GMT+01:00 2001
% clock format 985694996
Tue Mar 27 14:09:56 GMT+02:00 2001

Looking at your figures for the un-corrected and corrected versions of
Jacl:

Decimal                 Hexadecimal
1465268512 =            0xe4575f2648
980718397 * 1000 =      0x575f2648

shows us that your Linux figures are as wrong as any other "file mtime"
result and it shows why: Your time stamps were the same and the wrong one
had its left "0xe4" cut off.

My test run, described above, tells us that when running in certain time
slots, the result is wrong. Does a regression test of Jacl include
manipulating the system clock? If so, the shift at 2001-02-05 20:07:08 is a
good point in time to prove that the wrong version produces a wrong result
and that the result even can turn negative.

But when it comes to a straight test case, I give up.

Kind regards, Christian Sorensen




On Fri, 2 Feb 2001, Gary Baranzini wrote:

> Hi, 
> 
> I have a tcl script that performs the following statement:
>     load tclx83.dll Tclx 
> 
> When I run my tcl script, using  tcl84 shell, the tcl script works fine. 
> 
> I want to use jacl to run my tcl script from my java application. 

You can't load native Tcl libs into a Jacl application. If you
want to do that, you will need to use Tcl Blend not Jacl.
Tcl Blend 1.3 supports loading both Tcl and Tcl Blend into
an existing JVM.

Mo DeJong
Red Hat Inc



Hi, 

I have a tcl script that performs the following statement:
    load tclx83.dll Tclx 

When I run my tcl script, using  tcl84 shell, the tcl script works fine. 

I want to use jacl to run my tcl script from my java application. 

This following little test java program sources my tcl script but it appears to fail when the load command is executed.  If
 I comment the load statement, the script continues,

import tcl.lang.*; 

main()
{
    try
    {
        Interp i = new Interp();
        i.evalFile("makeTheList.tcl");
    }
    catch (tcl.lang.TclException e)
    {
        System.out.println (e.getLocalizedMessage());
    }
} 

The tclx83.dll file is in my current directory. I get a "null" when I run my test program


Any ideas or suggestions. 

TIA 

Gary






On Fri, 2 Feb 2001, Johnson, Bruce wrote:

> Hi All,
> 
> I just added the ability to read and write binary data (activating
> fconfigure's binary argument, adding a read and write binary (to & from
> TclByteArray objects)  to Channel, FileChannel and StdChannel).

Cool.

> Before I did any more work on this I wanted to make sure no one
> else is currently working on it ( I need to get this working
> quickly for my own use).  If not I may plug away at some of
> the other fconfigure modes.
> 
> Bruce

Nobody else is working on it. I would really like to get
Tcl file IO working before doing a 1.3 release of Jacl.
The basics are not that hard, but they would take
some time to implement properly. The reall tricky bit
is the fileevent API. It would need to be implemented
like the fileevent impl under Windows since Java
does not support async IO.

Do you want to take over as the "owner" of this
SF task id?

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=20698&group_id=13005&group_project_id=4999

Mo DeJong
Red Hat Inc



Hi All,

I just added the ability to read and write binary data (activating
fconfigure's binary argument, adding a read and write binary (to & from
TclByteArray objects)  to Channel, FileChannel and StdChannel).  Before I
did any more work on this I wanted to make sure no one else is currently
working on it ( I need to get this working quickly for my own use).  If not
I may plug away at some of the other fconfigure modes.

Bruce


Bruce Johnson, PhD
Sr. Research Fellow
Dept. of Endocrinology and Chemical Biology
Merck Research Laboratories
RY80Y-103
PO Box 2000
Rahway, NJ 07090

732 594-3166 (voice)
732 594-2991 (fax)
http://www.nmrview.com/swank/index.html




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

    Mo> On Sat, 6 Jan 2001, Dan Wickstrom wrote:
    >> Mo,
    >> 
    >> I would like to apply the attached patch to the tclblend source
    >> to add support for aolserver.  Let me know if it's ok.
    >> 
    >> -Dan

    Mo> In looking at this patch, I am a bit bothered by the fact that
    Mo> you moved the ThreadSpecificData struct from javaCmd.c to
    Mo> java.h. I was under the impression that Tcl needed to have
    Mo> this struct defined only in the .c file and not the .h
    Mo> file. This is so that it can be defined as different ways for
    Mo> different files. It seems you worked around this merging the
    Mo> TSD data, but I am not sure that it really "right". Will it
    Mo> break some other code that might need to #include java.h?

Typically the TSD (thread-specific-data) structure is limited to
"file" scope.  That way you can have multiple TSD structures
(one-per-file) that are isolated from each other.  I have taken the
two TSD structures that previously existed and combined them into a
single TSD structure which is accessible with global scope throughout
the tclblend sources.  If you included java.h in a file that already
had its own TSD structure defined, then there would be a problem.  The
way I have it setup now, you would need to add new variables to the
existing TSD structure rather than creating a separate TSD structure
as I did when I modified the notifier to be multi-threaded.

    Mo> I am not sure exactly what you want to do with the data ptr
    Mo> returned by JavaGetDataKey, can it be cast to a void * so that
    Mo> code outside of javaCmd.c does not need to know the type of
    Mo> the TSD ptr?

I use JavaGetDataKey to get the TSD data key when I'm accessing the
TSD structure from the aolserver specific code.  Yes, I should be able
to change it to return a void pointer.

    Mo> Also, why do you not call Interp.dispose() when compiled with
    Mo> -DWITH_AOLSERVER ?  A comment about why that bit was compiled
    Mo> out might be good. I assume it has something to do with this
    Mo> do_cleanup flag. I am a little fuzzy on what that is needed
    Mo> for.

    Mo> Also, why did you change the calls in JavaInterpDeleted? 

Aolserver disposes of the interpreter automatically, so it is not
necessary to explicitly dispose of the interpreter in aolserver.
Having the dispose call caused the server to crash.

    Mo> Does
    Mo> adding that tid variable in Java_tcl_lang_Notifier_init and
    Mo> Java_tcl_lang_Notifier_alertNotifier get rid of a compiler
    Mo> warning or something?

Yes, that was done to get rid of a compiler warning.




On Sat, 6 Jan 2001, Dan Wickstrom wrote:

> Mo,
> 
> I would like to apply the attached patch to the tclblend source to add
> support for aolserver.  Let me know if it's ok.
> 
> -Dan

In looking at this patch, I am a bit bothered by the
fact that you moved the ThreadSpecificData struct
from javaCmd.c to java.h. I was under the impression
that Tcl needed to have this struct defined only
in the .c file and not the .h file. This is so
that it can be defined as different ways for
different files. It seems you worked around
this merging the TSD data, but I am not
sure that it really "right". Will it
break some other code that might need
to #include java.h?

I am not sure exactly what you want to do
with the data ptr returned by JavaGetDataKey,
can it be cast to a void * so that code
outside of javaCmd.c does not need to
know the type of the TSD ptr?

Also, why do you not call Interp.dispose()
when compiled with -DWITH_AOLSERVER ?
A comment about why that bit was
compiled out might be good. I assume
it has something to do with this
do_cleanup flag. I am a little
fuzzy on what that is needed for.

Also, why did you change the calls
in JavaInterpDeleted? Does adding
that tid variable in
Java_tcl_lang_Notifier_init and
Java_tcl_lang_Notifier_alertNotifier
get rid of a compiler warning or
something?

Mo DeJong
Red Hat Inc



On Tue, 9 Jan 2001 cs...@ma... wrote:
 
> Hi again!
> 
> Re: tcljava-dev digest, Vol 1 #14.
> 
> I have made a test case, modifying the FileCmd.test element "filecmd-17.2"
> into this:
> 
> test filecmd-17.2 {cmdProc: mtime} {
>     set old [file mtime gorp.file]
>     for {set i 0} {$i < 10000} {incr i} {
>     }
>     set f [open gorp.file w]
>     puts $f "More text"
>     close $f
>     set new [file mtime gorp.file]
>   puts "old / new: $old / $new"
>     #expr {($new > $old) && ($new <= ($old+5))}
>     expr {($new > $old)}
> } {1}
> 
> Provided that there is a file called "gorp.file" when you start, the test
> will run. The "puts old/new..." statement shows something like:
> 
>   old / new: 979032853 / 979032903
> 
> when running with the patch, and something like:
> 
>   old / new: -219219228 / -219202955
> 
> on the orignal Jacl 1.2.6. The annoying part is that the wrong results
> actually gave the rigth answer - the second number is greater than the
> first. The experiences leading me to finding this error, however, showed me
> that this answer could easily be the other way around. Anyway, a negative
> number can never be what we want.
> 
> Kind regards, Christian Sorensen.


Sorry, but I just don't see how your test
case demonstrates the problem you talked
about. It seems like you just added
a for loop to the original filecmd-17.2
test. I don't get it.

When I run the test case with Jacl
from the current CVS, I get the
following on Linux:

old / new: 1465268512 / 1465270512

With your patch, I see results
more like:

old / new: 980718397 / 980718399

You were reporting results like:

>   old / new: -219219228 / -219202955

I have to assume that this only happens
on Windows. Is the problem just that
these numbers are less than zero? Could
you just change the test case so
that it made sure both of the
numbers that were returned were
greater than zero?

Mo DeJong
Red Hat Inc



Hi all.

I just finished up the first wave of changes needed to update
the regression tests used by Jacl to Tcl 8.3 specs. Things
went well, but a lot more work if going to be needed to
get Jacl up to date with respect to Tcl 8.3. If you have
any free time, it would be great if you could pick a
test file that has some failing cases and patch Jacl
so that those tests pass.

Here are the current test results:

all.tcl:        Total   6635    Passed  6070    Skipped 226     Failed  339

As you can see, things are not bad at all. The big problem that
remains is the lack of low level IO features in Jacl. This
makes it hard to run lots of tests since they use commands
like fconfigure and the like.

Mo DeJong
Red Hat Inc



Hi again!

Re: tcljava-dev digest, Vol 1 #14.

I have made a test case, modifying the FileCmd.test element "filecmd-17.2"
into this:

test filecmd-17.2 {cmdProc: mtime} {
    set old [file mtime gorp.file]
    for {set i 0} {$i < 10000} {incr i} {
    }
    set f [open gorp.file w]
    puts $f "More text"
    close $f
    set new [file mtime gorp.file]
  puts "old / new: $old / $new"
    #expr {($new > $old) && ($new <= ($old+5))}
    expr {($new > $old)}
} {1}

Provided that there is a file called "gorp.file" when you start, the test
will run. The "puts old/new..." statement shows something like:

  old / new: 979032853 / 979032903

when running with the patch, and something like:

  old / new: -219219228 / -219202955

on the orignal Jacl 1.2.6. The annoying part is that the wrong results
actually gave the rigth answer - the second number is greater than the
first. The experiences leading me to finding this error, however, showed me
that this answer could easily be the other way around. Anyway, a negative
number can never be what we want.

Kind regards, Christian Sorensen.



                                                                                                                     
                                                                                                                     
                     tcl...@li...       To:     tcl...@li...                  
                     ceforge.net                          cc:                                                        
                     Sent by:                             Subject:      tcljava-dev digest, Vol 1 #14 - 3 msgs       
                     tcl...@li...                                                                  
                     forge.net                                                                                       
                                                                                                                     
                                                                                                                     
                     2001-01-08 21:05                                                                                
                     Please respond to tcljava-dev                                                                   
                                                                                                                     
                                                                                                                     
                                                                                                                     



Send tcljava-dev mailing list submissions to
           tcl...@li...
To subscribe or unsubscribe via the World Wide Web, visit
           http://lists.sourceforge.net/mailman/listinfo/tcljava-dev
or, via email, send a message with subject or body 'help' to
           tcl...@li...

You can reach the person managing the list at
           tcl...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of tcljava-dev digest..."


Today's Topics:

   1. Jacl and file mtime (cs...@ma...)
   2. Re: Jacl and file mtime (Christian Krone)
   3. Re: Jacl and file mtime (Mo DeJong)

--__--__--

Message: 1
To: tcl...@li...
From: cs...@ma...
Date: Mon, 8 Jan 2001 08:02:56 +0100
Subject: [tcljava-dev] Jacl and file mtime
Reply-To: tcl...@li...

Hi!

I am using the Java implementation of Tcl, called Jacl, version 1.2.6.

I just tried to use the "file mtime <filename>" command and found out that
it does not work properly (on Windows 95/NT, that is). The reason seems to
be that the Tcl concept of integers is 32-bit and that the Java
File.getModified() method returns a long too long to be stored in an int.
By experimenting with  File.getModified() in pure Java (on Windows 95) I
found out that the three rigtmost digits of this huge number always were
"000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
time / 1000, "file mtime" became acceptable for an int - and it became
useful, e.g. for "make" like utilities.

Recap: In tcl.lang.FileCmd, method getMtime(), I changed:

  return (int) fileObj.lastModified();

to something like:

  long l = fileObj.lastModified();
  return (int) (l / 1000);

I should stress that I this was tested on Windows 95, where I get that long
(12 decimal digits) result but always with "000" in the rightmost three
digits. On Windows NT 4, I get a similarly long number but actually the
three rightmost digits are not (always) "000". But maybe the granularity is
so fine here that my simple fix still would work for all practical
purposes. From Windows NT, I have two files with the same timestamp
(<hours>:<minutes>), i.e. same minute, and they are different from the 5'th
digit from the right, not bad:

978591035662
978591042491

By the way: This "97" indicates that soon (?) we should be able to handle
13 digits!!?

What happens on non-Windows platforms I don't know.

I considered introducing the Java type "long" in Jacl but that seems hard
to control and a violation of some nice and simple principles for Tcl per
se.

Kind regards, Christian Sorensen.



--__--__--

Message: 2
Date: Mon, 08 Jan 2001 09:14:13 +0100
From: Christian Krone <chr...@so...>
Organization: SQL Datenbanksysteme GmbH
To: tcl...@li...
Subject: Re: [tcljava-dev] Jacl and file mtime
Reply-To: tcl...@li...

Hello,

Christian Sorensen wrote:

> I am using the Java implementation of Tcl, called Jacl, version 1.2.6.

> I just tried to use the "file mtime <filename>" command and found out
that
> it does not work properly (on Windows 95/NT, that is). The reason seems
to
> be that the Tcl concept of integers is 32-bit and that the Java
> File.getModified() method returns a long too long to be stored in an int.
> By experimenting with  File.getModified() in pure Java (on Windows 95) I
> found out that the three rigtmost digits of this huge number always were
> "000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
> time / 1000, "file mtime" became acceptable for an int - and it became
> useful, e.g. for "make" like utilities.

The JavaDoc of File.lastModified() explicitely mentions, that the return
value
should be interpreted in milliseconds. So I think that the implementation
of FileCmd.getMtime() is just wrong. It should devide the long value by
1000
any way to receive a valid date in seconds.

> What happens on non-Windows platforms I don't know.

I wonder why the comment in FileCmd.java above the definition of getMtime()
states that the return value of File.lastModified() is platform dependent.
This is not mentioned by the docs and at least on Linux and Windows the
return value is actually the same: the amount of millis since the Epoch.

I think the patch should devide by 1000 and should remove the comment
also...
So it would read like the following:

---- FileCmd.java~       Wed Aug 16 06:45:36 2000
+++ FileCmd.java        Mon Jan  8 09:09:05 2001
@@ -462,9 +462,6 @@
  * getMtime --
  *
  *     Finds the last modification of file in fileObj.
- *     WARNING:   The return value of lastModified() is system dependent
and
- *     should only be used to compare with other values returned by last
- *     modified. It should not be interpreted as an absolute time.
  *
  * Results:
  *     Returns an int representation of modification time.
@@ -488,7 +485,7 @@
        throw new TclPosixException(interp, TclPosixException.ENOENT, true,
                "could not read \"" + fileName + "\"");
     }
-    return (int) fileObj.lastModified();
+    return (int) (fileObj.lastModified() / 1000);
 }


 /*

> By the way: This "97" indicates that soon (?) we should be able to handle
> 13 digits!!?

Not exactly. The overrun will happen, but some thirty years ahead:
bash-2.04$ jaclsh
% expr 0x7fffffff
2147483647
% clock format 0x7fffffff
Tue Jan 19 04:14:07 GMT+01:00 2038

Greetings, Krischan
--
Christian Krone, SQL Datenbanksysteme GmbH


--__--__--

Message: 3
Date: Mon, 8 Jan 2001 00:22:59 -0800 (PST)
From: Mo DeJong <md...@cy...>
To: tcl...@li...
Subject: Re: [tcljava-dev] Jacl and file mtime
Reply-To: tcl...@li...

On Mon, 8 Jan 2001, Christian Krone wrote:

> Hello,
>
> Christian Sorensen wrote:
>
> > I am using the Java implementation of Tcl, called Jacl, version 1.2.6.
>
> > I just tried to use the "file mtime <filename>" command and found out
that
> > it does not work properly (on Windows 95/NT, that is). The reason seems
to
> > be that the Tcl concept of integers is 32-bit and that the Java
> > File.getModified() method returns a long too long to be stored in an
int.
> > By experimenting with  File.getModified() in pure Java (on Windows 95)
I
> > found out that the three rigtmost digits of this huge number always
were
> > "000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
> > time / 1000, "file mtime" became acceptable for an int - and it became
> > useful, e.g. for "make" like utilities.
>
> The JavaDoc of File.lastModified() explicitely mentions, that the return
value
> should be interpreted in milliseconds. So I think that the implementation
> of FileCmd.getMtime() is just wrong. It should devide the long value by
1000
> any way to receive a valid date in seconds.
>
> > What happens on non-Windows platforms I don't know.
>
> I wonder why the comment in FileCmd.java above the definition of getMtime
()
> states that the return value of File.lastModified() is platform
dependent.
> This is not mentioned by the docs and at least on Linux and Windows the
> return value is actually the same: the amount of millis since the Epoch.
>
> I think the patch should devide by 1000 and should remove the comment
also...
> So it would read like the following:
>
> ---- FileCmd.java~       Wed Aug 16 06:45:36 2000
> +++ FileCmd.java        Mon Jan  8 09:09:05 2001
> @@ -462,9 +462,6 @@
>   * getMtime --
>   *
>   *     Finds the last modification of file in fileObj.
> - *     WARNING:   The return value of lastModified() is system dependent
and
> - *     should only be used to compare with other values returned by last
> - *     modified. It should not be interpreted as an absolute time.
>   *
>   * Results:
>   *     Returns an int representation of modification time.
> @@ -488,7 +485,7 @@
>         throw new TclPosixException(interp, TclPosixException.ENOENT,
true,
>                 "could not read \"" + fileName + "\"");
>      }
> -    return (int) fileObj.lastModified();
> +    return (int) (fileObj.lastModified() / 1000);
>  }

I would have no problem with this patch as long
as there is a test case that shows the bug
before the patch and no bug after the patch.
The tests are a bit of a mess right now, so
I think the most safe bet would be to put
the test in tcljava/tests/jacl/FileCmd.test.

Mo DeJong
Red Hat Inc



--__--__--

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


End of tcljava-dev Digest







On Mon, 8 Jan 2001, Christian Krone wrote:

> Hello,
> 
> Christian Sorensen wrote:
> 
> > I am using the Java implementation of Tcl, called Jacl, version 1.2.6.
> 
> > I just tried to use the "file mtime <filename>" command and found out that
> > it does not work properly (on Windows 95/NT, that is). The reason seems to
> > be that the Tcl concept of integers is 32-bit and that the Java
> > File.getModified() method returns a long too long to be stored in an int.
> > By experimenting with  File.getModified() in pure Java (on Windows 95) I
> > found out that the three rigtmost digits of this huge number always were
> > "000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
> > time / 1000, "file mtime" became acceptable for an int - and it became
> > useful, e.g. for "make" like utilities.
> 
> The JavaDoc of File.lastModified() explicitely mentions, that the return value
> should be interpreted in milliseconds. So I think that the implementation
> of FileCmd.getMtime() is just wrong. It should devide the long value by 1000
> any way to receive a valid date in seconds.
> 
> > What happens on non-Windows platforms I don't know.
> 
> I wonder why the comment in FileCmd.java above the definition of getMtime()
> states that the return value of File.lastModified() is platform dependent.
> This is not mentioned by the docs and at least on Linux and Windows the
> return value is actually the same: the amount of millis since the Epoch.
> 
> I think the patch should devide by 1000 and should remove the comment also...
> So it would read like the following:
> 
> ---- FileCmd.java~       Wed Aug 16 06:45:36 2000
> +++ FileCmd.java        Mon Jan  8 09:09:05 2001
> @@ -462,9 +462,6 @@
>   * getMtime --
>   *
>   *     Finds the last modification of file in fileObj.
> - *     WARNING:   The return value of lastModified() is system dependent and
> - *     should only be used to compare with other values returned by last
> - *     modified. It should not be interpreted as an absolute time.
>   *
>   * Results:
>   *     Returns an int representation of modification time.
> @@ -488,7 +485,7 @@
>         throw new TclPosixException(interp, TclPosixException.ENOENT, true,
>                 "could not read \"" + fileName + "\"");
>      }
> -    return (int) fileObj.lastModified();
> +    return (int) (fileObj.lastModified() / 1000);
>  }

I would have no problem with this patch as long
as there is a test case that shows the bug
before the patch and no bug after the patch.
The tests are a bit of a mess right now, so
I think the most safe bet would be to put
the test in tcljava/tests/jacl/FileCmd.test.

Mo DeJong
Red Hat Inc



Hello,

Christian Sorensen wrote:

> I am using the Java implementation of Tcl, called Jacl, version 1.2.6.

> I just tried to use the "file mtime <filename>" command and found out that
> it does not work properly (on Windows 95/NT, that is). The reason seems to
> be that the Tcl concept of integers is 32-bit and that the Java
> File.getModified() method returns a long too long to be stored in an int.
> By experimenting with  File.getModified() in pure Java (on Windows 95) I
> found out that the three rigtmost digits of this huge number always were
> "000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
> time / 1000, "file mtime" became acceptable for an int - and it became
> useful, e.g. for "make" like utilities.

The JavaDoc of File.lastModified() explicitely mentions, that the return value
should be interpreted in milliseconds. So I think that the implementation
of FileCmd.getMtime() is just wrong. It should devide the long value by 1000
any way to receive a valid date in seconds.

> What happens on non-Windows platforms I don't know.

I wonder why the comment in FileCmd.java above the definition of getMtime()
states that the return value of File.lastModified() is platform dependent.
This is not mentioned by the docs and at least on Linux and Windows the
return value is actually the same: the amount of millis since the Epoch.

I think the patch should devide by 1000 and should remove the comment also...
So it would read like the following:

---- FileCmd.java~       Wed Aug 16 06:45:36 2000
+++ FileCmd.java        Mon Jan  8 09:09:05 2001
@@ -462,9 +462,6 @@
  * getMtime --
  *
  *     Finds the last modification of file in fileObj.
- *     WARNING:   The return value of lastModified() is system dependent and
- *     should only be used to compare with other values returned by last
- *     modified. It should not be interpreted as an absolute time.
  *
  * Results:
  *     Returns an int representation of modification time.
@@ -488,7 +485,7 @@
        throw new TclPosixException(interp, TclPosixException.ENOENT, true,
                "could not read \"" + fileName + "\"");
     }
-    return (int) fileObj.lastModified();
+    return (int) (fileObj.lastModified() / 1000);
 }
 
 
 /*

> By the way: This "97" indicates that soon (?) we should be able to handle
> 13 digits!!?

Not exactly. The overrun will happen, but some thirty years ahead:
bash-2.04$ jaclsh
% expr 0x7fffffff
2147483647
% clock format 0x7fffffff
Tue Jan 19 04:14:07 GMT+01:00 2038

Greetings, Krischan
-- 
Christian Krone, SQL Datenbanksysteme GmbH



Hi!

I am using the Java implementation of Tcl, called Jacl, version 1.2.6.

I just tried to use the "file mtime <filename>" command and found out that
it does not work properly (on Windows 95/NT, that is). The reason seems to
be that the Tcl concept of integers is 32-bit and that the Java
File.getModified() method returns a long too long to be stored in an int.
By experimenting with  File.getModified() in pure Java (on Windows 95) I
found out that the three rigtmost digits of this huge number always were
"000". So, by fixing tcl.lang.FileCmd's method getMtime() to return the
time / 1000, "file mtime" became acceptable for an int - and it became
useful, e.g. for "make" like utilities.

Recap: In tcl.lang.FileCmd, method getMtime(), I changed:

  return (int) fileObj.lastModified();

to something like:

  long l = fileObj.lastModified();
  return (int) (l / 1000);

I should stress that I this was tested on Windows 95, where I get that long
(12 decimal digits) result but always with "000" in the rightmost three
digits. On Windows NT 4, I get a similarly long number but actually the
three rightmost digits are not (always) "000". But maybe the granularity is
so fine here that my simple fix still would work for all practical
purposes. From Windows NT, I have two files with the same timestamp
(<hours>:<minutes>), i.e. same minute, and they are different from the 5'th
digit from the right, not bad:

978591035662
978591042491

By the way: This "97" indicates that soon (?) we should be able to handle
13 digits!!?

What happens on non-Windows platforms I don't know.

I considered introducing the Java type "long" in Jacl but that seems hard
to control and a violation of some nice and simple principles for Tcl per
se.

Kind regards, Christian Sorensen.




Mo,

I would like to apply the attached patch to the tclblend source to add
support for aolserver.  Let me know if it's ok.

-Dan

Thanks to a lot of hard work by Christian Krone, Jacl 1.3
is now able to run the tcltest package from Tcl 8.3.
Jacl currently uses a pre-8.0 test suite. Updating
the test suite is going to be a lot of hard work,
but at least the first step has begun.

I just checked in the tcltest.tcl file from the Tcl
8.3 suite, along with the changes needed to get
it running. Each test file is going to need to
be updated so that:

if {[lsearch [namespace children] ::tcltest] == -1} {
    package require tcltest
    namespace import -force ::tcltest::*
}

appears at the top and:

# cleanup
::tcltest::cleanupTests
return

appears at the bottom.


I have already updated all the test
cases in the following directories:

tests/inprogress
tests/jacl
tests/tclblend
tests/tcljava


Now for the hard part. All of the
tests in tests/tcl are going to
need to be updated to match
the ones in Tcl 8.3.

This is going to send the number
of test case failures through the
roof, since Jacl does not implement
all of Tcl 8.3 yet. My plan is to
update all the existing test cases
and then start the long process
of upgrading Jacl so that it passes
all of the test cases.

Note that we are only going to be
able to test for things that are
actually implemented. The good news
is that the list of things that
has not been implemented is getting
smaller all the time.

As always, if you are willing to lend
a hand please say so! This process
will go much more quickly if folks
help out. My hope is that when
this process is finished, Jacl
will be 99% compatible with Tcl 8.3.

cheers
Mo DeJong
Red Hat Inc




>>>>> "Dan" == Dan Wickstrom <dcw...@ea...> writes:

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

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


It appears that this method of using the finalize method to send the
object to the notifier as an event will not work correctly.  It is
possible for a tcl thread to exit before the garbage collector runs.
When the garbage collector does run and calls the finalize method, the
Tcl_ThreadAlert function will try to find the notifier for a thread
that is already cleaned up.  In such a case, Tcl_ThreadAlert is a
no-op, and no error will be noticed.  Of course the intended action of
cleaning up the corresponding Tcl_Obj's will not occur, and a memory
leak will result.  It seems that we explicitly decrement reference
counts on TclObjects when we are finished with them, we need to create
some type of automated method of tracking the underlying Tcl_Obj's and
releasing them at thread exit.

-Dan




2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (3)	Nov (12)	Dec (10)
2001	Jan (9)	Feb (29)	Mar (16)	Apr (8)	May (9)	Jun (1)	Jul (2)	Aug (4)	Sep (1)	Oct	Nov (11)	Dec (10)
2002	Jan (19)	Feb (11)	Mar (2)	Apr (17)	May (13)	Jun (2)	Jul (4)	Aug (2)	Sep (1)	Oct	Nov	Dec (4)
2003	Jan (1)	Feb	Mar (24)	Apr (9)	May (8)	Jun (17)	Jul (3)	Aug (1)	Sep	Oct (1)	Nov	Dec (2)
2004	Jan	Feb (5)	Mar	Apr	May (8)	Jun	Jul	Aug (3)	Sep	Oct	Nov	Dec (8)
2005	Jan	Feb (3)	Mar (7)	Apr	May	Jun	Jul (9)	Aug (3)	Sep (10)	Oct	Nov	Dec (3)
2006	Jan (10)	Feb (13)	Mar (11)	Apr (6)	May (4)	Jun (1)	Jul	Aug (1)	Sep	Oct	Nov	Dec (2)
2007	Jan (6)	Feb (18)	Mar (13)	Apr (1)	May	Jun (1)	Jul	Aug (6)	Sep (2)	Oct (2)	Nov (1)	Dec (1)
2008	Jan	Feb (2)	Mar	Apr (2)	May	Jun	Jul (6)	Aug (1)	Sep	Oct	Nov (6)	Dec (5)
2009	Jan (6)	Feb (3)	Mar (1)	Apr (1)	May (2)	Jun (2)	Jul	Aug	Sep (3)	Oct	Nov	Dec
2010	Jan (6)	Feb (2)	Mar (1)	Apr (7)	May (2)	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug (3)	Sep	Oct	Nov	Dec
2012	Jan	Feb	Mar	Apr (1)	May (1)	Jun	Jul	Aug (1)	Sep (1)	Oct (2)	Nov	Dec
2013	Jan	Feb (1)	Mar	Apr (1)	May	Jun (1)	Jul	Aug (4)	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug (1)	Sep	Oct (1)	Nov	Dec (1)
2015	Jan (1)	Feb	Mar	Apr (1)	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug	Sep (1)	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr (1)	May	Jun (1)	Jul	Aug (1)	Sep	Oct	Nov	Dec
2018	Jan	Feb (1)	Mar	Apr (1)	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2019	Jan	Feb	Mar	Apr (2)	May	Jun (1)	Jul	Aug (1)	Sep (2)	Oct	Nov	Dec
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2021	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec

tcljava-dev Mailing List for Tcl/Java (Page 20)

tcljava-dev — discuss implementation and post patches here