OK all, I've worked out what to keep and what to nuke.
I'll prepare a new patch-set once I've rebased and tested with Guile V2
on my VM.
Cheers,
Ian
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#newcode23
scm/display-lily.scm:23: (define-module (scm display-lily)
I will need to change the argument list here so we don't lose Jan's
changes.
Ian
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm#newcode41
scm/display-lily.scm:41: (use-modules (ice-9 curried-definitions)))
On 2010/11/02 21:53:54, Patrick McCarty wrote:
This doesn't work for me with Guile 1.9.13.
I see this in the log as the Scheme files are compiling:
;;; compiling
/home/pnorcks/usr/share/lilypond/2.13.39/scm/music-functions.scm
;;; compiling
/home/pnorcks/usr/share/lilypond/2.13.39/scm/display-lily.scm
;;; WARNING: compilation of
/home/pnorcks/usr/share/lilypond/2.13.39/scm/display-lily.scm failed:
;;; key syntax-error, throw args (macroexpand "~a in ~a" ("source
expression
failed to match any pattern" (define ((make-music-type-predicate-aux
mtypes)
expr) (if (null? mtypes) #f (or (eqv? (car mtypes) (ly:music-property
expr
(quote name))) ((make-music-type-predicate-aux (cdr mtypes)) expr)))))
#f)
;;; WARNING: compilation of
/home/pnorcks/usr/share/lilypond/2.13.39/scm/music-functions.scm
failed:
;;; key wrong-type-arg, throw args (#f "Wrong type to apply: ~S" (#f)
(#f))
Removing this change.
Ian
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
On 2011/02/17 16:17:08, Patrick McCarty wrote:
On 2011/02/17 15:07:00, ianhulin44 wrote:
> 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?
See my comment above. I think we should keep it.
Since we're still supporting Guile 1.8 and 2.0 simultaneously, and
Guile 1.8
supports currying out of the box, IMO it would not be smart to start
discouraging it.
Once everyone is using Guile 2.0 and people realize it doesn't support
currying
out of the box, then I think people will naturally stop using
currying. Even
then, I don't think we would need to actively discourage it.
OK, lets keep it, then.
Cheers,
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
On 2011/02/17 16:17:08, Patrick McCarty wrote:
On 2011/02/17 15:07:00, ianhulin44 wrote:
> 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.
Yes, but without this change, SCM files are not autocompiled. Is this
still the
case?
Yes, but autocompile is evil, until we work out how to fiddle things
like %compile-fallback-path and
%load-compiled-path in our initialization code. I can see how this is
done in compile-file in the guile code, but I'll need to dig around in
their code some a bit to find out how this affects load etc.
In the meantime, this will be a good debugging and diagnostic tool for
what will need compiling in which order, so let's keep it for the
interim.
Ian
http://codereview.appspot.com/2219044/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
