Re: Naming question for get_property, set_property

On Feb 10, 2020, at 21:35, David Kastrup wrote: > property_set (grob, "stencil", SCM_BOOL_F); > > and > > property_get (grob, "color") These are fine. — Dan

Re: Naming question for get_property, set_property

David Kastrup writes: > Dan Eble writes: > >> On Feb 10, 2020, at 17:47, David Kastrup wrote: >>> It will look a bit redundant either way with >>> >>> grob->Get (Grob, "color"); >>> or >>> grob->grob_set ("stencil", SCM_BOOL_F); >> >> "Yuck" either way. Removing "property" to shorten the

Re: Naming question for get_property, set_property

Dan Eble writes: > On Feb 10, 2020, at 17:47, David Kastrup wrote: >> It will look a bit redundant either way with >> >> grob->Get (Grob, "color"); >> or >> grob->grob_set ("stencil", SCM_BOOL_F); > > "Yuck" either way. Removing "property" to shorten the name is not a > good course of action.

Re: Naming question for get_property, set_property

On Feb 10, 2020, at 17:47, David Kastrup wrote: > It will look a bit redundant either way with > > grob->Get (Grob, "color"); > or > grob->grob_set ("stencil", SCM_BOOL_F); "Yuck" either way. Removing "property" to shorten the name is not a good course of action. My brainstorming without

Re: Integration of Guilev2 branches into master

On 2/10/2020 3:22 PM, Han-Wen Nienhuys wrote: How are filenames encoded on Windows? Not sure which Microsoft document is authoritative, but... " NTFS stores file names in Unicode. In contrast, the older FAT12, FAT16, and FAT32 file systems use the OEM character set. "

Re: Integration of Guilev2 branches into master

Am Mo., 10. Feb. 2020 um 22:43 Uhr schrieb David Kastrup : > > Han-Wen Nienhuys writes: > > > On Mon, Feb 10, 2020 at 9:44 PM Thomas Morley > >> (2) > >> A guile-2 build from current master is unable to find the file. > >> warning: cannot find file: `filename_?.ly' > >> fatal error:

Re: Integration of Guilev2 branches into master

Am Mo., 10. Feb. 2020 um 22:22 Uhr schrieb Han-Wen Nienhuys : > > > > On Mon, Feb 10, 2020 at 9:44 PM Thomas Morley > wrote: >> >> >> One is called 'filename.ly' the other 'filename_名字♯.ly' >> >> Observations >> (1) >> With 2.19.84 both files are found and compiled. >> 'filename_名字♯.ly' needs

Naming question for get_property, set_property

So for longterm efficiency reasons I am planning to reimplement the get_property/set_property macros and underlying data structures that map to get_property_internal/set_property_internal. They are currently used across a number of types in a sort of polymorphism, and for "reasons" I need to

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

Han-Wen Nienhuys writes: > On Mon, Feb 10, 2020 at 2:40 PM David Kastrup wrote: > >> >> > Short repro: >> > >> > fail-func = >> > #(define-music-function (name) >> >(string?) >> > #{ >> > \new Staff = #(string-append "bla" name) { c'4 } >> > #} >> > ) >> > >> > \fail-func "bla" >>

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

On 2020/02/10 22:00:04, michael.kaeppler wrote: > However, I think that the description of LilyPond's internal pitch data > structure > is not helpful for this (pretty introductory) part of the docs. Agreed. > The longer I think about it, the more I'm unsure if the term "alteration" makes >

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

On Mon, Feb 10, 2020 at 2:40 PM David Kastrup wrote: > > > Short repro: > > > > fail-func = > > #(define-music-function (name) > >(string?) > > #{ > > \new Staff = #(string-append "bla" name) { c'4 } > > #} > > ) > > > > \fail-func "bla" > > Still assuming that this is with your

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

On 2020/02/09 16:15:53, thomasmorley651 wrote: > On 2020/02/09 15:32:14, http://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: engraver: continue when trying to create non-existent Grob (issue 547620043 by hanw...@gmail.com)

On 2020/02/10 21:40:03, dak wrote: > On 2020/02/10 21:35:30, hanwenn wrote: > > On 2020/02/10 21:31:46, dak wrote: > > > https://codereview.appspot.com/547620043/diff/545560043/lily/engraver.cc > > > File lily/engraver.cc (right): > > > > > > > > >

Re: Integration of Guilev2 branches into master

Han-Wen Nienhuys writes: > On Mon, Feb 10, 2020 at 9:44 PM Thomas Morley > wrote: > >> >> One is called 'filename.ly' the other 'filename_名字♯.ly >> ' >> >> Observations >> (1) >> With 2.19.84 both files are found and compiled. >> 'filename_名字♯.ly

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

On 2020/02/09 14:16:51, Carl 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 mentioned by >

Re: engraver: continue when trying to create non-existent Grob (issue 547620043 by hanw...@gmail.com)

On 2020/02/10 21:35:30, hanwenn wrote: > On 2020/02/10 21:31:46, dak wrote: > > https://codereview.appspot.com/547620043/diff/545560043/lily/engraver.cc > > File lily/engraver.cc (right): > > > > > https://codereview.appspot.com/547620043/diff/545560043/lily/engraver.cc#newcode126 > >

Re: engraver: continue when trying to create non-existent Grob (issue 547620043 by hanw...@gmail.com)

Reviewers: dak, Message: On 2020/02/10 21:31:46, dak wrote: > https://codereview.appspot.com/547620043/diff/545560043/lily/engraver.cc > File lily/engraver.cc (right): > > https://codereview.appspot.com/547620043/diff/545560043/lily/engraver.cc#newcode126 > lily/engraver.cc:126: grob = new Item

engraver: continue when trying to create non-existent Grob (issue 547620043 by hanw...@gmail.com)

https://codereview.appspot.com/547620043/diff/545560043/lily/engraver.cc File lily/engraver.cc (right): https://codereview.appspot.com/547620043/diff/545560043/lily/engraver.cc#newcode126 lily/engraver.cc:126: grob = new Item (SCM_EOL); Ugh. How is that going to work? I am not sure we aren't

input/regression/multi-measure-rest-reminder: a demo of user-defined grobs (issue 557380044 by hanw...@gmail.com)

Thanks for providing a test. Not able to run it right now, maybe tomorrow. https://codereview.appspot.com/557380044/diff/563510046/input/regression/multi-measure-rest-reminder.ly File input/regression/multi-measure-rest-reminder.ly (right):

Re: Integration of Guilev2 branches into master

On Mon, Feb 10, 2020 at 9:44 PM Thomas Morley wrote: > > One is called 'filename.ly' the other 'filename_名字♯.ly > ' > > Observations > (1) > With 2.19.84 both files are found and compiled. > 'filename_名字♯.ly ' needs

Re: Integration of Guilev2 branches into master

Am Mo., 10. Feb. 2020 um 12:40 Uhr schrieb David Kastrup : > > Han-Wen Nienhuys writes: > > > 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

PATCHES - Countdown for February 10th

Hello, Here is the current patch countdown list. The next countdown will be on February 12th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ *** Push: 5703 Run scripts/auxiliar/fixcc.py - David Kastrup

Re: Integration of Guilev2 branches into master

David Kastrup writes: > Han-Wen Nienhuys writes: > >> 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: > >

Re: [RFC] weekly dev chats

> Found "Pidgin messenger" installed on my Ubuntu Studio. It purports to > talk AIM, Bonjour, Gadu-Gadu, Google Talk, Groupwise, ICQ, IRC, Simple, > Sametime, XMPP and Zephyr. No idea whether it does screencasts. FWIW, I’ve had positive experiences with Jitsi: https://jitsi.org/ It requires a

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

Han-Wen Nienhuys writes: > 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 >>

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

Han-Wen Nienhuys writes: > On Mon, Feb 10, 2020 at 9:41 AM Han-Wen Nienhuys wrote: > >> Yes. See also the list of commits that are effectively reverted by this >> commit. >> >> Note that there is still an off-by one error in the handling of closures >> and parsing #{ >> >> > Short repro: > >

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

Han-Wen Nienhuys writes: > On Sun, Feb 9, 2020 at 7:00 PM wrote: > >> 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

Re: Integration of Guilev2 branches into master

Han-Wen Nienhuys writes: > 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

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

On Mon, Feb 10, 2020 at 9:41 AM Han-Wen Nienhuys wrote: > Yes. See also the list of commits that are effectively reverted by this > commit. > > Note that there is still an off-by one error in the handling of closures > and parsing #{ > > Short repro: fail-func = #(define-music-function (name)

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

On Sun, Feb 9, 2020 at 7:00 PM wrote: > 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

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

Am Montag, den 10.02.2020, 07:58 +0100 schrieb Han-Wen Nienhuys: > Very nice. Why is the project/user called lilypond-issues? Because I don't want to to do this with my personal account. First I created a personal repo hahnjo/lilypond and granted lilypond-issues access to it. That doesn't work

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

Am Sonntag, den 09.02.2020, 23:34 +0100 schrieb Federico Bruni: > Il giorno dom 9 feb 2020 alle 22:50, Jonas Hahnfeld < > hah...@hahnjo.de > > > ha scritto: > > Thanks for sharing! I put together a simplistic script to create a > > proof-of-concept: > >