Re: Rational

[David Kastrup]

metachromatic  writes:

 If you want an answer, ask a question.  Just stating something in the
 hope that the correction will work as an answer is trying your luck.
>
>What's the point of asking a question on this forum?  The answer
> always seems to be: "Go fix it yourself. Dig into the Lilypond code,
> and get busy, and stop bothering us with your bug reports."

Replace "bug reports" with "explanations" and the result is exactly your
approach.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[metachromatic]

>>> If you want an answer, ask a question.  Just stating something in the
>>> hope that the correction will work as an answer is trying your luck.

   What's the point of asking a question on this forum?  The answer
always seems to be: "Go fix it yourself. Dig into the Lilypond code,
and get busy, and stop bothering us with your bug reports."

   So, seriously...what's the point of this forum at all?

   When a user who reports a problem gets told "Fix it yourself," what
purpose does this forum serve?

   Why not just replace the entire forum with a GIF that says FIX
YOURSELF, LOSER, LOL!

   Boy, programmers...what a group.

   Imagine this philosophy applied to society at large.

   "Hello, city hall? The bridge is falling down--"
   "Fix it yourself, loser, LOL!"

   "Hello, CDC, I'd like to report an outbreak of ebola at--"
   "Fix it yourself, loser, LOL!"

   "Hi, is this the fire department?  I want to report a fire at--"
   "That's not a bug, that's a feature!  If you don't like it, go put
it out yourself. Pathetic."
-
--mclaren

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Kieren MacMillan]

Hi Hans,

> On May 23, 2018, at 12:45 PM, Hans Åberg  wrote:
> 
>> If you want an answer, ask a question.  Just stating something in the
>> hope that the correction will work as an answer is trying your luck.
> 
> I will try to remember that these are your rules.

In my 34+ years on electronic networks, I’m not sure I’ve ever seen someone try 
so hard to die on a hill not worth dying on.

Best of luck,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Kieren MacMillan]

Hi,

> Let's assume that I'm a moron with a room-temperature IQ and, as
> our friend Kieran McMullen

I assume you mean me, Kieren MacMillan?

> has remarked, "You have no idea what you're talking about."

Could you please remind me where I remarked that?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 19:32, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>> But scm_malloc does not use GC_malloc_uncollectable, it seems, so it
>> too would require explicit markups in order to get internally in
>> Guile.
> 
> Getting "internally in Guile" is done by SCM_NEWSMOB.  Cf
> lily/include/smobs.hh .

OK.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 18:58, David Kastrup  wrote:
>
>> If you bothered looking at the LilyPond code base, you'll find that _no_
>> STL containers are created containing SCM objects in the expectation
>> that they will automagically marked for garbage collection.  Any STL
>> container containing SCM objects is either locally used for existing SCM
>> objects protected elsewhere, or its containing object is SCM controlled
>> and uses mark hooks for marking the elements of the STL container during
>> garbage collection scans.  There are even mechanisms for making sure
>> that the STL containers are fully initialized before a derived class may
>> have its mark hook triggered.
>
> But scm_malloc does not use GC_malloc_uncollectable, it seems, so it
> too would require explicit markups in order to get internally in
> Guile.

Getting "internally in Guile" is done by SCM_NEWSMOB.  Cf
lily/include/smobs.hh .

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 18:58, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 23 May 2018, at 18:36, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
> On 23 May 2018, at 18:12, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>> I ended up using GC_malloc_uncollectable, because it turned out too
>> tricky to use malloc.
> 
> This is C++, so we basically end up with operator ::new and operator
> ::delete unless overriden by individual classes.  They use
 
 This what they suggest for the Boehm GC, and it is what caused
 problems in my program.
>>> 
>>> Likely because of the expectation that it would be managed by the Boehm
>>> GC.  The Guilev2 documentation states:
>>> 
>>>  For memory that is not associated with a Scheme object, you can
>>>   use ‘scm_malloc’ instead of ‘malloc’.  Like ‘scm_gc_malloc’, it will
>>>   either return a valid pointer or signal an error.  However, it will
>>>   not assume that the new memory block can be freed by a garbage
>>>   collection.  The memory must be explicitly freed with ‘free’.
>>> 
>>> So memory allocated with the standard allocator in a Guile application
>>> is not managed by the Boehm GC.
>> 
>> The object has a container with GC objects, so using using standard
>> allocation for the container causes the GC to not trace the objects in
>> the container, and will thus collect them.
> 
> If you bothered looking at the LilyPond code base, you'll find that _no_
> STL containers are created containing SCM objects in the expectation
> that they will automagically marked for garbage collection.  Any STL
> container containing SCM objects is either locally used for existing SCM
> objects protected elsewhere, or its containing object is SCM controlled
> and uses mark hooks for marking the elements of the STL container during
> garbage collection scans.  There are even mechanisms for making sure
> that the STL containers are fully initialized before a derived class may
> have its mark hook triggered.

But scm_malloc does not use GC_malloc_uncollectable, it seems, so it too would 
require explicit markups in order to get internally in Guile.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 18:36, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 23 May 2018, at 18:12, David Kastrup  wrote:
 
 Hans Åberg  writes:
 
> I ended up using GC_malloc_uncollectable, because it turned out too
> tricky to use malloc.
 
 This is C++, so we basically end up with operator ::new and operator
 ::delete unless overriden by individual classes.  They use
>>> 
>>> This what they suggest for the Boehm GC, and it is what caused
>>> problems in my program.
>> 
>> Likely because of the expectation that it would be managed by the Boehm
>> GC.  The Guilev2 documentation states:
>> 
>>   For memory that is not associated with a Scheme object, you can
>>use ‘scm_malloc’ instead of ‘malloc’.  Like ‘scm_gc_malloc’, it will
>>either return a valid pointer or signal an error.  However, it will
>>not assume that the new memory block can be freed by a garbage
>>collection.  The memory must be explicitly freed with ‘free’.
>> 
>> So memory allocated with the standard allocator in a Guile application
>> is not managed by the Boehm GC.
>
> The object has a container with GC objects, so using using standard
> allocation for the container causes the GC to not trace the objects in
> the container, and will thus collect them.

If you bothered looking at the LilyPond code base, you'll find that _no_
STL containers are created containing SCM objects in the expectation
that they will automagically marked for garbage collection.  Any STL
container containing SCM objects is either locally used for existing SCM
objects protected elsewhere, or its containing object is SCM controlled
and uses mark hooks for marking the elements of the STL container during
garbage collection scans.  There are even mechanisms for making sure
that the STL containers are fully initialized before a derived class may
have its mark hook triggered.

