Menu
▾
▴
#1826 Guile 2.0 compat: `conditional-circle-markup' definition needs to be relocated
Accepted
nobody
None
needs_work
Enhancement
2016-03-21
2011-08-18
Anonymous
No
Originally created by: *anonymous
Originally created by: pnorcks@gmail.com
Originally owned by: ianhuli...@gmail.com
When compiling LilyPond against the Guile 2.0.2 library (after applying Ian's patch from issue #1349), compilation fails with
;;; compiling /home/pnorcks/git/lilypond/scm/define-woodwind-diagrams.scm
fatal error: Not a markup command: conditional-circle-markup
This indicates that `conditional-circle-markup' is not being compiled before it's used and therefore must be defined in an earlier-loading scheme file.
Originally posted by: pnorcks@gmail.com
One possible patch is attached.
Originally posted by: reinhold...@gmail.com
That's such a specialized markup (checking for trigger=0.5, which doesn't make sense anywhere else) that I don't like having it in our main markup definitions file and list...
Do I really understand it correctly that in guile 2.0 we are no longer able to define a markup command in an .scm file and use it afterwards in that same file??? That's really a severe restriction on markup functions.
Can't we find some other solution so that this case works also with guile 2.0?
Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Labels: Type-Enhancement
Originally posted by: ianhuli...@gmail.com
Re comment 2:
Hi Reinhold,
Things are a bit more complicated in Guile V2.0, because now you can be loading a scheme file in slightly differing environments:
1. File is loading as part of another load operation (e.g. loading markup.scm as part of loading lily.scm).
2. Evaluating (Interpreting code) in a guile statement which then kicks off a load operation.
3. Byte-compiling code containing a guile statement which kicks off a load operation.
In V1, because it is purely and simply an interpreter, (load) generally implies doing a combination of (1) and (2): i.e. load up the scheme file and interpret it straightaway. Because of this this I think there was a possibility of forward-referencing within a file, although I have never successfully done this from the Guile REPL. However, because of (3), Guile V2 has had to tighten up on the kind of lazy binding that allowed this.
In 1349 I split up the load list in lily.scm into subsections to allow clean separation of definitions on which other definitions depended to be loaded early, hence define-markup-macros.scm.
If you're seriously disturbed by Patrick's suggestion in his patch, it could go into its own define-fretboard-markup-macros.scm, to be loaded after define-markup-macros in the list.
Another possibility is to get all the scheme files generating the markup sub-language to generate a separate scheme module (lily markup) ? (scm markup) ?
What are your feelings on either of these propositions? Let me know and I'll get working on a patch for this.
Ian
Originally posted by: ianhuli...@gmail.com
Ooops, I meant "it could go in its own define-woodwind-markup-macros.scm" in the last comment,
Ian
Originally posted by: ianhuli...@gmail.com
I prefer making the markup subsystem a module. Prototyping patch.
Ian
Owner: ianhuli...@gmail.com
Status: Started
Originally posted by: ianhuli...@gmail.com
Making it a guile module is tricky because the markup subsystem does not seem to have clean enough interfaces with the rest of the code.
There are interactions with the parser and lexer => build dependencies and also strange failures to recognize the new module (scm markup) during initialization stage 2 (once lily.scm has been loaded and main.cc kicks off the main Scheme entry-point (lilypond-main) in lily.scm).
Stick with Patrick's original patch and address Reinhold's concerns and using a module in a future 'clean up act for markup subsystem' Issue.
Originally posted by: ianhuli...@gmail.com
Parking work on this issue until Issue 1686 is done.
Blockedon: 1686
Originally posted by: ianhuli...@gmail.com
Fixed by work on Issue 2026 - markup is now a separate module and the conditional-circle-markup is defined with other markup commands.
Blockedon: -1686
Status: Fixed
Originally posted by: k-ohara5...@oco.net
Issue 2150 has been merged into this issue.
Originally posted by: tomspuh...@gmail.com
sorry for filing 2150, I didn't see this one. This is now becoming a problem because the Distributions are moving to Guile-2
Originally posted by: PhilEHol...@googlemail.com
How would this fix be verified, please?
Originally posted by: dak@gnu.org
Since issue 2026 has not been committed for good yet, I mark this as blocked on 2026 and "Started".
Blockedon: 2026
Status: Started
Originally posted by: ianhuli...@gmail.com
Patch for 2026 now abandoned removing blocked-on 2026 attribute.
Blockedon: -lilypond:2026
Reverting the Status of this issue to Accepted, and indicating there is a patch that needs work, as there has been no activity for almost 3 years.
Diff: