[tcljava-dev] Re: tcljava-dev digest, Vol 1 #14 - 3 msgs - Jacl and file mtime
Brought to you by:
mdejong
Menu
▾
▴
[tcljava-dev] Re: tcljava-dev digest, Vol 1 #14 - 3 msgs - Jacl and file mtime
|
From: <cs...@ma...> - 2001-01-09 10:01:35
|
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
|
