lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rational


From: David Kastrup
Subject: Re: Rational
Date: Wed, 23 May 2018 13:10:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Hans Åberg <address@hidden> writes:

>> On 23 May 2018, at 12:20, David Kastrup <address@hidden> wrote:
>> 
>> ... work on "the problem" has moved beyond the stage where one can
>> just propose a generic solution, everybody slaps his forehead and
>> gets to work and does what it takes to do.
>
> How about using what I suggested and what you touched upon in your
> link?

Hans, with regard to the LilyPond code base you don't know what you are
talking about.  First, LilyPond is not in a state where you can get
serious work done with Guilev2 (memory consumption and speed are too far
off the mark) so the Boehm GC is just a theoretical consideration for
the bulk of the code base.  Second, its organization is such (using
loads of STL data structures with their own allocation for storing
structures containing only some SCM values) that the Boehm GC approach
does not make for a good match with wholescale conservative scanning
without employing mark hooks.

Guilev2, including its use of the Boehm GC, is optimized for
applications that are principally Scheme, and it works also for
applications that are principally C++ in their approach.  Or at least
small.  LilyPond is huge, with large resource demands, and it's sort-of
half Scheme and half C++, both regarding its data structures as well as
the data itself.

Guilev2 support by now is workable enough that somebody actually cluing
himself in and working with the respective patches/branches can get a
working setup for experimentation.  If you want to gather your own
experience in that area and give actually qualified advice and code
proposals, feel free to do so.

>> So if you want to be helpful, let go of your consultants' hat and don
>> the programmers' hat.
>
> I looked a bit at the LilyPond C++ code, but looks so 1990s, and I am
> on C++17.

It doesn't actually look a whole lot like code written in 1990s either
since much of it is done using specific SCM/C++ glue.  Not as bad as the
C code base of Emacs looks (which is tied more closely into Elisp than
LilyPond into Guile since Elisp does not exist as a separate interpreter
inside of Emacs) but bad enough.  At any rate, feel free to submit
patches.  Due to compatibility considerations, a currently acceptable
standard to write to would be about C++11 by now.  The current code base
is basically C++98 since the last time C++11 features were considered,
general availability and quality of compilers in distributions was
mottled.

It has to be noted that the code base of LilyPond is large enough that
gratuitous wholesale rewrites to follow standards are not really
feasible given its programmer base, and one needs to balance code
aesthetics with maintainability: code that only one person feels at home
with does not really help.

>>> and instead of a suitable reply, I get an endless row of rants, and
>>> now you fill in with those.
>> 
>> Just as a reminder: this thread is offspring from an endless row of
>> rather insulting and condescending rants about LilyPond's
>> limited-precision rational numbers and you jump-started...
>
> I started a new thread to get away from that.
>
>> ...a set of lectures on the Boehm GC on it predicated on the premise
>> that I don't know my way around it.  Now the other guy clearly
>> intended to be both insulting and condescending in order to get his
>> bidding done.  In contrast to that, you are only condescending and
>> more or less add accidentally to the implication that everybody
>> involved with LilyPond programming has to be an idiot compared to
>> yourself.
>
> You are on the right way, but your personality gets in the way of
> thinking it through.

Since you don't suffer from any such similar problem, how about thinking
it through yourself and submitting the finished patch(es) for review?

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]