Re: design decision needed - how to render "Used properties" for markup-(list-)commands
Am 03.01.2021 um 19:44 schrieb Thomas Morley:
Am So., 3. Jan. 2021 um 18:28 Uhr schrieb Michael Käppler :
Am 03.01.2021 um 16:34 schrieb Thomas Morley:
ailing file with us? :)
Attached.
Although not really familar with texinfo I aimed at doing it as
minimal as possible. Likely I miss something ...
'\input texinfo' at the beginning?
Thanks, works!
A meaningful error-message would have been helpfull...
With '\input texinfo' you are tellng TeX that it should load all definitions
from 'texinfo.tex' needed for compiling Texinfo files.
Without that, TeX will understand basically nothing you wrote in your
file, beginning
with the different escape characters ('\' in plain TeX vs. '@' in Texinfo)
So in this case it is pretty hard to give a meaningful error message,
not saying that
TeX would be great in this domain otherwise... ;)
Note that it will load the 'texinfo.tex' from your TeX distribution by
default, which may probably be
a different version that the bundled one from lilypond/tex. This can be
very important for testing.
You can force TeX to use another texinfo.tex by setting the
environmental variable 'TEXINPUTS',
e.g. by doing
export TEXINPUTS=your-path-to-lilypond/tex
before calling TeX.
(using 'export' will set it for the whole shell session, however. Normally,
doing 'TEXINPUTS=your-path-to-lilypond/tex xetex foo.texi' should also work,
I'm not sure how this is with 'texi2pdf', which is basically a shell script)
(Werner, feel free to correct me or provide more insights in this topic...)
Cheers,
Michael
Cheers,
Harm
Re: design decision needed - how to render "Used properties" for markup-(list-)commands
Am So., 3. Jan. 2021 um 18:34 Uhr schrieb Werner LEMBERG :
>
>
> > Used properties (Werner's proposal):
> > @itemize
> > @item @code{number} [default: 3]
> > @item @code{pair} [default: (0 . 0)]
> > @item @code{empty-list} [default: ()]
> > @end itemize
>
> Actually, my suggestion should be formatted like this:
>
> @itemize
> @item @code{number} [default: @code{3}]
> @item @code{pair} [default: @code{(0 . 0)}]
> @item @code{empty-list} [default: @code{()}]
> @end itemize
>
>
> Werner
Ofcourse! Same for Michael's one, I assume.
Cheers,
Harm
Re: design decision needed - how to render "Used properties" for markup-(list-)commands
Am So., 3. Jan. 2021 um 18:28 Uhr schrieb Michael Käppler : > > Am 03.01.2021 um 16:34 schrieb Thomas Morley: > > ailing file with us? :) > > Attached. > > Although not really familar with texinfo I aimed at doing it as > > minimal as possible. Likely I miss something ... > '\input texinfo' at the beginning? Thanks, works! A meaningful error-message would have been helpfull... Cheers, Harm
Re: Releasing 2.22.0
Le 03/01/2021 à 12:05, Jonas Hahnfeld a écrit : Hi all and happy new year 2021 to everyone! A happier new year to everyone ! As there was no real announcement for 2.20.0, I'd rather follow the release of 2.18.0 including a post to info-lilypond. Here's a first draft: OK with me for this new year's gift. Cheers, -- Jean-Charles
Re: design decision needed - how to render "Used properties" for markup-(list-)commands
> Used properties (Werner's proposal):
> @itemize
> @item @code{number} [default: 3]
> @item @code{pair} [default: (0 . 0)]
> @item @code{empty-list} [default: ()]
> @end itemize
Actually, my suggestion should be formatted like this:
@itemize
@item @code{number} [default: @code{3}]
@item @code{pair} [default: @code{(0 . 0)}]
@item @code{empty-list} [default: @code{()}]
@end itemize
Werner
Re: design decision needed - how to render "Used properties" for markup-(list-)commands
Am 03.01.2021 um 16:34 schrieb Thomas Morley: ailing file with us? :) Attached. Although not really familar with texinfo I aimed at doing it as minimal as possible. Likely I miss something ... '\input texinfo' at the beginning? Cheers, Michael
Re: design decision needed - how to render "Used properties" for markup-(list-)commands
Am So., 3. Jan. 2021 um 14:13 Uhr schrieb Michael Käppler :
>
> Am 03.01.2021 um 10:19 schrieb Thomas Morley:
> > Hi,
> Hi Harm,
> > currently https://gitlab.com/lilypond/lilypond/-/merge_requests/588
> > is tagged 'needs design', because there are proposals to change the
> > style how the "Used properties" for markup-(list-)commands should
> > print in NR.
> > I've manually [*] created a html-file to demonstrate the default and
> > the so far made suggestions.
> > See attached.
> >
> > Opinions?
> I would not call this a design decision. For me, a design decision would
> imply
> that you change (or initiate) something with fundamental consequences to
> other parts
> of the software. Something that can not be changed later without a lot
> of effort.
> The formatting we're discussing about can be changed in 5 minutes.
> So I would propose that you just take the style you like most and go on.
> If someone has strong feelings about this, he or she can speak up now.
Indeed, thus I wrote to -devel, not only a comment at gitlab
> >
> > Anyway, MR 588 is more a bugfix. Thus I'd prefer not to entangle a
> > bug-fix with a new design, but to open a new issue or MR for the
> > latter
> +1
> >
> > Thanks,
> >Harm
> >
> > [*] I wrote a short .texi-file and used texi2html.
> > Using texi2pdf aborts. same with texi2any --pdf
> > No clue why.
> Would you mind sharing the failing file with us? :)
Attached.
Although not really familar with texinfo I aimed at doing it as
minimal as possible. Likely I miss something ...
Cheers,
Harm
@settitle Used properties - proposals
Used properties (current behaviour):
@itemize
@item @code{number} (3)
@item @code{pair} ((0 . 0))
@item @code{empty-list} ('())
@end itemize
Used properties (after MR 588):
@itemize
@item @code{number} (3)
@item @code{pair} ((0 . 0))
@item @code{empty-list} (())
@end itemize
Used properties (Werner's proposal):
@itemize
@item @code{number} [default: 3]
@item @code{pair} [default: (0 . 0)]
@item @code{empty-list} [default: ()]
@end itemize
Used properties (Michael's proposal):
@itemize
@item @code{number}, default: 3
@item @code{pair}, default: (0 . 0)
@item @code{empty-list}, default: ()
@end itemize
@bye
Re: Releasing 2.22.0
Am 03.01.2021 um 12:05 schrieb Jonas Hahnfeld: Hi all and happy new year 2021 to everyone! Wishing you the same and thanks for your work on LilyPond! There were no bug reports for 2.21.82 and no other Critical issue that I'm aware of. While there are a few changes that could be backported (I tried to label the MRs at GitLab), I think we should release the current state as 2.22.0. More bug fixes can follow in future versions. I'll finalize the branch later today (merge translation, bump version numbers, add a convert rule for the stable version) and then would like to ask Phil to build the binaries using GUB. Once they're uploaded, it may be prudent to test that they work the same as the previous release candidates before announcing the new stable version. Sounds good! Thanks, Michael
Re: Releasing 2.22.0
Am 03.01.2021 um 14:22 schrieb Han-Wen Nienhuys: On Sun, Jan 3, 2021 at 12:06 PM Jonas Hahnfeld wrote: There were no bug reports for 2.21.82 and no other Critical issue that I'm aware of. While there are a few changes that could be backported (I tried to label the MRs at GitLab), What is the label to look for? Label = ~Backport. Cheers, Michael
Re: Releasing 2.22.0
Am Sonntag, dem 03.01.2021 um 14:22 +0100 schrieb Han-Wen Nienhuys: > On Sun, Jan 3, 2021 at 12:06 PM Jonas Hahnfeld wrote: > > There were no bug reports for 2.21.82 and no other Critical issue that > > I'm aware of. While there are a few changes that could be backported (I > > tried to label the MRs at GitLab), > > What is the label to look for? "Backport"; at the moment there are four (already merged): https://gitlab.com/lilypond/lilypond/-/merge_requests?scope=all=%E2%9C%93=merged_name[]=Backport signature.asc Description: This is a digitally signed message part
Re: Releasing 2.22.0
>> Hi all and happy new year 2021 to everyone! > > happy new year to everyone, and I hope everyone is healthy and safe. I wish the same :-) >> There were no bug reports for 2.21.82 and no other Critical issue >> that [..] > > Sounds good to me +1 Werner
Re: Would like to develop
Relying all this time: Right but brew is much more popular and would therefore drive more developers in (Or advance users) I remember installing macports on a previous mac just for this, and I agree it worked. I have been reading and reproducing the build process this week (I used docker for Mac instead of the other option) and I got to say it's pretty involved and wished it was simpler, and I'm saying this as a professional programmer. I'll have to dig deeper to see if there's anything I can help about that > On 3 Jan 2021, at 12:06, Jahrme Risner wrote: >
Re: Releasing 2.22.0
On Sun, Jan 3, 2021 at 12:06 PM Jonas Hahnfeld wrote: > There were no bug reports for 2.21.82 and no other Critical issue that > I'm aware of. While there are a few changes that could be backported (I > tried to label the MRs at GitLab), What is the label to look for? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Releasing 2.22.0
On Sun, Jan 3, 2021 at 12:06 PM Jonas Hahnfeld wrote: > Hi all and happy new year 2021 to everyone! happy new year to everyone, and I hope everyone is healthy and safe. > There were no bug reports for 2.21.82 and no other Critical issue that > [..] Sounds good to me Thanks for leading the way with the release! -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: design decision needed - how to render "Used properties" for markup-(list-)commands
Am 03.01.2021 um 10:19 schrieb Thomas Morley: Hi, Hi Harm, currently https://gitlab.com/lilypond/lilypond/-/merge_requests/588 is tagged 'needs design', because there are proposals to change the style how the "Used properties" for markup-(list-)commands should print in NR. I've manually [*] created a html-file to demonstrate the default and the so far made suggestions. See attached. Opinions? I would not call this a design decision. For me, a design decision would imply that you change (or initiate) something with fundamental consequences to other parts of the software. Something that can not be changed later without a lot of effort. The formatting we're discussing about can be changed in 5 minutes. So I would propose that you just take the style you like most and go on. If someone has strong feelings about this, he or she can speak up now. Anyway, MR 588 is more a bugfix. Thus I'd prefer not to entangle a bug-fix with a new design, but to open a new issue or MR for the latter +1 Thanks, Harm [*] I wrote a short .texi-file and used texi2html. Using texi2pdf aborts. same with texi2any --pdf No clue why. Would you mind sharing the failing file with us? :) Cheers, Michael
Re: Would like to develop
On Thu, Dec 31, 2020 at 15:57, Sven Axelsson wrote: > On Thu, 31 Dec 2020 at 21:59, Jonas Hahnfeld wrote: > >> Interesting, the brew formula uses the pre-built binaries which are 32- >> bit only (due to licensing issues, see below): >> https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/lilypond.rb >> That's more of a packaging issue in brew, LilyPond should build fine >> with Clang since a year or so. IMHO the formula should be updated to >> build from source. >> > > That's the Homebrew Cask formula. Those do not build anything, they just > install pre-built applications. The Brew formula for lilypond was removed > some years ago because it needed Guile 1.6 and at that time Homebrew did > not support multiple versions of the same library. That is no longer a > problem and in addition, Homebrew now has a buildbot that automatically > produces binaries for multiple OS and CPU versions ( > https://docs.brew.sh/Bottles). So, it would be a good thing to update the > Brew formula and get it back into Homebrew. A while back I had been playing with the idea of getting LilyPond building with HomeBrew and what I had at that point is available at https://github.com/Jahrme/homebrew-lilypond. In addition to the Guile issue already mentioned, last I checked HomeBrew dependencies on anything LaTeX related were not well supported. In the end, I’ve moved to using MacPorts instead of HomeBrew so I haven’t kept the release current and I’m sure it would need some work. As has been mentioned, MacPorts builds 64-bit binaries (I believe even on the new M1 Macs) and is kept pretty much up to date for new LilyPond releases. There has been a fair amount of work done to slim down the list of dependencies needed, and I still think that with a bit of effort MacPorts could be used to produce redistributable .pkg installers of a reasonable size. Best, Jahrme > -- > Sven Axelsson > ++[>++>+++>++>++ >><-]>.+..>+.>+.<<-.>>+.>.<<. > +++.>-.<<++.>>.<++.>>>++..>>.<.
Releasing 2.22.0
Hi all and happy new year 2021 to everyone! There were no bug reports for 2.21.82 and no other Critical issue that I'm aware of. While there are a few changes that could be backported (I tried to label the MRs at GitLab), I think we should release the current state as 2.22.0. More bug fixes can follow in future versions. I'll finalize the branch later today (merge translation, bump version numbers, add a convert rule for the stable version) and then would like to ask Phil to build the binaries using GUB. Once they're uploaded, it may be prudent to test that they work the same as the previous release candidates before announcing the new stable version. As there was no real announcement for 2.20.0, I'd rather follow the release of 2.18.0 including a post to info-lilypond. Here's a first draft: --- We are proud to announce the release of GNU LilyPond 2.22.0. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version includes improvements and fixes since the branching of the previous stable release in August 2017 (even though the final 2.20.0 was only released in March 2020). A list of added features and other user-visible changes can be found at http://lilypond.org/doc/v2.22/Documentation/changes/index.html Behind the scenes, this release switches to Python 3 and includes a number of performance improvements that should be noticeable for larger scores. --- Let me know what you think! Jonas signature.asc Description: This is a digitally signed message part
Re: state of the ’Pond for earnest tadpoles
Hello On 02/01/2021 16:58, Thomas Morley wrote: Am Sa., 2. Jan. 2021 um 14:41 Uhr schrieb James : On 02/01/2021 12:20, Thomas Morley wrote: A full `make doc` takes hours for me, even if invoked with `make doc -j5 CPU_COUNT=5` Thus I hardly do so, but use the CG-documented methods: Hours? Really? Perhaps 'an hour' if you were using some very, very old CPU - but even using a single CPU on an 'old' i5 Intel system a full make doc for me took less than 50 mins. That last time it took longer than an hour was when I had an old (8+ years ago) iMac running make doc in a linux VM. James time make doc -j5 CPU_COUNT=5 -> real77m53,168s user204m51,501s sys28m57,342s Ok, hours was not exactly correct, but significant more than one hour Cheers, Harm I don't mean to flog this dead horse, but I was curious. I did a make doc with one cpu on my laptop (it has an i7 7700HQ CPU - circa 2017) and while I don't have the exact numbers to hand, as I am currently at work, it was something like real: 45m user:55m (cannot recall sys values), my desktop before that was from 2013 (i5 something) and I was getting sub hour make doc times even then but using 3 CPUs. So you having those timings while using a -j5 option ... wow! I am obviously inhabiting some technological bubble that I wasn't aware I was in. :D James
PATCHES - Countdown for January 3rd
Hello, Here is the current patch countdown list. The next countdown will be on January 5th A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !577 Open_type_font: use std::unordered_map bbox table - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/577 !576 Bar_number_engraver: fix order dependence - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/576 !575 Timing_translator: measureStartNow and \partial - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/575 !573 Remove separate CSS files for Internet Explorer - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/573 !571 Add option -ddebug-eval - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/571 !570 Remove -ddebug-gc-assert-parsed-dead - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/570 Countdown: !589 Volta repeat cleanup - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/589 !587 Remove unused functions from general-scheme.cc - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/587 !586 Correct interfaces in multi-measure-rest-reminder.ly - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/586 !581 Add markup-list-command string-lines - Thomas Morley https://gitlab.com/lilypond/lilypond/-/merge_requests/581 !578 Restore '[FILENAME' progress indicator when opening .ly file - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/578 Review: !590 Type-specific C++ grob acknowledgers - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/590 !588 Improve doc-markup-function-properties from document-markup.scm - Thomas Morley https://gitlab.com/lilypond/lilypond/-/merge_requests/588 !583 Support -ddump-signatures in EPS backend - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/583 !580 Remove ly:parser-lexer. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/580 !574 Add ly:smob-counts, a histogram of live smob types - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/574 New: No patches in New at this time. Waiting: No patches in Waiting at this time. *** Regards, James
design decision needed - how to render "Used properties" for markup-(list-)commands
Hi, currently https://gitlab.com/lilypond/lilypond/-/merge_requests/588 is tagged 'needs design', because there are proposals to change the style how the "Used properties" for markup-(list-)commands should print in NR. I've manually [*] created a html-file to demonstrate the default and the so far made suggestions. See attached. Opinions? Anyway, MR 588 is more a bugfix. Thus I'd prefer not to entangle a bug-fix with a new design, but to open a new issue or MR for the latter. Thanks, Harm [*] I wrote a short .texi-file and used texi2html. Using texi2pdf aborts. same with texi2any --pdf No clue why. Used properties (current behaviour): * number (3) * pair ((0 . 0)) * empty-list (â()) Used properties (after MR 588): * number (3) * pair ((0 . 0)) * empty-list (()) Used properties (Wernerâs proposal): * number [default: 3] * pair [default: (0 . 0)] * empty-list [default: ()] Used properties (Michaelâs proposal): * number, default: 3 * pair, default: (0 . 0) * empty-list, default: ()
