On 2024-04-09 18:06, Sam James wrote:
> Nick poses that a specific combination of tools is what is tested and
> anything else invalidates it. But how does this work when building on
> a system that was never tested on, or with different flags, or a
> different toolchain?
>
> It's reasonable to say
On 4/9/24 1:06 PM, Eric Blake wrote:
> It does, since callable objects exist as first class citizens. For
> example:
Ah, I see. Thanks for the examples.
Collin
Sam James replied to Bruno Haible who cited Nick Bowler:
> >> If I distribute a release package, what I have tested is exactly what is
> >> in that package. If you start replacing different versions of m4 macros,
> >> or use some distribution-patched autoconf/automake/libtool or whatever,
> >>
Bruno Haible writes:
> Nick Bowler wrote:
>> If I distribute a release package, what I have tested is exactly what is
>> in that package. If you start replacing different versions of m4 macros,
>> or use some distribution-patched autoconf/automake/libtool or whatever,
>> then this you have
On Tue, Apr 09, 2024 at 12:35:27PM -0700, Collin Funk wrote:
> Yes, I see what you mean. I very much prefer the 'moduleFilter' idea.
> It would allow us to remove a lot of the repetitive conditionals. Now
> I just have to figure out how to do that. If only Python had function
> pointers...
It
On 4/9/24 12:04 PM, Bruno Haible wrote:
> According to
> https://stackoverflow.com/questions/2829528/whats-the-scope-of-a-variable-initialized-in-an-if-statement
> it is perfectly OK to initialize a variable 'solution' in various 'if'
> branches.
>
> The warning apparently comes from the data
Hi Collin,
> In GLEmiter.autoconfSnippets I see many warnings that a 'solution'
> variable may be unbound when it is used.
>
> if solution: # Solution may be unbound here.
> emit += self.autoconfSnippet(module, toplevel,
>
In GLEmiter.autoconfSnippets I see many warnings that a 'solution'
variable may be unbound when it is used.
if solution: # Solution may be unbound here.
emit += self.autoconfSnippet(module, toplevel,
disable_libtool,
On 4/9/24 9:32 AM, Bruno Haible wrote:
> Thanks, applied. Also I removed the outdated/silly comment here:
>
> self.avoids = set() # Avoids
Haha, yes I guess it doesn't really explain much. It was small enough
to not bother me so I left it.
There is a few others like that in
Collin Funk wrote:
> Patch 0001 removes the unused functions. Patch 0002 turns avoidlist
> into a set.
Thanks, applied. Also I removed the outdated/silly comment here:
self.avoids = set() # Avoids
Bruno
Hi Bruno,
On 4/9/24 5:48 AM, Bruno Haible wrote:
> OK, fine with me: there are no accessors for inc_all_direct_tests and
> inc_all_indirect_tests either.
Patch 0001 removes the unused functions. Patch 0002 turns avoidlist
into a set.
CollinFrom eb0dcffdf06a59f2d71010ce2030ed2d583f6500 Mon Sep
I wrote:
> This patch does it and thus fixes the test failures on Linux and NetBSD.
Well, it fixes them only when not optimizing. With -O2, I see the
same miscompilation with gcc as with clang. This patch works around it.
2024-04-09 Bruno Haible
totalorder, totalorderf: Avoid
Hi Collin,
> This patch removes the GLModuleTable.__getitem__ function and changes
> the dictionary-like indexing of the GLModuleTable objects to normal
> function calls.
Makes sense: This dictionary-like indexing makes sense for GLConfig
(for reading and parsing the gnulib-cache.m4 file, and
On OpenBSD 7.5/i386, the two tests still fail, except when compiling
without optimization (e.g. with CFLAGS="-ggdb").
So, it's a compiler optimization bug, as can be seen by the code
generated by the OpenBSD compiler (a clang 16.0.6 derivative).
Cf. the attached totalorderf.O0.s,
On NetBSD 10.0/i386 and OpenBSD 7.5/i386, I see these test failures:
FAIL: test-totalorder
=
Failed: i=0 j=1
Failed: i=1 j=0
Failed: i=12 j=13
Failed: i=13 j=12
FAIL test-totalorder (exit status: 1)
FAIL: test-totalorderf
==
Failed: i=0 j=1
Failed: i=1
This patch fixes a copy mistake.
2024-04-09 Bruno Haible
totalorder tests: Fix signature test.
* tests/test-totalorder.c: Test the signature of totalorder, not
totalorderf.
diff --git a/tests/test-totalorder.c b/tests/test-totalorder.c
index fc473a251d..77926e4a5f
This patch removes the GLModuleTable.__getitem__ function and changes
the dictionary-like indexing of the GLModuleTable objects to normal
function calls.
I mentioned some of my reasoning here:
https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00113.html
GLConfig has the
17 matches
Mail list logo
