Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

http://codereview.appspot.com/160048/diff/1/5 File scm/markup.scm (right): http://codereview.appspot.com/160048/diff/1/5#newcode74 scm/markup.scm:74: [ :category category ] On 2009/11/24 11:01:59, Carl wrote: Does this need to be [ #:category category ] ? Done. http://codereview.appspot.com/

Re: Doc: improve doc on markup command writing (issue157133)

It would make sense to apply http://codereview.appspot.com/160048> first and make this patch work on top of that. There may be cases where a separate property-bind like this is useful in called routines, and the markup commands from the mentioned patch might make use of it for implementing #:prop

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

On 2009/11/26 09:13:58, nicolas.sceaux wrote: Hi, Maybe this patch, as a first step, should focus on the unification of the syntax of the two macros? Hi Nicolas, patch set 3 already makes make-builtin-markup-command upwards-compatible with make-markup-command in its current form. I have

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

Thanks for looking this over. This patch set is sort of a moving target due to the removal of markup-init.ly. For example, recently documentation about the module related definitions in markup-init.ly has been added to the programmer's documentation. If removing markup-init.ly can be done succe

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

On 2009/12/03 17:34:24, c_sorensen_byu.edu wrote: > > I have not yet done anything in that respect since I have no idea yet > where to properly place the code turning on/off the documentation > collection. > How about scm/document-markup.scm? AFAICS scm/document-markup.scm is only loaded

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

On 2009/12/03 22:26:04, dak wrote: On 2009/12/03 17:34:24, c_sorensen_byu.edu wrote: > > How about scm/document-markup.scm? AFAICS scm/document-markup.scm is only loaded on documentation runs, and then last. I don't see how it could be used for switching documentation collect

Re: Chord repetition: \relative mode (issue164096)

On 2009/12/06 17:23:13, nicolas.sceaux wrote: When dealing with a simple_chord_element (simple notes, rests, etc) or a note_chord_element (chord with several notes), the parser updates the memorized chord by calling a user-settable memorization function (see parser.yy). I think it is the w

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)

On 2020/02/07 09:19:03, hanwenn wrote: > David mentions \cadenzaOff in the issue tracker. I think you could fix the > behavior inside the Timing_engraver without requiring a new construct (although, > if we did this, we'd probably upset bar numbering across existing scores.) I think I tried. At

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

Ok, that should probably have been stressed somewhat stronger before: have you checked the preexisting Guilev2 work in branches that Harm pointed you to? The problem you are addressing here seems to be the same as the one tackled in commit c0a8eec034b94be14c7665e2d4c8a94fae111b78 , namely commit c

Re: Issue 5740: Add \post to defer context actions to end of time step (issue 581600043 by nine.fierce.ball...@gmail.com)

On 2020/02/07 15:43:30, Dan Eble wrote: > On 2020/02/07 09:19:03, hanwenn wrote: > > On 2020/02/06 14:29:55, Dan Eble wrote: > > More code means more maintenance liability, so unless > > it either solves a problem, or it simplifies the existing system, it would be > a > > net negative. > > You're

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

On 2020/02/07 17:10:24, hanwenn wrote: > FWIW, the 2014 commit lacks explanation and comments of what is going on. I > would rather see "production quality" code that we submit to master, so we > have a precise record of what is going on, and can make sure the code > keeps working. The one I no

Re: parser-ly-from-scheme: Make #{ compilable (issue 581610043 by d...@gnu.org)

; > Which is nice. > > Not sure whether it's a lilypond or guile improvement. Uh, is this the right issue to discuss this with? Also dak@lola:/usr/local/tmp/lilypond$ dpkg -l guile-2.2-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-in

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

On 2020/02/08 22:57:13, janek wrote: > Because of significant disagreement, and to ensure that LilyPond contributors > don't feel pushed, I am hereby officially withdrawing this proposal. I apologize > for the disturbance caused by the way I have introduced this. > > Maybe I'll submit a revised pr

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)

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: 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 Un

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): > > https://codereview.appspot.com/547610043/diff/567190043/scm/define-note-names.scm#newco

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: 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 '\' --pickaxe

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 b

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/e

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

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

