Re: Huge PDF doc files
>> compiling the documentation of current git I get huge PDFs. For >> example, the NR is now 44.7MByte – previously (in my case two months >> ago), it was 7MByte. > > I can see the 44M number here, but I have extractpdfmark > disabled. Can you confiirm it is being run? It is, definitely. The very problem seems to be that the PDF snippets in 'lybook-db' are no longer created with `-dgs-never-embed-fonts=#t`. As a consequence, the new PDF file of the NR contains 3721 fonts, while the old one only has 74 fonts. Werner
Re: [RFC] Use GitLab Milestones
On 6/23/20, Jonas Hahnfeld wrote: > I knew that description and, honestly, that would be a show stopper for > me reporting any issue to a project in 2020. Why? Because mailing lists are a thing of the past in your view? :-) Sending an e-mail to an open mailing list is much more universal and accessible than requiring a GitLab subscription (which mandates to go through at least one if not several Google ReCaptchas, is blocking some public proxies and Tor nodes, etc.). It’s simple enough: we don’t forbid anyone from opening issues directly on the tracker, but we do discourage it because most of the time it turns to be either not a bug (LilyPond is a complex program with its fair share of unexpected or inconsistent behaviors) or an already known bug (and with 6000 tracker pages of which more than 1000 are still open, finding duplicates is actually pretty difficult for a newcomer). Besides, going through the bug list allows users to interact with knowledgeable people who (unlike on -user) are used to turning a large example into a minimal one, to translating layman terms into LilyPond jargon that the devs are more likely to be familiar with, etc. Look for example at this recent issue opened directly on the tracker, and compare the original report (which I had to re-label and edit because of a Markdown syntax error) with the comment I left: https://gitlab.com/lilypond/lilypond/-/issues/6004 On the Google tracker (IIRC), any new issue was automatically given the label Status::New. That doesn’t seem to be the case here, so there *could* be an argument that “unlabelled” should be the new “Status::New”. I don’t like it that much (ideally, “Status” should behave like “Patch” and follow a predictable sequence of states, from “New” to “Verified”) but if that’s technically more convenient, why not. Cheers, -- V.
Re: Texinfo - manual line breaks in URLs?
Am 22.06.2020 um 20:26 schrieb Werner LEMBERG: This looks strange. The red version is the newer one, right? What I see is that the URLs are broken in the middle of lines, leaving huge gaps to the right margin. This looks extremely ugly. The index changes look fishy, too: Everything typeset in typewriter is indented incorrectly by a space. Regarding this one: My new best friend git-bisect says that http://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=0539d4e685a2185dd46d676d0b3f8862493bf8bd introduced the misaligned index entries, which seems reasonable to me (being a TeX-newbie...) Maybe this interferes with the definitions in common-macros.itexi that you already mentioned in your patch... Cheers, Michael
Re: Parsing JSON in C++
There are just three files, so I'll go ahead and put them in flower/. One more minor thing--the files are .cpp and .h, which is a bit confusing given they're not our standard extensions. Is it all right if I change the extensions to .cc and .hh to match the rest of the files? Thanks, Owen On Tue, Jun 23, 2020 at 12:39 PM Han-Wen Nienhuys wrote: > On Tue, Jun 23, 2020 at 9:55 AM Jonas Hahnfeld via Discussions on > LilyPond development wrote: > > > > Am Montag, den 22.06.2020, 16:44 -0700 schrieb Owen Lamb: > > > Thanks, everyone! It looks like jsoncpp should work well for LilyPond. > > > > > > I don't have experience with adding files from one project to another. > > > Jonas, is this "Amalgamated" procedure what you were describing? > > > > https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated-(Possibly-outdated) > > > > Yes, that's what I did a few years back. I think there used to be > > amalgamated versions of the releases, not sure if they vanished or I'm > > just mistaken. In any case, I'd recommend using version 1.8.4; 1.9.x > > will eventually lead to version 2.0, but the developers are not there > > yet. > > > > > > > If so, when instructions say to add the generated files to one's > project, > > > does that mean to just copy them into the lilypond-git directory > somewhere? > > > > Pretty much that, yes. > > > > > Where would be a good place to put them? > > > > No clue. Historically, that sounds like a job for flower/, but I'm not > > a fan of the current split between flower/ and lily/. Please get > > opinions from other developers that have been involved longer than me. > > How many files are they? > > If there are many of them, we should have a separate subdirectory. If > it's just a few, flower/ would be a good place. > > -- > Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen >
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 10:26 PM Carl Sorensen wrote: > On Tue, Jun 23, 2020 at 2:18 PM Paolo Prete wrote: > > > > > > (Also in response to Carl) > > In Italy, we call this approach "fare la morale". > > C's answer made P's words look like: > > > > "Hey, please develop this for me." And the answer was, more or less > (---> do the moral): > > "If you want it to develop, collect the money." > > > > I'm sorry I gave that impression. I did not intend to do so. > > > No problem. > > > > I must have misinterpreted your words. I considered your words to say > that if nobody responded to your post, the thread would be wasted. > > I don't believe anybody that I'm aware of right now is likely to jump > on changing pedals from TextScript to TextSpanner, so I don't think > anything is likely to come from your request in the near future. I > was merely trying to keep you from being disappointed when nobody took > up the issue. > > Now I see the issue. I thought that overriding the function was trivial for the developer of that part, then I wrote my memo. Your words prevent me too to analyze/hack the chain of overrides, it would be too long. At the current state, then, I don't see at the moment any better solution than Pierre's one, having care to include a hidden pedal so to not corrupt the midi (again: I gently ask Harm if he can add a two-words-warning to the snippet, so that other users won't have a surprise)
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 10:32 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > I don't understand what you mean exactly, in the choral pieces. > > A cappella choral pieces don’t include piano music, and therefore don’t > include any piano pedal markings, and therefore don’t use or need the > feature you’re describing — therefore, they are one of the [uncountable!] > number of scores that are counterexamples to your claim that this feature > is "an essential feature for any score". > > Hi Kieren, This observation is pleonastic. When I wrote "any score" I intended the context of the thread (cuationary pedals on brackets). Words must always be interpreted on the basis of what the context suggests. > > I would estimate that I see cautionary markings in less than 50% of the > [professional, published] scores in which the only pedal used is the > sustain pedal. And of course, if no pedal brackets are used (e.g., if the > piece simply states "Ped ad lib." or something similar), the feature you > describe is again unnecessary/unessential. > > Of course the thread was about a cautionary pedal on a bracket, as the snippets show, and I am not aware of scores that do not use it. Could you point out some of them? (In any case it would be a *really* bad editorial practice) Best, P
Re: [RFC] Use GitLab Milestones
On Tue, Jun 23, 2020 at 2:25 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen: > > Accepted: the Bug Squad added it, or reviewed the item. > > Started: a contributor is working on a fix. Owner should change to be > > this contributor. > > > > Closed issues: > > > > Invalid: issue should not have been added in the current state. > > Duplicate: issue already exists in the tracker. > > Fixed: a contributor claims to have fixed the bug. The Bug Squad > > should check the fix with the next official binary release (not by > > compiling the source from git). Owner should be set to that > > contributor. > > Verified: Bug Squad has confirmed that the issue is closed. This means > > that nobody should ever need look at the report again – if there is > > any information in the issue that should be kept, open a new issue for > > that info. > > Which one of those would apply to an issue like > https://gitlab.com/lilypond/lilypond/-/issues/6000 ? > My guess is that it should be Accepted. It's a real issue, not an imaginary one. I believe that the proper fix for this issue is to make our configuration check for fontforge see whether python scripting is enabled, and if not, to generate a message informing the user of that fact. I don't think it's fixed, because it's easy to set up a system with FontForge not having python scripting enabled. But that's just my opinion. Thanks, Carl
Re: Pedal cautionary after a line break (current status and improvements)
Hi Paolo, > I don't understand what you mean exactly, in the choral pieces. A cappella choral pieces don’t include piano music, and therefore don’t include any piano pedal markings, and therefore don’t use or need the feature you’re describing — therefore, they are one of the [uncountable!] number of scores that are counterexamples to your claim that this feature is "an essential feature for any score". > But be sure that for any keyboard piece, not having the cautionary pedal > makes the score unpresentable, and not only when there are multiple spanners. I would estimate that I see cautionary markings in less than 50% of the [professional, published] scores in which the only pedal used is the sustain pedal. And of course, if no pedal brackets are used (e.g., if the piece simply states "Ped ad lib." or something similar), the feature you describe is again unnecessary/unessential. Summary: I’m pointing out that you are making sweeping generalizations that are easily disproven. The strength of your request/argument is likely not well-served by over-exaggeration. Simply state the [true and scope-limited] use case, and move on. Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 2:18 PM Paolo Prete wrote: > > > > (Also in response to Carl) > In Italy, we call this approach "fare la morale". > C's answer made P's words look like: > > "Hey, please develop this for me." And the answer was, more or less (---> do > the moral): > "If you want it to develop, collect the money." > I'm sorry I gave that impression. I did not intend to do so. In fact, your collecting money would have no affect on my desire to work on this issue. > This is absolutely the opposite of my intentions. > Instead, I pointed out that the lack of a cautionary pedal is not simply > something that can be improved. And I have no problem using ugly workaround > to solve it (I'm in control of my code). > Instead, it is a general problem that makes the pedal ** unusable *** in any > professional score. > And it's not a problem for me, but it's a problem especially for novice users. > > In any case, I reported the problem to the developers. Just as I reported to > Harm that there is an error on the snippet's Midi. > They will decide what to do, according to the time they can or want to > dedicate to the thing. > I must have misinterpreted your words. I considered your words to say that if nobody responded to your post, the thread would be wasted. I don't believe anybody that I'm aware of right now is likely to jump on changing pedals from TextScript to TextSpanner, so I don't think anything is likely to come from your request in the near future. I was merely trying to keep you from being disappointed when nobody took up the issue. Again, I am sorry for sounding harsh and polemical. I certainly did not intend to. Carl
Re: [RFC] Use GitLab Milestones
Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen: > On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > > > Hi, > > > > > Actually, I think the while Status family of scoped labels will no longer > > > need to exist. Status::Fixed and Status::Verified are replaced as above. > > > In addition, assigning issues should replace Status::Started (this > > > provides > > > an additional piece information, the person who started working). > > > Status::Duplicate > > > and Status::Invalid should be moved to Type (we already have a > > > Type::Invalid). One > > > remaining question is about the difference between Status::New and > > > Status::Accepted. > > > I don't really know what should be done about it. > > > > Never understood the difference between Started and Accepted either. > > But removing them requires a bit more thought than that. > > > > Jonas > > > > From the Contributors' Guide: > > Open issues: > > New: the item was added by a non-member, despite numerous warnings not > to do this. Should be reviewed by a member of the Bug Squad. I knew that description and, honestly, that would be a show stopper for me reporting any issue to a project in 2020. > Accepted: the Bug Squad added it, or reviewed the item. > Started: a contributor is working on a fix. Owner should change to be > this contributor. > > Closed issues: > > Invalid: issue should not have been added in the current state. > Duplicate: issue already exists in the tracker. > Fixed: a contributor claims to have fixed the bug. The Bug Squad > should check the fix with the next official binary release (not by > compiling the source from git). Owner should be set to that > contributor. > Verified: Bug Squad has confirmed that the issue is closed. This means > that nobody should ever need look at the report again – if there is > any information in the issue that should be kept, open a new issue for > that info. Which one of those would apply to an issue like https://gitlab.com/lilypond/lilypond/-/issues/6000 ? Jonas > > HTH, > > Carl > signature.asc Description: This is a digitally signed message part
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 10:13 PM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > This issue is not *important for me*. It is an *essential* feature for > any score. > > At best, one could argue that it‘s "an essential feature" for any score > with multiple pedal spanners [of different types] that cross line breaks. > It’s demonstrably false that it’s "an essential feature" for any score — > any a cappella choir piece is a counterexample to the claim. > > Therefore, it’s effectively not important to anyone who doesn’t engrave > keyboard music with multiple pedal spanners [of different types] that cross > line breaks. > > Hi Kieren, I don't understand what you mean exactly, in the choral pieces. But be sure that for any keyboard piece, not having the cautionary pedal makes the score unpresentable, and not only when there are multiple spanners. Cheers, P
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 9:53 PM Jean Abou Samra wrote: > Paolo, > > > I really think Carl did not intend to be harsh. He even explicitely tried > to > avoid making you taking it as an offence: > > > I'm trying not to be mean in this answer, but to explain the way > > LilyPond development works. > > It is a confusion in my eyes. Look, > > If you really want this worked on, here are a few ideas: > Carl told you what you needed in the gentlest possible way. Written > communication tends to be ambiguous, but I assure you, Carl is > really not the kind of person that could reply brutally. > > Best, > Jean > (Also in response to Carl) In Italy, we call this approach "fare la morale". C's answer made P's words look like: "Hey, please develop this for me." And the answer was, more or less (---> do the moral): "If you want it to develop, collect the money." This is absolutely the opposite of my intentions. Instead, I pointed out that the lack of a cautionary pedal is not simply something that can be improved. And I have no problem using ugly workaround to solve it (I'm in control of my code). Instead, it is a general problem that makes the pedal ** unusable *** in any professional score. And it's not a problem for me, but it's a problem especially for novice users. In any case, I reported the problem to the developers. Just as I reported to Harm that there is an error on the snippet's Midi. They will decide what to do, according to the time they can or want to dedicate to the thing.
Re: Pedal cautionary after a line break (current status and improvements)
Hi Paolo, > This issue is not *important for me*. It is an *essential* feature for any > score. At best, one could argue that it‘s "an essential feature" for any score with multiple pedal spanners [of different types] that cross line breaks. It’s demonstrably false that it’s "an essential feature" for any score — any a cappella choir piece is a counterexample to the claim. Therefore, it’s effectively not important to anyone who doesn’t engrave keyboard music with multiple pedal spanners [of different types] that cross line breaks. Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info
Re: [RFC] Use GitLab Milestones
On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote: > > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > > Hi, > > Actually, I think the while Status family of scoped labels will no longer > > need to exist. Status::Fixed and Status::Verified are replaced as above. > > In addition, assigning issues should replace Status::Started (this provides > > an additional piece information, the person who started working). > > Status::Duplicate > > and Status::Invalid should be moved to Type (we already have a > > Type::Invalid). One > > remaining question is about the difference between Status::New and > > Status::Accepted. > > I don't really know what should be done about it. > > Never understood the difference between Started and Accepted either. > But removing them requires a bit more thought than that. > > Jonas > >From the Contributors' Guide: Open issues: New: the item was added by a non-member, despite numerous warnings not to do this. Should be reviewed by a member of the Bug Squad. Accepted: the Bug Squad added it, or reviewed the item. Started: a contributor is working on a fix. Owner should change to be this contributor. Closed issues: Invalid: issue should not have been added in the current state. Duplicate: issue already exists in the tracker. Fixed: a contributor claims to have fixed the bug. The Bug Squad should check the fix with the next official binary release (not by compiling the source from git). Owner should be set to that contributor. Verified: Bug Squad has confirmed that the issue is closed. This means that nobody should ever need look at the report again – if there is any information in the issue that should be kept, open a new issue for that info. HTH, Carl
Re: Pedal cautionary after a line break (current status and improvements)
Paolo, Le 23/06/2020 à 21:32, Paolo Prete a écrit : On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen wrote: Paolo, On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote: 2) Considering that a Pedal cautionary is *essential* in *every* serious score, I really encourage the developers to fix this in the development branch. I forward this post to the devel ml. There is no way to "encourage the developers to fix this". The developers are all volunteers, and work on what they find interesting. [CUT.] I don't agree at all. Please don't use harsh words without a reason. I know the workflow of open source projects very well. For years and as an active volunteer. What I meant with "encouraging" is simply: "consider that a cautionary pedal is *essential* for *any* professional score". This simply means that the fact that a cautionary pedal is essential may have simply been left out casually, and consequently I find it useful to remember it. Of course then it will be the reader's decision to consider what I write. If it is taken into consideration, I will be happy. If it is not taken into consideration, it is okay as well, and I will find an alternative solution. Again: please, stop using harsh/polemic words without a reason. I really think Carl did not intend to be harsh. He even explicitely tried to avoid making you taking it as an offence: I'm trying not to be mean in this answer, but to explain the way LilyPond development works. It is a confusion in my eyes. Look, If you really want this worked on, here are a few ideas: Carl told you what you needed in the gentlest possible way. Written communication tends to be ambiguous, but I assure you, Carl is really not the kind of person that could reply brutally. Best, Jean
Re: Huge PDF doc files
Am 23.06.2020 um 21:30 schrieb Han-Wen Nienhuys: On Tue, Jun 23, 2020 at 8:44 PM Werner LEMBERG wrote: Folks, compiling the documentation of current git I get huge PDFs. For example, the NR is now 44.7MByte – previously (in my case two months ago), it was 7MByte. Then I used gs 9.21, now I use version 9.52; I guess this is the culprit since I don't think that any other program in my environment has changed. Can anyone confirm my observations? Masamichi-san? I can see the 44M number here, but I have extractpdfmark disabled. Can you confiirm it is being run? My NR is 44MByte, too, with gs 9.26 and extractpdfmark enabled. (At least I have *.pdfmark residual files in out-www and would thus deduce that it has been run...) Interesting, however, is that compiling the NR with a simple texi2pdf run gives only 40MByte size for me. Seems that extractpdfmark does not give a reduction in size here Cheers, Michael
Re: [RFC] Use GitLab Milestones
Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra: > Hi, > > Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit : > > Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave: > > > On 6/22/20, Jonas Hahnfeld wrote: > > > > In short, I'd like to propose that we replace the labels Fixed_x_y_z > > > > with milestones x.y.z and use these to track which issues were fixed > > > > for a particular release. This has the advantage of a) less labels > > > > which makes the drop-downs more usable and b) the possibility to close > > > > milestones. After all, we're not going to fix bugs in already released > > > > versions and they don't need to be available for new issues. > > > > […] > > > > Also deleting the labels stays manual to make sure that the scripts > > > > correctly assigned the milestones and did not miss any. Help on this > > > > part would be appreciated after running the scripts > > Of course. It's a very nice idea. > > Are we really going to delete all Fixed_X_Y_Z labels by hand though? > I believe that a second script could help achieve that, after we carefully > ensured that the first script setting milestones worked correctly. "carefully ensuring" means going through all labels. Whether we just delete them once verified or defer that to a script shouldn't make much of a difference. Except that we don't need a script. > > > Sounds good. I only have a few questions: > > > > > > - How do you plan to indicate backports? (Granted, this is a very > > > limited subset.) > > > > Yes, that's the question for the 277 issues with at least two labels. > > I'd argue that we're interested in the first released version. So maybe > > just removing the unstable release? > > Sounds reasonable. That was Trevor's opinion too, if I remember well > (I don't have time to search the archives, though, but I recall it has > been discussed already). > > > - What would become the process of marking issues as Fixed/Verified? > > > At what stage do we “close” them? (I’d like to make sure that anything > > > that has been fixed on master will be double-checked once the next GUB > > > release is out; marking the milestone as “closed” wouldn’t offer much > > > granularity in that regard, would it?) > > > > > > - By the way if I understand you correctly, the milestone would be > > > “closed” _prior_ to the release? Then how do we validate bugfixes? > > > > I think we're in confusion here: Closing a milestone does nothing to > > its issues. You just can't assign new issues to the milestone and it > > won't show up in the dropdown. So I think there's no change to issue > > verification, which for me currently means: clarification: for me >as a developer< > > close the issue, set > > Status::Fixed and the version it was fixed in (a milestone). After all > > issues have been assigned, we can close the milestone (probably some > > days after the version has been released). > > I guess you're not on the same wavelength here. My understanding is that > by "validating bugfixes" Valentin means the process outlined in > http://lilypond.org/doc/v2.19/Documentation/contributor/bug-squad-checklists Yes, I was also referring to that. And again, I don't think there's a change in action here except for replacing the labels by milestones. > [...] > > Whether we want to continue to verify issues this way is another question. > Assuming we do, here is how I would envision the process on GitLab: > > - When a merge request adressing an issue is merged, the issue should be > closed. , and add it to a milestone. This makes it easier for the community to see what's part of the release and corresponds to what we've been doing so far. > Verifying issues is done as a precaution, so issues should no longer > appear on > our dashboard once they have been addressed by a merge request. It is > convenient > to set the merge request to close the issue automatically upon merge. > > - When an unstable release is out, we browse all closed issues that do > not have a > milestone, like with > https://gitlab.com/lilypond/lilypond/-/issues?scope=all=closed_title=None > We compile the minimal example given on the tracker page. The bug should be > solved (or the enhancement should be visible), so when we've made sure of > that, we put a milestone on the corresponding issue. This won't work because there will be many issues without a milestone. I think it makes more sense to set the milestone when closing the issue (see above) and afterwards search for issues in Status::Fixed. Again, no change from the current procedure except for adapting the technical implementation. > > Those milestones are closed after we verified all issues for a given > release. > > This obviates the need for the series of labels Status::Fixed, Fixed_X_Y_Z > and Status::Verified, which tends to make things simpler. The new way of > saying Status::Fixed is to close the issue. The way of stating an issue > was verified is to give it a milestone
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 1:32 PM Paolo Prete wrote: > > > > On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen > wrote: >> >> Paolo, >> >> On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote: >> > >> >> > >> > 2) Considering that a Pedal cautionary is *essential* in *every* serious >> > score, I really encourage the developers to fix this in the development >> > branch. I forward this post to the devel ml. >> >> There is no way to "encourage the developers to fix this". The >> developers are all volunteers, and work on what they find interesting. >> > > [CUT.] > I don't agree at all. > Please don't use harsh words without a reason. > I know the workflow of open source projects very well. For years and as an > active volunteer. > What I meant with "encouraging" is simply: "consider that a cautionary pedal > is *essential* for *any* professional score". > This simply means that the fact that a cautionary pedal is essential may have > simply been left out casually, and consequently I find it useful to remember > it. > > Of course then it will be the reader's decision to consider what I write. > > If it is taken into consideration, I will be happy. > > If it is not taken into consideration, it is okay as well, and I will find an > alternative solution. > > Again: please, stop using harsh/polemic words without a reason. I'm sorry my words sounded harsh/polemic to you. I didn't intend them that way. Please help me understand how my words were harsh or polemic, so I can do better in the future. Thanks, Carl
Re: Parsing JSON in C++
On Tue, Jun 23, 2020 at 9:55 AM Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Am Montag, den 22.06.2020, 16:44 -0700 schrieb Owen Lamb: > > Thanks, everyone! It looks like jsoncpp should work well for LilyPond. > > > > I don't have experience with adding files from one project to another. > > Jonas, is this "Amalgamated" procedure what you were describing? > > https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated-(Possibly-outdated) > > Yes, that's what I did a few years back. I think there used to be > amalgamated versions of the releases, not sure if they vanished or I'm > just mistaken. In any case, I'd recommend using version 1.8.4; 1.9.x > will eventually lead to version 2.0, but the developers are not there > yet. > > > > If so, when instructions say to add the generated files to one's project, > > does that mean to just copy them into the lilypond-git directory somewhere? > > Pretty much that, yes. > > > Where would be a good place to put them? > > No clue. Historically, that sounds like a job for flower/, but I'm not > a fan of the current split between flower/ and lily/. Please get > opinions from other developers that have been involved longer than me. How many files are they? If there are many of them, we should have a separate subdirectory. If it's just a few, flower/ would be a good place. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 9:32 PM Jean Abou Samra wrote: > Hi Paolo, > > Le 23/06/2020 à 21:09, Carl Sorensen a écrit : > > Paolo, > > > > On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete > wrote: > >> 2) Considering that a Pedal cautionary is *essential* in *every* serious > >> score, I really encourage the developers to fix this in the development > >> branch. I forward this post to the devel ml. > > There is no way to "encourage the developers to fix this". The > > developers are all volunteers, and work on what they find interesting. > > > > If you really want this worked on, here are a few ideas: > > > > 1) Ask if there are any developers who are willing to do it as work > > for hire. And then either pay the developer or try to get together a > > group of users to collectively pay the developer. > > > > 2) Learn about LilyPond development and provide your own patch. This > > is one of the benefits of open source projects. You can "scratch your > > own itch". > > > > 3) Try to find somebody else who might make the change, either out of > > interest or for money. For example, you might find a computer science > > student at a local school who is interested in music. > I think filling an issue on https://gitlab.com/lilypond/lilypond/ > (with Type::Enhancement) would be a good starting point.This will > sort-of officialize that this feature is desired and create a place > to discuss it. Then, if that issue is really important to you, > This issue is not *important for me*. It is an *essential* feature for any score. If it won't be implemented, then I'll find a way to fix it on myself (and then share the result, as I always did). Best, P >
Re: Pedal cautionary after a line break (current status and improvements)
Hi Paolo, Le 23/06/2020 à 21:09, Carl Sorensen a écrit : Paolo, On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote: 2) Considering that a Pedal cautionary is *essential* in *every* serious score, I really encourage the developers to fix this in the development branch. I forward this post to the devel ml. There is no way to "encourage the developers to fix this". The developers are all volunteers, and work on what they find interesting. If you really want this worked on, here are a few ideas: 1) Ask if there are any developers who are willing to do it as work for hire. And then either pay the developer or try to get together a group of users to collectively pay the developer. 2) Learn about LilyPond development and provide your own patch. This is one of the benefits of open source projects. You can "scratch your own itch". 3) Try to find somebody else who might make the change, either out of interest or for money. For example, you might find a computer science student at a local school who is interested in music. I think filling an issue on https://gitlab.com/lilypond/lilypond/ (with Type::Enhancement) would be a good starting point.This will sort-of officialize that this feature is desired and create a place to discuss it. Then, if that issue is really important to you, you may want to dive into the code for SustainPedal and try to figure out how to add a boolean property to switch on parentheses on cautionary pedal signs. --Or, even better, make pedals spanners, which will solve other issues along the way (e.g., to-barline setting).-- You will certainly get help if you ask questions on the issue. But in order to make something implemented, you generally need to invest resources yourself (that is, energy or, if you want, money). Best, Jean
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 9:09 PM Carl Sorensen wrote: > Paolo, > > On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote: > > > > > > > 2) Considering that a Pedal cautionary is *essential* in *every* serious > > score, I really encourage the developers to fix this in the development > > branch. I forward this post to the devel ml. > > There is no way to "encourage the developers to fix this". The > developers are all volunteers, and work on what they find interesting. > > [CUT.] I don't agree at all. Please don't use harsh words without a reason. I know the workflow of open source projects very well. For years and as an active volunteer. What I meant with "encouraging" is simply: "consider that a cautionary pedal is *essential* for *any* professional score". This simply means that the fact that a cautionary pedal is essential may have simply been left out casually, and consequently I find it useful to remember it. Of course then it will be the reader's decision to consider what I write. If it is taken into consideration, I will be happy. If it is not taken into consideration, it is okay as well, and I will find an alternative solution. Again: please, stop using harsh/polemic words without a reason. P
Re: Huge PDF doc files
On Tue, Jun 23, 2020 at 8:44 PM Werner LEMBERG wrote: > > > Folks, > > > compiling the documentation of current git I get huge PDFs. For > example, the NR is now 44.7MByte – previously (in my case two months > ago), it was 7MByte. > > Then I used gs 9.21, now I use version 9.52; I guess this is the > culprit since I don't think that any other program in my environment > has changed. > > Can anyone confirm my observations? Masamichi-san? I can see the 44M number here, but I have extractpdfmark disabled. Can you confiirm it is being run? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Pedal cautionary after a line break (current status and improvements)
Paolo, On Tue, Jun 23, 2020 at 12:33 PM Paolo Prete wrote: > > > 2) Considering that a Pedal cautionary is *essential* in *every* serious > score, I really encourage the developers to fix this in the development > branch. I forward this post to the devel ml. There is no way to "encourage the developers to fix this". The developers are all volunteers, and work on what they find interesting. If you really want this worked on, here are a few ideas: 1) Ask if there are any developers who are willing to do it as work for hire. And then either pay the developer or try to get together a group of users to collectively pay the developer. 2) Learn about LilyPond development and provide your own patch. This is one of the benefits of open source projects. You can "scratch your own itch". 3) Try to find somebody else who might make the change, either out of interest or for money. For example, you might find a computer science student at a local school who is interested in music. Repeatedly asking for this functionality to be provided on the devel list is not likely to get anything done, and in fact may turn off some developers. I'm trying not to be mean in this answer, but to explain the way LilyPond development works. There is nobody who controls what is to be worked on next -- every developer chooses for themselves what they will do. Thanks, Carl
Re: [RFC] Use GitLab Milestones
Hi, Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit : Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave: On 6/22/20, Jonas Hahnfeld wrote: In short, I'd like to propose that we replace the labels Fixed_x_y_z with milestones x.y.z and use these to track which issues were fixed for a particular release. This has the advantage of a) less labels which makes the drop-downs more usable and b) the possibility to close milestones. After all, we're not going to fix bugs in already released versions and they don't need to be available for new issues. […] Also deleting the labels stays manual to make sure that the scripts correctly assigned the milestones and did not miss any. Help on this part would be appreciated after running the scripts Of course. It's a very nice idea. Are we really going to delete all Fixed_X_Y_Z labels by hand though? I believe that a second script could help achieve that, after we carefully ensured that the first script setting milestones worked correctly. Sounds good. I only have a few questions: - How do you plan to indicate backports? (Granted, this is a very limited subset.) Yes, that's the question for the 277 issues with at least two labels. I'd argue that we're interested in the first released version. So maybe just removing the unstable release? Sounds reasonable. That was Trevor's opinion too, if I remember well (I don't have time to search the archives, though, but I recall it has been discussed already). - What would become the process of marking issues as Fixed/Verified? At what stage do we “close” them? (I’d like to make sure that anything that has been fixed on master will be double-checked once the next GUB release is out; marking the milestone as “closed” wouldn’t offer much granularity in that regard, would it?) - By the way if I understand you correctly, the milestone would be “closed” _prior_ to the release? Then how do we validate bugfixes? I think we're in confusion here: Closing a milestone does nothing to its issues. You just can't assign new issues to the milestone and it won't show up in the dropdown. So I think there's no change to issue verification, which for me currently means: close the issue, set Status::Fixed and the version it was fixed in (a milestone). After all issues have been assigned, we can close the milestone (probably some days after the version has been released). I guess you're not on the same wavelength here. My understanding is that by "validating bugfixes" Valentin means the process outlined in http://lilypond.org/doc/v2.19/Documentation/contributor/bug-squad-checklists , that is, what has recently be done thanks to a crowd-sourced effort: check that every bug claimed fixed was actually fixed in the latest GUB release before marking the issue as "Status::Verified" instead of "Status::Fixed". For patch-tracking issues, it used to be verified that a commit with the right SHA was indeed present in master. Since there isn't any risk with merge requests, I think this part is no longer relevant (while previously someone could have closed the issue while forgetting to push the commit). Whether we want to continue to verify issues this way is another question. Assuming we do, here is how I would envision the process on GitLab: - When a merge request adressing an issue is merged, the issue should be closed. Verifying issues is done as a precaution, so issues should no longer appear on our dashboard once they have been addressed by a merge request. It is convenient to set the merge request to close the issue automatically upon merge. - When an unstable release is out, we browse all closed issues that do not have a milestone, like with https://gitlab.com/lilypond/lilypond/-/issues?scope=all=closed_title=None We compile the minimal example given on the tracker page. The bug should be solved (or the enhancement should be visible), so when we've made sure of that, we put a milestone on the corresponding issue. Those milestones are closed after we verified all issues for a given release. This obviates the need for the series of labels Status::Fixed, Fixed_X_Y_Z and Status::Verified, which tends to make things simpler. The new way of saying Status::Fixed is to close the issue. The way of stating an issue was verified is to give it a milestone indicating the first release it was fixed in. Actually, I think the while Status family of scoped labels will no longer need to exist. Status::Fixed and Status::Verified are replaced as above. In addition, assigning issues should replace Status::Started (this provides an additional piece information, the person who started working). Status::Duplicate and Status::Invalid should be moved to Type (we already have a Type::Invalid). One remaining question is about the difference between Status::New and Status::Accepted. I don't really know what should be done about it. Dan is entirely right: some scoped labels should become non-scoped to make coexistence possible.
Huge PDF doc files
Folks, compiling the documentation of current git I get huge PDFs. For example, the NR is now 44.7MByte – previously (in my case two months ago), it was 7MByte. Then I used gs 9.21, now I use version 9.52; I guess this is the culprit since I don't think that any other program in my environment has changed. Can anyone confirm my observations? Masamichi-san? Werner
Re: Pedal cautionary after a line break (current status and improvements)
On Tue, Jun 23, 2020 at 6:36 PM Pierre Perol-Schneider < pierre.schneider.pa...@gmail.com> wrote: > Hi Paolo, > See: http://lsr.di.unimi.it/LSR/Item?id=1023 > Cheers, > PIerre > > Hi Pierre, I already saw your workaround but, as said in the previous email, it has unwanted side effects. The first one is that no pedal is produced in the midi file. The second one is that the SustainPedal API is skipped, and this leads to messy code. A hidden *real* sustain pedal could be added to your functions (so that the midi file includes it), but this would lead to more huge and messy code. A this point: 1) I gently ask Harm (is Harm the snippet's maintainer ? ) to update the snippet at least by adding a warning (--> something like "no midi is produced") 2) Considering that a Pedal cautionary is *essential* in *every* serious score, I really encourage the developers to fix this in the development branch. I forward this post to the devel ml. Hope this thread will not be wasted and hope to obtain feedback. Thank you all! Best, P
Re: [RFC] Use GitLab Milestones
On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote: >> > Pretty much that: You can only have one label from the same scope, and > assigning a second automatically removes the old (cf. Patch::*). I > actually agree that multiple Type's might be useful. If others are in > favor as well, we can just rename the labels. My default position is to avoid restrictions when there isn't a good reason for them. There are some types in the current set that I can't imagine using together – for example (Enhancement|Maintainability) with (Crash|Defect|Regression) – but unless that endangers the efficiency of someone's workflow, I don't think we should spend time compartmentalizing them. Patch::* obviously need to remain scoped because they name states in a state machine. — Dan
Re: [RFC] Use GitLab Milestones
Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave: > On 6/22/20, Jonas Hahnfeld wrote: > > In short, I'd like to propose that we replace the labels Fixed_x_y_z > > with milestones x.y.z and use these to track which issues were fixed > > for a particular release. This has the advantage of a) less labels > > which makes the drop-downs more usable and b) the possibility to close > > milestones. After all, we're not going to fix bugs in already released > > versions and they don't need to be available for new issues. > > Sounds good. I only have a few questions: > > - How do you plan to indicate backports? (Granted, this is a very > limited subset.) Yes, that's the question for the 277 issues with at least two labels. I'd argue that we're interested in the first released version. So maybe just removing the unstable release? > - What would become the process of marking issues as Fixed/Verified? > At what stage do we “close” them? (I’d like to make sure that anything > that has been fixed on master will be double-checked once the next GUB > release is out; marking the milestone as “closed” wouldn’t offer much > granularity in that regard, would it?) > > - By the way if I understand you correctly, the milestone would be > “closed” _prior_ to the release? Then how do we validate bugfixes? I think we're in confusion here: Closing a milestone does nothing to its issues. You just can't assign new issues to the milestone and it won't show up in the dropdown. So I think there's no change to issue verification, which for me currently means: close the issue, set Status::Fixed and the version it was fixed in (a milestone). After all issues have been assigned, we can close the milestone (probably some days after the version has been released). > > > we should disable notifications of the lilypond project for that time frame. > > OK. To be clear: I'll do this from the project side (there's a global "Disable email notifications" for the project), no need to make any change for your personal notification settings. Jonas > > Cheers, > -- V. > signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
On 6/22/20, Jonas Hahnfeld wrote: > In short, I'd like to propose that we replace the labels Fixed_x_y_z > with milestones x.y.z and use these to track which issues were fixed > for a particular release. This has the advantage of a) less labels > which makes the drop-downs more usable and b) the possibility to close > milestones. After all, we're not going to fix bugs in already released > versions and they don't need to be available for new issues. Sounds good. I only have a few questions: - How do you plan to indicate backports? (Granted, this is a very limited subset.) - What would become the process of marking issues as Fixed/Verified? At what stage do we “close” them? (I’d like to make sure that anything that has been fixed on master will be double-checked once the next GUB release is out; marking the milestone as “closed” wouldn’t offer much granularity in that regard, would it?) - By the way if I understand you correctly, the milestone would be “closed” _prior_ to the release? Then how do we validate bugfixes? > we should disable notifications of the lilypond project for that time frame. OK. Cheers, -- V.
Re: Texinfo - manual line breaks in URLs?
Am 22.06.2020 um 22:55 schrieb Michael Käppler: Am 22.06.2020 um 20:26 schrieb Werner LEMBERG: I'm not sure what the best solution would be... I just put texi2dvi from texinfo git into scripts/build and adjusted stepmake/stepmake/texinfo-rules.make to use it. It works(tm) and is IMHO a cleaner approach than patching texi2dvi. But sure, it has to be maintained, like tex/texinfo.tex. Just to be curious, shat was the reason to bundle texinfo.tex with Lilypond and not rely on the version bundled with texinfo, which is required to build the docs anyway? See the results here: https://drive.google.com/drive/folders/1czVl2glLVoQiUOLu1mvnWh9hozivaPuC?usp=sharing Green color = reference version with texinfo.tex from out repo Red color = version with texinfo.tex from aforementioned commit This looks strange. The red version is the newer one, right? What I see is that the URLs are broken in the middle of lines, leaving huge gaps to the right margin. This looks extremely ugly. Yes, red is new, green is reference. From a quick glance onto my newest build with most recent texinfo, the ugly url breaking has disappeared. Well, it has improved, but it is still strange sometimes. Didn't manage to do the comparisons yet. Changes.pdf was empty, which I could track down: https://gitlab.com/lilypond/lilypond/-/merge_requests/195 Cheers, Michael
Re: [RFC] Use GitLab Milestones
Hi James, Am Dienstag, den 23.06.2020, 08:00 +0100 schrieb James: > Hello > > On 22/06/2020 18:33, Jonas Hahnfeld wrote: > > In short, I'd like to propose that we replace the labels Fixed_x_y_z > > with milestones x.y.z and use these to track which issues were fixed > > for a particular release. > > Just so you know I have just gone through all the 'Fixed_' labels this > morning and they are all consistent now. > > The form is > > Fixed_X_XX_XX > > e.g Fixed _2_04_01 or Fixed_2_19_01 > > There was no consistency for single digit or version 'zero' builds so I > made sure they always had 2 numerals even they were '00' just in case > this helps with find/replace. Okay, didn't notice that one. Do we want to retain this? Right now, I'm parsing integer numbers, so the milestones would be "2.4.1" and "2.19.1" for the two examples above. I think this matches what the releases advertise themselves, but not sure. > > [...] > > > > The bad news is that both creating and assigning a milestone induce > > notifications. We likely don't want to receive 4000 emails when running > > the scripts, so we should disable notifications of the lilypond project > > for that time frame. This means contributions during that period (~30 > > minutes?) might stay under the radar at first, but that's probably > > acceptable. > That's a good idea. Perhaps block all access for that period (can you do > that easily and informatively?). I fear I can't for external contributors, at least not without possibly breaking a bunch of stuff: * Making the whole repo private might disassociate forks. * Not sure what happens to existing MRs if I disable them for the repo. Plus issues have to stay active, that's the point of running the scripts. However, I think disabling notifications leaves the activity stream working (see https://gitlab.com/lilypond/lilypond/activity) and this will only show entries when creating the milestones, ie not when assigning issues. Skipping ~330 entries sounds feasible for checking that nothing was lost, plus you can filter for "Issue events" (new issues) and "Comments". So the whole topic is less bad than I initially thought. > > Let me know what you think! > > There is one thing that I find with the labels (and I don't care either > way) its those of the form > > Type::XXX vs just a normal string > > e.g. Type::Maintainabilty vs just Maintainability. > > You cannot have two labels of Type::XXX on the same issue. So an issue > that was labelled 'Font' AND 'Scripts' in the past, for instance, could > not be both Type::Font AND Type::Scripts. One replaces the other (at > least when I tested it manually). Not exactly related to this one, but I think there was at most one 'Type' on SourceForge as well, so scoped labels looked like the corresponding thing on GitLab. > Is this XXX:: what they call 'scoping'? Anyway, we're a few 'non-scoped' > labels out there and I wonder (apart from the 'Patch::' labels) what the > pros and cons of having a XXX:: label vs just a string. Pretty much that: You can only have one label from the same scope, and assigning a second automatically removes the old (cf. Patch::*). I actually agree that multiple Type's might be useful. If others are in favor as well, we can just rename the labels. Jonas > > James signature.asc Description: This is a digitally signed message part
Re: Parsing JSON in C++
Am Montag, den 22.06.2020, 16:44 -0700 schrieb Owen Lamb: > Thanks, everyone! It looks like jsoncpp should work well for LilyPond. > > I don't have experience with adding files from one project to another. > Jonas, is this "Amalgamated" procedure what you were describing? > https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated-(Possibly-outdated) Yes, that's what I did a few years back. I think there used to be amalgamated versions of the releases, not sure if they vanished or I'm just mistaken. In any case, I'd recommend using version 1.8.4; 1.9.x will eventually lead to version 2.0, but the developers are not there yet. > If so, when instructions say to add the generated files to one's project, > does that mean to just copy them into the lilypond-git directory somewhere? Pretty much that, yes. > Where would be a good place to put them? No clue. Historically, that sounds like a job for flower/, but I'm not a fan of the current split between flower/ and lily/. Please get opinions from other developers that have been involved longer than me. Regards Jonas > > Thanks, > Owen > > On Sat, Jun 20, 2020 at 5:20 AM Noeck < > noeck.marb...@gmx.de > > wrote: > > > > > 1. LilyPond already seems to use some parts of the BOOST library (which > > > > is kind of the extended C++ STL). > > > > > > Not that I know of. > > > > > > > You're right. I just quickly skimmed through a grep and found this: > > > > > > https://github.com/lilypond/lilypond/blob/master/flower/include/yaffut.hh#L2 > > > > > > or a define HAVE_BOOST_LAMBDA in an older version. > > > > Cheers, > > Joram > > > > signature.asc Description: This is a digitally signed message part
Re: [RFC] Use GitLab Milestones
Hello On 22/06/2020 18:33, Jonas Hahnfeld wrote: In short, I'd like to propose that we replace the labels Fixed_x_y_z with milestones x.y.z and use these to track which issues were fixed for a particular release. Just so you know I have just gone through all the 'Fixed_' labels this morning and they are all consistent now. The form is Fixed_X_XX_XX e.g Fixed _2_04_01 or Fixed_2_19_01 There was no consistency for single digit or version 'zero' builds so I made sure they always had 2 numerals even they were '00' just in case this helps with find/replace. This has the advantage of a) less labels which makes the drop-downs more usable and b) the possibility to close milestones. After all, we're not going to fix bugs in already released versions and they don't need to be available for new issues. This topic already surfaced right after the migration to GitLab, but now I finally had the chance to look into this with more detail. In particular we now seem to have a common naming for the labels in question (great work by James!) which makes scripting much more feasible. I've already started to write scripts to create the 328 milestones (that's what they tell me) and automatically assign 3662 issues which have exactly one label of the form mentioned above. Additionally, my scripts think that there are 277 issues with two or more labels (attached to this message). Most are instances of "fix was backported to a stable version", but I'd like to check them manually. Also deleting the labels stays manual to make sure that the scripts correctly assigned the milestones and did not miss any. Help on this part would be appreciated after running the scripts The bad news is that both creating and assigning a milestone induce notifications. We likely don't want to receive 4000 emails when running the scripts, so we should disable notifications of the lilypond project for that time frame. This means contributions during that period (~30 minutes?) might stay under the radar at first, but that's probably acceptable. That's a good idea. Perhaps block all access for that period (can you do that easily and informatively?). Let me know what you think! There is one thing that I find with the labels (and I don't care either way) its those of the form Type::XXX vs just a normal string e.g. Type::Maintainabilty vs just Maintainability. You cannot have two labels of Type::XXX on the same issue. So an issue that was labelled 'Font' AND 'Scripts' in the past, for instance, could not be both Type::Font AND Type::Scripts. One replaces the other (at least when I tested it manually). Is this XXX:: what they call 'scoping'? Anyway, we're a few 'non-scoped' labels out there and I wonder (apart from the 'Patch::' labels) what the pros and cons of having a XXX:: label vs just a string. James
