On Fri 13 Jan 2012 17:39, Mark H Weaver writes:
> Should we defend the legitimacy of this optimization, and ask the R7RS
> working group to include explicit language specifying that empty
> strings/vectors need not be freshly allocated?
It's a worthwhile question IMO. I'll mail scheme-reports.
Marijn writes:
> On 13-01-12 17:39, Mark H Weaver wrote:
>> David Kastrup writes:
>>
>> However, my mind is not set in stone on this. Does anyone else
>> here agree with David? Should we defend the legitimacy of this
>> optimization, and ask the R7RS working group to include explicit
>> langu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13-01-12 17:39, Mark H Weaver wrote:
> David Kastrup writes:
>
> However, my mind is not set in stone on this. Does anyone else
> here agree with David? Should we defend the legitimacy of this
> optimization, and ask the R7RS working group to in
Mark H Weaver writes:
> David Kastrup writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi Mark,
>>>
>>> Mark H Weaver skribis:
>>>
What do other people think?
>>>
>>> As you said, R5RS makes it clear that there can be several (in the sense
>>> of eq?) empty strings, so I think wh
David Kastrup writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mark,
>>
>> Mark H Weaver skribis:
>>
>>> What do other people think?
>>
>> As you said, R5RS makes it clear that there can be several (in the sense
>> of eq?) empty strings, so I think what you did is the right thing.
>
> Si
l...@gnu.org (Ludovic Courtès) writes:
> Hi Mark,
>
> Mark H Weaver skribis:
>
>> What do other people think?
>
> As you said, R5RS makes it clear that there can be several (in the sense
> of eq?) empty strings, so I think what you did is the right thing.
Since it uses the same verbiage with reg
Hi Mark,
Mark H Weaver skribis:
> What do other people think?
As you said, R5RS makes it clear that there can be several (in the sense
of eq?) empty strings, so I think what you did is the right thing.
Thanks!
Ludo’.
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
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
18 matches
Mail list logo