https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py File python/musicexp.py (right): https://codereview.appspot.com/547610043/diff/557380043/python/musicexp.py#newcode324 python/musicexp.py:324: return str On 2020/02/11 20:39:14, Be-3 wrote: > Proposal: > keep 1st characte

Re: Special-case syntax error of duration before octave marks (issue 557410043 by d...@gnu.org)

Reviewers: lemzwerg, Carl, Message: On 2020/02/11 22:37:39, Carl wrote: > On 2020/02/11 21:46:52, lemzwerg wrote: > > Good idea! From inspection only, LGTM. > > Sounds like a great idea! > > Carl Well, I sort of got a feature request.

Re: Special-case syntax error of duration before octave marks (issue 557410043 by d...@gnu.org)

https://codereview.appspot.com/557410043/diff/545570043/lily/parser.yy File lily/parser.yy (right): https://codereview.appspot.com/557410043/diff/545570043/lily/parser.yy#newcode3676 lily/parser.yy:3676: | pitch exclamations questions octave_check duration stray_quotes optional_rest post_events

Move include guard for fluid.hh (issue 565640043 by hanw...@gmail.com)

Guess a full test cycle for this one would be excessive. As far as I am concerned, feel free to push this one. https://codereview.appspot.com/565640043/

Remove unused ly_hash_scm (issue 569340043 by hanw...@gmail.com)

Issue title is wrong. Function is ly_scm_hash, not ly_hash_scm. Also its prototype in lily/include/lily-guile.hh should get removed. https://codereview.appspot.com/569340043/

Re: Special-case syntax error of duration before octave marks (issue 557410043 by d...@gnu.org)

On 2020/02/13 13:37:52, hanwenn wrote: > looks OK. > > Is there a way to exercise this? Maybe with #{ c4'' #} or something? Just { c4'' } would do it, but regtesting error messages is pretty icky. Warnings are more straightforward, but I really want an error. https://codereview.appspot.com/5574

Re: Don't count terminating \0 in Source_file::length (issue 579310043 by hanw...@gmail.com)

https://codereview.appspot.com/579310043/diff/549550043/lily/source-file.cc File lily/source-file.cc (right): https://codereview.appspot.com/579310043/diff/549550043/lily/source-file.cc#newcode51 lily/source-file.cc:51: characters_.push_back ((char)c); Frankly, this seems like C++ should offer s

Re: Don't count terminating \0 in Source_file::length (issue 579310043 by hanw...@gmail.com)

https://codereview.appspot.com/579310043/diff/561450043/lily/source-file.cc File lily/source-file.cc (right): https://codereview.appspot.com/579310043/diff/561450043/lily/source-file.cc#newcode137 lily/source-file.cc:137: data_ = string (&chars[0], chars.size ()); gulp_file_to_string ? That one

Re: musicxml2ly: portugues notenames and quarternotes in español (issue 571630043 by d...@gnu.org)

Reviewers: hanwenn, https://codereview.appspot.com/571630043/diff/567240043/python/musicexp.py File python/musicexp.py (right): https://codereview.appspot.com/571630043/diff/567240043/python/musicexp.py#newcode375 python/musicexp.py:375: "portugues": pitch_portugues, On 2020/02/15 12:19:54, hanw

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

On 2020/02/16 20:37:34, hanwenn wrote: > David, this goes on top of https://codereview.appspot.com/555300043/ > > maybe I am missing something, but the regtest completes successfully. Why did > you add this stuff? To allow for making aliases etc. A markup command definition involves a number of

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

> In this commit, extra support for the case where command-and-args is empty was added, ie. That characterisation is completely wrong. The support is not for the cases "where command-and-args is empty" but rather where command-and-args is not a list but a single symbol. Just like (define symbol

Re: Generate dependency files with Clang (issue 555300044 by jonas.hahnf...@gmail.com)

On 2020/02/16 21:12:50, lemzwerg wrote: > Good idea, thanks! LGTM. > > Apropos .lo files: We can remove STEPMAKE_LIBTOOL in `aclocal.m4` since it isn't > used. I think this change would probably fit into this issue, too. .lo files were likely needed for the midi module used in some Python progr

Re: Simplify define-markup-[list-]command-internal, (issue 545590045 by hanw...@gmail.com)

On 2020/02/16 21:23:56, hanwenn wrote: > On Sun, Feb 16, 2020 at 9:57 PM wrote: > > > > In this commit, extra support for the case where command-and-args is > > empty was added, ie. > > > > That characterisation is completely wrong. The support is not for the > > cases "wher

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

On 2020/02/17 10:01:29, hanwenn wrote: > https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measure-rest-reminder.ly > File input/regression/multi-measure-rest-reminder.ly (right): > > https://codereview.appspot.com/557380044/diff/569320045/input/regression/multi-measur

Re: Issue 5771: simplify \partial (issue 557440043 by nine.fierce.ball...@gmail.com)

https://codereview.appspot.com/557440043/diff/547670043/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/557440043/diff/547670043/ly/music-functions-init.ly#newcode1319 ly/music-functions-init.ly:1319: 'origin (*location*) On 2020/02/17 16:59:54,

Re: Issue 5771: simplify \partial (issue 557440043 by nine.fierce.ball...@gmail.com)

On 2020/02/17 19:17:04, Dan Eble wrote: > On 2020/02/17 18:41:58, dak wrote: > > Are you sure this is actually a working idea? At the beginning of music, > Score > > does not exist and 'Timing is only (reliably?) established as an alias by the > > Timing_translator.

Re: Implement Grob::event_cause, Grob::ultimate_event_cause (issue 559500043 by d...@gnu.org)

Reviewers: hahnjo, hanwenn, Dan Eble, https://codereview.appspot.com/559500043/diff/559510043/lily/grob.cc File lily/grob.cc (right): https://codereview.appspot.com/559500043/diff/559510043/lily/grob.cc#newcode733 lily/grob.cc:733: while (unsmob (cause)) On 2020/02/21 00:13:25, Dan Eble wrote: >

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

https://codereview.appspot.com/569390043/diff/551480043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/569390043/diff/551480043/aclocal.m4#newcode760 aclocal.m4:760: guile2.2-config guile-2.2-config guile-config-2.2 guile-config2.2 \ I think that at the current point of time,

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On 2020/02/21 16:02:14, hahnjo wrote: > guile-config since 2.0 has the following comment: > "This script has been deprecated. Just use pkg-config." It is not something it outputs but rather a script-internal comment. > Mabye it makes sense to completely turn to pkg-config? My system has $ ll > /u

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On 2020/02/21 17:03:07, hanwenn wrote: > make baseline: > > 1.8: > real 3m41.714s > user 6m52.414s > sys 0m36.662s > > 2.2: > real 6m8.344s > user 12m51.799s > sys 0m34.875s > > I think this warrants some deeper look, though: I have the impression that the > lilypond-book regression test

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

On 2020/02/22 22:08:33, hanwenn wrote: > On 2020/02/22 22:01:10, lemzwerg wrote: > > Never seen such code before, but if it fixes an issue... :-) > > it's a cut and paste from the internet, > https://blog.apokalyptik.com/2007/10/24/bash-tip-closing-file-descriptors/ > > I'm surprised that make pa

Re: Use $(MAKE) instead of 'make' in lilypond-book regtests (issue 569400043 by hanw...@gmail.com)

On 2020/02/22 23:18:43, hanwenn wrote: > On 2020/02/22 23:17:50, hanwenn wrote: > > you were already potentially in a state where you have 3 jobs each spawning 3 > > lp-book invocations, > > whoops, I mean: 3 lp-book invocations spawning 3 lilypond subprocesses each, for > 9 in total. Considering

Re: Use $(MAKE) instead of 'make' in lilypond-book regtests (issue 569400043 by hanw...@gmail.com)

On 2020/02/22 23:56:23, hanwenn wrote: > On Sun, Feb 23, 2020 at 12:29 AM wrote: > > > > On 2020/02/22 23:18:43, hanwenn wrote: > > > On 2020/02/22 23:17:50, hanwenn wrote: > > > > you were already potentially in a state where you have 3 jobs each > > spawning 3 > > > > lp-boo

Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

Stupid question: does the database design of lilypond-book even allow for uncoordinated parallel runs? https://codereview.appspot.com/547680043/

Re: Allow parallelism in input/regression/lilypond-book/ (issue 547680043 by hanw...@gmail.com)

On 2020/02/23 10:29:53, hanwenn wrote: > On 2020/02/23 10:04:46, hanwenn wrote: > > On 2020/02/23 09:49:24, dak wrote: > > > Stupid question: does the database design of lilypond-book even allow for > > > uncoordinated parallel runs? > > > > It's

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 15:54:54, hanwenn wrote: > I think this is worth it because it simplifies the build system, and puts the > locking in the place where we actually access the resource. Is there any indication that letting Make run multiple instances of lilypond-book with every instance except one at a

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 16:23:34, hanwenn wrote: > On 2020/02/23 16:05:08, dak wrote: > > On 2020/02/23 15:54:54, hanwenn wrote: > > > I think this is worth it because it simplifies the build system, and puts > the > > > locking in the place where we actually access the r

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/23 15:59:14, hahnjo wrote: > On 2020/02/23 15:54:54, hanwenn wrote: > > I think this is worth it because it simplifies the build system, and puts the > > locking in the place where we actually access the resource. > > Let me disagree: It complicates lilypond-book with something that no

Re: Issue 5790: Rational conversion clean-up (issue 573570043 by nine.fierce.ball...@gmail.com)

On 2020/02/25 08:07:14, hanwenn wrote: > LGTM > > (I wonder if we should bite the bullet and use uint64_t iso. U64.) Just for the record: the big bullet would be a Simple_smob wrapper class around Guile's rational data type. Showstopper in the current setup: Moments in data structures contain ra

Re: .dir-locals.el: spell out nil settings (issue 545640044 by d...@gnu.org)

Reviewers: lemzwerg, Message: On 2020/02/25 11:29:35, lemzwerg wrote: > LGTM. Please directly push. I think the reason I could answer this more or less off-the-cuff was that it confused the heck out of me until I figured out the reason. So my fear is that when people now use M-x add-directory-l

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/25 13:06:31, Be-3 wrote: > On 2020/02/24 06:44:39, hanwenn wrote: > > One thing to consider: since the mechanics are now very predictable, maybe we > > can name the property in after its mechanics? ie. french-correction -> > > stem-end-shorten or something? > > After having thought abou

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/25 13:33:13, lemzwerg wrote: > > > Please add one or more test cases for your 'french-correction' property. > > > > What specific French beaming examples are you missing? > > I was probably unclear. What I want is an example that shows how the > 'french-correction' *property* changes

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/26 08:28:33, hahnjo wrote: > On 2020/02/26 08:19:39, hahnjo wrote: > > > On a philosophical level, it is a lilypond-book implementation detail > > > that it can't deal with concurrent invocation, so the remediation for > > > this problem should be in lilypond-book too. > > > > Let me d

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

https://codereview.appspot.com/557500043/diff/563610046/scm/define-grob-properties.scm File scm/define-grob-properties.scm (right): https://codereview.appspot.com/557500043/diff/563610046/scm/define-grob-properties.scm#newcode1374 scm/define-grob-properties.scm:1374: amount of space in case of F

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/26 21:50:05, lemzwerg wrote: > > How about > > * beamed-stem-french-adjustment > > * french-beaming-stem-adjustment > > …? > > I like the second one. I'd be fine with it. https://codereview.appspot.com/557500043/

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/28 17:57:06, hanwenn wrote: > On 2020/02/26 11:59:14, dak wrote: > > It doesn't state at all what happens in cases of contentions. Fixing > > contentions with a lock is a brute-force solution just not allowing for > > parallelism, but it is a solution

