Re: State of LilyPond with Guile 2.2

[David Pirotte]

Hi Thomas,

> (1)
> The whole cycle worked fine, no errors apart from my own.
> Though, regtest-comparision shows:
> WARNING: (lily song): imported module (lily song-util) overrides core
> binding `compose'
> For input/regression/song-melisma.log and others.
> Which is new with guile-2.
> No clue how to avoid this other then not to use taken identifiers.

You can either 'brutally' replace, or replace 'with care', using
goops, by creating a generic function, then add the default method using
the guile core cmpose definition, and then add your own compose
method ...

In both cases, you need to use #:replace, in the module definition

        ...
        #:replace compose
        ...

Then for a 'care replace', you would also import (oop goops) in the
module def, then do:

        (define %compose
          (module-ref the-root-module 'compose))

        (define-method (compose . args)
          "The core Guile implementation of the compose procedure"
          (apply %compose args))

Finally add your method, specializing on at least the first arg ...

        (define-method (compose  (arg1 <arg1-type> [...])
          ;; here comes the lilypond compose code
          )

Note that:

1-      define-method will call define-generic for you if the generic
function does not exist - and by my personal advice, you should not
(never) call define-generic yourself;

2-      of course you'd need to use goops in the modules that import
lily-song - I would also advise to 'merge-generics', as explained
here (not to re-write ...):

        
https://www.gnu.org/software/g-golf/manual/html_node/GOOPS-Notes-and-Conventions.html#GOOPS-Notes-and-Conventions,
 see/read '- Merge Generics'

3-      if you'd like to see a real example, visit 

        
http://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/hl-api/gobject.scm?h=devel

and search/look at the connect (re)definition

  [ the other connect method(s) is/are defined 'on the fly', if/when a user 
imports 
  [ the Gtk namespace, which defines connect, connect-signal ... but
  [ here is what it would look like if done manually (from guile-gnome, which 
does
  [ 'this' manually 

(define-method (connect (object <gtype-instance>) (name <symbol>) (func 
<procedure>)
                        (after? <boolean>) (detail <symbol>))
  "A shorthand for @code{gtype-instance-signal-connect}, with all arguments."
  (gtype-instance-signal-connect object name func after? detail))

> (2)
> If I switch to a different branch, with changed .scm-files, do some
> work there and then switch back (NB in this branch the scm-files are
> _not_ changed inbetween) I need to recompile guile, a real nuisance.
> Could this be improved?

This is not a guile problem, is it? Anyway, iiuc, I would organize
things so that work being done on scheme files can (always) be merged -
ten always merge whenever you work on the scheme branch ...

David

pgpBHXVFj5YRx.pgp
Description: OpenPGP digital signature