lmi
[Top][All Lists]
Advanced

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

Re: [lmi] [lmi-commits] odd/test_all_products 53f77a1 2/2: Test every pr


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] odd/test_all_products 53f77a1 2/2: Test every product in every jurisdiction
Date: Mon, 16 Nov 2020 00:55:36 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 11/15/20 11:48 PM, Vadim Zeitlin wrote:
> On Sun, 15 Nov 2020 16:39:13 -0500 (EST) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: odd/test_all_products
[...]
> GC>     This implementation is casual, but it's needed now for acceptance
> GC>     testing of changes in proprietary product files. A careful
> GC>     reimplementation may be added to 'master' later. Beware: this takes
> GC>     about ten minutes with about 130 products, on an E5-2630 v3 machine.
> GC>     Threading would be most beneficial.
> 
>  Is this last sentence a call to action or just a general observation?

At the time I wrote it, I hadn't decided. But now I've looked into it a
little, and concluded that in the next couple of months I can't spend
the time it would take to figure it out myself. So, if it's pretty easy
for you, then please show me the way; otherwise, I can either
 - postpone further "lingo" work (probably not possible), or
 - accept the slowness, or
 - spend time factoring this into a one-product-at-a-time function,
   so that it can run as a set of processes rather than threads:
     lmi_cli_shared --test_one_product=sample
     lmi_cli_shared --test_one_product=sample2naic
     ...
     lmi_cli_shared --test_one_product=another_product
   and then run those processes in parallel, e.g. via 'make'.
which in practice means I'd accept the slowness.


reply via email to

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