Re: build cleanups. (issue 547690053 by hanw...@gmail.com)

https://codereview.appspot.com/547690053/diff/567300043/config.make.in File config.make.in (right): https://codereview.appspot.com/547690053/diff/567300043/config.make.in#newcode48 config.make.in:48: GROFF = @GROFF@ These sort of drive-by changes without any mention in commit message or issue ma

Re: build cleanups. (issue 547690053 by hanw...@gmail.com)

t.com/547690053/diff/567300043/config.make.in#newcode48 > config.make.in:48: GROFF = @GROFF@ > On 2020/02/29 22:03:03, dak wrote: > > These sort of drive-by changes without any mention in commit message or issue > > make it a bit harder to review. I find > > > > stepma

Re: Remove unused .1 => .txt rule (issue 557560044 by hanw...@gmail.com)

On 2020/02/29 22:37:03, hanwenn wrote: > tested by running 'make dist' Maybe move the removal of the GROFF test/flag here? If there should be some unexpected breakage at some point of time, that makes it more likely that it can be handled with a single revert. https://codereview.appspot.com/5575

Re: Remove unused .1 => .txt rule (issue 557560044 by hanw...@gmail.com)

On 2020/02/29 23:57:03, dak wrote: > On 2020/02/29 22:37:03, hanwenn wrote: > > tested by running 'make dist' > > Maybe move the removal of the GROFF test/flag here? If there should be some > unexpected breakage at some point of time, that makes it more likely tha

Re: Make make-autochange function upwards-compatible to 2.18 (issue 567280043 by d...@gnu.org)

Reviewers: thomasmorley651, Message: On 2020/03/01 10:20:01, thomasmorley651 wrote: > LGTM I knew I forgot something. Let's see whether it's still getting picked up by Phil. Description: Make make-autochange function upwards-compatible to 2.18 This entails putting the ref-pitch argument last a

Re: Issue 5773: Quarter Tones for all Languages incl. MusicXML import (issue 577520043 by torsten.haemme...@web.de)

https://codereview.appspot.com/577520043/diff/555310043/Documentation/es/notation/pitches.itely File Documentation/es/notation/pitches.itely (right): https://codereview.appspot.com/577520043/diff/555310043/Documentation/es/notation/pitches.itely#newcode524 Documentation/es/notation/pitches.itely

Re: Issue 5773: Quarter Tones for all Languages incl. MusicXML import (issue 577520043 by torsten.haemme...@web.de)

ode{s}/@code{-sharp}} {@code{f}/@code{-flat}} > {@code{ss}/@code{x}/@code{-sharpsharp}} {@code{ff}/@code{-flatflat}} > On 2020/03/01 19:54:14, dak wrote: > > I am pretty sure that those aren't the Portuguese note names here. > > No, definitely not. > BUT (!) the @multi

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/28 18:14:14, dak wrote: > On 2020/02/28 17:57:06, hanwenn wrote: > > On 2020/02/26 11:59:14, dak wrote: > > > > It doesn't state at all what happens in cases of contentions. Fixing > > > contentions with a lock is a brute-force solution just not all

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On 2020/02/21 16:34:35, hahnjo wrote: > On 2020/02/21 16:22:52, lemzwerg wrote: > > > Mabye it makes sense to completely turn to pkg-config? > > > > Sounds sensible. In particular, it eases cross-compilation. > > Reading my mind ;-) > > On 2020/02/21 16:2

Re: Fix Windows resource to enable manifest (issue 551580044 by truer...@gmail.com)

On 2020/03/08 11:27:52, Be-3 wrote: > LGTM (in combination with issue 5833). Many users of Windows will be quite > happy about this (myself included). > > Wouldn't this have merited an entry in changes.tely? After all, UTF-8 filenames > had never worked in Windows from the beginning, so it'd pro

Re: Fix Windows resource to enable manifest (issue 551580044 by truer...@gmail.com)

On 2020/03/08 12:16:55, thomasmorley651 wrote: > On 2020/03/08 12:11:43, Be-3 wrote: > > On 2020/03/08 11:38:29, dak wrote: > > > We don't really document bug fixes as a rule in changes.tely. It's pretty > > long > > > already... > > > >

Re: Calculate download sizes rather than hardcoding them (issue 567340043 by d...@gnu.org)

On 2020/03/08 20:25:50, hahnjo wrote: > A general question that I'm probably just unable to find in the script: As far > as I understand the documentation file changes, this will include download sizes > for both stable and devel releases. How is this going to work for a single > source tree that i

Re: Calculate download sizes rather than hardcoding them (issue 567340043 by d...@gnu.org)

On 2020/03/08 20:49:46, hahnjo wrote: > On 2020/03/08 20:45:46, dak wrote: > > On 2020/03/08 20:25:50, hahnjo wrote: > > > "sed -i" is not portable and doesn't work on FreeBSD and macOS IIRC. I > didn't > > > check the other commands in here, bu

Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)

On 2020/03/12 08:01:03, hahnjo wrote: > On 2020/03/11 23:49:23, dak wrote: > > [...] > > GNU LilyPond 2.21.0 > > cp: cannot stat '19.sub{-*.signature,.ly,-1.eps,.log,.profile}': No such file > or > > directory > > test results in ./out/test-output

Re: Address output-distance problems: (issue 563730043 by hanw...@gmail.com)

On 2020/03/12 09:52:31, hahnjo wrote: > On 2020/03/12 09:33:43, hahnjo wrote: > > On 2020/03/12 09:22:09, dak wrote: > > > On 2020/03/12 08:01:03, hahnjo wrote: > > > > This looks like bash-ism which might explain why it works for Han-Wen and > > me. > >

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by hanw...@gmail.com)

Why would we want to move away from GNU make as a build system? https://codereview.appspot.com/553700043/

Re: Remove compat hack for Solaris7 and HP-UX (issue 579480047 by hanw...@gmail.com)

https://codereview.appspot.com/579480047/diff/547750043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/579480047/diff/547750043/aclocal.m4#newcode694 aclocal.m4:694: AC_PATH_PROG(BASH, bash, $SHELL) This sets BASH with a fallback to /bin/sh , meaning that $BASH is not guarant

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by hanw...@gmail.com)

https://codereview.appspot.com/553700043/diff/567370043/mf/invoke-mf2pt.sh File mf/invoke-mf2pt.sh (right): https://codereview.appspot.com/553700043/diff/567370043/mf/invoke-mf2pt.sh#newcode4 mf/invoke-mf2pt.sh:4: realpath() { On 2020/03/17 07:41:25, hahnjo wrote: > AFAIK sh syntax would be > re

Re: aclocal.m4: Support GUILE_CONFIG, document GUILE_FLAVOR (issue 575860044 by d...@gnu.org)

On 2020/03/20 14:54:36, hahnjo wrote: > Generally looks fine to me, you only might want to revisit indention: aclocal.m4 > uses 4 spaces instead of tabs. Uh, right. Done. https://codereview.appspot.com/575860044/

Re: aclocal.m4: Support GUILE_CONFIG, document GUILE_FLAVOR (issue 575860044 by d...@gnu.org)

https://codereview.appspot.com/575860044/diff/547790043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/575860044/diff/547790043/aclocal.m4#newcode625 aclocal.m4:625: AC_ARG_VAR(GUILE_FLAVOR, AS_HELP_STRING([], On 2020/03/21 05:41:05, lemzwerg wrote: > What about breaking the

Re: Remove trailing whitespace {python,scm,lily,scripts}. (issue 547810043 by hanw...@gmail.com)

On 2020/03/21 13:14:50, hahnjo wrote: > Sending to lilypond-devel for broader notice. This is likely to give conflicts, > maybe we can combine this with running fixcc.py? Ah right, that one was still pending anyway. I think it would take care of trailing spaces in the C++ files. https://coderevi

Re: Remove trailing whitespace {python,scm,lily,scripts}. (issue 547810043 by hanw...@gmail.com)

On 2020/03/21 14:17:03, dak wrote: > On 2020/03/21 13:14:50, hahnjo wrote: > > Sending to lilypond-devel for broader notice. This is likely to give > conflicts, > > maybe we can combine this with running fixcc.py? > > Ah right, that one was still pending anyway. I thi

Re: Issue 5862: Prefer astyle 3.1 and update clang-format options (issue 551640043 by nine.fierce.ball...@gmail.com)

On 2020/03/26 01:25:57, Dan Eble wrote: > It's worth emphasizing this: even with these improvements to the clang-format > configuration, those who use clang-format will introduce a truckload of > differences from the traditional indentation. Our own fixcc script introduces some modifications to na

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

What I am worried about is a partitura that puts common dynamics on every staff, including staves without notes. That would keep those from being kept alive. So the question is whether we should not possibly create a different keepAliveInterfaces for the Dynamics context? Opinions? https://code

Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

Retaining define-markup-command-internal in order to allow defining markups in LilyPond syntax in a manner that stops being supported from Scheme seems like incoherent design. markup-lambdas can be created from within LilyPond using \markup ... \etc . Having them unusable from Scheme for the purp

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

On 2020/03/29 00:35:02, dak wrote: > Retaining define-markup-command-internal in order to allow defining markups in > LilyPond syntax in a manner that stops being supported from Scheme seems like > incoherent design. > > markup-lambdas can be created from within LilyPond using \

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

On 2020/03/29 13:55:41, hanwenn wrote: > On 2020/03/29 13:52:48, hanwenn wrote: > > retain existing > > how's this? This leaves things backward compatible. > > Note that we're currently incoherent, because you can't do > > (let ((n 0)) (define sym val)) "incoherent" means in conflict with one

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

On 2020/03/29 13:55:41, hanwenn wrote: > On 2020/03/29 13:52:48, hanwenn wrote: > > retain existing > > how's this? This leaves things backward compatible. Ugly and a maintenance burden since the code is used twice. Anything wrong with my proposal? It does not have duplicate code, makes define-

Re: Define Scheme markups using define-public (issue 577720043 by hanw...@gmail.com)

On 2020/03/29 14:35:43, hanwenn wrote: > On Sun, Mar 29, 2020 at 4:12 PM wrote: > > > > On 2020/03/29 13:55:41, hanwenn wrote: > > > On 2020/03/29 13:52:48, hanwenn wrote: > > > > retain existing > > > > > > how's this? This leaves things backward compatible. > > > > Ugly and

Re: Remove all uses of markup macro from scm/*.scm (issue 575930043 by d...@gnu.org)

https://codereview.appspot.com/575930043/diff/561620044/scm/time-signature.scm File scm/time-signature.scm (right): https://codereview.appspot.com/575930043/diff/561620044/scm/time-signature.scm#newcode23 scm/time-signature.scm:23: (mup (if (procedure? proc) On 2020/03/30 21:15:15, hanwenn wrote

Re: Refactor \markup \pattern (issue 549780045 by d...@gnu.org)

Reviewers: hanwenn, https://codereview.appspot.com/549780045/diff/30045/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): https://codereview.appspot.com/549780045/diff/30045/scm/define-markup-commands.scm#newcode4636 scm/define-markup-commands.scm:4636: (space (

Re: mf: use python scripting for generating Emmentaler fonts (issue 553580043 by hanw...@gmail.com)

On 2020/04/02 20:32:39, hanwenn wrote: > Jonas, what is the status of 2.21.0 ? I wanted to give Phil the go-ahead tomorrow, once some backdated convert-ly rule is in. Probably depends on how well the LSR import works whether this gets out then. https://codereview.appspot.com/553580043/

Re: mf: use python scripting for generating Emmentaler fonts (issue 553580043 by hanw...@gmail.com)

On 2020/04/02 21:09:57, thomasmorley651 wrote: > On 2020/04/02 21:04:06, dak wrote: > > On 2020/04/02 20:32:39, hanwenn wrote: > > > Jonas, what is the status of 2.21.0 ? > > > > I wanted to give Phil the go-ahead tomorrow, once some backdated convert-ly > rule &g

output-distance: write HTML as UTF-8 (issue 563810043 by hanw...@gmail.com)

Is this likely related to the problems in `make check` that James currently experiences? https://codereview.appspot.com/563810043/

Re: output-distance: write HTML as UTF-8 (issue 563810043 by hanw...@gmail.com)

https://codereview.appspot.com/563810043/diff/545810044/scripts/build/output-distance.py File scripts/build/output-distance.py (right): https://codereview.appspot.com/563810043/diff/545810044/scripts/build/output-distance.py#newcode1328 scripts/build/output-distance.py:1328: system (u'echo HEAD

Re: Remove all uses of markup macro from scm/*.scm (issue 575930043 by d...@gnu.org)

On 2020/04/03 22:22:31, hanwenn wrote: > note that this still doesn't fix the next error message for compilation which is > > > > fatal error: Not a markup command: line > > which is triggered by the *definition* of the markup macro: > > (defmacro*-public markup (#:rest body) > .. > (car (co

Re: Fix line comments for new snippets (issue 549820043 by d...@gnu.org)

Reviewers: lemzwerg, Message: On 2020/04/06 12:40:50, lemzwerg wrote: > LGTM, and please push directly. I'd rather not have 2.21.0 in a state inconsistent with its makelsr program. So if I were to push, I'd need to push the results of a new makelsr run as well. Description: Fix line comments fo

Re: Refactor get/set_property to take the item as first argument (issue 573670043 by d...@gnu.org)

On 2020/04/09 17:07:46, hanwenn wrote: > I'm curious about these optimizations. Can you say more? Properties are currently stored in alists. They can be stored in vectors instead. Give all grob properties a number, then have an array per grob type mapping this number to an index into an array.

Reimplement Scheme_hash_table using linear probing. (issue 559790043 by hanw...@gmail.com)

I don't see the point in reinventing the wheel. This functionality is provided both by Guile (where an improved implementation could be submitted) and C++'s STL. In addition, I don't think that it is used to a degree where it would significantly affect LilyPond's performance. Reworking this to a

Re: Fix line comments for new snippets (issue 549820043 by d...@gnu.org)

https://codereview.appspot.com/549820043/diff/565880043/scripts/auxiliar/makelsr.py File scripts/auxiliar/makelsr.py (right): https://codereview.appspot.com/549820043/diff/565880043/scripts/auxiliar/makelsr.py#newcode38 scripts/auxiliar/makelsr.py:38: new_lys_marker = "%% generated from %s" % ne

Re: Reimplement Scheme_hash_table using linear probing. (issue 559790043 by hanw...@gmail.com)

https://codereview.appspot.com/559790043/diff/563830043/input/regression/scheme-unit-test.ly#newcode6 > input/regression/scheme-unit-test.ly:6: #(ly:test-scheme-hash-table) > On 2020/04/10 21:43:28, dak wrote: > > This seems like a rather opaque way of testing functionality. > &g

Re: Reimplement Scheme_hash_table using linear probing. (issue 559790043 by hanw...@gmail.com)

On 2020/04/11 11:36:16, hanwenn wrote: > On Sat, Apr 11, 2020 at 1:05 PM wrote: > > > > On 2020/04/11 05:37:39, hanwenn wrote: > > > > In addition, I don't think that it is used to a degree where it > > would > > > significantly affect LilyPond's performance. > >

  1   2   3   4   5   6   7   8   9   10   >