Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)

[ianhulin44]

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/