frozen!

frozen!

[Andy Wingo]

Greetings Guilers,

It seems that the moon has rolled around again! Meaning, of course, that
Guile is frozen. Same thing as usual: testing, regression fixes,
documentation, etc.

I haven't discussed this with Ludovic yet, but maybe we can relax this
freeze slightly. This cycle has been a bit less hectic, Mike having
gotten most of his stuff in, my having been on holiday, etc; so, I would
like to propose that anyone who has a branch that they want in next
week's 1.9.4, please propose it now. We'll take a look at them and merge
(or not) by Friday.

Feedback welcome, of course :)

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: frozen!

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> I haven't discussed this with Ludovic yet, but maybe we can relax this
> freeze slightly. This cycle has been a bit less hectic, Mike having
> gotten most of his stuff in, my having been on holiday, etc; so, I would
> like to propose that anyone who has a branch that they want in next
> week's 1.9.4, please propose it now. We'll take a look at them and merge
> (or not) by Friday.

None such from me.  It seems there are a few important bugs outstanding,
so I will try to work on those for 1.9.4.

Regards,
        Neil

Re: frozen!

[Mike Gran]

> From: Andy Wingo <wingo@pobox.com>
> Subject: frozen!

I have three changes I'd like to put in for this
release.  One is a new feature.

I need to roll back the changes made to i18n.c
that made locale-specific case conversion of strings
work on GNU but break on Darwin.  Locale-specific
case conversion of strings works, but only when
the locale is set using setlocale.

Also, I need to revert the regexp.test which seems
to be broken on Darwin but work elsewhere.

And I want to put in aliases for some Emacs
"coding:" declarations.

I'll try to get that in over the next couple
of days.

-Mike 

Re: frozen!

[Ludovic Courtès]

Hello,

Mike Gran <spk121@yahoo.com> writes:

> I need to roll back the changes made to i18n.c
> that made locale-specific case conversion of strings
> work on GNU but break on Darwin.

Yes, this one is important IMO.

Thanks,
Ludo’.

Re: frozen!

[Ken Raeburn]

On Oct 6, 2009, at 17:35, Mike Gran wrote:
> I need to roll back the changes made to i18n.c
> that made locale-specific case conversion of strings
> work on GNU but break on Darwin.  Locale-specific
> case conversion of strings works, but only when
> the locale is set using setlocale.

Thanks.  Though perhaps you could just explicitly test for GNU libc,  
if the glibc structures are stable?

> Also, I need to revert the regexp.test which seems
> to be broken on Darwin but work elsewhere.

Is it only Darwin where it's broken?  It's kind of hard to tell from  
some of the email where testing is actually occurring.  I assume the  
bulk of it is on GNU/Linux systems, plus Greg's occasional tests on  
NetBSD and mine on the Mac....

If you think the regexp.test issues are likely to be Darwin-specific,  
I can try to dig into them a bit more.

Otherwise, I'll wait for your changes to go in, and see what else I  
can break. :-)
I think my library-path issue is still open, despite Andy's attempted  
fix...

Ken

Re: frozen!

[Ludovic Courtès]

Ken Raeburn <raeburn@raeburn.org> writes:

> On Oct 6, 2009, at 17:35, Mike Gran wrote:
>> I need to roll back the changes made to i18n.c
>> that made locale-specific case conversion of strings
>> work on GNU but break on Darwin.  Locale-specific
>> case conversion of strings works, but only when
>> the locale is set using setlocale.
>
> Thanks.  Though perhaps you could just explicitly test for GNU libc,
> if the glibc structures are stable?

There's no reason why they should be stable, they're internal.  Glibc's
<xlocale.h> reads:

--8<---------------cut here---------------start------------->8---
/* Structure for reentrant locale using functions.  This is an
   (almost) opaque type for the user level programs.  The file and
   this data structure is not standardized.  Don't rely on it.  It can
   go away without warning.  */
typedef struct __locale_struct
--8<---------------cut here---------------end--------------->8---

Maybe, until a better solution is found we could use:

  AC_CHECK_MEMBER([struct __locale_struct.__name] ...)

But we should aim for a more robust solution.

Thanks,
Ludo'.

Re: frozen!

[Ken Raeburn]

On Oct 6, 2009, at 17:35, Mike Gran wrote:
> Also, I need to revert the regexp.test which seems
> to be broken on Darwin but work elsewhere.

Hi, Mike.  I've done a little more digging...

The code in regexp.test tries the suffixes ".ISO-8859-1" and  
".iso88591" when selecting locale names.  I take it that means there's  
inadequate standardization on the naming of encodings across systems?   
Well, when I make it try ".ISO8859-1", most of the tests pass on Mac  
OS X.  The "string of all chars" ones still fail; I'm looking into  
those.

Ken

Re: frozen!

[Ken Raeburn]

On Oct 9, 2009, at 03:54, Ken Raeburn wrote:
> The code in regexp.test tries the suffixes ".ISO-8859-1" and  
> ".iso88591" when selecting locale names.  I take it that means  
> there's inadequate standardization on the naming of encodings across  
> systems?  Well, when I make it try ".ISO8859-1", most of the tests  
> pass on Mac OS X.  The "string of all chars" ones still fail; I'm  
> looking into those.