> And I found no reference to it in LilyPond, so I got curious about
> how you do it. But you are not going to tell me, so forget about it.
 
 You know, if you actually bothered _asking_, you'd increase your
 chances of getting an answer.
>>> 
>>> Typically when the item is brought up people would say "Yes, we use
>>> this or that", rather than long bodies of text with no such
>>> information.
>> 
>> If you want an answer, ask a question.  Just stating something in the
>> hope that the correction will work as an answer is trying your luck.
>
> I will try to remember that these are your rules.

You'll find that most humans operate in that manner.  Just stating
something potentially erroneous and then seeing what diagnostics you get
is how you talk with computers.  Computers have no feelings, so they
don't get annoyed in this manner.  Humans happen to be different.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 18:36, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 23 May 2018, at 18:12, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
 I ended up using GC_malloc_uncollectable, because it turned out too
 tricky to use malloc.
>>> 
>>> This is C++, so we basically end up with operator ::new and operator
>>> ::delete unless overriden by individual classes.  They use
>> 
>> This what they suggest for the Boehm GC, and it is what caused
>> problems in my program.
> 
> Likely because of the expectation that it would be managed by the Boehm
> GC.  The Guilev2 documentation states:
> 
>   For memory that is not associated with a Scheme object, you can
>use ‘scm_malloc’ instead of ‘malloc’.  Like ‘scm_gc_malloc’, it will
>either return a valid pointer or signal an error.  However, it will
>not assume that the new memory block can be freed by a garbage
>collection.  The memory must be explicitly freed with ‘free’.
> 
> So memory allocated with the standard allocator in a Guile application
> is not managed by the Boehm GC.

The object has a container with GC objects, so using using standard allocation 
for the container causes the GC to not trace the objects in the container, and 
will thus collect them.

 And I found no reference to it in LilyPond, so I got curious about
 how you do it. But you are not going to tell me, so forget about it.
>>> 
>>> You know, if you actually bothered _asking_, you'd increase your
>>> chances of getting an answer.
>> 
>> Typically when the item is brought up people would say "Yes, we use
>> this or that", rather than long bodies of text with no such
>> information.
> 
> If you want an answer, ask a question.  Just stating something in the
> hope that the correction will work as an answer is trying your luck.

I will try to remember that these are your rules.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 18:12, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
>>> I ended up using GC_malloc_uncollectable, because it turned out too
>>> tricky to use malloc.
>> 
>> This is C++, so we basically end up with operator ::new and operator
>> ::delete unless overriden by individual classes.  They use
>
> This what they suggest for the Boehm GC, and it is what caused
> problems in my program.

Likely because of the expectation that it would be managed by the Boehm
GC.  The Guilev2 documentation states:

   For memory that is not associated with a Scheme object, you can
use ‘scm_malloc’ instead of ‘malloc’.  Like ‘scm_gc_malloc’, it will
either return a valid pointer or signal an error.  However, it will
not assume that the new memory block can be freed by a garbage
collection.  The memory must be explicitly freed with ‘free’.

So memory allocated with the standard allocator in a Guile application
is not managed by the Boehm GC.

>>> And I found no reference to it in LilyPond, so I got curious about
>>> how you do it. But you are not going to tell me, so forget about it.
>> 
>> You know, if you actually bothered _asking_, you'd increase your
>> chances of getting an answer.
>
> Typically when the item is brought up people would say "Yes, we use
> this or that", rather than long bodies of text with no such
> information.

If you want an answer, ask a question.  Just stating something in the
hope that the correction will work as an answer is trying your luck.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 18:12, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>> I ended up using GC_malloc_uncollectable, because it turned out too
>> tricky to use malloc.
> 
> This is C++, so we basically end up with operator ::new and operator
> ::delete unless overriden by individual classes.  They use

This what they suggest for the Boehm GC, and it is what caused problems in my 
program.

> ...the
> equivalent of GC_malloc_uncollectable.

So what exactly is this in the Boehm GC?

>> And I found no reference to it in LilyPond, so I got curious about how
>> you do it. But you are not going to tell me, so forget about it.
> 
> You know, if you actually bothered _asking_, you'd increase your chances
> of getting an answer.

Typically when the item is brought up people would say "Yes, we use this or 
that", rather than long bodies of text with no such information.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 16:15, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 23 May 2018, at 15:46, David Kastrup  wrote:
 
 Try actually reading the code.  lily/include/smobs* are not that many
 files and nowadays pretty exclusively encapsulate all Scheme-related
 memory management.
>>> 
>>> As long you don't have pointers into that, as you suggested with
>>> Rational and other data that uses it.
>> 
>> Look, you are just stabbing around in the dark here.  Quite a few of
>> your statements don't even make sense.  You need to get yourself
>> acquainted with the code if you want to get anywhere.  Rational is not a
>> structure containing garbage-collected elements or pointers.
>
> The thread started with suggestions for changing that.

Correct.

>> It's fixed-size which is what triggered the original poster's
>> complaints.  Changing that requires work since currently you can use
>> and store Rational everywhere without bothering about garbage
>> collection.  I know perfectly well that the premise of the Boehm GC
>> is that you can do that with SCM values anyway but the cost
>> associated with that is a vastly expanded seed area for the mark pass
>> of garbage collection, basically adding the complete heap.
>
> I ended up using GC_malloc_uncollectable, because it turned out too
> tricky to use malloc.

This is C++, so we basically end up with operator ::new and operator
::delete unless overriden by individual classes.  They use the
equivalent of GC_malloc_uncollectable.

> And I found no reference to it in LilyPond, so I got curious about how
> you do it. But you are not going to tell me, so forget about it.

You know, if you actually bothered _asking_, you'd increase your chances
of getting an answer.

>> LilyPond's data structures are too much of a
>> mixed bag to make that a good idea.
>
> It is indeed slower, but not using it requires isolating it. But is of
> course fine that you are willing to do that.

Sigh.  It's been done for dozens of years already since Guilev1 required
it.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 16:15, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 23 May 2018, at 15:46, David Kastrup  wrote:
>>> 
>>> Try actually reading the code.  lily/include/smobs* are not that many
>>> files and nowadays pretty exclusively encapsulate all Scheme-related
>>> memory management.
>> 
>> As long you don't have pointers into that, as you suggested with
>> Rational and other data that uses it.
> 
> Look, you are just stabbing around in the dark here.  Quite a few of
> your statements don't even make sense.  You need to get yourself
> acquainted with the code if you want to get anywhere.  Rational is not a
> structure containing garbage-collected elements or pointers.

The thread started with suggestions for changing that.

>  It's
> fixed-size which is what triggered the original poster's complaints.
> Changing that requires work since currently you can use and store
> Rational everywhere without bothering about garbage collection.  I know
> perfectly well that the premise of the Boehm GC is that you can do that
> with SCM values anyway but the cost associated with that is a vastly
> expanded seed area for the mark pass of garbage collection, basically
> adding the complete heap.  

I ended up using GC_malloc_uncollectable, because it turned out too tricky to 
use malloc.

And I found no reference to it in LilyPond, so I got curious about how you do 
it. But you are not going to tell me, so forget about it.

> LilyPond's data structures are too much of a
> mixed bag to make that a good idea.

It is indeed slower, but not using it requires isolating it. But is of course 
fine that you are willing to do that.

>>> In contrast to the actual typesetting, the Midi backend is
>>> lackadaisical with its allocations and does not create data
>>> structures connected with the Guile garbage collector.  Nor does it
>>> free them.  The data structures are much more compact than the
>>> typical typesetting stuff but nevertheless this is a memory leak
>>> wanting to get patched up, and in the process of turning its timing
>>> data structures into SCM data structures, this might be a side
>>> benefit.
>> 
>> As long it does not use Rational with a pointer into Guile.
>> 
>> Anyway, you seem to have decided how the LilyPond development should
>> progress.
> 
> No, I decide what I work on and I have the technical expertise to know
> what will work.  As long as nobody else steps up to the plate of the
> core Guile/LilyPond integration with more than advice unrelated to the
> actual code base, that determines how LilyPond development will
> progress.  Poorly, yes, but not for a lack of advice.

You must do it the way you find right.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 15:46, David Kastrup  wrote:
>> 
>> Try actually reading the code.  lily/include/smobs* are not that many
>> files and nowadays pretty exclusively encapsulate all Scheme-related
>> memory management.
>
> As long you don't have pointers into that, as you suggested with
> Rational and other data that uses it.

Look, you are just stabbing around in the dark here.  Quite a few of
your statements don't even make sense.  You need to get yourself
acquainted with the code if you want to get anywhere.  Rational is not a
structure containing garbage-collected elements or pointers.  It's
fixed-size which is what triggered the original poster's complaints.
Changing that requires work since currently you can use and store
Rational everywhere without bothering about garbage collection.  I know
perfectly well that the premise of the Boehm GC is that you can do that
with SCM values anyway but the cost associated with that is a vastly
expanded seed area for the mark pass of garbage collection, basically
adding the complete heap.  LilyPond's data structures are too much of a
mixed bag to make that a good idea.

>> LilyPond has worked for decades on large file sets compiled in
>> sequence and large projects, with a conservative garbage collector
>> with a small seed core area (basically stack and memory explicitly
>> allocated by Guile).  You keep pontificating about problems with
>> solutions that have been known for decades and that have polished
>> abstractions and implementations (which made the Guilev2 migration
>> possible in the first place) in place.
>
> But the Boehm GC is new for Guile 2.

The problems of conservative garbage collection aren't.

>> In contrast to the actual typesetting, the Midi backend is
>> lackadaisical with its allocations and does not create data
>> structures connected with the Guile garbage collector.  Nor does it
>> free them.  The data structures are much more compact than the
>> typical typesetting stuff but nevertheless this is a memory leak
>> wanting to get patched up, and in the process of turning its timing
>> data structures into SCM data structures, this might be a side
>> benefit.
>
> As long it does not use Rational with a pointer into Guile.
>
> Anyway, you seem to have decided how the LilyPond development should
> progress.

No, I decide what I work on and I have the technical expertise to know
what will work.  As long as nobody else steps up to the plate of the
core Guile/LilyPond integration with more than advice unrelated to the
actual code base, that determines how LilyPond development will
progress.  Poorly, yes, but not for a lack of advice.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 15:46, David Kastrup  wrote:
> 
> Try actually reading the code.  lily/include/smobs* are not that many
> files and nowadays pretty exclusively encapsulate all Scheme-related
> memory management.

As long you don't have pointers into that, as you suggested with Rational and 
other data that uses it.

> LilyPond has worked for decades on large file sets compiled in sequence
> and large projects, with a conservative garbage collector with a small
> seed core area (basically stack and memory explicitly allocated by
> Guile).  You keep pontificating about problems with solutions that have
> been known for decades and that have polished abstractions and
> implementations (which made the Guilev2 migration possible in the first
> place) in place.

But the Boehm GC is new for Guile 2.

> In contrast to the actual typesetting, the Midi backend is lackadaisical
> with its allocations and does not create data structures connected with
> the Guile garbage collector.  Nor does it free them.  The data
> structures are much more compact than the typical typesetting stuff but
> nevertheless this is a memory leak wanting to get patched up, and in the
> process of turning its timing data structures into SCM data structures,
> this might be a side benefit.

As long it does not use Rational with a pointer into Guile.

Anyway, you seem to have decided how the LilyPond development should progress.




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 14:34, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
>>> I mentioned that the GC supports traditional allocations/deallocation,
>>> but they must be traced so as to not end up with dead pointers.
>> 
>> Hans, please.  You are proferring utter trivialities.  There is a reason
>> that Guilev2 support is available in a rudimentary form, and the reason
>> is that people actually have bothered dealing with the respective
>> problems and getting Boehm GC bugs flagged and fixed or at least worked
>> around in the Guile and LilyPond code bases.
>> 
>> If you don't believe me, feel free to make yourself acquainted with the
>> respective code.  You want to offer advice but at your current level of
>> knowledge about LilyPond, it would be a rather strange coincidence if
>> you could offer anything not already well-known and well-considered.
>
> They are not mentioned in the link you gave, so it looks as though
> like you insist on using untraceable containers, which of course, will
> end up with dead pointers.

Try actually reading the code.  lily/include/smobs* are not that many
files and nowadays pretty exclusively encapsulate all Scheme-related
memory management.

LilyPond has worked for decades on large file sets compiled in sequence
and large projects, with a conservative garbage collector with a small
seed core area (basically stack and memory explicitly allocated by
Guile).  You keep pontificating about problems with solutions that have
been known for decades and that have polished abstractions and
implementations (which made the Guilev2 migration possible in the first
place) in place.

