Hi Collin,
> Would you prefer one patch with all of the changes or one per file?
One patch with all the changes of the same kind, please.
Whereas different kinds of refactorings belong in different patches,
I would say.
> Since it is just you and I testing we can leave it as is. In the
> future
Hi Bruno,
On 3/26/24 5:18 PM, Bruno Haible wrote:
> Yes. Sounds good.
Would you prefer one patch with all of the changes or one per file?
I'm happy either way, so whatever would make it easier for you if you
want to review the changes.
> I'm reluctant to add a dependency on yet another environme
Hi Collin,
> > Feel free to do so. Either in GLFileSystem only, or globally - as you like.
>
> I would prefer to do it globally. I find they make it easier to
> reference code. Since we have *some* of the information in docstrings,
> I would just remove those and turn them into actual type hints.
Hi Bruno,
On 3/26/24 3:19 PM, Bruno Haible wrote:
> Feel free to do so. Either in GLFileSystem only, or globally - as you like.
I would prefer to do it globally. I find they make it easier to
reference code. Since we have *some* of the information in docstrings,
I would just remove those and turn
Hi Collin,
> How does this patch look?
This one looks good. Applied. Thanks!
> An unintended side effect is that the './configure.ac' and
> 'configure.ac' disagreement in that gnulib-comp.m4 comment is also
> fixed. The GLConfig.py change is not needed.
Nice.
> On 3/26/24 4:46 AM, Bruno Haible
Hi Bruno,
On 3/26/24 4:46 AM, Bruno Haible wrote:
> The original code looked out for multiple AC_PREREQ invocations and
> took the maximum. For example:
> AC_PREREQ([2.64])
> AC_PREREQ([2.69])
> AC_PREREQ([2.66])
> must be treated as if it were
> AC_PREREQ([2.69])
> The
Hi Collin,
> The GLFileSystem.py file returns many tuples which is very much making
> me want to add type hints. It is easier to glance at and understand
> that way, in my opinion.
Feel free to do so. Either in GLFileSystem only, or globally - as you like.
> Right now GLFileSystem.lookup returns
Hi Bruno,
On 3/26/24 5:20 AM, Bruno Haible wrote:
> Regarding the 'modules' subdirectory: When I see you replacing 2 lines of code
> with 8 lines of code, and especially searching for a 'modules' file name
> component, I wonder whether there's no simpler solution.
> Namely, a module of name NAME c
Paul Eggert wrote:
> > It doesn't work because it takes only 32 samples of current_timespec ().
> > In order to work reliably it would need 10 million samples.
>
> Thanks for the fix. My puzzlement was more why one needs 10 million
> samples. Perhaps it's possible to alter the test somewhat so th
On 3/26/24 05:16, Bruno Haible wrote:
It doesn't work because it takes only 32 samples of current_timespec ().
In order to work reliably it would need 10 million samples.
Thanks for the fix. My puzzlement was more why one needs 10 million
samples. Perhaps it's possible to alter the test somewh
Hi Collin,
> But, atleast we are not back to taking 20 seconds to run ./test-all.sh.
It's good that you are looking at the execution times. These __eq__
etc. methods are apparently heavily used.
> It seems that Python has an index() function to find the first
> occurrence of an item in a list, b
Hi Collin,
> > One point needs attention, still: In gnulib-tool.sh the code looks at
> > configure.ac and, if that does not exist, at configure.in:
> > ...
> > Whereas in main.py configure.in is not looked at:
> > ...
Thanks for getting back to this item.
But the patch does way too much, and doe
Paul Eggert wrote:
> > What shall we do with this one? Override gettime_res() to return 1 ns
> > instead of 5 ns? Or adapt the unit test?
>
> Perhaps overriding is best. I'm a bit puzzled why the current code
> doesn't work, though.
It doesn't work because it takes only 32 samples of current_tim
13 matches
Mail list logo
