Re: french beaming incorrectly makes stems longer

[Kevin Barry]

The minimum length of the stem of the middle note is forcing the beams down.

Re: french beaming incorrectly makes stems longer

[Werner LEMBERG]

> What is "french beaming" supposed to do/be?

No stems within the beam.


Werner

Re: french beaming incorrectly makes stems longer

[Urs Liska]

Am 25. Januar 2020 08:36:08 MEZ schrieb Han-Wen Nienhuys :
>Looks like a bug.

What is "french beaming" supposed to do/be?

>
>On Sat, Jan 25, 2020 at 8:12 AM Werner LEMBERG  wrote:
>>
>>
>> Before adding it to the bug tracker I want to check this group's
>> knowledge whether there is a reason that French beams are longer than
>> normal:
>>
>>   \relative c'' {
>> r16 f d f
>> \override Stem.french-beaming = ##t
>> r16 f d f
>>   }
>>
>> Looking into scores from French publishers this behaviour seems to be
>> incorrect.
>>
>>
>> Werner

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: french beaming incorrectly makes stems longer

[Han-Wen Nienhuys]

Looks like a bug.

On Sat, Jan 25, 2020 at 8:12 AM Werner LEMBERG  wrote:
>
>
> Before adding it to the bug tracker I want to check this group's
> knowledge whether there is a reason that French beams are longer than
> normal:
>
>   \relative c'' {
> r16 f d f
> \override Stem.french-beaming = ##t
> r16 f d f
>   }
>
> Looking into scores from French publishers this behaviour seems to be
> incorrect.
>
>
> Werner



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

french beaming incorrectly makes stems longer

[Werner LEMBERG]

Before adding it to the bug tracker I want to check this group's
knowledge whether there is a reason that French beams are longer than
normal:

  \relative c'' {
r16 f d f
\override Stem.french-beaming = ##t
r16 f d f
  }

Looking into scores from French publishers this behaviour seems to be
incorrect.


Werner

MacUpdate - your app listing has been updated

[MacUpdate]

   [1][macupdate-logo.png]
   top background

   App Listing Updated

   Hi lilypond.org, We have updated your application listing for LilyPond
   2.19.83-1 on [2]MacUpdate.com. Please take a moment to review your
   application's information to make sure that everything is correct.
   [3]View your updated app listing view your updated app
   You can [4]login to your Developer Account to reply to comments and
   view stats, or [5]submit new updates and changes to your app listing.
   [6]MacUpdate Desktop install compatibility

   Desktop Install Compatibility

   MacUpdate Desktop 6 is helping developers make it easier for users to
   fully install and use their apps. Download Desktop 6 and to ensure your
   app works with the “Install” link on our download pages.

Advertise With MacUpdate

   The best Mac devs advertise their apps on MacUpdate.com because it’s
   the most targeted, highly performing Mac app advertising you can find
   on the web. Contact a...@macupdate.com to guarantee your annual ad
   campaigns get booked and expand your app’s audience.
   Learn more view your updated app
   MacUpdate Desktop install compatibility Questions? Contact our Content
   Update Team [7]upda...@macupdate.com.
   bottom background

   You are receiving this offer because you have an app listed on
   MacUpdate.com. Add us to your address book or white list to ensure
   reliable delivery.

   © 2018 MacUpdate - All Rights Reserved
   526 W. 14th St. #100 • Traverse City, MI 49684

   [devemail-lilypond]

References

   Visible links
   1. 
https://www.macupdate.com/?utm_source=macupdate_medium=email_term=LilyPond_content=appupdate_campaign=dev_emails
   2. 
https://www.macupdate.com/?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   3. 
https://www.macupdate.com/app/mac/19024/lilypond?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   4. 
https://www.macupdate.com/member/account-developer?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   5. 
https://www.macupdate.com/content/submit/19024?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   6. 
https://www.macupdate.com/desktop?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails
   7. mailto:upda...@macupdate.com

   Hidden links:
   9. 
https://www.macupdate.com/advertise?utm_source=macupdate_medium=email_term=lilypond_content=appupdate_campaign=dev_emails

Re: gub fail/local-build-script/new bug?

[Dan Eble]

On Jan 24, 2020, at 16:19, David Kastrup  wrote:
> 
> It may be enough to call GCC with --std=g++11 (?) option without
> updating GCC itself, but I don't really have an idea.

GUB is using GCC 4.9.4 [1].

I've compiled the following program with Compiler Explorer [2] using that 
version of g++:

#include 

int main()
{
  std::to_string(13);
  return 0;
}

With the default command line, the compiler complains that "'to_string' is not 
a member of 'std'".  After adding the option "-std=c++11", the program compiles.

In stepmake/stepmake/c++-vars.make, EXTRA_CXXFLAGS is defined with "-std=c++11" 
in it, so I don't understand why Harm is having trouble.

Could something in GUB be overriding that option?
— 
Dan

[1] https://lists.gnu.org/archive/html/lilypond-devel/2019-12/msg00072.html
[2] https://godbolt.org

Re: gub fail/local-build-script/new bug?

[Thomas Morley]

Am Fr., 24. Jan. 2020 um 23:28 Uhr schrieb Michael Käppler :
>
> Am 24.01.2020 um 22:28 schrieb Thomas Morley:
> >
> > Well, I can't do any reasonable GUB-fixing, it's out of my depth.
> >
> > Also, your relevant patches are out of my depth as well. Though,
> > nobody objected during review, thus I think we should keep them.
> >
> > But I happily test things :)
> > Right now I try a GUB-build from a local branch containing nothing
> > else than already released 2.19.83. (with said gublbb and most recent
> > GUB)
> > If it fails (it worked half a year ago), than I suspect a GUB-problem.
> > And I may try to bisect GUB, although this will be very tedious...
> > If success I may try going lilypond-upstream.
>
> I tried Knut's script too, while testing Dan's patches for issue 5658.
> I did not work for me, either.
> Your description from mid-2019
> https://lists.gnu.org/archive/html/lilypond-devel/2019-06/msg00065.html
> worked like a charm, however.
>
> Did not have time to look at Knut's script.
>
> Cheers,
> Michael
>
>

I totaly forgot I wrote up a way using a daemon manually without using
Knut's script.
I may resort to it
lol


Thanks,
  Harm

Re: gub fail/local-build-script/new bug?

[Michael Käppler]

Am 24.01.2020 um 22:28 schrieb Thomas Morley:


Well, I can't do any reasonable GUB-fixing, it's out of my depth.

Also, your relevant patches are out of my depth as well. Though,
nobody objected during review, thus I think we should keep them.

But I happily test things :)
Right now I try a GUB-build from a local branch containing nothing
else than already released 2.19.83. (with said gublbb and most recent
GUB)
If it fails (it worked half a year ago), than I suspect a GUB-problem.
And I may try to bisect GUB, although this will be very tedious...
If success I may try going lilypond-upstream.


I tried Knut's script too, while testing Dan's patches for issue 5658.
I did not work for me, either.
Your description from mid-2019
https://lists.gnu.org/archive/html/lilypond-devel/2019-06/msg00065.html
worked like a charm, however.

Did not have time to look at Knut's script.

Cheers,
Michael

Re: Looking for help in configuring LilyDev in VirtualBox

[Michael Käppler]

Hello Peter,

Am 23.01.2020 um 11:45 schrieb Peter Toye:


Oh dear. It looks as if I'll have to work out how to do it myself. I
know there's a way of starting up programs on boot, but I've
completely forgotten what it is. Will do some research.




I did some research. The responsible utility VBoxClient is part of the
package virtualbox-guest-x11.
It is started from the script /etc/X11/Xsession.d/98vboxadd-xclient
during X server startup.
You could try to execute the checks there manually, i.e. run

lspci -d 80ee:beef

(should show something like "VGA compatible controller"

and

test -c /dev/vboxguest
echo $?

(should give 0 for success)

Best regards,
Michael

Re: gub fail/local-build-script/new bug?

[Thomas Morley]

Am Fr., 24. Jan. 2020 um 22:16 Uhr schrieb Dan Eble :
>
> On Jan 24, 2020, at 15:13, David Kastrup  wrote:
>
>
> Thomas Morley  writes:
>
> ...
>
> In member function 'std::string Interval_t::to_string() const':
> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:142:14:
> error: 'std::to_string' has not been declared
>
> ...
>
> Probably:
>
> commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d
> Author: Dan Eble 
> Date:   Sat Jan 11 08:55:36 2020 -0500
>
>Issue 5659/8: Remove Interval_t::T_to_string ()
>
>
> This is probably not the root cause, for though this tries to use 
> std::to_string(), the reason it does so is because several preceding commits 
> that removed ::to_string() overloads that were duplicating the function of 
> std::to_string().  I think if you reverted just this commit, you'd hit an 
> undefined std::to_string() elsewhere.
>
> Our current source code assumes more or less C++11 I think, and GUB
> compilers might not be up to it?
>
>
> This seems likely.  (Have I mentioned how tiresome GUB is?  I know it's been 
> a while since anyone complained about it.)
>
> Can we upgrade GUB, or should I start working to restore the global 
> ::to_string() functions?  Newer systems are better off with things the way 
> they are, but I don't see a third option.
> —
> Dan
>

Well, I can't do any reasonable GUB-fixing, it's out of my depth.

Also, your relevant patches are out of my depth as well. Though,
nobody objected during review, thus I think we should keep them.

But I happily test things :)
Right now I try a GUB-build from a local branch containing nothing
else than already released 2.19.83. (with said gublbb and most recent
GUB)
If it fails (it worked half a year ago), than I suspect a GUB-problem.
And I may try to bisect GUB, although this will be very tedious...
If success I may try going lilypond-upstream.

Cheers,
  Harm

Re: gub fail/local-build-script/new bug?

[David Kastrup]

Dan Eble  writes:

> On Jan 24, 2020, at 15:13, David Kastrup  wrote:
>> 
>> Thomas Morley mailto:thomasmorle...@gmail.com>> 
>> writes:
> ...
>>> In member function 'std::string Interval_t::to_string() const':
>>> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:142:14:
>>> error: 'std::to_string' has not been declared
> ...
>>> Probably:
>>> 
>>> commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d
>>> Author: Dan Eble 
>>> Date:   Sat Jan 11 08:55:36 2020 -0500
>>> 
>>>Issue 5659/8: Remove Interval_t::T_to_string ()
>
> This is probably not the root cause, for though this tries to use
> std::to_string(), the reason it does so is because several preceding
> commits that removed ::to_string() overloads that were duplicating the
> function of std::to_string().  I think if you reverted just this
> commit, you'd hit an undefined std::to_string() elsewhere.
>
>> Our current source code assumes more or less C++11 I think, and GUB
>> compilers might not be up to it?
>
> This seems likely.  (Have I mentioned how tiresome GUB is?  I know
> it's been a while since anyone complained about it.)
>
> Can we upgrade GUB, or should I start working to restore the global
> ::to_string() functions?  Newer systems are better off with things the
> way they are, but I don't see a third option.

It may be enough to call GCC with --std=g++11 (?) option without
updating GCC itself, but I don't really have an idea.

-- 
David Kastrup

Re: gub fail/local-build-script/new bug?

[Dan Eble]

On Jan 24, 2020, at 15:13, David Kastrup  wrote:
> 
> Thomas Morley mailto:thomasmorle...@gmail.com>> 
> writes:
...
>> In member function 'std::string Interval_t::to_string() const':
>> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:142:14:
>> error: 'std::to_string' has not been declared
...
>> Probably:
>> 
>> commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d
>> Author: Dan Eble 
>> Date:   Sat Jan 11 08:55:36 2020 -0500
>> 
>>Issue 5659/8: Remove Interval_t::T_to_string ()

This is probably not the root cause, for though this tries to use 
std::to_string(), the reason it does so is because several preceding commits 
that removed ::to_string() overloads that were duplicating the function of 
std::to_string().  I think if you reverted just this commit, you'd hit an 
undefined std::to_string() elsewhere.

> Our current source code assumes more or less C++11 I think, and GUB
> compilers might not be up to it?

This seems likely.  (Have I mentioned how tiresome GUB is?  I know it's been a 
while since anyone complained about it.)

Can we upgrade GUB, or should I start working to restore the global 
::to_string() functions?  Newer systems are better off with things the way they 
are, but I don't see a third option.
— 
Dan

Re: gub fail/local-build-script/new bug?

[David Kastrup]

Thomas Morley  writes:

> Hi,
>
> although we are discussing other methods to do releases, I'd expect
> for 2.20 we still will use gub.

No alternative here, really.

> Furthermore I promised Arnold from the german forum to do some custom
> windows-installer with some code which may fix fix issue 4943 and
> probably other related windows-only bugs.
>
> Thus I fired up my local gub, made it up to date and tried the nice
> gubllb-script by Knut Petersen.
> https://lists.gnu.org/archive/html/lilypond-devel/2019-06/msg00066.html
> First I tried from my local lilypond-git-master.
> Regrettable it fails.
> But worked half a year back.
> I'll attach the script. Someone with some insights?
>
>
>
> Then I tried directly ´make lilypond´ (which uses our official
> repo),though, it fails as well. Log goes wrong starting with:
>
> Making flower/out/offset.o < cc
> In file included from
> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/interval.cc:22:0:
> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:
> In member function 'std::string Interval_t::to_string() const':
> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:142:14:
> error: 'std::to_string' has not been declared
>using std::to_string;
>   ^
>
> Looks like a problem from a recent change.
>
> Probably:
>
> commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d
> Author: Dan Eble 
> Date:   Sat Jan 11 08:55:36 2020 -0500
>
> Issue 5659/8: Remove Interval_t::T_to_string ()
>
>
> Any hints?

Our current source code assumes more or less C++11 I think, and GUB
compilers might not be up to it?

Another possibility is that std::to_string is defined by accident (by
some include file including another file) and this does not work for all
implementations of the library.

-- 
David Kastrup

gub fail/local-build-script/new bug?

[Thomas Morley]

Hi,

although we are discussing other methods to do releases, I'd expect
for 2.20 we still will use gub. Furthermore I promised Arnold from the
german forum to do some custom windows-installer with some code which
may fix fix issue 4943 and probably other related windows-only bugs.

Thus I fired up my local gub, made it up to date and tried the nice
gubllb-script by Knut Petersen.
https://lists.gnu.org/archive/html/lilypond-devel/2019-06/msg00066.html
First I tried from my local lilypond-git-master.
Regrettable it fails.
But worked half a year back.
I'll attach the script. Someone with some insights?



Then I tried directly ´make lilypond´ (which uses our official
repo),though, it fails as well. Log goes wrong starting with:

Making flower/out/offset.o < cc
In file included from
/home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/interval.cc:22:0:
/home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:
In member function 'std::string Interval_t::to_string() const':
/home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:142:14:
error: 'std::to_string' has not been declared
   using std::to_string;
  ^

Looks like a problem from a recent change.

Probably:

commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d
Author: Dan Eble 
Date:   Sat Jan 11 08:55:36 2020 -0500

Issue 5659/8: Remove Interval_t::T_to_string ()


Any hints?

Cheers,
  Harm


gubllb
Description: Binary data

Re: EXPERIMENTAL: put a reminder of the mm rest on the last page at the top. (issue 553400043 by hanw...@gmail.com)

[hanwenn]

Reviewers: Dan Eble,

Message:
I'm not asking for anyone to review. It's context to the other change
about multi-measure-rests.

It's also a demonstration of why I want to get away from rietveld,
because it doesn't handle dependent changes.

Description:
EXPERIMENTAL: put a reminder of the mm rest on the last page at the top.

Introduces grob MultiMeasureRestReminder, controlled by
createMultiMeasureRestReminders.

TODO:
 * regtest
 * a nicer layout of the reminder (use a mmrest-like symbol?)
 * more structured positioning and extent routines for the grob.
 (the grob should be ignored for pure computations.)

Set page breaking properties in the System grob

* Record system rank within page in rank-on-page property

* Record page number in page-number property

lily/page-breaking: pass vector by reference


lily: fix some type conversion warnings


Document why System::rank_type is int16


Documentation: fix typo in German spacing.itely file


Documentation: fix typos in tool naming

Please review this at https://codereview.appspot.com/553400043/

Affected files (+71, -18 lines):
  M Documentation/contributor/administration.itexi
  M Documentation/contributor/introduction.itexi
  M Documentation/de/notation/spacing.itely
  M lily/break-substitution.cc
  M lily/include/page-breaking.hh
  M lily/include/system.hh
  M lily/lookup.cc
  M lily/multi-measure-rest-engraver.cc
  M lily/page-breaking.cc
  M lily/page-spacing-result.cc
  M lily/pointer-group-interface.cc
  M lily/quote-iterator.cc
  M lily/stem.cc
  M scm/define-context-properties.scm
  M scm/define-grob-properties.scm
  M scm/define-grobs.scm


Index: Documentation/contributor/administration.itexi
diff --git a/Documentation/contributor/administration.itexi 
b/Documentation/contributor/administration.itexi
index 
9af951ee8e6602429b58974a2f7ad33f4fb51194..2ac03ee2d5f4b5ccc7feaf028559a3e2356b1ddf
 100644
--- a/Documentation/contributor/administration.itexi
+++ b/Documentation/contributor/administration.itexi
@@ -788,9 +788,9 @@ savannah bug tracker?
 (prep: 1 hour.  discuss: 5 hours)
 
 @item @strong{Patch review tool}:
-Reitveld is inconvenient in some respects: it requires a google
+Rietveld is inconvenient in some respects: it requires a google
 account, and there's no way to see all patches relating to
-lilypond. Should we switch to something like gerritt?
+lilypond. Should we switch to something like gerrit?
 @uref{https://sourceforge.net/p/testlilyissues/issues/1184/}
 
 (prep: 5 hours.  discuss: 15 hours)
Index: Documentation/contributor/introduction.itexi
diff --git a/Documentation/contributor/introduction.itexi 
b/Documentation/contributor/introduction.itexi
index 
ed6f2cf8291899218ed4c55d2023982dd091e306..9306da6c6512d862d0b28438c04e7f3aef9a6339
 100644
--- a/Documentation/contributor/introduction.itexi
+++ b/Documentation/contributor/introduction.itexi
@@ -117,7 +117,7 @@ currently hosted by Sourceforge.
 @end example
 
 @item @strong{patch review}:
-Reitveld -- the collaborative code review tool.
+Rietveld -- the collaborative code review tool.
 
 @example
 @uref{https://codereview.appspot.com}
Index: Documentation/de/notation/spacing.itely
diff --git a/Documentation/de/notation/spacing.itely 
b/Documentation/de/notation/spacing.itely
index 
c4c8aea68f041d78fdad7fb9f0bd3f84c0b134f8..375135872c3e971d705d940bd14c7570bf00fdf4
 100644
--- a/Documentation/de/notation/spacing.itely
+++ b/Documentation/de/notation/spacing.itely
@@ -184,7 +184,7 @@ welcher immer auf oberster Ebene der Datei geschrieben 
werden muss, und
 
 @example
 \paper @{
-  #(set-paper-size "tabliod")
+  #(set-paper-size "tabloid")
 @}
 @end example
 
Index: lily/break-substitution.cc
diff --git a/lily/break-substitution.cc b/lily/break-substitution.cc
index 
901f6b0ceb188bcf470b8333ec825d0761aaf3a6..8f30d3ff4776709d10e7261974c73a698afefd68
 100644
--- a/lily/break-substitution.cc
+++ b/lily/break-substitution.cc
@@ -113,11 +113,11 @@ again:
 }
   else if (scm_is_vector (src))
 {
-  int len = scm_c_vector_length (src);
+  size_t len = scm_c_vector_length (src);
   SCM nv = scm_c_make_vector (len, SCM_UNDEFINED);
-  for (int i = 0; i < len; i++)
+  for (size_t i = 0; i < len; i++)
 {
-  SCM si = scm_from_int (i);
+  SCM si = scm_from_int ((int)i);
   scm_vector_set_x (nv, si,
 do_break_substitution (scm_vector_ref (src, si)));
 }
@@ -254,6 +254,10 @@ struct Substitution_entry
 {
   Grob *grob_;
 
+  /* The all-elements array inside the System is large. To save
+ memory, we assume there will not be more than 32k systems, and use
+ int16 for the indices, to save some space.
+  */
   System::rank_type left_;
   System::rank_type right_;
 
@@ -303,7 +307,7 @@ bool
 Spanner::fast_substitute_grob_array (SCM sym,
  Grob_array *grob_array)
 {
-  int len = grob_array->size ();
+  vsize len = grob_array->size ();
 
   if (grob_array->ordered ())

EXPERIMENTAL: put a reminder of the mm rest on the last page at the top. (issue 553400043 by hanw...@gmail.com)

[nine . fierce . ballads]

There's some stuff here that I already spent time reviewing, and having
to sift through it to find the new stuff is asking a lot.  Would you
mind narrowing this review down to the code for the feature itself?


https://codereview.appspot.com/553400043/

Re: Remove dead code throughout (issue 547470044 by hanw...@gmail.com)

[hanwenn]

 


https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh
File lily/include/smobs.hh (left):

https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh#oldcode316
lily/include/smobs.hh:316: SCM protection_cons_;
On 2020/01/24 18:21:40, Dan Eble wrote:
> Changing the size of a structure is not the first thing that comes to
mind when
> someone says "dead-code removal."  I'm happy to see this change, but
it could be
> summarized a little better.

Done.

https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh
File lily/include/smobs.hh (right):

https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh#newcode319
lily/include/smobs.hh:319: Smob () { };
On 2020/01/24 18:21:40, Dan Eble wrote:
> Try this:
> 
> Smob () = default;

Done.

https://codereview.appspot.com/547470044/

Re: Announce end of multi-measure-rest (issue 561310045 by hanw...@gmail.com)

[hanwenn]

Reviewers: lemzwerg, Dan Eble,

Message:
That's for anoter change. I thought that I should do
https://codereview.appspot.com/553400043/ as a scheme engraver, but
maybe it's more something for OLL ?

Description:
Announce end of multi-measure-rest

This will allow certain user-defined engravers to do useful things

Please review this at https://codereview.appspot.com/561310045/

Affected files (+2, -0 lines):
  M lily/multi-measure-rest-engraver.cc


Index: lily/multi-measure-rest-engraver.cc
diff --git a/lily/multi-measure-rest-engraver.cc 
b/lily/multi-measure-rest-engraver.cc
index 
017d01ca134eeb8255f2b3157d7de4c45e2fb485..3e95806e6422d1741bf04c4798ab59e48d1f291e
 100644
--- a/lily/multi-measure-rest-engraver.cc
+++ b/lily/multi-measure-rest-engraver.cc
@@ -242,6 +242,8 @@ Multi_measure_rest_engraver::process_music ()
   set_measure_count (curr_measure - start_measure_);
   if (last_command_item_)
 add_bound_item_to_grobs (last_command_item_);
+
+  announce_end_grob(mmrest_, SCM_EOL);
   reset_grobs ();
 }
 }

Re: Explain dead code for GUILE2 (issue 547470043 by hanw...@gmail.com)

[hanwenn]

Reviewers: lemzwerg, Dan Eble,


https://codereview.appspot.com/547470043/diff/547480043/lily/main.cc
File lily/main.cc (right):

https://codereview.appspot.com/547470043/diff/547480043/lily/main.cc#newcode447
lily/main.cc:447: /* this code is dead, but keeping this around until we
sort the
On 2020/01/24 18:05:08, Dan Eble wrote:
> LGTM, but ...
> 
> "'Mostly dead' is 'slightly alive.'"
> 
> It sounds like you think you might need to reinstate this.  Consider
keeping the
> #if GUILE2 and wrapping the code in if (false) {...}.  That way it
will have to
> remain compilable in the meantime, so it will be closer to ready when
you need
> it.
> 
> Also, the title of this review is "Explain dead code for GUILE2," but
the change
> appears to go beyond explanation into modification.

note that the #define is GUILEV2 so this was always equivalent to #if 0

Description:
Explain dead code for GUILE2

Please review this at https://codereview.appspot.com/547470043/

Affected files (+3, -1 lines):
  M lily/main.cc


Index: lily/main.cc
diff --git a/lily/main.cc b/lily/main.cc
index 
60b5738265e6d9a41f9ad2dcfecf887c823de01c..37efa7168094b62403b804361b47c2d433601cf6
 100644
--- a/lily/main.cc
+++ b/lily/main.cc
@@ -443,7 +443,9 @@ main_with_guile (void *, int, char **)
prepend_scheme_list (lilypond_datadir, scm_pct_load_path );
prepend_scheme_list (lilypond_datadir + "/scm", scm_pct_load_path);
 
-#if (GUILE2)
+#if 0
+   /* this code is dead, but keeping this around until we sort the
+  guile2/3 situation. */
/*
  Just as ughy - prepend "/scm/out" onto GUILE V2+ %load-compiled-path
  and set %compile-fallback-path to our scm/out directory

Re: Announce end of multi-measure-rest (issue 561310045 by hanw...@gmail.com)

[nine . fierce . ballads]

On 2020/01/24 17:58:44, lemzwerg wrote:
> Would be nice to have a regtest so that there is an example how to use
it.

+1

https://codereview.appspot.com/561310045/

Re: Remove dead code throughout (issue 547470044 by hanw...@gmail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh
File lily/include/smobs.hh (left):

https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh#oldcode316
lily/include/smobs.hh:316: SCM protection_cons_;
Changing the size of a structure is not the first thing that comes to
mind when someone says "dead-code removal."  I'm happy to see this
change, but it could be summarized a little better.

https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh
File lily/include/smobs.hh (right):

https://codereview.appspot.com/547470044/diff/575540047/lily/include/smobs.hh#newcode319
lily/include/smobs.hh:319: Smob () { };
Try this:

Smob () = default;

https://codereview.appspot.com/547470044/

Re: Explain dead code for GUILE2 (issue 547470043 by hanw...@gmail.com)

[nine . fierce . ballads]

https://codereview.appspot.com/547470043/diff/547480043/lily/main.cc
File lily/main.cc (right):

https://codereview.appspot.com/547470043/diff/547480043/lily/main.cc#newcode447
lily/main.cc:447: /* this code is dead, but keeping this around until we
sort the
LGTM, but ...

"'Mostly dead' is 'slightly alive.'"

It sounds like you think you might need to reinstate this.  Consider
keeping the #if GUILE2 and wrapping the code in if (false) {...}.  That
way it will have to remain compilable in the meantime, so it will be
closer to ready when you need it.

Also, the title of this review is "Explain dead code for GUILE2," but
the change appears to go beyond explanation into modification.

https://codereview.appspot.com/547470043/

Announce end of multi-measure-rest (issue 561310045 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

Would be nice to have a regtest so that there is an example how to use
it.

https://codereview.appspot.com/561310045/

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[Werner LEMBERG]

> What I meant to say: I guess I should be able to handle those
> comparatively obvious merge conflicts.
> 
> https://codereview.appspot.com/579240043/

Thanks for taking care of Han-Wen's patches.  My back is still not OK;
I must avoid sitting too much in front of the computer currently...


Werner

Remove dead code throughout (issue 547470044 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

LGTM, thanks

https://codereview.appspot.com/547470044/

Re: Only print out open type font substitution if there was a change (issue 577390043 by hanw...@gmail.com)

[Carl . D . Sorensen]

On 2020/01/24 17:46:33, Dan Eble wrote:
> On 2020/01/24 17:37:42, lemzwerg wrote:
> >  Replace font name '%s' with '%s'.
> 
> Yes, or,
> 
> Change font name from `%s' to `%s'

Or 

Use font name `%s' instead of `%s'

Since the name of the font is not changed on the disk, but only in the
currently running program.


Carl

https://codereview.appspot.com/577390043/

Re: Only print out open type font substitution if there was a change (issue 577390043 by hanw...@gmail.com)

[nine . fierce . ballads]

On 2020/01/24 17:37:42, lemzwerg wrote:
>  Replace font name '%s' with '%s'.

Yes, or,

Change font name from `%s' to `%s'


https://codereview.appspot.com/577390043/

Explain dead code for GUILE2 (issue 547470043 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

LGTM

https://codereview.appspot.com/547470043/

Re: Only print out open type font substitution if there was a change (issue 577390043 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

Grammar nit.


https://codereview.appspot.com/577390043/diff/573430045/lily/open-type-font.cc
File lily/open-type-font.cc (right):

https://codereview.appspot.com/577390043/diff/573430045/lily/open-type-font.cc#newcode238
lily/open-type-font.cc:238: debug_output (_f ("Replace font name from %s
to %s.",
Is this correct English?  Shouldn't this be rather

  Replace font name '%s' with '%s'.

?

https://codereview.appspot.com/577390043/

In verbose mode, dump time spent on parsing lily.scm and friends. (issue 573420043 by hanw...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

LGTM


https://codereview.appspot.com/573420043/diff/575530043/lily/main.cc
File lily/main.cc (left):

https://codereview.appspot.com/573420043/diff/575530043/lily/main.cc#oldcode515
lily/main.cc:515: // SCM result = scm_call_1 (
I guess you are submitting two commits as one Rietveld issue, right?  To
me, the changes in the two files look unrelated.

https://codereview.appspot.com/573420043/

Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys  writes:

> Both your hunches were correct:
>
> the code below works, but it makes the GC time go from 2s to 5s.

Have you disabled the call of scm_set_smob_mark in
lily/include/smobs.tcc ?  I mean, not having to use it is what should be
the advantage of this change.

> // GUILE v2 uses the Boehm GC. By allocating all memory through
> // scm_gc_malloc, we ensure that all our data structures are traced
> // for SCM values. As a performance optimization, we could define
> // operator new/delete for data structures that contain just atomic
> // data
> void *
> operator new(std::size_t size) {
>   if (guile_booted) {
> return scm_gc_malloc(size, "c++ new");
>   }
>   return malloc(size);
> }
>
> void
> operator delete(void *p) {
>   // Don't call GC_FREE or scm_gc_free. GC_free manipulates the
>   // to-be-freed pointer, and we can't guarantee that the pointer
>   // actually comes from GC_MALLOC.
> }

That looks rather crude.  Should be ok for a rough profiling guess, though.

-- 
David Kastrup

Re: ly_scm_write_string: call scm_write directly (issue 545450043 by hanw...@gmail.com)

[hanwenn]

Reviewers: dak, thomasmorley651,


https://codereview.appspot.com/545450043/diff/583370043/lily/lily-guile.cc
File lily/lily-guile.cc (right):

https://codereview.appspot.com/545450043/diff/583370043/lily/lily-guile.cc#newcode55
lily/lily-guile.cc:55: scm_write(s, port);
On 2020/01/18 23:29:30, dak wrote:
> Well, I was "what the Dickens?" reading this.  I suppose the original
purpose of
> the code is to follow redefinitions of "write".  I cannot imagine that
to be
> overly useful, though.

I think the original code may have been from a time we didn't really
understand GUILE.

Description:
ly_scm_write_string: call scm_write directly

Previously, this tried to get at the write function by evaluating
'write, which caused a hang on Guile 2.0

Please review this at https://codereview.appspot.com/545450043/

Affected files (+1, -5 lines):
  M lily/lily-guile.cc


Index: lily/lily-guile.cc
diff --git a/lily/lily-guile.cc b/lily/lily-guile.cc
index 
54e5e4a22d7934fc46aadd6b5ed023d6ddd8b20c..cd9213a252b350844d7eac6cf0937c2c4c3db3ed
 100644
--- a/lily/lily-guile.cc
+++ b/lily/lily-guile.cc
@@ -52,11 +52,7 @@ ly_scm_write_string (SCM s)
 scm_make_string (SCM_INUM0, SCM_UNDEFINED),
 SCM_OPN | SCM_WRTNG,
 "ly_write2string");
-  //  SCM write = scm_eval_3 (ly_symbol2scm ("write"), s, SCM_EOL);
-  SCM write = scm_primitive_eval (ly_symbol2scm ("write"));
-
-  // scm_apply (write, port, SCM_EOL);
-  scm_call_2 (write, s, port);
+  scm_write(s, port);
   return ly_scm2string (scm_strport_to_string (port));
 }
 

Re: Instrument and improve GC time (issue 577380043 by hanw...@gmail.com)

[hanwenn]

On 2020/01/24 17:01:50, hanwenn wrote:
> not LGtM - the setting is marked deprecated

actually, maybe this is the best solution for now - we otherwise have to
write autoconf detection for libgc to get the header that has the
prototype for GC_set_xxx.

https://codereview.appspot.com/577380043/

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 6:09 PM Han-Wen Nienhuys  wrote:
> Both your hunches were correct:
>
> the code below works, but it makes the GC time go from 2s to 5s.

Probably a lot of overhead would go away if we could properly pair up
GC_FREE with GC_MALLOC from libgc, but I can't get this to pass
GUILE's init phase.

I have some other ideas: I think we could instead define a
ly::vector<> that uses a custom allocator. The smob classes could then
define their own operator new, that uses scm_gc_malloc.

It willl have to wait for next week though.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

Both your hunches were correct:

the code below works, but it makes the GC time go from 2s to 5s.


// GUILE v2 uses the Boehm GC. By allocating all memory through
// scm_gc_malloc, we ensure that all our data structures are traced
// for SCM values. As a performance optimization, we could define
// operator new/delete for data structures that contain just atomic
// data
void *
operator new(std::size_t size) {
  if (guile_booted) {
return scm_gc_malloc(size, "c++ new");
  }
  return malloc(size);
}

void
operator delete(void *p) {
  // Don't call GC_FREE or scm_gc_free. GC_free manipulates the
  // to-be-freed pointer, and we can't guarantee that the pointer
  // actually comes from GC_MALLOC.
}

On Fri, Jan 24, 2020 at 5:54 PM David Kastrup  wrote:
>
> David Kastrup  writes:
>
> > Han-Wen Nienhuys  writes:
> >
> >> On Fri, Jan 24, 2020 at 12:45 PM David Kastrup  wrote:
> >>> >> No.  Since much of LilyPond's data containing SCM values is stored in
> >>> >> STL containers, it would require serious messing with allocators to get
> >>> >> there.
> >>> >
> >>> > Good point! And I'd agree with you, but if I look at the source code,
> >>> > I can't find much STL structures that really do this. There is
> >>> > Grob_array that would have to be revised, and there is a couple of
> >>> > Drul_array instances.
> >>>
> >>> There are a few other structures I think.  Basically one would need to
> >>> go through all mark_smob routines and check for loops over arrays or
> >>> other indirections.  You are right that their number seems reasonably
> >>> small.
> >>
> >> We should be able to short circuit all of this by doing
> >>
> >> +#if GUILEV2
> >> +
> >> +void *
> >> +operator new(std::size_t size) {
> >> +  return scm_gc_malloc(size, "c++ new");
> >> +}
> >> +
> >> +void
> >> +operator delete(void *p) {
> >> +  return scm_gc_free(p, 0, "new");
> >> +}
> >> +
> >> +#endif
> >
> > I wouldn't do that since it would affect all allocated memory even
> > outside of LilyPond proper, like for STL bookkeeping and file buffers
> > and whatnot.
>
> And particularly calling scm_gc_malloc before Guile has even been
> started up might be problematic...
>
> >> unfortunately, it crashes somewhere near the start of GUILE initialization.
> >>
> >> (in GUILE2 the above functions directly call GC_MALLOC, GC_FREE, so I
> >> don't understand why this would be a problem.)
> >>
> >> I am actually quite attracted to moving to GUILE 2 and using BGC.
> >> Debugging GC problems (eg. a constructor triggering GC, which then
> >> deletes the smob under construction) were one of most hairy things to
> >> get right.
> >
> > Them not being done right is the reason for the existence of the
> > Pre_init class...
>
> --
> David Kastrup



-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Instrument and improve GC time (issue 577380043 by hanw...@gmail.com)

[hanwenn]

not LGtM - the setting is marked deprecated

https://codereview.appspot.com/577380043/

Re: GUILE 2/3 and string encoding cost

[David Kastrup]

David Kastrup  writes:

> Han-Wen Nienhuys  writes:
>
>> On Fri, Jan 24, 2020 at 12:45 PM David Kastrup  wrote:
>>> >> No.  Since much of LilyPond's data containing SCM values is stored in
>>> >> STL containers, it would require serious messing with allocators to get
>>> >> there.
>>> >
>>> > Good point! And I'd agree with you, but if I look at the source code,
>>> > I can't find much STL structures that really do this. There is
>>> > Grob_array that would have to be revised, and there is a couple of
>>> > Drul_array instances.
>>>
>>> There are a few other structures I think.  Basically one would need to
>>> go through all mark_smob routines and check for loops over arrays or
>>> other indirections.  You are right that their number seems reasonably
>>> small.
>>
>> We should be able to short circuit all of this by doing
>>
>> +#if GUILEV2
>> +
>> +void *
>> +operator new(std::size_t size) {
>> +  return scm_gc_malloc(size, "c++ new");
>> +}
>> +
>> +void
>> +operator delete(void *p) {
>> +  return scm_gc_free(p, 0, "new");
>> +}
>> +
>> +#endif
>
> I wouldn't do that since it would affect all allocated memory even
> outside of LilyPond proper, like for STL bookkeeping and file buffers
> and whatnot.

And particularly calling scm_gc_malloc before Guile has even been
started up might be problematic...

>> unfortunately, it crashes somewhere near the start of GUILE initialization.
>>
>> (in GUILE2 the above functions directly call GC_MALLOC, GC_FREE, so I
>> don't understand why this would be a problem.)
>>
>> I am actually quite attracted to moving to GUILE 2 and using BGC.
>> Debugging GC problems (eg. a constructor triggering GC, which then
>> deletes the smob under construction) were one of most hairy things to
>> get right.
>
> Them not being done right is the reason for the existence of the
> Pre_init class...

-- 
David Kastrup

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 12:45 PM David Kastrup  wrote:
> >> No.  Since much of LilyPond's data containing SCM values is stored in
> >> STL containers, it would require serious messing with allocators to get
> >> there.
> >
> > Good point! And I'd agree with you, but if I look at the source code,
> > I can't find much STL structures that really do this. There is
> > Grob_array that would have to be revised, and there is a couple of
> > Drul_array instances.
>
> There are a few other structures I think.  Basically one would need to
> go through all mark_smob routines and check for loops over arrays or
> other indirections.  You are right that their number seems reasonably
> small.

We should be able to short circuit all of this by doing

+#if GUILEV2
+
+void *
+operator new(std::size_t size) {
+  return scm_gc_malloc(size, "c++ new");
+}
+
+void
+operator delete(void *p) {
+  return scm_gc_free(p, 0, "new");
+}
+
+#endif

unfortunately, it crashes somewhere near the start of GUILE initialization.

(in GUILE2 the above functions directly call GC_MALLOC, GC_FREE, so I
don't understand why this would be a problem.)

I am actually quite attracted to moving to GUILE 2 and using BGC.
Debugging GC problems (eg. a constructor triggering GC, which then
deletes the smob under construction) were one of most hairy things to
get right.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[Dan Eble]

On Jan 24, 2020, at 11:11, d...@gnu.org wrote:
>> Don't assume the hash function is perfect: create the table with more
> buckets,
>> say 2*size.
> 
> I'd not do that.  It's second-guessing the implementation.  The size
> should be good as a hint.  In particular if there are actual
> duplicates...

You are right.  I hadn't read the documentation closely enough.  The 
constructor argument is a minimum bucket count.

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 4:43 PM  wrote:
> > > Well, I should be able to handle them well enough.  It would be
> > > preferable if Han-Wen would provide Git-formatted patches (Rietveld
> is
> > > missing out on commit messages unless you consider scooping them up
> from
> > > the description as such, and while I would make sure that issue
> numbers
> > > are in the title lines, I think future rebases/merges at least for
> > > Han-Wen himself would work better if I work from original commits
> rather
> > > than original diffs).  And then it makes little sense distributing
> those
> > > patches to more than one person.
> >
> > this goes back to what we discussed in Salzburg, namely that our
> > tooling is clumsy. Having a gerrit or GH/GL based workflow would let
> > us review and exchange diffs as native Git commits, which simplifies a
> > lot of things.
> >
> > I'm happy to push my stuff to some git branch somewhere, if that helps
> you.
>
> I wasn't in Salzburg, but why can't you push to staging as everybody
> else does? It's not harder than pushing to a random branch and you
> obviously have all commits locally, don't you?

I am lazy, and quite busy :-)

There is a certain amount of process to follow; especially the part
where I have to wait for a couple of days for the countdown to
complete is something I lack the patience for.  Also, I now have 26
outstanding patches; coordinating this with rietveld LGTMs and
countdowns is a bit of a bother.

If y'all think that I should be allowed to bypass process, then that
would simplify things, obviously, but I also make mistakes that the
process is designed to catc.

> > BTW, Why do we insist in associating each review with a http://sf.net
> issue,
> > even if there is no related bug?
>
> I think there's no initial message for a new patch here, so there needs
> to be a place where new patches go and others can see them.

Git-CL gets a token, so presumably, it could also post a request to
press the 'm' button

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[dak]

On 2020/01/24 15:50:22, Dan Eble wrote:
> On 2020/01/24 15:17:02, dak wrote:
> > On 2020/01/24 14:11:59, Dan Eble wrote:
> > > On 2020/01/24 14:06:22, hanwenn wrote:
> > > > If the allocation cost becomes problematic, we can use another
hashmap
> > > instead.
> > > 
> > > "We" could profile it and know before pushing whether it is worth
it.
> > 
> > I don't think that this is really performance-critical.
> 
> I accept your informed intuition, but I also have more suggestions.
> 
> Don't assume the hash function is perfect: create the table with more
buckets,
> say 2*size.

I'd not do that.  It's second-guessing the implementation.  The size
should be good as a hint.  In particular if there are actual
duplicates...

> Instead of calling find() then insert(), just call insert() and check
whether it
> worked, something like this (untested):
> 
> if (seen.insert(grobs[i]).second)
>   grobs[j++] = grobs[i];

Ok, that's a good idea.
 
> https://en.cppreference.com/w/cpp/container/unordered_set/insert



https://codereview.appspot.com/583390043/

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[pkx166h]

On 24/01/2020 15:43, jonas.hahnf...@gmail.com wrote:

On 2020/01/24 15:32:43, hanwenn wrote:

On Fri, Jan 24, 2020 at 4:26 PM  wrote:
...
BTW, Why do we insist in associating each review with a http://sf.net

issue,

even if there is no related bug?

I think there's no initial message for a new patch here, so there needs
to be a place where new patches go and others can see them.

https://codereview.appspot.com/579240043/

Correct (mostly), when the scripts for patch testing worked (they can 
still be found in lilypond-extra) they would scan Allura and before that 
... google's issue tracker (I forget its name) for anything with Patch = 
new. Then it would scrape the issue for the Rietveld link and apply the 
diff. All automatically.


git-cl would create the issue, set the labels and paste the rietveld.

Hence the need for an 'issue'.

Today we (or I) simply look for any issue with new/started labels and 
scan for the URL myself.


That's why we have a tracker. This is something that was in place when I 
started, all I provided back then was a powerful machine that could test 
the patches using the patchy-test script (it'd run on a cron job and 
save the diffs in a local dir that I could check visually).


I'd then edit the issue saying it passed all tests (or failed and how).

What we have today is because these scripts never got updated for Allura 
(when we moved from google code's tracker).


James

Re: Looking for help in configuring LilyDev in VirtualBox

[David Kastrup]

Peter Toye  writes:

> Friday, January 24, 2020, 3:29:54 PM, David Kastrup wrote:
>
>> Peter Toye  writes:
>
>>> Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote:
>>>
>
>>> But if bash can't find the app in the first place,
>>> clearing   the   hash   table   wno't   make  much
>>> difference!
>
>> I have no idea what you mean by "in the first place".
>
> I mean that trying to execute lsusb by typing its name produces the
> bash error message saying that it can't be found. SO clearing the hash
> table won't have any effect.

That makes no sense whatsoever.  The whole reason to execute hash -r is
to tell bash that its memory of no lsusb being in the PATH might be
mistaken.

>> Have you tried
>
>> hash -r
>
>> or haven't you?  It is not clear from what you wrote.
>
> Yes I did, but same result.

Ok.

> But I've found that dpkg (which I've only just found out about) says
> that the package isn't installed, which would explain a lot.

Indeed.

> So I've just tried using apt-get again. It came up with what look like
> the same set of messages, and this time lsusb works. Don't understand
> what went wrong the first time, but now it's sorted. Thanks for the
> help.

-- 
David Kastrup

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[nine . fierce . ballads]

On 2020/01/24 15:17:02, dak wrote:
> On 2020/01/24 14:11:59, Dan Eble wrote:
> > On 2020/01/24 14:06:22, hanwenn wrote:
> > > If the allocation cost becomes problematic, we can use another
hashmap
> > instead.
> > 
> > "We" could profile it and know before pushing whether it is worth
it.
> 
> I don't think that this is really performance-critical.

I accept your informed intuition, but I also have more suggestions.

Don't assume the hash function is perfect: create the table with more
buckets, say 2*size.

Instead of calling find() then insert(), just call insert() and check
whether it worked, something like this (untested):

if (seen.insert(grobs[i]).second)
  grobs[j++] = grobs[i];

https://en.cppreference.com/w/cpp/container/unordered_set/insert

https://codereview.appspot.com/583390043/

Re: Looking for help in configuring LilyDev in VirtualBox

[Peter Toye]

Friday, January 24, 2020, 3:29:54 PM, David Kastrup wrote:

> Peter Toye  writes:

>> Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote:
>>

>> But if bash can't find the app in the first place,
>> clearing   the   hash   table   wno't   make  much
>> difference!

> I have no idea what you mean by "in the first place".

I mean that trying to execute lsusb by typing its name produces the bash error 
message saying that it can't be found. SO clearing the hash table won't have 
any effect.

> Have you tried

> hash -r

> or haven't you?  It is not clear from what you wrote.

Yes I did, but same result. But I've found that dpkg (which I've only just 
found out about) says that the package isn't installed, which would explain a 
lot.
So I've just tried using apt-get again. It came up with what look like the same 
set of messages, and this time lsusb works. Don't understand what went wrong 
the first time, but now it's sorted. Thanks for the help.

Best regards,

Peter

   

Re: PATCHES - Countdown for January 23rd

[pkx166h]

On 24/01/2020 11:19, David Kastrup wrote:

Han-Wen Nienhuys  writes:
...

BTW, Do issues get closed on Rietveld automatically too? I still have
many open reviews from many years ago.
The only person able to close them is the author.  Not sure whether a
project manager could, but then this would be quite a bit of additional
work.  I probably have accumulated a lot of them by now, too.  Probably
a few years since I last remembered to clean up.


I (as Patch Meiser) only care about the Allura Issue. I will close those 
if the dev doesn't in timr (i.e set with label 'Fixed_2_21', set status 
to 'null' and for convenience/reference if needed, the commit date/hash 
copied from the commit as the 'last comment'.


This helps those that then verify that the issue is in the tree or not 
as stated.


James

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[jonas . hahnfeld]

On 2020/01/24 15:32:43, hanwenn wrote:
> On Fri, Jan 24, 2020 at 4:26 PM  wrote:
> >
> > On 2020/01/24 13:57:33, Dan Eble wrote:
> > > On 2020/01/24 13:45:50, dak wrote:
> > > > Hoo yes.  That kind of extensive change is going to hurt anyway
> > given the
> > > > current burst activity level.  It will likely suck either way. 
Do
> > you have
> > > > particular dependencies yourself, Dan?
> > >
> > > I have a bunch of private branches (contexts, rehearsal marks,
warning
> > clean-up)
> > > that I would like to get on with rebasing.  Normally, once I'm
pretty
> > sure that
> > > a change of mine will be pushed, I'll just rebase to it locally,
but
> > with this
> > > one, I don't want to start until it's in master.
> > >
> > > If you want help handling Han-Wen's patches tomorrow, you can
delegate
> > some to
> > > me.
> >
> > Well, I should be able to handle them well enough.  It would be
> > preferable if Han-Wen would provide Git-formatted patches (Rietveld
is
> > missing out on commit messages unless you consider scooping them up
from
> > the description as such, and while I would make sure that issue
numbers
> > are in the title lines, I think future rebases/merges at least for
> > Han-Wen himself would work better if I work from original commits
rather
> > than original diffs).  And then it makes little sense distributing
those
> > patches to more than one person.
> 
> this goes back to what we discussed in Salzburg, namely that our
> tooling is clumsy. Having a gerrit or GH/GL based workflow would let
> us review and exchange diffs as native Git commits, which simplifies a
> lot of things.
> 
> I'm happy to push my stuff to some git branch somewhere, if that helps
you.

I wasn't in Salzburg, but why can't you push to staging as everybody
else does? It's not harder than pushing to a random branch and you
obviously have all commits locally, don't you?

> BTW, Why do we insist in associating each review with a http://sf.net
issue,
> even if there is no related bug?

I think there's no initial message for a new patch here, so there needs
to be a place where new patches go and others can see them.

https://codereview.appspot.com/579240043/

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[Han-Wen Nienhuys]

this change seems uncontroversial, and if it compiles, it should be
good to push.

On Fri, Jan 24, 2020 at 12:22 PM  wrote:
>
> I'd like special permission to skip the countdown and push this today
> instead of tomorrow.  Would that be OK?
>
> https://codereview.appspot.com/579240043/
>


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 4:26 PM  wrote:
>
> On 2020/01/24 13:57:33, Dan Eble wrote:
> > On 2020/01/24 13:45:50, dak wrote:
> > > Hoo yes.  That kind of extensive change is going to hurt anyway
> given the
> > > current burst activity level.  It will likely suck either way.  Do
> you have
> > > particular dependencies yourself, Dan?
> >
> > I have a bunch of private branches (contexts, rehearsal marks, warning
> clean-up)
> > that I would like to get on with rebasing.  Normally, once I'm pretty
> sure that
> > a change of mine will be pushed, I'll just rebase to it locally, but
> with this
> > one, I don't want to start until it's in master.
> >
> > If you want help handling Han-Wen's patches tomorrow, you can delegate
> some to
> > me.
>
> Well, I should be able to handle them well enough.  It would be
> preferable if Han-Wen would provide Git-formatted patches (Rietveld is
> missing out on commit messages unless you consider scooping them up from
> the description as such, and while I would make sure that issue numbers
> are in the title lines, I think future rebases/merges at least for
> Han-Wen himself would work better if I work from original commits rather
> than original diffs).  And then it makes little sense distributing those
> patches to more than one person.

this goes back to what we discussed in Salzburg, namely that our
tooling is clumsy. Having a gerrit or GH/GL based workflow would let
us review and exchange diffs as native Git commits, which simplifies a
lot of things.

I'm happy to push my stuff to some git branch somewhere, if that helps you.

BTW, Why do we insist in associating each review with a sf.net issue,
even if there is no related bug?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Looking for help in configuring LilyDev in VirtualBox

[David Kastrup]

Peter Toye  writes:

> Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote:
>
>> Peter Toye  writes:
>
>>> Friday, January 24, 2020, 11:34:24 AM, Peter Toye wrote:
>>>
>>> That's easier said than done. I found the relevant package name and
>>> used apt-get to install it. At least, I think I did, but typing lsusb
>>> comes up with bash: lsusb: command not found so that's obviously not
>>> right. i tried searching for a file called lsusb but came up with no
>>> result.
>
>> hash -r
>
>> or open a new terminal window.
>
> But if bash can't find the app in the first place,
> clearing   the   hash   table   wno't   make  much
> difference!

I have no idea what you mean by "in the first place".

>>> So (newbie Linux question again) - where does apt-get put the
>>> installed package? Or do I have to do something else first?
>
>> Should be installed where it's getting found as long as your shell is
>> not convinced otherwise from previous tries.
>
> But it's not getting found - that's the issue! 

Have you tried

hash -r

or haven't you?  It is not clear from what you wrote.

-- 
David Kastrup

Re: Looking for help in configuring LilyDev in VirtualBox

[Peter Toye]

Friday, January 24, 2020, 1:32:32 PM, David Kastrup wrote:

> Peter Toye  writes:

>> Friday, January 24, 2020, 11:34:24 AM, Peter Toye wrote:
>>
>> That's easier said than done. I found the relevant package name and
>> used apt-get to install it. At least, I think I did, but typing lsusb
>> comes up with bash: lsusb: command not found so that's obviously not
>> right. i tried searching for a file called lsusb but came up with no
>> result.

> hash -r

> or open a new terminal window.

But if bash can't find the app in the first place,
clearing   the   hash   table   wno't   make  much
difference!

>> So (newbie Linux question again) - where does apt-get put the
>> installed package? Or do I have to do something else first?

> Should be installed where it's getting found as long as your shell is
> not convinced otherwise from previous tries.

But it's not getting found - that's the issue! 

Best regards,

Peter

   

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[dak]

On 2020/01/24 15:26:06, dak wrote:
> On 2020/01/24 13:57:33, Dan Eble wrote:
> > On 2020/01/24 13:45:50, dak wrote:
> > > Hoo yes.  That kind of extensive change is going to hurt anyway
given the
> > > current burst activity level.  It will likely suck either way.  Do
you have
> > > particular dependencies yourself, Dan?
> > 
> > I have a bunch of private branches (contexts, rehearsal marks,
warning
> clean-up)
> > that I would like to get on with rebasing.  Normally, once I'm
pretty sure
> that
> > a change of mine will be pushed, I'll just rebase to it locally, but
with this
> > one, I don't want to start until it's in master.
> > 
> > If you want help handling Han-Wen's patches tomorrow, you can
delegate some to
> > me.
> 
> Well, I should be able to handle them well enough.  It would be
preferable if
> Han-Wen would provide Git-formatted patches (Rietveld is missing out
on commit
> messages unless you consider scooping them up from the description as
such, and
> while I would make sure that issue numbers are in the title lines, I
think
> future rebases/merges at least for Han-Wen himself would work better
if I work
> from original commits rather than original diffs).  And then it makes
little
> sense distributing those patches to more than one person.

What I meant to say: I guess I should be able to handle those
comparatively obvious merge conflicts.

https://codereview.appspot.com/579240043/

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[dak]

On 2020/01/24 13:57:33, Dan Eble wrote:
> On 2020/01/24 13:45:50, dak wrote:
> > Hoo yes.  That kind of extensive change is going to hurt anyway
given the
> > current burst activity level.  It will likely suck either way.  Do
you have
> > particular dependencies yourself, Dan?
> 
> I have a bunch of private branches (contexts, rehearsal marks, warning
clean-up)
> that I would like to get on with rebasing.  Normally, once I'm pretty
sure that
> a change of mine will be pushed, I'll just rebase to it locally, but
with this
> one, I don't want to start until it's in master.
> 
> If you want help handling Han-Wen's patches tomorrow, you can delegate
some to
> me.

Well, I should be able to handle them well enough.  It would be
preferable if Han-Wen would provide Git-formatted patches (Rietveld is
missing out on commit messages unless you consider scooping them up from
the description as such, and while I would make sure that issue numbers
are in the title lines, I think future rebases/merges at least for
Han-Wen himself would work better if I work from original commits rather
than original diffs).  And then it makes little sense distributing those
patches to more than one person.

https://codereview.appspot.com/579240043/

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[hanwenn]

https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc
File lily/grob.cc (right):

https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc#newcode971
lily/grob.cc:971: int j = 0;
On 2020/01/24 15:17:13, dak wrote:
> vsize j = 0;
> :-)

Done.

https://codereview.appspot.com/583390043/

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[dak]

https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc
File lily/grob.cc (right):

https://codereview.appspot.com/583390043/diff/551390044/lily/grob.cc#newcode971
lily/grob.cc:971: int j = 0;
vsize j = 0;
:-)

https://codereview.appspot.com/583390043/

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[dak]

On 2020/01/24 14:11:59, Dan Eble wrote:
> On 2020/01/24 14:06:22, hanwenn wrote:
> > If the allocation cost becomes problematic, we can use another
hashmap
> instead.
> 
> "We" could profile it and know before pushing whether it is worth it.

I don't think that this is really performance-critical.  Given the kind
of headache we had with non-deterministic runs, something as simple as
that is nice.

A more efficient way to do the thing via sorting indirect pointers would
be just to sort the indirect pointers, go through the indirect pointers
and null out all except the smallest non-unique direct pointers in the
array and then compact the array to the non-null entries.

But I still think I'd prefer Han-Wen's version.

https://codereview.appspot.com/583390043/

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[nine . fierce . ballads]

On 2020/01/24 14:06:22, hanwenn wrote:
> If the allocation cost becomes problematic, we can use another hashmap
instead.

"We" could profile it and know before pushing whether it is worth it.


https://codereview.appspot.com/583390043/

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[hanwenn]

Reviewers: dak,

Message:
On 2020/01/24 13:29:34, dak wrote:
> Not sure about the speedup (we might have small sizes often enough
that the
> constant factor becomes relevant), but the code is quite a net win
with regard
> to obviously doing what it should do.  It probably takes a whole lot
more
> allocation calls, but at least the impact on memory is just temporary.
> 
> LGTM

I was hoping the standard hashmap would use probing, but looks like it's
chaining

If the allocation cost becomes problematic, we can use another hashmap
instead. 

Description:
Simplify and speed up uniquify

Previously we sorted the array twice. Instead, we use a hash set. This
makes the procedure O(N) rather than O(N log N).

Please review this at https://codereview.appspot.com/583390043/

Affected files (+12, -42 lines):
  M lily/grob.cc


Index: lily/grob.cc
diff --git a/lily/grob.cc b/lily/grob.cc
index 
e1582583c095f9a25dcdfd19f41708115e0c7734..13f0edf4f21789694a85d5855c0a99b0f17d2259
 100644
--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 
 #include "align-interface.hh"
 #include "axis-group-interface.hh"
@@ -963,50 +964,19 @@ Grob::check_cross_staff (Grob *commony)
   return false;
 }
 
-static
-bool
-indirect_less (Grob **a, Grob **b)
-{
-  // Use original order as tie breaker.  That gives us a stable sort
-  // at the lower price tag of an unstable one, and we want a stable
-  // sort in order to reliably retain the first instance of a grob
-  // pointer.
-  return *a < *b || (*a == *b && a < b);
-}
-
-static
-bool
-indirect_eq (Grob **a, Grob **b)
-{
-  return *a == *b;
-}
-
-static
-bool
-direct_less (Grob **a, Grob **b)
-{
-  return a < b;
-}
-
-// uniquify uniquifies on the memory addresses of the Grobs, but then
-// uses the original order.  This makes results independent from the
-// memory allocation of Grobs.
-
 void
 uniquify (vector  & grobs)
 {
-  vector  vec (grobs.size ());
+  std::unordered_set seen(grobs.size());
+  int j = 0;
   for (vsize i = 0; i < grobs.size (); i++)
-vec[i] = [i];
-  vector_sort (vec, indirect_less);
-  vec.erase (unique (vec.begin (), vec.end (), indirect_eq), vec.end ());
-  vector_sort (vec, direct_less);
-
-  // Since the output is a sorted copy of the input with some elements
-  // removed, we can fill in the vector in-place if we do it starting
-  // from the front.
-  for (vsize i = 0; i < vec.size (); i++)
-grobs[i] = *vec[i];
-  grobs.erase (grobs.begin () + vec.size (), grobs.end ());
-  return;
+{
+  if (seen.find(grobs[i]) == seen.end())
+{
+  seen.insert(grobs[i]);
+  grobs[j++] = grobs[i];
+}
+}
+
+  grobs.resize(j);
 }

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

On 2020/01/24 13:45:50, dak wrote:
> Hoo yes.  That kind of extensive change is going to hurt anyway given
the
> current burst activity level.  It will likely suck either way.  Do you
have
> particular dependencies yourself, Dan?

I have a bunch of private branches (contexts, rehearsal marks, warning
clean-up) that I would like to get on with rebasing.  Normally, once I'm
pretty sure that a change of mine will be pushed, I'll just rebase to it
locally, but with this one, I don't want to start until it's in master.

If you want help handling Han-Wen's patches tomorrow, you can delegate
some to me.


https://codereview.appspot.com/579240043/

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[dak]

On 2020/01/24 13:39:15, hahnjo wrote:
> On 2020/01/24 11:22:43, Dan Eble wrote:
> > I'd like special permission to skip the countdown and push this
today instead
> of
> > tomorrow.  Would that be OK?
> 
> Not my call, but maybe you can give a reason? Is it the expected merge
> conflicts? If so, it's probably shifting the problem from you to
everyone
> else...

Hoo yes.  That kind of extensive change is going to hurt anyway given
the current burst activity level.  It will likely suck either way.  Do
you have particular dependencies yourself, Dan?

https://codereview.appspot.com/579240043/

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[jonas . hahnfeld]

On 2020/01/24 11:22:43, Dan Eble wrote:
> I'd like special permission to skip the countdown and push this today
instead of
> tomorrow.  Would that be OK?

Not my call, but maybe you can give a reason? Is it the expected merge
conflicts? If so, it's probably shifting the problem from you to
everyone else...

https://codereview.appspot.com/579240043/

Re: Looking for help in configuring LilyDev in VirtualBox

[David Kastrup]

Peter Toye  writes:

> Friday, January 24, 2020, 11:34:24 AM, Peter Toye wrote:
>
>> Thursday, January 23, 2020, 5:40:00 PM, Michael Käppler wrote:
>
>>> Do you think that 'lsusb' could be necessary? I think Federico's
>>> intention was to keep the image as small as possible,
>>> because one can easily install every debian
>>> package in the stretch repo
>>> afterwards.
>
>> Fine, Makes sense. I'll work out how to get it.
>
> That's easier said than done. I found the relevant package name and
> used apt-get to install it. At least, I think I did, but typing lsusb
> comes up with bash: lsusb: command not found so that's obviously not
> right. i tried searching for a file called lsusb but came up with no
> result.

hash -r

or open a new terminal window.

> So (newbie Linux question again) - where does apt-get put the
> installed package? Or do I have to do something else first?

Should be installed where it's getting found as long as your shell is
not convinced otherwise from previous tries.

-- 
David Kastrup

Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[dak]

Not sure about the speedup (we might have small sizes often enough that
the constant factor becomes relevant), but the code is quite a net win
with regard to obviously doing what it should do.  It probably takes a
whole lot more allocation calls, but at least the impact on memory is
just temporary.

LGTM

https://codereview.appspot.com/583390043/

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

[David Kastrup]

Dan Eble  writes:

> On Jan 24, 2020, at 03:49, Han-Wen Nienhuys  wrote:
>> The alternative is that we don't cast it, but pass on the 64 bit
>> size_t, but every time we do that, we'll create new call sites where
>> we have to fix up conversions, so that will create more work for
>> ourselves,
>
> I've been trickling in changes of this nature for a few months, and
> I'm content to keep it up if we can agree that it's the right thing to
> do.

Personally I think it's not as much "the right" as a good thing to do.
We have stuff like the "Rational" type exploding for certain
denominators that the "new complexity" composers love to be dealing
with, and removing size mismatches at least lets them explode at a time
when their actual capacity rather than a fraction of it gets exhausted.

-- 
David Kastrup

Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Fri, Jan 24, 2020 at 10:51 AM David Kastrup  wrote:
>
>>
>> > What do you mean with "heap is collected"?
>>
>> "Collected" is probably the wrong expression.  Sweeped and marked.  The
>> proposed behavior by Guile developers is not to bother with individual
>> mark hooks and just let the whole heap be marked and sweeped.
>>
>
> what is the documented way of disabling the hooks?

Just don't register them, I suppose.

All of our Guile allocation stuff by now is supposed to be routed
through the files

lily/include/smobs.hh
lily/include/smobs.tcc
lily/include/small-smobs.hh
lily/smobs.cc
lily/undead.cc

So disabling the registration hooks should not affect too many lines.
I think just outcommenting the lines

  if (::mark_smob != _base::mark_smob)
scm_set_smob_mark (smob_tag_, Super::mark_trampoline);

in lily/include/smobs.tcc should disable all hooks.  At least there does
not appear to be any other call to scm_set_smob_mark in the code base.

> And are we supposed to include the BGC headers ourselves and issue
> GC_blah commands directly?

Oh no, just use the same mechanism as in Guile-1 (which is what we do
currently).  Using the hooks is seen as a second-class citizen, but
after years of bug reports and nagging, our tests stopped crashing
because of GC problems.

-- 
David Kastrup

Re: Looking for help in configuring LilyDev in VirtualBox

[Peter Toye]

Friday, January 24, 2020, 11:34:24 AM, Peter Toye wrote:

> Thursday, January 23, 2020, 5:40:00 PM, Michael Käppler wrote:

>> Do you think that 'lsusb' could be necessary? I think Federico's
>> intention was to keep the image as small as possible,
>> because one can easily install every debian
>> package in the stretch repo
>> afterwards.

> Fine, Makes sense. I'll work out how to get it.

That's easier said than done. I found the relevant package name and used 
apt-get to install it. At least, I think I did, but typing lsusb comes up with 
bash: lsusb: command not found so that's obviously not right. i tried searching 
for a file called lsusb but came up with no result.

So (newbie Linux question again) - where does apt-get put the installed 
package? Or do I have to do something else first?

Sorry for my ignorance. I think I shall have to buy a book - there's a 
wholeload in the catalogues, but I suspect most of them don't deal with this 
sort of question. I used to use Frisch for Unix admin help, but that looks very 
out of date (2009) now.

Best regards,

Peter

   

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

[Dan Eble]

On Jan 24, 2020, at 03:49, Han-Wen Nienhuys  wrote:
> The alternative is that we don't cast it, but pass on the 64 bit size_t, but 
> every time we do that, we'll create new call sites where we have to fix up 
> conversions, so that will create more work for ourselves,

I've been trickling in changes of this nature for a few months, and I'm content 
to keep it up if we can agree that it's the right thing to do.
— 
Dan

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 10:51 AM David Kastrup  wrote:

>
> > What do you mean with "heap is collected"?
>
> "Collected" is probably the wrong expression.  Sweeped and marked.  The
> proposed behavior by Guile developers is not to bother with individual
> mark hooks and just let the whole heap be marked and sweeped.
>

what is the documented way of disabling the hooks? And are we supposed to
include the BGC headers ourselves and issue GC_blah commands directly?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Fri, Jan 24, 2020 at 11:30 AM David Kastrup  wrote:
>> >> >> On a 64bit application, this would be somewhat more tenable, but we'd
>> >> >> need to override operator new for smobs.
>> >> >>
>> >> >> Or do we?  Maybe the heap is collected by default, and we need to 
>> >> >> switch
>> >> >> that off?
>> >> >>
>> >> > What do you mean with "heap is collected"?
>> >>
>> >> "Collected" is probably the wrong expression.  Sweeped and marked.  The
>> >> proposed behavior by Guile developers is not to bother with individual
>> >> mark hooks and just let the whole heap be marked and sweeped.
>> >>
>> >
>> > Did we ever try this and publish results?
>>
>> No.  Since much of LilyPond's data containing SCM values is stored in
>> STL containers, it would require serious messing with allocators to get
>> there.
>
> Good point! And I'd agree with you, but if I look at the source code,
> I can't find much STL structures that really do this. There is
> Grob_array that would have to be revised, and there is a couple of
> Drul_array instances.

There are a few other structures I think.  Basically one would need to
go through all mark_smob routines and check for loops over arrays or
other indirections.  You are right that their number seems reasonably
small.

> There are a bunch of others (eg. in Slur_engraver), that mark into STL
> structures, but they retain pointers to events (which are kept alive
> through the Music structures)

Stream events are not kept alive through music structures.  There is a
reverse mechanism that I think should actually get removed:

  /*
ES TODO: This is a temporary fix. Stream_events should not be
aware of music.
  */
  e->set_property ("music-cause", self_scm ());

(it's in lily/music.cc).

At any rate, stream events tend to be kept alive by engravers which in
turn are kept alive by their contexts.  Events are also kept alive as
"cause" of grobs.

> and grobs (which are only unprotected when they are put into the
> System).

-- 
David Kastrup

Re: Looking for help in configuring LilyDev in VirtualBox

[Peter Toye]

Thursday, January 23, 2020, 9:11:34 PM, Federico Bruni wrote:

> Il giorno gio 23 gen 2020 alle 18:30, Michael Käppler
>  ha scritto:
>> 
>>  What we both noticed was that startup occassionally fails with a
>>  console prompt "Enter Maintenance mode...".
>>  Have you ever noticed this behaviour, too? I was not able to 
>> reproduce it reliably, so
>>  it's hard to track down.

> No, but I tested VirtualBox just a few times.

It happens about half the time on my system, and doesn't seems to correlate 
with any actions I've taken when booting the guest in. As Michael suggested, I 
just hit ctrl-D and ignore it.

> I will let you know when v2 is released.

Best regards,

Peter

   

Re: Looking for help in configuring LilyDev in VirtualBox

[Peter Toye]

Thursday, January 23, 2020, 5:40:00 PM, Michael Käppler wrote:

> Am 23.01.2020 um 11:45 schrieb Peter Toye:
>>
>> I hadn't realised that your new instructions were for the next issue
>> of LilyDev. Are there any other missing bits? I noticed that some of
>> the utilities for listing hardware like lsusb aren't there.
> Do you think that 'lsusb' could be necessary? I think Federico's
> intention was to keep the image as small as possible,
> because one can easily install every debian
> package in the stretch repo
> afterwards.

Fine, Makes sense. I'll work out how to get it.

> Best regards,
> Michael

Best regards,

Peter

   

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

[Dan Eble]

On Jan 24, 2020, at 03:49, Han-Wen Nienhuys  wrote:
> 
> (I think Dan is nine.fierce.ballads?)

sort(Dan.full_name) == sort('ninE Fierce ballaDs')
— 
Dan

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 11:30 AM David Kastrup  wrote:
> >> >> On a 64bit application, this would be somewhat more tenable, but we'd
> >> >> need to override operator new for smobs.
> >> >>
> >> >> Or do we?  Maybe the heap is collected by default, and we need to switch
> >> >> that off?
> >> >>
> >> > What do you mean with "heap is collected"?
> >>
> >> "Collected" is probably the wrong expression.  Sweeped and marked.  The
> >> proposed behavior by Guile developers is not to bother with individual
> >> mark hooks and just let the whole heap be marked and sweeped.
> >>
> >
> > Did we ever try this and publish results?
>
> No.  Since much of LilyPond's data containing SCM values is stored in
> STL containers, it would require serious messing with allocators to get
> there.

Good point! And I'd agree with you, but if I look at the source code,
I can't find much STL structures that really do this. There is
Grob_array that would have to be revised, and there is a couple of
Drul_array instances.

There are a bunch of others (eg. in Slur_engraver), that mark into STL
structures, but they retain pointers to events (which are kept alive
through the Music structures) and grobs (which are only unprotected
when they are put into the System).

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

I'd like special permission to skip the countdown and push this today
instead of tomorrow.  Would that be OK?

https://codereview.appspot.com/579240043/

Re: PATCHES - Countdown for January 23rd

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Fri, Jan 24, 2020 at 11:58 AM David Kastrup  wrote:
>> >> I guess I am a developer with repository access, but in Salzburg,
>> >> Werner
>> >> offered to me to do the mechanics of shepherding the patches through,
>> >> and
>> >> I'd like to take that offer. My time is probably better spent
>> >> navigating
>> >> the arcana of the GUILE 2 / 3 transition.
>> >>
>> >
>> > OK, that looks reasonable. That means patches will *not* get pushed
>> > "without any of your involvement" but you have to ask someone, i.e.
>> > Werner to do so. Probably he's monitoring this anyway, but you might
>> > ping him again privately, just in case.
>>
>> I can also do this.  The decision should still be done individually:
>> some patches reach "push" in spite of comments on Rietveld, and James
>> implements more of a janitorial process and the decision which comments
>> may be showstoppers really rests with the patch submitter.
>
> Thanks, that's greatly appreciated.
>
> BTW, Do issues get closed on Rietveld automatically too? I still have
> many open reviews from many years ago.

The only person able to close them is the author.  Not sure whether a
project manager could, but then this would be quite a bit of additional
work.  I probably have accumulated a lot of them by now, too.  Probably
a few years since I last remembered to clean up.

-- 
David Kastrup

Re: GUILE2: generate internals doc in UTF-8 (issue 575540045 by hanw...@gmail.com)

[hanwenn]

https://codereview.appspot.com/575540045/diff/571410043/scm/documentation-generate.scm
File scm/documentation-generate.scm (right):

https://codereview.appspot.com/575540045/diff/571410043/scm/documentation-generate.scm#newcode98
scm/documentation-generate.scm:98: (if (defined? 'set-port-encoding!)
On 2020/01/24 11:08:51, dak wrote:
> I think we usually do this as
> 
> (if (guile-v2) ...
> 
> in order to better be able to find dependencies and ultimately (after
migration)
> throw them out.  Also I am not sure that the byte-compiler is happy
about those
> constructs.

Done.

https://codereview.appspot.com/575540045/

Re: PATCHES - Countdown for January 23rd

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 11:58 AM David Kastrup  wrote:
> >> I guess I am a developer with repository access, but in Salzburg,
> >> Werner
> >> offered to me to do the mechanics of shepherding the patches through,
> >> and
> >> I'd like to take that offer. My time is probably better spent
> >> navigating
> >> the arcana of the GUILE 2 / 3 transition.
> >>
> >
> > OK, that looks reasonable. That means patches will *not* get pushed
> > "without any of your involvement" but you have to ask someone, i.e.
> > Werner to do so. Probably he's monitoring this anyway, but you might
> > ping him again privately, just in case.
>
> I can also do this.  The decision should still be done individually:
> some patches reach "push" in spite of comments on Rietveld, and James
> implements more of a janitorial process and the decision which comments
> may be showstoppers really rests with the patch submitter.

Thanks, that's greatly appreciated.

BTW, Do issues get closed on Rietveld automatically too? I still have
many open reviews from many years ago.

--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

GUILE2: generate internals doc in UTF-8 (issue 575540045 by hanw...@gmail.com)

[dak]

https://codereview.appspot.com/575540045/diff/571410043/scm/documentation-generate.scm
File scm/documentation-generate.scm (right):

https://codereview.appspot.com/575540045/diff/571410043/scm/documentation-generate.scm#newcode98
scm/documentation-generate.scm:98: (if (defined? 'set-port-encoding!)
I think we usually do this as

(if (guile-v2) ...

in order to better be able to find dependencies and ultimately (after
migration) throw them out.  Also I am not sure that the byte-compiler is
happy about those constructs.

https://codereview.appspot.com/575540045/

Re: PATCHES - Countdown for January 23rd

[David Kastrup]

Urs Liska  writes:

> Am Freitag, den 24.01.2020, 11:41 +0100 schrieb Han-Wen Nienhuys:
>> On Fri, Jan 24, 2020 at 11:28 AM David Kastrup  wrote:
>> 
>> > Han-Wen Nienhuys  writes:
>> > 
>> > > Thanks for keeping track of this.
>> > > 
>> > > Can you confirm my countdown patches will get pushed without any
>> > > of my
>> > > involvement (assuming nobody else objects)?
>> > 
>> > For developers with repository access, the procedure is for them to
>> > do
>> > the pushing themselves once "patch push" is reached, so if you have
>> > doubts about how to do that (only push to staging branch, ever,
>> > never to
>> > master) or want someone else to do it, holler.
>> > 
>> 
>> I guess I am a developer with repository access, but in Salzburg,
>> Werner
>> offered to me to do the mechanics of shepherding the patches through,
>> and
>> I'd like to take that offer. My time is probably better spent
>> navigating
>> the arcana of the GUILE 2 / 3 transition.
>> 
>
> OK, that looks reasonable. That means patches will *not* get pushed
> "without any of your involvement" but you have to ask someone, i.e.
> Werner to do so. Probably he's monitoring this anyway, but you might
> ping him again privately, just in case.

I can also do this.  The decision should still be done individually:
some patches reach "push" in spite of comments on Rietveld, and James
implements more of a janitorial process and the decision which comments
may be showstoppers really rests with the patch submitter.

-- 
David Kastrup

Re: PATCHES - Countdown for January 23rd

[Urs Liska]

Am Freitag, den 24.01.2020, 11:41 +0100 schrieb Han-Wen Nienhuys:
> On Fri, Jan 24, 2020 at 11:28 AM David Kastrup  wrote:
> 
> > Han-Wen Nienhuys  writes:
> > 
> > > Thanks for keeping track of this.
> > > 
> > > Can you confirm my countdown patches will get pushed without any
> > > of my
> > > involvement (assuming nobody else objects)?
> > 
> > For developers with repository access, the procedure is for them to
> > do
> > the pushing themselves once "patch push" is reached, so if you have
> > doubts about how to do that (only push to staging branch, ever,
> > never to
> > master) or want someone else to do it, holler.
> > 
> 
> I guess I am a developer with repository access, but in Salzburg,
> Werner
> offered to me to do the mechanics of shepherding the patches through,
> and
> I'd like to take that offer. My time is probably better spent
> navigating
> the arcana of the GUILE 2 / 3 transition.
> 

OK, that looks reasonable. That means patches will *not* get pushed
"without any of your involvement" but you have to ask someone, i.e.
Werner to do so. Probably he's monitoring this anyway, but you might
ping him again privately, just in case.

Urs

Re: PATCHES - Countdown for January 23rd

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 11:28 AM David Kastrup  wrote:

> Han-Wen Nienhuys  writes:
>
> > Thanks for keeping track of this.
> >
> > Can you confirm my countdown patches will get pushed without any of my
> > involvement (assuming nobody else objects)?
>
> For developers with repository access, the procedure is for them to do
> the pushing themselves once "patch push" is reached, so if you have
> doubts about how to do that (only push to staging branch, ever, never to
> master) or want someone else to do it, holler.
>

I guess I am a developer with repository access, but in Salzburg, Werner
offered to me to do the mechanics of shepherding the patches through, and
I'd like to take that offer. My time is probably better spent navigating
the arcana of the GUILE 2 / 3 transition.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Fri, Jan 24, 2020 at 10:51 AM David Kastrup  wrote:
>
>>
>> >> On a 64bit application, this would be somewhat more tenable, but we'd
>> >> need to override operator new for smobs.
>> >>
>> >> Or do we?  Maybe the heap is collected by default, and we need to switch
>> >> that off?
>> >>
>> >>
>> > What do you mean with "heap is collected"?
>>
>> "Collected" is probably the wrong expression.  Sweeped and marked.  The
>> proposed behavior by Guile developers is not to bother with individual
>> mark hooks and just let the whole heap be marked and sweeped.
>>
>
> Did we ever try this and publish results?

No.  Since much of LilyPond's data containing SCM values is stored in
STL containers, it would require serious messing with allocators to get
there.

-- 
David Kastrup

Re: PATCHES - Countdown for January 23rd

[David Kastrup]

Han-Wen Nienhuys  writes:

> Thanks for keeping track of this.
>
> Can you confirm my countdown patches will get pushed without any of my
> involvement (assuming nobody else objects)?

For developers with repository access, the procedure is for them to do
the pushing themselves once "patch push" is reached, so if you have
doubts about how to do that (only push to staging branch, ever, never to
master) or want someone else to do it, holler.

If you aren't entirely clear whether they might all go through, it makes
sense to do this in smaller bunches and wait for them to make it to
master in the automated process: otherwise the whole bunch may need to
get thrown out in case the process complains.  Most of the time it is my
computer these days that does the integration.  If you are impatient,
you can try setting up your own integration pass for it as well, using
patches/lilypond-patchy-staging.py in the lilypond-extra repository (and
configuring it in ~/.lilypond-patchy-config .

I have an old 4-core laptop with
Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
(which is not supposed to be 4-core, so I need to crank up the fan to
max manually in order to deal with the 45W TDP instead of the expected
35W) which takes about 45 minutes for the full test with docs.

-- 
David Kastrup

Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Fri, Jan 24, 2020 at 10:22 AM Hans Åberg  wrote:
>
>> >> Boehm GC can work in a background thread I think.  And Guile-v2
>> >> applications typically just let all their data be treated as pointers
>> >> rather than using a smob-marking algorithm like we do, and it is
>> >> conceivable that Boehm GC's individual mark function does not scale.
>> >>
>> >
>> > Do you mean our mechanism to call user-defined mark functions? I doubt
>> that
>> > there are obvious BGC scalability problems in BGC's mark functoin.
>>
>> The Boehm GC collects in separate threads, however, when the program is
>> threaded, it puts locks around every allocation, which is very time
>> consuming
>>
>
> Are you sure? Multithreaded memory management usually has per-thread
> strategies to avoid contention. Locking by itself is very cheap unless
> there is contention. The docs I can find are
>
> https://www.hboehm.info/gc/scale.html
>
> but it talks about a 500Mhz Pentium 3 as the benchmark platform, so it's
> probably out of date.

Last time I looked, Guile 2 switched the BGC into Java collection
semantics where it finishes one mark pass (including user-defined hooks)
before it commences to collecting stuff marked with it and calling its
(equivalent of) destructors.  That prevents the mark hooks continuing to
get called after the C++ destructor already ran.  That is somewhat more
synchronised than its default manner of operating.

-- 
David Kastrup

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 10:51 AM David Kastrup  wrote:

>
> >> On a 64bit application, this would be somewhat more tenable, but we'd
> >> need to override operator new for smobs.
> >>
> >> Or do we?  Maybe the heap is collected by default, and we need to switch
> >> that off?
> >>
> >>
> > What do you mean with "heap is collected"?
>
> "Collected" is probably the wrong expression.  Sweeped and marked.  The
> proposed behavior by Guile developers is not to bother with individual
> mark hooks and just let the whole heap be marked and sweeped.
>

Did we ever try this and publish results?


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: PATCHES - Countdown for January 23rd

[Han-Wen Nienhuys]

Thanks for keeping track of this.

Can you confirm my countdown patches will get pushed without any of my
involvement (assuming nobody else objects)?

On Thu, Jan 23, 2020 at 8:24 PM  wrote:

> Hello,
>
> Here is the current patch countdown list. The next countdown will be on
> January 25th
>
> A quick synopsis of all patches currently in the review process can be
> found here:
>
> http://philholmes.net/lilypond/allura/
>
> 
>
>
>   Push:
>
> 5665 Remove broken and undocumented tracing features - Jonas Hahnfeld
> https://sourceforge.net/p/testlilyissues/issues/5665
> http://codereview.appspot.com/577320043
>
> 5660 Doc: Added documentation for fill-line line-width - davidsg
> https://sourceforge.net/p/testlilyissues/issues/5660
> http://codereview.appspot.com/583340043
>
>
>   Countdown:
>
> 5676 remove obsolete lines from lily-guile-macros.hh - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5676
> http://codereview.appspot.com/555170043
>
> 5675 Document C++ structs for slur scoring - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5675
> http://codereview.appspot.com/571380043
>
> 5673 Remove implicit evaluation of the ".twy" file - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5673
> http://codereview.appspot.com/551380043
>
> 5672 Clean up and document include file searching - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5672
> http://codereview.appspot.com/573400043
>
> 5671 lily/page-breaking: pass vector by reference - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5671
> http://codereview.appspot.com/581510043
>
> 5669 Document why System::rank_type is int16 - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5669
> http://codereview.appspot.com/559370043
>
> 5668 Documentation: fix typo in German spacing.itely file - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5668
> http://codereview.appspot.com/581490043
>
> 5667 Documentation: fix typos in tool naming - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5667
> http://codereview.appspot.com/581480043
>
> 5666 ly_scm_write_string: call scm_write directly - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5666
> http://codereview.appspot.com/545450043
>
> 4550 Avoid "using" directives in included files - Dan Eble
> https://sourceforge.net/p/testlilyissues/issues/4550
> http://codereview.appspot.com/579240043
>
>
>   Review:
>
> 5670 lily: fix some type conversion warnings - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5670
> http://codereview.appspot.com/557190043
>
>
>   New:
>
> 5678 l -> lilne - hanwen
> https://sourceforge.net/p/testlilyissues/issues/5678
> http://codereview.appspot.com/581470047
>
>
> ***
>
>
> Regards,
>
> James
>
>
>

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Fri, Jan 24, 2020 at 10:22 AM Hans Åberg  wrote:

> >> Boehm GC can work in a background thread I think.  And Guile-v2
> >> applications typically just let all their data be treated as pointers
> >> rather than using a smob-marking algorithm like we do, and it is
> >> conceivable that Boehm GC's individual mark function does not scale.
> >>
> >
> > Do you mean our mechanism to call user-defined mark functions? I doubt
> that
> > there are obvious BGC scalability problems in BGC's mark functoin.
>
> The Boehm GC collects in separate threads, however, when the program is
> threaded, it puts locks around every allocation, which is very time
> consuming
>

Are you sure? Multithreaded memory management usually has per-thread
strategies to avoid contention. Locking by itself is very cheap unless
there is contention. The docs I can find are

https://www.hboehm.info/gc/scale.html

but it talks about a 500Mhz Pentium 3 as the benchmark platform, so it's
probably out of date.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: GUILE 2/3 and string encoding cost

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Thu, Jan 23, 2020 at 10:39 PM David Kastrup  wrote:
>
>>
>> > on mozart-hrn-3, over 3 runs, we get
>> >
>> > 2.0.14  - avg 2.1s
>> > 1.8.8 - avg 0.31s
>> >
>> > so the new GC is about 5-10x slower than the old one. With GUILE 1.8,
>> > garbage collection covers typically is 10% of the runtime, so all things
>> > equal, the Boehm GC would cause a 1.5-2.0x slowdown in the total.
>> >
>> > It would be good to see how the JITting of code impacts Scheme
>> > execution.
>>
>> Boehm GC can work in a background thread I think.  And Guile-v2
>> applications typically just let all their data be treated as pointers
>> rather than using a smob-marking algorithm like we do, and it is
>> conceivable that Boehm GC's individual mark function does not scale.
>>
>
> Do you mean our mechanism to call user-defined mark functions? I doubt
> that there are obvious BGC scalability problems in BGC's mark
> functoin.

We do everything through user-defined mark functions and BGC might not
be efficient in that regard.

>> However, considering everything a pointer for a 32bit application
>> that can eat a significant ratio of the total address space is a
>> nightmare: there would be just too much memory pinned down due to
>> conservative garbage collection.
>>
> GUILE 1.8 already scanned the stack conservatively, so large scores
> would probably never work on 32 bits.

We keep very little on the stack.  And GC is explicitly called between
command line files at a particularly low point in the stack.  We have a
warning in 1.8 for leftovers of types that are not expected at that
point of time, and while it triggers in random regtests, the frequency
is pretty low.

> Was this a concern in the past?  How do score sizes (in pages)
> translates to memory usage (in megabytes)?

Memory use for scores of several hundred pages can come close to eating
the 32bit address space.

> I think it is reasonable for us to start assuming people run lilypond
> on a 64-bit machines.

Sure.  That would make the assumptions of the BGC a better deal in
principle.

>> On a 64bit application, this would be somewhat more tenable, but we'd
>> need to override operator new for smobs.
>>
>> Or do we?  Maybe the heap is collected by default, and we need to switch
>> that off?
>>
>>
> What do you mean with "heap is collected"?

"Collected" is probably the wrong expression.  Sweeped and marked.  The
proposed behavior by Guile developers is not to bother with individual
mark hooks and just let the whole heap be marked and sweeped.

-- 
David Kastrup

Re: GUILE 2/3 and string encoding cost

[Hans Åberg]

> On 24 Jan 2020, at 10:03, Han-Wen Nienhuys  wrote:
> 
> On Thu, Jan 23, 2020 at 10:39 PM David Kastrup  wrote:
> 
>> 
>>> on mozart-hrn-3, over 3 runs, we get
>>> 
>>> 2.0.14  - avg 2.1s
>>> 1.8.8 - avg 0.31s
>>> 
>>> so the new GC is about 5-10x slower than the old one. With GUILE 1.8,
>>> garbage collection covers typically is 10% of the runtime, so all things
>>> equal, the Boehm GC would cause a 1.5-2.0x slowdown in the total.
>>> 
>>> It would be good to see how the JITting of code impacts Scheme
>>> execution.
>> 
>> Boehm GC can work in a background thread I think.  And Guile-v2
>> applications typically just let all their data be treated as pointers
>> rather than using a smob-marking algorithm like we do, and it is
>> conceivable that Boehm GC's individual mark function does not scale.
>> 
> 
> Do you mean our mechanism to call user-defined mark functions? I doubt that
> there are obvious BGC scalability problems in BGC's mark functoin.

The Boehm GC collects in separate threads, however, when the program is 
threaded, it puts locks around every allocation, which is very time consuming.

> However, considering everything a pointer for a 32bit application that
>> can eat a significant ratio of the total address space is a nightmare:
>> there would be just too much memory pinned down due to conservative
>> garbage collection.
>> 
>> 
> GUILE 1.8 already scanned the stack conservatively, so large scores would
> probably never work on 32 bits. Was this a concern in the past?  How do
> score sizes (in pages) translates to memory usage (in megabytes)?
> 
> I think it is reasonable for us to start assuming people run lilypond on a
> 64-bit machines.
> 
> 
>> On a 64bit application, this would be somewhat more tenable, but we'd
>> need to override operator new for smobs.
>> 
>> Or do we?  Maybe the heap is collected by default, and we need to switch
>> that off?
>> 
> What do you mean with "heap is collected”?

The Boehm GC also has a malloc/free pair that keeps track of pointers into the 
GC heap. One can use them to define global operator new/delete, which the C++ 
standard guarantees that the linker will use them for all allocations. This can 
combined with GC allocations. 

Re: GUILE 2/3 and string encoding cost

[Han-Wen Nienhuys]

On Thu, Jan 23, 2020 at 10:39 PM David Kastrup  wrote:

>
> > on mozart-hrn-3, over 3 runs, we get
> >
> > 2.0.14  - avg 2.1s
> > 1.8.8 - avg 0.31s
> >
> > so the new GC is about 5-10x slower than the old one. With GUILE 1.8,
> > garbage collection covers typically is 10% of the runtime, so all things
> > equal, the Boehm GC would cause a 1.5-2.0x slowdown in the total.
> >
> > It would be good to see how the JITting of code impacts Scheme
> > execution.
>
> Boehm GC can work in a background thread I think.  And Guile-v2
> applications typically just let all their data be treated as pointers
> rather than using a smob-marking algorithm like we do, and it is
> conceivable that Boehm GC's individual mark function does not scale.
>

Do you mean our mechanism to call user-defined mark functions? I doubt that
there are obvious BGC scalability problems in BGC's mark functoin.

However, considering everything a pointer for a 32bit application that
> can eat a significant ratio of the total address space is a nightmare:
> there would be just too much memory pinned down due to conservative
> garbage collection.
>
>
GUILE 1.8 already scanned the stack conservatively, so large scores would
probably never work on 32 bits. Was this a concern in the past?  How do
score sizes (in pages) translates to memory usage (in megabytes)?

I think it is reasonable for us to start assuming people run lilypond on a
64-bit machines.


> On a 64bit application, this would be somewhat more tenable, but we'd
> need to override operator new for smobs.
>
> Or do we?  Maybe the heap is collected by default, and we need to switch
> that off?
>
>
What do you mean with "heap is collected"?


-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Thu, Jan 23, 2020 at 10:11 PM David Kastrup  wrote:

> hanw...@gmail.com writes:
>
> > In LilyPond, the bulk of the warnings come from unsigned 64 bit sizes,
> > ie. vector and list sizes.
> >
> > In order to cause an error, you would have to create vector or list of
> > over 2G of
> > elements (on 32 bit architecture), so the unsigned size would be
> > converted to a negative integer. Since our objects
> > are all larger than a single byte, there isn't enough memory for this to
> > be possible. (The same holds for 64 bit,
> > except that you can't buy machines with that much RAM)
>
> Reality check: my laptop is something like 10 years old and holds 16GB
> of RAM.
>

I meant: you can't buy a machine that has 2^63 bytes of RAM.

The hole in my argument here is that int is 32-bit even on 64-bit
architectures. I have been submersed in the world of the Go programming
language, where things are generally more sane, and "int" mirrors the size
of pointers.

Dan's argument (I think Dan is nine.fierce.ballads?) about the MIDI code is
a good argument to not switch off the -Werror=conversion error. Thanks for
setting me straight on that, Dan.

That said, for typesetting, a 32-bit signed size leaves room for 2e9
entities, and I claim that it is enough for anybody (an A4 page of music
typically 1k objects), so we can freely cast down to 32 bits when we get a
64 bit size_t somewhere. The alternative is that we don't cast it, but pass
on the 64 bit size_t, but every time we do that, we'll create new call
sites where we have to fix up conversions, so that will create more work
for ourselves, while we have many other more pressing issues to attend,
like resolving the GUILE 3 situation.

Thoughts?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen