l...@gnu.org (Ludovic Courtès) writes:
> Hello Mark,
>
> Mark H Weaver skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>> Anyway, it seems that before, you couldn’t get any encoding error for
>>> scm_from_stringn ("", "SOME-ENCODING"), whereas now you can.
>>
>> Good point. I just committe
Hello Mark,
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>> Anyway, it seems that before, you couldn’t get any encoding error for
>> scm_from_stringn ("", "SOME-ENCODING"), whereas now you can.
>
> Good point. I just committed a change to avoid this.
Cool, thanks for the ins
David Kastrup writes:
> Mark H Weaver writes:
>
>> I went ahead and committed this optimization. Empty substrings are now
>> always freshly allocated, and never hold a reference to the original
>> stringbuf.
>
> Why would they need an allocation at all? They don't contain
> characters.
It is
Mark H Weaver writes:
> Mike Gran wrote:
>>> Right now it seems that zero-length shared substring of a wide string is
>>> wide. A zero-length substring still shares the stringbuf of the
>>> original string.
>> [...]
>>> What do you think about that? Do zero-length substrings need to
>>> still
Mike Gran wrote:
>> Right now it seems that zero-length shared substring of a wide string is
>> wide. A zero-length substring still shares the stringbuf of the
>> original string.
> [...]
>> What do you think about that? Do zero-length substrings need to
>> still share stringbufs with their pare
Mike Gran writes:
>> From: Ludovic Courtès
>> A related question: can we have both narrow and wide empty strings?
>
> The intention is that a string is encoded as wide only if it can't
> be encoded as narrow. So _newly created_ empty strings should only be narrow.
>
> Right now it seems that
> From: Mark H Weaver
>> What do you think about that? Do zero-length substrings need to
>> still share stringbufs with their parent strings?
>
> I think the answer is: no they don't, and avoiding that might be a
> worthwhile optimization, mainly to avoid needlessly holding a reference
> to a
I definitely agree that the "Guile Modules" / "Standard Library"
distinction doesn't make sense. I never knew why it was that way until
I saw this email.
It's not so obvious to me how things should be organized, but I think
base namespace / modules is a pretty natural distinction. The
distinction
Mike Gran writes:
> Right now it seems that zero-length shared substring of a wide string is
> wide. A zero-length substring still shares the stringbuf of the
> original string.
[...]
> What do you think about that? Do zero-length substrings need to
> still share stringbufs with their parent str
l...@gnu.org (Ludovic Courtès) writes:
> Anyway, it seems that before, you couldn’t get any encoding error for
> scm_from_stringn ("", "SOME-ENCODING"), whereas now you can.
Good point. I just committed a change to avoid this.
> A related question: can we have both narrow and wide empty strings?
> From: Ludovic Courtès
> I just noticed that there are i18n.test failures on Hydra, which point
> at this commit:
>
> http://hydra.nixos.org/build/1790097
>
> I think this is under the C locale, but I haven’t been able to reproduce
> it yet.
>
> Anyway, it seems that before, you couldn’t get
> From: Ludovic Courtès
> A related question: can we have both narrow and wide empty strings?
The intention is that a string is encoded as wide only if it can't
be encoded as narrow. So _newly created_ empty strings should only be narrow.
Right now it seems that zero-length shared substring of
Hello Mark!
Mark H Weaver skribis:
> I wrote:
>> 3. Make scm_nullstr into a mutable string. After all, it can't be
>>changed anyway, and the _only_ reference to it is from
>>scm_from_stringn, so the result should always be mutable.
>
> For the record: my statement above was in error; sc
13 matches
Mail list logo
