Am Sonntag, dem 18.04.2021 um 15:16 +0200 schrieb David Kastrup:
> Werner LEMBERG writes:
>
> > > > For me, the speed of Guile 2.x without compiled Scheme bytecode
> > > > would be too painful.
> > >
> > > Agreed for user installations, but we have a work-around there. So
> > > what about devel
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Am Montag, dem 19.04.2021 um 11:48 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld via Discussions on LilyPond development
>> writes:
>>
>> > Am Montag, dem 19.04.2021 um 10:39 +0200 schrieb Thomas Morley:
>> >
>> > > Maybe a mini
Am Montag, dem 19.04.2021 um 11:48 +0200 schrieb David Kastrup:
> Jonas Hahnfeld via Discussions on LilyPond development
> writes:
>
> > Am Montag, dem 19.04.2021 um 10:39 +0200 schrieb Thomas Morley:
> >
> > > Maybe a minimal example demonstrates it better than any explanation:
> > > In lilypon
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Am Montag, dem 19.04.2021 um 10:39 +0200 schrieb Thomas Morley:
>
>> Maybe a minimal example demonstrates it better than any explanation:
>> In lilypond master:
>> $ /home/hermann/lilypond-git/build-guile-2-2-6/out/bin/lilypond
>>
Am Montag, dem 19.04.2021 um 10:39 +0200 schrieb Thomas Morley:
> Am Mo., 19. Apr. 2021 um 08:42 Uhr schrieb Jonas Hahnfeld :
>
> > > (2)
> > > If I switch to a different branch, with changed .scm-files, do some
> > > work there and then switch back (NB in this branch the scm-files are
> > > _not_
Am Mo., 19. Apr. 2021 um 08:42 Uhr schrieb Jonas Hahnfeld :
> > ## Error-handling:
> > consider the typo in
> > {
> > \override NoteHead.after-line-breaking =
> > #(lambda (grob) (ly:grob-set-property! grob 'stencil poit-stencil))
> > b1
> > }
> > with guile-1 one gets:
> >
> > While evaluat
Thanks for testing!
Am Sonntag, dem 18.04.2021 um 22:16 +0200 schrieb Thomas Morley:
> Am So., 18. Apr. 2021 um 16:41 Uhr schrieb Thomas Morley
> :
> > Currently I'm testing both. From a user's and a developer's point of view.
> > I'll post about it in the (late) evening or tomorrow.
> > Please ha
Hi Thomas,
> (1)
> The whole cycle worked fine, no errors apart from my own.
> Though, regtest-comparision shows:
> WARNING: (lily song): imported module (lily song-util) overrides core
> binding `compose'
> For input/regression/song-melisma.log and others.
> Which is new with guile-2.
> No clue h
Am So., 18. Apr. 2021 um 16:41 Uhr schrieb Thomas Morley
:
>
> Am So., 18. Apr. 2021 um 15:38 Uhr schrieb Jonas Hahnfeld via
> Discussions on LilyPond development :
> >
> > Am Sonntag, dem 18.04.2021 um 13:11 + schrieb Werner LEMBERG:
> > > > > For me, the speed of Guile 2.x without compiled Sc
> By now I guess just nobody cares to tell me in advance and whatever
> I choose to do, it will be questioned when I try to proceed to the
> next steps...
Well, I *do* care, but I simply don't have enough knowledge to give
even an uneducated guess as answers to your questions, sorry.
Werne
Am So., 18. Apr. 2021 um 15:38 Uhr schrieb Jonas Hahnfeld via
Discussions on LilyPond development :
>
> Am Sonntag, dem 18.04.2021 um 13:11 + schrieb Werner LEMBERG:
> > > > For me, the speed of Guile 2.x without compiled Scheme bytecode
> > > > would be too painful.
> > >
> > > Agreed for user
Am Sonntag, dem 18.04.2021 um 13:11 + schrieb Werner LEMBERG:
> > > For me, the speed of Guile 2.x without compiled Scheme bytecode
> > > would be too painful.
> >
> > Agreed for user installations, but we have a work-around there. So
> > what about development? Do we *require* compiled bytec
Werner LEMBERG writes:
>>> For me, the speed of Guile 2.x without compiled Scheme bytecode
>>> would be too painful.
>>
>> Agreed for user installations, but we have a work-around there. So
>> what about development? Do we *require* compiled bytecode to work
>> there? [...]
>
> I don't know, r
>> For me, the speed of Guile 2.x without compiled Scheme bytecode
>> would be too painful.
>
> Agreed for user installations, but we have a work-around there. So
> what about development? Do we *require* compiled bytecode to work
> there? [...]
I don't know, really. I have zero feeling for
Am Sonntag, dem 18.04.2021 um 10:35 + schrieb Werner LEMBERG:
> > > Working towards a fork of Guile 1.8 was never meant to be a good
> > > option, rather as a last resort if speed differences make normal
> > > work too painful.
> >
> > Well, the question of this thread was: What is "too painfu
>> Working towards a fork of Guile 1.8 was never meant to be a good
>> option, rather as a last resort if speed differences make normal
>> work too painful.
>
> Well, the question of this thread was: What is "too painful"? Do we
> require less "speed differences" than what I measured? In general
Am Sonntag, dem 18.04.2021 um 05:31 + schrieb Werner LEMBERG:
> > > I stand corrected. Somehow I got the impression that compiled
> > > Scheme code is a 3.x thing only.
> >
> > So with that hopefully clarified, does this change your assessment
> > that we should work towards forking our own G
>> I stand corrected. Somehow I got the impression that compiled
>> Scheme code is a 3.x thing only.
>
> So with that hopefully clarified, does this change your assessment
> that we should work towards forking our own Guile 1.8?
Working towards a fork of Guile 1.8 was never meant to be a good
o
Am Samstag, dem 17.04.2021 um 12:02 +0200 schrieb Thomas Morley:
> Above was meant to get a default build, i.e. without compiled .go-files.
> Though, it's not entirely clear to me how to enable compiling those files.
> Am I correct that
> GUILE_AUTO_COMPILE=1
> is not an option while running config
Am Sa., 17. Apr. 2021 um 12:02 Uhr schrieb Thomas Morley
:
>
> Am So., 11. Apr. 2021 um 20:04 Uhr schrieb Thomas Morley
> :
> >
> > Am So., 11. Apr. 2021 um 19:37 Uhr schrieb Jonas Hahnfeld via
> > Discussions on LilyPond development :
> > >
> > > Am Sonntag, dem 11.04.2021 um 18:04 +0200 schrieb H
Am So., 11. Apr. 2021 um 20:04 Uhr schrieb Thomas Morley
:
>
> Am So., 11. Apr. 2021 um 19:37 Uhr schrieb Jonas Hahnfeld via
> Discussions on LilyPond development :
> >
> > Am Sonntag, dem 11.04.2021 um 18:04 +0200 schrieb Han-Wen Nienhuys:
> > > I wonder if it isn't more practical to fork guile 1.
Now I can reply to this message with a bit more time.
Am Montag, dem 12.04.2021 um 09:28 +0200 schrieb Han-Wen Nienhuys:
> Jonas didn't include 3.0 in the benchmarking because it's not
> generally available yet, but I think it is relevant data. Part of the
> reason why we want to be on an up-to-da
Am Montag, dem 12.04.2021 um 09:36 +0200 schrieb Werner LEMBERG:
> > > ... you were talking about advancing to Guile 2.x as the next
> > > step,
> > > and if I have understood your original e-mail correctly, this
> > > speed
> > > is only available with 3.x.
> >
> > Then please re-read the initial
On 4/12/2021 7:06 AM, David Kastrup wrote:
Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
an extremely serious problem.
I was of the opinion that we distributed a 64-bit version here? Or did
I get that wrong?
Windows Subsystem for Linux continues to gain capability. It's
Am Montag, dem 12.04.2021 um 13:50 +0200 schrieb David Kastrup:
> Werner LEMBERG writes:
>
> > > > ... you were talking about advancing to Guile 2.x as the next step,
> > > > and if I have understood your original e-mail correctly, this speed
> > > > is only available with 3.x.
> > >
> > > Then
Han-Wen Nienhuys writes:
> It seems that most of the core work on GUILE is done by a single
> person (Andy Wingo).
Last time I looked at commit history and mailing list usage, the
"development version" of Guile was exclusively Andy Wingo's domain and
he did not communicate with anyone on publicl
Werner LEMBERG writes:
>>> ... you were talking about advancing to Guile 2.x as the next step,
>>> and if I have understood your original e-mail correctly, this speed
>>> is only available with 3.x.
>>
>> Then please re-read the initial message *carefully*!
>
> I stand corrected. Somehow I got
Am Montag, dem 12.04.2021 um 10:00 +0200 schrieb Han-Wen Nienhuys:
> On Mon, Apr 12, 2021 at 9:36 AM Jonas Hahnfeld wrote:
> >
> > Am Montag, dem 12.04.2021 um 09:28 +0200 schrieb Han-Wen Nienhuys:
> > > Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
> > > an extremely serio
On Mon, Apr 12, 2021 at 9:36 AM Jonas Hahnfeld wrote:
>
> Am Montag, dem 12.04.2021 um 09:28 +0200 schrieb Han-Wen Nienhuys:
> > Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
> > an extremely serious problem. What is the reason for this? Is it
> > because dynamic loading doe
>> ... you were talking about advancing to Guile 2.x as the next step,
>> and if I have understood your original e-mail correctly, this speed
>> is only available with 3.x.
>
> Then please re-read the initial message *carefully*!
I stand corrected. Somehow I got the impression that compiled Sc
Am Montag, dem 12.04.2021 um 09:28 +0200 schrieb Han-Wen Nienhuys:
> Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
> an extremely serious problem. What is the reason for this? Is it
> because dynamic loading doesn't work correctly, and GUILE tries to
> load SRFI modules as .d
Am Montag, dem 12.04.2021 um 09:19 +0200 schrieb Werner LEMBERG:
> > > Note that I don't want that we stay with Guile 1.8 forever, but
> > > the slowness of 2.x and 3.x is a serious issue. To sacrifice
> > > this still enormous speed advantage just for the sake of
> > > orthodoxy seems wrong to me
On Sun, Apr 11, 2021 at 7:55 PM Werner LEMBERG wrote:
> > Guile 2.2 also makes binary distribution much nicer (because there
> > no more shared srfi libraries, so lilypond can be linked as one
> > static executable) and makes it possible to offer 64 bit executables
> > for Windows.
>
> ... especi
>> Note that I don't want that we stay with Guile 1.8 forever, but the
>> slowness of 2.x and 3.x is a serious issue. To sacrifice this
>> still enormous speed advantage just for the sake of orthodoxy seems
>> wrong to me.
>
> So 10% performance regression for users is enormous?
This would be a
Am Montag, dem 12.04.2021 um 09:00 +0200 schrieb Werner LEMBERG:
> > > Almost all developers use a Unix-like OS and can be thus served
> > > with Guile 1.8.x! Are there actually LilyPond developers who
> > > work
> > > natively with Windows or MacOS? With 'natively' I mean using a
> > > binary sp
>> Almost all developers use a Unix-like OS and can be thus served
>> with Guile 1.8.x! Are there actually LilyPond developers who work
>> natively with Windows or MacOS? With 'natively' I mean using a
>> binary specifically compiled for that platform and not a virtual
>> box.
>
> Adding a mix
Am Sonntag, dem 11.04.2021 um 22:19 +0200 schrieb Werner LEMBERG:
> > > It is very unfortunate that more recent Guile versions cause such
> > > a serious deterioration for LilyPond. Maybe it makes sense for
> > > the foreseeable future to stay with the status quo, this is,
> > > using Guile 1.8 as
>> It is very unfortunate that more recent Guile versions cause such a
>> serious deterioration for LilyPond. Maybe it makes sense for the
>> foreseeable future to stay with the status quo, this is, using
>> Guile 1.8 as much as possible,
>
> For reference: Ubuntu 16.04, the longest supported ve
On Sun, Apr 11, 2021 at 08:11:37PM +0200, Jonas Hahnfeld via Discussions on
LilyPond development wrote:
> So, that was the main question of the message (sorry if that got hidden
> in the lengthy text and many numbers): What is "reasonable"? I think
> the numbers I showed are reasonable, but that's
Am Sonntag, dem 11.04.2021 um 19:55 +0200 schrieb Werner LEMBERG:
>
> It is very unfortunate that more recent Guile versions cause such a
> serious deterioration for LilyPond. Maybe it makes sense for the
> foreseeable future to stay with the status quo, this is, using Guile
> 1.8 as much as poss
Am Sonntag, dem 11.04.2021 um 20:04 +0200 schrieb Thomas Morley:
> Am So., 11. Apr. 2021 um 19:37 Uhr schrieb Jonas Hahnfeld via
> Discussions on LilyPond development :
> >
> > Am Sonntag, dem 11.04.2021 um 18:04 +0200 schrieb Han-Wen Nienhuys:
> > > I wonder if it isn't more practical to fork gui
Am So., 11. Apr. 2021 um 19:37 Uhr schrieb Jonas Hahnfeld via
Discussions on LilyPond development :
>
> Am Sonntag, dem 11.04.2021 um 18:04 +0200 schrieb Han-Wen Nienhuys:
> > I wonder if it isn't more practical to fork guile 1.8, and stick it
> > into our tree as a submodule, and always build lily
> I had already replied that I don't like that option; it was always a
> given for me that LilyPond would move on.
Your arguments are sound, no question, ...
> Guile 2.2 also makes binary distribution much nicer (because there
> no more shared srfi libraries, so lilypond can be linked as one
>
Am Sonntag, dem 11.04.2021 um 18:04 +0200 schrieb Han-Wen Nienhuys:
> On Sun, Apr 11, 2021 at 4:24 PM Jonas Hahnfeld wrote:
> >
> > Am Sonntag, dem 11.04.2021 um 16:04 +0200 schrieb Han-Wen Nienhuys:
> > > On Sun, Apr 11, 2021 at 3:42 PM Jonas Hahnfeld via Discussions on
> > > LilyPond developmen
On Sun, Apr 11, 2021 at 4:24 PM Jonas Hahnfeld wrote:
>
> Am Sonntag, dem 11.04.2021 um 16:04 +0200 schrieb Han-Wen Nienhuys:
> > On Sun, Apr 11, 2021 at 3:42 PM Jonas Hahnfeld via Discussions on
> > LilyPond development wrote:
> > >
> > > All numbers are from my laptop running Arch Linux (with p
Am Sonntag, dem 11.04.2021 um 16:17 +0200 schrieb Werner LEMBERG:
> > I'd like to give an update on the status of Guile 2.2, including
> > some benchmark numbers. See the end for my conclusions, but I'd
> > welcome comments on your take.
>
> Thanks for doing the comparison.
>
> This has certainl
Am Sonntag, dem 11.04.2021 um 16:04 +0200 schrieb Han-Wen Nienhuys:
> On Sun, Apr 11, 2021 at 3:42 PM Jonas Hahnfeld via Discussions on
> LilyPond development wrote:
> >
> > All numbers are from my laptop running Arch Linux (with pango
> > downgraded to 1:1.48.2-1 to keep out the memory hogging i
> I'd like to give an update on the status of Guile 2.2, including
> some benchmark numbers. See the end for my conclusions, but I'd
> welcome comments on your take.
Thanks for doing the comparison.
This has certainly be mentioned somewhere, but what exactly is the
advantage for LilyPond of us
On Sun, Apr 11, 2021 at 3:42 PM Jonas Hahnfeld via Discussions on LilyPond
development wrote:
>
> All numbers are from my laptop running Arch Linux (with pango
> downgraded to 1:1.48.2-1 to keep out the memory hogging in 1.48.3) and
> measured with "/usr/bin/time -v". I use commit fce156f219 from
Hi all,
I'd like to give an update on the status of Guile 2.2, including some
benchmark numbers. See the end for my conclusions, but I'd welcome
comments on your take.
Setup
-
All numbers are from my laptop running Arch Linux (with pango
downgraded to 1:1.48.2-1 to keep out the memory hoggin
50 matches
Mail list logo
