Re: Integration of Guilev2 branches into master

On Sat, Feb 8, 2020 at 11:43 AM David Kastrup wrote: > Ok, there are still 3 unmerged patches marked XXX in the (now rebased) > branch dev/guile-v2-work . They are unmerged because they are marked > XXX . Here is the list: > can you push the branch? I can't find some of the sha1s you mention.

Re: Parse inline scheme using per-expression port (issue 557330043 by hanw...@gmail.com)

On Sun, Feb 9, 2020 at 7:00 PM wrote: > > Now my original solution was aimed at staying in binary even during > Scheme times while Antonio Ospite does go all-in on UTF-8 in Scheme. So > the result of combining my and his work is a chimæra which I am less > confident about than my own code on

Re: [RFC] switch to GitLab / gitlab.com

Very nice. Why is the project/user called lilypond-issues? Do we know who owns the 'lilypond' user? On Sun, Feb 9, 2020 at 10:50 PM Jonas Hahnfeld wrote: > Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: > > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni > > < > >

Re: Fix and align musicxml and input language "deutsch" (issue 547610043 by d...@gnu.org)

On 2020/02/09 22:27:55, lemzwerg wrote: > > > What about providing an alias for the old name 'beh' > > for backward compatibility? > > > > I'd rather not since it so glaringly wrong. [...] > > OK, but then we need either a NEWS entry or a convert-ly rule (or both) IMHO. git log -S '\'

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

On 2020/02/09 10:08:20, hanwenn wrote: > A way around that is to change all instances of vectors holding SCM values to a > new > gc_vector type that has a custom allocator. That will be significant work, but > probably > desirable in the long term. I'd recommend a two-pronged approach for now,

Re: How to deal with failing 'make test-bseline'

Am So., 9. Feb. 2020 um 20:17 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > I've rerun with > > CPU_COUNT=3 make -j3 test > > with success, i.e. the errored file is grepped. > > No idea why more cores help here. > > > I usally use 3 not 5, because of limited memory. > > How limited?

Re: [RFC] switch to GitLab / gitlab.com

Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld ha scritto: Thanks for sharing! I put together a simplistic script to create a proof-of-concept: https://gitlab.com/lilypond-issues/lilypond/issues It's only 1137 issues (now my server is blacklisted for spamming...), but it has some

Re: [RFC] switch to GitLab / gitlab.com

Am Sonntag, den 09.02.2020, 23:03 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: > > > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni > > > < > > > f...@inventati.org > > > > > > > ha

Re: Fix and align musicxml and input language "deutsch" (issue 547610043 by d...@gnu.org)

> > What about providing an alias for the old name 'beh' > for backward compatibility? > > I'd rather not since it so glaringly wrong. [...] OK, but then we need either a NEWS entry or a convert-ly rule (or both) IMHO. https://codereview.appspot.com/547610043/

Re: [RFC] switch to GitLab / gitlab.com

>> Please all take a look and let me know what you think! > > For a first pitch certainly impressive. It's nice that the SHA1 ids > have become live. +1 Very nice! Werner

Re: Fix and align musicxml and input language "deutsch" (issue 547610043 by d...@gnu.org)

Reviewers: lemzwerg, Message: On 2020/02/09 22:08:11, lemzwerg wrote: > LGTM > > https://codereview.appspot.com/547610043/diff/567190043/scm/define-note-names.scm > File scm/define-note-names.scm (right): > >

Re: [RFC] switch to GitLab / gitlab.com

Am Sonntag, den 09.02.2020, 22:50 +0100 schrieb Jonas Hahnfeld: > Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: > > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni > > < > > f...@inventati.org > > > > > ha scritto: > > > I guess that the quality of the issue migration might

Fix and align musicxml and input language "deutsch" (issue 547610043 by d...@gnu.org)

LGTM https://codereview.appspot.com/547610043/diff/567190043/scm/define-note-names.scm File scm/define-note-names.scm (right): https://codereview.appspot.com/547610043/diff/567190043/scm/define-note-names.scm#newcode302 scm/define-note-names.scm:302: (heh . ,(ly:make-pitch -1 6 SEMI-FLAT)) What

Re: [RFC] switch to GitLab / gitlab.com

Jonas Hahnfeld writes: > Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: >> Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni >> < >> f...@inventati.org >> > ha scritto: >> > I guess that the quality of the issue migration might influence the >> > decision. >> >> I forgot I

Re: [RFC] switch to GitLab / gitlab.com

Am Freitag, den 07.02.2020, 16:28 +0100 schrieb Federico Bruni: > Il giorno ven 7 feb 2020 alle 10:33, Federico Bruni > < > f...@inventati.org > > ha scritto: > > I guess that the quality of the issue migration might influence the > > decision. > > I forgot I already investigated the SF ->

