[m-rev.] for review: parsing .used files

[Zoltan Somogyi]

2021-04-20 17:02 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
> I suggest using a representation of timestampe based on Java's Instant
> type (java.time.Instant).  That should cover all of the points above,
> except readability.

The documentation of java.time.Instant provided by the first few hits
in ddg was spectacular in its uselessness.  My guess is that the getLong
method gets the seconds since the epoch, but "documentation" such as
"getLong(TemporalField field)	This method gets the value of the specified
field from this instant as along (sic)" does not do anything to confirm this
in my mind: what field is specified, what it is specified by, and what is
the f*cking *meaning* of this field?

> In Mercury, that would be something like the following:
> 
>     :- type timestamp
>          --->   timestamp(
>                     seconds :: int64,  % Seconds from the epoch.
>                     nanos   :: uint32  % [0, 999,999,999]
>                 ).
> 
> where nanos is the number of nanoseconds further along the time line
> from the seconds field.
> 
> This will work with clocks of resolutions from a second down to
> nanosecond resolution clocks (i.e it will be portable).
> (I think ISO 8601 has readable represention of this format, e.g.
> 2021-04-20T11:07:22.956087, but for this use case you could probably
> just write the raw components of the timestamp and be done with it.)

What I propose to do is to switch the timestamp representation
to the one you have above *with* an additional field containing
the current string representation of yyyy mm dd hh mm ss.
For now, to make the transition simpler, the seconds and nanos
will always be zeroes, and the checking code will pay attention
to the string, as it does now. Then we can start writing out
meaningful seconds and nanos (for which I think I will need help
from you or Peter for the non-Unix, non-C backends), and later
still, switch to using them to make decisions, keeping the string
representation only as an aid to debugging the smart recompilation
system itself.

Any objections to this plan?

Zoltan.