LilyPond could not have worked in the manner it did for most of its
existence if the assumptions underlying your continued "advice" were
valid.  Really, if you want to offer anything of value, there is no way
around getting your eyes dirty and actually reading and working with the
code.

In contrast to the actual typesetting, the Midi backend is lackadaisical
with its allocations and does not create data structures connected with
the Guile garbage collector.  Nor does it free them.  The data
structures are much more compact than the typical typesetting stuff but
nevertheless this is a memory leak wanting to get patched up, and in the
process of turning its timing data structures into SCM data structures,
this might be a side benefit.

There are a few other areas in want of cleanup.  But advice is the last
thing that is needed here: actual work on and with the code is called
for.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 14:34, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>> I mentioned that the GC supports traditional allocations/deallocation,
>> but they must be traced so as to not end up with dead pointers.
> 
> Hans, please.  You are proferring utter trivialities.  There is a reason
> that Guilev2 support is available in a rudimentary form, and the reason
> is that people actually have bothered dealing with the respective
> problems and getting Boehm GC bugs flagged and fixed or at least worked
> around in the Guile and LilyPond code bases.
> 
> If you don't believe me, feel free to make yourself acquainted with the
> respective code.  You want to offer advice but at your current level of
> knowledge about LilyPond, it would be a rather strange coincidence if
> you could offer anything not already well-known and well-considered.

They are not mentioned in the link you gave, so it looks as though like you 
insist on using untraceable containers, which of course, will end up with dead 
pointers.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 13:10, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 23 May 2018, at 12:20, David Kastrup  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.
>
> I mentioned that the GC supports traditional allocations/deallocation,
>
>> 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.
>
> ...but they must be traced so as to not end up with dead pointers.

Hans, please.  You are proferring utter trivialities.  There is a reason
that Guilev2 support is available in a rudimentary form, and the reason
is that people actually have bothered dealing with the respective
problems and getting Boehm GC bugs flagged and fixed or at least worked
around in the Guile and LilyPond code bases.

If you don't believe me, feel free to make yourself acquainted with the
respective code.  You want to offer advice but at your current level of
knowledge about LilyPond, it would be a rather strange coincidence if
you could offer anything not already well-known and well-considered.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 13:10, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 23 May 2018, at 12:20, David Kastrup  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.

I mentioned that the GC supports traditional allocations/deallocation,

> 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.

...but they must be traced so as to not end up with dead pointers.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 12:20, David Kastrup  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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 12:20, David Kastrup  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?

> 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.

>> 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.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 11:04, Werner LEMBERG  wrote:
>> 
>>> The ultimate in self-assertion is to disagree with those that agree
>>> with you.
>> 
>> Hans, such remarks aren't helpful.  You sound like you are lecturing.
>> Maybe this is not your intention and you have serious questions – if
>> this is so, please be more careful in formulation.
>
> It means that I am telling what I think the problem is and how to fix
> it,

Sorry to say so, Hans, but 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.

So if you want to be helpful, let go of your consultants' hat and don
the programmers' hat.

> 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 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.

Now the set of "everybody involved with LilyPond programming" is smaller
than I'd like it to be, and I do my best to lower the barriers of entry.
But the working set acting on garbage collection is rather tiny, and
being a rather smart guy is just the entry fee and not a winning ticket.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 11:04, Werner LEMBERG  wrote:
> 
>> The ultimate in self-assertion is to disagree with those that agree
>> with you.
> 
> Hans, such remarks aren't helpful.  You sound like you are lecturing.
> Maybe this is not your intention and you have serious questions – if
> this is so, please be more careful in formulation.

It means that I am telling what I think the problem is and how to fix it, and 
instead of a suitable reply, I get an endless row of rants, and now you fill in 
with those.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Werner LEMBERG]

> The ultimate in self-assertion is to disagree with those that agree
> with you.

Hans, such remarks aren't helpful.  You sound like you are lecturing.
Maybe this is not your intention and you have serious questions – if
this is so, please be more careful in formulation.


   Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 10:39, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 23 May 2018, at 00:41, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
> On 22 May 2018, at 23:28, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
 I wrote a C++ wrap for that latter, too. As it turns out to be
 difficult to keep of pointers into the GC heap, I had to use only
 those that it supplies. Do you do that?
>>> 
>>> I don't know what "I had to use only those that it supplies" is supposed
>>> to mean, so I cannot answer the question.
>> 
>> In addition to the collected GC_malloc, there are
>> GC_malloc_uncollectable and GC_free that correspond to malloc and
>> free. If one uses the latter pair and have pointers into the GC heap,
>> they may suddenly disappear, causing strange memory errors.
> 
> That's why we don't do that.
> 
>> In addition, beware that on some platforms, the GC must be initialized
>> before the first use (like on MacOS), and if one is using global C++
>> objects with heap allocations, that must occur before those being
>> initialized, which is before 'main' starts.
> 
> Uhm, you _are_ aware that LilyPond has been used for large scores with
> Guile data structures for 20+ years?  Don't you think people might have
> noticed a problem in the mean time?  If you want to contribute useful
> advice, it might be a good idea to actually look into the LilyPond code
> base.  The vast majority of LilyPond's memory management in connection
> with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .
 
 So you don't know anything about the Boehm GC?
>>> 
>>> Is there a point to this silliness?
>>> 
>>> 
>>> 
>>> Apparently I got to know enough to distill a test case showing that
>>> Guilev2's type system was critically affected by a bug in the Boehm GC's
>>> use of finalizers, leading to workarounds first in the LilyPond code
>>> base and later on in Guile proper.
>> 
>> Relative to that, which seems to be a problem with dead, collected
>> pointers, if one is using what I said above, then the GC keeps those
>> objects pointed at alive.
> 
> How come all of those smart guys knowing better than myself how LilyPond
> works and how garbage collection works and how C++ works can never be
> seen creating a single patch but instead have to rely on telling some
> simpleton like myself how he should be doing things?
> 
> Seriously folks, if you think you are so much more intelligent, get to
> work rather than bother lecturing a moron like myself.

The ultimate in self-assertion is to disagree with those that agree with you.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 23 May 2018, at 00:41, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 22 May 2018, at 23:28, David Kastrup  wrote:
 
 Hans Åberg  writes:
 