Re: How to deal with failing 'make test-bseline'

Thomas Morley writes: > I've rerun with > CPU_COUNT=3 make -j3 test > with success, i.e. the errored file is grepped. No idea why more cores help here. > I usally use 3 not 5, because of limited memory. How limited? What kind of SODIMM could you use for extending? I think there is a

Re: How to deal with failing 'make test-bseline'

Am So., 9. Feb. 2020 um 19:48 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > I now tried > > 2014 make test-clean > > 2015 make test > > with no useful infos, like before > > > > but > > 2020 make test-clean > > 2021 CPU_COUNT=9 make -j9 test > > 2022 grep sourcefilename

Re: wrong note name conversion in musicxml2ly

mari+lilyp...@mailbox.org writes: > According to > http://www.ekmelic-music.org/de/extra/name24.htm > the "beh" in Netherlands or "bqf" in English does correspond indeed to > "heh" in German. But I never worked with quarter notes. Frankly, I suspect that their names are essentially

Re: How to deal with failing 'make test-bseline'

Thomas Morley writes: > I now tried > 2014 make test-clean > 2015 make test > with no useful infos, like before > > but > 2020 make test-clean > 2021 CPU_COUNT=9 make -j9 test > 2022 grep sourcefilename `grep -L systems.texi > out/lybook-testdb/*/*log|sed s/log/ly/g` > finally pointed

Re: How to deal with failing 'make test-bseline'

Am So., 9. Feb. 2020 um 18:03 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > 1996 git clone git://git.sv.gnu.org/lilypond.git ~/lilypond-git-2 > > 1997 cd lilypond-git-2 > > 1998 git log > > 1999 git fetch > > 2000 git pull -r > > 2001 sh autogen.sh --noconfigure > > 2002

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

Hi David, > my own take on what that means would not have been to abolish > grace time: it's still useful for identifying things. But rather to > reduce NoteColumn/MusicalColumn sharing/alignment during grace time to > being just per-Staff, or possibly as option per-Voice. That would > allow,

Re: Parse inline scheme using per-expression port (issue 557330043 by hanw...@gmail.com)

On 2020/02/09 17:18:19, hanwenn wrote: > David, please take another look. First, you are aware that the rationale for This commit fixes a problem with GUILE 2.2.6, where LilyPond calculates offsets in the source file as bytes, while GUILE interprets the source file as UTF-8 encoded

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

Sunday, February 9, 2020, 4:15:53 PM, you wrote: > On 2020/02/09 15:32:14, lilypond_ptoye.com wrote: >> Surely "standard scale pitch or previously altered pitch". In D major: > "cis c >> cis" the first note is an alteration but not an accidental, the second > is an >> accidental but not an

Re: Parse inline scheme using per-expression port (issue 557330043 by hanw...@gmail.com)

David, please take another look. https://codereview.appspot.com/557330043/

Re: How to deal with failing 'make test-bseline'

Thomas Morley writes: > 1996 git clone git://git.sv.gnu.org/lilypond.git ~/lilypond-git-2 > 1997 cd lilypond-git-2 > 1998 git log > 1999 git fetch > 2000 git pull -r > 2001 sh autogen.sh --noconfigure > 2002 mkdir -p build/ > 2003 cd build/ > 2004 ../configure --enable-guile2 >

Re: How to deal with failing 'make test-bseline'

Am So., 9. Feb. 2020 um 16:35 Uhr schrieb Thomas Morley : > > Am So., 9. Feb. 2020 um 16:12 Uhr schrieb David Kastrup : > > > > Thomas Morley writes: > > > > > Bringing some offlist-discussion back to the list because it may > > > interest more people > > > > > > Am So., 9. Feb. 2020 um 12:44 Uhr

Re: wrong note name conversion in musicxml2ly

mari+lilyp...@mailbox.org writes: >> On 2/9/20 1:49 PM, David Kastrup wrote: >>> mari+lilyp...@mailbox.org writes: >>> when converting a mxl file with "musicxml2ly --language=deutsch" the note "beses" is converted to "bes". Lilypond gives an error at this notename with \language

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

On 2020/02/09 15:32:14, lilypond_ptoye.com wrote: > Surely "standard scale pitch or previously altered pitch". In D major: "cis c > cis" the first note is an alteration but not an accidental, the second is an > accidental but not an alteration, the third is both. Now I'm really splitting > hairs.

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

On 2020/02/09 15:32:14, lilypond_ptoye.com wrote: > Sunday, February 9, 2020, 2:16:50 PM, you wrote: > > > I'm a native US speaker. The following is my opinion. > > > Alteration is a change in pitch from the base > > pitch. Base pitch is C, > > alteration is sharp, actual pitch is C#. > > >

Re: How to deal with failing 'make test-bseline'

Am So., 9. Feb. 2020 um 16:12 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Bringing some offlist-discussion back to the list because it may > > interest more people > > > > Am So., 9. Feb. 2020 um 12:44 Uhr schrieb David Kastrup : > > > >> The output of "make test" starts with a

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

Sunday, February 9, 2020, 2:16:50 PM, you wrote: > I'm a native US speaker. The following is my opinion. > Alteration is a change in pitch from the base > pitch. Base pitch is C, > alteration is sharp, actual pitch is C#. > Accidental is a change in pitch from the > standard scale pitch. As

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

Sunday, February 9, 2020, 2:09:09 PM, you wrote: >> On 9 Feb 2020, at 13:23, lilyp...@ptoye.com wrote: >> >> - >> Friday, February 7, 2020, 8:39:36 PM, you wrote: >> >>> Am 06.02.2020 um 22:55 schrieb >>> thomasmorle...@gmail.com:

Re: How to deal with failing 'make test-bseline'

Thomas Morley writes: > Bringing some offlist-discussion back to the list because it may > interest more people > > Am So., 9. Feb. 2020 um 12:44 Uhr schrieb David Kastrup : > >> The output of "make test" starts with a line "for tracing crashes, run >> the following command" followed by some

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

> On 9 Feb 2020, at 15:09, Graham King wrote: > > From a speed-reading of Gould, it appears that she uses the verb "alter" and > the adjective "altered", but _not_ the noun "alteration" in this context. > > It is worth noting that "alteration" has a very specific and well-established >

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

I'm a native US speaker. The following is my opinion. Alteration is a change in pitch from the base pitch. Base pitch is C, alteration is sharp, actual pitch is C#. Accidental is a change in pitch from the standard scale pitch. As mentioned by Peter, C# in a D major scale is not an

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

> On 9 Feb 2020, at 13:23, lilyp...@ptoye.com wrote: > > - > Friday, February 7, 2020, 8:39:36 PM, you wrote: > >> Am 06.02.2020 um 22:55 schrieb >> thomasmorle...@gmail.com: >>>

How to deal with failing 'make test-bseline'

Bringing some offlist-discussion back to the list because it may interest more people Am So., 9. Feb. 2020 um 12:41 Uhr schrieb Thomas Morley : > > Am So., 9. Feb. 2020 um 12:12 Uhr schrieb David Kastrup : > > > > Dan Eble writes: > > > > It would be nice if the test driver would not abort the

Re: Staging is broken

pkx1...@posteo.net writes: > Hello, > > .. > > Making lily/out/metronome-engraver.o < cc > Making lily/out/warn-scheme.o < cc > Making lily/out/lexer.o < cc > Making lily/out/parser.o < cc > ./out/parser.cc: In function 'int yyparse(Lily_parser*, > scm_unused_struct**)': >

Re: displayLilyMusic and guilev2

Thomas Morley writes: > Am So., 9. Feb. 2020 um 00:23 Uhr schrieb David Kastrup : >> >> Thomas Morley writes: >> >> > Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup : >> >> >> >> Thomas Morley writes: >> >> >> >> > Hi, >> >> > >> >> > one problem with guilev2 are anonymous procedures.

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

- Friday, February 7, 2020, 8:39:36 PM, you wrote: > Am 06.02.2020 um 22:55 schrieb > thomasmorle...@gmail.com: >> https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely >> File Documentation/learning/common-notation.itely

Re: displayLilyMusic and guilev2

Am So., 9. Feb. 2020 um 00:23 Uhr schrieb David Kastrup : > > Thomas Morley writes: > > > Am Sa., 8. Feb. 2020 um 23:59 Uhr schrieb David Kastrup : > >> > >> Thomas Morley writes: > >> > >> > Hi, > >> > > >> > one problem with guilev2 are anonymous procedures. Like how to get > >> > nice output

Re: Staging is broken

"no space left on device" Is that a full disk or something? On Sun, Feb 9, 2020, 13:10 wrote: > Hello, > > .. > > Making lily/out/metronome-engraver.o < cc > Making lily/out/warn-scheme.o < cc > Making lily/out/lexer.o < cc > Making lily/out/parser.o < cc > ./out/parser.cc: In function 'int

Staging is broken

Hello, .. Making lily/out/metronome-engraver.o < cc Making lily/out/warn-scheme.o < cc Making lily/out/lexer.o < cc Making lily/out/parser.o < cc ./out/parser.cc: In function 'int yyparse(Lily_parser*, scm_unused_struct**)': ./out/parser.cc:2917:12: warning: conversion to 'yytype_int16 {aka

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