The "string of all chars" test calls setbinary before performing the  
test.  The documentation for setbinary says it sets the encoding for  
current input, output and error streams to ISO-8859-1, as well as  
making it the default for new ports.  Is that supposed to affect make- 
regexp and regexp-exec as well?

If I replace the call with a call to set-latin-1 (modified to try  
".ISO8859-1", as described above), which sets the locale, the test  
passes on the Mac.

Ken

Re: frozen!

[Mike Gran]

On Sat, 2009-10-10 at 10:43 -0400, Ken Raeburn wrote:
> On Oct 9, 2009, at 03:54, Ken Raeburn wrote:
> > The code in regexp.test tries the suffixes ".ISO-8859-1" and  
> > ".iso88591" when selecting locale names.  I take it that means  
> > there's inadequate standardization on the naming of encodings across  
> > systems?  Well, when I make it try ".ISO8859-1", most of the tests  
> > pass on Mac OS X.  The "string of all chars" ones still fail; I'm  
> > looking into those.
> 
> The "string of all chars" test calls setbinary before performing the  
> test.  The documentation for setbinary says it sets the encoding for  
> current input, output and error streams to ISO-8859-1, as well as  
> making it the default for new ports.  Is that supposed to affect make- 
> regexp and regexp-exec as well?
> 
> If I replace the call with a call to set-latin-1 (modified to try  
> ".ISO8859-1", as described above), which sets the locale, the test  
> passes on the Mac.

Excellent.  I pushed that.

> 
> Ken

-Mike

setbinary

[Ludovic Courtès]

Hi,

Ken Raeburn <raeburn@raeburn.org> writes:

> The documentation for setbinary says it sets the encoding for
> current input, output and error streams to ISO-8859-1, as well as
> making it the default for new ports.

This reminds me that I proposed renaming/splitting ‘setbinary’ (see
http://thread.gmane.org/gmane.lisp.guile.devel/9300).

Mike: could you eventually look into it? (that doesn’t have to be done
for 1.9.4.)

Thanks,
Ludo’.

Re: frozen!

[Andy Wingo]

Hi Mike,

On Tue 06 Oct 2009 23:35, Mike Gran <spk121@yahoo.com> writes:

>> From: Andy Wingo <wingo@pobox.com>
>> Subject: frozen!
>
> I need to roll back the changes made to i18n.c
> that made locale-specific case conversion of strings
> work on GNU but break on Darwin.  Locale-specific
> case conversion of strings works, but only when
> the locale is set using setlocale.
>
> Also, I need to revert the regexp.test which seems
> to be broken on Darwin but work elsewhere.

So I think you got to these, no?

> And I want to put in aliases for some Emacs
> "coding:" declarations.

And perhaps this will land for 1.9.5 :)

Thanks (again!) for all of the great work!

Peace,

Andy
-- 
http://wingolog.org/

Re: frozen!

[Ludovic Courtès]

Hello,

Andy Wingo <wingo@pobox.com> writes:

> It seems that the moon has rolled around again!

Already!

> I haven't discussed this with Ludovic yet, but maybe we can relax this
> freeze slightly. This cycle has been a bit less hectic, Mike having
> gotten most of his stuff in, my having been on holiday, etc; so, I would
> like to propose that anyone who has a branch that they want in next
> week's 1.9.4, please propose it now. We'll take a look at them and merge
> (or not) by Friday.

I have:

  - wip-tls
  - bdw-gc-static-alloc (need to grep through sources to estimate the
    amount of breakage it would cause)

The former should be harmless, the latter is a bit more intrusive.

Then I think there are many fixes to be bugged.

Thanks,
Ludo’.

Re: frozen!

[Andy Wingo]

Hi Ludo,

On Tue 06 Oct 2009 23:49, ludo@gnu.org (Ludovic Courtès) writes:

>   - bdw-gc-static-alloc (need to grep through sources to estimate the
>     amount of breakage it would cause)

Neat :)

My only concern is with bytevectors. It should be possible to map a
bytevector to an existing range of memory, for read-write access. That
implies a pointer indirection. We can optimize for the inline case by
doing something like:

   +--------+------+-----+...
   | header | len  | ptr | inline-contents
   +--------+------+-----+...
                      \----^

andy
-- 
http://wingolog.org/

Re: frozen!

[Ludovic Courtès]

Hello,

Andy Wingo <wingo@pobox.com> writes:

> My only concern is with bytevectors. It should be possible to map a
> bytevector to an existing range of memory, for read-write access. That
> implies a pointer indirection. We can optimize for the inline case by
> doing something like:
>
>    +--------+------+-----+...
>    | header | len  | ptr | inline-contents
>    +--------+------+-----+...
>                       \----^

Yes, we agreed to do that (Neil suggested it as well), and it’s on my
to-do list.

Thanks,
Ludo’.