Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld:
Thanks for testing! I assume this is also enabling Guile optimizations
during LilyPond runtime? It would be interesting to see if there's a
gain from just compiling the bytecode with optimizations. That would be
a one-time cost that may be worth p
Am 08.04.2024 um 23:40 schrieb Jonas Hahnfeld:
[snip]
Thanks for testing! I assume this is also enabling Guile optimizations
during LilyPond runtime? It would be interesting to see if there's a
gain from just compiling the bytecode with optimizations. That would be
a one-time cost that may be
On Tue, 2024-04-02 at 16:40 +0200, Michael Käppler wrote:
> Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on LilyPond
> development:
> > As pointed out by Han-Wen in November, this is actually fairly little
> > code that gets dropped; we need to keep some related to optimizations
>
Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on
LilyPond development:
This is now up for review in the following merge request:
https://gitlab.com/lilypond/lilypond/-/merge_requests/2293
As pointed out by Han-Wen in November, this is actually fairly little
code that gets drop
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
> Step 4: Remove compatibility code for Guile 2.2
> This can happen after we made one or two releases with only Guile 3.0.
This is now up for review in the following merge request:
https://gitlab.com/lilypond/lilypond/-/merge_request
On Mon, 2023-12-04 at 21:55 +0100, Jonas Hahnfeld wrote:
> On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
>
> > then remove automatic detection of Guile 2.2 from configure.
>
> I did not yet upload a merge request to make Guile 3.0 the default for
> all builds:
>> then remove automatic detection of Guile 2.2 from configure.
>
> I did not yet upload a merge request to make Guile 3.0 the default
> for all builds: After more thought, I believe it's better to do this
> together with the removal of automatic configure support for Gu
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
> Step 3: Switch to Guile 3.0
> Afterwards, we can merge
> https://gitlab.com/lilypond/lilypond/-/merge_requests/2163
I put the merge request back on Patch::review, along with
https://gitlab.com/lilypond/lilypond/-/merge_requests
s 11 21H2, Intel Core i5-1135G7.
>
> "
> > lilypond.exe scheme-sandbox
> GNU LilyPond 2.25.10 (running Guile 3.0)
> Processing
> `C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly'
> P
lyPond 2.25.10 (running Guile 3.0)
Processing
`C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly'
Parsing...
GNU Guile 3.0.9
"
When I run convert-ly, it makes version statements "2.25.9". I can't
> “_” needs to be replaced with “G_”. Already in Guile 2, but Guile 3 checks for
> it more eagerly.
Fixed in LSR.
signature.asc
Description: This is a digitally signed message part
> Le 12 nov. 2023 à 19:14, Robin Bannister a écrit :
>
> If I take the code of LSR1098 [1] , without the demo part,
> Guile3 errors the input-warning call:
>
> GNU LilyPond 2.25.10 (running Guile 3.0)
> Processing `1.ly'
> Parsing...
> 1.ly:38:2: error:
Jonas Hahnfeld wrote:
On Sat, 2023-11-11 at 19:37 +0100, Jonas Hahnfeld wrote:
We are happy to announce the release of LilyPond 2.25.10.
And here are the binaries with Guile 3.0, built using
https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and
https://gitlab.com/lilypond/lilypond
On Sat, 2023-11-11 at 19:37 +0100, Jonas Hahnfeld wrote:
> We are happy to announce the release of LilyPond 2.25.10.
And here are the binaries with Guile 3.0, built using
https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and
https://gitlab.com/lilypond/lilypond/-/merge_requests/2
h the current
> > situation, let me propose to move to Guile 3.0. Below is a plan for
> > that switch, with a transition period to test the official binaries.
> > Last time, when going from Guile 1.8 to version 2.2, the switch had to
> > coincide with moving away from GUB. Betw
On Sun, Nov 5, 2023 at 10:36 PM Jonas Hahnfeld via Discussions on LilyPond
development wrote:
> Hi all,
>
> I hear LilyPond hasn't changed its Guile version since some time (more
> than 18 months). So before we get too comfortable with the current
> situation, let me propose
>> Step 1: Officially support Guile 3.0 and add optional CI testing I
>> opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162
>> to add some compatibility with earlier versions of Guile 3.0 and
>> then implement detection support in configure. It also crea
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote:
> Step 1: Officially support Guile 3.0 and add optional CI testing
> I opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 to
> add some compatibility with earlier versions of Guile 3.0 and then
> implement detectio
>> Please let me know of your comments!
>
> I'm very happy that you got Guile 3.0 working on Windows. Kudos for
> that (and I guess we need to send big thanks to Mike Gran too).
+1
> What I don't really understand is why you want to add compatibility
> with Gui
Le lundi 06 novembre 2023 à 01:11 +0100, David Kastrup a écrit :
> I have not checked recently, but last time I looked, Guile's versioning
> system more or less worked so that the development branch (and the
> corresponding versions) was Andy Wingo's playground. It was not
> concerned with APIs in
Jean Abou Samra writes:
> What I don't really understand is why you want to add compatibility
> with Guile 3.0.x for small x. Upstream completely breaks the normal
> expectation from what you would find in a point release, by putting
> features and even severely backwards inc
On Sun, 2023-11-05 at 22:48 +0100, Jean Abou Samra wrote:
> What I don't really understand is why you want to add compatibility
> with Guile 3.0.x for small x. Upstream completely breaks the normal
> expectation from what you would find in a point release, by putting
> features
Le dimanche 05 novembre 2023 à 22:36 +0100, Jonas Hahnfeld via Discussions on
LilyPond development a écrit :
> Please let me know of your comments!
I'm very happy that you got Guile 3.0 working on Windows. Kudos for
that (and I guess we need to send big thanks to Mike Gran too).
What
Hi all,
I hear LilyPond hasn't changed its Guile version since some time (more
than 18 months). So before we get too comfortable with the current
situation, let me propose to move to Guile 3.0. Below is a plan for
that switch, with a transition period to test the official binaries.
Last
Le 23/05/2022 à 23:00, Wol a écrit :
On 23/05/2022 20:19, Han-Wen Nienhuys wrote:
Vendoring Guile seems totally impractical. The Guile compilation does
some sort of bootstrapping, which makes building it from scratch
glacially slow (like: O(1 hour)), so it would be impossible for day to
day deve
Wol writes:
> On 23/05/2022 20:19, Han-Wen Nienhuys wrote:
>> Vendoring Guile seems totally impractical. The Guile compilation does
>> some sort of bootstrapping, which makes building it from scratch
>> glacially slow (like: O(1 hour)), so it would be impossible for day to
>> day development work
On 23/05/2022 20:19, Han-Wen Nienhuys wrote:
Vendoring Guile seems totally impractical. The Guile compilation does
some sort of bootstrapping, which makes building it from scratch
glacially slow (like: O(1 hour)), so it would be impossible for day to
day development work.
Just an idea, if "curr
On Mon, May 23, 2022 at 9:19 PM Han-Wen Nienhuys wrote:
> I'm missing the context for this proposal.
>
Something in the original thread from Jonas made me think some distros were
wrangling keeping up distributing
guile only for lilypond's benefit. It's possible I misunderstood and he
actually me
On Sun, May 22, 2022 at 7:48 PM Luca Fascione wrote:
> I would like to bring up an option that I'd expect fair few of you will
> _really_ not like.
> I'm doing this not because I necessarily believe it to be a
> particularly good way forward,
> rather because I feel it is sometimes useful to artic
This also makes a lot of sense to me, yes.
L
On Mon, 23 May 2022, 13:12 Jean Abou Samra, wrote:
>
>
> Le 22/05/2022 à 21:52, Luca Fascione a écrit :
> >
> > On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote:
> >
> > On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> > > So at
Le 22/05/2022 à 21:52, Luca Fascione a écrit :
On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote:
On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> So at the cost of rocking the cage a bit hard, I came asking the
> uncomfortable question:
> what would happen if (f
On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld wrote:
> On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> > So at the cost of rocking the cage a bit hard, I came asking the
> > uncomfortable question:
> > what would happen if (for this unique circumstance) we'd do what one
> > would norma
On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> So at the cost of rocking the cage a bit hard, I came asking the
> uncomfortable question:
> what would happen if (for this unique circumstance) we'd do what one
> would normally consider poor practice?
Let's call your proposal by its true,
On Sun, May 22, 2022 at 8:02 PM David Kastrup wrote:
> What do you mean with "shipped"?
I mean that when you clone the lilypond repo you'd find one more directory,
say
guile-2.2.7+/
or
guile-3.0.8+/
or something like that.
In fact we'd likely end up compiling a slightly different version thereo
Luca Fascione writes:
> I would like to bring up an option that I'd expect fair few of you will
> _really_ not like.
> I'm doing this not because I necessarily believe it to be a
> particularly good way forward,
> rather because I feel it is sometimes useful to articulate in words why an
> "obvio
heir own initiative and
> >> end up with one version of Guile they are going to ship for their whole
> >> distro, it would be good if that does not end up in making LilyPond
> >> disappear. That's all.
> >>
> >> What we _recommend_ and use ourselves
t;> disappear. That's all.
>>
>> What we _recommend_ and use ourselves is an entirely different matter.
>
>
> OK, but in that case, what is your request concretely?
> Current LilyPond master works with Guile 3.0.
That's essentially all. I wasn't sure of that
atter.
OK, but in that case, what is your request concretely?
Current LilyPond master works with Guile 3.0. Do you
want to add it to the CI?
Jean
Thomas Morley writes:
> Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>>
>>
>> #(ly:set-option 'warning-as-error #t)
>> %% not sure why these warnings appear twice [dfe]
>> -#(ly:expect-warning (_ "default child context begins a cycle: `~a'") 'Score)
>> -#(ly:expect-warning (_ "can
Am Mi., 22. Jan. 2020 um 00:59 Uhr schrieb David Kastrup :
>
> Thomas Morley writes:
>
> > Hi,
> >
> > some remarks:
> >
> > Guile-3.0
> > First I compiled successfully guile-master from their repo, giving GNU
> > Guile 3.0.0.6-f3298
> > Tr
Thomas Morley writes:
> Hi,
>
> some remarks:
>
> Guile-3.0
> First I compiled successfully guile-master from their repo, giving GNU
> Guile 3.0.0.6-f3298
> Trying to compile LilyPond with that guile (ofcourse adding a bunch of
> patches) I had some problems pointi
Am Mi., 22. Jan. 2020 um 00:41 Uhr schrieb Karlin High :
>
> On 1/21/2020 5:10 PM, Thomas Morley wrote:
> > Afterwards I've got a successful ´make´ with current LilyPond-master.
>
> So it's a functional LilyPond with guile-3.0? How does it perform if fed
> something
On 1/21/2020 5:10 PM, Thomas Morley wrote:
Afterwards I've got a successful ´make´ with current LilyPond-master.
So it's a functional LilyPond with guile-3.0? How does it perform if fed
something big? I'm thinking of the thread on benchmarking that used
Vaughan McAlley's
Hi,
some remarks:
Guile-3.0
First I compiled successfully guile-master from their repo, giving GNU
Guile 3.0.0.6-f3298
Trying to compile LilyPond with that guile (ofcourse adding a bunch of
patches) I had some problems pointing configure to the correct guile
and guile-config to the correct
44 matches
Mail list logo
