Martin [gz] wrote:
> So, Inno also create another problem for us by rounding the timestamp to the nearest even second, in the name of FAT compat:
> <http://www.jrsoftware.org/ishelp/topic_setup_timestamprounding.htm>
>
> Disabling that as well should finally fix this bug... for everyone
> except those still on FAT filesystems. To cover them as well, we'd have
> to round the timestamps of all plugin py files prior to bytecode
> compilation.
>
Why does that matter, given that the stored value in the .pyo is an
integer? Is it because it rounds rather than truncates?
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin [gz] wrote: www.jrsoftware. org/ishelp/ topic_setup_ timestamproundi ng.htm>
> So, Inno also create another problem for us by rounding the timestamp to the nearest even second, in the name of FAT compat:
> <http://
>
> Disabling that as well should finally fix this bug... for everyone
> except those still on FAT filesystems. To cover them as well, we'd have
> to round the timestamps of all plugin py files prior to bytecode
> compilation.
>
Why does that matter, given that the stored value in the .pyo is an
integer? Is it because it rounds rather than truncates?
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkw vuhoACgkQJdeBCY SNAAPEuACfY/ Zp1F0mhti7UZSjY X/VigHl nGPCsP1IFUJ6ubq A2sdlM+
Hv0An0TC5/
=LFYc
-----END PGP SIGNATURE-----