Copy-on-write strings and mutation-sharing strings

Copy-on-write strings and mutation-sharing strings

[Marius Vollmer]

Hi,

CVS HEAD now has copy-on-write strings and also mutation-sharing
strings.

Test cases are still missing, so go crazy and try to break them!

(The motivation for doing this now is that they make symbol->string
efficient and we thus don't need an extra set of functions for
converting symbols to C strings.  Of course, they are a nice feature
in general and much of the work needed for cow-strings is useful when
properly supporting Unicode later.)

>From the NEWS:

** There is now support for copy-on-write substrings and
   mutation-sharing substrings.

Two new procedures are related to this: substring/shared and
substring/copy.  See the manual for more information.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Copy-on-write strings and mutation-sharing strings

[Kevin Ryde]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>
> Test cases are still missing, so go crazy and try to break them!

I applied a fix to mkstemp! since it needs to modify it's input
string.  This crept in with the locale_string business.  You can check
if it's right.  New test case in posix.test too.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Copy-on-write strings and mutation-sharing strings

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> I applied a fix to mkstemp! since it needs to modify it's input
> string.

Right, thanks!

> This crept in with the locale_string business.  You can check if
> it's right.  New test case in posix.test too.

The fix is not entirely correct, since mkstemp expects a
null-terminated string but scm_i_strings_writable_chars isn't
guaranteed to give you one.  

[ Also, mkstemp should get a string in the current locale encoding,
  but the internal encoding of Guile might differ from that in the
  future.  Much work needs to be done anyway when that happens, but
  when can get mkstemp! right now, we should.
]

I fixed this by copying the modified template back into the SCM
string.  Please check.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Copy-on-write strings and mutation-sharing strings

[Kevin Ryde]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>
> null-terminated string but scm_i_strings_writable_chars isn't
> guaranteed to give you one.  

Ah.  You could put a comment about that with that function if you like
:-).

> [ Also, mkstemp should get a string in the current locale encoding,
>   but the internal encoding of Guile might differ from that in the
>   future.

Yes, I was too slack.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Copy-on-write strings and mutation-sharing strings

[Kevin Ryde]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>
> go crazy and try to break them!

The build script (the scheme bit, not any C code) in the guile-gtk-1.2
cvs exposes some breakage.  It bombs in a string-ref, looking like
taking a substring has caused truncation of the originating string,
maybe.

Changing scm_substring to use scm_i_substring_copy makes it better, if
that helps suggest a cause.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Copy-on-write strings and mutation-sharing strings

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>>
>> go crazy and try to break them!
>
> The build script (the scheme bit, not any C code) in the guile-gtk-1.2
> cvs exposes some breakage.  It bombs in a string-ref, looking like
> taking a substring has caused truncation of the originating string,
> maybe.

Now that is embarassing!  I got the substring operation totally wrong,
not taking into account that the substringed string might itself be a
substring.

I don't have time right now to fix it, but this is so embarrasing, I
must start blathering right away about how embarassing it is... should
be fixed today.

A simple test case is:

    guile> (substring (substring "0123456789" 3) 0 4)
    "0123"

The second substring gets a string with STRING_START != 0, which is
totally ignored.  Also mutation-sharing substrings would crash Guile,
as in:

    guile> (substring (substring/shared "0123456789" 3) 0 4)
    "'\x02
    \x00"

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Copy-on-write strings and mutation-sharing strings

[Kevin Ryde]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>
> substring/shared

Can srfi-12 substring/shared just be a re-export of the core binding,
or is it subtly different?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Copy-on-write strings and mutation-sharing strings

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:
>>
>> substring/shared
>
> Can srfi-12 substring/shared just be a re-export of the core binding,
> or is it subtly different?

It can be a re-export.

I'm putting srfi-13 into the core as an experiment, and when
everything works out, there will be only one substring/shared.  (The
main problem with putting srfi-13 into the core is the C API...)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel