Re: my favorite bug :-)
Am 01.05.2015 um 13:53 schrieb Masamichi HOSODA: The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? Maybe the functions in this file help you? https://github.com/openlilylib/openlilylib/blob/master/ly/_internal/utilities/os-path.scm Urs ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Incorrect interaction of stemLeft/RightBeamCount and Score.skipTypesetting
I'm not top posting.
Wrong output: the \set stemRightBeamCount and \set stemLeftBeamCount
are incorrectly applied to the first note AFTER
\set Score.skipTypesetting = ##f.
\version 2.18.2
{ $\set Score.skipTypesetting = ##t
c'16 \set stemRightBeamCount = #1 c' \set stemLeftBeamCount = #1 c' c'
\set Score.skipTypesetting = ##f
c' c' c' c'
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? Maybe the functions in this file help you? https://github.com/openlilylib/openlilylib/blob/master/ly/_internal/utilities/os-path.scm Thank you. But, now, I think using an absolute path for solving ghostscript file name issue is not a good idea. Using mkstemp generated temporary file is a good idea. It is the same way as gcc's intermediate file treatment. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? When the following command is used, lilypond uses the absolute (complete) path to the intermediate files. $ lilypond -dgui `pwd`/lines.ly It works fine. However, I think that the intermediate file should be temporary by mkstemp etc. If lilypond uses mkstemp generated temporary file, this ghostscript problem will not occur. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
There is a big difference: If you compile a .c file, the .o files
stays by default; the compiler doesn't remove it.
Uh, wrong?
cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega*
gega gega.c
I've meant using option `-c' of the compiler. BTW, if you specify
option `-o', does gcc create an intermediate file `gega.o' that
overwrites another file `gega.o' in the compilation directory?
Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
On Fri, 1 May 2015 12:48:52 +0200 (CEST) Martin Tarenskeen m.tarensk...@zonnet.nl wrote: In this case, as an intermediate file example.ps is used. This is a problem if a file named example.ps already exists in my working directory. This file is brutally overwritten and deleted when I run lilypond without any warning or option to cancel, nor is a backup copy of the old file made. Exactly the behaviour that I want. When I work on manuscripts the .pdf (as well as the .midi) are objects. The .ly is the only source. Just like compiling .c files, I don't want a warning every time it is going to overwrite a .o file. If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but Solved for some, problem for others. I don't want to have to guess what my final manuscript is named. If I start with example.ly I know that example.pdf is my target. Scripts can deal with that easily. I use make for my charts. Having to deal with guessing output file names would be incredibly tricky if possible at all. also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. Different issue. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VoIP: sip:da...@druid.net ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Werner LEMBERG w...@gnu.org writes:
There is a big difference: If you compile a .c file, the .o files
stays by default; the compiler doesn't remove it.
Uh, wrong?
cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega*
gega gega.c
I've meant using option `-c' of the compiler.
Uh, removing the actual end product of a command would be sort of
strange, wouldn't it?
BTW, if you specify option `-o', does gcc create an intermediate file
`gega.o' that overwrites another file `gega.o' in the compilation
directory?
dak@lola:/tmp$ touch gega.o
dak@lola:/tmp$ gcc -o gega gega.c
dak@lola:/tmp$ ls -l gega.o
-rw-rw-r-- 1 dak dak 0 May 1 16:46 gega.o
No. It is a safe bet that there _are_ intermediate files, but they'll
likely end up somewhere on /tmp or similar.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
However, I think that the intermediate file should be temporary by mkstemp etc. If lilypond uses mkstemp generated temporary file, this ghostscript problem will not occur. +1 Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Hello David and Masamichi! I've meant using option `-c' of the compiler. Uh, removing the actual end product of a command would be sort of strange, wouldn't it? Yes. But sometimes there are Makefile rules that remove intermediate files. BTW, if you specify option `-o', does gcc create an intermediate file `gega.o' that overwrites another file `gega.o' in the compilation directory? dak@lola:/tmp$ touch gega.o dak@lola:/tmp$ gcc -o gega gega.c dak@lola:/tmp$ ls -l gega.o -rw-rw-r-- 1 dak dak 0 May 1 16:46 gega.o No. It is a safe bet that there _are_ intermediate files, but they'll likely end up somewhere on /tmp or similar. Thanks for confirmation. The suggestion is to let lilypond do the same. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Werner LEMBERG w...@gnu.org writes:
In this case, as an intermediate file example.ps is used. This is
a problem if a file named example.ps already exists in my working
directory. This file is brutally overwritten and deleted when I
run lilypond without any warning or option to cancel, nor is a
backup copy of the old file made.
Exactly the behaviour that I want.
Certainly not.
When I work on manuscripts the .pdf (as well as the .midi) are
objects. The .ly is the only source. Just like compiling .c files,
I don't want a warning every time it is going to overwrite a .o
file.
There is a big difference: If you compile a .c file, the .o files
stays by default; the compiler doesn't remove it.
Uh, wrong?
cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega*
gega gega.c
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
There is a big difference: If you compile a .c file, the .o files
stays by default; the compiler doesn't remove it.
Uh, wrong?
cd /tmp;echo main(){return 0;} gega.c;gcc -o gega gega.c;ls gega*
gega gega.c
I've meant using option `-c' of the compiler. BTW, if you specify
option `-o', does gcc create an intermediate file `gega.o' that
overwrites another file `gega.o' in the compilation directory?
If I understand correctly,
in this case, gcc does not use gega.o.
gcc uses /tmp/ccXX.o etc.
(XX is replaced by random unique charactor by mkstemp.)
gcc removes it.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
Werner LEMBERG w...@gnu.org writes: Hello David and Masamichi! I've meant using option `-c' of the compiler. Uh, removing the actual end product of a command would be sort of strange, wouldn't it? Yes. But sometimes there are Makefile rules that remove intermediate files. Why bring up Make? Make has no mechanism for dealing with intermediate files (it removes _target_ files by default when the rule producing them errors out). So any removal of intermediate files has to happen by writing it as part of an action. You could equally well say sometimes there are shell scripts that remove intermediate files. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-) (fwd)
Did you know it is not possible/allowed to name a lilypond file
align.ly or lines.ly? On my Fedora system I can find all the names
that suffer from this bug by typing
#ls /usr/share/ghostscript/9.15/lib/*.ps
all these filenames (minus .ps) can not be used as lilypond inputfiles
(plus .ly)
for example create a file lines.ly with a minimal content
\version 2.19.19
{c' d' e' f'}
and compile ...
Fortunately there are no prelude.ps, etude.ps, or sonata.ps in the
ghostscript files ;-)
In my cygwin64 environment, I've reproduced it.
(I've installed lilypond by cygwin64 setup in the environment.)
And, the following commands also has been reproduced it.
$ lilypond -f ps lines.ly
$ ps2pdf14 lines.ps lines.pdf
On the other hand, the following commands has not been reproduced it.
$ lilypond -f ps lines.ly
$ ps2pdf14 `pwd`/lines.ps lines.pdf
Perhaps it's a ghostscript's bug.
(ps2pdf14 is ghostscript included command.)
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
for example create a file lines.ly with a minimal content
\version 2.19.19
{c' d' e' f'}
and compile ...
I'm trying to narrow down the issue
It seems that on some systems (like mine).
# gs lines.ps
is expanded to something like
# gs /usr/share/ghostscript/9.15/lines.ps
but
# gs /complete/path/to/lines.ps
is not.
When compiling a lines.ly file, lines.ps is produced as an intermediate
file before ghostscript converts this to lines.pdf
The bug would be fixed if lilypond would make ghostscript use a complete
path to the intermediate lines.ps file for the ps to pdf conversion.
--
MT
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
my favorite bug :-) (fwd)
-- Forwarded message --
Date: Fri, 1 May 2015 09:47:25 +0200 (CEST)
From: Martin Tarenskeen m.tarensk...@zonnet.nl
To: lilypond-user mailinglist lilypond-u...@gnu.org
Subject: my favorite bug :-)
This issue has been reported in the mailing list some time ago - I think it was
David Kastrup who discovered it - but I can't find it anywhere in the buglist
or in the docs.
Did you know it is not possible/allowed to name a lilypond file align.ly or
lines.ly? On my Fedora system I can find all the names that suffer from this
bug by typing
#ls /usr/share/ghostscript/9.15/lib/*.ps
all these filenames (minus .ps) can not be used as lilypond inputfiles (plus
.ly)
for example create a file lines.ly with a minimal content
\version 2.19.19
{c' d' e' f'}
and compile ...
Fortunately there are no prelude.ps, etude.ps, or sonata.ps in the ghostscript
files ;-)
--
MT
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: compile failure - parsed object should be dead in 2.19.20
Addendum: this is not a bug with ghostscript, at least for me, but rather
with a part of ghostscript failing against recent versions of fontconfig
(on my gentoo system, fontconfig-2.11.93 fails to compile .ly files with
the errors above, but downgrading to 2.11.1 allows files to compile). Can
anybody else confirm?
Cheers,
A
On Tue, Apr 28, 2015 at 10:11 PM, N. Andrew Walsh n.andrew.wa...@gmail.com
wrote:
according to Urs Liska, this resembles an error he encountered with
ghostscript, as the output on my machine when using --verbose confirms. If
you're also on the user list, the longer output is there. If not, I can
post here (but I imagine you'd prefer avoiding double-posting if it isn't
necessary).
I'm using gs 9.15.
Cheers,
A
On Tue, Apr 28, 2015 at 9:52 PM, Thomas Morley thomasmorle...@gmail.com
wrote:
2015-04-28 21:15 GMT+02:00 N. Andrew Walsh n.andrew.wa...@gmail.com:
I'm not top posting.
With a MWE:
\version 2.19.20
\relative c' {
a4 b c d
}
I get the following error in the console output under frescobaldi:
Starting lilypond 2.19.20 [Untitled]...
Processing `/tmp/frescobaldi-NJlynW/tmpIzKobr/document.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `document.ps'...
Converting to `./document.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -
dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -
r1200 -sDEVICE=pdfwrite -sOutputFile=./document.pdf -c.setpdfwrite -
fdocument.ps)' failed (256)
programming error: Parsed object should be dead: #Grob NoteSpacing
continuing, cross fingers
programming error: Parsed object should be dead: #Prob: paper-system
C++:
Prob((Y-offset . 1.0) (system-grob . #Grob System ) (staff-refpoint-
extent -3.776 . -3.776) (last-in-score . #t) (page-turn-penalty) (page-
break-penalty) (page-turn-permission . allow) (page-break-permission .
allow) (vertical-skylines . #Skyline_pair) (stencil . #Stencil))()
continuing, cross fingers
fatal error: failed files: /tmp/frescobaldi-NJlynW/tmpIzKobr/
document.ly
Exited with return code 1.
-
Error output is the same on larger files.
Cheers
Can't confirm with a build from latest master in LilyDev (Ubuntu 10.04)
All works as expected.
Cheers,
Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
On Fri, 1 May 2015, Martin Tarenskeen wrote: The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. The issue has brought me to another problem: LilyPond by default takes *.ly file as input and produces a *.pdf file as output. $lilypond example.ly --- result: example.pdf In this case, as an intermediate file example.ps is used. This is a problem if a file named example.ps already exists in my working directory. This file is brutally overwritten and deleted when I run lilypond without any warning or option to cancel, nor is a backup copy of the old file made. If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. I'm not a (LilyPond) developer but does it makes sense what I am suggesting? -- MT ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
In this case, as an intermediate file example.ps is used. This is a problem if a file named example.ps already exists in my working directory. This file is brutally overwritten and deleted when I run lilypond without any warning or option to cancel, nor is a backup copy of the old file made. Exactly the behaviour that I want. Certainly not. When I work on manuscripts the .pdf (as well as the .midi) are objects. The .ly is the only source. Just like compiling .c files, I don't want a warning every time it is going to overwrite a .o file. There is a big difference: If you compile a .c file, the .o files stays by default; the compiler doesn't remove it. However, lilypond, if called with option `--pdf' (which is the default), *does* remove the intermediate .ps file! If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but Solved for some, problem for others. I don't want to have to guess what my final manuscript is named. If I start with example.ly I know that example.pdf is my target. Scripts can deal with that easily. Perhaps a misunderstanding: If I say lilypond --pdf foo.ly I get `foo.pdf', no question. If I say lilypond --os foo.ly I get `foo.ps'. However, the former call creates an intermediate file `foo.ps' that gets deleted eventually by lilypond itself. And this is bad. also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. Different issue. No, not at all. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Completion_heads_engraver and dotted breve
On Mon, Apr 27, 2015 at 4:05 AM, Simon Albrecht simon.albre...@mail.de wrote: Hello, Completion_heads_engraver doesn’t use dotted breve notes for its output, where smaller note values work as expected. Thanks, Simon Thanks, Simon. Submitted as Issue 4362 : https://code.google.com/p/lilypond/issues/detail?id=4362 Ralph ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
If the intermediate file would be given a unique, not already existing, temporary filename, not only this issue would be solved but also the original lines.ly - lines.ps - lines.pdf issue that started this thread would not be a problem anymore. I'm not a (LilyPond) developer but does it makes sense what I am suggesting? Yes, it does. As soon as your bug report gets added to the tracker, please add this your comment. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: my favorite bug :-)
The bug would be fixed if lilypond would make ghostscript use a complete path to the intermediate lines.ps file for the ps to pdf conversion. Does anyone know how to convert from any path (relative and absolute path) to absolute path in scheme (guile) ? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: figured bass on grace note
On Tue, Apr 28, 2015 at 10:58 PM, Yuan Ye yuanyel...@openmailbox.org wrote: I believe there is a bug when writing figured bass on grace note. The figure before the grace note is repeated on the grace note. Here is a tiny example: The second figure should be 5 but turns out 6 5. Thanks, Yuan Ye. This has been submitted as Issue 4363 : https://code.google.com/p/lilypond/issues/detail?id=4363 Ralph ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