>>> I wrote a C++ wrap for that latter, too. As it turns out to be
>>> difficult to keep of pointers into the GC heap, I had to use only
>>> those that it supplies. Do you do that?
>> 
>> I don't know what "I had to use only those that it supplies" is supposed
>> to mean, so I cannot answer the question.
> 
> In addition to the collected GC_malloc, there are
> GC_malloc_uncollectable and GC_free that correspond to malloc and
> free. If one uses the latter pair and have pointers into the GC heap,
> they may suddenly disappear, causing strange memory errors.
 
 That's why we don't do that.
 
> In addition, beware that on some platforms, the GC must be initialized
> before the first use (like on MacOS), and if one is using global C++
> objects with heap allocations, that must occur before those being
> initialized, which is before 'main' starts.
 
 Uhm, you _are_ aware that LilyPond has been used for large scores with
 Guile data structures for 20+ years?  Don't you think people might have
 noticed a problem in the mean time?  If you want to contribute useful
 advice, it might be a good idea to actually look into the LilyPond code
 base.  The vast majority of LilyPond's memory management in connection
 with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .
>>> 
>>> So you don't know anything about the Boehm GC?
>> 
>> Is there a point to this silliness?
>> 
>> 
>> 
>> Apparently I got to know enough to distill a test case showing that
>> Guilev2's type system was critically affected by a bug in the Boehm GC's
>> use of finalizers, leading to workarounds first in the LilyPond code
>> base and later on in Guile proper.
>
> Relative to that, which seems to be a problem with dead, collected
> pointers, if one is using what I said above, then the GC keeps those
> objects pointed at alive.

How come all of those smart guys knowing better than myself how LilyPond
works and how garbage collection works and how C++ works can never be
seen creating a single patch but instead have to rely on telling some
simpleton like myself how he should be doing things?

Seriously folks, if you think you are so much more intelligent, get to
work rather than bother lecturing a moron like myself.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 23 May 2018, at 00:41, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 22 May 2018, at 23:28, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
>> I wrote a C++ wrap for that latter, too. As it turns out to be
>> difficult to keep of pointers into the GC heap, I had to use only
>> those that it supplies. Do you do that?
> 
> I don't know what "I had to use only those that it supplies" is supposed
> to mean, so I cannot answer the question.
 
 In addition to the collected GC_malloc, there are
 GC_malloc_uncollectable and GC_free that correspond to malloc and
 free. If one uses the latter pair and have pointers into the GC heap,
 they may suddenly disappear, causing strange memory errors.
>>> 
>>> That's why we don't do that.
>>> 
 In addition, beware that on some platforms, the GC must be initialized
 before the first use (like on MacOS), and if one is using global C++
 objects with heap allocations, that must occur before those being
 initialized, which is before 'main' starts.
>>> 
>>> Uhm, you _are_ aware that LilyPond has been used for large scores with
>>> Guile data structures for 20+ years?  Don't you think people might have
>>> noticed a problem in the mean time?  If you want to contribute useful
>>> advice, it might be a good idea to actually look into the LilyPond code
>>> base.  The vast majority of LilyPond's memory management in connection
>>> with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .
>> 
>> So you don't know anything about the Boehm GC?
> 
> Is there a point to this silliness?
> 
> 
> 
> Apparently I got to know enough to distill a test case showing that
> Guilev2's type system was critically affected by a bug in the Boehm GC's
> use of finalizers, leading to workarounds first in the LilyPond code
> base and later on in Guile proper.

Relative to that, which seems to be a problem with dead, collected pointers, if 
one is using what I said above, then the GC keeps those objects pointed at 
alive.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

metachromatic  writes:

>   To get back to practicalities, here is an absolutely minimal example
> of the alleged problems with using rationals as internal
> representations of durations/positions in Lilypond.

It is a known problem with know workarounds (basically you need to apply
scaling factors bringing back the actual durations to a reasonably
fine-grained raster) and Midi cannot represent arbitrary rationals
anyway.

>"So what's wrong?" you say. "What's the problem?"
>
>Here's the problem: uncomment the third to last tuplet and rerun Lilypond.
>
>Then uncomment the second to last tuplet and rerun Lilypond.
>
>Now rerun the last tuplet and rerun Lilypond.
>
>Attached as a PNG, the output for
>
>A) last 3 tuplets commented out.
>
>B) last 2 tuplets commented out.
>
>C) no tuplets commented out.
>
>Let's assume that I'm a moron with a room-temperature IQ and, as
> our friend Kieran McMullen has remarked, "You have no idea what you're
> talking about." Fine, assume I'm not only dumb as a box of rocks, but
> also hopelessly ignorant.

You don't understand the problem you are failing to deal with.  It is
not a technical problem but a social one.  You are trying to get people
to work for you by cussing at them.  That may work on people getting
your pay checks from you, at least until they leave for employers with a
better appreciation of their work, leaving you with less capable
workers.

It doesn't when you are talking to volunteers.

>So since we can't take my word for it, how do we actually _know_
> that the internal representation of integers is making Lilypond blow
> up when it tries to generate a score for more than the first 7 tuplets
> in the above example?

It's reasonably easy to create an engraver giving out the current time.

>Now, why did Lilypond's internal position jump to such large
> numbers merely by uncommenting one measly little tuplet?
>
>Because all the tuplets are prime. Evidently, no programmer ever
> imagined any composer would want to use a bunch of tuplets that were
> prime numbers.

Well, evidently no composer with the brains to apply rational
adjustments to his note lengths to coax LilyPond into cooperation or a
rational style of discussion with people supposed to help him for free.

€6000 and the temporary fix is yours.  Temporary because we are talking
about systematic input like this not failing after 3 measures but after
20 while LilyPond is pretty much crawling to halt.

For proper typesetting of things, LilyPond needs to know whether two
notes happen simultaneously or not.  Even timing differences that are
not distinguishable acoustically need to be distingushed visually (one
stem or two?).  So it uses exact arithmetic.  It's only you who can
decide which notes in an arbitrarily fine raster coincide and round them
to identical point on a fine raster, giving them a common stem.

Really, you have to understand that this is a well-known issue
extraordinarily hard to even mitigate (due to even Guile/GMP integers
being ultimately limited in size and you deliberately growing them in
size) and you are trying to fix it with name-calling and a show of
condescension.

>   Now, call me overly picky, but it seems to me that in the 21st
> century, with multicore CPUs and 16 gigs of RAM and a modern language
> like Scheme and expert programmers, we really seriously ought to be
> able to do better with a program like Lilypond than

[Rest of condescending rant clueless about the actual problems involved
here deleted]

Go ahead.  It should be simple for such a smart guy as yourself to fix
it.  Not talk about how others are supposed to fix it, but rather fix it
yourself.  Obviously your level of intelligence is so far above that of
LilyPond's programmers that you should be done in a week.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Flaming Hakama by Elaine]

