Re: [Chicken-hackers] CR #1142 and upcoming changes

[Mario Domenech Goulart]

Hi Felix and all,

On Mon, 18 Aug 2014 16:53:22 +0200 (CEST) Felix Winkelmann <address@hidden> 
wrote:

> I'm not sure how to go on with the CR-related changes. 
>
> All eggs that use queues, mmap, binary-search and eviction will break.
> This is manageable, as salmonella will point them out to us, but I'd
> also like to eggify srfi-18, srfi-69, srfi-1/13/14 and perhaps srfi-4
> as well and all that (including the /really/ massive changes related
> to core unit restructuring) will require us constantly running after
> broken eggs. The compiler-patch by Peter will add some more breakage.
>
> I wonder whether it isn't better to postpone releasing these changes,
> by creating development branches and switch in one step to CHICKEN 5,
> which would have a number of advantages over doing all that in a
> piecewise fashion:
>
> - There is no need to keep around deprecated APIs, confusing both
>   users and tools (e.g. chicken-doc, which would have to list multiple
>   variants of the same APIs, both in core (deprecated) and in eggs.
>
> - Any one change will break stuff; starting from a "clean slate"
>   (sort of) with a new major release of CHICKEN would allow users
>   a choice of whether to make a transition or keep working with
>   CHICKEN 4. Specifically, anybody having production code will
>   not like being forced to upgrade perfectly running code.
>
> It's clear that phasing out CHICKEN 4 does have it's disadvantages
> (keeping up with security fixes and critical bugs and so on), but
> since the changes planned are quite pervasive, backporting will be
> painful in any case, regardless of how we go on.
>
> So I would propose to do the following:
>
> - Starting with Peter's compiler-modularization, use a new branch in
>   the core-repository ("chicken-5"). Drop all core support for the
>   eggs in CR #1142, without going through a deprecation phase.
>
> - Branch off the egg-repo into a "5" branch. I know that this will not
>   catch problems with eggs outside of the svn repository, but it's a
>   start. Here we can add the eggs related to CR #1142, of course.
>
> - Setup a salmonalla instance for these new branches. 
>
> - I don't know how this is handled with henrietta - do we need a
>   separate CGI script running for this? It seems so, so the
>   core-branch will need to have different download URLs in
>   setup.defaults.
>
> All this is mainly to safe time - keeping up backward-compatibility
> hacks (wrapper-eggs, hacks in setup.defaults, etc.) just needs more
> work and time and we haven't much of that, considering that we are
> just a handful of part-time maintainers.
>
> Further steps will be creating a core unit for srfi-1/13/14 stuff
> that's needed there, extracting srfi-18/69/(4), restructuring the core
> units, and r7rs-compatibility work.
>
> This is just a proposal. What do others think?

Thanks for your message.  This is all very exciting and I'm totally for
shrinking the core.

Not related with removing units from the core, but since we are talking
about CHICKEN 5, shouldn't we consider discussing some polemic topics
like the support for Unicode and bignums in core?  Those are limitations
that recently lead to some ugly hacks (some examples in [1]) and bugs
(e.g., [2]).

[1] http://lists.gnu.org/archive/html/chicken-users/2014-07/msg00017.html

[2] http://bugs.call-cc.org/ticket/1139

Best wishes.
Mario
-- 
http://parenteses.org/mario