[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) i

From: ianhulin44
Subject: Re: T1247 - Conditionally do (use-modules (ice-9 curried-definitions)) if running with Guile V2, (issue2219044)
Date: Thu, 17 Feb 2011 19:06:52 +0000

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.

File scm/display-lily.scm (right):
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

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
;;; compiling
;;; 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
failed to match any pattern" (define ((make-music-type-predicate-aux
expr) (if (null? mtypes) #f (or (eqv? (car mtypes) (ly:music-property
(quote name))) ((make-music-type-predicate-aux (cdr mtypes)) expr)))))
;;; WARNING: compilation of
;;; key wrong-type-arg, throw args (#f "Wrong type to apply: ~S" (#f)

Removing this change.

File scm/lily.scm (right):
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
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.

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
> extra  changes in the Guile initialisation code  This change makes
> 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]