Hi Everyone/Bruno,
I think Bruno and I were talking about this for a while back in 2018
or 2019. Gnulib was failing one self test due to floats on OS X 10.5
on PowerPC
Here is the OS X man page on floats:
I wrote:
> I should better revert yesterday's patch, and instead,
> in the table show the guaranteed average performance
> gl_list_get_first
> gl_list_get_last
> gl_list_set_first
> gl_list_set_last
> gl_list_remove_first
> gl_list_remove_last
> where these 6 functions are defined
Hi Akim,
> > Le 2 mai 2020 à 17:31, Bruno Haible a écrit :
> >
> > +BISON_LOCALEDIR="${localedir}"
> > +AC_ARG_WITH([bison-prefix],
> > + [[ with-bison-prefix=DIR search for bison's runtime data in
> > DIR/share]],
>
> You meant --with-bison-prefix here. Or use AS_HELP_STRING.
Hi Bruno,
> Le 2 mai 2020 à 10:45, Bruno Haible a écrit :
>
> Hi Akim,
>
>> I was suggesting that the macro _itself_ could just
>> run bison on a file with the %require.
>
> This sounds better than the existing code that runs '--version'.
>
> What about users who have non-released versions
Bruno,
Thanks for this!
> Le 2 mai 2020 à 17:31, Bruno Haible a écrit :
>
> +BISON_LOCALEDIR="${localedir}"
> +AC_ARG_WITH([bison-prefix],
> + [[ with-bison-prefix=DIR search for bison's runtime data in
> DIR/share]],
You meant --with-bison-prefix here. Or use AS_HELP_STRING.
Hi Bruno,
[...]
> > I don't see, however, to implement the function dealing with
> > end of the list in O(1) behavior when the underlying data structure is
> > a linked list.
>
> The LINKED list implementation is a doubly-linked list, and the functions
> get_at, set_at, or remove_at are
Hi Marc,
> Okay; I agree that a separate stack or FIFO module can make more
> sense; in particular when it only has to deal with a single
> implementation of an underlying data structure. At the moment I do
> have other work to finish first, but maybe I will find some time in
> the near future
Hi Akim,
> Someone suggested that it would be nice to force a given value
> to BISON_LOCALEDIR in ./configure. Are you interested in that?
> I'm not a huge fan of adding tons of options to configure, I would
> rather have this macro take incoming values of $BISON_LOCALEDIR,
> and of course
Dear gnulibers,
Denis reported a failure in Bison's test suite which is related to the handling
of mb chars on Cygwin (https://lists.gnu.org/r/bug-bison/2020-05/msg3.html).
Bruno fixed a similar issue (on the same test case actually) on Solaris some
time ago, and demonstrated it with the
Hi Bruno,
[...]
> The gl_list_node_t type, in the 'list' interface so far, is used in
> operations that work on a single position. Except for the functions
> gl_list_next_node and gl_list_previous_node, which intentionally
> walk from one node to a neighbour node. Having a function that
> does
Hi Marc,
> I didn't mean that gl_list_remove_last
> should return the just deleted node but the node of the element that
> is now the last one (the respectively first one for
> gl_list_remove_first) after the removal.
The gl_list_node_t type, in the 'list' interface so far, is used in
operations
Hi Akim,
> I was suggesting that the macro _itself_ could just
> run bison on a file with the %require.
This sounds better than the existing code that runs '--version'.
What about users who have non-released versions installed?
I think the %require solution will be on par with the --version
Hi Paul,
> into the attached patch.
Looks good overall. Just a few small remarks:
1)
> +#ifndef _GL_ATTRIBUTE_GCC_GL_H
> +#define _GL_ATTRIBUTE_GCC_GL_H
> +#ifndef _GL_ATTRIBUTE_GCC_H
> +#define _GL_ATTRIBUTE_GCC_H
Why not align the double-inclusion guard macros with the file names
(which
Hi Bruno,
thanks again very much!
Am Sa., 2. Mai 2020 um 02:07 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > This is a feature request to add an operation
> >
> > extern gl_list_node_t gl_list_remove_last (gl_list_t list)
> >
> > to the list/xlist interface.
> >
> > This
14 matches
Mail list logo
