Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #7337 > unrolled thread

most portable way to compare file times

Back to article view | Back to comp.lang.forth

Contents

  most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-18 00:43 -0800
    Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-18 02:33 -0800
      Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-18 05:26 -0800
        Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-18 09:14 -0800
          Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-18 20:10 +0100
            Re: most portable way to compare file times Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-18 15:10 -0600
              Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-18 13:32 -0800
                Re: most portable way to compare file times anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-21 10:22 +0000
                  Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-21 08:51 -0800
              Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-19 00:57 +0100
          Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-18 14:45 -0800
    Re: most portable way to compare file times "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-11-18 05:44 -0500
      Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-18 05:31 -0800
        Re: most portable way to compare file times anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-18 16:22 +0000
          Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-19 13:59 -0800
            Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-20 02:06 -0800
              Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-20 02:44 -0800
                Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-20 14:58 +0100
                  Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-20 06:48 -0800
                    Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-20 08:05 -0800
                    Re: most portable way to compare file times Coos Haak <chforth@hccnet.nl> - 2011-11-20 20:53 +0100
                      Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-20 12:21 -0800
                        Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-21 21:03 +0100
                          Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-21 17:32 -0800
                            Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-21 17:45 -0800
                            Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-24 15:48 +0100
                              Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-24 09:34 -0800
                                Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-24 11:58 -0800
                                  Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-24 17:25 -0800
                                    Re: most portable way to compare file times "Elizabeth D. Rather" <erather@forth.com> - 2011-11-24 20:56 -1000
                                      Re: most portable way to compare file times Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-11-25 04:15 -0600
                                        Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-25 04:17 -0800
                                          Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-25 05:47 -0800
                                            Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-25 08:58 -0800
                                              Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-25 11:43 -0800
                                        Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-25 11:12 -0800
                                      Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-25 05:39 -0800
                                      Re: most portable way to compare file times anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-11-27 14:34 +0000
                                        Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-27 08:46 -0800
                                    Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-25 04:32 -0800
                                      Re: most portable way to compare file times Alex McDonald <blog@rivadpm.com> - 2011-11-25 04:51 -0800
                                    Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-25 16:46 +0100
                                      Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-25 08:33 -0800
                                        Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-26 01:11 +0100
                                          Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-26 12:18 -0800
                                            Re: most portable way to compare file times Bernd Paysan <bernd.paysan@gmx.de> - 2011-11-26 21:44 +0100
                                              Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-26 13:18 -0800
                      Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-20 12:45 -0800
              Re: most portable way to compare file times Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-11-20 07:49 -0800
          Re: most portable way to compare file times mhx@iae.nl (Marcel Hendrix) - 2011-11-20 09:45 +0200
        Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-18 10:42 -0800
    Re: most portable way to compare file times BruceMcF <agila61@netscape.net> - 2011-11-20 13:05 -0800

Page 1 of 3  [1] 2 3  Next page →

#7337 — most portable way to compare file times

Would like suggestions on the most portable way to implement
comparison of file times, given existing implementations of the
standard Forth-94 file extension words. That is, if I have file A and
file B, I would like to determine which file is more recent. This is,
of course, system dependent, and there are no standard Forth words to
accomplish this directly, but will likely involve use of FILE-STATUS .
Perhaps there should be a standard way of obtaining the time stamp of
the file.

My particular problem is in connection with the LyX file loader:

ftp://ccreweb.org/software/gforth/lyx-included.fs

I want to avoid regenerating the .fs file from the .lyx file, if
the .fs file is more recent than the .lyx file.

Krishna

[toc] | [next] | [standalone]

#7338

On Nov 18, 8:43 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> Would like suggestions on the most portable way to implement
> comparison of file times, given existing implementations of the
> standard Forth-94 file extension words. That is, if I have file A and
> file B, I would like to determine which file is more recent. This is,
> of course, system dependent, and there are no standard Forth words to
> accomplish this directly, but will likely involve use of FILE-STATUS .
> Perhaps there should be a standard way of obtaining the time stamp of
> the file.
>
> My particular problem is in connection with the LyX file loader:
>
> ftp://ccreweb.org/software/gforth/lyx-included.fs
>
> I want to avoid regenerating the .fs file from the .lyx file, if
> the .fs file is more recent than the .lyx file.
>
> Krishna