On Feb 9, 2020, at 04:25, jonas.hahnf...@gmail.com wrote: > > Anyway I think adding a comment here and in smobs.cc how this is > initialized (refer to static lifetime in C/C++) would likely clarify the > intent. Initialization is an area where the legacy of the language is complicated (more

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

> > I'd love to see more opinions about comments #12 and #14. > > Otherwise I'd object to this part of the patch > > I agree with the objection raised in #12 +1 https://codereview.appspot.com/579280043/

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

On 2020/02/09 12:33:23, thomasmorley651 wrote: > I'd love to see more opinions about comments #12 and #14. > Otherwise I'd object to this part of the patch I agree with the objection raised in #12 https://codereview.appspot.com/579280043/

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

I'd love to see more opinions about comments #12 and #14. Otherwise I'd object to this part of the patch https://codereview.appspot.com/579280043/

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh File lily/include/smobs.hh (right): https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh#newcode312 lily/include/smobs.hh:312: static size_t count; On 2020/02/09 03:29:26, Dan Eble wrote: > It

Re: Doc: Some miscellaneous suggestions from Peter Toye (issue 579280043 by michael.kaepp...@googlemail.com)

Saturday, February 8, 2020, 6:07:23 PM, you wrote: See the line above which is in CMU Concrete! >> >>> ??? I use Emacs to read my e-mail, and emacs is configured to use >>> the font 'DejaVu Sans Mono' on my GNU/Linux box. This font >>> contains Cyrillic glyphs... >> >> I composed that

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

LGTM, thanks for this clearly documented change! https://codereview.appspot.com/561390043/

Re: can a Scheme engraver "solve" Issue #34 (grace note bug)? [cross-posted]

Kieren MacMillan writes: > Hi David (et al.), > >> I don't think grace notes are usually synchronized optically. > > According to our recent "live-from-London" keynote speaker… ;) > > … you are correct — in fact, in one example, she shows how grace > groups [of different "sizes"] on two

Re: [RFC] Commit message format

Jonas Hahnfeld via Discussions on LilyPond development writes: > For SHA1, I'd recommend using more than 6 chars to avoid collisions. > The Linux kernel encourages 12 characters [1], but I think we are good > with less. $ git log --oneline currently shows 10 chars for the > LilyPond repo, that

Re: Correction for snippet 446

Am So., 9. Feb. 2020 um 09:58 Uhr schrieb Werner LEMBERG : > > > Snipped 446 ('Modifying default values for articulation shorthand > notation') still talks about 'dashBar', which has been replaced by > 'dashBang' in 2013. > > Please fix. Alternatively, please make me (user 'lemzwerg' on LSR) an >

New Japanese PO file for 'lilypond' (version 2.19.84)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Japanese team of translators. The file is available at: https://translationproject.org/latest/lilypond/ja.po (We can arrange things so

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh File lily/include/smobs.hh (right): https://codereview.appspot.com/561390043/diff/567180043/lily/include/smobs.hh#newcode312 lily/include/smobs.hh:312: static size_t count; On 2020/02/09 03:29:26, Dan Eble wrote: > It

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

On 2020/02/09 09:55:12, hahnjo wrote: > On 2020/02/09 09:36:40, hanwenn wrote: > > On Sun, Feb 9, 2020 at 10:25 AM wrote: > > > FWIW I tried to research on the internals of GC. I found the following > > > statement that decides whether to collect or just expand

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

On 2020/02/09 09:36:40, hanwenn wrote: > On Sun, Feb 9, 2020 at 10:25 AM wrote: > > FWIW I tried to research on the internals of GC. I found the following > > statement that decides whether to collect or just expand the heap: > >

Re: [RFC] Commit message format

Am Freitag, den 07.02.2020, 12:37 -0500 schrieb Dan Eble: > On Feb 7, 2020, at 10:39, Han-Wen Nienhuys < > hanw...@gmail.com > > wrote: > > There are a couple of downsides to this format: > > * The number takes up space in the > >git log --format=short > > upside: the number appears in git

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

On Sun, Feb 9, 2020 at 10:25 AM wrote: > The approach sounds good to me. I can confirm that this works on my > system and the runtime is pretty good. Please readd the autoconf logic > to detect bdw-gc. > will do. > FWIW I tried to research on the internals of GC. I found the following >

Re: Grow heap aggressively during music interpretation (issue 561390043 by hanw...@gmail.com)

The approach sounds good to me. I can confirm that this works on my system and the runtime is pretty good. Please readd the autoconf logic to detect bdw-gc. FWIW I tried to research on the internals of GC. I found the following statement that decides whether to collect or just expand the heap:

Correction for snippet 446

Snipped 446 ('Modifying default values for articulation shorthand notation') still talks about 'dashBar', which has been replaced by 'dashBang' in 2013. Please fix. Alternatively, please make me (user 'lemzwerg' on LSR) an editor so that I can do it myself :-) Werner

GUILE2: softcode GC environment tuning (issue 563500045 by hanw...@gmail.com)

LGTM https://codereview.appspot.com/563500045/