Issue 2024: Let #{ ... #} pass its $ handling to environment cloning

Issue 2024: Let #{ ... #} pass its $ handling to environment cloning

Consists of the patches:

Adapt docs to new $ and #{ ... #} behavior


Run scripts/auxiliar/update-with-convert-ly.sh


Let #{ ... #} pass its $ handling to environment cloning

Includes convertrules.py rules

Permit ly:parser-clone to receive an environment


lexer.ll: add $ for immediate export.



Purpose is to make $ generally available rather than to have it just
in #{ ... #}, let it completely replace the need for ly:export, and to
let #{ ... #} import its lexical environment into its embedded Scheme
expressions via # or $.

Unfortunately, you will likely have to bump PATCHLEVEL in VERSION
manually for testing, as dev/staging is still locked at 2.15.17 which
is too small after running convert-ly.

[Trevor Daniels, 2011-11-08 16:37:25]

I don't claim to understand much of this, but the resulting simplification seems
worth the pain to me.  The expectation that convert-ly will generate many
changes to (advanced) user code suggests changes.tely needs a clear notice
adding explaining what has been done.

Trevor

http://codereview.appspot.com/5341049/diff/2001/Documentation/extending/progr...
File Documentation/extending/programming-interface.itely (right):

http://codereview.appspot.com/5341049/diff/2001/Documentation/extending/progr...
Documentation/extending/programming-interface.itely:44: It extracts the Lilypond
code block and generates a call to the
LilyPond

http://codereview.appspot.com/5341049/diff/2001/Documentation/extending/progr...
Documentation/extending/programming-interface.itely:47: the lexical environment
of the Lilypond code block, so you have access
LilyPond

http://codereview.appspot.com/5341049/diff/2001/Documentation/extending/progr...
Documentation/extending/programming-interface.itely:48: to local variables and
function parameters at the point the Lilypond
LilyPond

[dak, 2011-11-08 17:24:03]

On 2011/11/08 16:37:25, Trevor Daniels wrote:
> I don't claim to understand much of this, but the resulting simplification
seems
> worth the pain to me.

Obviously to me as well.  I want to stress that I did _no_ manual changes to
Documentation and regtests, and even converted scm/music-functions.scm (with a
manual call of convert-ly as it can't be done automatically, missing a version
string) with convert-ly.

> The expectation that convert-ly will generate many
> changes to (advanced) user code suggests changes.tely needs a clear notice
> adding explaining what has been done.

Not just changes.tely: quite a bit more documentation is warranted (and will be
forthcoming).  However, most of it makes the best sense once ly:export has
actually been removed, and # has lost its feature of immediate execution.

The behavior of $ is actually easy to explain: $something-in-scheme is perfectly
equivalent to \id once id has been set (where is is allowed) with
id=#something-in-scheme.

Basically equivalent to the most common of the half dozen special cases
previously just available in #{ ... #}.

The five functions add-grace-property, remove-grace-property, empty-music,
set-accidental-style and set-time-signature really need to get replaced by
sensibly named music functions in a separate step. They are responsible for a
user interface oddity that is now even more apparent.  Once that has been done,
$ should no longer crop up in the documentation in places where it does not
actually belong, given the respective topic and level of its surrounding
material.

That would make it easier to pick the right point for addressing it in detail.

I'll incorporate your detailed comments likely sometime tomorrow, as I have
choir practice soon.

[Carl, 2011-11-08 17:46:10]

I *really* like this change.  It simplifies and clarifies things tremendously.

Some time ago, Han-Wen mentioned his concern that most of the development on
LilyPond was basically code-janitoring.  IMO, this qualifies as something much
better than that.

I support you in being serious about implementing this -- we definitely should
do it.

Thanks,

Carl

[wl_gnu.org, 2011-11-08 18:44:53]

>> I don't claim to understand much of this, but the resulting
>> simplification seems worth the pain to me.

Me too.

> The behavior of $ is actually easy to explain: $something-in-scheme
> is perfectly equivalent to \id once id has been set (where is is
> allowed) with id=#something-in-scheme.

Ah.  This isn't obvious without documentation, as you've already
stated.


    Werner

[pkx166h, 2011-11-08 21:04:34]

This didn't pass 'make'. Not sure if it is JUST the version number (not sure how
to test this patch otherwise) or if there is an additional problem. I can also
do a full make doc when it passes make.

--snip--

error: program too old: 2.15.17 (file requires: 2.15.18)
/home/jlowe/lilypond-git/ly/engraver-init.ly:19:9: error: syntax error,
unexpected \version-error
\version 
         "2.15.18"
]]
 [/home/jlowe/lilypond-git/ly/generate-documentation.ly
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/documentation-lib.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/lily-sort.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-functions.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-translation.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-music.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-type-predicates.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-identifiers.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-context-mods.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-backend.scm]
[/home/jlowe/lilypond-git/build/out/share/lilypond/current/scm/document-markup.scm]
Writing "internals.texi"...
]]
programming error: Parsed object should be dead: static scm_unused_struct*
Prob::mark_smob(scm_unused_struct*)
continuing, cross fingers
programming error: Parsed object should be dead: static scm_unused_struct*
Context_mod::mark_smob(scm_unused_struct*)
continuing, cross fingers
programming error: Parsed object should be dead: static scm_unused_struct*
Context_def::mark_smob(scm_unused_struct*)
continuing, cross fingers
fatal error: failed files: "/home/jlowe/lilypond-git/ly/generate-documentation"
make[1]: *** [out/internals.texi] Error 1
make[1]: Leaving directory `/home/jlowe/lilypond-git/build/Documentation'
make: *** [all] Error 2
jlowe@jlowe-lilybuntu2:~/lilypond-git/build$ 

--snip--

James

[c_sorensen, 2011-11-08 21:49:19]

On 11/8/11 2:04 PM, "pkx166h@gmail.com" <pkx166h@gmail.com> wrote:

>This didn't pass 'make'. Not sure if it is JUST the version number (not
>sure how to test this patch otherwise) or if there is an additional
>problem. I can also do a full make doc when it passes make.
>

Edit the file VERSION in the home directory, so that the PATCH_LEVEL entry
says

PATCH_LEVEL=17


This should fix the error you listed.

Thanks,

Carl

[dak, 2011-11-08 21:50:54]

Carl Sorensen <c_sorensen@byu.edu> writes:

> On 11/8/11 2:04 PM, "pkx166h@gmail.com" <pkx166h@gmail.com> wrote:
>
>>This didn't pass 'make'. Not sure if it is JUST the version number (not
>>sure how to test this patch otherwise) or if there is an additional
>>problem. I can also do a full make doc when it passes make.
>>
>
> Edit the file VERSION in the home directory, so that the PATCH_LEVEL entry
> says
>
> PATCH_LEVEL=17
>
>
> This should fix the error you listed.

18, I should think.

-- 
David Kastrup

[pkx166h, 2011-11-08 22:06:28]

Passes make and there are no pictorial reg test diffs but the 'textural' test
results are attached here for completeness

http://code.google.com/p/lilypond/issues/detail?id=2024#c10

James

[c_sorensen, 2011-11-08 22:06:57]

On 11/8/11 2:50 PM, "David Kastrup" <dak@gnu.org> wrote:

>Carl Sorensen <c_sorensen@byu.edu> writes:
>
>> On 11/8/11 2:04 PM, "pkx166h@gmail.com" <pkx166h@gmail.com> wrote:
>>
>>>This didn't pass 'make'. Not sure if it is JUST the version number (not
>>>sure how to test this patch otherwise) or if there is an additional
>>>problem. I can also do a full make doc when it passes make.
>>>
>>
>> Edit the file VERSION in the home directory, so that the PATCH_LEVEL
>>entry
>> says
>>
>> PATCH_LEVEL=17
>>
>>
>> This should fix the error you listed.
>
>18, I should think.

Yep, absolutely.   I hate typos.  I need to proofread things better....

Carl