Re: Time to fork a guile-2 branch?

[address@hidden]

On 13 août 2012, at 11:14, David Kastrup <address@hidden> wrote:

> Graham Percival <address@hidden> writes:
> 
>> On Mon, Aug 13, 2012 at 09:38:15AM +0200, David Kastrup wrote:
>>>> 3. Where there are significant changes to component .scm files for
>>>> guile V2, these will also be converted into a shim similar to lily.scm
>>>> and will have <file>-guile-1.scm and <file>-guile-2.scm files
>>>> produced.
>>> 
>>> Personally, I am almost in favor of a rather hard cut where we switch
>>> from Guilev1 to Guilev2.  The problem with that is that such a step
>>> cannot really be prepared separately since it would likely get code
>>> outdated: we had that problem previously.
>>> 
>>> Most direct would be a hard cut: exchange the Guile version, and get
>>> everybody working furiously until LilyPond works again.
>> 
>> I'm fine with this, perhaps immediately after 2.17.0 comes out?
>> Provided that the regtests compile, I have no trouble switching to
>> it for 2.17.1 regardless of what that might do to user scores
>> (since nobody should be using 2.17.1).
>> 
>> Note that GUB will need to be updated to compile guile V2, and
>> also that if that update is done poorly then GUB would lose the
>> ability to compile 2.16.x.  IIRC that happened with the 2.12
>> branch, or at least the compile needed some manual hacks in order
>> to complete the build.
> 
> The problem I am seeing here is a scheduling problem.  We have two
> pent-up changes.  One is changing from Guilev1 to Guilev2.  The intended
> user-visible change is no change at all except for performance.
> 
> Another is incorporating the new skyline code.  The intended
> user-visible change is lots of change.  The skyline code is also likely
> to cause significant performance impact that will want ironing out.
> 
> It seems to make comparatively little sense to do this ironing out based
> on the Guilev1 architecture: while any reduction in computation
> complexity will remain valid, the constant factors at very least will
> all be quite different.
> 
> On the other hand, the skyline "patch" is quite large by now.  Rebasing
> it on a Guilev2 architecture will only be feasible if we try keeping it
> as similar as possible.  Which would favor a "minimally invasive"
> Guilev2 migration, one that does not in its first iteration require
> reorganizing the source code into independently compilable Scheme source
> modules: that would be attempted only after the skyline code has been
> successfully merged.
> 
> Tricky.
> 
> -- 
> David Kastrup
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel


For me it's a question of time more than anything else.  If Ian thinks that he 
can get the Guile 2.0 stuff pushed in the next couple weeks, it's worth it to 
hold off on skyline stuff.  Otherwise, I'd like to get the skyline stuff in 
there ASAP, as I am sure that it'll take several versions for all the bugs and 
performance issues to be ironed out.

There are not many .scm files changed in my patch, and all of it seems to be 
changing what goes on inside functions rather than the order that things are 
called.  So I am optimistic that, irrespective of which gets pushed first, 
there won't be that much manual rebasing that needs to be done.

Cheers,
MS