Re: 2.13.8 now?
2009/11/23 Graham Percival : > Now that 2.13.8 is uploaded: http://lilypond.org/install/ still links 2.13.7. Regards -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
2009/11/24 David Kastrup
>
> > file3.ly:
> > myInclude =
> > #(define-music-function (parser location file) (string?)
> > #{ \include $file #}
> > (make-music 'void #t))
> >
> > \myInclude "file2.ly"
> > \markup \foo
>
Please ignore this case, it's broken. What I had in mind a bit more complex,
and probably does not really matter.
The two important points to keep in mind are:
1) user defined commands shall not pollute the internal modules
When file1.ly e.g. redefines a builtin command, it shall not change the
behavior of other file compilation:
lilypond file1.ly file2.ly
shall give the same result as:
lilypond file1.ly
lilypond file2.ly
Corollary: a command defined in file1.ly, shall not be accessible from
file2.ly in the "lilypond file1.ly file2.ly" case. No side effect allowed.
2) A user command defined in one included file shall be accessible from
another included file.
Nobody will make your patches available on retvield for you, and it's not a
matter of fighting, but of reading git-cl README.
Using retvield makes your patches both easier to read and to comment. This
is the current policy on this project, please conform. Yesterday, I
anticipated changes that were yet to come (the unification of both macro),
that's why my comments where out of the point of your patch. I feel that
publishing your previous patch on retvield as expected here, by giving a
clearer picture, would have avoided this situation. Your patch was fine.
Nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
Nicolas Sceaux writes: > Please ignore this case, it's broken. What I had in mind a bit more > complex, and probably does not really matter. > > The two important points to keep in mind are: > > 1) user defined commands shall not pollute the internal modules > When file1.ly e.g. redefines a builtin command, it shall not change the > behavior of other file compilation: > lilypond file1.ly file2.ly > shall give the same result as: > lilypond file1.ly > lilypond file2.ly > Corollary: a command defined in file1.ly, shall not be accessible from > file2.ly > in the "lilypond file1.ly file2.ly" case. No side effect allowed. I don't see how you can achieve this reliably without redefining all of the core's *-public commands as well as export. If you do that, however, it is trivial to use the same code for *-builtin-* and the user level equivalents: compile those with a version of the redefined core commands that can switch its target module for public definitions to the user "toplevel" but has it set to the system toplevel during execution of the, well, public scheme files. *-public commands in modules will also have to be covered, which makes this approach sort an open-ended task. However, I think that few modules actually provide *-public defining commands, so this might sound worse than it is. Absolute security will not be possible in this manner since new guile releases might come with new *-public commands. But I don't think that security is really not as much a target here as predictability. This approach allows the current code of the *-builtin-* defining commands to be used for the user variants as well. Doing it the other way round also is a possibility. In that case, moving most of markup-init.ly to public scheme files and just duplicating the #(let ((toplevel-module (current-module))) (set! toplevel-module-define-public! (lambda (symbol value) (module-define! toplevel-module symbol value) (module-export! toplevel-module (list symbol (set! toplevel-module-ref (lambda (symbol) (module-ref toplevel-module symbol sequence into both markup-init.ly as well as the top of the first loaded public code scheme file should do the trick. In this case the *-toplevel commands will, while loading the system files, actually define their stuff in global scope. This offers less "security", but not less than what we currently have, and more transparency. However, it will mean that users using *-public commands will cause permanent effects, possibly unwittingly. > 2) A user command defined in one included file shall be accessible > from another included file. The above approach would give that. I am not saying that it is the best possible approach. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
David Kastrup writes: > Nicolas Sceaux writes: > >> Please ignore this case, it's broken. What I had in mind a bit more >> complex, and probably does not really matter. >> >> The two important points to keep in mind are: >> >> 1) user defined commands shall not pollute the internal modules >> When file1.ly e.g. redefines a builtin command, it shall not change the >> behavior of other file compilation: >> lilypond file1.ly file2.ly >> shall give the same result as: >> lilypond file1.ly >> lilypond file2.ly >> Corollary: a command defined in file1.ly, shall not be accessible from >> file2.ly >> in the "lilypond file1.ly file2.ly" case. No side effect allowed. > > I don't see how you can achieve this reliably without redefining all of > the core's *-public commands as well as export. If you do that, > however, it is trivial to use the same code for *-builtin-* and the user > level equivalents: compile those with a version of the redefined core > commands that can switch its target module for public definitions to the > user "toplevel" but has it set to the system toplevel during execution > of the, well, public scheme files. > > *-public commands in modules will also have to be covered, which makes > this approach sort an open-ended task. However, I think that few > modules actually provide *-public defining commands, so this might sound > worse than it is. Absolute security will not be possible in this manner > since new guile releases might come with new *-public commands. Cough, cough. I actually tried the following: test1.ly: #(define-public xxx "Hello") #(display xxx) #(export xxx) test2.ly: #(display xxx) Running delivers: lilypond test1.ly test2.ly GNU LilyPond 2.13.8 Processing `test1.ly' Parsing...Hello test1.ly:0: warning: no \version statement found, please add \version "2.13.8" for future compatibility Processing `test2.ly' Parsing... test2.ly:1:1: error: GUILE signaled an error for the expression beginning here # (display xxx) Unbound variable: xxx test2.ly:0: warning: no \version statement found, please add \version "2.13.8" for future compatibility error: failed files: "test2.ly" d...@lola:/tmp$ So it would appear that the public defining commands already don't export not further than toplevel, probably because exports more or less just "throw" their value upwards to the module having issued the corresponding "usemodule" but not further. This is pure speculation on my part. Whatever the mechanism, it would appear that the necessary encapsulation for define-public is already in place. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)
carl.d.soren...@gmail.com writes: > David, > > Thank you for posting this on Rietveld. It was much easier for me to > review it. > > I have one documentation question (see below). > > I also have one patch philosophy question: should define-markup also > have (at least) a :properties keyword added to it? Goal #1 was to be able to move user-level markup to system markup unchanged. This goal actually is not achieved with the current state of the patch series since it fails for markup definitions without DOC string. > I think that if it did, then we'd have the possibility of using the > exact same code and just changing from define-markup to > define-builtin-markup by only changing the macro name. After fixing the DOC string issue and exporting define-builtin-markup-command as define-markup-command, the regression test seems to work fine (namely, it runs until it crashes on "Unable to load the map file" which it always does here) and the scoping would appear to be correct as well. Which suggests that the apparent main reason for *-builtin-* commands, the changed toplevel scoping, is not valid, and the scoping works out well enough without extra complications. Renaming define-builtin-markup-command to define-markup-command, making it public and adapting all callers would appear to finish the job, obviously unifying the syntax. I have to check that this is indeed the case. > http://codereview.appspot.com/160048/diff/1/5 > File scm/markup.scm (right): > > http://codereview.appspot.com/160048/diff/1/5#newcode74 > scm/markup.scm:74: [ :category category ] > Does this need to be [ #:category category ] ? Yes. Sorry. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.8 now?
On Tue, Nov 24, 2009 at 09:46:07AM +0100, Francisco Vila wrote: > 2009/11/23 Graham Percival : > > Now that 2.13.8 is uploaded: > > http://lilypond.org/install/ still links 2.13.7. Interesting. Anybody want to look at the old web/ branch to figure out why make update-versions isn't working? The files are in the download site. My initial guess is that it's a directory thing, since the redirects in .htaccess is the only thing that changed since 2.13.7 (I think). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: repeated music
[from -user] Francesco Petrogalli wrote: I have no idea where to find documentation about this programming in "lilypond-scheme". There is a big list of scheme function in the documentation, but I can't see any "tutorial" about using it. Should this section "A.16 Scheme functions" also be moved to the "Extend LilyPond" manual, now that the "Interfaces for programmers" section is there? At least, there should be a link to the function list in the TOC of the Extend manual, and a corresponding link to the Extend manual on top of A.16. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)
http://codereview.appspot.com/160048/diff/1/5 File scm/markup.scm (right): http://codereview.appspot.com/160048/diff/1/5#newcode74 scm/markup.scm:74: [ :category category ] On 2009/11/24 11:01:59, Carl wrote: Does this need to be [ #:category category ] ? Done. http://codereview.appspot.com/160048 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
Han-Wen Nienhuys writes: > On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote: > >>> lilypond a.ly b.ly >>> >>> we want to reuse the built-in definitions, without changes effected in >>> a.ly leaking into the processing of b.ly >> >> Wouldn't just putting the built-in definition at public scope accomplish >> that? > > I don't know. Why don't you try it, and send us a patch if it passes > the regression tests? After applying http://codereview.appspot.com/160048> first, indeed the following diff that throws out all the toplevel scoping constructs and separate definitions of define-markup-command and define-markup-list-command passes the regressions tests. Furthermore, tests show that the namespace of markups defined in one input file does not extend into the next input file. Shrug. diff --git a/ly/markup-init.ly b/ly/markup-init.ly index 5749c7b..c678391 100644 --- a/ly/markup-init.ly +++ b/ly/markup-init.ly @@ -2,119 +2,3 @@ \version "2.12.0" -%%;; to be define later, in a closure -#(define-public toplevel-module-define-public! #f) -#(define-public toplevel-module-ref #f) -#(let ((toplevel-module (current-module))) - (set! toplevel-module-define-public! - (lambda (symbol value) - (module-define! toplevel-module symbol value) - (module-export! toplevel-module (list symbol - (set! toplevel-module-ref - (lambda (symbol) - (module-ref toplevel-module symbol - -#(defmacro-public define-public-toplevel - (first-arg . rest) - "Define a public variable or function in the toplevel module: - (define-public-toplevel variable-name value) -or: - (define-public-toplevel (function-name . args) -..body..)" - (if (symbol? first-arg) - ;; (define-public-toplevel symbol value) - (let ((symbol first-arg) -(value (car rest))) -`(toplevel-module-define-public! ',symbol ,value)) - ;; (define-public-toplevel (function-name . args) . body) - (let ((function-name (car first-arg)) -(arg-list (cdr first-arg)) -(body rest)) -`(toplevel-module-define-public! - ',function-name - (let ((proc (lambda ,arg-list -,@body))) -(set-procedure-property! proc - 'name - ',function-name) -proc) - -#(defmacro-public define-markup-command (command-and-args signature . body) - " -* Define a COMMAND-markup function after command-and-args and body, -register COMMAND-markup and its signature, - -* add COMMAND-markup to markup-function-list, - -* sets COMMAND-markup markup-signature and markup-keyword object properties, - -* define a make-COMMAND-markup function. - -Syntax: - (define-markup-command (COMMAND layout props arg1 arg2 ...) - (arg1-type? arg2-type? ...) -\"documentation string\" -...command body...) -or: - (define-markup-command COMMAND (arg1-type? arg2-type? ...) function) -" - (let* ((command (if (pair? command-and-args) - (car command-and-args) - command-and-args)) - (command-name (string->symbol (format #f "~a-markup" command))) - (make-markup-name (string->symbol (format #f "make-~a-markup" command -`(begin - ;; define the COMMAND-markup procedure in toplevel module - ,(if (pair? command-and-args) -;; 1/ (define (COMMAND-markup layout props arg1 arg2 ...) -;; ..command body)) -`(define-public-toplevel (,command-name ,@(cdr command-and-args)) - ,@body) -;; 2/ (define (COMMAND-markup . args) (apply function args)) -(let ((args (gensym "args")) - (command (car body))) -`(define-public-toplevel (,command-name . ,args) - (apply ,command ,args - (let ((command-proc (toplevel-module-ref ',command-name))) - ;; register its command signature - (set! (markup-command-signature command-proc) - (list ,@signature)) - ;; define the make-COMMAND-markup procedure in the toplevel module - (define-public-toplevel (,make-markup-name . args) - (make-markup command-proc -,(symbol->string make-markup-name) -(list ,@signature) -args)) - -#(defmacro-public define-markup-list-command (command-and-args signature . body) - "Same as `define-markup-command', but defines a command that, when interpreted, -returns a list of stencils, instead of a single one." - (let* ((command (if (pair? command-and-args) - (car command-and-args) - command-and-args)) -(command-name (string->symbol (format #f "~a-markup-list" command))) -(make-markup-name (string->symbol (format #f "make-~a-markup-list" command -`(begin - ;; define the COMMAND-markup-l
Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups
David Kastrup writes: > Nicolas Sceaux writes: > >> I'd be insterested to see an implementation of a single >> `define-markup-command' for builtin and user defined markups, where >> user defined commands do not pollute the (lily) module, and still are >> available across file includes. >> >> If you can come up with one, fine, I'm not opposed to #:property or >> #:category keywords. But if that's not possible, then please stop with >> this macro unification debate. IMHO it's just waisting time, for this >> is not a problem that you're trying to solve, but at most a little >> inconvenience. > >> PS: *please*, call things by there name, it's "builtin", not >> "internal". > > Wouldn't it be worth it alone to do this change because of not having to > get annoyed time and again by me confusing the two? > > I'll see whether I can cook up a suitable patch. Done. The current state of http://codereview.appspot.com/160048> (Patchset 4) removes *-builtin-* completely and appears to pass all tests. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: improve doc on markup command writing (issue157133)
It would make sense to apply http://codereview.appspot.com/160048> first and make this patch work on top of that. There may be cases where a separate property-bind like this is useful in called routines, and the markup commands from the mentioned patch might make use of it for implementing #:properties. However, a separate property-bind function can't do the job of entering the properties and their defaults into the command reference. For this reason, it is probably not a good idea to encourage users to use a macro like this in markups defined with define-markup-command. They would need to be rewritten in order to get the properties mentioned in the command reference. Since the above-mentioned patch does not provide user-level documentation, it would make sense to adapt your patch here for documenting the functionality provided by the above-mentioned patch of mine. http://codereview.appspot.com/157133 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 872 in lilypond: Changes split-page has broken images
Le samedi 21 novembre 2009 à 19:17 +, Graham Percival a écrit : > Hmm. Now I'm wondering if I had a half-built doc tree, with the > remains of Jan's "@node lower-case" stuff. I cleared out > Docuemtnation/out-www/, but I didn't think to touch out/xref-maps. I hope it's not needed to touch them... I'm not much interested by the answer anyway, as we wish to replace this build system. > Instead of doing texi2html init files, could you check that the > translation infrastructure is working? In particular, > - we now have web.texi > - web.texi now goes into web/ > - index.html.in just redirects to web/ Perfetto! > Could you check this stuff, maybe translate one sentence on half a > dozen nodes inside Documentation/fr/web/*.itexi for testing, etc > etc ? Jan already translate a few sentences in several nodes in French and Dutch, and while splitted HTML translated docs used to be written as index_xx.html it works for me now, kudos. Shall I take over mangling a v2.xx directory in www_post.py? As this is only relevant to the web site (offlien docs don't need this), I'd better not add this complication to the main build system. www_post.py stuff will survive from the switch to another build system anyway. > I don't really know where we stand on waf; I've spent 20 hours so > far, and I'm not enthusiastic. But I definitely think we should > get the stepmake system working again, with translations. waf > isn't going to be ready before 2.14, and in any case I want people > to be translating web.texi ASAP. It works way better than one week ago; do you think there are some files in web/ we can already declare as translatable? There are several people who report their experience of building docs on the French list, so in case they want to help with translations we should not limit their enthusiasm :-) Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] serious doubts about waf
Sorry for the delay, it often takes me a while to catch all traffic on Lily lists when I'm back from a trip, even a few-days one. Le jeudi 12 novembre 2009 à 17:54 +, Graham Percival a écrit : > 1) if you can't duplicate the problem after checking out > dev/gperciva, then I'll check a third time to see if there's any > old version of waf floating around on this machine. No, I couldn't duplicate. But, it might be necessary to clear some cache using distclean, then reconfigure, so you can have a command like waf-light distclean configure build Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixing spelling errors in documentation
John, It's been brought to my attention that we are using an incorrect spelling for "ukulele". We've been using (at least in part of our documentation) "ukelele". I've done a git grep for ukelele, and found the misspelling existing in de/ es/ and fr/ notation/fretted-strings.itely. I'm happy to fix it in all of those, and I think I should do so. I have read the CG, and I'm not sure if I should fix the misspelling in Documentation/po/*.po. If I do change the .po files, I think that I should allow the translations meister to do the make *-update work. Have I got it correct? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] serious doubts about waf
On Tue, Nov 24, 2009 at 09:42:05PM +0100, John Mandereau wrote: > Le jeudi 12 novembre 2009 à 17:54 +, Graham Percival a écrit : > > 1) if you can't duplicate the problem after checking out > > dev/gperciva, then I'll check a third time to see if there's any > > old version of waf floating around on this machine. > > No, I couldn't duplicate. But, it might be necessary to clear some > cache using distclean, then reconfigure, so you can have a command like I clear the cache with rm -rf waf-out On the 16th, I gave up and fixed this one myself. However, I discovered that I couldn't copy files from srcdir into the blddir without changing their name, which kind-of borks Documentation/pictures/. That message is on -devel somewhere. Waf is dead until at least after 2.14. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing spelling errors in documentation
Hi Carl, Le mardi 24 novembre 2009 à 14:15 -0700, Carl Sorensen a écrit : > I've done a git grep for ukelele, and found the misspelling existing in de/ > es/ and fr/ notation/fretted-strings.itely. I'm happy to fix it in all of > those, and I think I should do so. Certainly. > I have read the CG, and I'm not sure if I should fix the misspelling in > Documentation/po/*.po. Sure. I wouldn't be as affirmative if the change was on po/*.po. > If I do change the .po files, I think that I should allow the translations > meister to do the make *-update work. If you do a blind sed substitution even on .po/.pot files, it will avoid that po-update marks the translation of the changed string as obsolete — the spelling is correct in most translated strings. Thanks, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] serious doubts about waf
Le mardi 24 novembre 2009 à 21:20 +, Graham Percival a écrit : > On the 16th, I gave up and fixed this one myself. However, I > discovered that I couldn't copy files from srcdir into the blddir > without changing their name, which kind-of borks > Documentation/pictures/. I'm quite certain we can avoid copying pictures from outdir to blddir; however, if more generally we can't transform a file in srcdir to a file in blddir that has the same name, let's sit down two minutes to see why we do this. It's not for making the pictures available to Texinfo formatters, as a simple -I srcdir (which we already have in current build system IIRC) would do the job. For some pictures, we resize them, but then for clarity we could give a different name to the source. For other pictures, IIRC we just symlink them so that they're caught by mirrortree (a module used by www_post.py that links files into *-root). Is it worth going on investigating this? I think so, so I'll have a look. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
2009/11/24 David Kastrup : > After applying http://codereview.appspot.com/160048> first, > indeed the following diff that throws out all the toplevel scoping > constructs and separate definitions of define-markup-command and > define-markup-list-command passes the regressions tests. Furthermore, > tests show that the namespace of markups defined in one input file does > not extend into the next input file. As far as I can see, all you've done is effectively revert Nicolas's code which fixed the memory leaks, so I can't see why it would work. I've just applied your patch, and as expected, I get the following errors with nearly every file (using a binary compiled with --disable-optimising): programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers programming error: Parsed object should be dead: static scm_unused_struct* Context_def::mark_smob(scm_unused_struct*) continuing, cross fingers Furthermore, make check segfaults if I use -j2. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Difficulties with `make check'
Hi,
For the past few months, I have been experiencing strange failures
when checking the regression test suite, and I have just discovered
why.
I recently posted to the ImageMagick forums:
http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=15098
Even though this solution works for me, it is unclear how this (ugly)
command line option behaves with older versions of ImageMagick that do
not support it.
See the attached patch. Can someone (or multiple people) try running
the regression test suite with this patch to see if it works for you?
Thanks,
Patrick
>From 396684dc11dcd89f1e5ec2a96ddec4e2852dcb8e Mon Sep 17 00:00:00 2001
From: Patrick McCarty
Date: Tue, 24 Nov 2009 21:27:34 -0800
Subject: [PATCH] output-distance: Add new flag for `compare'.
Newer versions of ImageMagick seem to be more picky about comparing
images that are not very similar.
I don't know any further details, but this patch fixes `make check' for
me when comparing release/2.13.7-1 with release/2.13.8-1.
I am running ImageMagick 6.5.7-10.
---
scripts/build/output-distance.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/build/output-distance.py b/scripts/build/output-distance.py
index 2b49689..7cada36 100644
--- a/scripts/build/output-distance.py
+++ b/scripts/build/output-distance.py
@@ -87,7 +87,7 @@ def compare_png_images (old, new, dest_dir):
system ('convert -depth 8 -crop %dx%d+0+0 %s %s/crop1.png' % (dims + (old,
dir)))
system ('convert -depth 8 -crop %dx%d+0+0 %s %s/crop2.png' % (dims + (new,
dir)))
-system ('compare -depth 8 %(dir)s/crop1.png %(dir)s/crop2.png
%(dir)s/diff.png' % locals ())
+system ('compare -depth 8 -dissimilarity-threshold 1 %(dir)s/crop1.png
%(dir)s/crop2.png %(dir)s/diff.png' % locals ())
system ("convert -depth 8 %(dir)s/diff.png -blur 0x3 -negate -channel
alpha,blue -type TrueColorMatte -fx 'intensity'%(dir)s/matte.png" % locals
())
--
1.6.5.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's the deal with the module system?
Neil Puttock writes: > 2009/11/24 David Kastrup : > >> After applying http://codereview.appspot.com/160048> first, >> indeed the following diff that throws out all the toplevel scoping >> constructs and separate definitions of define-markup-command and >> define-markup-list-command passes the regressions tests. Furthermore, >> tests show that the namespace of markups defined in one input file does >> not extend into the next input file. > > As far as I can see, all you've done is effectively revert Nicolas's > code which fixed the memory leaks, so I can't see why it would work. Fixed the memory leaks. Something new every day. Why tell me all the time that the purpose of the code was scoping, then? Since the code registers properties and functions permanently, sure it will work as a memory leak between multiple sessions. I was worrying about the action of the code. It is easy enough to turn off this registration for user level code. That might already do the job. > I've just applied your patch, and as expected, I get the following > errors with nearly every file (using a binary compiled with > --disable-optimising): I did not use --disable-optimising. > programming error: Parsed object should be dead: static > scm_unused_struct* Prob::mark_smob(scm_unused_struct*) > continuing, cross fingers > programming error: Parsed object should be dead: static > scm_unused_struct* Context_def::mark_smob(scm_unused_struct*) > continuing, cross fingers > > Furthermore, make check segfaults if I use -j2. I have my doubts -j2 is concerned with the patch other than accidently. Our results are so different that I have my suspicion this might also depend on the guile version used. 1.8.7 here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