I'd recommend, whatever method is used to return the timestamp, that
it conforms to RFC-3339 http://www.ietf.org/rfc/rfc3339.txt. It's
human readable, UTC based, easily converted, and see 5.1 Ordering; the
format allows simple ASCII comparisons for older/younger.

[toc] | [prev] | [next] | [standalone]

#7341

On Nov 18, 4:33 am, Alex McDonald <b...@rivadpm.com> wrote:
> On Nov 18, 8:43 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
>
>
>
>
>
>
>
>
> > Would like suggestions on the most portable way to implement
> > comparison of file times, given existing implementations of the
> > standard Forth-94 file extension words. That is, if I have file A and
> > file B, I would like to determine which file is more recent. This is,
> > of course, system dependent, and there are no standard Forth words to
> > accomplish this directly, but will likely involve use of FILE-STATUS .
> > Perhaps there should be a standard way of obtaining the time stamp of
> > the file.
>
> > My particular problem is in connection with the LyX file loader:
>
> >ftp://ccreweb.org/software/gforth/lyx-included.fs
>
> > I want to avoid regenerating the .fs file from the .lyx file, if
> > the .fs file is more recent than the .lyx file.
>
> > Krishna
>
> I'd recommend, whatever method is used to return the timestamp, that
> it conforms to RFC-3339http://www.ietf.org/rfc/rfc3339.txt. It's
> human readable, UTC based, easily converted, and see 5.1 Ordering; the
> format allows simple ASCII comparisons for older/younger.

The example from the above document:

"Here are some examples of Internet date/time format.

      1985-04-12T23:20:50.52Z

   This represents 20 minutes and 50.52 seconds after the 23rd hour of
   April 12th, 1985 in UTC."

Yes, it's easy to parse.

Thanks.

Krishna

[toc] | [prev] | [next] | [standalone]

#7345

On Nov 18, 1:26 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> On Nov 18, 4:33 am, Alex McDonald <b...@rivadpm.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 18, 8:43 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
> > > Would like suggestions on the most portable way to implement
> > > comparison of file times, given existing implementations of the
> > > standard Forth-94 file extension words. That is, if I have file A and
> > > file B, I would like to determine which file is more recent. This is,
> > > of course, system dependent, and there are no standard Forth words to
> > > accomplish this directly, but will likely involve use of FILE-STATUS .
> > > Perhaps there should be a standard way of obtaining the time stamp of
> > > the file.
>
> > > My particular problem is in connection with the LyX file loader:
>
> > >ftp://ccreweb.org/software/gforth/lyx-included.fs
>
> > > I want to avoid regenerating the .fs file from the .lyx file, if
> > > the .fs file is more recent than the .lyx file.
>
> > > Krishna
>
> > I'd recommend, whatever method is used to return the timestamp, that
> > it conforms to RFC-3339http://www.ietf.org/rfc/rfc3339.txt. It's
> > human readable, UTC based, easily converted, and see 5.1 Ordering; the
> > format allows simple ASCII comparisons for older/younger.
>
> The example from the above document:
>
> "Here are some examples of Internet date/time format.
>
>       1985-04-12T23:20:50.52Z
>
>    This represents 20 minutes and 50.52 seconds after the 23rd hour of
>    April 12th, 1985 in UTC."
>
> Yes, it's easy to parse.
>
> Thanks.
>
> Krishna

Did you mean to add a smiley? I can't tell whether that's weapon's
grade sarcasm or wide-eyed innocent agreement...

[toc] | [prev] | [next] | [standalone]

