Release time!

Release time!

[Ludovic Courtès]

Hello!

I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
WDYT?

By then, we should essentially squash as many bugs as possible.

New features we may want to include:

  - functional setters, for SRFI-9
  - ‘--r6rs’ and related R6RS things
  - Chris’s SRFI-41

Noteworthy bugs that come to mind:

  - CSE bug I recently hit
  - assertion failure hit when running srfi-18.test in a loop

Anything else?

Thanks,
Ludo’.

Re: Release time!

[Hans Aberg]

On 5 Nov 2012, at 19:11, Ludovic Courtès wrote:

> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
> WDYT?

FYI, this is the last week of November - a lot of countries do not use this week numbering system.

https://en.wikipedia.org/wiki/Seven-day_week#Week_numbering

Re: Release time!

[Ludovic Courtès]

Hi Hans,

Hans Aberg <haberg-1@telia.com> skribis:

> On 5 Nov 2012, at 19:11, Ludovic Courtès wrote:
>
>> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
>> WDYT?
>
> FYI, this is the last week of November - a lot of countries do not use this week numbering system.
>
> https://en.wikipedia.org/wiki/Seven-day_week#Week_numbering

Oh, interesting.  I used the number Org gave me, and it starts on
Nov. 26th, which apparently corresponds to the ISO 8601 week date.  :-)

Ludo’.

Re: Release time!

[Hans Aberg]

On 5 Nov 2012, at 22:02, Ludovic Courtès wrote:

> Hi Hans,

Hi Ludo,

> Hans Aberg <haberg-1@telia.com> skribis:
> 
>> On 5 Nov 2012, at 19:11, Ludovic Courtès wrote:
>> 
>>> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
>>> WDYT?
>> 
>> FYI, this is the last week of November - a lot of countries do not use this week numbering system.
>> 
>> https://en.wikipedia.org/wiki/Seven-day_week#Week_numbering
> 
> Oh, interesting.  I used the number Org gave me, and it starts on
> Nov. 26th, which apparently corresponds to the ISO 8601 week date.  :-)

Is Org the repository? Then perhaps people know about week numbers. In the US, for example, they are normally not used.

Hans

Re: Release time!

[Ludovic Courtès]

Hi,

Hans Aberg <haberg-1@telia.com> skribis:

> On 5 Nov 2012, at 22:02, Ludovic Courtès wrote:
>
>> Hi Hans,
>
> Hi Ludo,
>
>> Hans Aberg <haberg-1@telia.com> skribis:
>> 
>>> On 5 Nov 2012, at 19:11, Ludovic Courtès wrote:
>>> 
>>>> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
>>>> WDYT?
>>> 
>>> FYI, this is the last week of November - a lot of countries do not use this week numbering system.
>>> 
>>> https://en.wikipedia.org/wiki/Seven-day_week#Week_numbering
>> 
>> Oh, interesting.  I used the number Org gave me, and it starts on
>> Nov. 26th, which apparently corresponds to the ISO 8601 week date.  :-)
>
> Is Org the repository?

I meant http://orgmode.org/ .

> Then perhaps people know about week numbers. In the US, for example, they are normally not used.

OK, thanks for the note.

Ludo’.

Re: Release time!

[Hans Aberg]

On 6 Nov 2012, at 19:28, Ludovic Courtès wrote:

> Hi,
> 
> Hans Aberg <haberg-1@telia.com> skribis:
> 
>> On 5 Nov 2012, at 22:02, Ludovic Courtès wrote:
>> 
>>> Hi Hans,
>> 
>> Hi Ludo,
>> 
>>> Hans Aberg <haberg-1@telia.com> skribis:
>>> 
>>>> On 5 Nov 2012, at 19:11, Ludovic Courtès wrote:
>>>> 
>>>>> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
>>>>> WDYT?
>>>> 
>>>> FYI, this is the last week of November - a lot of countries do not use this week numbering system.
>>>> 
>>>> https://en.wikipedia.org/wiki/Seven-day_week#Week_numbering
>>> 
>>> Oh, interesting.  I used the number Org gave me, and it starts on
>>> Nov. 26th, which apparently corresponds to the ISO 8601 week date.  :-)
>> 
>> Is Org the repository?
> 
> I meant http://orgmode.org/ .