> From: metachromatic <metachroma...@gmail.com>
> Subject: Re: Rational
>



> ===
>
> \version "2.18.2"
>
> \score {
>
> <<
>
> \new Staff {
> \clef "treble"
> \override TupletNumber.text = #tuplet-number::calc-fraction-text
> \override Staff.TimeSignature #'stencil = ##f
> \omit Score.BarLine
> \relative c''
> {
> \tuplet 53/37{r4}
> \tuplet 43/29{c8}
> r8
> \tuplet 3/2{d8}
> \tuplet 19/13 {e8[ d8 c8]}
> \tuplet 11/7{b4.}
> \tuplet 17/13{g8}
> r8
> \tuplet 61/47{r4}
> %\tuplet 31/23{a8}
> %\tuplet 89/79 {b4}
> %\tuplet 97/41{r4}
>
> }
>
> }
> >>
>
> }
>


>So let's ask ourselves, as a practical matter, what kind of
> accuracy does Lilypond _really_ need internally?
>


>   So what we'd like is for no note in a Lilypond score to be off by
> more than 1/31,250 of a second in (oh, let's say) 100 page of score.
> That means we need a timing accuracy of 1/100*(1/31250) second =
> 1/(3.125) microseconds. That works out to an accuracy of (ballpark) 3
> parts in 10 million.
>


If you think you (or any human) can audibly distinguish among these
durations, you are even more delusional than you are lacking in social
graces.

>From a CS perspective, this might be an interesting theoretical problem.

But it lies entirely outside the realm of music.


Sincerely,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[metachromatic]

  To get back to practicalities, here is an absolutely minimal example
of the alleged problems with using rationals as internal
representations of durations/positions in Lilypond.

  Please note that I use the term "alleged problems" because it might
not be clear to everyone that this internal integer representation
issue critically affects real music in the real world in a crippling
way. With any luck, this elementary example should illustrate

  1) that the internal use of rationals in Lilypond is a genuine
problem, not some deluded fantasy;

   2) that the use of rationals internally in Lilypond isn't some airy
abstract issue of concern only to the most abstruse programming
honchos, but instead blows away actual composers working with real
music in the real world, and does it in a brutal way. And I do mean
brutal. As in "sorry, you can't enter more than 7 tuplets without
Lilypond blowing up and crashing" depending on the tuplets.

   Here's some dead-simple Lilypond code that illustrates the problem:

===

\version "2.18.2"

\score {

<<

\new Staff {
\clef "treble"
\override TupletNumber.text = #tuplet-number::calc-fraction-text
\override Staff.TimeSignature #'stencil = ##f
\omit Score.BarLine
\relative c''
{
\tuplet 53/37{r4}
\tuplet 43/29{c8}
r8
\tuplet 3/2{d8}
\tuplet 19/13 {e8[ d8 c8]}
\tuplet 11/7{b4.}
\tuplet 17/13{g8}
r8
\tuplet 61/47{r4}
%\tuplet 31/23{a8}
%\tuplet 89/79 {b4}
%\tuplet 97/41{r4}

}

}
>>

}

===

   "So what's wrong?" you say. "What's the problem?"

   Here's the problem: uncomment the third to last tuplet and rerun Lilypond.

   Then uncomment the second to last tuplet and rerun Lilypond.

   Now rerun the last tuplet and rerun Lilypond.

   Attached as a PNG, the output for

   A) last 3 tuplets commented out.

   B) last 2 tuplets commented out.

   C) no tuplets commented out.

   Let's assume that I'm a moron with a room-temperature IQ and, as
our friend Kieran McMullen has remarked, "You have no idea what you're
talking about." Fine, assume I'm not only dumb as a box of rocks, but
also hopelessly ignorant.

   So since we can't take my word for it, how do we actually _know_
that the internal representation of integers is making Lilypond blow
up when it tries to generate a score for more than the first 7 tuplets
in the above example?

   Well, Lilypond actually gives us information about the internal
representation of durations/positions of the notes. It does this when
you position the cursor in front of the various tuplets, and before
you run Lilypond to produce the score.

  Placing the cursor in front of the 7th tuplet \tuplet 61/47{r4}
tells you the position Lilypond has given to that note:
114945929/97167444.

  Now let's uncomment the 8th tuplet \tuplet 31/23{a8} and place the
cursor in front of it, without running Lilypond to generate a score.
What does Lilypond say the position of that note is?

  2038354784/1481803521.

  That's 203 million over 1.4 billion, roughly, whereas the previous
rational fraction was about 115 million over 97 million.

   Now, why did Lilypond's internal position jump to such large
numbers merely by uncommenting one measly little tuplet?

   Because all the tuplets are prime. Evidently, no programmer ever
imagined any composer would want to use a bunch of tuplets that were
prime numbers. (Why not? Well...further, deponent sayeth not.)  To
generate an internal position for the notes, Lilypond clearly uses
some kind of Least Common Multiple algorithm. Trouble is, when you
have a bunch of prime numbers in both numerators and denominators of
your tuplets, that LCM grows _very_ fast. In fact, the LCM for a set
of absolutely prime number tuplets grows even faster than the
factorial function...and that's pretty fast.

  So the problem Lilypond runs into is that it must calculate a Least
Common Multiple after the first 8 tuplets for the quantity

  61*53*47*43*37*29*19*17*13*11*7*3*2 = 1.3600648 times 10^16.

  You can see the problem, and it only gets worse after the 8th
tuplet. By the 9th tuplet we need a Least Common Multiple of 89*79*
(61*53*47*43*37*29*19*17*13*11*7*3*2) =

  9.5626154 times 10^19

  By the 10th tuplet, we need a Least Common Multiple of 97*41 *
(89*79*61*53*47*43*37*29*19*17*13*11*7*3*2) =

  3.8030521 times 10^23.

  And so it goes, as Vonnegut was wont to say.  Bottom line?  Using
different prime numbers in both numerator and denominator of your
tuplets very quickly runs Lilypond out of integer headroom to
represent the notes internally.

  How quickly is "very quickly"?

  7 tuplets.

  Count 'em, ladies and gents: 7 (that's seven) tuplets.

  Now, call me overly picky, but it seems to me that in the 21st
century, with multicore CPUs and 16 gigs of RAM and a modern language
like Scheme and expert programmers, we really seriously ought to be
able to do better with a program like Lilypond than

   ...Blowing up if the program tries to generate a score with more
