Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
"Phil Holmes" writes: > - Original Message ----- > From: "David Kastrup" > To: "Phil Holmes" > Cc: "John Mandereau" ; "Lily devel" > > Sent: Wednesday, March 20, 2019 7:09 PM > Subject: Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB > with stable/2.20 branch] > > >> >> On typical UNIX-like systems these days, a user account beowulf has both >> a user id of beowulf and a group id of beowulf. This is not a necessity >> as much as a convention making some permission management easier. >> Typical utilities creating accounts follow that permission. It seems >> like on your system, the user "lilypond" (assuming it exists) does not >> have an accompanying group "lilypond". > > > I don't even have a username "lilypond". Don't think the VM I used to > use does either. I would be surprised if it didn't. > Not sure why it wants to change group to a non-existent entity. Does > it copy the permissions (and memberships) to the remote server? Depends on what commands are used for copying. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
"Phil Holmes" writes: > - Original Message ----- > From: "David Kastrup" > To: "Phil Holmes" > Cc: "John Mandereau" ; "Lily devel" > > Sent: Wednesday, March 20, 2019 8:27 PM > Subject: Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB > with stable/2.20 branch] > > >> "Phil Holmes" writes: >> >>> - Original Message - >>> From: "David Kastrup" > >>> Not sure why it wants to change group to a non-existent entity. Does >>> it copy the permissions (and memberships) to the remote server? >> >> Depends on what commands are used for copying. > > > I believe GUB upload uses rsync. Then it depends on the options used. Some versions of rsync try to preserve group/owner. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
"Phil Holmes" writes: > - Original Message ----- > From: "David Kastrup" [...] >>> I believe GUB upload uses rsync. >> >> Then it depends on the options used. Some versions Oops. Some options >> of rsync try to preserve group/owner. > > It looks like the command is this from upload.py: > > cmds += ['rsync --delay-updates --progress %s %s' > > % tup for tup in src_dests] As long as those %s fields don't interpolate additional options, this would not appear to try transferring/preserving group ownership. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
Knut Petersen writes:
> On 21.03.19 12:04, Phil Holmes wrote:
>
>> Anyway - it would seem easiest just to create a 'lilypond' group.
>> Does that seem the best way forward?
>
> In rsync-lily-doc.py we have:
>
> system ('rsync --exclude "*.signature" --hard-links
> --delay-updates --delete --delete-after --stats --progress -pgorltvu
> -e ssh . %s/%s/' % (options.destination, branch_dir))
>
> In rsync-test.py we have:
>
> system ('rsync --hard-links --delay-updates --delete --delete-after
> --stats --progress -pgorltvu -e ssh . %s/%s/' % (options.destination,
> target))
>
> Group and ownership are preserved here. But "preserved" means that the
> numeric group / user id is preserved, not the literal name mapped to
> the GID/UID on the two systems.
Sure about that?
-o, --owner
This option causes rsync to set the owner of the
destination file to be the same as the source file, but
only if the receiving rsync is being run as the
super-user (see also the --super and --fake-super
options). Without this option, the owner of new and/or
transferred files are set to the invoking user on the
receiving side.
The preservation of ownership will associate matching
names by default, but may fall back to using the ID
number in somecircumstances (see also the
--numeric-ids option for a full discussion).
-g, --group
This option causes rsync to set the group of the
destination file to be the same as the source file. If
the receiving program is not running as the super-user
(or if --no-super was specified), only groups that the
invoking user on the receiving side is a member of will
be preserved. Without this option, the group is set to
the default group of the invoking user on the receiving
side.
The preservation of group information will associate
matching names by default, but may fall back to using
the ID number in some circumstances (see also the
--numeric-ids option for a full discussion).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guile - State of 2 / Release of 3
Thomas Morley writes: > Hi Jahrme, > > great you're interested in the topic. > I'll try to give you some feedback to your questions. > > ad 1. > > If you do on master > confirgure --enable-guile2 > and apply the attached patches (some are in master already, if in > doubt prefer what's in the source already) you'll get a working > lilypond. > Working means `make´, `make doc´ will succeed and it survives the > regtest with very minor issues, for guile-2.2.x and guile-2.9.1 > At least the last time I tested this. > > Disadvantges/issues are the slow-down. > Other issues are listed here: https://ao2.it/tmp/lilypond-guile2/TODO > Furthermore `procedure-source´ is disabled in guile-2, which is > problematic for us. I've grepped for it: I don't think that this should be an issue since it just involves some diagnostic output that could be disabled without loss of crucial functionality. > In general we have no method to deal with .go-files. Yup. That's important for installed versions of LilyPond. > And we're beaten by encoding-issues. That's a strong word: most stuff works but the principal problem is that Guile has no way to pass anything but Latin-1 strings through the Guile API without recoding, and LilyPond works in UTF-8. This is a major performance problem since LilyPond is coded in significant parts in C++ and passes large amounts of text in and out of Guile. > There's are likely more ... > > ad 2. > Though, the slow-down is still huge. I can't confirm a substantielly > speed up for guile-2.9.1 > > Over the years several people worked on the topic. > Speaking only for me, I think all low hanging fruits are done. And I > don't have the knowledge to go deeper :( > .go-files and encoding-thingies are the heaviest showstopper for now, > all way out of my depth. > > If you want to start the above listed issues are the current TODO-list. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problems with \cueDuring and events
Thomas Morley writes: > Am So., 14. Apr. 2019 um 12:05 Uhr schrieb Werner LEMBERG : > >> > I doubt there are events missing. I even tried [...] To no avail. >> > >> > So I tend to think it has to do how quotes are processed. [...] >> > Though, I'm at a loss how to get deeper. >> >> David K., can you help? > > As far as I understand, it's the partcombiner at work here. It is common infrastructure, recording-group-emulate I think (and likely in scm/part-combiner.scm). It only picks up a single bottom context, ignoring the rest. I am currently on my yearly climbing vacation in Italy. This does involve sampling of the local wine so I am not really in a condition to analyse this to any useful detail before hitting the bed. I'll try taking a look tomorrow but am doubtful that I have much more of a clue about it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stack smashing detected
Thomas Morley writes:
> Hi all,
>
> the following code
>
> \version "2.21.0"
> {
> \override Slur.control-points = #'((1 . 0) (2 . 3) (3 . 4) (4 . 3) (5 . 0))
> b1( b)
> }
>
> stored in metaspline-tests-01.ly, returns:
>
> GNU LilyPond 2.21.0
> Processing `metaspline-tests-01.ly'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...*** stack smashing detected ***: terminated
> Aborted (core dumped)
>
> Obviously more control-points than usual are provided.
> Though I've never seen such a message.
> Any insights?
> gdb-output attached.
>
>
> Background: I'm exploring whether it would be feasable to draw higher
> order bezier-curves, splitting them in cubic ones.
That's not overly useful: higher order bezier curves are higher-order
polynomials and tend to have quite less affinity to their control points
than cubic beziers have. When splicing them together, the boundary
conditions prescribe more continuous derivatives than human drawing
would care for. So usually your goals would be better served by
allowing _multiple_ cubic beziers in a row with suitable continuity of
derivatives (and thus some aspects of the control points) provided
automagically. Metafont is an ingenious engine for specifying this sort
of thing, so studying it is likely a good idea.
I have an old copy of the Metafont Book flying around here that I
haven't touched in years. I could send it to you if you want to get
ideas. It's better than some PDF on a computer and, well, legal too.
With regard to the stack smashing: that indeed looks awful. I'll take a
look at it.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stack smashing detected
Benkő Pál writes: > David Kastrup ezt írta (időpont: 2019. ápr. 25., Cs, 16:46): >> >> Thomas Morley writes: >> >> > Background: I'm exploring whether it would be feasible to draw higher >> > order bezier-curves, splitting them in cubic ones. > > you can't split a Bezier curve into lower order ones, only approximate. > >> So usually your goals would be better served by >> allowing _multiple_ cubic beziers in a row with suitable continuity of >> derivatives (and thus some aspects of the control points) provided >> automagically. > > which is called B-splines. is it possible to use (cubic) B-splines directly? What's "directly"? Where you can use multiple splines with control points, by suitably calculating the control points, you can of course use B-splines. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stack smashing detected
Thomas Morley writes: > ' > > Am Do., 25. Apr. 2019 um 17:21 Uhr schrieb Benkő Pál : >> >> David Kastrup ezt írta (időpont: 2019. ápr. 25., Cs, 16:46): >> > >> > Thomas Morley writes: >> > >> > > Background: I'm exploring whether it would be feasible to draw higher >> > > order bezier-curves, splitting them in cubic ones. >> >> you can't split a Bezier curve into lower order ones, only approximate. > > Bad wording of mine, sorry. > I meant 'approximate'. > >> > So usually your goals would be better served by >> > allowing _multiple_ cubic beziers in a row with suitable continuity of >> > derivatives (and thus some aspects of the control points) provided >> > automagically. >> >> which is called B-splines. is it possible to use (cubic) B-splines directly? > > B-splines are also mentioned in one of the linked sources, but > currently can't deal with them. I'll continue exploring ;) It just means that you draw a number of Bezier curves through a number of curve points maintaining as many continuous derivatives as your Bezier degree can deliver per point and then filling the remaining degrees of freedom at the end points with suitable boundary conditions. Typical choices are "periodic", namely keeping all derivatives at the end the same as at the start, or "natural", making the final derivatives zero. I may have some Bezier curve booklet as well but it's likely with examples in BASIC and not necessarily all the math is correct. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid some crashes for bad "control-points" property (issue 576610043 by d...@gnu.org)
thomasmorle...@gmail.com writes: > As always, I can't review C++. > > So let me ask, how will LilyPond react seeing 5 or more control-points > after your patch? > > https://codereview.appspot.com/576610043/ It just ignores additional control points and replaces missing ones with (0 . 0). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Appearance of S-curves
Simon Albrecht writes: > Hi, > > I find the second one with crossing beziers mich more pleasant, but > I'm sure the question is easily settled by looking at any good > hand-engraved example (I'm travelling right now and don't have any at > hand, sorry). I think the usual hand-engraved version would be done with an oval stencil so the curve should be thinner in the middle for the particular case of a symmetric steep S. Bezier sandwiches are a reasonably working approximation of this kind of turning action for single-segment slurs. I am not sure that multi-segment slurs map as well to them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid some crashes for bad "control-points" property (issue 576610043 by d...@gnu.org)
hanw...@gmail.com writes: > add a regression test? > > https://codereview.appspot.com/576610043/ I am not sure what the point of it would be. This kind of bug may be present elsewhere (and the regression test would not cover that) and it is not likely to get reintroduced here since this code does not really interact with other code. And if you try running the test on older versions for comparison, it will just crash. The visual output is meaningless since the condition it protects against does not have meaning. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add articulation support to multi measure rests (issue 562710043 by lilyp...@maltemeyn.de)
Dan Eble writes: > On Apr 27, 2019, at 04:54, d...@gnu.org wrote: >> >> Multimeasure rests can be split into multiple rests and across lines. >> That's what makes then a Spanner rather than an Item and is the main >> cause of this complication. How are you dealing with such a split? A >> fermata only makes sense on the last such rest, most text markups make >> sense only on the first such rest. > > See Malte’s answer when I raised the same concern: > http://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00087.html > <http://lists.gnu.org/archive/html/lilypond-devel/2019-04/msg00087.html> > > It’s a bit long to quote, but his major premise is that \fermata on a > compressed multimeasure rest is ambiguous to the point of being > useless. But we are talking about a \fermata on an _uncompressed_ multimeasure rest here. If the compression leaves just a single rest, placing the fermata does not pose a conundrum to typesetting (it may pose one to the musician but that's entirely the composer's choice and fault). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid some crashes for bad "control-points" property (issue 576610043 by d...@gnu.org)
hanw...@gmail.com writes: > On 2019/04/26 18:49:03, dak wrote: >> mailto:hanw...@gmail.com writes: > >> > add a regression test? >> > >> > https://codereview.appspot.com/576610043/ > >> I am not sure what the point of it would be. This kind of bug may be >> present elsewhere (and the regression test would not cover that) and > it >> is not likely to get reintroduced here since this code does not really >> interact with other code. And if you try running the test on older >> versions for comparison, it will just crash. The visual output is >> meaningless since the condition it protects against does not have >> meaning. > > After many years of developing software, I'm skeptic of any bugfix > without test, but yes, maybe it's overkill in this case? In any case, I > think there is a case in slur-configuration.cc too You are right, and I'll have to fix that. Seems my grep-fu is lacklustre. But a regression test would not have found it. This kind of bug seems more amenable to review. Regression tests would protect against badly resolved merge conflicts reintroducing old code, of course, but our workflow does not really make them probable: there are just too few people working on too few things. I mean, feel free to propose a regtest. > https://codereview.appspot.com/576610043/ -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add fermata markup commands (issue 344160043 by lilyp...@maltemeyn.de)
lilyp...@maltemeyn.de writes: > On 2019/04/29 20:15:30, lemzwerg wrote: >> I wonder whether it makes sense to use more camel case for the macro > names, this >> is, \shortFermata, \longFermata, etc. > > Hm … that would need new names also for other scripts like \reverseTurn, > \halfOpen and probably many others like \prallMordent, \prallPrall, > \upMordent, \snapPizzicato, \signumCongruentiae. > > What happened to GLISS? camelCase vs. lowercase and others is mentioned > in section 14.7 of the CG … > > https://codereview.appspot.com/344160043/ GLISS has fallen a bit by the wayside: as I understand it, it was to a good degree an endeavor driven by non-programmers (at least not core programmers) to get focused proposals for better human interfaces for LilyPond that programmers then can tackle. The composition of core programmers and users and the balance of things being hardwired into LilyPond (where simple changes required a core programmer) and things being programmable at an advanced user level as long as they met certain limitations has significantly shifted since then, and so have the discussion and decision and code making processes. Like with many slow-moving changes, not everything that was a good idea remains as desirable as it once was and as the way to do things changes, the set of people enjoying doing them also changes, partly because of a change in the actual matter at hand, partly because of changes in the community doing them. Whether you want to call it GLISS or not, consistency in interfaces does make some sense but it usually is a good idea to work on those mostly when there is a comparatively fresh stable branch out. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
marnen writes: > My understanding from other posts here (correct me if I'm wrong) is > that a major (legal, not technical) roadblock for doing this with GUB > is the licensing requirement that seems to require that Xcode be run > on Apple hardware, and the lack of consistent availability of Apple > hardware for builds. The GPL 3.0 does not allow additional restrictions such as requiring certain hardware. Availability is not an issue, the restrictions are. > If that's so, then I have a suggestion that doesn't seem to have been > made at least on this list so far. Travis CI provides a cloud-based > Mac build environment (see > https://docs.travis-ci.com/user/reference/osx/ for specifics), and > like all of Travis's services, this is available free of charge to > open-source projects. If we can get GUB or something else suitable to > run on Travis's Mac build environment (which seems likely), then our > Mac build issue should be solved, right? This is not a problem of abilities but of permissions. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Marnen Laibow-Koser writes: > On Thu, May 16, 2019 at 5:01 PM David Kastrup wrote: > >> marnen writes: >> >> > My understanding from other posts here (correct me if I'm wrong) is >> > that a major (legal, not technical) roadblock for doing this with GUB >> > is the licensing requirement that seems to require that Xcode be run >> > on Apple hardware, and the lack of consistent availability of Apple >> > hardware for builds. >> >> The GPL 3.0 does not allow additional restrictions such as requiring >> certain hardware. Availability is not an issue, the restrictions are. >> > [...] > > Xcode is not governed by GPL3, and AFAIK it's the only component at issue > here whose license stipulates particular hardware. GUB is governed by the GPLv3. Nobody claims that people may not independently create ports of LilyPond for MacOSX but creating them as part of GUB in the general release process is not an option with the current Xcode license. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Jahrme Risner writes: > Hello Marnen, > >> My understanding from other posts here (correct me if I'm wrong) is >> that a major (legal, not technical) roadblock for doing this with GUB >> is the licensing requirement that seems to require that Xcode be run >> on Apple hardware, and the lack of consistent availability of Apple >> hardware for builds. > > In my opinion, the largest issue here is that any *developers* working > to fix/improve/modify LilyPond who do not *personally* have access to > Apple hardware cannot test how their change will affect Darwin. No, it means that is prohibited by Apple to use Xcode for compiling LilyPond with GUB on non-Apple hardware. This is a restriction incompatible with the GPLv3 license GUB is under, so current Xcode versions cannot be made a part of GUB. It does not preclude someone else compiling LilyPond with Xcode under whatever native platform they want, but it means that MacOSX compilation cannot be integrated into GUB and consequently our release process using the current Xcode SDK. > With every other system a developer could create a VM to test build > results (even Windows, though a license would be required) but not so > with Darwin. We build our Windows binaries with GUB and upload them essentially untested. That may seem surprising, but once stuff makes it through GUB, it is quite rare that it is inoperative to any significant degree. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Marnen Laibow-Koser writes: > On Thu, May 16, 2019 at 6:22 PM David Kastrup wrote: > >> Marnen Laibow-Koser writes: >> >> > On Thu, May 16, 2019 at 5:01 PM David Kastrup wrote: >> > >> >> marnen writes: >> >> >> >> > My understanding from other posts here (correct me if I'm wrong) is >> >> > that a major (legal, not technical) roadblock for doing this with GUB >> >> > is the licensing requirement that seems to require that Xcode be run >> >> > on Apple hardware, and the lack of consistent availability of Apple >> >> > hardware for builds. >> >> >> >> The GPL 3.0 does not allow additional restrictions such as requiring >> >> certain hardware. Availability is not an issue, the restrictions are. >> >> >> > [...] >> > >> > Xcode is not governed by GPL3, and AFAIK it's the only component at issue >> > here whose license stipulates particular hardware. >> >> GUB is governed by the GPLv3. Nobody claims that people may not >> independently create ports of LilyPond for MacOSX but creating them as >> part of GUB in the general release process is not an option with the >> current Xcode license. > > Perhaps I don’t understand. If GUB merely calls out to Xcode, how is this > a GPL3 issue? You would not be allowed to execute GUB on non-MacOSX hardware if using Xcode were an integral part of its operation, and this kind of restriction is not allowed by the GPLv3. How do you even imagine we could use Xcode on non-Mac hardware in the course of the release process? Apple demands native compilation when using Xcode, and our release process does not run on Apple hardware. It's not like Jan as the author of GUB is out of the world and could be asked to license GUB in a manner where restraining its use to Apple hardware would be possible. But I will not do so as LilyPond maintainer, and pressing for that kind of proprietary release process is outside of the resources the GNU project lends to LilyPond as GNU software. If Apple does not want software to be crosscompiled to MacOSX, that is their privilege. If you want to find a way around it, the way would likely be using some Darwin-only SDK. We won't likely be able to include a GUI editor or GUI based install and it might impact some font inclusion details, but for the MacOSX GUI Apple clearly barrs us from using their current Xcode SDK in the release process using crosscompilation on GUB. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Carl Sorensen writes: > I'm pretty sure there are no Mac build instructions for Lilypond. > > The Linux build instructions are in the Contributor's Guide. > > GUB is a Linux build environment. The CG does not contain GUB building instructions I think, just native ones. LilyPond uses autoconf (and its own stepmake on top) and thus building on MacOSX natively is not significantly different from building on Linux natively. Hunting dependencies might be less fun, of course. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What version of guile to build 2.21.0
Urs Liska writes: > Am 18.05.19 um 05:53 schrieb Carl Sorensen: >> 1.8 > > > It's actually 1.8.8 IIRC Plus patches on top to make it compile. There is a branch in the Guile repository that does that, even though no tarballed release. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Undocumented "ambitusAfter"
Thomas Morley writes: > Am Sa., 18. Mai 2019 um 11:09 Uhr schrieb Malte Meyn : > >> Am 10.05.19 um 22:42 schrieb Thomas Morley: >> > Malte, do you've time to add a doc-string? >> >> I didn’t realize that the doc-string is used for documentation >> generation also for music functions. Thanks for the hint! > > Not sure how `make doc´ does things. > But while working on #5518 I generated IR by doing > lilypond generate-documentation.ly > This returns a file internals.texi > Then > texi2html internals.texi > returning > internals.html > > A plethora of warnings are displayed, though it's a _lot_ faster > compared to `make doc´, even if restricted to build IR only. > > Actually, music-functions are not printed in internals.html. > Though, obviously they are processed. > Probably one could have them integrated in IR, if wished, but I didn't > research in this direction. They are in an appendix of NR. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New grob-stencil needs to look at Beam-dimensions
Thomas Morley writes: > Hi, > > currently I continue my work to create a Slash-grob for automatic slashed > Beams. > The Slash-stencil needs to know Beam-properties (X-positions, > positions) to be adjusted. If I call those beam-properties directly > the Beam collopses, because this call is done before the Beam is > ready. > But if I wrap the Slash-stencil in another procedure like > (define slash-stil (lambda (grob) (lambda (grob) ...))) > all works. > > Questions: > - Why does it work? (it seems the outer procedure is called > before-line-breaking, the inner after-line-breaking) > - Is this something I can rely on (I'm thinking of patch) or am I > doing bug-using? Depends on whether someone asks for your stencil prematurely. We have a lot of those implicit dependencies though. > - Is there a better/different method? An unpure/pure container has somewhat more defined semantics when its respective callbacks are exercised. But if it works without, go for it. If it doesn't and the Beam uses unpure-pure-containers, you can also use an unpure-pure-container and work with ly:pure-call and ly:unpure-call in your respective callbacks: those work even when the definition of Beam changes significantly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New grob-stencil needs to look at Beam-dimensions
Thomas Morley writes: > Beam uses `grob::unpure-vertical-skylines-from-stencil´ for > vertical-skylines. I plan to use > `grob::always-vertical-skylines-from-stencil´ there for Slash. > Though, as far as I know this has no direct impact on the used stencil > procedure. Not on the used stencil procedure but possibly on when it or its pure/unpure parts (and/or how often) may get called. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Inconsistent beam-slope?
Thomas Morley writes:
> while working on automated slashed Beams, I noticed my
> stencil-procedure was always inexact for non-horizontal Beams. I
> looked at 'X-positions and 'positions of a Beam to get it's slope and
> derived the slope from those values.
>
> But the visible gradient obviously relies on blot-diameter as well.
> Look at the attached image (code for it below). There you can always
> see three overlayed Beams with blot-diameters: 0, 0.5 and 1
> For _identical_ 'positions the _visible_ slope is not the same. And
> I've got the impression the difference increases with steeped
> beam-slope.
>
> Is this intended or a bug?
>
> Thanks,
> Harm
>
> Here the used code:
>
> {
> \override Beam.stencil =
> #(lambda (grob)
>(let* ((layout (ly:grob-layout grob)))
> (ly:stencil-add
>(begin
> (ly:output-def-set-variable! layout 'blot-diameter 1)
> (stencil-with-color (ly:beam::print grob) black))
>(begin
> (ly:output-def-set-variable! layout 'blot-diameter 0.5)
> (stencil-with-color (ly:beam::print grob) red))
>(begin
> (ly:output-def-set-variable! layout 'blot-diameter 0)
> (stencil-with-color (ly:beam::print grob) cyan)
>
>
> \override Beam.positions = #'(2 . 8)
> b8^[ b]
> \override Beam.positions = #'(2 . 7)
> b8^[ b]
> \override Beam.positions = #'(2 . 6)
> b8^[ b]
> \override Beam.positions = #'(2 . 5)
> b8^[ b]
> \override Beam.positions = #'(2 . 4)
> b8^[ b]
> \override Beam.positions = #'(2 . 3)
> b8^[ b]
> \override Beam.positions = #'(2 . 2)
> b8^[ b]
> }
You talk about beam slope a lot but instead specify beam positions.
I get the impression that those positions are heeded pretty well, so
I don't see fit to label this as a bug. What would you think qualifies
as problematic here?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Inconsistent beam-slope?
Thomas Morley writes:
> Am Mi., 5. Juni 2019 um 23:56 Uhr schrieb David Kastrup :
>>
>> Thomas Morley writes:
>>
>> > while working on automated slashed Beams, I noticed my
>> > stencil-procedure was always inexact for non-horizontal Beams. I
>> > looked at 'X-positions and 'positions of a Beam to get it's slope and
>> > derived the slope from those values.
>> >
>> > But the visible gradient obviously relies on blot-diameter as well.
>> > Look at the attached image (code for it below). There you can always
>> > see three overlayed Beams with blot-diameters: 0, 0.5 and 1
>> > For _identical_ 'positions the _visible_ slope is not the same. And
>> > I've got the impression the difference increases with steeped
>> > beam-slope.
>> >
>> > Is this intended or a bug?
>> >
>> > Thanks,
>> > Harm
>> >
>> > Here the used code:
>> >
>> > {
>> > \override Beam.stencil =
>> > #(lambda (grob)
>> >(let* ((layout (ly:grob-layout grob)))
>> > (ly:stencil-add
>> >(begin
>> > (ly:output-def-set-variable! layout 'blot-diameter 1)
>> > (stencil-with-color (ly:beam::print grob) black))
>> >(begin
>> > (ly:output-def-set-variable! layout 'blot-diameter 0.5)
>> > (stencil-with-color (ly:beam::print grob) red))
>> >(begin
>> > (ly:output-def-set-variable! layout 'blot-diameter 0)
>> > (stencil-with-color (ly:beam::print grob) cyan)
>> >
>> >
>> > \override Beam.positions = #'(2 . 8)
>> > b8^[ b]
>> > \override Beam.positions = #'(2 . 7)
>> > b8^[ b]
>> > \override Beam.positions = #'(2 . 6)
>> > b8^[ b]
>> > \override Beam.positions = #'(2 . 5)
>> > b8^[ b]
>> > \override Beam.positions = #'(2 . 4)
>> > b8^[ b]
>> > \override Beam.positions = #'(2 . 3)
>> > b8^[ b]
>> > \override Beam.positions = #'(2 . 2)
>> > b8^[ b]
>> > }
>>
>> You talk about beam slope a lot but instead specify beam positions.
>> I get the impression that those positions are heeded pretty well, so
>> I don't see fit to label this as a bug. What would you think qualifies
>> as problematic here?
>
> I need to know the actual slope of a Beam.
> Probably too naive, but I thought I could go for (pseudocode):
> positions-delta / X-positions-delta
> If this is wrong, I have no good idea how to do it different.
>
> Any hints?
Subtract blot-diameter from X-positions-delta?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Inconsistent beam-slope?
Thomas Morley writes: > Am Do., 6. Juni 2019 um 00:10 Uhr schrieb David Kastrup : > >> > I need to know the actual slope of a Beam. >> > Probably too naive, but I thought I could go for (pseudocode): >> > positions-delta / X-positions-delta >> > If this is wrong, I have no good idea how to do it different. >> > >> > Any hints? >> >> Subtract blot-diameter from X-positions-delta? > > I'll give it a try and report back. It's possible that one needs to add the stem thickness back also. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4365: non-member is_smob<>(), is_derived_smob<>(), etc. (issue 231680043 by nine.fierce.ball...@gmail.com)
Dan Eble writes: > On Jun 5, 2019, at 09:33, d...@gnu.org wrote: >> >> The resulting comment text is nonsensical. That might have been a clue >> that the resulting behavior is not up to par, either. > > I took a new job last October and it doesn’t leave me with much energy > to dig into LilyPond issues. I hope that's good. I'll take a look about what to do here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB with local git-repo?
Thomas Morley writes: > Hi Phil, > > let's see, if I understand correctly: > > For a public branch, I'd checkout a local branch, say: dev/issue4943 > Then make it public with > git push origin dev/issue4943 > Further changes added to this branch with > git push dev/issue4943 HEAD:staging What? No, just continue with git push origin dev/issue4943 > Invoking GUB with > make LILYPOND_BRANCH=dev/issue4943 lilypond > > Though, I don't know how to delete said branch from the official repo, > after all work is done. git push origin :dev/issue4943 Basically, push an empty ref. Seems a bit strange that one can only work through the official repository. Can't you just clone a repository for which "origin" is your local repository rather than the official upstream? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB with local git-repo?
Federico Bruni writes: > Il giorno sab 8 giu 2019 alle 13:10, Phil Holmes > ha scritto: >> I think David is suggesting it's strange that GUB can only use the >> Savannah repo, not any git repo of your choice. TBH I'm not sure >> whether it's a configuration item or hard wired into the GUB code. >> For me, an even bigger problem is that GUB only does partial builds >> from master, not a branch of choise. > > I haven't tried building GUB for a while but I think you can override > the environment variables you see in lilypond.make, e.g.: > > LILYPOND_REPO_URL=http://my.personal.repo LILYPOND_BRANCH=issue20 make > lilypond Probably even LILYPOND_REPO_URL=file:///my/personal/repo ... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB with local git-repo?
Thomas Morley writes: > Am So., 9. Juni 2019 um 11:10 Uhr schrieb David Kastrup : >> >> Federico Bruni writes: >> >> > Il giorno sab 8 giu 2019 alle 13:10, Phil Holmes >> > ha scritto: >> >> I think David is suggesting it's strange that GUB can only use the >> >> Savannah repo, not any git repo of your choice. TBH I'm not sure >> >> whether it's a configuration item or hard wired into the GUB code. >> >> For me, an even bigger problem is that GUB only does partial builds >> >> from master, not a branch of choise. >> > >> > I haven't tried building GUB for a while but I think you can override >> > the environment variables you see in lilypond.make, e.g.: >> > >> > LILYPOND_REPO_URL=http://my.personal.repo LILYPOND_BRANCH=issue20 make >> > lilypond >> >> Probably even >> >> LILYPOND_REPO_URL=file:///my/personal/repo ... >> >> -- >> David Kastrup > > I tried > > ~/gub (master)$ make lilypond > LILYPOND_REPO_URL=file:///home/hermann/lilypond-git/ Probably the trailing slash? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB with local git-repo?
Thomas Morley writes: > Am Di., 11. Juni 2019 um 18:35 Uhr schrieb Thomas Morley > : >> >> Am Di., 11. Juni 2019 um 17:57 Uhr schrieb Thomas Morley >> : >> >> > Just for fun I then tried to go for >> > https://github.com/lilypond/lilypond >> > a repository once set up by Janek. >> > ~/gub (master)$ make >> > LILYPOND_REPO_URL=https://github.com/lilypond/lilypond.git lilypond >> > => >> [...] >> > make: *** [lilypond] Error 2 >> >> Probably I should have done: >> LILYPOND_REPO_URL=git://github.com/lilypond/lilypond.git >> Note the git:// instead of https:// >> At least it errors not immediately. I'll report later. > > Build failed because of > https://sourceforge.net/p/testlilyissues/issues/5526/ > which is fixed in master of our official repo. Unlikely. A missing \version statement in a file that isn't even present in the branch cannot do much harm. Or are we not talking about the stable/2.20 branch? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
pat...@gnu.org writes:
> 07:02:37 (UTC) Begin LilyPond compile, previous commit at
> 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> 07:02:40 Merged staging, now at: 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> 07:02:41 Success:./autogen.sh --noconfigure
> 07:02:57 Success:/tmp/lilypond-autobuild/configure
> --enable-checking
> 07:02:59 Success:nice make clean
> 07:06:51 *** FAILED BUILD ***
> nice make -j9 CPU_COUNT=9
> Previous good commit: 1272e45b49fb91fb5fd181b7d045a0ac4d662450
> Current broken commit: 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
> 07:06:51 *** FAILED STEP ***
> merge from staging
> Failed runner: nice make -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
> 07:06:51 Traceback (most recent call last):
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 528, in handle_staging
> self.build (issue_id=issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 316, in build
> issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: nice make -j9 CPU_COUNT=9
> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
The relevant line:
lilypond-book.py: error: file not found: turkish-makam-example.ly
Most likely this built on the committer's computer because this file was
locally present but not checked into the version control system.
I'll be backing that commit out of staging.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
David Kastrup writes:
> pat...@gnu.org writes:
>
>> 07:02:37 (UTC) Begin LilyPond compile, previous commit at
>> 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
>> 07:02:40 Merged staging, now at: 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
>> 07:02:41 Success:./autogen.sh --noconfigure
>> 07:02:57 Success:/tmp/lilypond-autobuild/configure
>> --enable-checking
>> 07:02:59 Success:nice make clean
>> 07:06:51 *** FAILED BUILD ***
>> nice make -j9 CPU_COUNT=9
>> Previous good commit: 1272e45b49fb91fb5fd181b7d045a0ac4d662450
>> Current broken commit: 52c98e2ec5f3ef2a24ee1a2d94dd09f8517a6f36
>> 07:06:51 *** FAILED STEP ***
>> merge from staging
>> Failed runner: nice make -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
>> 07:06:51 Traceback (most recent call last):
>> File
>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> line 528, in handle_staging
>> self.build (issue_id=issue_id)
>> File
>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> line 316, in build
>> issue_id)
>> File
>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> line 266, in runner
>> raise FailedCommand ("Failed runner: %s\nSee the log file %s" %
>> (command, this_logfilename))
>> FailedCommand: Failed runner: nice make -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make--j9-CPU_COUNT=9.txt
>
> The relevant line:
>
> lilypond-book.py: error: file not found: turkish-makam-example.ly
>
> Most likely this built on the committer's computer because this file was
> locally present but not checked into the version control system.
>
> I'll be backing that commit out of staging.
Did so. Though I am puzzled how the original commit had been able to
pass patchy testing when it had that problem. Is the pushed version
different than the tested one? If so, how did that happen?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
James writes: > David, > > Revert the commit if its easier. I'll figure it out this evening when > I get home. It's probably some oversight or a makelsr issue. > > Sorry. Ah, this was a third-party commit by you. The most frequent error here is to apply a provided patch with git apply xxx.patch instead of git apply --index xxx.patch (only the latter will add new files to the repository). However, given that there also is a large commit message with a significantly different AuthorDate than the CommitDate, it is more likely that this was applied and tested as a complete commit using git am ... So I don't really know. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Strange space between beam and slur
Lukas-Fabian Moser writes:
> Hi Andrew,
>
> Am 25.06.19 um 10:56 schrieb Andrew Bernard:
>> What is it about 19? Is it some magic borderline number in some unit
>> system in lilypond? Do we know?
>
> I'd rather suspect there's some kind of "anthropic principle" at work
> here: The bugs (at least the one I reported) should probably occur for
> any staff size in some (staff-size-dependent) situations, but we
> notice them with staff sizes that are used in real-world situations,
> hence our MWEs expose _those_ cases. But of course I lilypond-user
> Mailinglist might be wrong, especially for the
> misplaced-note-head problem which occurs for quite a generic
> situation.
>
> Anyway: The misplaced-note-head bug
> (https://sourceforge.net/p/testlilyissues/issues/5303/) first appeared
> in 2.19.16 (I just found out that it's convenient as well as quite
> easy to keep arbitrarily many LilyPond versions installed on the same
> account).
>
> @gcc experts (hence posting to devel also): Unfortunately, I cannot
> build 2.19.15 on my machine because of errors of the type:
>
> /home/lukas/git/lilypond/lily/include/smobs.tcc:98:25: error: invalid
> conversion from 'int' to 'scm_unused_struct* (*)(SCM, SCM) {aka
> scm_unused_struct* (*)(scm_unused_struct*, scm_unused_struct*)}'
> [-fpermissive]
> scm_set_smob_equalp (smob_tag_, Super::equal_p);
>
> I suspect that this is a case of some conversions having become
> illegal for later versions of gcc. Is there a cheap way to make the
> build succeed in order to be able to bisect for the
> misplaced-note-head bug?
I think I used a few cherry-picks commits for building. Embarrassingly,
it doesn't appear like I have them in a branch. They were a few C++
commits, a few Texinfo ones, some stuff related to freetype.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: misplaced-note-head bug (issue 5303)
Lukas-Fabian Moser writes:
> Folks,
>>
>> I think I isolated the rounding (?) issue leading to the misplaced
>> note head in https://sourceforge.net/p/testlilyissues/issues/5303/
>>
>> Please forgive the horrible C/C++ jumble - it's been quite long
>> since I did this kind of stuff and usually only ever wrote vanilla
>> C:
>>
>> #include
>>
>> double a = -0x1.7p+1;
>>
>> int main(void) {
>> printf("%a, as float: %f, as int: %d\n", a, a, int (a));
>> }
>
> Aah, I'm sorry - I was not aware that casting to int works by
> /truncating/. Then it's quite obvious what's happening here.
Which code do you think has a problem related to your example?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stable/2.20 might fail to build
Knut Petersen writes: > Hi everybody! > > During building stable/ 2.20 we have to build the Portuguese > website. As we have no txi-pt.tex in the tex/ directory that will > fail if there is no installation of texinfo on the host system. > > Before I write a patch: Could someone please explain to me why > we use txi-*.tex files stored in /tex instead of the build system's > files? Frequent significant divergence from upstream Texinfo? I think we had several Texinfo language supports and features before Texinfo proper had them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: misplaced-note-head bug (issue 5303)
"Phil Holmes" writes: > - Original Message - > From: "Lukas-Fabian Moser" >> >> Questions: >> >> a) How to decide which fix is "better"? (My guess that using floats >> might pose the danger of rounding errors adding up until something bad >> happens - probably only for huge chords comprising hundreds of notes, >> but I'd tend to favor the solution with rounding.) > > > I would think that rounding the int and keeping lastpos as an integer > would be less invasive and I would do that. It would be less invasive, the question is what the right thing would be. Anybody have an idea whether non-integer positions can sensibly be employed here for, say, chromatic notation systems having three positions per staff-line? Or is that all integer in that case? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: misplaced-note-head bug (issue 5303)
Lukas-Fabian Moser writes: > To me, this would seem to suggest that the "less invasive" bugfix I > proposed (by rounding) would in fact preserve the incompleteness in > the move from int to float calculations that Han-Wen probably > introduced by accident (unless (*) is motivated in a way I do not > understand). This would seem to me to suggest that (*) should be > replaced by a straight "lastpos = p;". Agreed. > It all comes down to the question I can't answer due to lack of > knowledge about the internal workings: What's the rationale for the > claim that dy can only be integer or .5? I think short of rewriting everything to use integers again, removing the int cast seems like the fix more in line with what the code is currently written to do/be. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: macOS 64-bit
Karlin High writes: > On 7/8/2019 8:30 AM, Marnen Laibow-Koser wrote: >> I’ve also been reading about osxcross, which looks like it *might* >> do 64-bit builds now, though I can’t be sure from the available >> info. > > <https://github.com/tpoechtrager/osxcross#packaging-the-sdk> > "Please ensure you have read and understood the Xcode license terms > before continuing." > > Anything that says "Download XCode, dissect like so, copy this one > piece to your Linux system somewhere..." is likely a violation of > Apple's XCode Software License Agreement. > > UNLESS the Linux is running in a Virtual Machine on Apple hardware. > > Which MacStadium apparently can provide, with Mac Mini rental > computers. (aka "in the cloud.") > > If this effort was completed, it sounds to me like non-Mac builds > could continue as normal. Then MacStadium gets used to produce the Mac > builds. Automation would be possible, with Travis or Cirrus. (About > which I know nothing but the names.) > > My question here is, will this arrangement be satisfactory for the > people running the LilyPond build system? Phil Holmes? Anyone? What does this have to do with the people running the build system? It's a different setup on different hardware. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some cherry-picks for stable/2.20
Knut Petersen writes: > Hi everybody > > I think some commits in master should be cherry-picked for stable/2.20: > >git cherry-pick -x \ >6e98e7e7b0d0ac46ba7e54f4b3946228f44fc414 \ >9fb52ef2c93588192842fffa1b115c6f2d360321 \ >f76997b5097f588060f823c4c87f01bac9f2fe50 \ >b0300944e015b5957e50441224699e55c68c3dc3 \ >a64b4dbc92ac0bbece08043349a55dccd84f4fd7 > > > Reason: Our regression test code was broken in master and > still is broken in stable/2.20. We need the fix in issue 5467, > these are the last three of the five recommended commits. > The last three commits change scm/framework-ps.scm and > scripts/build/output-distance.py, if we also cherry-pick the > first two commits we update scm/framework-ps.scm and > scripts/build/output-distance.py to be identical to the code > in master. There's no reason not to do so: The first commit > fixes pdf metadata generation, the 2nd improves debugging > output during executino of output-distance.py. Done. I need to get back on the 2.20 track by picking a few other fixes from master. Currently it feels like 2.20 is slipping from releasable state rather than moving towards it. I'm very bad at concentrating right now which doesn't help. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build fix for stable 2.20 on openSuSE Tumbleweed
Knut Petersen writes: > Hi everybody! > >> Attached is bc4f5fdc299 of master ported to stable/2.20. >> Cherry picking did not work as the aclocal.m4 files diverged to much. > Please do not apply the patch attached to my previous message. > Instead I recommend to update aclocal.m4 to the code used in master. > >git cherry-pick -x \ >58f25aaf939fc4e00618f7178da9095dfeed00d7 \ >fd4ec3ef3d9150ff13b54125aa902671c6da4106 \ >59bf9a378d5d1e3b6bbd21f76f2c5019b64dae8f \ >0e1eeb7838eec11220858d4d9e541d20f948a794 \ >bc4f5fdc299ff21d0ee2de4462af30b22e1321c1 > I picked those; I am not really into the current compilation problems I am afraid. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Additional cherry-pick for stable/2.20
Knut Petersen writes: > Hi everybody > > In master we have txi-ja.tex listed in the 'copied_files' array > in scripts/build/grand-replace.py. > > We also have txi-ja.tex in stable/2.20 and have to list it in > 'copied-files' too, so please > >git cherry-pick -x commit 2a4dfab3dbeb3412fda4f3e35a879a55fe8fd3c0. Done. Thanks for your diligence and patience. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with predefined-guitar-fretboards.ly?
James writes:
> Hello,
>
> I saw arecent update by a LP user to an 'already-fixed' tracker
>
> <https://sourceforge.net/p/testlilyissues/issues/3290/>
>
> That made it into my inbox thus:
>
> On 06/07/2019 21:54, Christopher Heckman wrote:
>> It's isn't just the website; the boards for augmented and diminished
>> chords are calculated incorrectly.
>>
>> \include "predefined-guitar-fretboards.ly"
>> \new FretBoards \chordmode { b:dim f:aug aes:aug g:dim }
>>
>> The F aug chord is incorrect; it actually shows a G augmented
>> chord.
>> In all four cases, the numbers at the bottom do not match up with the
>> diagram. The B dim number should be 2343, the A flat aug 032110, and
>> G dim should be 3131.
This is just a misunderstanding of the numbers: they are not fret
numbers but fingering numbers. It is a bit unusual that they are
present by default: typically players are expected to figure them out on
their own, and sometimes they are just inscribed in the dots.
f:aug is clearly wrong, aes:aug has the right notes but the root note is
awkward, not being the lowest. I have no idea how guitarists would feel
about that.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with predefined-guitar-fretboards.ly?
Wols Lists writes: > On 17/07/19 13:55, David Kastrup wrote: >> f:aug is clearly wrong, aes:aug has the right notes but the root note is >> awkward, not being the lowest. I have no idea how guitarists would feel >> about that. > > As a classical guitarist, I think there is a notation for "don't use > this string" (for example, the chord of C uses strings 1-5, but 6 is an > E so that's okay). Uh, playing that E as part of a chord sounds awful. In alternate bass picking, you'd usually put a G on the E string. > But provided the bottom string is part of the chord, it doesn't really > matter. After all, chords are quite often inverted in other music too, > no? An inversion is an inversion. Guitar chords tend to be comparatively nonchalant about them except for the root note, and that's what we are talking about here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem with predefined-guitar-fretboards.ly?
Wols Lists writes: > On 18/07/19 15:42, David Kastrup wrote: >>> But provided the bottom string is part of the chord, it doesn't really >>> > matter. After all, chords are quite often inverted in other music too, >>> > no? > >> An inversion is an inversion. Guitar chords tend to be comparatively >> nonchalant about them except for the root note, and that's what we are >> talking about here. > > Isn't the whole point of an inversion that the root isn't at the bottom? > At least that's what I remember from my music theory. Well, it's more a matter of "voicing" than of "inversion" with a guitar since mapping chords to notes is different on a fretboard instrument than on a keyboard instrument (I don't want to discuss clavichords here). > So a C-chord using all six strings is a first inversion - the 3rd of > the chord is at the bottom. Which probably does sound not too good on > its own ... It actually sounds awful. The lowest note sort-of determines what you'd call the equivalent of an inversion on a guitar. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub / Windows Subsystem for Linux
Knut Petersen writes: > Hi everybody! > > Has anybody tried to use GUB in the WSL environment? I am not sure this is a useful target when virtual Linux systems are reasonably accessible. If I remember correctly (but I am rather fuzzy here, so verification would be sensible), Microsoft stuck with GPLv2 versions of most programs, meaning that the bootstrap environment may be rather dated. Of course, that would be beneficial for diagnosing bootstrapping mishaps like the system Python use you figured out, but I am not sure that this is otherwise fun. For example, I think that current g++ versions are written in C++ rather than C, making for quite different bootstrap requisites. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Colored box behind a single note
Werner LEMBERG writes:
> [Moving the discussion to lilypond-devel.]
>
>>> A loop?
>
> Attached a new version of the patch, now using a loop.
>
>
> Werner
>
> diff --git a/lily/horizontal-bracket-engraver.cc
> b/lily/horizontal-bracket-engraver.cc
> index 608af35965..a42268a357 100644
> --- a/lily/horizontal-bracket-engraver.cc
> +++ b/lily/horizontal-bracket-engraver.cc
> @@ -56,10 +56,23 @@ Horizontal_bracket_engraver::listen_note_grouping
> (Stream_event *ev)
> {
>Direction d = to_dir (ev->get_property ("span-direction"));
>
> + // Allow one single-moment bracket. Abbreviating a horizontal bracket's
> + // `START' span-direction with `L' and `STOP' with `R', this means that we
> + // can have
> + //
> + // LLL...LLR
> + //
> + // or
> + //
> + // LRRR...RR
> + //
> + // events attached to a single moment (we don't take care of the order of
> + // `L' and `R' events).
> +
>if (d == STOP)
> {
>pop_count_++;
> - if (pop_count_ > bracket_stack_.size ())
> + if (pop_count_ > bracket_stack_.size () + 1)
> ev->origin ()->warning (_ ("do not have that many brackets"));
> }
>else
> @@ -68,22 +81,33 @@ Horizontal_bracket_engraver::listen_note_grouping
> (Stream_event *ev)
>events_.push_back (ev);
> }
>
> - if (pop_count_ && push_count_)
> + if (pop_count_ >= 2 && push_count_ >= 2)
> ev->origin ()->warning (_ ("conflicting note group events"));
> }
Those number changes do not appear like reflecting some design but
rather like poking the code until the wanted construct happens not to
cause warnings or errors. Why increase push/pop counts by 2 when
admitting one more level? Why allow popping exactly 1 more than
pushing?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
pat...@gnu.org writes:
> 14:39:40 (UTC) Begin LilyPond compile, previous commit at
> 1c51a616e289fffb918942c8f1e189ab50809157
> 14:39:51 Merged staging, now at: 1c51a616e289fffb918942c8f1e189ab50809157
> 14:39:52 Success:./autogen.sh --noconfigure
> 14:40:08 Success:/tmp/lilypond-autobuild/configure
> --enable-checking
> 14:40:11 Success:nice make clean
> 14:44:20 Success:nice make -j9 CPU_COUNT=9
> 14:47:28 *** FAILED BUILD ***
> nice make test -j9 CPU_COUNT=9
> Previous good commit: 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
> Current broken commit: 1c51a616e289fffb918942c8f1e189ab50809157
> 14:47:28 *** FAILED STEP ***
> merge from staging
> Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
> 14:47:28 Traceback (most recent call last):
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 528, in handle_staging
> self.build (issue_id=issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 328, in build
> issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
Error log contains the message:
if test -d /tmp/lilypond-autobuild/.git ; then \
cd /tmp/lilypond-autobuild ; \
BR=`LANG=c git branch | grep "^\*" | sed -e "s|^* *||"` ; \
HD=`git rev-parse --verify HEAD` ; \
FP=`git merge-base --octopus master HEAD` ; \
echo "BRANCH: $BR" ; \
echo " HEAD: $HD" ; \
if [ ! -z $FP ]; then \
echo "MERGE_BASE: $FP" ; \
echo -e '\n HISTORY:\n \n' ; \
git log --pretty=format:" HASH: %H%n SUBJECT: %s%n"
$FP~1..HEAD ; \
else \
echo "MERGE_BASE: unknown" ; \
echo -e '\n HISTORY:\n \n' ; \
git log --max-count=10 --pretty=format:" HASH:
%H%nSUBJECT: %s%n" ; \
fi ; \
echo "" ; \
fi > ./out-test/tree.gittxt
fatal: Not a valid object name master
Apparently, the patch from
commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
Author: Knut Petersen
Date: Sun Jul 7 13:16:05 2019 +0200
Optimize tree.gittxt messages
We display BRANCH, HEAD, MERGE-POINT
and HISTORY fom merge-point to HEAD.
If we do not find a merge-point we
display the last ten commits if this
is possible.
relies on the existence of a local (rather than upstream) branch
"master", not a good idea. I am backing out this commit from staging:
it needs to get fixed.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
David Kastrup writes:
> pat...@gnu.org writes:
>
>> 14:39:40 (UTC) Begin LilyPond compile, previous commit at
>> 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:39:51 Merged staging, now at: 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:39:52 Success:./autogen.sh --noconfigure
>> 14:40:08 Success:/tmp/lilypond-autobuild/configure
>> --enable-checking
>> 14:40:11 Success:nice make clean
>> 14:44:20 Success:nice make -j9 CPU_COUNT=9
>> 14:47:28 *** FAILED BUILD ***
>> nice make test -j9 CPU_COUNT=9
>> Previous good commit: 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
>> Current broken commit: 1c51a616e289fffb918942c8f1e189ab50809157
>> 14:47:28 *** FAILED STEP ***
>> merge from staging
>> Failed runner: nice make test -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>> 14:47:28 Traceback (most recent call last):
>> File
>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> line 528, in handle_staging
>> self.build (issue_id=issue_id)
>> File
>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> line 328, in build
>> issue_id)
>> File
>> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> line 266, in runner
>> raise FailedCommand ("Failed runner: %s\nSee the log file %s" %
>> (command, this_logfilename))
>> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
>> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>
> Error log contains the message:
>
> if test -d /tmp/lilypond-autobuild/.git ; then \
> cd /tmp/lilypond-autobuild ; \
> BR=`LANG=c git branch | grep "^\*" | sed -e "s|^* *||"` ; \
> HD=`git rev-parse --verify HEAD` ; \
> FP=`git merge-base --octopus master HEAD` ; \
> echo "BRANCH: $BR" ; \
> echo " HEAD: $HD" ; \
> if [ ! -z $FP ]; then \
> echo "MERGE_BASE: $FP" ; \
> echo -e '\n HISTORY:\n \n' ; \
> git log --pretty=format:" HASH: %H%n SUBJECT: %s%n"
> $FP~1..HEAD ; \
> else \
> echo "MERGE_BASE: unknown" ; \
> echo -e '\n HISTORY:\n \n' ; \
> git log --max-count=10 --pretty=format:" HASH:
> %H%nSUBJECT: %s%n" ; \
> fi ; \
> echo "" ; \
> fi > ./out-test/tree.gittxt
> fatal: Not a valid object name master
>
> Apparently, the patch from
> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
> Author: Knut Petersen
> Date: Sun Jul 7 13:16:05 2019 +0200
>
> Optimize tree.gittxt messages
>
> We display BRANCH, HEAD, MERGE-POINT
> and HISTORY fom merge-point to HEAD.
>
> If we do not find a merge-point we
> display the last ten commits if this
> is possible.
>
> relies on the existence of a local (rather than upstream) branch
> "master", not a good idea. I am backing out this commit from staging:
> it needs to get fixed.
Someone or some patchy happening to have a local master branch (a bad
idea since absolutely no development should happen in a local master
branch in our setup) already pushed that commit to staging.
Consequentially, I had to push a revert to staging and hope I'll get it
through without manually tampering with master.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
David Kastrup writes: > David Kastrup writes: > >> fatal: Not a valid object name master >> >> Apparently, the patch from >> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95 >> Author: Knut Petersen >> Date: Sun Jul 7 13:16:05 2019 +0200 >> >> Optimize tree.gittxt messages >> >> We display BRANCH, HEAD, MERGE-POINT >> and HISTORY fom merge-point to HEAD. >> >> If we do not find a merge-point we >> display the last ten commits if this >> is possible. >> >> relies on the existence of a local (rather than upstream) branch >> "master", not a good idea. I am backing out this commit from staging: >> it needs to get fixed. > > Someone or some patchy happening to have a local master branch (a bad > idea since absolutely no development should happen in a local master > branch in our setup) already pushed that commit to staging. I mean, to master. Pushing to staging was very much the correct step to take in the life of the patch. > Consequentially, I had to push a revert to staging and hope I'll get it > through without manually tampering with master. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
pat...@gnu.org writes:
> 15:04:59 (UTC) Begin LilyPond compile, previous commit at
> 95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:05:03 Merged staging, now at: 95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:05:03 Success:./autogen.sh --noconfigure
> 15:05:19 Success:/tmp/lilypond-autobuild/configure
> --enable-checking
> 15:05:22 Success:nice make clean
> 15:09:28 Success:nice make -j9 CPU_COUNT=9
> 15:12:41 *** FAILED BUILD ***
> nice make test -j9 CPU_COUNT=9
> Previous good commit: 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95
> Current broken commit: 95a26f04acfa14068edff2d4457bfeca12ad80fc
> 15:12:41 *** FAILED STEP ***
> merge from staging
> Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
> 15:12:41 Traceback (most recent call last):
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 528, in handle_staging
> self.build (issue_id=issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 328, in build
> issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>
This fails in multiple musicxml-converted files. It's not clear to me
just why from the logs. I am backing out
commit 1c51a616e289fffb918942c8f1e189ab50809157
Author: Knut Petersen
Date: Fri Jul 19 00:05:00 2019 +0200
Fix musicxml2ly.py / Python 2.4.5 incompatibility
In LilyPond 2.19.44 code was introduced that
improved musicxml2ly. Unfortunately, the new
code introduced a dependency on Python 2.7+,
although our installers only provide the
ancient Python 2.4.5.
If our Python 2.4.5 was used to interpret
musicxml2ly, some parts of the generated
lilypond source file were ok, in other parts
every character was paired with an additional
NUL byte. This commit fixes that problem
by adding '.encode('utf-8')' at some places.
A 2nd problem was that str.format() was
used. Unfortunately, str.format() is only
available in python 2.6+. The patch replaces
affected code with syntax compatible to our
Python 2.4.5.
from staging in order to try again. If you cannot reproduce, I'll try
to see whether I can figure out more after patchy finishes with the
previous revert.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Colored box behind a single note
Werner LEMBERG writes: > OK, more comments added to the source code. > > I wish that other parts of lilypond are having similarly detailed > comments... Well, that's exactly the reason to be adding them according to Immanuel Kant's seminal writings on coding standards. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Colored box behind a single note
Werner LEMBERG writes:
>>> diff --git a/lily/horizontal-bracket-engraver.cc
>>> b/lily/horizontal-bracket-eng
>if (d == STOP)
> {
>pop_count_++;
> - if (pop_count_ > bracket_stack_.size ())
> +
> + // Since N `L' events create N HorizontalBracket grobs we need (at
> + // most) N `R' events to finish them. However, at this particular
> + // moment, a single-moment horizontal bracket might be created also;
> + // this takes another `L' event (which might not have caused a new
> + // element on `bracket_stack' yet) and its corresponding `R' event.
> + if (pop_count_ > bracket_stack_.size () + 1)
> ev->origin ()->warning (_ ("do not have that many brackets"));
> }
"which might not have caused a new element"? That sounds like this may
or may not suppress an actually warranted warning.
Correct?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
James writes: > Hello, > > On 26/07/2019 16:13, David Kastrup wrote: >> David Kastrup writes: >> >>> David Kastrup writes: >>> >>>> fatal: Not a valid object name master >>>> >>>> Apparently, the patch from >>>> commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95 >>>> Author: Knut Petersen >>>> Date: Sun Jul 7 13:16:05 2019 +0200 >>>> >>>> Optimize tree.gittxt messages >>>> We display BRANCH, HEAD, MERGE-POINT >>>> and HISTORY fom merge-point to HEAD. >>>> If we do not find a merge-point we >>>> display the last ten commits if this >>>> is possible. >>>> >>>> relies on the existence of a local (rather than upstream) branch >>>> "master", not a good idea. I am backing out this commit from staging: >>>> it needs to get fixed. >>> Someone or some patchy happening to have a local master branch (a bad >>> idea since absolutely no development should happen in a local master >>> branch in our setup) already pushed that commit to staging. >> I mean, to master. Pushing to staging was very much the correct step to >> take in the life of the patch. >> >>> Consequentially, I had to push a revert to staging and hope I'll get it >>> through without manually tampering with master. > > I personally closed the sourceforge ticket with the commit ID etc. > > --snip-- > > pkx166h <https://sourceforge.net/u/lilypond-pkx/> - /3 days ago / > <https://sourceforge.net/p/testlilyissues/issues/5534/#d5a7> > > Optimize tree.gittxt messages master staging > author Knut Petersen > Sun, 7 Jul 2019 12:16:05 +0100 (13:16 +0200) > committer Knut Petersen > Mon, 22 Jul 2019 10:04:40 +0100 (11:04 +0200) > commit 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95 > > --snip-- > > However looking at the date stamps of the logs of my patchy runs - the > patchy scrits generate text files for each run - I ran one on the 25th > (pushing Urs trivial checkin) and then before that on the 17th, which > was for Knut's previous fix (and I think included Werner's). > > So there is another patchy pushing stuff as Knut's 'failed' commit was > in between those times. I run Patchy when I notice something went to staging. Due to its cost, I tend to abort it when I discover someone else pushing before me. So it would appear that your repository (and probably that of Knut) have a local master branch which would mask that the patch in question does not produce output relative to the origin repository and thus produces stuff that is not reducible. A local master branch tends to be a bad idea (though not as bad as a local staging branch) since you don't want to collect changes of your own on it. > Unless Knut is also running patchy now that he has commit access (and > perhaps didn't have a clean master?). > > (I don't want to cast aspersions, but it might be a genuine mistake if > it was Knut). Knut? I rather doubt that it was Knut since I mentioned the procedures to him right now and you said that you pushed the patch in question anyway (so it's very unlikely that he'd run the patchy subsequently responsible for promoting it to master). The more likely version is that your repository, having a local master branch, failed figuring out that the patch was problematic and promoted it to master. And my patchy version, running at some later date to push an unrelated patch, got tripped up by the change that had entered master because of your Patchy not tripping over the behavior that my Patchy got stuck on. And my first mails were based on me missing that the problematic patch in master had already been there for a day or two. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Colored box behind a single note
Werner LEMBERG writes:
>>>if (d == STOP)
>>> {
>>>pop_count_++;
>>> - if (pop_count_ > bracket_stack_.size ())
>>> +
>>> + // Since N `L' events create N HorizontalBracket grobs we need (at
>>> + // most) N `R' events to finish them. However, at this particular
>>> + // moment, a single-moment horizontal bracket might be created also;
>>> + // this takes another `L' event (which might not have caused a new
>>> + // element on `bracket_stack' yet) and its corresponding `R' event.
>>> + if (pop_count_ > bracket_stack_.size () + 1)
>>> ev->origin ()->warning (_ ("do not have that many brackets"));
>>> }
>>
>> "which might not have caused a new element"? That sounds like this
>> may or may not suppress an actually warranted warning.
>>
>> Correct?
>
> Right, thanks for noticing. I've fixed this – to a certain extent,
> see comments in the attached new version of the patch.
>
> If someone is going to rewrite the algorithm, the order of events
> should be obeyed.
For simultaneous events, LilyPond has no order. That's why one needs to
have one phase for recording events and another for doing something
based on them.
There is a very tricky exception in order to distinguish
[Some override] \grace { ...
from
\grace { [Some override] ...
since \grace itself overrides a number of properties (mostly sizes) and
the order needs to be heeded. The grace iterator creates special events
for that purpose.
Maybe the infamous issue 34 could be tackled as part of that mechanism?
Not sure about that.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Colored box behind a single note
Werner LEMBERG writes: >>> If someone is going to rewrite the algorithm, the order of events >>> should be obeyed. >> >> For simultaneous events, LilyPond has no order. > > Oh. This means that > > c'\startGroup\stopGroup > > and > > c'\stopGroup\startGroup > > can't be reliably distinguished? Not completely. In particular, some engravers might get to see the \startGroup before other engravers see the \stopGroup. Also things like \startGroup and \stopGroup are quite likely to be placed in a separate music variable that is being combined using parallel music. So while there is a typical order of events, it's not a guaranteed one. >> That's why one needs to have one phase for recording events and >> another for doing something based on them. > > Hmm. I got the impression that `listen_note_grouping' is this > recording-events phase. I'd have to take a closer look. So far, I've mostly did code review by reflex, just knowing what kind of trouble LilyPond is prone to cause. >> Maybe the infamous issue 34 could be tackled as part of that >> mechanism? Not sure about that. > > It would be nice if we find a solution for that. You bet. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Knut Petersen writes: > On 26.07.19 20:36, David Kastrup wrote: >> >>> Unless Knut is also running patchy now that he has commit access (and >>> perhaps didn't have a clean master?). >>> >>> (I don't want to cast aspersions, but it might be a genuine mistake if >>> it was Knut). Knut? >> I rather doubt that it was Knut since I mentioned the procedures to him >> right now and you said that you pushed the patch in question anyway (so >> it's very unlikely that he'd run the patchy subsequently responsible for >> promoting it to master). > I never used patchy. According to my memories and according to my logs > pushing the commits to staging was done right and successful. > > But yes, there is a local branch master on my system. I never thought that > there is a clone of the lilypond repository without a local master as > >git clone git://git.sv.gnu.org/lilypond.git > > > clones the repository and checks out 'master'. Sorry for the mess. > > It's clear that 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95 needs > to be fixed. > > What happened to the musicxml2ly patch? It vanished from staging. > Shall I push it again? It didn't pass patchy testing on my computer with failures in the musicxml files. So it appears to have a problem with, uh, Python 2.7.16+ (according to python --version on my current Ubuntu). If you need more pointers, I can try getting useful logs. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Knut Petersen writes:
> On 27.07.19 07:56, David Kastrup wrote:
>>
>>> What happened to the musicxml2ly patch? It vanished from staging.
>>> Shall I push it again?
>> It didn't pass patchy testing on my computer with failures in the
>> musicxml files. So it appears to have a problem with, uh, Python
>> 2.7.16+ (according to python --version on my current Ubuntu). If you
>> need more pointers, I can try getting useful logs.
>
>
> Yes, that would be very helpful. Before announcing that I thought that
> the patch was ready it passed a full GUB build on my system and the
> code processed all musicxml from the lilypond sources correctly with
> both the GUB-generated python 2.4.5 and the system's (opensuse
> tumbleweed) python 2.7.16.
>
> The relevant log file and the *.ly files generated from the xml
> sources would be of interest.
Converting MusicXML file `74a-FiguredBass.xml'...
Converting MusicXML file `75a-AccordionRegistrations.xml'...
Converting MusicXML file `90a-Compressed-MusicXML.mxl'...
Converting MusicXML file `99a-Sibelius5-IgnoreBeaming.xml'...
Converting MusicXML file `99b-Lyrics-BeamsMelismata-IgnoreBeams.xml'...
Writing snippets...
Processing...
Processing
/usr/local/tmp/lilypond/out/lybook-testdb/snippet-names-9124213700985165589.ly
command failed: /usr/local/tmp/lilypond/out/bin/lilypond \
-I . -dbackend=eps --formats=ps -dseparate-log-files
-dinclude-eps-fonts -dgs-load-fonts --header=texidoc -I
/usr/local/tmp/lilypond/Documentation/included/ -ddump-profile
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1
-dfont-export-dir=/usr/local/tmp/lilypond/out-fonts -O TeX-GS -I "./" -I
"/usr/local/tmp/lilypond/input/regression/musicxml" -I
"/usr/local/tmp/lilypond/input/regression/musicxml" --formats=eps
-deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir
"/usr/local/tmp/lilypond/out/lybook-testdb/snippet-names-9124213700985165589.ly"
Child returned 1
Error ignored by lilylib
Error trapped by lilypond-book
Please see
/usr/local/tmp/lilypond/out/lybook-testdb/snippet-names-9124213700985165589.log
make[2]: *** [../../../make/ly-rules.make:42: out-test/collated-files.texi]
Error 1
make[2]: Leaving directory '/usr/local/tmp/lilypond/input/regression/musicxml'
make[1]: *** [../../../make/lysdoc-targets.make:14: local-test] Error 2
make[1]: Leaving directory '/usr/local/tmp/lilypond/input/regression/musicxml'
make: *** [GNUmakefile:314: test] Error 2
dak@lola:/usr/local/tmp/lilypond$ grep sourcefilename `grep -L systems.texi
out/lybook-testdb/*/*log|sed s/log/ly/g`
out/lybook-testdb/02/lily-9590f87a.ly:\sourcefilename
"46g-PickupMeasure-Chordnames-FiguredBass.xml"
out/lybook-testdb/bf/lily-5968767c.ly:\sourcefilename "71f-AllChordTypes.xml"
out/lybook-testdb/cf/lily-aefcd7fa.ly:\sourcefilename
"71d-ChordsFrets-Multistaff.xml"
out/lybook-testdb/d1/lily-4604f705.ly:\sourcefilename
"71g-MultipleChordnames.xml"
out/lybook-testdb/e9/lily-5da7485a.ly:\sourcefilename "71a-Chordnames.xml"
out/lybook-testdb/f7/lily-4ea110e1.ly:\sourcefilename "71c-ChordsFrets.xml"
%% Generated by lilypond-book.py
%% Options: [exampleindent=10.16\mm,indent=0\mm,line-width=160\mm]
\include "lilypond-book-preamble.ly"
%
% Start cut-&-pastable-section
%
\paper {
indent = 0\mm
line-width = 160\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.00) (* mm 1))
}
\layout {
}
%
% ly snippet:
%
\sourcefilename "46g-PickupMeasure-Chordnames-FiguredBass.xml"
\sourcefileline 0
\version "2.21.0"
% automatically converted by musicxml2ly from -
\pointAndClickOff
\header {
texidoc =
"Pickup measure with chord names
and figured bass."
}
\layout {
\context { \Score
autoBeaming = ##f
}
}
PartPOneVoiceOne = \relative c'' {
\key c \major \numericTimeSignature\time 4/4 \partial 4 c8 c8 | % 1
c,4 c4 c4 c4 }
PartPOneVoiceOneChords = \chordmode {
\partial 4 :5 s8 | % 1
:5 s4 s4 }
PartPOneVoiceOneFiguredBass = \figuremode {
\partial 4 <3>8 s8 | % 1
<3>8 s8 s4 s4 }
% The score definition
\score {
<<
\context ChordNames = "PartPOneVoiceOneChords" { \PartPOneVoiceOneChords}
\new Staff
<<
\context Staff <<
\mergeDifferentlyDot
Re: Patchy email
James writes: > On 26/07/2019 19:36, David Kastrup wrote: >> ... >> I run Patchy when I notice something went to staging. Due to its cost, >> I tend to abort it when I discover someone else pushing before me. >> >> So it would appear that your repository (and probably that of Knut) have >> a local master branch which would mask that the patch in question does >> not produce output relative to the origin repository and thus produces >> stuff that is not reducible. A local master branch tends to be a bad >> idea (though not as bad as a local staging branch) since you don't want >> to collect changes of your own on it. > > However the patchy scripts set up a local master > > e.g. If I manually delete my local master and then run the patchy scripts: > >> Branch 'master' set up to track remote branch 'master' from 'origin'. >> Switched to a new branch 'master' > > (or is that not what you are talking about?) It is, but that does not happen in my repository when running lilypond-patchy-staging.py . Since there is no point in maintaining a local master potentially differing from upstream in the testing scripts, I wonder what script would be responsible here. > My workflow is that I always make sure that dev/local_working (where I > do my own changes before creating patches), local staging and local > master are always 'in sync' before I run patchy and that staging is > cleaned. > > It's no different than what I have always done. > > So I wonder why the tests passed and my own patchy merge passed but > yours failed? My patchy-staging test does not create a local master and I don't maintain one of my own. I wonder why it would be different from yours. > I am just worried that the veracity of my patch testing is not good > enough My lilypond-extra is up to date with two patches on top (that likely should at some time be pushed): commit c8c317eed3e774fb73132e48071ebd14bdda1b88 (HEAD -> master) Author: David Kastrup Date: Tue May 19 10:21:13 2015 +0200 Replace --disable-optimising with the faster --enable-checking commit 6d784e9a2c5e7f0f1baf6cd500459504be51826e Author: David Kastrup Date: Tue Feb 12 11:11:57 2013 +0100 Use printf rather than echo for result script to avoid interpreted backslashes Neither of those would make a difference in that regard. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
James writes: > Hello, > > On 27/07/2019 10:10, David Kastrup wrote: >> James writes: >> >>> On 26/07/2019 19:36, David Kastrup wrote: >>>> ... >>>> I run Patchy when I notice something went to staging. Due to its cost, >>>> I tend to abort it when I discover someone else pushing before me. >>>> >>>> So it would appear that your repository (and probably that of Knut) have >>>> a local master branch which would mask that the patch in question does >>>> not produce output relative to the origin repository and thus produces >>>> stuff that is not reducible. A local master branch tends to be a bad >>>> idea (though not as bad as a local staging branch) since you don't want >>>> to collect changes of your own on it. >>> However the patchy scripts set up a local master >>> >>> e.g. If I manually delete my local master and then run the patchy scripts: >>> >>>> Branch 'master' set up to track remote branch 'master' from 'origin'. >>>> Switched to a new branch 'master' >>> (or is that not what you are talking about?) >> It is, but that does not happen in my repository when running >> lilypond-patchy-staging.py . Since there is no point in maintaining a >> local master potentially differing from upstream in the testing scripts, >> I wonder what script would be responsible here. > > I don't think it is any script per se, I used to use Lily-git (which > fetches master and staging and sets up dev/local_working. > > So I've always had a local master. > > Also, I test patches against current master (not staging) so I'd need > a local master then too right? > > i.e > > checkout master, run make, make test-basline, apply patch etc etc. You don't need a local master for that. checkout origin or checkout origin/master does not create a local branch but just works from an ephemeral commit. > I don't run a script to test patches - the script 'broke' when we > moved from Google to Sourceforge, so I just test patches 'manually' > (out of tree) but I do make sure my local master is reset 'hard' (so > to speak) before I test things. You'll need to reset the work directory in any case (but a new checkout should cater for that), but branch maintenance is not really necessary. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Knut Petersen writes: > Hi David! > > Thank you for the information you provided. Something is really broken, > but after quite some time of debugging, I'm beginning to wonder if it really > is my patch / system or if it might be that origin/master is broken after all. > > Could you please verify if (after adapting the arguments to configure in > line 6) executing the following commands in your local lilypond repository > succeeds? Be aware that there is a 'git clean' command, so save your work > first! > >git clean -dfx I am not going to git-clean on my current repository/workdirectory since there is too much temporary stuff in there I might still need. I will create a separate clone. >git checkout origin/master >./autogen.sh --noconfigure >mkdir -p build >cd build >../configure --prefix= > --with-urwotf-dir= I don't have urwotf fonts but doubt that would be related to the musicxml2ly issues. >make -j 11 CPU_COUNT=11 all >make -j 11 CPU_COUNT=11 test-baseline > > Making test-baseline really should succeed - on my system it does _not_ > succeed > with the current origin/master. If making test-baseline does not succeed: > Does it > succeed with my patch (1c51a616e289fffb918942c8f1e189ab50809157)? > > Is there a safe way to execute a local patchy test? Patchy does nothing you cannot do manually. I don't remember offhand whether it builds in-place or out-of-place. lilypond-patchy-staging does not work with "make check" or "make test-baseline": it merely does make all, make test, and make doc . I haven't created a test-baseline for myself in quite a bit of time. I'll do that first in my local setup to check whether that still works. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
David Kastrup writes: > Knut Petersen writes: > >> Hi David! >> >> Thank you for the information you provided. Something is really broken, >> but after quite some time of debugging, I'm beginning to wonder if it really >> is my patch / system or if it might be that origin/master is broken after >> all. >> >> Could you please verify if (after adapting the arguments to configure in >> line 6) executing the following commands in your local lilypond repository >> succeeds? Be aware that there is a 'git clean' command, so save your work >> first! >> >>git clean -dfx > > I am not going to git-clean on my current repository/workdirectory since > there is too much temporary stuff in there I might still need. I will > create a separate clone. > >>git checkout origin/master >>./autogen.sh --noconfigure >>mkdir -p build >>cd build >>../configure --prefix= >> --with-urwotf-dir= > > I don't have urwotf fonts but doubt that would be related to the > musicxml2ly issues. > >>make -j 11 CPU_COUNT=11 all >>make -j 11 CPU_COUNT=11 test-baseline >> >> Making test-baseline really should succeed - on my system it does _not_ >> succeed >> with the current origin/master. If making test-baseline does not >> succeed: Does it >> succeed with my patch (1c51a616e289fffb918942c8f1e189ab50809157)? >> >> Is there a safe way to execute a local patchy test? > > Patchy does nothing you cannot do manually. I don't remember offhand > whether it builds in-place or out-of-place. lilypond-patchy-staging > does not work with "make check" or "make test-baseline": it merely does > make all, make test, and make doc . I haven't created a test-baseline > for myself in quite a bit of time. I'll do that first in my local setup > to check whether that still works. And here are the results from a freshly cloned tree: with your patch, test-baseline fails. Without it, it succeeds. The musicxml error clearly is due to the way you rewrote chord mode output. Either you forgot to cater for some case (in which case it would be surprising that it succeeds at your site), or the committed patch does not contain all the changes you did at your site (have you checked cherry-picking the version pushed to staging?). Or our environment differs in some crucial detail. Or, given the rather bland symptoms, the build procedures on your and/or my site pick up part of locally installed files rather than just the build tree, and the corresponding mismatch of the code (more than one Python file is changed by the patch) leads to the problematic output. Would any log files help? I can rerun make test (both successfully and unsuccessfully) with redirected log files and probably also not use multithreading in order to give comparable log files. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Knut Petersen writes: > On 29.07.19 16:27, David Kastrup wrote: >> And here are the results from a freshly cloned tree: with your patch, >> test-baseline fails. Without it, it succeeds. > > Thanks. The other way round here. > >> Would any log files help? I can rerun make test (both successfully and >> unsuccessfully) with redirected log files and probably also not use >> multithreading in order to give comparable log files. > Unfortunately the logs don't show which parts of the python etc. are used. > I'll do some further tests and strace the whole 'make test-baseline' process. > Somewhere in the strace logs will be the answer. For whatever it may be worth: outside of running the build scripts I have dak@lola:/usr/local/tmp/lilypond2/build$ which musicxml2ly /usr/local/bin/musicxml2ly dak@lola:/usr/local/tmp/lilypond2/build$ echo $PATH /home/dak/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin That variant of musicxml2ly would be of some 2.21.0 leadup variety. If you have anything derived from your patch/testing there, this could be involved with the difference we are (but should not be) seeing. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Knut Petersen writes: > On 29.07.19 16:27, David Kastrup wrote: >> And here are the results from a freshly cloned tree: with your patch, >> test-baseline fails. Without it, it succeeds. > > Thanks. The other way round here. > >> Would any log files help? I can rerun make test (both successfully and >> unsuccessfully) with redirected log files and probably also not use >> multithreading in order to give comparable log files. > Unfortunately the logs don't show which parts of the python etc. are used. > I'll do some further tests and strace the whole 'make test-baseline' process. > Somewhere in the strace logs will be the answer. Well, it is rather obvious that you should not be seeing failure with unchanged master (assuming that you have some reasonably current Python on your system) and I should not be seeing failure with your patch (assuming that it tests out on your system: the symptoms are just too clear to seem dependent on Python version). So it's likely that some preinstalled part (assuming both of us worked from clean trees) creeps into both our operations. That would be more likely than not a preexisting problem not caused by your patch but we would still better fix it before it causes more headaches. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Knut Petersen writes: > On 29.07.19 17:55, David Kastrup wrote: >> Well, it is rather obvious that you should not be seeing failure with >> unchanged master (assuming that you have some reasonably current Python >> on your system) and I should not be seeing failure with your patch >> (assuming that it tests out on your system: the symptoms are just too >> clear to seem dependent on Python version). So it's likely that some >> preinstalled part (assuming both of us worked from clean trees) creeps >> into both our operations. That would be more likely than not a >> preexisting problem not caused by your patch but we would still better >> fix it before it causes more headaches. > > In the chapter "Regtest comparison" of our contributor's guide we can read: > >Run |make|with current git master without any of your changes. >Before making changes to the code, establish a baseline for the comparison > by going to the ‘$LILYPOND_GIT/build/’ directory and running: > >make test-baseline > > Stracing shows that after 'make all' it is also necessary to execute > 'make install' prior to 'make test-baseline' or 'make test-clean'. That's insane. Having to install LilyPond before being able to test it makes no sense. > If 'make install' is omitted, the result depends both on files from > the baseline version and on files that belong to the version of > lilypond that was last installed with the same prefix. Then we need to fix that. > David, please rerun the test of my patch against origin/master on your > system. On my system the process succeeds now: > If the process also succeeds on your system we would know that patchy > needs a fix. No, that make test needs a fix. make test is supposed to test the version in the work directory, not some weird amalgamate between system installed version and work directory version. Any idea what would be required here? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book-preamble and cropping
"Urs Liska" writes: > I'm not sure if this is actually a *development* request or if it > could also be solved at the "user" level. > > As Werner showed in https://github.com/jperon/lyluatex/issues/268 > (https://github.com/jperon/lyluatex/issues/268) there is an issue with > the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT > this is something inherent in the lilypond-book handling which should > also be visible in any lilypond-book scores. > > When compiling with lilypond-book-preamble the score gets sliced in > systems, and each system is *additionally cropped*. I have never > understood the commands in that file so I don't know in what order > these things happen, I don't even know if that lack of the concept of > a "page" (we only have a sequence of systems now) affects the actual > layout process. > > Of course you will often want to have the cropped systems, essentially > when including single systems in a text document, or at the top or the > bottom of pages. However, when stacking the resulting systems this > means that the space between systems is inconsistent and generally too > narrow. This can sometimes be alleviated by adding space between the > systems, but sometimes this doesn't help. As Werner's example images > in the issue report linked above show: when a system has much > additional stuff above or below (e.g. marks, text or just legder > lines) this significantly disturbes the vertical spacing. > > What I would need to achieve - either by providing some modification > of lilypond-book-preamble or as a feature request to be added to > LilyPond - is a compilation mode that behaves like > lilypond-book-preamble *without the vertical cropping* (but with > horizontal cropping). Alternatively (maybe even better) would be > writing an additional aux file stating the amount of space cropped, at > least at the top and bottom but maybe for all four sides. Or the > original image size before cropping. Anything that can be used to > infer the space one should add before and after the system to rebuild > LilyPond's original page layout. > > Any ideas? For employing something like TeX, one needs to know the baseline, the top extent, the bottom extent, and the skyline spacing to be used between one system and the next. Then one can pad as necessary when systems are separated by pagebreaks or other material and use the skyline spacing then they aren't. Yes, glue like that can be constructed in TeX while still leaving the page break decisions to TeX. The main problem we are having with cropping is the implementation of cross staff material which does not count towards skylines and extents. Instead it would need to count towards the upper skyline and extent in its top staff, and towards the bottom skyline and extent in its bottom staff. That way it would not push apart the systems it crosses while still making an impact letting it survive in the bounding boxes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book-preamble and cropping
"Urs Liska" writes: > 30. Juli 2019 11:16, "David Kastrup" schrieb: > >> "Urs Liska" writes: >> >>> I'm not sure if this is actually a *development* request or if it >>> could also be solved at the "user" level. >>> >>> As Werner showed in https://github.com/jperon/lyluatex/issues/268 >>> (https://github.com/jperon/lyluatex/issues/268) there is an issue with >>> the output of scores compiled with `lilypond-book-preamble.ly`. AFAICT >>> this is something inherent in the lilypond-book handling which should >>> also be visible in any lilypond-book scores. >>> >>> When compiling with lilypond-book-preamble the score gets sliced in >>> systems, and each system is *additionally cropped*. I have never >>> understood the commands in that file so I don't know in what order >>> these things happen, I don't even know if that lack of the concept of >>> a "page" (we only have a sequence of systems now) affects the actual >>> layout process. >>> >>> Of course you will often want to have the cropped systems, essentially >>> when including single systems in a text document, or at the top or the >>> bottom of pages. However, when stacking the resulting systems this >>> means that the space between systems is inconsistent and generally too >>> narrow. This can sometimes be alleviated by adding space between the >>> systems, but sometimes this doesn't help. As Werner's example images >>> in the issue report linked above show: when a system has much >>> additional stuff above or below (e.g. marks, text or just legder >>> lines) this significantly disturbes the vertical spacing. >>> >>> What I would need to achieve - either by providing some modification >>> of lilypond-book-preamble or as a feature request to be added to >>> LilyPond - is a compilation mode that behaves like >>> lilypond-book-preamble *without the vertical cropping* (but with >>> horizontal cropping). Alternatively (maybe even better) would be >>> writing an additional aux file stating the amount of space cropped, at >>> least at the top and bottom but maybe for all four sides. Or the >>> original image size before cropping. Anything that can be used to >>> infer the space one should add before and after the system to rebuild >>> LilyPond's original page layout. >>> >>> Any ideas? >> >> For employing something like TeX, one needs to know the baseline, the >> top extent, the bottom extent, and the skyline spacing to be used >> between one system and the next. Then one can pad as necessary when >> systems are separated by pagebreaks or other material and use the >> skyline spacing then they aren't. Yes, glue like that can be >> constructed in TeX while still leaving the page break decisions to TeX. >> >> The main problem we are having with cropping is the implementation of >> cross staff material which does not count towards skylines and extents. >> Instead it would need to count towards the upper skyline and extent in >> its top staff, and towards the bottom skyline and extent in its bottom >> staff. That way it would not push apart the systems it crosses while >> still making an impact letting it survive in the bounding boxes. > > I see that an issue is that *of course* a PDF including one system > *has* to cause a problem when two adjacent systems > overlap. https://github.com/jperon/lyluatex/issues/268#issuecomment-516358134 > and > https://github.com/jperon/lyluatex/issues/268#issuecomment-516360973 > show contrived examples compiled with and without > lilypond-book-preamble to demonstrate the problem. > > Would there be any way to get LilyPond to produce a number from which > one can infer the extent by which two adjacent systems should overlap > or have been drawn apart through the page layout? Uh, no? We'd be using them in \score-lines or lilypond-book if they were available, wouldn't we? Flexible spacing and skyline-based spacing only exists internally of LilyPond's page breaker/builder. Cracking this open would certainly increase LilyPond's flexibility a lot and would give the design of custom page layouts a lot more substance. But this is quite a closed box as of now. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond's gs console output on windows
Werner LEMBERG writes: > Folks, > > > on a Windows 10 box I downloaded and installed the binary distribution > of 2.19.83, which worked fine; I was able to compile a PDF on the > Windows command line (I think that drag and drop to the lilypond icon > doesn't work, but since my Windows knowledge is too limited I haven't > pursued this further). Then I tried to directly call `gs', the > ghostscript binary that comes with lilypond. It produces an empty > line on the console, and that's it. Later on, I wondered why the > laptop's fan suddenly starts to run loudly – checking with the task > manager I saw that gs still run as a background process... Doesn't Windows use rungs or something like that for interactive use? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development stalled
"Frank Bryce" writes: > Hello, > > my name is Frank and I have now used Lilypond for quite a long time, I > enjoy it for some years but I dont like that there is no current > improvements which a normal user can use. See the following list that > shows that it has been more then 5 1/2 years since the last major > version and even almost two years for the prerelease stage. That makes > me sad. Unfortunately Im not a programmer so I dont know how to > help. The German translation is very much outdated (lagging behind a number of years). Your Email address suggests being located in Austria though your family name does not exactly appear Austrian. Would you be close enough to being a native speaker to work in that area? > Should I change to Musescore or Dorico? What are you missing? What do you expect to accomplish from a change? LilyPond is so different from Musescore and Dorico that I don't really know what expectations you would have from changing programs that could also be addressed by a new release. > version release datedays since last release > 2.0.0 2003/09/24 > 2.2.0 2004/04/01 190 > 2.4.2 2004/11/08 221 > 2.6.0 2005/06/27 231 > 2.8.0 2006/03/22 268 > 2.10.02006/11/15 238 > 2.12.02008/12/22 768 > 2.14.02011/06/06 896 > 2.16.02012/08/24 445 > 2.18.02013/12/29 492 > 2.19.80 2017/10/16 1387 > today 2019/08/13 666 2.19.80 is not the latest release. Why would you not even upgrade to the latest release, yet complain that there is no newer one? I am not enthused about our current delays (for which I am certainly responsible to a good degree) but really don't see how you think you would gain from a program change. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: development stalled
Karlin High writes: > On 8/13/2019 4:42 PM, David Kastrup wrote: >> "Frank Bryce" writes: >> >>> Unfortunately Im not a programmer so I dont know how to >>> help. >> >> I am not enthused about our current delays > > David K. or other contributors, what would you suggest is a good > LilyPond development area for beginners to work on? > > The documentation seems often suggested, but in my experience it > mostly looks good already (the English version, anyway) The main translations in good order tend to be the Romance languages. The Germanic ones are really trailing, and the slavic ones are basically in disorder. > and I still have the same question: what needs work? > > The Contributor Guide suggests searching the issue tracker for issues > labeled "frog," but the most recent one is from 2014. Would this still > be a good approach? The problem is that code base problems are not really beginner stuff to tackle. There is a lot these days at LSR level that one can get working on, but there is not a lot of infrastructure (like LaTeX has for plugging in style files) where loose work like this can be collected in an organised manner. One might want to look at the openlilylib stuff. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond's gs console output on windows
Werner LEMBERG writes: > Ten days ago I wrote the following. > >> on a Windows 10 box I downloaded and installed the binary >> distribution of 2.19.83, which worked fine; I was able to compile a >> PDF on the Windows command line (I think that drag and drop to the >> lilypond icon doesn't work, but since my Windows knowledge is too >> limited I haven't pursued this further). Then I tried to directly >> call `gs', the ghostscript binary that comes with lilypond. It >> produces an empty line on the console, and that's it. Later on, I >> wondered why the laptop's fan suddenly starts to run loudly – >> checking with the task manager I saw that gs still run as a >> background process... >> >> After some tests I found out that only redirecting the stdout output >> to a file works on the Windows console. On the other hand, using >> the bash shell that comes with git for windows, I get proper output >> on the bash window without redirection. This behaviour is different >> to the lilypond binary, which produces output in both the Windows >> console and git bash. >> >> I know wonder whether this problem is >> >> (1) limited to the gs program that comes with lilypond, >> (2) related to the way gub is compiling gs, >> (3) connected to changes in the Windows 10 console, >> (4) or whether this a generic issue with gs itself, probably fixed >> in newer gs versions. >> >> If we will have this behaviour with the next gub build also, I >> suggest that it gets documented. > > There wasn't a response – I would be glad to get a confirmation (or > not) so that I can add it as an issue in case more people see the > problem. Didn't Windows require something like rungs or mgs or gswin32c or so? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond's gs console output on windows
Werner LEMBERG writes: >>> >> I know wonder whether this problem is >>> >> >>> >> (1) limited to the gs program that comes with lilypond, >>> >> (2) related to the way gub is compiling gs, >>> >> (3) connected to changes in the Windows 10 console, >>> >> (4) or whether this a generic issue with gs itself, probably >>> >> fixed in newer gs versions. >>> >> >>> >> If we will have this behaviour with the next gub build also, I >>> >> suggest that it gets documented. >>> >>> Didn't Windows require something like rungs or mgs or gswin32c or >>> so? >> >> I have LilyPond 2.19.83 on Windows 7 Pro 64-bit SP1 and Windows 10 >> Pro 64-bit version 1903. >> >> Both of them behave the same way on Windows console: output a blank >> line and exit. >> >> But, with Windows Subsystem for Linux, one can type "bash" in the >> console and it switches to a bash environment. That seems to >> execute things as expected. I haven't tried Git on Windows' bash >> shell. > > Thanks for testing; git's bash shell works just fine. > > It seems this is a GUB issue: It doesn't set the proper flag(s) to > build gs on windows as a console application. In other words, right > now GUB builds `gswin32' and not `gswin32c'. Maybe this is > intentional – I'm no expert on the Windows setup of GS. Intentional or not, it does not seem like a good idea. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @cindex and friends in snippet files
Werner LEMBERG writes: > Folks, > > > some stuff like `subdivideBeams' is only documented in files from > `Documentation/snippets'. However, not a single file in this > directory contains an index entry. > > What is the proper way to add index entries to those files? Are they > still synchronized with LSI? I would like to add a bunch of them, for > obvious reasons. I think that they are usually referenced from the main manual, and that's where the index entries then are placed. Of course, mentioning "related material" that is not actually related to the main entry is not overly sensible so this usually does require penning a few lines in the main manual if you don't want to appear obtuse. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @cindex and friends in snippet files
Werner LEMBERG writes: >>> What is the proper way to add index entries to those files? Are >>> they still synchronized with LSI? I would like to add a bunch of >>> them, for obvious reasons. >> >> I think that they are usually referenced from the main manual, and >> that's where the index entries then are placed. Of course, >> mentioning "related material" that is not actually related to the >> main entry is not overly sensible so this usually does require >> penning a few lines in the main manual if you don't want to appear >> obtuse. > > OK, thanks, will try. A separate index for the snippets would likely be nice (we have categories, though) but I have no idea how we could sensibly manage that without messing up the main manual indexing and also the LSR coordination. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.20 release roadmap
"Phil Holmes" writes: > Don't believe so. I've run GUB recently to build 2.18.83 and don't > know that 2.20 would not build, once the git repo is stable. There has been significant progress on GUB recently, mostly due to Knut. It's pretty clear however that it's unlikely Python 2 will be around for all of the 2.20 life cycle so that's likely to become a major distraction at some point of time. I don't think it would preclude 2.20.0 to be released, but it might necessitate a 2.20.1 (or greater) later in its life cycle, distracting from other work. I've recently done some significant bunches of cherry-picking from the development branch if anybody had bothered to look at the stable branch instead of just complaining, but am not finished with it yet. Once I am, that will likely be 2.19.84. It might end up being released 2.20.0 eventually (if no major problems surface) since the current impasse is looking to be causing more trouble than it is fixing. I am fighting with motivating myself. This question is being answered about every month or two and pretending otherwise is not really improving morale. I am really grateful for all the great people who reliably manage to keep up and contribute their part of getting there and am sorry that it seems so hard for me to do my part. As it stands, we don't have realistic alternatives for 2.20 release management offering themselves so I'll keep up stumbling to the finishing line. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.20 where are we?
Andrew Bernard writes: > So let me get this straight. > > It's not the case that GUB is completely broken. We can still build > releases. It's not broken _yet_ because Python 2 is still more or less available and of course we can keep using it (ignoring security issues) as long as we want. This will hit the native builds first. There have been some hits concerning Ghostscript that are currently in check but may come back. Also some other issues. > DK is working steadily to cherry pick items for 2.20. I'd not use the label "steadily" here. > Python 2 to Python 3 is a major issue. > > So, I offered to do the 2->3 port a long time ago but circumstances > prevented me from doing so. Would it be constructive if I launched > into that aspect? I cant understand the lilypond internals code but I > have extensive Python experience. > > Would this be helpful to moving forward? > > But have people already started on this, I thought? Kurt had started on it but asked for help getting more done. I don't know to what degrees others have actually stepped in also, but it's not like one could not share work by arranging who ports what. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Jonas Hahnfeld via lilypond-devel writes: > Am Samstag, den 21.09.2019, 12:09 +1000 schrieb Andrew Bernard: >> So let me get this straight. >> >> It's not the case that GUB is completely broken. We can still build >> releases. >> >> DK is working steadily to cherry pick items for 2.20. >> >> Python 2 to Python 3 is a major issue. >> >> So, I offered to do the 2->3 port a long time ago but circumstances >> prevented me from doing so. Would it be constructive if I launched into >> that aspect? I cant understand the lilypond internals code but I have >> extensive Python experience. >> >> Would this be helpful to moving forward? >> >> But have people already started on this, I thought? > > I've also started looking into this and used the branch > dev/knupero/lilypy3devel as a starting point (see also > https://lists.gnu.org/archive/html/bug-lilypond/2019-08/msg00014.html). > > On top of that I've worked on the attached patches which brings the > make targets check / test and doc back to life with Python 3.7.4. Maybe > they can be added to the branch mentioned above to serve as a single > source of truth? I know the third patch is pretty large, let me know if > I should try to split it up... > > As I'm pretty new to the development of Lilypond, I'm not really sure > if there's something else to do in the source code repository itself? > I'm pretty sure I didn't get to run through all error branches in all > scripts, but the targets mentioned in the documentation work for me > right now. If not, sounds like working on GUB would be next? I haven't checked yet, but at the current point of time, the best patches will be those running under both Python 2 and Python 3 without having to special-case code. Those can be applied to master and thus minimize the actual amount of code switching we ultimately need to do. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Jonas Hahnfeld writes: > Am Samstag, den 21.09.2019, 11:25 +0200 schrieb David Kastrup: > >> I haven't checked yet, but at the current point of time, the best >> patches will be those running under both Python 2 and Python 3 without >> having to special-case code. Those can be applied to master and thus >> minimize the actual amount of code switching we ultimately need to do. > > I agree that this would be ideal, but pretty hard: Already the result > of running 2to3 can't be executed under Python 2 in some cases or may > start to give different results. Examples include > * "isinstance(s, unicode)" -> "isinstance(s, str)", which is something > different in Python 2, and > * "import StringIO" -> "import io", which didn't have all functions in > Python 2. > > If that is the way required to get Lilypond ported to Python 3, I can > try to work into that direction. But finally, I guess there will need > to be a hard switch to Python 3... I think the principal problem is that I don't see us providing a GUB installer with both Python2 and Python3 in it. So code that does not run in both will need to get switched over at the time we switch GUB from Python2 to Python3. If I remember correctly, this will be the time that we definitely have to retire the PowerPC MacOSX version (it's not clear anybody is actually using it, though). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Jonas Hahnfeld via lilypond-devel writes: > Am Samstag, den 21.09.2019, 13:09 +0200 schrieb Werner LEMBERG: >> >> `git add -p' is your friend to do that conveniently. >> >> > >> >> > Sure, that is the usual suggestion. But I'm not sure if that is >> >> > really helpful here because none of these changes will do anything >> >> > on its own. >> >> >> What do you mean with `none will do anything on its own'? >> >> > So my question is whether the patch is too large to go as one "fix >> >> > that script for Python 3"? >> >> >> Well, I prefer a series of patches instead of a single patch. > > Ok, I'll split the third one. My concern was that a single part of the > series won't bring any benefit on its own. So for example only > changing the division operator will not make musicxml2ly work with > Python 3. Personally I am here more with you than with Werner here: as long as all changes are of a similar character not achieving an identifiable goal of their own (or being the result of running some script that may warrant rerunning because of required fixes or because of getting applied to a different branch with different code in it), I don't see the point into splitting them into separate commits. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated Stockhausen example
Werner LEMBERG writes: > Here's an updated version of the Stockhausen example, with a lot of > added comments to the source code. > > I've also attached an image of rendering the old code (as present in > the git) with a lilypond binary from current git. [...] Looking at the image, this appears more to the credit of LilyPond than Stockhausen. I have a hard time imagining a performer bringing this to life in a manner justifying the complexity written into the score. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @cindex and friends in snippet files
Werner LEMBERG writes: >> A separate index for the snippets would likely be nice (we have >> categories, though) but I have no idea how we could sensibly manage >> that without messing up the main manual indexing and also the LSR >> coordination. > > It's not clear to me what you exactly mean with a `separate index for > snippets'. Where should this index be? In the notation reference, in > the snippets document? And what do you envision of its contents? Uh, it was second-guessing what you were trying to achieve here. If you were only talking about indexing snippets into NR and/or LM, then it does not apply. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `begin verbatim' glitches in snippet files
usic is within a @code{\\transpose} section.
> \column {
>"LilyPond example file by Amelie Zapf,"
>"Berlin 07/07/2003"
> -} % begin verbatim
> -
> +}
>}
> }
> % To make the example display in the documentation
> diff --git a/Documentation/snippets/piano-template-simple.ly
> b/Documentation/snippets/piano-template-simple.ly
> index 278d0195da..414cc132fc 100644
> --- a/Documentation/snippets/piano-template-simple.ly
> +++ b/Documentation/snippets/piano-template-simple.ly
> @@ -23,8 +23,7 @@ upper = \relative c'' {
>\time 4/4
>
>a4 b c d
> -} % begin verbatim
> -
> +}
>
> lower = \relative c {
>\clef bass
> diff --git
> a/Documentation/snippets/quoting-another-voice-with-transposition.ly
> b/Documentation/snippets/quoting-another-voice-with-transposition.ly
> index f1a2651283..932f3d3d6d 100644
> --- a/Documentation/snippets/quoting-another-voice-with-transposition.ly
> +++ b/Documentation/snippets/quoting-another-voice-with-transposition.ly
> @@ -23,8 +23,7 @@ quoted ones) are transposed.
>
> \addQuote clarinet {
>\transposition bes
> - \repeat unfold 8 { d'16 d' d'8 } % begin verbatim
> -
> + \repeat unfold 8 { d'16 d' d'8 }
> }
>
> \addQuote sax {
> diff --git a/Documentation/snippets/quoting-another-voice.ly
> b/Documentation/snippets/quoting-another-voice.ly
> index 666e6fa55b..eaf0fede62 100644
> --- a/Documentation/snippets/quoting-another-voice.ly
> +++ b/Documentation/snippets/quoting-another-voice.ly
> @@ -28,7 +28,7 @@ the Internals Reference.
>
> quoteMe = \relative c' {
>fis4 r16 a8.-> b4\ff c
> -} % begin verbatim
> +}
>
> \addQuote quoteMe \quoteMe
>
> diff --git a/Documentation/snippets/string-quartet-template-simple.ly
> b/Documentation/snippets/string-quartet-template-simple.ly
> index 6e7f6e1a23..6ea885a57a 100644
> --- a/Documentation/snippets/string-quartet-template-simple.ly
> +++ b/Documentation/snippets/string-quartet-template-simple.ly
> @@ -21,8 +21,7 @@ This template demonstrates a simple string quartet. It also
> uses a
> global= {
>\time 4/4
>\key c \major
> -} % begin verbatim
> -
> +}
>
> violinOne = \new Voice \relative c'' {
>c2 d
> diff --git
> a/Documentation/snippets/string-quartet-template-with-separate-parts.ly
> b/Documentation/snippets/string-quartet-template-with-separate-parts.ly
> index e4e82c5ec0..26cd166d5c 100644
> --- a/Documentation/snippets/string-quartet-template-with-separate-parts.ly
> +++ b/Documentation/snippets/string-quartet-template-with-separate-parts.ly
> @@ -35,8 +35,7 @@ Do not forget to remove specified comments when using
> separate files!
> global= {
>\time 4/4
>\key c \major
> -} % begin verbatim
> -
> +}
>
>
> Violinone = \new Voice {
> diff --git a/Documentation/snippets/turkish-makam-example.ly
> b/Documentation/snippets/turkish-makam-example.ly
> index 7bb8d50fa2..440643448d 100644
> --- a/Documentation/snippets/turkish-makam-example.ly
> +++ b/Documentation/snippets/turkish-makam-example.ly
> @@ -24,8 +24,7 @@ of Turkish music notation.
> \header {
> title = "Hüseyni Saz Semaisi"
> composer = "Lavtacı Andon"
> -} % begin verbatim
> -
> +}
>
> \relative {
>\set Staff.extraNatural = ##f
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `begin verbatim' glitches in snippet files
Werner LEMBERG writes: >>> Since I'm unsure how to apply this correctly I post it here so that >>> a knowledgeable person can proceed. >> >> I'll try fixing those. > > Thanks. Current branch: verbatim Tracker issue: 5557 (https://sourceforge.net/p/testlilyissues/issues/5557/) Rietveld issue: 58343 (https://codereview.appspot.com/58343) Issue description: Remove spurious '% begin verbatim' in Documentation/snippets/new Also: Run scripts/auxiliar/makelsr.py This was a purely mechanical change. Please review to make sure that the resulting spacing and content in the Documentation/snippets directory given the mechanical changes in Documentation/snippets/new are correct: there are likely some ugly spacings and possibly some accidental removal of an actually intended % begin verbatim. Particularly utf-8.ly looks suspicious but make doc appeared to succeed. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updating makeinfo
Werner LEMBERG writes: >> I've not used my Ubuntu 14 lilypond computer for a while, and I'm >> now trying to help update the example images on the website. If I >> run configure I'm being told my makeinfo is too old - I've got 5.2 >> and it requires 6.1. I can't run the GUI updater because it just >> tells me there's an update to Ubuntu 16 and if I don't upgrade, but >> just click OK it exits. If I run sudo apt-get install texinfo it >> tells me I have the latest version. If I download the texinfo 6.1 >> tarball, extract it, and run configure. make and make install it >> does stuff, but makeinfo --version from my build directory still say >> I have 5.2. >> >> Anyone with any suggestions for getting and installing 6.1? > > I guess you just have to prepend `/usr/local/bin' to your path. > Usually, you can do this in your `~/.bashrc' file. > > Alternatively, assuming that you want a safe location for texinfo 6.1 > that won't get accidentally deleted or overwritten, you could try the > following. > > sudo mkdir /opt > > cd texinfo-6.1 > ./configure --prefix=/opt ... > make > make install > > cd lilypond > PATH=/opt/bin:$PATH ./configure ... > PATH=/opt/bin:$PATH make doc I prefer to install stuff in conflict with system installations in a separate directory of their own, say /opt/texinfo . You do this by configuring TeXinfo with ./configure --prefix=/opt/texinfo and then sudo make install will install underneath. Then you need to configure LilyPond with MAKEINFO=/opt/texinfo/bin/makeinfo ./configure and usually this should make the LilyPond build procedure fine for working with this version of makeinfo. I do the same for Guile-1.8, with the magic incantation making the Guile installation known to LilyPond's configure is GUILE_CONFIG=/opt/guile-1.8/bin/guile-config ./configure since guile-config is used for teaching the build process everything about how to locate Guile components. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updating makeinfo
"Phil Holmes" writes: > A bit odd. I checked my path following your advice and /usr/local/bin > was already there. So I tried makeinfo --version again from my > lilypond directory and this time it said version 6.1. So I re-ran > configure and it was OK. > > Guess the path statement was reread when the computer was idle. hash -r -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: define-public vs. define-safe-public
Malte Meyn writes: > Hi list, > > is there a clear policy which functions are defined public or > safe-public? Asking for > https://sourceforge.net/p/testlilyissues/issues/5517/ If I understand > correctly what define-safe-public does I don’t understand why some > things at the beginning of lily-library.scm are public and others > safe-public. Safe stuff cannot be used for breaching containment via Scheme, like accessing files on disk. Many functions that appear quite safe are not declared that way: this is implemented rather cursorily. The full LSR import gives a list of files not working when using -dsafe; this list is humongous and does not really reflect reality. For anything serious, you'd rather rely on containers. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3
Dan Eble writes: > On Sep 27, 2019, at 16:34, Matthew Peveler wrote: >> >> I'll have another email later on with patches for having this branch run >> under both python2.7 & 3 as the necessary backport efforts were not really >> all that extravagant with just a handful of shims around the changes you >> noted in long vs int, unicode vs str, StringIO vs io, iter.next vs >> iter.__next__, reload, xrange vs range. > > Are these complications desirable? A clean and obvious implementation > requiring Python 3 will be easier to maintain. And that's what we are going to end up with ultimately. But I don't see that a clean cut from Python2 to Python3 in a single step is easily feasible and testable for all targets at once including all GUB targets. If we are talking about "just a handful of shims", that certainly sounds like causing the least trouble. The plan would not be to maintain them for extended amounts of time but rather to help getting the Python3 transition over with with the least amount of pain. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Allow slurs instead of brackets with tuplets (issue 581110043 by lemzw...@googlemail.com)
lilyp...@maltemeyn.de writes: > On 2019/10/07 15:01:56, dak wrote: > > https://codereview.appspot.com/581110043/diff/569040043/input/regression/tuplet-slur-tweaks.ly >> File input/regression/tuplet-slur-tweaks.ly (right): > > > https://codereview.appspot.com/581110043/diff/569040043/input/regression/tuplet-slur-tweaks.ly#newcode1 >> input/regression/tuplet-slur-tweaks.ly:1: \version "2.19.55" >> On 2019/10/07 14:02:46, Malte Meyn wrote: >> > Shouldn’t this be 2.21.0? > >> Why? > > IIUC the version should always be the first one which supports the > syntax and features used. Is this incorrect? > > https://codereview.appspot.com/581110043/ Syntax yes, features not necessarily. It should be a version that compiles (and does not produce warnings, like for non-existing properties) so that one can compare regtests if desired. Does this exercise new features, or does it only change the results of existing ones? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub targets + binary packages
Carl Sorensen writes: > On 10/7/19, 11:27 AM, "lilypond-devel on behalf of Jonas Hahnfeld via > lilypond-devel" of lilypond-devel@gnu.org> wrote: > > Hi all, > > lately I've been playing with gub, partly to get python3 packaged. Upon > inspection, it seems some targets are broken and some are ... a bit > out-of-date: > > darwin-ppc: Support for applications targeting PowerPC was removed in > Darwin 11.0 / Mac OS X 10.7, released in 2011. > > That doesn't mean there aren’t people using PowerPC macs. I don't > think there is a reason to eliminate this target. When we complete transition to Python 3, I don't think there is a working port. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub targets + binary packages
Carl Sorensen writes: > On 10/7/19, 12:33 PM, "David Kastrup" wrote: > > Carl Sorensen writes: > > > On 10/7/19, 11:27 AM, "lilypond-devel on behalf of Jonas > > Hahnfeld via lilypond-devel" > > > lilypond-devel@gnu.org> wrote: > > > > Hi all, > > > > lately I've been playing with gub, partly to get python3 packaged. > Upon > > inspection, it seems some targets are broken and some are ... a bit > > out-of-date: > > > > darwin-ppc: Support for applications targeting PowerPC was removed > in > > Darwin 11.0 / Mac OS X 10.7, released in 2011. > > > > That doesn't mean there aren’t people using PowerPC macs. I don't > > think there is a reason to eliminate this target. > > When we complete transition to Python 3, I don't think there is a > working port. > > By port, do you mean Python 3 doesn't work on PPC, or the MacPorts > doesn't support Python 3 on PPC, or something else entirely? > > I note that both Python 3.4 and 3.5 have working PPC installers, > although 3.6 and later do not. > https://www.python.org/downloads/mac-osx/ Ah, ok. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ottava signs
Malte Meyn writes: > Am 11.10.19 um 15:13 schrieb foxfanfare: >> Hi Malte, this sounds really terrific, thank you very much for your work. >> How could I test it or include your patch in my score presently? Should I >> wait for a new release of lilypond (2.19.83)? > > You could either compile LilyPond yourself or wait for the release of > 2.21.0. But I have no idea when that will be … I don’t think that > these patches will be cherry-picked to 2.19.84. A week ago I was at the burial of a good friend and orchestra member. That was pretty distracting. We currently have a hord of house guests making it a bit tricky to focus. While I tend to do most of my work at night anyway, my sleep schedule is a bit messed up right now. That being said, I should hope that the final cherry-picking phase for 2.19.85 can happen this weekend and I don't think it makes a lot of sense to pull in anything but critical stuff into 2.20 after that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 5583: www_post.py: don't mirror regtest baseline (issue 565170043 by nine.fierce.ball...@gmail.com)
Dan Eble writes: >> On Oct 23, 2019, at 12:36, David Kastrup wrote: >> >> "James Lowe" writes: >> >> Fixes should always be to staging rather than master but I guess that's >> what you meant. It depends on just how old the problem is whether one >> tries to hotfix it. > > Baselines created after this commit (a few back from the current tip > of master) will create out-test-baseline/share as a symlink. > > 0d7744aad0 Issue 5572/1: Compile modified C++ files automatically before > testing > — > Dan I've no qualified opinion about this one. If you think it's messing up current testing, feel free to push the fix to staging without waiting for count-down etc (I doubt there will be much further feedback) if you are reasonably confident that this will address it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 5583: www_post.py: don't mirror regtest baseline (issue 565170043 by nine.fierce.ball...@gmail.com)
"James Lowe" writes: > Hello, > > On Wed, 23 Oct 2019 06:39:24 -0700, nine.fierce.ball...@gmail.com wrote: > >> Reviewers: , >> >> Description: >> https://sourceforge.net/p/testlilyissues/issues/5583/ >> >> I ran into a problem running "make ... doc" today, where www_post was >> trying unsuccessfully to mirror a symlink in an out-test-baseline >> subdirectory. > > OK good, it wasn't just me. I hit this today but as I am at work I > didn't get time to look and was planning this evening. > > I am not sure which commit this was but normally we should revert it > right? NOt just patch over it in master? Fixes should always be to staging rather than master but I guess that's what you meant. It depends on just how old the problem is whether one tries to hotfix it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace deprecated functions from string module (issue 566920044 by jonas.hahnf...@gmail.com)
jonas.hahnf...@gmail.com writes:
> Reviewers: Malte Meyn,
>
> Message:
> On 2019/10/23 21:22:16, Malte Meyn wrote:
>> For someone who doesn’t know python two questions come up:
>
>> 1. Why do you sometimes use " " and sometimes ' '?
>
> AFAIK there is no difference between the two ways of writing a constant
> string (or not relevant here), so I've tried to stay consistent with the
> surrounding code.
>
>> 2. Is a space (" " or ' ') the default for the old string.join? Or
> should you
>> use an empty string ("".join()) instead in some places of the new
> version?
>
> A space is the old default. I quoted the relevant documentation in the
> commit message of the separate patches I posted in the issue, but
> unfortunately this is lost when uploading for review here :-(
git cl upload allows you to edit the message. You can edit in a
suitably edited version of git log (typically I put something like
Contains commits:
at the end of the principal text and then a lightly edited list of
reverse commit messages)
Tastes differ, but one has the opportunity to give more information.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Replace deprecated functions from string module (issue 566920044 by jonas.hahnf...@gmail.com)
jonas.hahnf...@gmail.com writes: > On 2019/10/24 07:36:50, dak wrote: > >> git cl upload allows you to edit the message. You can edit in a >> suitably edited version of git log (typically I put something like >> Contains commits: at the end of the principal text and then a lightly >> edited list of reverse commit messages) > >> Tastes differ, but one has the opportunity to give more information. > > Yeah, messed this up I guess. I had expected that I only entered the > cover description and that the separate commits would be uploaded as > sub-revisions or something. Will pay more attention in the future. That would be a reasonable expectation given a Git-centric project tool. But we are working with some Google tools on a code review site created for Subversion and have migrated the Google code part more or less to SourceForge as a stopgap measure before managing self-hosting on the Free version of its software, a step that we never managed due to a lack of manpower and ongoing resource needs. All the while having the repository itself on Savannah. So it turns out that a few things that would be obvious candidates for automation just aren't up to scratch. On the plus side, "messed this up" seems way overblown for "didn't score a perfect 10 in a quagmire I got into for the first time". Our procedures tend to avoid annoying more than one person at a time, so it's pretty uncommon that tempers flare up. > https://codereview.appspot.com/566920044/ -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [gnu.org #1443339] Re: Fyi: this list, lilypond-devel, just had it's subject [tag] and footer removed
"Ian Kelling via RT" writes: > On Thu Oct 24 22:56:44 2019, andrew.bern...@gmail.com wrote: >> See my post re this on the User list. >> >> Andrew > > Sorry, I'm short on time today, I would like to reply directly to > lilypond-user, if you could let them know that, perhaps the footer or > header setting for lilypond-user was just some whitespace that mailman > was ignoring, because I don't see any change either. Munging was > unnecessary in that case, so this is just a purely good change to stop > unnecessarily munging. I think there was a footer: lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel that is now gone. -- David Kastrup
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
James writes: > On 26/10/2019 09:37, Jonas Hahnfeld wrote: >> >> I already debugged this, and assuming you don't have tidy installed (I >> don't have either), please apply >> https://sourceforge.net/p/testlilyissues/issues/5586/ first. >> >> Regards, >> Jonas > > Sorry, I don't care. > > I still cannot do make-check this morning based on current master. I have no idea why the problem is only being discussed instead of fixed, but I'll revert commit 911788f173eb58438fc9c850a005638d053b8bba Author: Dan Eble Date: Thu Oct 17 18:17:44 2019 -0400 Issue 5578: add a button to flip between old and new regtest images now so that people can figure out what to do without the development process being blocked further. Expect my patchy-staging to finisn in about 45 minutes. -- David Kastrup
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
Werner LEMBERG writes: >>> I still cannot do make-check this morning based on current master. >> >> I have no idea why the problem is only being discussed instead of >> fixed, but I'll revert >> >> commit 911788f173eb58438fc9c850a005638d053b8bba >> Author: Dan Eble >> Date: Thu Oct 17 18:17:44 2019 -0400 >> >> Issue 5578: add a button to flip between old and new regtest images >> >> now so that people can figure out what to do without the development >> process being blocked further. >> >> Expect my patchy-staging to finisn in about 45 minutes. > > Hmm. I now get > > PYTHONPATH=[...] \ > PATH=[...] \ > python2 \ > test-lily/rsync-test.py \ > --version-file=[...] > --output-distance=[...] > --test-dir=uploads/webtest \ > --gub-target-dir=/.../gub/target/linux-64 > File ".../scripts/build/output-distance.py", line 913 > 's' if len(paired) != 1 else '')) >^ > SyntaxError: invalid syntax > > while running gub with lilypond's current master branch (commit > fd1734364). Looks like a Python3-ism (or at least some newer version Pythonism) in commit 306fc6b509a9e71e16d54e11d11d70968aa4c3ef Author: Dan Eble Date: Wed Oct 16 18:51:34 2019 -0400 Issue 5576: make output-distance less verbose by default which would be an independent problem. I'll try reverting this one as well and hope that we don't get into a dependency hell for that. -- David Kastrup
