1. the configure files in the tar file are empty. I deleted them and
ran autoconf.
2. ly2dvi mucks the environment so that lilypond can't find its init
files.
$ /usr/local/bin/ly2dvi verso_2.ly
ly2dvi 0.0.6
executing: lilypond verso_2.ly 2>&1
GNU LilyPond 1.1.10.
warning: can't find file: `init.ly'
ly2dvi hmm, I could not find an output file name
3. Lilypond itself hangs.
$ lilypond verso_2.ly
GNU LilyPond 1.1.10.
Parsing...[/usr/local/share/lilypond/ly/init.ly[/usr/local/share/lilypond/ly/declarations.ly[/usr/local/share/lilypond/ly/dynamic.ly][/usr/local/share/lilypond/ly/nederlands.ly][/usr/local/share/lilypond/ly/script.ly][/usr/local/share/lilypond/ly/paper20.ly[/usr/local/share/lilypond/ly/table20.ly][/usr/local/share/lilypond/ly/table13.ly][/usr/local/share/lilypond/ly/table16.ly][/usr/local/share/lilypond/ly/params.ly[/usr/local/share/lilypond/ly/a4.ly][/usr/local/share/lilypond/ly/paper.ly][/usr/local/share/lilypond/ly/engraver.ly]]][/usr/local/share/lilypond/ly/midi.ly[/usr/local/share/lilypond/ly/performer.ly]][/usr/local/share/lilypond/ly/property.ly]
It appears to be reading from standard input:
$ lilypond verso_2.ly < /dev/null
GNU LilyPond 1.1.10.
Parsing...[/usr/local/share/lilypond/ly/init.ly[/usr/local/share/lilypond/ly/declarations.ly[/usr/local/share/lilypond/ly/dynamic.ly][/usr/local/share/lilypond/ly/nederlands.ly][/usr/local/share/lilypond/ly/script.ly][/usr/local/share/lilypond/ly/paper20.ly[/usr/local/share/lilypond/ly/table20.ly][/usr/local/share/lilypond/ly/table13.ly][/usr/local/share/lilypond/ly/table16.ly][/usr/local/share/lilypond/ly/params.ly[/usr/local/share/lilypond/ly/a4.ly][/usr/local/share/lilypond/ly/paper.ly][/usr/local/share/lilypond/ly/engraver.ly]]][/usr/local/share/lilypond/ly/midi.ly[/usr/local/share/lilypond/ly/performer.ly]][/usr/local/share/lilypond/ly/property.ly]ERROR:
In procedure scm_eval_0str:
ERROR: Wrong type argument in position 1: #f
There is a long delay before it does anything.
I used strace (we're on a Linux 2.0.35 system with libc 5.4.46 here)
which showed some of the most bizarre I/O patterns I seen for a
while:
....
read(6, "(open-input-file str)\n (open-f"..., 4096) = 2426
lseek(6, -2425, SEEK_CUR) = 2235
read(6, "open-input-file str)\n (open-fi"..., 4096) = 2425
lseek(6, -2424, SEEK_CUR) = 2236
read(6, "pen-input-file str)\n (open-fil"..., 4096) = 2424
lseek(6, -2409, SEEK_CUR) = 2251
read(6, "str)\n (open-file str OPEN_READ"..., 4096) = 2409
lseek(6, -2408, SEEK_CUR) = 2252
read(6, "tr)\n (open-file str OPEN_READ)"..., 4096) = 2408
lseek(6, -2405, SEEK_CUR) = 2255
read(6, "\n (open-file str OPEN_READ))\n"..., 4096) = 2405
lseek(6, -2401, SEEK_CUR) = 2259
read(6, "open-file str OPEN_READ))\n\n(de"..., 4096) = 2401
lseek(6, -2400, SEEK_CUR) = 2260
read(6, "pen-file str OPEN_READ))\n\n(def"..., 4096) = 2400
lseek(6, -2391, SEEK_CUR) = 2269
read(6, "str OPEN_READ))\n\n(define (open"..., 4096) = 2391
lseek(6, -2390, SEEK_CUR) = 2270
read(6, "tr OPEN_READ))\n\n(define (open-"..., 4096) = 2390
lseek(6, -2387, SEEK_CUR) = 2273
read(6, "OPEN_READ))\n\n(define (open-out"..., 4096) = 2387
It seems to be trying to read a symbol at a time by reading a block,
seeking to the end of the symbol it's just parsed, and reading another
block.
Very very inefficient! (This appears to be while it's setting up Guile)
Eventually I worked out it's because lily.scm is not being
installed by
make install
and the default is to try to read it from stdin!
Peter C
