Re: GOP-PROP 8: issue priorities (probable decision)
On Sat, Aug 13, 2011 at 07:12:53AM +0200, David Kastrup wrote: Keith OHara k-ohara5...@oco.net writes: Issue 1809 is an interesting test of this policy. `make test` sometimes crashes for some programmers, making it very hard for them to contribute, but it crashes in the Guile garbage collection, so we might be powerless to resolve the issue. It crashes because the internal garbage collector data structures have been clobbered. Which is likely due to some Lilypond code problem (like data available too early for collection). So it is likely that we are not powerless to resolve the issue, but since the crash is happening at a point rather remote from the likely bug and is quite sensitive to the memory layout of the code, it is really hard to track down. If it's at all relevant, we haven't heard any complaints about thsi before a month or two ago. Without a reliable test, this doesn't really help in narrowing down the scope of the problem -- but I do believe that it's due to (or at least, exacerbated by) a relatively recent lilypond code change. I think we can avoid the horns of the dilemma, though: - if it crashes regularly, (safe) contribution is impossible. But then we have a reliable (or at least reliable-ish) test case. - if it crashes very infrequently, (safe) contribution is a pain, but not impossible. Given the frequency I've heard about, I'd rank this as type-Maintainability, rather than type-Critical. With a note that if anybody can reproduce it with a command-line more than 30% of the time, we'll bump it up to type-Critical. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
David Kastrup wrote Saturday, August 13, 2011 6:12 AM It crashes because the internal garbage collector data structures have been clobbered. Which is likely due to some Lilypond code problem (like data available too early for collection). So it is likely that we are not powerless to resolve the issue, but since the crash is happening at a point rather remote from the likely bug and is quite sensitive to the memory layout of the code, it is really hard to track down. This type of problem used to occur quite frequently in 1970s IBM operating systems, when all the code of the OS ran in the same address space. The hardest bugs to find and fix were when something was clobbered in a way which caused a crash much later. In fact most of these were never resolved. The only way to make progress (when it was possible) was to identify a signature of the crash which allowed a trap to be set so a core dump could be obtained a little earlier, and repeat. Often setting the trap disturbed things in such a way that the crash no longer occurred because something less critical was being clobbered. Maybe that was a fix of some sort. Even that approach doesn't seem possible here, as we don't have access to the garbage collector. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3829 - Release Date: 08/12/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Nested context properties -- an implementation sketch
Ok, so I have been trying to get a hold on the nested context property thing. The main issue is getting a grip of how to update stuff on removal. With regard to nested context properties, an update further down in the nested property alist can have repercussions further up if some parts of the lower hierarchies have been used in setting up a nested context property alist further up in the hierarchy. There are basically two approaches I see possible for dealing with this: a) when removing a higher-level property further down in the stack, replace its conses, possibly consulted further up, with copies of the next property lower down in the stack. But if I have set a property 'x with a value ((y . ((z . 4, then the property handler has no business overwriting the internals of my property just because he copied them for filling in the blanks when setting a nested property (x y c). b) update stuff further up the stack. I've implemented this as Scheme for experimenting with, probably with bugs remaining. Other key elements: A revert will _only_ match an override with the _same_ signature, the signature consisting of the state of the \once flag as well as the full property path. This makes sure that unexpected pairings of reverts with overrides will be kept to a minimum. \once\override will _not_ register the old value of the setting. Instead, every not-yet cancelled \once will get cancelled at the end of the time step. I don't think that anything close to a sensible implementation can be significantly simpler or significantly more efficient. There are some things that may be nicer to do in C, and some shortcuts that may be taken. But as a functional sketch, this should more or less be what it takes. I don't think we can get this much cheaper. ;; Plan: context contains, in contrast to the current Lilypond ;; implementation, an additional source list for context overrides ;; corresponding to the cache list member by member. The source list ;; stops with the last override in the context and does not continue ;; into parenting contexts. ;; ;; In this file, this list is titled source and the actual override ;; list is titled cache. source is not really the most accurate ;; description since it merely contains _additional_ data. ;; ;; Structure of context (only changed destructively). ;; car - parenting context or #f ;; cadr - source ;; cddr - list head for contexts as currently existing: ;; caddr - cache, the property list for this context including ;; parents ;; cdddr - tail. The cache is only valid if the cache of the ;; parent is valid and eq to this context's tail. ;; ;; Structure of source: a list exactly as long as the list reaching ;; from cache inclusively to tail exclusively, and associated 1:1 with ;; the respective list elements. Each element of source has the ;; following parts: ;; car - records whether this property was entered with \once or ;; not. ;; cdr - length of nested property path. After this many cdar ;; calls on the property alist, you reach the set value of ;; the nested property. All other content of the property ;; alist entry is taken from other alist entries. ;; ;; The cache is never changed destructively, instead new copies are ;; created for changes. Any parts of the cache that are eq to some ;; part of the structure at an arbitrary different point of time, are ;; for this reason unchanged. (use-modules (ice-9 optargs) (srfi srfi-1) (srfi srfi-2)) (use-modules (ice-9 debug)) (define* (make-context #:optional parent) (cons parent (cons '() (cons '() (if parent (caddr parent) '()) (define (updatecache source oldcache newcache) updatecache should be called with (fold-right updatecache cachetail oldcachelist sourcelist) cachetail contains the new tail for the cache which has lost sync with the previous cache. (let loop ((depth (cdr source)) (oldcache oldcache) (newcache newcache)) (if (zero? depth) ;; entry is the original data entry in this list without copied ;; material so we just cons it up and continue. (cons oldcache newcache) ;; Now we may need to update a nested property override. This ;; is tricky. The property (car oldcache)'s nested property ;; list (cdr oldcache) starts with an override in the first ;; position (cadr oldcache) followed by the top level ;; original nested list (cddr oldcache). If the original for ;; the copied nested list has remained eq, the whole entry can ;; stay the way it is. If we had a sibling override, we need ;; not copy the whole depth of the recursion but only up to ;; the level where the chain is again intact. So we can solve ;; this problem in a recursive manner. Don't even dream of ;; using ly:assoc-get here: strict eq is vital for getting ;; this right.
Re: Adds a glyph for tied lyrics. (issue 4808074)
Here's how a better solution should work: * create a smaller tie in addition to this one * use a scm regexp to find this special case; something like: #(use-modules (ice-9 regex)) #(display (regexp-substitute #f (string-match ([^:])~([^:])~([^:]) questa~è~in) 'pre 1 2 3 'post)) But I don't have time to do it right now. I'll push this patch when the countdown will be over and make another patch later for this special case. http://codereview.appspot.com/4808074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Texi2HTML: don't wrap p around the contents of table cells. (issue 4891044)
Reviewers: ,
Message:
This patch prevents all table cells in our documentation from being
wrapped with a p, which causes huge spacing, like in
http://lilypond.org/doc/v2.14/Documentation/learning/on-the-un_002dnestedness-of-brackets-and-ties.html
http://lilypond.org/doc/v2.14/Documentation/learning/engravers-explained
http://lilypond.org/doc/v2.14/Documentation/music-glossary/pitch-names
Please review
Description:
Texi2HTML: don't wrap p around the contents of table cells.
This fixes the ugly huge space around table cells in our
documentation
Please review this at http://codereview.appspot.com/4891044/
Affected files:
M Documentation/lilypond-texi2html.init
Index: Documentation/lilypond-texi2html.init
diff --git a/Documentation/lilypond-texi2html.init
b/Documentation/lilypond-texi2html.init
index
6814aafed73b77435468900be865f84cf339a508..e0ebeae75a76d0b96e269e009cf94320f8381354
100644
--- a/Documentation/lilypond-texi2html.init
+++ b/Documentation/lilypond-texi2html.init
@@ -55,6 +55,8 @@
### makeinfo_like_foot_line_and_ref
### makeinfo_like_foot_lines
### makeinfo_like_paragraph
+### -) In tables, don't wrap p around the contents. Implemented in
+### makeinfo_like_paragraph
###
###
### Useful helper functions:
@@ -2070,6 +2072,13 @@ sub makeinfo_like_paragraph ($)
return $text if (($format eq 'itemize' or $format
eq 'enumerate') and
($$paragraph_number == 1));
}
+# The cells of a table should not be wrapped in a p tag, so just
return the text
+if (defined ($command_stack_at_begin-[0]) and
$command_stack_at_begin-[0] eq 'multitable')
+{
+return $text;
+}
+
+# Adjust all footnotes so that they look like good old makeinfo
my $open = 'p';
if ($align)
{
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
topdocs?
Hello. I have found http://lilypond.org/doc/v2.14/Documentation/topdocs/ and http://lilypond.org/doc/v2.14/Documentation/topdocs/AUTHORS which are not linked from anywhere AFAIK. Given that we now have different pages for author listings, maybe we could get rid of those. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Loglevels: Developer documentation (issue 4896042)
Reviewers: , Message: Assuming that there will not be major objections for the loglevels patch on the 48-hour countdown, here is a patch that documents the various logging functions in the contributor's guild. Description: Loglevels: Developer documentation Please review this at http://codereview.appspot.com/4896042/ Affected files: M Documentation/contributor/programming-work.itexi ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
On 12 August 2011 01:44, Carl Sorensen c_soren...@byu.edu wrote:
Yep. Here it is, along with the change to /usr/bin/env guile.
I had to change this to
/usr/bin/guile
to get the script to work:
/usr/bin/env: guile -s: No such file or directory
I think I'm really going to like having this, if we can get all the bugs
worked out..
I've just tested it on a few files, and there are several problems:
1) it introduces whitespace on blank lines
2) inside an `if', comments are counted, leading to incorrect
indentation for the subexpressions
3) subexpression inside `begin' are indented only one space
4) if a top-level form is erroneously indented (e.g.,
`set-music-properties!' in music-functions.scm), the rest of the file
also gets the same indentation
I've attached a diff which only shows the indentation changes (i.e.,
tab-space conversion is ignored).
Cheers,
Neil
diff --git a/scm/music-functions.scm b/scm/music-functions.scm
index 0266f63..6c27a86 100644
--- a/scm/music-functions.scm
+++ b/scm/music-functions.scm
@@ -68,7 +68,7 @@ First it recurses over the children, then the function is applied to
(define-public (music-filter pred? music)
Filter out music expressions that do not satisfy @var{pred?}.
-
+
(define (inner-music-filter pred? music)
Recursive function.
(let* ((es (ly:music-property music 'elements))
@@ -89,7 +89,7 @@ First it recurses over the children, then the function is applied to
(ly:music? e
(set! music '()))
music))
-
+
(set! music (inner-music-filter pred? music))
(if (ly:music? music)
music
@@ -98,7 +98,7 @@ First it recurses over the children, then the function is applied to
(define-public (display-music music)
Display music, not done with @code{music-map} for clarity of
presentation.
-
+
(display music)
(display : { )
(let ((es (ly:music-property music 'elements))
@@ -110,8 +110,8 @@ presentation.
(display }\n)))
(if (ly:music? e)
(begin
- (display \nChild:)
- (display-music e
+ (display \nChild:)
+ (display-music e
(display }\n)
music)
@@ -135,7 +135,7 @@ For instance,
((and (not (string? arg)) (markup? arg)) ;; a markup
(inner-markup-make-markup arg))
(else ;; scheme arg
- (music-make-music arg
+(music-make-music arg
(define (inner-markup-make-markup mrkup)
(if (string? mrkup)
`(#:simple ,mrkup)
@@ -167,20 +167,20 @@ equivalent to @var{obj}, that is, for a music expression, a
(;; moment
(ly:moment? obj)
`(ly:make-moment ,(ly:moment-main-numerator obj)
- ,(ly:moment-main-denominator obj)
- ,(ly:moment-grace-numerator obj)
- ,(ly:moment-grace-denominator obj)))
+ ,(ly:moment-main-denominator obj)
+ ,(ly:moment-grace-numerator obj)
+ ,(ly:moment-grace-denominator obj)))
(;; note duration
(ly:duration? obj)
`(ly:make-duration ,(ly:duration-log obj)
-,(ly:duration-dot-count obj)
-,(car (ly:duration-factor obj))
-,(cdr (ly:duration-factor obj
+ ,(ly:duration-dot-count obj)
+ ,(car (ly:duration-factor obj))
+ ,(cdr (ly:duration-factor obj
(;; note pitch
(ly:pitch? obj)
`(ly:make-pitch ,(ly:pitch-octave obj)
- ,(ly:pitch-notename obj)
- ,(ly:pitch-alteration obj)))
+ ,(ly:pitch-notename obj)
+ ,(ly:pitch-alteration obj)))
(;; scheme procedure
(procedure? obj)
(or (procedure-name obj) obj))
@@ -196,7 +196,7 @@ equivalent to @var{obj}, that is, for a music expression, a
(;; a pair
(pair? obj)
`(cons ,(music-make-music (car obj))
-,(music-make-music (cdr obj
+ ,(music-make-music (cdr obj
(else
obj)))
@@ -223,8 +223,8 @@ Returns `obj'.
(parameterize ((*indent* 0)
(*previous-duration* (ly:make-duration 2))
(*force-duration* force-duration))
-(display (music-lily-string expr parser))
-(newline)))
+(display (music-lily-string expr parser))
+(newline)))
@@ -262,11 +262,11 @@ through MUSIC.
(if (ly:duration? dur)
dur
(loop (cdr elts
-
+
(let ((talts (if ( times (length alts))
(begin
- (ly:warning (_ More alternatives than repeats. Junking excess alternatives))
- (take alts times))
+(ly:warning (_ More
Re: Adds a glyph for tied lyrics. (issue 4808074)
LGTM. http://codereview.appspot.com/4808074/diff/7001/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/4808074/diff/7001/scm/define-markup-commands.scm#newcode943 scm/define-markup-commands.scm:943: (tie-str (markup #:hspace (/ word-space 2) use separate binding for (/ word-space 2) http://codereview.appspot.com/4808074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Ends of barlines are hidden in staff lines. (issue 4809057)
http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc File lily/bar-line.cc (right): http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc#newcode40 lily/bar-line.cc:40: /* Due to rounding problems, barlines extending to the outermost edges bar lines http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc#newcode43 lily/bar-line.cc:43: The solution is to extend barlines only to the middle bar lines http://codereview.appspot.com/4809057/diff/1/lily/bar-line.cc#newcode48 lily/bar-line.cc:48: SCM staff_color = Staff_symbol_referencer::color (me); I think it's overkill to define a new method just to access 'color from a stave (unless you plan on using it elsewhere) SCM staff_color = staff-get_property (color); http://codereview.appspot.com/4809057/diff/1/lily/staff-symbol-referencer.cc File lily/staff-symbol-referencer.cc (right): http://codereview.appspot.com/4809057/diff/1/lily/staff-symbol-referencer.cc#newcode72 lily/staff-symbol-referencer.cc:72: return ly_symbol2scm (black); 'color is a list: (list R G B) http://codereview.appspot.com/4809057/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
chaotic stems when querying direction property
Hi list,
I'm having a problem with a scheme engraver. Whenever I fetch the
direction property of a grob's stem object (or directly through a
listener on stem-event), the following warning is shown:
warning: no viable initial configuration found: may not find good
beam slope
The resulting score has a few notes with their stems pointing in the
wrong direction, so that the beams have a terribly ugly slope. As soon
as I remove the code to store the direction everything is fine again.
I've attached a simple demo file where the chaotic stem directions can
be observed. All the code does is to save all grobs it encounters during
the acknowledge phase and then query the direction for each stored grob
during the processing phase.
I'd be happy if you could explain to me why this happens.
Best,
Rekado
\version 2.14.2
% ---
#(define my-engraver
(let ((grobs '()))
(list
;; process each note object with each saved grob
(cons 'process-acknowledged
(lambda (trans)
(for-each
(lambda (grob)
(if (ly:grob? grob)
(let* ((stem-grob (ly:grob-object grob 'stem))
(direction (ly:grob-property stem-grob
'direction)))
(display direction)
))) grobs)))
;; save grob for processing
(cons 'acknowledgers
(list
(cons 'note-head-interface
(lambda (engraver grob source-engraver)
(set! grobs (append grobs (list grob)
))
)))
% ---
\score {
\new Staff {
\clef bass
\key c \major
\new MyVoice {
\relative f {
%e8-4\8
r2.. e8-4\8 ~ e
e,8-1\7 fis-2 g16-1 g-2 a8-4 cis-1\8 d-2 e8-4
}
}
}
\layout {
\context {
\Voice
\name MyVoice
\alias Voice
\description A voice using my engraver
\remove Fingering_engraver
\remove New_fingering_engraver
\consists \my-engraver
}
\context {
\Staff
\accepts MyVoice
}
}
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: chaotic stems when querying direction property
On 13 August 2011 17:14, Ricardo Wurmus ricardo.wur...@gmail.com wrote: I'm having a problem with a scheme engraver. Whenever I fetch the direction property of a grob's stem object (or directly through a listener on stem-event), the following warning is shown: warning: no viable initial configuration found: may not find good beam slope The resulting score has a few notes with their stems pointing in the wrong direction, so that the beams have a terribly ugly slope. As soon as I remove the code to store the direction everything is fine again. I've attached a simple demo file where the chaotic stem directions can be observed. All the code does is to save all grobs it encounters during the acknowledge phase and then query the direction for each stored grob during the processing phase. I'd be happy if you could explain to me why this happens. The stems of beamed notes have a dependency on beam direction, so if you try to get the direction of a stem which is part of a beam that hasn't been completed it can mess up the calculation (i.e., you end up with a disagreement between beam/stem directions in some cases). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (probable decision)
Graham Percival wrote Thursday, August 11, 2011 8:41 PM On Thu, Aug 11, 2011 at 12:32:09PM -0700, Keith OHara wrote: On Wed, 10 Aug 2011 22:06:16 -0700, Graham Percival gra...@percival-music.ca wrote: On Thu, 11 Aug 2011 00:02:51 -0700, Trevor Daniels t.dani...@treda.co.uk wrote: Graham Percival graham at percival-music.ca writes: * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. That will work; now we can think of a name for the label. Need_clarification Need_goal What_should_Lily_do I like Colin's suggestion of Type-ambiguous. Not sure ambiguous quite captures the correct meaning, and I don't think we want Type if this is to be a label. I like Keith's Needs. This easily extends to several labels if we find that is desirable. Other suggestions: Needs_input Needs_data Needs_sources Needs_references Needs_evidence Needs_support or simply Needs_more Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3830 - Release Date: 08/12/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
Am Saturday, 13. August 2011, 17:44:52 schrieb Neil Puttock: On 12 August 2011 01:44, Carl Sorensen c_soren...@byu.edu wrote: Yep. Here it is, along with the change to /usr/bin/env guile. I had to change this to /usr/bin/guile to get the script to work: /usr/bin/env: guile -s: No such file or directory We don't need the -s argument, so we can simply use #!/usr/bin/env guile This works here, while guile -s didn't work here, either, see e.g. http://en.wikipedia.org/wiki/Shebang_(Unix)#Portability Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: topdocs?
On Sat, Aug 13, 2011 at 04:21:41PM +0200, Francisco Vila wrote: Hello. I have found http://lilypond.org/doc/v2.14/Documentation/topdocs/ which are not linked from anywhere AFAIK. Given that we now have different pages for author listings, maybe we could get rid of those. Aren't those used to create text files for a source tarball release (for compliance with GNU tarball specifications) ? Particularly the INSTALL.texi ? I'm not opposed to getting rid of them, but this involves: - the build system - GUB - external demands/suggestions for packaging I'm calling this ETA: 10 hours. Certainly more than 3 hours for me personally to do it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Comand token too long?
Hello, does anybody what this error means? cd Documentation/ cd ./out-www; texi2pdf -I ./out-www -I ../out -I .. -I .. --quiet notation.texi egrep: Invalid range end Error (196): Command token too long Error (196): Command token too long Doc compilation ends successfuly, but an error is an error. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
On 8/13/11 9:44 AM, Neil Puttock n.putt...@gmail.com wrote: On 12 August 2011 01:44, Carl Sorensen c_soren...@byu.edu wrote: Yep. Here it is, along with the change to /usr/bin/env guile. I had to change this to /usr/bin/guile to get the script to work: /usr/bin/env: guile -s: No such file or directory Thanks. I'll get this worked out, I think. I think I'm really going to like having this, if we can get all the bugs worked out.. I've just tested it on a few files, and there are several problems: 1) it introduces whitespace on blank lines I had missed that difference. That's now fixed. 2) inside an `if', comments are counted, leading to incorrect indentation for the subexpressions Good catch. I'm not sure how I'll fix that, but I certainly need to. 3) subexpression inside `begin' are indented only one space De we have a standard for how much indentation we should have for each type of compound expression? define let begin all get two, apparently. I see some sources that show that list gets one. Are you aware of a definitive statement I can follow? 4) if a top-level form is erroneously indented (e.g., `set-music-properties!' in music-functions.scm), the rest of the file also gets the same indentation Thanks for catching that. I've fixed it so all top-level forms start at column zero. I've attached a diff which only shows the indentation changes (i.e., tab-space conversion is ignored). How did you do this? Did you do tab expansion on the file in an editor, then run it through guileindent.scm? Once I've fixed all the issues you've raised and done some more experimentation, I'll post a new patch. Actually, since there has been no outcry saying This is a stupid thing to do I'll add it to scripts/auxiliar and post it on Rietveld for review. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
2011/8/13 Francisco Vila paconet@gmail.com: Hello, does anybody what this error means? cd Documentation/ cd ./out-www; texi2pdf -I ./out-www -I ../out -I .. -I .. --quiet notation.texi egrep: Invalid range end This is caused by line 1713 of /usr/bin/texi2dvi (GNU Texinfo 4.13) 1.135 in my system, # If the COMMAND_LINE_FILENAME is not absolute (e.g., --debug.tex), # prepend `./' in order to avoid that the tools take it as an option. echo $command_line_filename | $EGREP '^(/|[A-z]:/)' 6 \ || command_line_filename=./$command_line_filename and [A-z] is an invalid range. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
Am Saturday, 13. August 2011, 21:05:13 schrieb Francisco Vila:
Hello, does anybody what this error means?
cd Documentation/
cd ./out-www; texi2pdf -I ./out-www -I ../out -I .. -I .. --quiet
notation.texi egrep: Invalid range end
Bug in texi2dvi. egrep doesn't like a range [A-z]... Probably needs to be
changed to [A-Za-z]?
Error (196): Command token too long
Error (196): Command token too long
Doc compilation ends successfuly, but an error is an error.
Yes, I tried to debug it a few days ago. The problem is that some of the
generated PDF files for a system are somehow broken. I haven't found out what
exactly is the problem. Attached is a stripped down example.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
\input texinfo
@comment @setfilename collated-files.tely.info
@comment @settitle LilyPond Regression Tests
@documentencoding utf-8
@comment @node Top, , , (dir)
@comment @top LilyPond Regression Tests
@c generated from input/regression/page-break-turn-toplevel.ly
@image{lily-1cae1978-4}
@bye
lily-1cae1978-4.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script for auto-indenting .scm files.
On 13 August 2011 20:06, Carl Sorensen c_soren...@byu.edu wrote: De we have a standard for how much indentation we should have for each type of compound expression? define let begin all get two, apparently. I see some sources that show that list gets one. Are you aware of a definitive statement I can follow? Not really; I'm just comparing it to Emacs* (which is by no means perfect; I've got several additions to my .emacs file for things like lambda* and parameterize). * http://cvs.savannah.gnu.org/viewvc/emacs/emacs/lisp/progmodes/scheme.el?view=markup How did you do this? Did you do tab expansion on the file in an editor, then run it through guileindent.scm? Yes (M-x untabify). Once I've fixed all the issues you've raised and done some more experimentation, I'll post a new patch. Great. I could've listed some more issues, but I think the majority of them are glaringly obvious in the diff. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
Hello, does anybody what this error means? cd Documentation/ cd ./out-www; texi2pdf -I ./out-www -I ../out -I .. -I .. --quiet notation.texi egrep: Invalid range end Bug in texi2dvi. egrep doesn't like a range [A-z]... Probably needs to be changed to [A-Za-z]? Fixed already in texinfo's CVS (since 2010-03-30). We might add the CVS version of texi2dvi to lilypond... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilydev remix iso - where
The lilynet website still seems to be under construction. In particular the lilydev remix iso is not available from the link in the CG. (I guess this should be a critical bug under the proposed new classification scheme.) I'd actually like to obtain it, as I need to reinstall my ubuntu system and want to upgrade to it. Is it available anywhere else? Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3831 - Release Date: 08/13/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilydev remix iso - where
On Sat, Aug 13, 2011 at 5:53 PM, Trevor Daniels t.dani...@treda.co.uk wrote: The lilynet website still seems to be under construction. In particular the lilydev remix iso is not available from the link in the CG. (I guess this should be a critical bug under the proposed new classification scheme.) I'd actually like to obtain it, as I need to reinstall my ubuntu system and want to upgrade to it. Is it available anywhere else? I have it but it's 827MB. Do you have a server where I could upload it for you? Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
Francisco Vila: 2011/8/13 Francisco Vila paconet@gmail.com: Hello, does anybody what this error means? cd Documentation/ cd ./out-www; texi2pdf -I ./out-www -I ../out -I .. -I .. --quiet notation.texi egrep: Invalid range end This is caused by line 1713 of /usr/bin/texi2dvi (GNU Texinfo 4.13) 1.135 in my system, # If the COMMAND_LINE_FILENAME is not absolute (e.g., --debug.tex), # prepend `./' in order to avoid that the tools take it as an option. echo $command_line_filename | $EGREP '^(/|[A-z]:/)' 6 \ || command_line_filename=./$command_line_filename and [A-z] is an invalid range. Works here: $ echo '/usr/' | egrep '^(/|[A-z]:/)' /usr/ $ echo 'B:/' | egrep '^(/|[A-z]:/)' B:/ $ echo 'z:/' | egrep '^(/|[A-z]:/)' z:/ $ echo 'bin/' | egrep '^(/|[A-z]:/)' $ egrep --version | head -1 GNU grep 2.6.3 $ echo $LANG C $ [A-z] is a valid range in the C locale. Maybe you have a locale with a sorting order where z comes before A. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
Am Sunday, 14. August 2011, 03:36:05 schrieb Karl Hammar: Works here: Doesn't work here on a German Kubuntu system: $ echo '/usr/' | egrep '^(/|[A-z]:/)' /usr/ $ echo '/usr/' | egrep '^(/|[A-z]:/)' egrep: Das Ende des angegebenen Intervalls ist nicht gültig (No output; same result for all the other examples you gave) $ egrep --version | head -1 GNU grep 2.6.3 $ egrep --version | head -1 GNU grep 2.6.3 $ echo $LANG C $ echo $LANG de_AT.UTF-8 Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
