http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm File scm/display-lily.scm (right):
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm#newcode34 scm/display-lily.scm:34: On 2011/02/17 06:50:21, Patrick McCarty wrote:
Jan recently removed all of the curried definitions that were affected
by this
conditional (use-modules ...) call.
I just compiled LilyPond (and the patch queue from my "guile" branch)
against
Guile 2.0 *without* this part of your patch, and I didn't run into any
issues.
In other words, you can safely remove this chunk from your patch.
In which case, do we even need lily.scm to pull in (ice-9 curried-definitions) at all if we aren't currying in our code? http://codereview.appspot.com/2219044/diff/25001/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/2219044/diff/25001/scm/lily.scm#newcode222 scm/lily.scm:222: (cond This block is the whole point of the patch and the tracker. Jan has just re-written code in display-lily.scm so it doesn't curry. If there's no currying in Lily Scheme code do we need this, or should we defend against users using currying their Scheme code? Opinions please? Ian http://codereview.appspot.com/2219044/diff/25001/scm/lily.scm#newcode291 scm/lily.scm:291: (primitive-load-path file-name) ;; to support Guile V2 autocompile When we move to generating our own compiled Scheme files ly:load will need a significant re-write. We will also need routines to do the compilation and some extra changes in the Guile initialisation code This change makes no difference using Guile V1.8 but is only temporary debug code until Tracker 1349 is fixed, and the code to support compiling out scheme files to scm/out. http://codereview.appspot.com/2219044/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel