Re: scheme night-mare...
the big difference came out of the notes.clean() (???) line!
yours, Arno
On Thu, 15 Jul 2010 01:02:07 +0200, Joe Neeman joenee...@gmail.com wrote:
On Wed, Jul 14, 2010 at 3:34 PM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work
much
better now.
Wow! First impression is huge running time reduction. Rough guess 80%
for
my large score. So 400% performance gain...
But in the end it dies again with that memory error, but i wll check for
that.
Is this with git master or with my patch for extra caching?
In my little example it dies differently, obviously an endless loop in
grob-smob.cc:50 according to an endless backtrace in gdb.
This is also a memory problem, since grob-smob.cc:50 is run as part of
guile's garbage collections.
I have uploaded my patch for comments here:
http://codereview.appspot.com/1817045
Cheers,
Joe
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com wrote: On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com wrote: Hi Joe, On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote: Does the attached patch help? For me, it reduces dramatically the number of times that combine_pure_heights (and also ly_scm2interval) is called, but it has very little effect on lilypond's overall running time (for the optimized build, at least). I've just tested this patch (after removing the bits which prevented it from applying; they look like they belong to a fix for issue 1152. :) It has a dramatic effect in several cases: on one 26 page score it's halved the compilation time to just over a minute. Ok, it seems like I should be benchmarking with bigger files; I was just trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on rietveld. Cheers, Joe Hi, with Joe's patch i got with my actual project's big score close to 25% reduction on lilypond run time, which is very nice! After git pull origin (onto Joe's patch) i got: Zeilenumbrüche werden berechnet...terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted Can somebody help me? Thanks, Arno ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote:
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also ly_scm2interval)
is called, but it has very little effect on lilypond's overall
running
time (for the optimized build, at least).
I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue 1152.
:) It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.
Ok, it seems like I should be benchmarking with bigger files; I was just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.
Cheers,
Joe
Hi, with Joe's patch i got with my actual project's big score close to
25% reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:
Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Can somebody help me?
Thanks, Arno
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000, 4 GB memory, 2 GB swap space...
but was i actually had wanted to try was the question whether the layout
goes quicker with manual page breaks (since i thought that would lead to
lily only be looking for layout issues within two manual pagebreaks ...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and
hardly a difference whether the \pageBreak is commented out or not...
Yours, Arno
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote:
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also ly_scm2interval)
is called, but it has very little effect on lilypond's overall running
time (for the optimized build, at least).
I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue 1152.
:) It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.
Ok, it seems like I should be benchmarking with bigger files; I was just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.
Cheers,
Joe
Hi, with Joe's patch i got with my actual project's big score close to 25%
reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:
Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Can somebody help me?
Thanks, Arno
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.
but was i actually had wanted to try was the question whether the layout
goes quicker with manual page breaks (since i thought that would lead to
lily only be looking for layout issues within two manual pagebreaks ...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and hardly
a difference whether the \pageBreak is commented out or not...
As per the discussion on bug 884, \pageBreak no longer speeds up the
page-breaking computation.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman joenee...@gmail.com wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk hamama...@gmx.de
wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote:
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also
ly_scm2interval)
is called, but it has very little effect on lilypond's overall
running
time (for the optimized build, at least).
I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue 1152.
:) It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.
Ok, it seems like I should be benchmarking with bigger files; I was
just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.
Cheers,
Joe
Hi, with Joe's patch i got with my actual project's big score close to
25%
reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:
Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
Can somebody help me?
Thanks, Arno
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.
but was i actually had wanted to try was the question whether the layout
goes quicker with manual page breaks (since i thought that would lead to
lily only be looking for layout issues within two manual pagebreaks
...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and
hardly
a difference whether the \pageBreak is commented out or not...
As per the discussion on bug 884, \pageBreak no longer speeds up the
page-breaking computation.
Cheers,
Joe
Wow! First impression is huge running time reduction. Rough guess 80% for
my large score. So 400% performance gain...
But in the end it dies again with that memory error, but i wll check for
that.
In my little example it dies differently, obviously an endless loop in
grob-smob.cc:50 according to an endless backtrace in gdb.
Hope that helps?
Yours, Arno
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Wed, Jul 14, 2010 at 3:34 PM, Arno Waschk hamama...@gmx.de wrote:
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman joenee...@gmail.com
wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk hamama...@gmx.de wrote:
seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...
looks my score is too long for lilypond, or too many accidentals?
the following:
\version 2.13.28
\layout { ragged-right = ##t }
\relative c' {
\key a \major
\repeat unfold 1000 {
f8 g f g fis gis a a
f8 g f g fis gis a a
%\pageBreak
f8 g f g fis gis a a
f8 g f g fis gis a a}
c r r4 r2
}
dies in Accidental_placement::get_relevant_accidentals
where etls.size is reported as 16000 in the loop. On my machine at
i~13000,
4 GB memory, 2 GB swap space...
I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.
Wow! First impression is huge running time reduction. Rough guess 80% for
my large score. So 400% performance gain...
But in the end it dies again with that memory error, but i wll check for
that.
Is this with git master or with my patch for extra caching?
In my little example it dies differently, obviously an endless loop in
grob-smob.cc:50 according to an endless backtrace in gdb.
This is also a memory problem, since grob-smob.cc:50 is run as part of
guile's garbage collections.
I have uploaded my patch for comments here:
http://codereview.appspot.com/1817045
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
Hi Joe, On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote: Does the attached patch help? For me, it reduces dramatically the number of times that combine_pure_heights (and also ly_scm2interval) is called, but it has very little effect on lilypond's overall running time (for the optimized build, at least). I've just tested this patch (after removing the bits which prevented it from applying; they look like they belong to a fix for issue 1152. :) It has a dramatic effect in several cases: on one 26 page score it's halved the compilation time to just over a minute. On Haipeng's `Harmonious' score (http://lists.gnu.org/archive/html/lilypond-user/2010-07/msg00122.html), I get the following results (both optimized): master: 3m40.766s patched: 2m3.297s Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock n.putt...@gmail.com wrote: Hi Joe, On 13 July 2010 02:18, Joe Neeman joenee...@gmail.com wrote: Does the attached patch help? For me, it reduces dramatically the number of times that combine_pure_heights (and also ly_scm2interval) is called, but it has very little effect on lilypond's overall running time (for the optimized build, at least). I've just tested this patch (after removing the bits which prevented it from applying; they look like they belong to a fix for issue 1152. :) It has a dramatic effect in several cases: on one 26 page score it's halved the compilation time to just over a minute. Ok, it seems like I should be benchmarking with bigger files; I was just trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on rietveld. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
Just finished a profile run with a larger score- ly_scm2interval is reported to have consumd 16% of computation time. There must be something wrong. ... which appears in a loop, which is performed 2 billions times (!) for a 18 a3 page test score. Says gprof... Is that possible/necessary? Yours, Arno -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On 7/12/10 4:48 AM, Arno Waschk hamama...@gmx.de wrote: Just finished a profile run with a larger score- ly_scm2interval is reported to have consumd 16% of computation time. There must be something wrong. ... which appears in a loop, which is performed 2 billions times (!) for a 18 a3 page test score. Says gprof... Is that possible/necessary? Well, if it's an 18 page score, then there are lots of page break options, and so there would be lots of calculations. 2 billion seems like a lot, but there are a lot of ways to figure out line and page breaks in 18 pages of score ly_scm2interval is part of the beam scoring code. So that might be where many of the calls come from. I'm not sure what the fix might be. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen c_soren...@byu.edu wrote: On 7/12/10 4:48 AM, Arno Waschk hamama...@gmx.de wrote: Just finished a profile run with a larger score- ly_scm2interval is reported to have consumd 16% of computation time. There must be something wrong. ... which appears in a loop, which is performed 2 billions times (!) for a 18 a3 page test score. Says gprof... Is that possible/necessary? Well, if it's an 18 page score, then there are lots of page break options, and so there would be lots of calculations. 2 billion seems like a lot, but there are a lot of ways to figure out line and page breaks in 18 pages of score ly_scm2interval is part of the beam scoring code. So that might be where many of the calls come from. no, from the beam thing it is only called ~1000 tmes, the two billion come from a loop in Axis_group_interface::combine_pure_heights (...) Yours, Arno I'm not sure what the fix might be. Carl -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen c_soren...@byu.edu wrote: On 7/12/10 4:48 AM, Arno Waschk hamama...@gmx.de wrote: Just finished a profile run with a larger score- ly_scm2interval is reported to have consumd 16% of computation time. There must be something wrong. ... which appears in a loop, which is performed 2 billions times (!) for a 18 a3 page test score. Says gprof... Is that possible/necessary? Well, if it's an 18 page score, then there are lots of page break options, and so there would be lots of calculations. 2 billion seems like a lot, but there are a lot of ways to figure out line and page breaks in 18 pages of score and breaks.size() is 1202. just for info. ly_scm2interval is part of the beam scoring code. So that might be where many of the calls come from. I'm not sure what the fix might be. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
Arno, I think you're doing a great job of tracking this issue down! Keep up the good work, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Monday, July 12, 2010 06:51:15 am Arno Waschk wrote: On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen c_soren...@byu.edu wrote: On 7/12/10 4:48 AM, Arno Waschk hamama...@gmx.de wrote: Just finished a profile run with a larger score- ly_scm2interval is reported to have consumd 16% of computation time. There must be something wrong. ... which appears in a loop, which is performed 2 billions times (!) for a 18 a3 page test score. Says gprof... Is that possible/necessary? Well, if it's an 18 page score, then there are lots of page break options, and so there would be lots of calculations. 2 billion seems like a lot, but there are a lot of ways to figure out line and page breaks in 18 pages of score ly_scm2interval is part of the beam scoring code. So that might be where many of the calls come from. no, from the beam thing it is only called ~1000 tmes, the two billion come from a loop in Axis_group_interface::combine_pure_heights (...) This sounds excessive; if we cache more sensibly, this should reduce by at least a factor of 100. Does your score have many staves? Also, how many times is Align_interface::get_pure_child_y_translation called? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Mon, 12 Jul 2010 22:23:04 +0200, Joe Neeman joenee...@gmail.com wrote: On Monday, July 12, 2010 06:51:15 am Arno Waschk wrote: On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen c_soren...@byu.edu wrote: On 7/12/10 4:48 AM, Arno Waschk hamama...@gmx.de wrote: Just finished a profile run with a larger score- ly_scm2interval is reported to have consumd 16% of computation time. There must be something wrong. ... which appears in a loop, which is performed 2 billions times (!) for a 18 a3 page test score. Says gprof... Is that possible/necessary? Well, if it's an 18 page score, then there are lots of page break options, and so there would be lots of calculations. 2 billion seems like a lot, but there are a lot of ways to figure out line and page breaks in 18 pages of score ly_scm2interval is part of the beam scoring code. So that might be where many of the calls come from. no, from the beam thing it is only called ~1000 tmes, the two billion come from a loop in Axis_group_interface::combine_pure_heights (...) This sounds excessive; if we cache more sensibly, this should reduce by at least a factor of 100. Does your score have many staves? Also, how many times is Align_interface::get_pure_child_y_translation called? Cheers, Joe Hi, the mentioned routine is called ~ 23 times and does hardly consume time according to gprof. it is a cello and piano score with quite lot systems squeezed onto the a3 pages. it contains ~ 1600 bars, and breaks.size() is around 1200 IIRC Yours, Arno ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
Hi, the mentioned routine is called ~ 23 times and does hardly consume
time according to gprof.
it is a cello and piano score with quite lot systems squeezed onto the a3
pages. it contains ~ 1600 bars, and breaks.size() is around 1200 IIRC
Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also ly_scm2interval)
is called, but it has very little effect on lilypond's overall running
time (for the optimized build, at least).
Cheers,
Joe
From bd562d3d3e83a2545209bad8f6e97e2e263e8fe4 Mon Sep 17 00:00:00 2001
From: Joe Neeman joenee...@gmail.com
Date: Mon, 12 Jul 2010 18:07:06 -0700
Subject: [PATCH] Optimizations.
---
lily/axis-group-interface.cc | 49 +-
lily/include/axis-group-interface.hh |3 +-
lily/note-head.cc| 21 +-
stepmake/aclocal.m4 |2 +-
4 files changed, 52 insertions(+), 23 deletions(-)
diff --git a/lily/axis-group-interface.cc b/lily/axis-group-interface.cc
index 18994f1..42ed69f 100644
--- a/lily/axis-group-interface.cc
+++ b/lily/axis-group-interface.cc
@@ -87,7 +87,7 @@ Axis_group_interface::relative_group_extent (vectorGrob* const elts,
}
Interval
-Axis_group_interface::cached_pure_height (Grob *me, int start, int end)
+Axis_group_interface::sum_partial_pure_heights (Grob *me, int start, int end)
{
Interval iv = begin_of_line_pure_height (me, start);
iv.unite (rest_of_line_pure_height (me, start, end));
@@ -96,27 +96,50 @@ Axis_group_interface::cached_pure_height (Grob *me, int start, int end)
}
Interval
-Axis_group_interface::rest_of_line_pure_height (Grob *me, int start, int end)
+Axis_group_interface::part_of_line_pure_height (Grob *me, bool begin, int start, int end)
{
+ SCM cache_sym = begin ? ly_symbol2scm (start-pure-height-cache)
+: ly_symbol2scm (rest-pure-height-cache);
+ SCM key = begin ? scm_from_int (start) : scm_cons (scm_from_int (start), scm_from_int (end));
+ SCM pure_height_cache = me-get_property (cache_sym);
+
+ if (to_boolean (scm_hash_table_p (pure_height_cache)))
+{
+ SCM cached = scm_hash_ref (pure_height_cache, key, SCM_BOOL_F);
+ if (scm_is_pair (cached))
+ return robust_scm2interval (cached, Interval (0, 0));
+}
+
SCM adjacent_pure_heights = me-get_property (adjacent-pure-heights);
+ if (!scm_is_pair (adjacent_pure_heights))
+return Interval (0, 0);
+ SCM these_pure_heights = begin ? scm_car (adjacent_pure_heights) :
+scm_cdr (adjacent_pure_heights);
- if (!scm_is_pair (adjacent_pure_heights)
- || !scm_is_vector (scm_cdr (adjacent_pure_heights)))
+ if (!scm_is_vector (these_pure_heights))
return Interval (0, 0);
- return combine_pure_heights (me, scm_cdr (adjacent_pure_heights), start, end);
+ Interval ret = combine_pure_heights (me, these_pure_heights, start, end);
+ if (!to_boolean (scm_hash_table_p (pure_height_cache)))
+{
+ pure_height_cache = scm_c_make_hash_table (1000);
+ me-set_property (cache_sym, pure_height_cache);
+}
+ scm_hash_set_x (pure_height_cache, key, ly_interval2scm (ret));
+
+ return ret;
}
Interval
-Axis_group_interface::begin_of_line_pure_height (Grob *me, int start)
+Axis_group_interface::rest_of_line_pure_height (Grob *me, int start, int end)
{
- SCM adjacent_pure_heights = me-get_property (adjacent-pure-heights);
-
- if (!scm_is_pair (adjacent_pure_heights)
- || !scm_is_vector (scm_car (adjacent_pure_heights)))
-return Interval (0, 0);
+ return part_of_line_pure_height (me, false, start, end);
+}
- return combine_pure_heights (me, scm_car (adjacent_pure_heights), start, start+1);
+Interval
+Axis_group_interface::begin_of_line_pure_height (Grob *me, int start)
+{
+ return part_of_line_pure_height (me, true, start, start+1);
}
Interval
@@ -237,7 +260,7 @@ Axis_group_interface::relative_pure_height (Grob *me, int start, int end)
we can assume additivity and cache things nicely. */
Grob *p = me-get_parent (Y_AXIS);
if (p Align_interface::has_interface (p))
-return Axis_group_interface::cached_pure_height (me, start, end);
+return Axis_group_interface::sum_partial_pure_heights (me, start, end);
Grob *common = unsmob_grob (me-get_object (pure-Y-common));
extract_grob_set (me, pure-relevant-items, items);
diff --git a/lily/include/axis-group-interface.hh b/lily/include/axis-group-interface.hh
index bd038c7..ac765d2 100644
--- a/lily/include/axis-group-interface.hh
+++ b/lily/include/axis-group-interface.hh
@@ -48,9 +48,10 @@ struct Axis_group_interface
Grob *common, Axis);
static Interval relative_pure_height (Grob *me, int start, int end);
static Interval combine_pure_heights (Grob *me, SCM, int, int);
- static Interval cached_pure_height (Grob *me, int, int);
+ static Interval sum_partial_pure_heights (Grob *me, int, int);
static Interval begin_of_line_pure_height (Grob *me, int);
static Interval
Re: scheme night-mare...
On 7/11/10 7:16 AM, Arno Waschk hamama...@gmx.de wrote: Dear list, in the hope not for the x-th time having to give up due to that type mess scheme/c++ please forgive and help me: how can i convert/process/whatever the result of whateverGrob-get_property_alist_chain (SCM_EOL) into something easily useable in the c++ realm? Alist chains aren't easily handled in c++, as far as I know. But they can be used with scheme functions by using scm_call_3. If you don't need the alist chain, but just need individual properties, there are c++ functions to get the properties. If your question were a little bit more specific, we could probably help better. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Sun, 11 Jul 2010 16:35:07 +0200, Carl Sorensen c_soren...@byu.edu wrote: On 7/11/10 8:18 AM, Arno Waschk hamama...@gmx.de wrote: On Sun, 11 Jul 2010 16:01:52 +0200, Carl Sorensen c_soren...@byu.edu wrote: On 7/11/10 7:53 AM, Arno Waschk hamama...@gmx.de wrote: On Sun, 11 Jul 2010 15:48:57 +0200, Carl Sorensen c_soren...@byu.edu wrote: On 7/11/10 7:16 AM, Arno Waschk hamama...@gmx.de wrote: Dear list, in the hope not for the x-th time having to give up due to that type mess scheme/c++ please forgive and help me: how can i convert/process/whatever the result of whateverGrob-get_property_alist_chain (SCM_EOL) into something easily useable in the c++ realm? Alist chains aren't easily handled in c++, as far as I know. But they can be used with scheme functions by using scm_call_3. for the moment i am looking for either a complete dump of those properties, or at least a complete list of which properties could be addressed individually, although that would be less comfortable... If you don't need the alist chain, but just need individual properties, there are c++ functions to get the properties. If your question were a little bit more specific, we could probably help better. well, it is about getting around that types' things generally, too... OK, so here's the place to go to find what you need. The Guile reference has an API reference that lists all of the c++ calls to execute scheme functions. The stuff that deals with alists is found under the compound data types section: http://www.gnu.org/software/guile/manual/html_node/Compound-Data-Types.html# Compound-Data-Types You can do anything that you can do in scheme in c++ with these calls. except for generating the list of keys, it seems... :( There is a scheme function in scm/lily-library.scm map-alist-keys that will apply a function to all the keys in an alist. That might be helpful... How do i use this in a c line? Your question isn't really about converting from scheme to c++, it's really about getting all of the keys and/or properties from an alist. That's not built into scheme. No, it is about easily accessing information buried into some scheme structures by some little c code. As long this is not possible, this information is next to encrypted for me. Just finished a profile run with a larger score- ly_scm2interval is reported to have consumd 16% of computation time. There must be something wrong. Thanks, Arno Sorry, Carl -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Sun, 11 Jul 2010 20:08:10 +0200, Neil Puttock n.putt...@gmail.com
wrote:
On 11 July 2010 15:52, Arno Waschk hamama...@gmx.de wrote:
How do i use this in a c line?
Look up the procedure:
SCM proc = ly_lily_module_constant (map-alist-keys);
Call the procedure, using scm_call_2:
SCM result = scm_call_2 (proc, arg1, arg2);
Your question isn't really about converting from scheme to c++, it's
really
about getting all of the keys and/or properties from an alist. That's
not
built into scheme.
No, it is about easily accessing information buried into some scheme
structures by some little c code.
As long this is not possible, this information is next to encrypted for
me.
Why do you need to do this in C/C++ though?
If you're running a .ly file, this information's easily available via
ly:grob-alist-chain:
\relative c' {
\override Staff.KeySignature #'after-line-breaking =
#(lambda (grob)
(for-each (lambda (lst title)
(display (format #f ~a:\n title))
(for-each (lambda (entry)
(display (format #f ~a\n (car entry
lst)
(newline))
(ly:grob-alist-chain grob '()) '(mutable immutable)))
\key a \major
a1
}
Cheers,
Neil
Thanks for your explanations!
My main reason for all this is not to do something on the .ly file level
(at least not for now) but for learning what is going on on the c++ level,
including searching for hints onto my theory that lilypond's processing
times grow far more quadratically than i would believe to be necessary (or
to prove myself wrong, who knows??
Anyway, i came to a point where it seems very helpful to provide an easy
option to print somehow the actual content of e. g. a grob at a certain
point in the c++ code, or easily do some other voodoo to it, which i do
not know yet...
Where dealing with types including the letters S C M proves to be pure
horror. Or maybe it is my not-knowledge of those languages? I am musician
after all...
So i am looking for something fool-proof leading to something easily
printable (vulgo: string or the like) and not something hidden within a
scheme type labyrinth which i need to translate into a scheme type to call
it to have a scheme type result which maybe can or cannot converted into
something which might be a scheme type which can be translated into
something c++ might be able to convert, you got the point?
But thank you a lot for your help!
Cheers, Arno
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Mon, 12 Jul 2010 00:08:02 +0200, Arno Waschk hamama...@gmx.de wrote:
On Sun, 11 Jul 2010 20:08:10 +0200, Neil Puttock n.putt...@gmail.com
wrote:
On 11 July 2010 15:52, Arno Waschk hamama...@gmx.de wrote:
How do i use this in a c line?
Look up the procedure:
SCM proc = ly_lily_module_constant (map-alist-keys);
Call the procedure, using scm_call_2:
SCM result = scm_call_2 (proc, arg1, arg2);
okay, what are arg1 and arg2, and what is the type of result beyond being
called SCM?
Thanks, Arno
Your question isn't really about converting from scheme to c++, it's
really
about getting all of the keys and/or properties from an alist.
That's not
built into scheme.
No, it is about easily accessing information buried into some scheme
structures by some little c code.
As long this is not possible, this information is next to encrypted
for me.
Why do you need to do this in C/C++ though?
If you're running a .ly file, this information's easily available via
ly:grob-alist-chain:
\relative c' {
\override Staff.KeySignature #'after-line-breaking =
#(lambda (grob)
(for-each (lambda (lst title)
(display (format #f ~a:\n title))
(for-each (lambda (entry)
(display (format #f ~a\n (car entry
lst)
(newline))
(ly:grob-alist-chain grob '()) '(mutable immutable)))
\key a \major
a1
}
Cheers,
Neil
Thanks for your explanations!
My main reason for all this is not to do something on the .ly file level
(at least not for now) but for learning what is going on on the c++
level, including searching for hints onto my theory that lilypond's
processing times grow far more quadratically than i would believe to be
necessary (or to prove myself wrong, who knows??
Anyway, i came to a point where it seems very helpful to provide an easy
option to print somehow the actual content of e. g. a grob at a certain
point in the c++ code, or easily do some other voodoo to it, which i do
not know yet...
Where dealing with types including the letters S C M proves to be pure
horror. Or maybe it is my not-knowledge of those languages? I am
musician after all...
So i am looking for something fool-proof leading to something easily
printable (vulgo: string or the like) and not something hidden within a
scheme type labyrinth which i need to translate into a scheme type to
call it to have a scheme type result which maybe can or cannot converted
into something which might be a scheme type which can be translated into
something c++ might be able to convert, you got the point?
But thank you a lot for your help!
Cheers, Arno
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On 11 July 2010 23:08, Arno Waschk hamama...@gmx.de wrote: Anyway, i came to a point where it seems very helpful to provide an easy option to print somehow the actual content of e. g. a grob at a certain point in the c++ code, or easily do some other voodoo to it, which i do not know yet... If you use the .gdbinit file in the Contributor's Guide, it's easy to set breakpoints in the code and look at the properties of grobs. You can display any SCM object via ly_display_scm () (which is what the .gdbinit file uses for the gdb macros). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Mon, 12 Jul 2010 01:11:40 +0200, Neil Puttock n.putt...@gmail.com wrote: On 11 July 2010 23:08, Arno Waschk hamama...@gmx.de wrote: Anyway, i came to a point where it seems very helpful to provide an easy option to print somehow the actual content of e. g. a grob at a certain point in the c++ code, or easily do some other voodoo to it, which i do not know yet... If you use the .gdbinit file in the Contributor's Guide, it's easy to set breakpoints in the code and look at the properties of grobs. You can display any SCM object via ly_display_scm () (which is what the .gdbinit file uses for the gdb macros). Cheers, Neil Thanks again, that wokrs at least for some displaying, buit still i need that handy conversion from this type of scheme list into something i can deal with with c. Please!!! Yours, Arno -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On 07/11/2010 06:47 PM, Arno Waschk wrote: okay, what are arg1 and arg2, and what is the type of result beyond being called SCM? An ID for a Scheme entity. This is a fundamental concept in languages such as Scheme, Smalltalk, Self of Java. The value of the SCM itself is completely opaque to the client of the VM. It can be an index into a table, or it can be a direct address. The entity that it refers to, can in turn be any Scheme object: it can be a pair, or an atom, or the entity may even be immediately encoded in the SCM itself (for example, in Guile, #f is encoded in a special SCM). If you are familiar with JNI, then you can think of SCM as something similar to jobject. In Smalltalk, the equivalent concept is OOP. If you want to understand the communication between the Scheme and C++ code, the best reading explaining the underlying concepts are books on implementation of functional programming languages. But any VM book will do just as well (I started from GoldbergRobson's Smalltalk Blue Book back in 1994; Simon Jones is more directly applicable to Scheme). Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On 07/11/2010 07:22 PM, Arno Waschk wrote: Thanks again, that wokrs at least for some displaying, buit still i need that handy conversion from this type of scheme list into something i can deal with with c. Please!!! No, no, the main question is, what are you going to do with that something? Ok, the keys are probably Scheme strings, so you can transform them into UTF byte-arrays which you can then feed into functions like printf. But in Scheme, you frequently work with lists of things (lists themselves, or atoms) -- this is what a data structure looks like. So when you say something i can DEAL with with c, what exactly is this DEALing you want to do? And with which objects? some of them are Scheme wrappers around C structs. For those, there is smob/unsmob. But for true Scheme data structures, you really want to deal with them using Scheme code -- that is, using scm_call_X(), as Carl already suggested. Boris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme night-mare...
On Sun, Jul 11, 2010 at 7:47 PM, Arno Waschk hamama...@gmx.de wrote: SCM proc = ly_lily_module_constant (map-alist-keys); Call the procedure, using scm_call_2: SCM result = scm_call_2 (proc, arg1, arg2); okay, what are arg1 and arg2, and what is the type of result beyond being called SCM? Scheme is dynamically typed, so the answer to this question depends on what map-alist-keys returns. The easiest to deal with this is look at things from the scheme side, the 2nd option is printing out things in gdb. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