#7347

Alex McDonald wrote:
> Did you mean to add a smiley? I can't tell whether that's weapon's
> grade sarcasm or wide-eyed innocent agreement...

As easy to parse time format, I'd rather suggest seconds or microseconds 
since 1970 (1970 is the time base of the Unix time stamp, so this is 
referring to POSIX) - microseconds that's what Gforth's utime gives you.  
For a file time stamp, seconds are probably good enough, for other 
purposes, you want microseconds.

This is much easier to parse (it's just a 32 or 64 bit number), it's 
easy to calculate differences, and to convert it into a time&date string 
is also not too difficult.  I've put some code here, this is correct 
until around 30 BC, when the Julian calendar was in place, and the 
obvious bugs were fixed (by that time, they had already shifted the year 
by 3 days, so 24th of december was no longer winter solstice).

http://www.forth-ev.de/wiki/doku.php/examples:daymonthyear

I do not want a human readable time format in a Forth program as 
primitive data type.  If you want it human readable, implement something 
like >utime and .utime (>utime would leave it in the picture number 
buffer).

The proposed word would be file-utime ( addr u -- udc uda udu ), with 
three result values, because you might want create, access and 
modification time.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#7348

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> 
> As easy to parse time format, I'd rather suggest seconds or microseconds 
> since 1970 (1970 is the time base of the Unix time stamp, so this is 
> referring to POSIX) - microseconds that's what Gforth's utime gives you.  
> For a file time stamp, seconds are probably good enough, for other 
> purposes, you want microseconds.
> 
> This is much easier to parse (it's just a 32 or 64 bit number),

64 bits, please!  There are many people alive now who will still be
alive when 32 (signed) bits overflow, and a few who will still be
alive when the unsigned number overflows.

Andrew.

[toc] | [prev] | [next] | [standalone]

#7349

On Nov 18, 9:10 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Bernd Paysan <bernd.pay...@gmx.de> wrote:
>
> > As easy to parse time format, I'd rather suggest seconds or microseconds
> > since 1970 (1970 is the time base of the Unix time stamp, so this is
> > referring to POSIX) - microseconds that's what Gforth's utime gives you.
> > For a file time stamp, seconds are probably good enough, for other
> > purposes, you want microseconds.

There are applications where seconds are definitely not good enough.

And Unix insists on the daftness of two 32bit fields; one accurate to
the second that expires in 2038, and the other in microseconds encoded
as a 32bit number. Insanity.

>
> > This is much easier to parse (it's just a 32 or 64 bit number),
>
> 64 bits, please!  There are many people alive now who will still be
> alive when 32 (signed) bits overflow, and a few who will still be
> alive when the unsigned number overflows.
>
> Andrew.

Hence the point of the string. It's valid til 9999AD, and can be as
shrt or as looooooooooo.ooooooooooooong as you wish; and which,
without conversion, can indicate earlier, later and equal. You can
even subtract them from each other char by char and get some sense out
of the resulting string.

[toc] | [prev] | [next] | [standalone]

#7386

Alex McDonald <blog@rivadpm.com> writes:
>On Nov 18, 9:10=A0pm, Andrew Haley <andre...@littlepinkcloud.invalid>
>wrote:
>> Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> > For a file time stamp, seconds are probably good enough

Not really, but most file systems don't provide anything better.

>There are applications where seconds are definitely not good enough.
>
>And Unix insists on the daftness of two 32bit fields; one accurate to
>the second that expires in 2038, and the other in microseconds encoded
>as a 32bit number. Insanity.

Unix has several funny time specifications, but they are not relevant
for Forth.

I suggest to use doubles as the basic time format for Forth.  Do we
really need to standardize the units used? (If we just need to know
which was earlier, the units are irrelevant).  Or do we prefer to
standardize a conversion word from the unspecified tick unit to real
units?

If we want to standardize units, microseconds seem to be a good match
for systems with 32-bit cells: fine-grained enough for most purposes
in the foreseeable future (and given that the CPU clock rates have
mostly stopped increasing, that's probably going to be good enough for
a while), with a range of more than 200,000 years on either side of
the Epoch, which should also be good enough for most purposes.

Alternatively, Nanoseconds, which gives us only ~280 years or so on
either side of the Epoch, and those people who need more should use
64-bit systems.

16-bit systems won't be very happy with either unit, but it ISTM that
16-bit systems prefer compactness to standardness anyway.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

[toc] | [prev] | [next] | [standalone]

#7389

On Nov 21, 5:22 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> I suggest to use doubles as the basic time format for Forth.  Do we
> really need to standardize the units used? (If we just need to know
> which was earlier, the units are irrelevant).  Or do we prefer to
> standardize a conversion word from the unspecified tick unit to real
> units?

For a consolidated time integer, 16bit systems are better off with
time ticks as a double. But then the number of microseconds per tick
is a double for 16bit systems and a single for larger systems.

> If we want to standardize units, microseconds seem to be a good match
> for systems with 32-bit cells: fine-grained enough for most purposes
> in the foreseeable future (and given that the CPU clock rates have
> mostly stopped increasing, that's probably going to be good enough for
> a while), with a range of more than 200,000 years on either side of
> the Epoch, which should also be good enough for most purposes.

> Alternatively, Nanoseconds, which gives us only ~280 years or so on
> either side of the Epoch, and those people who need more should use
> 64-bit systems.

> 16-bit systems won't be very happy with either unit, but it ISTM that
> 16-bit systems prefer compactness to standardness anyway.

A +/- ticks since epoch as a double and a nanoseconds per tick word
would allow 16bit systems to support source that only cares about
relative time position, without implementing the nanoseconds per tick
word if it is out of range.

[toc] | [prev] | [next] | [standalone]

#7353

Andrew Haley wrote:
> 64 bits, please!  There are many people alive now who will still be
> alive when 32 (signed) bits overflow, and a few who will still be
> alive when the unsigned number overflows.

I'm all for 64 bits (double number, i.e. 128 bits on a 64 bit system), 
but then microseconds, please.  All timing informations should be 
treated as cyclic numbers, i.e. you calculate deltas with -, and before 
or after depends on the sign; you don't compare with < or u<, you 
compare with - 0<.  I'm more worried that the 292471 years are too much 
to find all the bugs where the time is actually compared with < or u<, 
which it shouldn't ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#7351

On Nov 18, 11:14 am, Alex McDonald <b...@rivadpm.com> wrote:
> On Nov 18, 1:26 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 18, 4:33 am, Alex McDonald <b...@rivadpm.com> wrote:
>
> > > On Nov 18, 8:43 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
> > > > Would like suggestions on the most portable way to implement
> > > > comparison of file times, given existing implementations of the
> > > > standard Forth-94 file extension words. That is, if I have file A and
> > > > file B, I would like to determine which file is more recent. This is,
> > > > of course, system dependent, and there are no standard Forth words to
> > > > accomplish this directly, but will likely involve use of FILE-STATUS .
> > > > Perhaps there should be a standard way of obtaining the time stamp of
> > > > the file.
>
> > > > My particular problem is in connection with the LyX file loader:
>
> > > >ftp://ccreweb.org/software/gforth/lyx-included.fs
>
> > > > I want to avoid regenerating the .fs file from the .lyx file, if
> > > > the .fs file is more recent than the .lyx file.
>
> > > > Krishna
>
> > > I'd recommend, whatever method is used to return the timestamp, that
> > > it conforms to RFC-3339http://www.ietf.org/rfc/rfc3339.txt. It's
> > > human readable, UTC based, easily converted, and see 5.1 Ordering; the
> > > format allows simple ASCII comparisons for older/younger.
>
> > The example from the above document:
>
> > "Here are some examples of Internet date/time format.
>
> >       1985-04-12T23:20:50.52Z
>
> >    This represents 20 minutes and 50.52 seconds after the 23rd hour of
> >    April 12th, 1985 in UTC."
>
> > Yes, it's easy to parse.
>
> > Thanks.
>
> > Krishna
>
> Did you mean to add a smiley? I can't tell whether that's weapon's
> grade sarcasm or wide-eyed innocent agreement...

No, no sarcasm intended. I've found out the hard way that plain text
messages don't convey nuances of communication, ... or sometimes that
they carry unintended nuances.

Considering that different file times that may be needed, and that the
time zone may not be available, Bernd's suggestion seems like it would
be more portable. The different return values, udc, uda, and udu, can
be set to zero if the system can't return one or all of those three
values.

Krishna

[toc] | [prev] | [next] | [standalone]

#7339

"Krishna Myneni" <krishna.myneni@ccreweb.org> wrote in message
news:041be770-8990-49a9-ba0d-6d5397b6bd8a@j10g2000vbe.googlegroups.com...
>
> Would like suggestions on the most portable way to
> implement comparison of file times,
>

You want to be able to compare two integer values.

Most operating systems allow you to convert the time to a single integer
value in terms of seconds since Jan 1, 1970 - called the start of the
epoch - for the current timezone, i.e., local time.  Some systems use 1980.
The problem is local time is expressed in total seconds from the epoch for
the current zone which is GMT+/-offset.  UTC is used in place of GMT today
...  If daylight saving time is in use, comparing the resulting integers for
local time will result in bad comparisons.  If one file has a time of
10:00AM local time as EDT (GMT-4) and another file has a time of 10:00AM
local time as EST (GMT-5), there will be an hour difference in seconds
between their local times.  So, what you want is GMT time since it's
independent of the timezone, but what you've got is local time in seconds
since the epoch which is a zone dependent time.  To get GMT, you'll need to
determine the timeshift for the current zone in seconds (e.g., 5*60*60 for
EST or 4*60*60 for EDT) and subtract that from the local time.  This will
typically require determining the zone used for the file time and encoding
the start of the epoch, e.g., Jan 1, 1970, for that zone, e.g., EDT or EST.
That gives the offset in seconds for that zone.  Then, you can subtract that
from the local time for that file.  After doing both files that way, you can
compare their times.

> given existing implementations of the
> standard Forth-94 file extension words.

After a quick skim of the ANS specification, I don't see anything related to
file times and dates, GMT, UTC, timezones, etc.  TIME&DATE seems to
be all there is ...

Good luck ...


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#7342

On Nov 18, 4:44 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Krishna Myneni" <krishna.myn...@ccreweb.org> wrote in message
>
> news:041be770-8990-49a9-ba0d-6d5397b6bd8a@j10g2000vbe.googlegroups.com...
>
>
>
> > Would like suggestions on the most portable way to
> > implement comparison of file times,
>
> You want to be able to compare two integer values.
>
> Most operating systems allow you to convert the time to a single integer
> value in terms of seconds since Jan 1, 1970 - called the start of the
> epoch - for the current timezone, i.e., local time.  Some systems use 1980.
> The problem is local time is expressed in total seconds from the epoch for
> the current zone which is GMT+/-offset.  UTC is used in place of GMT today
> ...  If daylight saving time is in use, comparing the resulting integers for
> local time will result in bad comparisons.  If one file has a time of
> 10:00AM local time as EDT (GMT-4) and another file has a time of 10:00AM
> local time as EST (GMT-5), there will be an hour difference in seconds
> between their local times.  So, what you want is GMT time since it's
> independent of the timezone, but what you've got is local time in seconds
> since the epoch which is a zone dependent time.  To get GMT, you'll need to
> determine the timeshift for the current zone in seconds (e.g., 5*60*60 for
> EST or 4*60*60 for EDT) and subtract that from the local time.  This will
> typically require determining the zone used for the file time and encoding
> the start of the epoch, e.g., Jan 1, 1970, for that zone, e.g., EDT or EST.
> That gives the offset in seconds for that zone.  Then, you can subtract that
> from the local time for that file.  After doing both files that way, you can
> compare their times.
>
> > given existing implementations of the
> > standard Forth-94 file extension words.
>
> After a quick skim of the ANS specification, I don't see anything related to
> file times and dates, GMT, UTC, timezones, etc.  TIME&DATE seems to
> be all there is ...
>
> Good luck ...
>
> Rod Pemberton

There is no ANS word to obtain a file time stamp; however, the
implication of the spec of FILE-STATUS is that it could possibly
contain the time stamp info:

--
11.6.2.1524 FILE-STATUS
FILE EXT

	( c-addr u -- x ior )

Return the status of the file identified by the character string c-
addr u. If the file exists, ior is zero; otherwise ior is the
implementation-defined I/O result code. x contains implementation-
defined information about the file.
--

Thus, x may be a buffer with the required contents. I don't know
whether current implementations of FILE-STATUS return the necessary
info.

Krishna

[toc] | [prev] | [next] | [standalone]

#7343

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>There is no ANS word to obtain a file time stamp; however, the
>implication of the spec of FILE-STATUS is that it could possibly
>contain the time stamp info:
>
>--
>11.6.2.1524 FILE-STATUS
>FILE EXT
>
>	( c-addr u -- x ior )
>
>Return the status of the file identified by the character string c-
>addr u. If the file exists, ior is zero; otherwise ior is the
>implementation-defined I/O result code. x contains implementation-
>defined information about the file.
>--
>
>Thus, x may be a buffer with the required contents. I don't know
>whether current implementations of FILE-STATUS return the necessary
>info.

At least two implementations (Gforth and PFE) return a fam (file
access mode, to be consumed by OPEN-FILE), so they certainly do not
return the modification time.

FILE-STATUS is an example of what happens if a word is underspecified
in standardization: There is no useful standard or portable usage, and
the name is burned and cannot be used for a useful word.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

[toc] | [prev] | [next] | [standalone]

#7361

On Nov 18, 10:22 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> >There is no ANS word to obtain a file time stamp; however, the
> >implication of the spec of FILE-STATUS is that it could possibly
> >contain the time stamp info:
>
> >--
> >11.6.2.1524 FILE-STATUS
> >FILE EXT
>
> >    ( c-addr u -- x ior )
>
> >Return the status of the file identified by the character string c-
> >addr u. If the file exists, ior is zero; otherwise ior is the
> >implementation-defined I/O result code. x contains implementation-
> >defined information about the file.
> >--
>
> >Thus, x may be a buffer with the required contents. I don't know
> >whether current implementations of FILE-STATUS return the necessary
> >info.
>
> At least two implementations (Gforth and PFE) return a fam (file
> access mode, to be consumed by OPEN-FILE), so they certainly do not
> return the modification time.
>
> FILE-STATUS is an example of what happens if a word is underspecified
> in standardization: There is no useful standard or portable usage, and
> the name is burned and cannot be used for a useful word.
>
> - anton
> --
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard:http://www.forth200x.org/forth200x.html
>    EuroForth 2011:http://www.euroforth.org/ef11/


fstat appears to be a Posix standard interface for obtaining the
necessary info about a file, including the various time stamps
associated it with it. To me, this would have been the logical mapping
of FILE-STATUS on a Unix-like system.

Krishna

[toc] | [prev] | [next] | [standalone]

#7364

On Nov 19, 3:59 pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> On Nov 18, 10:22 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>
>
>
>
>
>
>
>
>
> > Krishna Myneni <krishna.myn...@ccreweb.org> writes:
> > >There is no ANS word to obtain a file time stamp; however, the
> > >implication of the spec of FILE-STATUS is that it could possibly
> > >contain the time stamp info:
>
> > >--
> > >11.6.2.1524 FILE-STATUS
> > >FILE EXT
>
> > >    ( c-addr u -- x ior )
>
> > >Return the status of the file identified by the character string c-
> > >addr u. If the file exists, ior is zero; otherwise ior is the
> > >implementation-defined I/O result code. x contains implementation-
> > >defined information about the file.
> > >--
>
> > >Thus, x may be a buffer with the required contents. I don't know
> > >whether current implementations of FILE-STATUS return the necessary
> > >info.
>
> > At least two implementations (Gforth and PFE) return a fam (file
> > access mode, to be consumed by OPEN-FILE), so they certainly do not
> > return the modification time.
>
> > FILE-STATUS is an example of what happens if a word is underspecified
> > in standardization: There is no useful standard or portable usage, and
> > the name is burned and cannot be used for a useful word.
>
> > - anton
> > --
> > M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> > comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html
> >      New standard:http://www.forth200x.org/forth200x.html
> >    EuroForth 2011:http://www.euroforth.org/ef11/
>
> fstat appears to be a Posix standard interface for obtaining the
> necessary info about a file, including the various time stamps
> associated it with it. To me, this would have been the logical mapping
> of FILE-STATUS on a Unix-like system.
>
> Krishna

Here's an example of obtaining the file status data on 32-bit Forth
systems under Linux, using the FSTAT syscall (108). The time info is
provided in three 64-bit fields. For 64-bit systems, the structure
(and its size) needs to be revised accordingly. I had to use DUMP to
figure out the sizes of the structure fields -- the stat.h include
file is hard to decipher and doesn't seem to correspond to the buffer
returned by the syscall.

KM
--

\ fstat.4th
\
\ Posix get file status
\
\ for use on 32-bit Forth systems under Linux.

include ans-words
include strings
include files
include syscalls
include struct
include struct-ext
include dump

struct
	int32:  st_dev
	int32:	st_ino
	int16:	st_mode
	int16:	st_nlink
	int16:	st_uid
	int16:	st_gid
	int32:	st_rdev
	int32:	st_size
	int32:	st_blksize
	int32:	st_blocks
	int64:	st_atime
	int64:	st_mtime
	int64:	st_ctime
        \ The structure has other fields, apparently.
end-struct file-stat%

create s1 ( file-stat% %allot drop) 88 allot

: uw@ ( a -- u) w@ ( signed word fetch) 65535 and ;

variable fd

cr .( Open the file zwords.4th ) s" zwords.4th" R/O open-file 0=
[IF]
.( ... successful.) fd !
cr .( Obtain file status of file)  fd @ s1 fstat 0=
[IF]
.( ... successful.)
cr s1 88 dump
cr .( Device id:                       ) s1 st_dev ?
cr .( Inode  #:                        ) s1 st_ino ?
cr .( Mode:                            ) s1 st_mode  uw@ .
cr .( # hard links:                    ) s1 st_nlink uw@ .
cr .( Owner user id:                   ) s1 st_uid   uw@ .
cr .( Owner group id:                  ) s1 st_gid   uw@ .
cr .( Special file id:                 ) s1 st_rdev ?
cr .( Total size in bytes:             ) s1 st_size ?
cr .( Blocksize for filesystem i/o:    ) s1 st_blksize ?
cr .( Number of 512B blocks allocated: ) s1 st_blocks ?
cr .( Last access time:                ) s1 st_atime 2@ d.
cr .( Last modification time:          ) s1 st_mtime 2@ d.
cr .( Last status change time:         ) s1 st_ctime 2@ d.
[THEN]
cr .( Close the file ) fd @ close-file drop
[ELSE]
.( ... unable to OPEN!)
[THEN]
cr

[toc] | [prev] | [next] | [standalone]

#7365

On Nov 20, 4:06 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
...
> cr .( Last access time:                ) s1 st_atime 2@ d.
> cr .( Last modification time:          ) s1 st_mtime 2@ d.
> cr .( Last status change time:         ) s1 st_ctime 2@ d.
...

For seconds elapsed since 1970-01-01, the above should be

cr .( Last access time:                ) s1 st_atime  ?
cr .( Last modification time:          ) s1 st_mtime  ?
cr .( Last status change time:         ) s1 st_ctime  ?

I'm not yet sure what the second half of the 64-bit field is supposed
to represent.

Krishna

[toc] | [prev] | [next] | [standalone]

#7367

Krishna Myneni wrote:

> On Nov 20, 4:06 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> ...
>> cr .( Last access time:                ) s1 st_atime 2@ d.
>> cr .( Last modification time:          ) s1 st_mtime 2@ d.
>> cr .( Last status change time:         ) s1 st_ctime 2@ d.
> ...
> 
> For seconds elapsed since 1970-01-01, the above should be
> 
> cr .( Last access time:                ) s1 st_atime  ?
> cr .( Last modification time:          ) s1 st_mtime  ?
> cr .( Last status change time:         ) s1 st_ctime  ?
> 
> I'm not yet sure what the second half of the 64-bit field is supposed
> to represent.

Nanoseconds.

Gforth uses gettimeofday to provide it's microseconds since the epoch 
stamp, but sice gettimeofday is declared obsolete, and clock_gettime 
returns nanoseconds, as well, maybe we should use that. A 64 bit 
nanoseconds timer since 1970 still won't overflow within our life-time 
(wraps around in 2262).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#7368

On Nov 20, 7:58 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Krishna Myneni wrote:
> > On Nov 20, 4:06 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > ...
> >> cr .( Last access time:                ) s1 st_atime 2@ d.
> >> cr .( Last modification time:          ) s1 st_mtime 2@ d.
> >> cr .( Last status change time:         ) s1 st_ctime 2@ d.
> > ...
>
> > For seconds elapsed since 1970-01-01, the above should be
>
> > cr .( Last access time:                ) s1 st_atime  ?
> > cr .( Last modification time:          ) s1 st_mtime  ?
> > cr .( Last status change time:         ) s1 st_ctime  ?
>
> > I'm not yet sure what the second half of the 64-bit field is supposed
> > to represent.
>
> Nanoseconds.
>
> Gforth uses gettimeofday to provide it's microseconds since the epoch
> stamp, but sice gettimeofday is declared obsolete, and clock_gettime
> returns nanoseconds, as well, maybe we should use that. A 64 bit
> nanoseconds timer since 1970 still won't overflow within our life-time
> (wraps around in 2262).
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

Ah, so we would have

   FILE-NTIME ( fd -- da dm dc )

where da , dm , and dc  are double length signed quantities,
representing the access, modification, and status change times in
nanoseconds. I think the argument should be a file descriptor/handle
rather than the file name. Not only is this consistent with a standard
function like fstat, but I believe it is more commonly the case that
the file is likely to already be opened when its status is needed.

The only drawback is that 16-bit Forth systems could not implement
FILE-NTIME .

Krishna

[toc] | [prev] | [next] | [standalone]

#7371

On Nov 20, 9:48 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> The only drawback is that 16-bit Forth systems could not implement
> FILE-NTIME .

But FILE-NTIME could be used to define FILE-TIMESTAMP ...
  ( c-addr1 u1 fd -- c-addr1 u2 ior )

... in general for 32bit+ POSIX based systems. For the problem at
hand, checking whether the .fs to be generated is older than the .fs
file already in place, the hundredth of a second resolution of the IRC
UTC time and date format is ample. 16bit and 20bit systems could still
support FILE-TIMESTAMP.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web