than seven tuplets.

   I 

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 22 May 2018, at 23:28, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 22 May 2018, at 22:53, David Kastrup  wrote:
 
>> This was somewhat complicated by some Midi classes being heap-allocated
>> and containing Rational/Moment members: those Midi classes would have to
>> become SCM-connected.  I did some work on that, don't remember how
>> complete it was.
> 
> Guile uses the Boehm GC.
 
 Not Guile 1, and LilyPond will have large amounts of heap space outside
 of Boehm's fully automated sweep areas even in Guile 2 for efficiency
 and compatibility reasons.
>>> 
>>> Something for the future then.
>>> 
> I wrote a C++ wrap for that latter, too. As it turns out to be
> difficult to keep of pointers into the GC heap, I had to use only
> those that it supplies. Do you do that?
 
 I don't know what "I had to use only those that it supplies" is supposed
 to mean, so I cannot answer the question.
>>> 
>>> In addition to the collected GC_malloc, there are
>>> GC_malloc_uncollectable and GC_free that correspond to malloc and
>>> free. If one uses the latter pair and have pointers into the GC heap,
>>> they may suddenly disappear, causing strange memory errors.
>> 
>> That's why we don't do that.
>> 
>>> In addition, beware that on some platforms, the GC must be initialized
>>> before the first use (like on MacOS), and if one is using global C++
>>> objects with heap allocations, that must occur before those being
>>> initialized, which is before 'main' starts.
>> 
>> Uhm, you _are_ aware that LilyPond has been used for large scores with
>> Guile data structures for 20+ years?  Don't you think people might have
>> noticed a problem in the mean time?  If you want to contribute useful
>> advice, it might be a good idea to actually look into the LilyPond code
>> base.  The vast majority of LilyPond's memory management in connection
>> with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .
>
> So you don't know anything about the Boehm GC?

Is there a point to this silliness?



Apparently I got to know enough to distill a test case showing that
Guilev2's type system was critically affected by a bug in the Boehm GC's
use of finalizers, leading to workarounds first in the LilyPond code
base and later on in Guile proper.

I appreciate that you are trying to be helpful but the state of my
involvement with Guilev2 (and consequently also the Boehm GC) is such
that one needs to have been living under the proverbial rock regarding
the developer mailing list traffic to assume that I have no idea about
the details of the memory management components of the Guilev2
transition.

For better or worse, we have moved seriously beyond the point where
smart off-hand observations are going to be the saving grace of the day.
Really, you'll need to invest more than that if you want to make a
difference.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 22 May 2018, at 23:28, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 22 May 2018, at 22:53, David Kastrup  wrote:
>>> 
> This was somewhat complicated by some Midi classes being heap-allocated
> and containing Rational/Moment members: those Midi classes would have to
> become SCM-connected.  I did some work on that, don't remember how
> complete it was.
 
 Guile uses the Boehm GC.
>>> 
>>> Not Guile 1, and LilyPond will have large amounts of heap space outside
>>> of Boehm's fully automated sweep areas even in Guile 2 for efficiency
>>> and compatibility reasons.
>> 
>> Something for the future then.
>> 
 I wrote a C++ wrap for that latter, too. As it turns out to be
 difficult to keep of pointers into the GC heap, I had to use only
 those that it supplies. Do you do that?
>>> 
>>> I don't know what "I had to use only those that it supplies" is supposed
>>> to mean, so I cannot answer the question.
>> 
>> In addition to the collected GC_malloc, there are
>> GC_malloc_uncollectable and GC_free that correspond to malloc and
>> free. If one uses the latter pair and have pointers into the GC heap,
>> they may suddenly disappear, causing strange memory errors.
> 
> That's why we don't do that.
> 
>> In addition, beware that on some platforms, the GC must be initialized
>> before the first use (like on MacOS), and if one is using global C++
>> objects with heap allocations, that must occur before those being
>> initialized, which is before 'main' starts.
> 
> Uhm, you _are_ aware that LilyPond has been used for large scores with
> Guile data structures for 20+ years?  Don't you think people might have
> noticed a problem in the mean time?  If you want to contribute useful
> advice, it might be a good idea to actually look into the LilyPond code
> base.  The vast majority of LilyPond's memory management in connection
> with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .

So you don't know anything about the Boehm GC?



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 22 May 2018, at 22:53, David Kastrup  wrote:
>> 
 This was somewhat complicated by some Midi classes being heap-allocated
 and containing Rational/Moment members: those Midi classes would have to
 become SCM-connected.  I did some work on that, don't remember how
 complete it was.
>>> 
>>> Guile uses the Boehm GC.
>> 
>> Not Guile 1, and LilyPond will have large amounts of heap space outside
>> of Boehm's fully automated sweep areas even in Guile 2 for efficiency
>> and compatibility reasons.
>
> Something for the future then.
>
>>> I wrote a C++ wrap for that latter, too. As it turns out to be
>>> difficult to keep of pointers into the GC heap, I had to use only
>>> those that it supplies. Do you do that?
>> 
>> I don't know what "I had to use only those that it supplies" is supposed
>> to mean, so I cannot answer the question.
>
> In addition to the collected GC_malloc, there are
> GC_malloc_uncollectable and GC_free that correspond to malloc and
> free. If one uses the latter pair and have pointers into the GC heap,
> they may suddenly disappear, causing strange memory errors.

That's why we don't do that.

> In addition, beware that on some platforms, the GC must be initialized
> before the first use (like on MacOS), and if one is using global C++
> objects with heap allocations, that must occur before those being
> initialized, which is before 'main' starts.

Uhm, you _are_ aware that LilyPond has been used for large scores with
Guile data structures for 20+ years?  Don't you think people might have
noticed a problem in the mean time?  If you want to contribute useful
advice, it might be a good idea to actually look into the LilyPond code
base.  The vast majority of LilyPond's memory management in connection
with Guile is in lily/include/smobs.hh and lily/include/smobs.tcc .

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 22 May 2018, at 22:53, David Kastrup  wrote:
> 
>>> This was somewhat complicated by some Midi classes being heap-allocated
>>> and containing Rational/Moment members: those Midi classes would have to
>>> become SCM-connected.  I did some work on that, don't remember how
>>> complete it was.
>> 
>> Guile uses the Boehm GC.
> 
> Not Guile 1, and LilyPond will have large amounts of heap space outside
> of Boehm's fully automated sweep areas even in Guile 2 for efficiency
> and compatibility reasons.

