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 3 of 3 — ← Prev page 1 2 [3]

#7465

On Nov 25, 12:32 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Nov 25, 1:25 am, BruceMcF <agil...@netscape.net> wrote:
>
> > On Nov 24, 2:58 pm, Alex McDonald <b...@rivadpm.com> wrote:
>
> > > Which is why I suggested a string up-thread; cell size doesn't matter,
> > > and resolution can be whatever you wish.
>
> > Its my preferred option, as I think of time stamping and timers as two
> > different things, but if they're chasing up a ticks-since-epoch style
> > semantic for porting among POSIX systems, I'd be happy if it was not
> > unnecessarily impossible to implement by smaller systems.
>
> I agree. Dealing with a high resolution file timestamp in this fashion
> (and as has been pointed out elsethread, with limited requirement and
> justification for an accurate timestamp) simply takes us in the
> direction of a multiplicity of varying granularity timestamp formats.
> Should anyone have the requirement to translate a string into
> picoseconds since the Big Bang at 512bit resolution, they're welcome
> to do so, but to impose it as a base file timestamp standard simply
> because it's POSIX compliant is not justifiable.

[premature send]

In addition, a file timestamp should really be future proof as much as
possible. Any timestamp format that "rolls over" in the next few
hundred years is going to be unacceptable much, much earlier than
that. For example, records that are held in medical systems for the
lifetime of the patient plus 30 years, as is required by at least UK
law, demands a timestamp now that is valid out to at least 2141; a
century (since we all live longer) +30. The string "2141" (a valid ISO
date format) is sufficient.

The problem of many underlying file systems not supporting such
expansive date formats shouldn't hobble Forth.

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

#7471

BruceMcF wrote:

> On Nov 24, 2:58 pm, Alex McDonald <b...@rivadpm.com> wrote:
>> Which is why I suggested a string up-thread; cell size doesn't
>> matter, and resolution can be whatever you wish.
> 
> Its my preferred option, as I think of time stamping and timers as two
> different things, but if they're chasing up a ticks-since-epoch style
> semantic for porting among POSIX systems, I'd be happy if it was not
> unnecessarily impossible to implement by smaller systems.

I'm ok with the double ticks + single resolution (in ticks/s) solution.  
That one is dead easy to implement on a small system (you usually have 
some timer running where you can derive that value), and it is easy to 
process.  Note that on a small system, the "epoch" starts when you 
booted the device, since you often don't have a real time clock.

What I want to have:

* I don't want to impose the presence of a RTC, since it is not always 
possible
* I don't want to deal with strings, since this means some sort of 
primitive memory management (the make example will read the time stamps 
of a number of files, and then determine what to do, so a simple "is 
valid until the next call of this word" is not acceptable), and, on a 
small system, is a costly operator
* I want it be a primitive data type, so that you can use readily 
available operators
* I don't want to arbitrary limit the precision

So on a 64 bit system, femtoseconds since big bang is possible, on a 32 
bit system, microseconds since 1970.1.1T0:0:0Z won't wrap around soon, 
and on a 16 bit system, you might have 10 millisecond ticks since the 
last boot, which wraps around after one and a half year.  This is not 
the format you want your medical records in, but you won't create those 
on such a small system.

Networked systems always should synchronize their clocks with each other 
or with a common, high-quality clock source.  A network stack with time 
stamps can drop packets with "impossible" time stamps (an acknowledge 
for a packet timed before the package was sent, or after the acknowledge 
was received is impossible).

If the system has a real time clock and/or is synchronized to a global 
clock, then it should provide the information when the epoch started.  
Also, the ticks themselves should never go back.  I.e. if your clock 
needs to be synchronized by -1.2 seconds after boot, you correct the 
epoch starting point, not the actual tick counter.  If you figure out 
durning synchronization, that your so-called "nanoseconds" really are 
1002039185 ticks per second, just report that, and adjust the start of 
the epoch accordingly.  I'd propose the nominal clock starting point to 
be 1970.1.1T0:0:0Z.

This would be three words for the timing:

ticks ( -- d ) ticks since the epoch, monotonuous function, serializes 
the instruction stream, i.e. for any ticks ... ticks -, this is 
guaranteed to be <=0.
ticks/s ( -- u ) ticks per second
epoch ( -- d )  epoch started d ticks after 1970.1.1T00:00:00Z (negative 
means "before"), this is an optional word.

And for files, you have

file-ticks ( -- dc dw da ).

A standard program should assume that the timer may roll over.  How do 
we deal with small systems that have an RTC, but don't have enough bits 
to represent the epoch return value? 

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

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

#7474

On Nov 25, 10:46 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> BruceMcF wrote:
>> On Nov 24, 2:58 pm, Alex McDonald <b...@rivadpm.com> wrote:
>>> Which is why I suggested a string up-thread; cell size doesn't
>>> matter, and resolution can be whatever you wish.

>> Its my preferred option, as I think of time stamping and timers
>> as two different things, but if they're chasing up a
>> ticks-since-epoch style semantic for porting among POSIX systems,
>> I'd be happy if it was not unnecessarily impossible to implement
>> by smaller systems.

> I'm ok with the double ticks + single resolution (in ticks/s)
> solution. That one is dead easy to implement on a small system
> (you usually have some timer running where you can derive that
> value), and it is easy to process.  Note that on a small system,
> the "epoch" starts when you booted the device, since you often
> don't have a real time clock.

> What I want to have:

> * I don't want to impose the presence of a RTC, since it is not always
> possible

Yes.

> * I don't want to deal with strings, since this means some sort of
> primitive memory management (the make example will read the time stamps
> of a number of files, and then determine what to do, so a simple "is
> valid until the next call of this word" is not acceptable), and, on a
> small system, is a costly operator

The semantic I suggested was ( ca u1 fd -- ca u2 ior ) ~ if the small
system has enough room to run a make process, won't it have enough
room for a wrap around string buffer for the total number of time
stamps it might require at once?

> * I want it be a primitive data type, so that you can use readily
> available operators

Yes.

> * I don't want to arbitrary limit the precision

Yes, as it will lead those nervous about the proximity to the
precision to roll their own instead of using the portable words.

> So on a 64 bit system, femtoseconds since big bang is possible, on a 32
> bit system, microseconds since 1970.1.1T0:0:0Z won't wrap around soon,
> and on a 16 bit system, you might have 10 millisecond ticks since the
> last boot, which wraps around after one and a half year.  This is not
> the format you want your medical records in, but you won't create those
> on such a small system.

Of course, a small system may be a free standing data logger, but then
it is likely to have an RTC. Otherwise the user can be interrogated
about year, month and day at boot-up if need be.

> This would be three words for the timing:

> ticks ( -- d ) ticks since the epoch, monotonuous function, serializes
> the instruction stream, i.e. for any ticks ... ticks -, this is
> guaranteed to be <=0.
> ticks/s ( -- u ) ticks per second
> epoch ( -- d )  epoch started d ticks after 1970.1.1T00:00:00Z (negative
> means "before"), this is an optional word.
>
> And for files, you have
>
> file-ticks ( -- dc dw da ).

> A standard program should assume that the timer may roll over.  How do
> we deal with small systems that have an RTC, but don't have enough bits
> to represent the epoch return value?

Complete the semantics above ~ there still should be a textual time.
On the above, that would be:

timestamp ( ca u1 d -- ca u2|0 )
... where d is a given tick value, u1 is the length of the standard
timestamp string required, u2 is the length returned (the resolution
fraction of seconds specified might not be available) or 0 (if not
timestamp is presently available).

Then the small system simply does not provide "epoch" and holds the
information internally in some useful form ~ eg, ticks since start of
system epoch year in double and years since Unix epoch in single.

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

#7489

BruceMcF wrote:
> The semantic I suggested was ( ca u1 fd -- ca u2 ior )

That's really an awful way to return a file time stamp.  I've recently 
read an article about what the main advantage of C# and Java is over C, 
and it's the automatic memory management.  You now can actually return a 
string, instead of jumping through hoops with buffers.  The author said 
that typical Windows functions which return strings usually required a 
page of code or so, while the same thing in C# is just three lines.

There is a reason why we have words like SLURP-FILE ( addr1 u1 -- addr2 
u2 ) in Gforth, the reason is that this is a lot easier to use than when 
you manage your buffer yourself.

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

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

#7505

On Nov 25, 7:11 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> BruceMcF wrote:
> > The semantic I suggested was ( ca u1 fd -- ca u2 ior )

> That's really an awful way to return a file time stamp.

> I've recently
> read an article about what the main advantage of C# and Java is over C,
> and it's the automatic memory management.  You now can actually return
> a string, instead of jumping through hoops with buffers.

Yes, if this was used in the presumed application opening dozens of
files at the same time, we'd of course expect that the application
would wrap the word to generate and manage the buffers with whatever
string tools they are using to simplify the management of all of those
file names.

Meanwhile, for the simpler setting of of calling the timestamp on a
pair of files to compare their times, two calls to BUFFER and you have
the buffers you need.

> The author said
> that typical Windows functions which return strings usually required a
> page of code or so, while the same thing in C# is just three lines.

Yes, I agree with the author, C is indeed a pain.

> There is a reason why we have words like SLURP-FILE ( addr1 u1 -- addr2
> u2 ) in Gforth, the reason is that this is a lot easier to use than
> when you manage your buffer yourself.

But we wouldn't expect SLURP-FILE to be portable to all Forth systems
that may have access to a file system.

The other portable semantic is the TIME&DATE style:
   ( -- +n1 +n2 +n3 +n4 +n5 +n6 )

eg:
   ( -- ud +n1 +n2 +n3 +n4 +n5 )

ud: ticks since minute started ~ that allows as much resolution as a
system can specify with an unsigned single ticks/second word.

Year: +n5|0 ~ There is no 0AD, so a year of 0 implies no RTC, the
months are months since system start-up.

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

#7507

BruceMcF wrote:
> Year: +n5|0 ~ There is no 0AD, so a year of 0 implies no RTC, the
> months are months since system start-up.

Oh no, that's a fairly outdated way of counting years, the year 0 exists 
for quite some time (and negative years for the years before).  That's 
why people were actually sort-of-right who claimed that the third 
millennium started in the year 2000: the transition to a year 0 and a 
millennium therefore ending at x999/12/31 was before 2000, and the 20th 
century was the shortest century ever (only 99 years long from start to 
finish ;-), but it might have a second chance (when this century is 
renamed to "20th century", since all Fortran programmers died before it 
ends ;-).

We also had to move our monthly Forth meeting (meet on the fourth day of 
the fourth week) to Thursday due to all these date counting shifts, and 
it took quite a while until we realized that this had happened.  These 
silent calendar reforms usually have no practical impacts.

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

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

#7508

On Nov 26, 3:44 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> BruceMcF wrote:
>> Year: +n5|0 ~ There is no 0AD, so a year of 0 implies no RTC, the
>> months are months since system start-up.

> Oh no, that's a fairly outdated way of counting years,
> the year 0 exists for quite some time (and negative years for
> the years before).

Not in the Gregorian calendar. 1 CE is preceded by 1 BCE.

It certainly is in the astronomical calender, and has been for a long
time, which accounts for use of negative years in the ISO system, as
ISO Year -1 is 2BCE.

However, I don't see how we get files that are time stamped 1BCE, or
ISO Year 0, so that a range of (+n>0) poses no problems at all for the
issue at hand.

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

#7378

On Nov 20, 2:53 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> My 16 bit (DOS) Chforth version has
>   GET-FILE-TIME ( fileid -- u1 u2 ior )
> u1 and u2 are the 16 bit packed time and date respectively.
> With 2-second resolution ;-)

This would also work for FILE-TIMESTAMP ( ca u1 fd -- ca u2 ior )

If the ior is non-zero, return ( ca 0 ior ), otherwise use u2 to write
the date result and u1 to write the time result to even seconds, ".
00".

Passing the timestamp in a buffer handed by the user eliminates buffer
lifespan issues from the application ~ the internal buffer for FILE-
TIMESTAMP only has to survive until the required portion of the
results are returned ~ and also allows the timestamp to just request
the date without the time by handing across a buffer length long
enough for the Internet RFC format date alone.

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

#7370

On Nov 20, 4:06 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> ... 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.
> ...

The man page for fstat explains why the standard include file, stat.h,
does not correspond to the return buffer of the syscall:

"Underlying kernel interface
       Over time, increases in the size of the stat structure have led
to  three  successive  ver‐
       sions  of  stat():  sys_stat()  (slot  __NR_oldstat),
sys_newstat()  (slot __NR_stat), and
       sys_stat64() (new in kernel 2.4; slot __NR_stat64).   The
glibc  stat()  wrapper  function
       hides  these details from applications, invoking the most
recent version of the system call
       provided by the kernel, and repacking the returned information
if required  for  old  bina‐
       ries.  Similar remarks apply for fstat() and lstat()."

For awhile, I couldn't figure out why the C fstat() function didn't
have the same size fields as the return buffer from the syscall.
Apparently, the contents of the underlying syscall are fixed up by
fstat().

Krishna

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

#7363

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: most portable way to compare file times

> 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:
[..]
>>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.

[..]

-- --------------------------------------------------------------
iForth version 4.0.753, generated 13:01:18, October 8, 2011.
x86_64 binary, native floating-point, extended precision.
Copyright 1996 - 2011 Marcel Hendrix.

FORTH> help FILE-STATUS
FILE-STATUS                                                        FILE EXT
     ( c-addr u -- x ior )
     Return the status of the file/directory identified by the character
     string (c-addr u). The ior is zero if the file/directory exists and
     writing to it is possible; otherwise <ior> is TRUE.
     x contains implementation-defined information about the file.
     In iForth x is a bitmask giving more details,
       $0001 - set when a regular file was tested.
       $0002 - set when a directory was tested
       $0100 - set when reading from file/directory is possible
       $0200 - set when writing to file/directory is possible
     All other bits are reserved and cleared.
 ok
FORTH> locate FILE-TIME
File: C:\dfwforth/include/miscutil.frt, line: 1616
1614|
1615|  : FILE-EXISTS? ( c-addr u -- bool )   FILE-STATUS NIP 0= ;
1616>> : FILE-TIME    ( c-addr u -- ftime )  2 #416 SYSCALL 0= IF  @  ELSE  DROP 0  ENDIF ;
1617|  : FILE-BIRTH   ( c-addr u -- u )      FILE-TIME ;
1618|
-- --------------------------------------------------------------

So iForth can be used to see if a file exists, and to make sure it is not
read-only or a directory.

Getting file time (last modified) is done with a separate word. At present 
the result of this word, based on _stat64, has a resolution of one second 
and can be off by one to two seconds because of delayed-writes etc.. Although 
a 100 ns resolution for last modified is possible (it requires opening and
closing the file), write delay is a big problem for some uses of FILE-TIME. 
For instance, when a program is closed it might write out several files 
that logically depends on the other(s).

-marcel

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

#7346

On Nov 18, 8:31 am, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> 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.

However, since its not specified to be, the most portable approach in
any event will be to specify your own word that returns the
information you want, and in the portability harness of the various
implementation/OS combinations to define the implementation dependent
means of obtaining the result.

The specification has to cope with the fact that perhaps it cannot be
done for some given system, eg.
   ( caddr u ior )
where ( caddr u ) is a pointer to a timestamp in the Internet RFC
format given above, and if u=0 then the os and/or implementation does
not have access to timestamp info.

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

#7379

On Nov 18, 3: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.

Note that since your output is a Forth file source, the most vanilla
portable way to time stamp a master file and its result files where
the result files may be independently edited is to add a time stamp
comment line.

For a forth file source, a first line as a comment in the form of:

\ 2011-12-08T10:30:00.00Z Source: foo.lyx

... for the lyx file, a first line as a comment in its comment format.

You could automatically timestamp the master file if it lacks one in
the master file processing code, the result files inherit the
timestamp of the master file, and you have a freestanding word that
timestamps forth sources. The first timestamping of the masterfile
would be generated from the current TIME&DATE if available, otherwise
ask the user what the date is.

Then the masterfile processor would check to see if the result file is
already there, and if so if the timestamp already in place is later
than the one that would have been generated.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web