Re: aap 1.090 - issues with DEFAULTCHECK=newer

Pavol Juhas <[email protected]> Wed, 12 Dec 2007 16:25:07 -0500
Newsgroups gmane.comp.tools.aap.devel
Message-ID <[email protected]>
On Wed, Dec 12, 2007 at 09:52:41PM +0100, Bram Moolenaar wrote:
> 
> Pavol Juhas wrote:
> 
> > > > I have recently tried to use DEFAULTCHECK=newer in my aap recipe
> > > > and found a couple of issues.  First, aap 1.090 would crash with this
> > > > setting, because python getmtime function returns float, and
> > > > a string representation of float cannot be converted to long [e.g.,
> > > > long("0.0") raises an exception].
> > > > 
> > > > It was very simple to fix this, see the attached patch,
> > > 
> > > Thanks.  I guess an older verion of Python allowed this.
> > 
> > I just realized it may be better to store file modification times
> > as floats instead of longs.  Python float is large enough to avoid
> > any overflow issues and it is the same type as returned by built-in
> > getmtime().  Float would also prevent any loss of precision
> > should getmtime() resolution become smaller than 1 second in the future.
> > 
> > So the previous patch should rather say
> >      atime = float(atime)
> > instead of
> >      atime = long(float(atime))
> 
> The times are stored as an integer in the signature file.  Changing that
> will cause an upgrade of Aap to trigger a lot of rebuilding.
> 
> Nevertheless, if one builds quick it's possible that two things happen
> within a second.  So sub-second timestamps would be preferred.

Well, the times already get stored as floats (at least some
of them) in the signature - that's why unpatched aap crashes for
DEFAULTCHECK=newer.  In older versions of python getmtime() returned
int, but as of 2.3 it returns float (still an integer value - at
least on my computer, but represented as float).  The time is written
as a string to the signature file.  Unpatched aap tries to convert
times from signature file to long, but fails, because "1.0" is not
valid long representation.  Anyway, the large rebuilding is not
likely, because comparison of integers should work the same regardless
of their representation, i.e., long(1) == int(1) == float(1).

Pavol

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace