Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)

2014-05-30 Thread markpolesky

Reviewers: ,

Message:
Here's a new patch to tidy up the IR a little bit.  Please review.

- Mark

Description:
This patch uses (pretty-print) instead of (display) to show some IR
properties, such as alists and vectors, that are really hard to read as
it stands.

It increases the internals.pdf page-count from 638 to 651, but I believe
the increase in legibility is worth it.

View some examples at:
http://code.google.com/p/lilypond/issues/detail?id=3935

Please review this at https://codereview.appspot.com/95710044/

Affected files (+109, -53 lines):
  M scm/document-backend.scm
  M scm/document-context-mods.scm
  M scm/document-translation.scm
  M scm/documentation-lib.scm
  M scm/lily-library.scm



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)

2014-05-30 Thread Urs Liska

Am 30.05.2014 09:31, schrieb markpole...@gmail.com:

Reviewers: ,

Message:
Here's a new patch to tidy up the IR a little bit.  Please review.

- Mark

Description:
This patch uses (pretty-print) instead of (display) to show some IR
properties, such as alists and vectors, that are really hard to read as
it stands.

It increases the internals.pdf page-count from 638 to 651, but I believe
the increase in legibility is worth it.

View some examples at:
http://code.google.com/p/lilypond/issues/detail?id=3935

Please review this at https://codereview.appspot.com/95710044/

Affected files (+109, -53 lines):
   M scm/document-backend.scm
   M scm/document-context-mods.scm
   M scm/document-translation.scm
   M scm/documentation-lib.scm
   M scm/lily-library.scm




I can only judge from the example images on the google tracker, but 
these are definitely an improvement and (IMO) worth the extra pages.


Urs


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)

2014-05-30 Thread dak


https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode112
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
Comment makes no sense.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode138
scm/documentation-lib.scm:138: (lambda (port) (pretty-print val port
#:display? #t))
Wouldn't #:display? #t show a partial value of "string" as string
without quotes?  The examples in the issue report don't contain strings,
so it's hard to guess.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode144
scm/documentation-lib.scm:144: (string-regexp-substitute "\n " "\n  "
str)))
pretty-print has a key #:per-line-prefix.  Would that be easier to use?

https://codereview.appspot.com/95710044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)

2014-05-30 Thread markpolesky


https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode112
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
On 2014/05/30 08:38:23, dak wrote:

Comment makes no sense.


Would this pseudocode suffice?
  ; (ly-type? vector) => #t

The problem is that we need to make sure that most LilyPond internal
"datatypes" don't get displayed with @verbatim, since (pretty-print)
doesn't work on them, and they'll sail right past the page/screen
margin.  I'm not sure what else to call them; I'm referring to things
that look like # or # etc.

So this prevents that problem:
  (not (ly-type? val))

but causes another problem, namely that vectors would end up not getting
(pretty-print), which is the point after all.  Hence the conditional:
  (or (vector? val) ...

If the pseudocode I proposed above is still too abstruse, I welcome your
suggestions.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode138
scm/documentation-lib.scm:138: (lambda (port) (pretty-print val port
#:display? #t))
On 2014/05/30 08:38:23, dak wrote:

Wouldn't #:display? #t show a partial value of "string" as string

without

quotes?  The examples in the issue report don't contain strings, so

it's hard to

guess.


That's correct, no quotes, hence the added quotes a few lines below:
  (string-append "\"" str "\"")

An example is in the BarLine node, which after processing looks like
this in internals.texi:
  @item @code{glyph} (string):
  @code{"|"}

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode144
scm/documentation-lib.scm:144: (string-regexp-substitute "\n " "\n  "
str)))
On 2014/05/30 08:38:23, dak wrote:

pretty-print has a key #:per-line-prefix.  Would that be easier to

use?

Yes, thank you.

https://codereview.appspot.com/95710044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: varC clefs in 2.19

2014-05-30 Thread James

On 29/05/14 23:11, bobr...@centrum.is wrote:

I was just looking over the "changes" page for the current development version (2.19.x) 
and the section with the new clef glyphs caught my eye.  The example given for; \clef 
"varC" *seems* to be alto clef only.


Yes that seems right from the file changes.

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=476c0adbf748f1adcb6927a6197d13f3790c8a9b

scm/parser-clef.scm is the file that (I think) determines the position.



This clef in any position is a 'C' clef as it marks middle C.  I'm sure it must 
be possible to redefine the clef's position somehow, but this strikes me as an 
oversight, especially with all the other clef transpositions which are readily 
available.
Seems to be a documentation oversight actually if you look at the diff 
for the file parser-clef.scm there _is_ a tenor version.


I'm not a programmer, but I seem to remember trying to document these 
other clefs in that are in this file more coherently in, say, the 
appendix. I just never got fully around to it.


However can you see if this 'tenor' version is what you wanted?

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: varC clefs in 2.19

2014-05-30 Thread James

On 30/05/14 10:24, James wrote:

On 29/05/14 23:11, bobr...@centrum.is wrote:
I was just looking over the "changes" page for the current 
development version (2.19.x) and the section with the new clef glyphs 
caught my eye.  The example given for; \clef "varC" *seems* to be 
alto clef only.


Yes that seems right from the file changes.

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=476c0adbf748f1adcb6927a6197d13f3790c8a9b 



scm/parser-clef.scm is the file that (I think) determines the position.


This clef in any position is a 'C' clef as it marks middle C.  I'm 
sure it must be possible to redefine the clef's position somehow, but 
this strikes me as an oversight, especially with all the other clef 
transpositions which are readily available.
Seems to be a documentation oversight actually if you look at the diff 
for the file parser-clef.scm there _is_ a tenor version.


I'm not a programmer, but I seem to remember trying to document these 
other clefs in that are in this file more coherently in, say, the 
appendix. I just never got fully around to it.


However can you see if this 'tenor' version is what you wanted?

James


Sorry for replying to my own post. I forget sometimes that not everyone 
necessarily reads the code or cares about looking in the code tree in git


Assuming you can understand these files I am referring to then it should 
be obvious, but just in case (and so I apologize if I am patronizing 
you) you should be able to use


\clef "tenorvarC"

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)

2014-05-30 Thread markpolesky

On 2014/05/30 09:11:57, Mark Polesky wrote:

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode144

scm/documentation-lib.scm:144: (string-regexp-substitute "\n " "\n  "

str)))

On 2014/05/30 08:38:23, dak wrote:
> pretty-print has a key #:per-line-prefix.  Would that be easier to

use?


Yes, thank you.


I spoke too soon.  I don't think #:per-line-prefix will work with my
code structure here.  The regex substitution is there for items
prepended with a single-quote, which might not end up using
pretty-print.  Plus then we'd have to remove the first space anyway (or
replace it with the quote).  Unless you have some clever way of making
it work, I think I'll leave it as is.

https://codereview.appspot.com/95710044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)

2014-05-30 Thread dak


https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm
File scm/documentation-lib.scm (right):

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode112
scm/documentation-lib.scm:112: (or (vector? val) ; vector is an ly-type
On 2014/05/30 09:11:57, Mark Polesky wrote:

On 2014/05/30 08:38:23, dak wrote:
> Comment makes no sense.



Would this pseudocode suffice?
   ; (ly-type? vector) => #t


That's rubbish.  None of the given types in ly-type? should trigger for
a vector.  And indeed it would appear that the definition of
ly:music-list? is broken and returns #t for anything that is not a list.

Instead of trying to work around obvious bugs when one finds them, they
should be reported and fixed.

I'll do so, but of course your patch will then depend on mine.  I'll try
to fast-track it.

https://codereview.appspot.com/95710044/diff/20001/scm/documentation-lib.scm#newcode138
scm/documentation-lib.scm:138: (lambda (port) (pretty-print val port
#:display? #t))
On 2014/05/30 09:11:57, Mark Polesky wrote:

On 2014/05/30 08:38:23, dak wrote:
> Wouldn't #:display? #t show a partial value of "string" as string

without

> quotes?  The examples in the issue report don't contain strings, so

it's hard

to
> guess.



That's correct, no quotes, hence the added quotes a few lines below:
   (string-append "\"" str "\"")


But you'd get ("x" y") to print as (x y) then, wouldn't you?

An example is in the BarLine node, which after processing looks like

this in

internals.texi:
   @item @code{glyph} (string):
   @code{"|"}


https://codereview.appspot.com/95710044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: varC clefs in 2.19

2014-05-30 Thread bobr...@centrum.is


- Original Message -
From: "James" 
To: bobr...@centrum.is, "lilypond-devel" 
Sent: Friday, May 30, 2014 9:26:56 AM
Subject: Re: varC clefs in 2.19

On 30/05/14 10:24, James wrote:
> On 29/05/14 23:11, bobr...@centrum.is wrote:
>> I was just looking over the "changes" page for the current 
>> development version (2.19.x) and the section with the new clef glyphs 
>> caught my eye.  The example given for; \clef "varC" *seems* to be 
>> alto clef only.
>
> Yes that seems right from the file changes.
>
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=476c0adbf748f1adcb6927a6197d13f3790c8a9b
>  
>
>
> scm/parser-clef.scm is the file that (I think) determines the position.
>
>
>> This clef in any position is a 'C' clef as it marks middle C.  I'm 
>> sure it must be possible to redefine the clef's position somehow, but 
>> this strikes me as an oversight, especially with all the other clef 
>> transpositions which are readily available.
> Seems to be a documentation oversight actually if you look at the diff 
> for the file parser-clef.scm there _is_ a tenor version.
>
> I'm not a programmer, but I seem to remember trying to document these 
> other clefs in that are in this file more coherently in, say, the 
> appendix. I just never got fully around to it.
>
> However can you see if this 'tenor' version is what you wanted?
>
> James

Sorry for replying to my own post. I forget sometimes that not everyone 
necessarily reads the code or cares about looking in the code tree in git

Assuming you can understand these files I am referring to then it should 
be obvious, but just in case (and so I apologize if I am patronizing 
you) you should be able to use

\clef "tenorvarC"

James


I must confess that I've not been using 2.19.  My comments were based on my 
encounter with the "changes" page.  If \clef "tenorvarC" puts that 'varC' clef 
in the tenor position then my question is answered.

Thanks!

-David

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: varC clefs in 2.19

2014-05-30 Thread James

On 30/05/14 14:12, bobr...@centrum.is wrote:


- Original Message -
From: "James" 
To: bobr...@centrum.is, "lilypond-devel" 
Sent: Friday, May 30, 2014 9:26:56 AM
Subject: Re: varC clefs in 2.19

On 30/05/14 10:24, James wrote:

On 29/05/14 23:11, bobr...@centrum.is wrote:

I was just looking over the "changes" page for the current
development version (2.19.x) and the section with the new clef glyphs
caught my eye.  The example given for; \clef "varC" *seems* to be
alto clef only.

Yes that seems right from the file changes.

http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=476c0adbf748f1adcb6927a6197d13f3790c8a9b


scm/parser-clef.scm is the file that (I think) determines the position.



This clef in any position is a 'C' clef as it marks middle C.  I'm
sure it must be possible to redefine the clef's position somehow, but
this strikes me as an oversight, especially with all the other clef
transpositions which are readily available.

Seems to be a documentation oversight actually if you look at the diff
for the file parser-clef.scm there _is_ a tenor version.

I'm not a programmer, but I seem to remember trying to document these
other clefs in that are in this file more coherently in, say, the
appendix. I just never got fully around to it.

However can you see if this 'tenor' version is what you wanted?

James

Sorry for replying to my own post. I forget sometimes that not everyone
necessarily reads the code or cares about looking in the code tree in git

Assuming you can understand these files I am referring to then it should
be obvious, but just in case (and so I apologize if I am patronizing
you) you should be able to use

\clef "tenorvarC"

James


I must confess that I've not been using 2.19.  My comments were based on my encounter with the 
"changes" page.  If \clef "tenorvarC" puts that 'varC' clef in the tenor 
position then my question is answered.

Well let us know :)

Then we know it really does work as expected.

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


PATCHES: Countdown - June 2nd - 06:00 GMT

2014-05-30 Thread James
Hello,

3927

Enhancement Han-WennpushPatch: Make object files depend 
on
out/config.hh.  






3932

Other   Mark Poleskycountdown   Patch: Clean up code for sorting
grob-properties.






3935

Documentation   Mark Poleskyreview  Patch: Use (pretty-print) for 
some
IR props.   
3934

Enhancement David Kastrup   review  Patch: \compoundMeter should 
change
TimeSignature.stencil at Timing, not Staff level
3933

Documentation   Trevor Daniels  review  Use \tempo in Real music 
example
3930

UglyThomas Morely   review  parenthesizing very small objects 
returns
ugly output 
3926

Enhancement Mark Poleskyreview  Patch: Add \magnifyMusic; 
clarify
fontSize in docs.   
3902

UglyPhile Holmesreview  the position of the initial \voiceOne 
rest
is suboptimal   






3937

Enhancement David Kastrup   new Patch: Support \once\unset  






3186

UglyJanek Warchol   waiting Positioning of "8" under clef 
symbol in
G_8 clef   Bounty   Jan 26
3156

Enhancement Mike Solomonwaiting Patch: Prevents 
vertical axis
groups with empty skylines  Feb 2013
3134

Enhancement Mike Solomonwaiting Patch: Removes the 
translate_axis
call from axis-group-interface outside-staff positioning.   Aug 2013
2812


Re: Issue 3935: Use (pretty-print) for some IR props. (issue 95710044)

2014-05-30 Thread markpolesky

On 2014/05/30 10:45:36, dak wrote:

   ; (ly-type? vector) => #t



That's rubbish.  None of the given types in ly-type? should trigger

for a

vector.  And indeed it would appear that the definition of

ly:music-list? is

broken and returns #t for anything that is not a list.


Your new commit still leaves this situation:
  (ly:music-list? '()) => #t

Is that intended?


Instead of trying to work around obvious bugs when one finds them,

they should

be reported and fixed.


Well, in my defense, I didn't realize it was a bug, but thanks for the
speedy fix.


That's correct, no quotes, hence the added quotes a few lines below:
   (string-append "\"" str "\"")



But you'd get ("x" y") to print as (x y) then, wouldn't you?


Yes, I hadn't noticed that.  I had added `#:display #t' because without
it, even slightly long lines would get wrapped, even when (pretty-print)
was given a large value of #:width:

'(...
  (-1 . "accidentals.flatflat")
  (3/4
   .
   "accidentals.sharp.slashslash.stemstemstem")
  (1/4 . "accidentals.sharp.slashslash.stem")
  ...)

Is that a bug with (pretty-print #:width ...)?  Or am I misunderstanding
something?  Anyway, you are right; as it stands, my patch drops the
double-quotes with these strings:

'(...
  (-1 . accidentals.flatflat)
  (3/4 . accidentals.sharp.slashslash.stemstemstem)
  (1/4 . accidentals.sharp.slashslash.stem)
  ...)

What would you suggest?  Should I recurse into the prop-values to put
quotes around all those inner strings?  Or just accept the needless
line-wrapping (which is ugly to me)?  Do I need to file a guile bug?
For now, I'll remove the `#:display' since it's not right.

I've uploaded a new patch that incorporates your new commit and other
things, including a more maintainable definition of `ly-type?'.  Please
check it out.

Thanks!
- Mark

https://codereview.appspot.com/95710044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: guile-1.8 to be removed from debian unstable before the freeze (5th of November)

2014-05-30 Thread Don Armstrong
On Fri, 23 May 2014, Federico Bruni wrote:
> Have you seen this email from guile maintainer?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005
> 
> "I'm planning to have guile-1.8 removed from unstable before the
> freeze; please migrate to guile-2.0 as soon as possible."
> 
> Does it mean that lilypond can be removed from debian repository if it's
> not upgraded to guile-2?

Either 1) lilypond will be updated to work with guile 2, 2) the
maintainer can be convinced to keep maintaining guile 1.8, or 3)
lilypond will have to be removed.

I'd prefer that #1 happened, of course.

> This is the open issue, right?
> http://code.google.com/p/lilypond/issues/detail?id=1055

I believe so, yes.

There's also an additional problem that texi2html is no longer being
maintained, and everything should switch to makeinfo --html.
This (I believe) is
http://code.google.com/p/lilypond/issues/detail?id=1000. I've requested
that texi2html stay around for the time being, but it's likely that this
will only be a viable short-term solution.

-- 
Don Armstrong  http://www.donarmstrong.com

Q: What Can a Thoughtful Man Hope for Mankind on Earth, Given the
Experience of the Past Million Years?
A: Nothing.
 -- Bokonon _The Fourteenth Book of Bokonon_ (Vonnegut _Cats Cradle_)

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel