i guess we're frozen & stuff
Hello Guilers, Today's the 10th, we release on the 15th, ergo we're frozen. What does this mean? Well I think the dilly is that we shouldn't be pushing to master, except to fix things that don't work at all, and to update documentation, NEWS, etc. What if you don't have push access? Well give Guile a try with your programs, run some benchmarks against 1.9.1, give the tires a good kick. >From my part, I wrote a summary of what I've been up to here: http://wingolog.org/archives/2009/08/10/goto- Happy hacking! Andy -- http://wingolog.org/
Re: i guess we're frozen & stuff
> From: Andy Wingo > > Hello Guilers, Hi Andy, > > Today's the 10th, we release on the 15th, ergo we're frozen. > Hmmm. I should have been watching the clock. I've left master in an odd state w.r.t. strings and chars. The storage is available for non-8-bit strings and chars, but, nothing can be done with them. > What does this mean? Well I think the dilly is that we shouldn't be > pushing to master, except to fix things that don't work at all, and to > update documentation, NEWS, etc. Do test-suite tests count? > From my part, I wrote a summary of what I've been up to here: > http://wingolog.org/archives/2009/08/10/goto- Nice! Thanks, Mike
Re: i guess we're frozen & stuff
Hi Mike, On Mon 10 Aug 2009 23:08, Mike Gran writes: >> Today's the 10th, we release on the 15th, ergo we're frozen. > > Hmmm. I should have been watching the clock. I've left master in > an odd state w.r.t. strings and chars. The storage is available for > non-8-bit strings and chars, but, nothing can be done with them. Well, I think a certain amount of disrespect for temporal prescriptions is healthy. Should you manage to push something tomorrow that makes things monotonically more awesome, I don't think anyone would object :) The positive effect of this cyclic rhythm is that it allows us to coordinate our efforts -- we're managing our expectations. The corollary being, don't mess up Ludovic's expectations of a great release with a half-baked push :) >> What does this mean? Well I think the dilly is that we shouldn't be >> pushing to master, except to fix things that don't work at all, and to >> update documentation, NEWS, etc. > > Do test-suite tests count? Tests are welcome! Cheers, Andy -- http://wingolog.org/
Re: Unicode strings and symbols
Hey,
Mike Gran writes:
[...]
>> > +SCM_API void scm_charprint (scm_t_uint32 c, SCM port);
>>
>> This ought to be internal, no?
>
> Could be. A couple of the types are given their own print functions:
> scm_intprint and an scm_uintprint. Most types don't have their own
> print functions. Are int and uint given special treatment because of
> their radix term?
Dunno. Anyway, they're not really meant to be public either. Feel free
to make them internal as well, while you're at it. ;-)
>> > + (scm_t_wchar) (unsigned char) STRINGBUF_INLINE_CHARS (buf)[i];
>>
>> Is the double cast needed?
>
> Sort of. Unsigned char will successfully be implicitly cast to
> scm_t_wchar, so the scm_t_wchar term is just for clarity. The unsigned
> char term is definitely needed. Negative 8-bit chars are the upper half
> of the 8-bit charset (128 - 255). Casting them directly to scm_t_wchar
> may return 0xFF80 - 0x instead of 128-255. I don't have any
> problem removing the scm_t_wchar cast. Would you prefer that?
How about:
#define STRINGBUF_INLINE_CHARS(buf) \
((unsigned char *) SCM_CELL_OBJECT_LOC ((buf), 1))
and changing the caller to:
for (i = 0; i < len; i++)
mem[i] = (scm_t_wchar) STRINGBUF_INLINE_CHARS (buf)[i];
?
That would make the intent clearer to me.
> I put it in because that information needs to be available in the
> bytecode compiler. A slightly clearer name would probably be
> string-bytes-per-character, I suppose.
Agreed, let's take this name.
>> > +SCM_INTERNAL char *scm_to_stringn (SCM str, size_t *lenp,
>> > + const char *encoding,
>> > + enum iconv_ilseq_handler handler);
>>
>> I suppose this would eventually become public. What do you think?
>> Should we use a different type for HANDLER before that happens?
>
> The simplest thing would be to make some constants like
>
> scm_c_define ("STRING_ESCAPE", scm_from_int(iconveh_escape_sequence))
>
> Something similar is done in the scm_seek function's constants, such as
> SEEK_CUR.
It's a C API so Scheme-level constants don't matter.
I was wondering whether using `enum iconv_ilseq_handler' in the public
API would be a good idea because that means that public headers include
either the system's or GNU libiconv's (or some libunistring
header), in which case `guile.pc' must include the right `-I' flag, etc.
This may slightly complicate compilation of Guile apps. Another
downside is that Guile's API would be bound to the values and semantics
of `iconv_ilseq_handler', and bound to iconv.
One possibility to avoid th would be to define our own type similar to
`iconv_ilseq_handler'.
Thanks,
Ludo'.
Re: i guess we're frozen & stuff
Mike Gran writes: > Hmmm. I should have been watching the clock. I've left master in > an odd state w.r.t. strings and chars. The storage is available for > non-8-bit strings and chars, but, nothing can be done with them. I don't think it's a serious issue. Just a small comment: --8<---cut here---start->8--- scheme@(guile-user)> (%string-dump "foo") $1 = ((string . "foo") (start . 0) (length . 3) (shared . #f) (stringbuf . #) (stringbuf-chars . "foo") (stringbuf-length . 3) (stringbuf-shared . #f) (stringbuf-inline . #t) (stringbuf-wide . #f)) --8<---cut here---end--->8--- The stringbuf object cannot be printed (as shown above), has no public type predicate, etc., so I think we'd better not return it to Scheme code. Can you change that in `%string-dump'? Note for later: it'd be great if we had micro-benchmarks to compare the former and the new string implementations (on Latin-1 strings, that is), and to compare Latin-1 and wide strings in the new implementation. Thanks, Ludo'.
