lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Fwd: [lmi-commits] master 066d739f 3/3: Update mortality tables fo


From: Greg Chicares
Subject: [lmi] Fwd: [lmi-commits] master 066d739f 3/3: Update mortality tables for 'sample' product
Date: Sat, 14 May 2022 19:25:43 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0

[...I had inadvertently sent this to Vadim rather than to the mailing list...]

-------- Forwarded Message --------
Subject: Re: [lmi-commits] [lmi] master 066d739f 3/3: Update mortality tables 
for 'sample' product
Date: Sat, 14 May 2022 15:39:19 +0000
From: Greg Chicares <gchicares@sbcglobal.net>
To: Vadim Zeitlin <vadim@tt-solutions.com>

On 5/14/22 14:21, Vadim Zeitlin wrote:
> [I'm resending this message in a modified form directly as the original one
>  got somehow classified as spam by your ISP, so you shouldn't have received
>  its initial version -- but it should be in the mailing list archives
>  and the commits referenced here are also available in xanadu/fix-sample-md5
>  branch]

[I've subscribed to this mailing list with two addresses. One is
provided by my ISP, and the other by gmail. The gmail account did
receive your original message, through the mailing list. My ISP
account dropped both your directly-sent original and the copy from
the mailing list.

But when your email provider's company name contains an exclamation
point, what can you expect? The other day, they delivered some spam
that pretended to come from the US Postal Service, but when I tried
to forward it to CyberSafe@usps.gov, they blocked that, and forced
me off their server.]

> On Fri, 13 May 2022 20:13:15 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...]
> GC> commit 066d739fab21dfa17c63b2dbaa533c5e0fd267e3
[...]
> GC> -sample_archive   := lmi-data-20050618T1440Z.tar.bz2
> GC> +sample_archive   := lmi-data-20220511T0107Z.tar.bz2
[...]
>  I was surprised to see that this commit didn't update the sample archive
> MD5

Oh. Again, because the build was broken, I pushed an urgent commit
without testing it. Sorry.

> echo "e7f07133abfc3b9c2252dfa3b61191bc 
> */srv/cache_for_lmi/downloads/lmi-data-20220511T0107Z.tar.bz2" | md5sum 
> --check
> md5sum: WARNING: 1 computed checksum did NOT match

> and so there is no problem here -- except that the builds are broken.
[...]
> tar --extract --keep-old-files --bzip2 
> --directory=/opt/lmi/third_party/ad_hoc 
> --file=/srv/cache_for_lmi/downloads/lmi-data-20220511T0107Z.tar.bz2
> bzip2: (stdin) is not a bzip2 file.
[...]
> I've done this commit for testing only instead:

This is a classic "charlie foxtrot": creating multiple errors
while attempting to fix a single one. Rushing to commit more
urgent changes is likely to leave a Hydra with even more heads.
It sounds like you've made a testing-only commit that prevents
the build problem in CI, so I think you should rely on that
for the moment.

Now I rue that change. The question is whether rate tables should
be limited to eight decimals. I decided at first to impose that
limit, because
 - it's almost always enough in practice; and
 - redesigning "rate * amount" calculations is a complicated
     problem, and imposing a strict eight-decimal restriction
     made it easier to design a solution.
Now that I better understand the problem, and the range of
solutions that are wanted, I want to remove that restriction.
That means changing the rate tables again, after changing the
code, and testing everything thoroughly beforehand. For this
reason, it's especially good if you can just use a workaround
for the CI problem, for now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]