OK. Good to know.

>> Then perhaps people know about week numbers. In the US, for example, they are normally not used.
> 
> OK, thanks for the note.

They use it a lot here in Sweden, for example, but in the US, I think they would likely not know what it is.

Hans

Re: Release time!

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

>   - assertion failure hit when running srfi-18.test in a loop

This one turned out to be easy (it could be reproduced by running the
"sleeping threads notified of abandonment" in a loop), and is fixed by
02a362a.  Cool!  :-)

Ludo’.

Re: Release time!

[Bruce Korb]

On 11/05/12 10:11, Ludovic Courtès wrote:
> Hello!
> 
> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
> WDYT?

I think it would be Really Nice if it were not fiddling LD_LIBRARY_PATH
by the next release.

> By then, we should essentially squash as many bugs as possible.

that bug is quite the nuisance for me....

Re: Release time!

[Ludovic Courtès]

Hi Bruce,

Bruce Korb <bkorb@gnu.org> skribis:

> I think it would be Really Nice if it were not fiddling LD_LIBRARY_PATH
> by the next release.

Right, thanks for the reminder.  I’ll see where we left it...

Ludo’.

Re: Release time!

[nalaginrut]

On Mon, 2012-11-05 at 19:11 +0100, Ludovic Courtès wrote:
> Hello!
> 
> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
> WDYT?
> 
> By then, we should essentially squash as many bugs as possible.
> 
> New features we may want to include:
> 
>   - functional setters, for SRFI-9
>   - ‘--r6rs’ and related R6RS things
>   - Chris’s SRFI-41
> 

And don't forget SRFI-105 ;-D
And what about the status of ethread?

> Noteworthy bugs that come to mind:
> 
>   - CSE bug I recently hit
>   - assertion failure hit when running srfi-18.test in a loop
> 
> Anything else?
> 
> Thanks,
> Ludo’.
> 
> 

Re: Release time!

[Mark H Weaver]

nalaginrut <nalaginrut@gmail.com> writes:
> And don't forget SRFI-105 ;-D

SRFI-105 is already in.

    Mark

Re: Release time!

[Ludovic Courtès]

nalaginrut <nalaginrut@gmail.com> skribis:

> And don't forget SRFI-105 ;-D

It’s already in.

> And what about the status of ethread?

We were still debating whether to include it, how, etc.  So not for this
time.

Ludo’.

Re: Release time!

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> I think time has come for 2.0.7.  I suggest scheduling it for Week 48,
> WDYT?

Sounds good!

Here are the items from my TODO list that I hope to do for 2.0.7:
(and if anyone else wants to do any of these, that would be great!)

* Move docs for SRFI-9 records into the "Compound Data Types" section of
  the manual, and move docs for the older structures and records into a
  "Low-level structures" section (with big warnings on top).

* Fix thread-unsafe lazy initialization of 'scm_eval_string_in_module'.
  (and search for other similar bugs).

* Deal with the LD_LIBRARY_PATH issue.

* Make sure that curly-infix is disabled when reading elisp code.

* Fix par-map and par-for-each to use all ncores, not ncores-1.

* Fix decompile-tree-il to recognize 'case' statements properly, now
  that 'eqv?' is sometimes being optimized to 'eq?'.

and maybe:

* Figure out a way to make Guildhall modules that will be overridden by
  a matching module in core guile (if it exists).  This is important for
  SRFIs.  Ian Price's Guildhall repository contains portable
  implementions of several SRFIs that might become part of core Guile in
  the future, and the core versions should take priority.

     Mark

Re: Release time!

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Here are the items from my TODO list that I hope to do for 2.0.7:
> (and if anyone else wants to do any of these, that would be great!)
>
> * Move docs for SRFI-9 records into the "Compound Data Types" section of
>   the manual, and move docs for the older structures and records into a
>   "Low-level structures" section (with big warnings on top).
>
> * Fix thread-unsafe lazy initialization of 'scm_eval_string_in_module'.
>   (and search for other similar bugs).
>
> * Deal with the LD_LIBRARY_PATH issue.
>
> * Make sure that curly-infix is disabled when reading elisp code.
>
> * Fix par-map and par-for-each to use all ncores, not ncores-1.
>
> * Fix decompile-tree-il to recognize 'case' statements properly, now
>   that 'eqv?' is sometimes being optimized to 'eq?'.

