Patchset 2 was reviewed, counted down, pushed to staging, made it to
master. Then David's patchy broke because I incorrectly assumed that
every clone of a lilypond repository has a local copy of the master
branch. Consequently the patch was reverted in staging and master.
The fix is obvious, we m
Reviewers: ,
Message:
Please review. See 'Re: Patchy email' thread in lilypond-devel.
Knut
Description:
Fix relocate-preamble.py bug
In relocate-preamble.py the search
path for python modules is changed.
If a python script / module used
in our regression tests is changed,
the results of "make
Ready for review now
https://codereview.appspot.com/558920043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
Won't be able to work on this until next week, maybe somebody has an
idea how to fix the rest.
Description:
Fix musicxml2ly.py - incomplete attempt
Our current musicxml2ly code requires at
least python2 2.7.0. The installers provide
python 2.4.5.
If the python 2.4.5 is us
We display BRANCH and HEAD.
If we find a merge-point with master, we display that
merge-point and the history from merge-point to HEAD.
If not, we display up to 10 commits of history.
Finding a merge-point may fail if we are in a git repository
that is not a full clone of the master repository.
What I would like to see for such branches is the ID of the commit
where the branch is rooted in master, this is, if we have
o---o---o branch
/
o---o---o---o---o master
0 1 2 3 4
I want to see ID 2 in this file, marked as the root of `branch'.
So
On 2019/07/12 22:36:29, Carl wrote:
Why do we want 10 commits instead of just 1? I don't see the
rationale for this
patch.
Well, the patch first adds the name of the branch used and increases the
number of commits in the history.
Whether or not this is helpful depends on the situation. When
Reviewers: ,
Message:
Hi everybody!
With the proposed patch tree.gittxt will contain the name of the current
branch as well as up to 10 commits of history. Example tree:gittxt:
BRANCH: IMPROVE_TREE.GITTXT
HISTORY:
HASH: b9a2c64a66147f3b1b4a30f27ca4d3c96a01e982
SUBJECT: Improve c
Reviewers: ,
Message:
Please review.
Should also be applied to stable/2.20 after cherry-picking
2a4dfab3dbeb3412fda4f3e35a879a55fe8fd3c0.
Knut
Description:
Add tex/txi-pt.tex
We need txi-*.tex files for all the languages we
support. Without them, building of lilypond fails.
If you did not ex
See individual comments ...
https://codereview.appspot.com/568820043/diff/582790043/config.make.in
File config.make.in (right):
https://codereview.appspot.com/568820043/diff/582790043/config.make.in#newcode23
config.make.in:23: CONFIG_CFLAGS = @CFLAGS@ $(GLIB_CFLAGS)
$(GUILE_CFLAGS)
This breaks
I reverted pull request #59 on a local branch of gub. In the local
lilypond repository I created branch 3538700043 pointing to HEAD of
stable/2.20, and added the proposed patch to branch 353870043.
make LILYPOND_REPO_URL=git://golem/lilypond.git
LILYPOND_BRANCH=stable/2.20 lilypond
fails
On 2019/01/28 21:44:11, lemzwerg wrote:
LGTM, thanks!
I agree, LGTM.
I'll do an strace gub build tomorrow to verify that no hidden use of
etex was missed.
If the patch passes the strace test it would be an immediate candidate
for both master and stable/2.20.
https://codereview.appspot.com/35
On 2018/06/08 10:29:40, dak wrote:
On 2018/06/08 09:54:29, knupero wrote:
> Please review.
When you say "will not pass make check", you mean that there are
visual
differences, not that the test aborts, right? Since the latter would
not be ok.
Exactly. There is an in
Reviewers: ,
Message:
Please review.
Description:
Fix out-of-sync LilyScriptEncoding / ps script defs
Commit 12fe78825798191ecb7e5a4ee3064679773ae1ab broke
encodingdefs.ps.
This patch will not pass 'make check', but this is ok
as the current state is wrong.
I did not care about the 80-charact
Answers to comments.
https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):
https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile#newcode145
mf/GNUmakefile:145: cd $(outdir) && mv $(notdir $@).otf $(notdir $@)
On 2018/05/26 16:25:25, lemzwerg wrote:
Changes:
Command line:
"-O size" is gone
"-O legacy" is added, uses our old non-encodings code
"-O TeX" new default as the pdf files are smaller.
"-O TeX-GS" use if you want to include lilypond pdfs in TeX document and
postprocess the resulting pdfs with ghostscript. You also need to give
/path/
On 2018/05/29 22:44:44, knupero wrote:
Also use CMap Identity-H for TeX Gyre Schola family, some fixes and
enhancements.
It would be nice to know if this code also works on Windows and MacOS
systems.
https://codereview.appspot.com/343970043
https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):
https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile#newcode145
mf/GNUmakefile:145: cd $(outdir) && mv $(notdir $@).otf $(notdir $@)
On 2018/05/26 15:17:09, Carl wrote:
I think there is potenti
However, I believe that the case problem with MacOS needs to be fixed.
I
believe this patch won't work on MacOS -- only one version of the font
will be
installed (the last one to be created).
I wasn't aware of MacOS case handling, I'll have a look at it.
Thanks for pointing out that problem
Reviewers: ,
Message:
Please review.
Description:
Allow use of Identity-H CMap and CID versions of Emmentaler
When -O TeX or -O TeX-GS is given, lilypond generates
postscript code that instructs ghostscript to use the
Identity-H CMap and CID versions of the emmentaler
fonts. Used e.g. by 'make
I don't see the point in starting a formal review after this has
already been
discussed on the mailing list.
I was hoping, apparently in vain, that the formal process would lead to
a more reasonable discussion. Apparently, however, this process also
invites speculation about the amount of work
Reviewers: ,
Message:
Please test & review the proposed syntax change.
Description:
Syntax: lyric_mode_music might be a MUSIC_FUNCTION
With this patch, all four scores in the lilypond
source below use a valid syntax and produce correct
output.
Without this patch only the first two scores use
a
https://codereview.appspot.com/336240043/diff/40001/scripts/lilypond-invoke-editor.scm
File scripts/lilypond-invoke-editor.scm (right):
https://codereview.appspot.com/336240043/diff/40001/scripts/lilypond-invoke-editor.scm#newcode1
scripts/lilypond-invoke-editor.scm:1:
#!/home/knut/sources/lilyb
Reviewers: ,
Message:
This security problem was introduced in 2005.
Description:
Fix security problem in lilypond-invoke-editor
If lilypond-invoke-editor was installed as a
general uri-helper it was easy to abuse it to
execute arbitrary code on an attacked system.
With this patch lilypond-invo
> Unfortunately, non-CID-keyed fonts can not use Identity-H encoding.
> XeTeX and LuaTeX seem to convert non-CID-Keyed font to CID-keyed
font on the
> fly, and embed it to PDF, use Identity-H encoding.
Should we create a tracker for this?
I think whoever has an idea and the time to solve
Issue 1255 is: "#1255 Extract hyphen dimensions and/or hyphen glyph
from the
font "
Your patch does not extract hyphen dimensions or the hyphen glyph from
the font.
It might get used for using the hyphen glyph (provided that you know
its
font-dependent character code) as a hyphen, so
While we are at it, it may make sense not to refer to the no longer
existing Gmane page for bug reports.
I changed the message, but there are 58 more places where post.gmane is
referenced in the tree.
And there 113 mor place that reference othere places of gmane.
At least http://lilypond.org/bu
BTW, is there any chance to reduce the width of the help screen to
stay within 78 characters?
I don't think so
https://codereview.appspot.com/325630043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/l
lilypond --help gives the following output:
Usage: lilypond [OPTION]... FILE...
Typeset music and/or produce MIDI from FILE.
LilyPond produces beautiful music notation.
For more information, see http://lilypond.org
Options:
-f, --formats=FORMATs dump FORMAT,... Also as separat
How about just --pdf= ? One option less to remember. This
is going to
be double the fun once we can generate PDF bypassing PS altogether.
Yes, even better.
Sounds like a good strategy. Just not in time for 2.20.
I tend to agree.
https://codereview.appspot.com/325630043/
_
Bikeshedding done for the day.
Let me continue.
"lilypond --help" and "lilypond -dhelp" gives perfect help to all users.
I doubt that there are a lot of people who know which parameters to use
for a non-trivial case even after reading the help texts.
At least the following parameters influence
> Remember: We used the hardcoded name "Emmentaler" at various places
> for --bigpdfs, and --use-encodings still needs and uses that portion
> of the old code.
Before remembering something, I need to know it in the first place.
Sounds like something we should get rid off in the long run.
Ye
On 2017/09/25 17:33:47, dak wrote:
Why are we still navigating the bleeding edge? LilyPond is more than
20 years
old.
I remember a company that failed to get flash right.
Ghostscript still fails on GoToR without the help of extractpdfmarks ;-)
On 2017/09/25 16:38:16, knupero wrote
I don't really have a clue here: can someone chime in with the current
Ghostscript versions in possibly concerned distributions? Naturally
including
our own Gub-based ones?
OpenSuSE Tumbleweed: 9.21
OpenSuSE Leap: 9.15, but also offers 9.21
https://codereview.appspot.com/325630043/
> --use-encodings switches emmentaler glyph generation from
"glyphshow" to
> "show"+encodings and might be combined width -dgs-never-embed-fonts.
That sounds good. It also sounds like -dgs-never-embed-fonts should
imply
--use-encodings, right?
No. There are legitimate uses for both sta
https://codereview.appspot.com/325630043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
A bit more far-reaching.
As newer versions of gs
- don't need the helpemmentaler functions and
- don't need the real inclusion of all font data and
- don't need some other details and
- don't work properly with our old code
we might well decide to kill --bigpdfs.
Instead of --bigpdfs thi
Combining them means that the size of the final PDF may be smaller but
the size
of the intermediate PDFs will be larger.
In my experiment, even if there is a bug in gs's full set font
embedding, the
disk size that `make doc` eats has increased.
I did not check that, but I would expect an i
Reviewers: dak,
Message:
On 2017/09/23 16:02:32, dak wrote:
https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make
File make/lilypond-vars.make (right):
https://codereview.appspot.com/325630043/diff/1/make/lilypond-vars.make#newcode54
make/lilypond-vars.make:54: -dgs-never-
https://codereview.appspot.com/325470043/diff/20001/lily/lyric-hyphen.cc
File lily/lyric-hyphen.cc (right):
https://codereview.appspot.com/325470043/diff/20001/lily/lyric-hyphen.cc#newcode125
lily/lyric-hyphen.cc:125: Box b (Interval (0, dash_length), Interval (h,
h + th));
On 2017/09/16 19:53:5
On 2017/09/16 19:53:57, dak wrote:
Indepent of those: I don't actually see this addressing issue 1255, so
maybe
create a new issue in the Sourceforge issue tracker for it and attach
this
Rietveld issue? It seems at best loosely related to issue #1255 but
seems to be
desirable nevertheless
https://codereview.appspot.com/325470043/diff/1/lily/lyric-hyphen.cc
File lily/lyric-hyphen.cc (right):
https://codereview.appspot.com/325470043/diff/1/lily/lyric-hyphen.cc#newcode55
lily/lyric-hyphen.cc:55: bool use_markup = to_boolean (me->get_property
("use-markup"));
On 2017/09/14 09:34:03,
42 matches
Mail list logo
