Re: Issue 3572: convert-ly should produce several backup files for eachinvokation (issue 14383044)
- Original Message - From: d...@gnu.org To: d...@gnu.org Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org Sent: Friday, October 04, 2013 9:05 PM Subject: Issue 3572: convert-ly should produce several backup files for eachinvokation (issue 14383044) Reviewers: , https://codereview.appspot.com/14383044/diff/1/Documentation/usage/updating.itely File Documentation/usage/updating.itely (right): https://codereview.appspot.com/14383044/diff/1/Documentation/usage/updating.itely#newcode172 Documentation/usage/updating.itely:172: @item -h,--help Actually, where is the point in deleting those spaces? It's not done for -l, and cross-checking with GNU tools shows that their help messages offset the long option forms with a space. So what gives with this form of interpunction? Short of any argument, I'll put the space back in (or in in the first place) everywhere. I deleted it for consistency. Feel free to add one in throughout as an alternative form of consistency. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fedora and mpost
Hi all! Since Fedora's version of mpost is 1.802, I'm now unable to build LilyPond from scratch, and have not the resources to rebuild the Texlive package in order to upgrade. Is there any workaround other than locally revert Julien's commit? TIA, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
Le 05/10/2013 16:50, Phil Holmes disait : - Original Message - From: Jean-Charles Malahieude Since Fedora's version of mpost is 1.802, I'm now unable to build LilyPond from scratch, and have not the resources to rebuild the Texlive package in order to upgrade. Is there any workaround other than locally revert Julien's commit? Could you use a virtual machine? I could, but with low resources : dual-core 1.86GHz with 2 Go RAM I normally need about 1.5 hour for a full make make doc, so… Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
Jean-Charles Malahieude lily...@orange.fr writes: Hi all! Since Fedora's version of mpost is 1.802, I'm now unable to build LilyPond from scratch, and have not the resources to rebuild the Texlive package in order to upgrade. Is there any workaround other than locally revert Julien's commit? That's not a workaround since your fonts would all be broken. Maybe install TeXlive2013 to a local tree and update to the newest version using tlmgr? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
- Original Message - From: Jean-Charles Malahieude lily...@orange.fr To: lilypond-devel lilypond-devel@gnu.org Sent: Saturday, October 05, 2013 3:32 PM Subject: Fedora and mpost Hi all! Since Fedora's version of mpost is 1.802, I'm now unable to build LilyPond from scratch, and have not the resources to rebuild the Texlive package in order to upgrade. Is there any workaround other than locally revert Julien's commit? TIA, Jean-Charles Could you use a virtual machine? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond build dependencies
Hello all, I'm trying to build Lilypond from git-HEAD source for the first time in a while and running into some curiosities from the ./configure script. This is on Ubuntu 13.10. First of all: ./configure requests a number of build dependencies that are not listed on the pages here: http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-running-lilypond http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-compiling-lilypond http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-building-documentation ... which included dblatex, epsf.tex (contained in texlive-generic-recommended) and lh (contained in texlive-lang-cyrillic). At a guess, perhaps these would typically be installed as recommended by the packages that are listed, so anyone (like me) installing _only_ what's listed (and its strict dependencies) will come up against this issue. I'm sure that if I'd just run apt-get build-dep lilypond all would have been fine, but the listed dependencies are the first thing one reads. The blocker to building is the metapost version currently in Ubuntu 13.10. ./configure reports: ERROR: Please install required programs: mpost (due to a bug in metapost, versions 1.600 = x 1.803 are not supported; installed: 1.802) What's the problem here, and is it possible to work around (i.e. tell ./configure I don't care, go ahead and accept working with 1.802) or is the bug sufficiently show-stopping that nothing can be done bar install the updated metapost? Thanks best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
On 05/10/13 17:24, David Kastrup wrote: That's not a workaround since your fonts would all be broken. Maybe install TeXlive2013 to a local tree and update to the newest version using tlmgr? Currently trying to get it to set up a local texmf tree -- running any tlmgr command, e.g. tlmgr init-usertree or tlmgr update --list, results in the following error (I'm running on Ubuntu 13.10): (running on Debian, switching to user mode!) cannot setup TLPDB in /home/joseph/texmf at /usr/bin/tlmgr line 5308. ... any suggestions? Googling around isn't proving much help other than to find that it was a known issue earlier this year. :-( tlmgr --version gives: tlmgr revision 31259 (2013-07-22 00:07:38 +0200) tlmgr using installation: /usr/share/texlive TeX Live (http://tug.org/texlive) version 2013 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 05/10/13 17:24, David Kastrup wrote: That's not a workaround since your fonts would all be broken. Maybe install TeXlive2013 to a local tree and update to the newest version using tlmgr? Currently trying to get it to set up a local texmf tree -- running any tlmgr command, e.g. tlmgr init-usertree or tlmgr update --list, results in the following error (I'm running on Ubuntu 13.10): (running on Debian, switching to user mode!) cannot setup TLPDB in /home/joseph/texmf at /usr/bin/tlmgr line 5308. ... any suggestions? Googling around isn't proving much help other than to find that it was a known issue earlier this year. :-( tlmgr --version gives: tlmgr revision 31259 (2013-07-22 00:07:38 +0200) tlmgr using installation: /usr/share/texlive TeX Live (http://tug.org/texlive) version 2013 Interesting. From URL:https://bugs.launchpad.net/ubuntu/+source/texlive-bin/+bug/1220653: The Debian unstable changelog lists as additional changes over the Saucy version (among others): texlive-bin (2013.20130722.31261-1) unstable; urgency=low * allow for different origin in make-orig-tar * Imported Upstream version 2013.20130722.31261 - fix for crash of luatex on x32 archs in certain cases - update metapost to 1.803 * ship new pmpost patch for 1.803 * bump standards version, no changes necessary -- Norbert Preining prein...@debian.org Fri, 26 Jul 2013 14:39:43 +0900 This would appear to be the relevant change regarding Metapost. So why isn't the Metapost 1.803 if tlmgr is 0733.31261 ? dak@lola:/usr/local/tmp/lilypond$ dpkg -S /usr/bin/tlmgr texlive-base: /usr/bin/tlmgr dak@lola:/usr/local/tmp/lilypond$ dpkg -S /usr/bin/mpost texlive-binaries: /usr/bin/mpost Oh wow. Different package. And indeed apt-get changelog texlive-base starts with texlive-base (2013.20130722-1) unstable; urgency=low * new upstream checkout * conflict with texlive common so that it gets removed (Closes: #710789) * add Polish debconf translation, thanks to Michał Kułach (Closes: #711235) * update tlmgr (and with new upstream also TLUtils.pm) to support map files in user mode -- Norbert Preining prein...@debian.org Mon, 22 Jul 2013 17:35:16 +0900 While apt-get changelog texlive-binaries has texlive-bin (2013.20130529.30792-1build2) saucy; urgency=low * No-change rebuild for new poppler ABIs -- Iain Lane i...@orangesquash.org.uk Tue, 30 Jul 2013 17:02:46 + Unfortunately, nobody seems to be interested in URL:https://bugs.launchpad.net/ubuntu/+source/texlive-bin/+bug/1220653 -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 05/10/13 17:24, David Kastrup wrote: That's not a workaround since your fonts would all be broken. Maybe install TeXlive2013 to a local tree and update to the newest version using tlmgr? Currently trying to get it to set up a local texmf tree -- running any tlmgr command, e.g. tlmgr init-usertree or tlmgr update --list, results in the following error (I'm running on Ubuntu 13.10): (running on Debian, switching to user mode!) cannot setup TLPDB in /home/joseph/texmf at /usr/bin/tlmgr line 5308. ... any suggestions? Googling around isn't proving much help other than to find that it was a known issue earlier this year. :-( tlmgr --version gives: tlmgr revision 31259 (2013-07-22 00:07:38 +0200) tlmgr using installation: /usr/share/texlive TeX Live (http://tug.org/texlive) version 2013 Why not just install the texlive-binaries package from Debian sid? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
On 05/10/13 19:39, David Kastrup wrote: Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: Unfortunately, nobody seems to be interested in URL:https://bugs.launchpad.net/ubuntu/+source/texlive-bin/+bug/1220653 Thanks ever so much for looking into the problem in this depth. In my experience it can help if more than one person reports the bug as affecting them (I've just done so). So, fingers crossed. By the look of it though, they just copy over from Debian rather than having any dedicated TeXlive maintainers themselves :-( ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
On 05/10/13 20:08, Joseph Rushton Wakeling wrote: In my experience it can help if more than one person reports the bug as affecting them (I've just done so). So, fingers crossed. By the look of it though, they just copy over from Debian rather than having any dedicated TeXlive maintainers themselves :-( Yup, their janitor bot has updated the bug's status to Confirmed now that I've asserted the bug affects me too. Hopefully that will prompt some action. There is an Ubuntu TeX team https://launchpad.net/~ubuntu-tex, and I've written to them to see if there's anything they can do. If not I'll try installing the sid packages as you suggest, but better to get it actually fixed in Ubuntu if possible. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build dependencies
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: What's the problem here, and is it possible to work around (i.e. tell ./configure I don't care, go ahead and accept working with 1.802) or is the bug sufficiently show-stopping that nothing can be done bar install the updated metapost? It's a showstopper. Most of the flags will look absurd, and things like the treble clef as well. Maybe you can use tlmgr for updating your Metapost. No idea. Or complain to Ubuntu that they still have not updated their TeXlive. Maybe downgrading Metapost is an option if you can't figure out how to upgrade. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build dependencies
On 05/10/13 19:01, David Kastrup wrote: Maybe you can use tlmgr for updating your Metapost. Well, you saw the error I encountered when trying to use tlmgr to do that. (Maybe I'm just misunderstanding how it works, I've never used it before.) No idea. Or complain to Ubuntu that they still have not updated their TeXlive. Done. :-) Maybe downgrading Metapost is an option if you can't figure out how to upgrade. If Ubuntu don't do anything I'll try installing sid packages as you suggested. Can you confirm that my list of missing build dependencies is accurate? I'd be happy to send a CG patch about this (assuming I get to the point of a working build:-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora and mpost
Le 05/10/2013 20:03, Werner LEMBERG disait : Is there any workaround other than locally revert Julien's commit? That's not a workaround since your fonts would all be broken. Maybe install TeXlive2013 to a local tree and update to the newest version using tlmgr? It's not necessary to downlaod the whole TeXLive; it is fully sufficient to download a new mpost binary from the TeXLive's SVN: http://www.tug.org/svn/texlive/trunk/Master/bin/ Note, however, that you must *replace* the old binary, this is, the new binary must put into the same directory as the old binary was. Since tlmgr is not distributed, I owe a triple Schnäpsle to Werner. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build dependencies
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 05/10/13 19:01, David Kastrup wrote: Maybe you can use tlmgr for updating your Metapost. Well, you saw the error I encountered when trying to use tlmgr to do that. (Maybe I'm just misunderstanding how it works, I've never used it before.) No idea. Or complain to Ubuntu that they still have not updated their TeXlive. Done. :-) Maybe downgrading Metapost is an option if you can't figure out how to upgrade. If Ubuntu don't do anything I'll try installing sid packages as you suggested. Can you confirm that my list of missing build dependencies is accurate? They look plausible, but I have no idea whether they would be complete. I'd be happy to send a CG patch about this (assuming I get to the point of a working build:-) -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add the command \offset to LilyPond (issue 8647044)
https://codereview.appspot.com/8647044/diff/5001/input/regression/offsets.ly
File input/regression/offsets.ly (right):
https://codereview.appspot.com/8647044/diff/5001/input/regression/offsets.ly#newcode5
input/regression/offsets.ly:5: the @code{\\offset} command. These
properties are limited to immutable
On 2013/04/23 20:24:57, dak wrote:
What does immutable mean here?
Hopefully this rewrite is less opaque.
https://codereview.appspot.com/8647044/diff/5001/input/regression/offsets.ly#newcode8
input/regression/offsets.ly:8: in its default appearance. The command
is used both as a tweak and an
On 2013/04/23 20:24:57, dak wrote:
demonstrated as a tweak and as an override. The double as is
important, and
I'd remove both since otherwise the impression arises that it is
both at the
same time.
Done.
https://codereview.appspot.com/8647044/diff/5001/scm/c++.scm
File scm/c++.scm (right):
https://codereview.appspot.com/8647044/diff/5001/scm/c++.scm#newcode30
scm/c++.scm:30: (every number-pair? x)))
On 2013/10/04 01:17:08, david.nalesnik wrote:
On 2013/04/23 20:24:57, dak wrote:
Isn't it dangerous to call every on something that is not
necessarily a
list?
Like (cons 2 3)?
I would think so... However,
(every number-pair? (cons 2 3))
returns #f
Fixed. No more reliance on undefined behavior.
https://codereview.appspot.com/8647044/diff/5001/scm/music-functions.scm
File scm/music-functions.scm (right):
https://codereview.appspot.com/8647044/diff/5001/scm/music-functions.scm#newcode2103
scm/music-functions.scm:2103: ; head of the alist. We reverse the alist
so our search will return
Thank you for your explanations!
On 2013/10/04 05:59:15, dak wrote:
It is probably more interesting how the function offsetter is then
ended:
(define (offsetter property offsets)
(define (self grob) .)
self)
This is what stumped me. I was attempting to return (self grob).
There is a major problem with this patch set which I don't know how to
address.
The examples below represent my efforts to test the effects of multiple
applications of \offset. You can see that some accumulation is
possible. However, the last two examples (commented out) will cause a
crash. All I can think of is that this relates to the multiple
instances of self in the properties alist. I've verified that the
instances aren't identical despite having the same name, so I don't
understand why there should be a problem.
\relative c' {
%% TESTS FOR ACCUMULATION %%
% default
c e g b1\arpeggio
\override Arpeggio.positions = #'(-3.5 . 0.5)
c e g b1\arpeggio
% values created by override are offset
\offset #'positions #'(-2 . 2) Arpeggio
c e g b1\arpeggio
% This is the result of new offset and override still in effect;
% two offsets have not accumulated.
\offset #'positions #'(-1 . 1) Arpeggio
c e g b1\arpeggio
% override + last offset + offset tweak
c e g b1-\offset #'positions #'(-0.5 . 0.5) \arpeggio
}
\relative c' {
%% MORE TESTS FOR ACCUMULATION %%
% default
c e g b1\arpeggio
\once \offset #'positions #'(-2 . 2) Arpeggio
c e g b1\arpeggio
% This accumulates:
\offset #'positions #'(-2 . 2) Arpeggio
c e g b1-\offset #'positions #'(-2 . 2) \arpeggio
%%% This causes a crash:
%\offset #'positions #'(-2 . 2) Arpeggio
%\once \offset #'positions #'(-2 . 2) Arpeggio
%c e g b1\arpeggio
%% This causes a crash:
%\once \offset #'positions #'(-2 . 2) Arpeggio
%\temporary \offset #'positions #'(-2 . 2) Arpeggio
%c e g b1\arpeggio
}
https://codereview.appspot.com/8647044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add support for setting MIDI balance, pan position, reverb and chorus levels (issue 14434043)
Thanks, Heikki; this looks very good.
Panning will help people to proof-read complex scores by listening to
the MIDI output. I added an item to the bug tracker to add some
documentation when this is done.
Did you consider adding the functionality to Staff_performer, rather
than the separate Midi_effect_performer ?
They both control settings that apply to a MIDI channel. If we move one
_performer to the Voice context and not the other, the results seem more
potentially confusing, than potentially useful.
https://codereview.appspot.com/14434043/diff/8001/lily/midi-item.cc
File lily/midi-item.cc (right):
https://codereview.appspot.com/14434043/diff/8001/lily/midi-item.cc#newcode367
lily/midi-item.cc:367: // Audio_control_function_value_change::Control.
Is it appropriate, then, to make this array a public static member of
Audio_control_function_value_change and still access it from here?
(I find the spaghetti of object-oriented obfuscation in the MIDI-output
code to be overwhelming, so I'm happy that you seem to find your way
through it.)
https://codereview.appspot.com/14434043/diff/8001/lily/midi-item.cc#newcode398
lily/midi-item.cc:398:
Implementing fine as well as coarse seems to be more trouble than it is
worth.
https://codereview.appspot.com/14434043/diff/8001/lily/staff-performer.cc
File lily/staff-performer.cc (right):
https://codereview.appspot.com/14434043/diff/8001/lily/staff-performer.cc#newcode71
lily/staff-performer.cc:71: Control_function_value_map
control_function_value_map_;
Better to move up a few lines, outside of the group of mappings indexed
by voice names, and to define directly without typedef so it can be
compared with the others.
https://codereview.appspot.com/14434043/diff/8001/lily/staff-performer.cc#newcode231
lily/staff-performer.cc:231: if (!ins.second ai-value_ == value)
Why bother removing duplicate settings of midiPanPosition, etc. ?
The bookkeeping is complicated, and a duplicate setting would come from
a second explicit \set Staff.midiPanPosition, so the user might expect
to see the duplicate control-change-event.
Users often have applications that are surprising; someone might use the
MIDI output as input to another program that does not remember control
settings properly.
https://codereview.appspot.com/14434043/diff/8001/ly/performer-init.ly
File ly/performer-init.ly (right):
https://codereview.appspot.com/14434043/diff/8001/ly/performer-init.ly#newcode200
ly/performer-init.ly:200: instrumentName = #bright acoustic
Answering your earlier question on the bug-tracker, I would suggest
simply omitting this initialization.
The current state with the erroneous name has no effect, and people have
not complained about a missing initial programChange. If you fix it,
and start sending an initial programChange, someone might have a
problem.
https://codereview.appspot.com/14434043/diff/8001/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):
https://codereview.appspot.com/14434043/diff/8001/scm/define-context-properties.scm#newcode435
scm/define-context-properties.scm:435: (midiChannelMapping ,symbol? How
to map MIDI channels: per @code{instrument} (default), @code{staff} or
@code{voice}.)
Oops. I changed the default to be 'staff, so that it works with the
default arrangement of performers in the Staff-like contexts, but forgot
to change this line of documentation. I'll fix it later if you don't.
I hope that didn't cause confusion.
https://codereview.appspot.com/14434043/diff/8001/scm/define-context-properties.scm#newcode438
scm/define-context-properties.scm:438: @code{midiChannelMapping}).
Ranges from@tie{}@w{-1} to@tie{}1,
I would skip the text in (...) because MIDI channel associated with
the context says it all.
https://codereview.appspot.com/14434043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
