Re: [guile-2.2] patches

[Thomas Morley]

2017-03-19 15:59 GMT+01:00 Urs Liska <address@hidden>:
>
>
> Am 19.03.2017 um 15:43 schrieb David Kastrup:
>> The problem is more that Guile-2.0 will not work at all any more, and it
>> will take some time until Guile-2.2 becomes generally available.  Now
>> it's not like compilation with Guile-2.0 is doing us a lot of favors
>> anyway.
>
> I think that's what Harm wanted to imply and suggest (to drop any
> efforts towards Guile 2.0).

Well, the above attached patch works with guile-2.0.14 as well. Just tested.


Though, the question remains what to do?

(Some thoughts:)

For both guile-versions we lack a method to deal with .go-files.
Although I always happily test, I'm afraid I can't help with it. I
have the feeling already touching the limits of my current skills.

Also, for both guile-versions (more for 2.0.14) encoding and
string-handling-issues may persist.
I'm aware of your thoughts here
http://lists.gnu.org/archive/html/guile-user/2017-03/msg00112.html
Though, I think it's out of my depth as well.

Forking guile-1.8 was discussed as well.

Currently I have builds for guile-1.8.8, 2.0.14 and 2.2.0 on my
computer, all working.

It would be nice we could move to guile 2.2. As guile-devs claimed, I
think I can confirm memory-handling is far better with guile 2.x.
While forking 1.8 we wouldn't benefit from it.
For huge scores my small laptop needs to be restarted every time I
compile a huge score with lily-guile-1.8. That's a pain.
Far better with guile 2.x
Ok, lilypond is (sometimes much) slower (even slower with 2.0.14),
that's the main drawback from a user's point of view.



But back to the initial question.

Possibilities:
(1) I could try to revise the guile2-patches and implement them in master.
(2) Doing the same but placing them in a new public branch for guile-2.2
(3) We could fork guile-1.8.

I think we need a consensus or at least sort of a roadmap.

Cheers,
  Harm