Sounds good to me.  Thanks for keeping track of that!

> * Figure out a way to make Guildhall modules that will be overridden by
>   a matching module in core guile (if it exists).  This is important for
>   SRFIs.  Ian Price's Guildhall repository contains portable
>   implementions of several SRFIs that might become part of core Guile in
>   the future, and the core versions should take priority.

Could guildhall use SRFI-0 to check whether a given SRFI is already
provided by the host’s Guile, and determine based on that whether to
install its own version?

Thanks,
Ludo’.

Re: Release time!

[Ian Price]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 1221 bytes --]

ludo@gnu.org (Ludovic Court^[$(D+2^[(Bs) writes:

>> * Figure out a way to make Guildhall modules that will be overridden by
>>   a matching module in core guile (if it exists).  This is important for
>>   SRFIs.  Ian Price's Guildhall repository contains portable
>>   implementions of several SRFIs that might become part of core Guile in
>>   the future, and the core versions should take priority.
>
> Could guildhall use SRFI-0 to check whether a given SRFI is already
> provided by the host^[$B!G^[(Bs Guile, and determine based on that whether to
> install its own version?

Well, maybe I could hack something that uses srfi-0, but it sounds kinda
ugly, and liable to break if a guile upgrade changed the features it exported.

Right now, a package can declare multiple 'provides' so that you can
e.g. require srfi-1 and it would pull in the appropriate package. But as
it stands, the provides are somewhat orthogonal to how the code gets
installed.

Andreas,
Guildhall is a friendly fork of Dorodango, so what do you think about
adding this sort of thing?

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Release time!

[Andreas Rottmann]

Ian Price <ianprice90@googlemail.com> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>>> * Figure out a way to make Guildhall modules that will be overridden by
>>>   a matching module in core guile (if it exists).  This is important for
>>>   SRFIs.  Ian Price's Guildhall repository contains portable
>>>   implementions of several SRFIs that might become part of core Guile in
>>>   the future, and the core versions should take priority.
>>
>> Could guildhall use SRFI-0 to check whether a given SRFI is already
>> provided by the host’s Guile, and determine based on that whether to
>> install its own version?
>
> Well, maybe I could hack something that uses srfi-0, but it sounds kinda
> ugly, and liable to break if a guile upgrade changed the features it exported.
>
> Right now, a package can declare multiple 'provides' so that you can
> e.g. require srfi-1 and it would pull in the appropriate package. But as
> it stands, the provides are somewhat orthogonal to how the code gets
> installed.
>
> Andreas,
> Guildhall is a friendly fork of Dorodango, so what do you think about
> adding this sort of thing?
>
I've thought about this issue some time ago, but have not yet come to a
definite conclusion on how to handle this.  A rough idea is to add a
"proxy package" for the Scheme implementation of the destination
(i.e. installation target) to the `dorodango-support' bundle, which is
created upon initialization of the destination.

If that proxy package would "provide" (e.g. based on a feature check)
all SRFIs that are present in the target Scheme (aka "Guile" from now
on), that would bring us closer to the goal. If all SRFIs required by
the set of packages installed are indeed provided by Guile, no
additional package would be pulled in.  However, if a single package
provides multiple SRFIs, of which only some are provided by Guile, that
package will get installed to satisfy any requirements not met by the
proxy package, and will thus *override* any core SRFI implementation in
Guile that it provides as well.

However, there's a reasonable (I think) workaround: no longer `provide'
the SRFIs, but instead really use individual packages for them, so they
can be installed on an individual basis.  This is not as tedious as it
might sound: the pkg-list.scm file would have to list each SRFI, but the
collection of portable SRFIs can still be maintained in a single source
repository and dorodango bundle (i.e. unit of distribution).

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>