On 12.12.2012, at 20:49, Paul Eggert wrote:
> On 12/12/12 11:21, Jeremy Huddleston Sequoia wrote:
>> Can you please instead just '#define _DONT_USE_CTYPE_INLINE_ 1'
>
> I had considered that, but unfortunately as I understand it
> we'd still have problems when compiling C code
> with GCC in the
else has objections, they had 3 months time to voice them, after
all, and even if they still have some, then it shouldn't be a major issue to
adjust the code later on. Right?
Cheers,
Max
On 07.09.2012, at 19:39, Max Horn wrote:
> Dear Paul, all,
>
>
> On 06.09.2012, at 1
Dear Paul, all,
On 06.09.2012, at 12:39, Paul Eggert wrote:
> On 09/06/2012 11:03 AM, Max Horn wrote:
>
>> I proposed the exact same patch you proposed back in January.
>
> Ah, sorry, I was confused. Again. Ouch.
>
> Please let me try to summarize the situa
posed patch
> <http://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00319.html>
> would break gettext-based i18n of GNU programs on OS X; see
> <http://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00342.html>.
And I refuted those claims in
<http://lists.gnu.org/archiv
Hi there,
once again, I am begging the gnulib team to consider fixing an issue in the
locale code of gnulib which causes errors when using GNU sed on Mac OS X --
i.e. scrips (such as "git filter-branches") start failing when one installs GNU
sed 4.2.1, due to this bug in gnulib. Moreover, the c
[resending this email via another email, as there seems to have been a problem
the first time around...?]
Hi again,
On 23.06.2012, at 18:36, Paul Eggert wrote:
> On 06/23/2012 07:54 AM, Paolo Bonzini wrote:
>> I'm waiting for feedback from the Gnulib guys.
>
> Can you please summarize the issu
Hi again,
On 23.06.2012, at 18:36, Paul Eggert wrote:
> On 06/23/2012 07:54 AM, Paolo Bonzini wrote:
>> I'm waiting for feedback from the Gnulib guys.
>
> Can you please summarize the issue, the proposed fixes,
> and the pros and cons of each? The discussion has been
> spread out for so long th
Hi there,
I noticed that gnulib (almost) consistently misspells "Mac OS X" as "MacOS X".
Of course that's not really a problem, but since apparently some effort went
into correctly spelling the names of other OSes (e.g. FreeBSD, BeOS, ...) I was
wondering whether a patch that resolves this would
schrieb Max Horn:
> Hi again,
>
>
> Am 07.06.2012 um 14:07 schrieb Bruno Haible:
>
> [...]
>
>>
>>> But this is dangerous, because now UTF-8 is set but MB_CUR_MAX is 1
>>> and various parts of sed interpret "Rémi Leblond" as an invalid
>>
Hi again,
Am 07.06.2012 um 14:07 schrieb Bruno Haible:
[...]
>
>> But this is dangerous, because now UTF-8 is set but MB_CUR_MAX is 1
>> and various parts of sed interpret "Rémi Leblond" as an invalid
>> character sequence for a UTF-8 character set.
>
> Indeed, I can see how this inconsistenc
Dear Paul,
thank you for considering resolving this issue!
Am 06.06.2012 um 16:53 schrieb Paul Eggert:
> How about the following patch instead? Does it solve the problem?
Yes, that also solves the problem (I just tested it).
BTW, a very off-topic, very low importance remark: In your patch, a
PS: I should have clarified what Mac OS X version(s) I was talking about: The
data reported in my email was from Mac OS X 10.6.8. Tonight, I'll compare this
with a 10.5 machine of mine; and I could try get hold of a 10.4 machine, too,
though this may have to wait a few days. On the other hand, I
Dear all,
I subscribed to this list solely to respond to this thread, and hopefully help
iron out issues caused by installing GNU sed on Mac OS X (regressions in
behavior compared to the system's sed). My interest stems from that fact that I
am the maintainer of the GNU sed package in the Fink
13 matches
Mail list logo