Something for the future then.

>> I wrote a C++ wrap for that latter, too. As it turns out to be
>> difficult to keep of pointers into the GC heap, I had to use only
>> those that it supplies. Do you do that?
> 
> I don't know what "I had to use only those that it supplies" is supposed
> to mean, so I cannot answer the question.

In addition to the collected GC_malloc, there are GC_malloc_uncollectable and 
GC_free that correspond to malloc and free. If one uses the latter pair and 
have pointers into the GC heap, they may suddenly disappear, causing strange 
memory errors.

In addition, beware that on some platforms, the GC must be initialized before 
the first use (like on MacOS), and if one is using global C++ objects with heap 
allocations, that must occur before those being initialized, which is before 
'main' starts.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 22 May 2018, at 22:07, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 22 May 2018, at 20:45, David Kastrup  wrote:
 
 LilyPond's "rational" type should indeed get replaced
 by Guile's rational types which would seriously shift the threshold
 where things start breaking apart at the cost of efficiency.
 
 That's quite a lot of tedious work (I have some started patches for
 different approaches to that) but of course if its seminal for someone's
 _own_ work, the motivation for finishing that might be larger.
>>> 
>>> Guile uses GMP internally, and it might be fairly easy to change the
>>> class Rational to use GMP. Have you considered that?
>> 
>> Pointless.  The principal problem is that Rational is a fixed size
>> struct without additional allocations to keep track of.  Guile's SCM
>> isn't, and GMP's numbers aren't.  The garbage collection situation
>> becomes more rather than less complicated by introducing yet another
>> SCM-connected GMP type to be collected via Guile.
>
> I realized after my first post that it might better to write it
> directly onto Guile. I wrote a C++ wrap for Guile:
>   https://web2.storegate.com/share/TN6lmp5
>
>> The grunt work to be done is to make sure that each SCM-connected class
>> having Rational or Moment(!) members calls the respective mark hooks.
>
> What are these mark hooks?
>
>> This was somewhat complicated by some Midi classes being heap-allocated
>> and containing Rational/Moment members: those Midi classes would have to
>> become SCM-connected.  I did some work on that, don't remember how
>> complete it was.
>
> Guile uses the Boehm GC.

Not Guile 1, and LilyPond will have large amounts of heap space outside
of Boehm's fully automated sweep areas even in Guile 2 for efficiency
and compatibility reasons.

> I wrote a C++ wrap for that latter, too. As it turns out to be
> difficult to keep of pointers into the GC heap, I had to use only
> those that it supplies. Do you do that?

I don't know what "I had to use only those that it supplies" is supposed
to mean, so I cannot answer the question.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 22 May 2018, at 22:07, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 22 May 2018, at 20:45, David Kastrup  wrote:
>>> 
>>> LilyPond's "rational" type should indeed get replaced
>>> by Guile's rational types which would seriously shift the threshold
>>> where things start breaking apart at the cost of efficiency.
>>> 
>>> That's quite a lot of tedious work (I have some started patches for
>>> different approaches to that) but of course if its seminal for someone's
>>> _own_ work, the motivation for finishing that might be larger.
>> 
>> Guile uses GMP internally, and it might be fairly easy to change the
>> class Rational to use GMP. Have you considered that?
> 
> Pointless.  The principal problem is that Rational is a fixed size
> struct without additional allocations to keep track of.  Guile's SCM
> isn't, and GMP's numbers aren't.  The garbage collection situation
> becomes more rather than less complicated by introducing yet another
> SCM-connected GMP type to be collected via Guile.

I realized after my first post that it might better to write it directly onto 
Guile. I wrote a C++ wrap for Guile:
  https://web2.storegate.com/share/TN6lmp5

> The grunt work to be done is to make sure that each SCM-connected class
> having Rational or Moment(!) members calls the respective mark hooks.

What are these mark hooks?

> This was somewhat complicated by some Midi classes being heap-allocated
> and containing Rational/Moment members: those Midi classes would have to
> become SCM-connected.  I did some work on that, don't remember how
> complete it was.

Guile uses the Boehm GC. I wrote a C++ wrap for that latter, too. As it turns 
out to be difficult to keep of pointers into the GC heap, I had to use only 
those that it supplies. Do you do that?

> Of course, the kind of abuse one gets for that work is not exactly an
> incentive.

That would probably not be the motivation.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[David Kastrup]

Hans Åberg  writes:

>> On 22 May 2018, at 20:45, David Kastrup  wrote:
>> 
>> LilyPond's "rational" type should indeed get replaced
>> by Guile's rational types which would seriously shift the threshold
>> where things start breaking apart at the cost of efficiency.
>> 
>> That's quite a lot of tedious work (I have some started patches for
>> different approaches to that) but of course if its seminal for someone's
>> _own_ work, the motivation for finishing that might be larger.
>
> Guile uses GMP internally, and it might be fairly easy to change the
> class Rational to use GMP. Have you considered that?

Pointless.  The principal problem is that Rational is a fixed size
struct without additional allocations to keep track of.  Guile's SCM
isn't, and GMP's numbers aren't.  The garbage collection situation
becomes more rather than less complicated by introducing yet another
SCM-connected GMP type to be collected via Guile.

The grunt work to be done is to make sure that each SCM-connected class
having Rational or Moment(!) members calls the respective mark hooks.
This was somewhat complicated by some Midi classes being heap-allocated
and containing Rational/Moment members: those Midi classes would have to
become SCM-connected.  I did some work on that, don't remember how
complete it was.

Of course, the kind of abuse one gets for that work is not exactly an
incentive.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Hans Åberg]

> On 22 May 2018, at 21:10, Hans Åberg  wrote:
> 
> 
>> On 22 May 2018, at 20:45, David Kastrup  wrote:
>> 
>> LilyPond's "rational" type should indeed get replaced
>> by Guile's rational types which would seriously shift the threshold
>> where things start breaking apart at the cost of efficiency.
>> 
>> That's quite a lot of tedious work (I have some started patches for
>> different approaches to that) but of course if its seminal for someone's
>> _own_ work, the motivation for finishing that might be larger.
> 
> Guile uses GMP internally, and it might be fairly easy to change the class 
> Rational to use GMP. Have you considered that?

Actually, I wrote an C++ interface for Guile [1], which includes the numbers, 
exact and inexact. The root class holds a reference to a SCM object. In Guile, 
integers and rational numbers are merged, so that should probably be so in such 
an interface.

1. https://web2.storegate.com/share/TN6lmp5



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel