Menu
▾
▴
#1055 guile 2.0
Originally created by: *anonymous
Originally created by: percival.music.ca@gmail.com
Originally owned by: pnorcks@gmail.com
When guile 2.0 is out, we'll want to switch to it eventually, which will
require some rewriting of our scheme code to fit the stricter adherence to
R5RS.
For example, (Patrick)
(if ...) can only contain *expressions*, IIUC, and (define ...) is a
top-level definition, not an expression.
This will **not** be done before 2.14.0.
Originally posted by: pnorcks@gmail.com
Here's an update on where we are with regard to Guile 2.0 compatibility...
- Many, many backward-compatibility issues have been fixed upstream, which is good for us.
- Ian is working on a backward-compatibility patch: http://www.codereview.appspot.com/1160044/show
- I have managed to hack my way around other compile failures and just had my first successful build today. For those interested, I will keep my latest patches on repo.or.cz:
http://repo.or.cz/w/lilypond/patrick.git/shortlog/refs/heads/guile
- I think there is a problem with the interface between Paper_outputter and the output modules (output-ps.scm, output-svg.scm, etc.), because I sometimes see compile failures where stencil expressions are evaluated incorrectly.
- The LilyPond fonts (emmentaler-*.otf) are loaded *very* slowly with Guile 1.9, but I haven't looked into that yet.
Originally posted by: pnorcks@gmail.com
The Paper_outputter compile failures (mentioned above) happen very rarely, but I managed to capture a backtrace for one of them.
Originally posted by: hanw...@gmail.com
In unknown file:
?: 0 [catch-closure wrong-type-arg #f ...]
ERROR: In procedure catch-closure:
ERROR: Wrong type to apply: #<Grob Spanner >
does this also happen if you disable point-n-click?
Originally posted by: pnorcks@gmail.com
Yes, it also happens when point-and-click is disabled.
Also I should mention that the compile failures don't always happen when evaluating a specific expression and aren't always reproducible for a particular file.
Another backtrace is attached.
Originally posted by: ianhuli...@gmail.com
Hi,
I've marked this as Patch because there's a patch under review for the backwards-compatibility bit.
Patrick, how about you being overall owner for the issue?
Will we need an ly:guile-compile (or similar) so we can produce .go files from our .scm during the build? Should we spin off problems we find like the Paper_outputter thing as separate issues?
Cheers,
Ian
Labels: Patch
Originally posted by: pnorcks@gmail.com
Hi Ian,
> I've marked this as Patch because there's a patch under review for the backwards-compatibility bit.
I think it would be cleaner to create a new issue for your backward-compatibility work and reserve this issue for general discussion. What do you think? If you want to split it off (and I think you should), please remove the Patch label.
> Patrick, how about you being overall owner for the issue?
Sure.
> Will we need an ly:guile-compile (or similar) so we can produce .go files from our .scm during the build?
It sounds like the Guile developers are working on a solution for this:
http://lists.gnu.org/archive/html/guile-devel/2010-07/msg00109.html
> Should we spin off problems we find like the Paper_outputter thing as separate issues?
Yes, that would be fine with me.
Owner: pnorcks
Originally posted by: ianhuli...@gmail.com
Removed Patch on this issue.
Backwards-compatibility work has now been moved out to Issue 1224.
Ian
Labels: -Patch
Originally posted by: hanw...@gmail.com
Patrick, the fact that we get
wrong type to apply: X
where X randomly is anything but a function is really bad. It means that there is some sort of memory corruption going on. My first instinct is to suspect GUILE except that they moved to the Boehm garbage collector which should be much more robust than the old hand-written one.
Originally posted by: hanw...@gmail.com
do these errors always look like that? Or do things crash badly/randomly at times?
Originally posted by: pnorcks@gmail.com
Han-Wen,
With GUILE git, the crashes seem to be occurring less regularly...
I have been copying all of the regression tests into a directory, and then running
$ lilypond *.ly
Strangely (or maybe not), crashes happen less often when running
$ lilypond --verbose
so I rarely ever have a chance to capture backtraces. The same thing happens when running LilyPond through GDB.
Attached is an example of another type of crash that never happens while using --verbose.
Originally posted by: pnorcks@gmail.com
One more problem. With GUILE git (and previous 1.9 versions, IIRC), there are some new "parsed object should be dead" errors. These appear when compiling a single file.
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
programming error: Parsed object should be dead: static scm_unused_struct* Grob::mark_smob(scm_unused_struct*)
continuing, cross fingers
programming error: Parsed object should be dead: static scm_unused_struct* Lily_lexer::mark_smob(scm_unused_struct*)
continuing, cross fingers
Originally posted by: hanw...@gmail.com
Guile 1.9 now uses Boehm GC, so I am mystified: the mark routines should not be called at all, AFAIK. Can you check how code linking against Guile 1.9 is supposed to handle garbage collection?
Labels: Performance
Originally posted by: pnorcks@gmail.com
I won't be able to look into it until next week, but I will attach the backtrace from the Prob::mark_smob() programming error for now, in case you want to take a look.
Originally posted by: hanw...@gmail.com
regarding the crashes and --verbose: this is a symptom of GC related bugs alright: --verbose changes the GUILE evaluator, and memory allocation patterns. It can certainly influence when garbage collections are triggered, and hence, when GC errors trigger.
Originally posted by: hanw...@gmail.com
For GUILE 1.9 you may want to decide to just retire the SMOB should be dead warnings. There is a (gc) call after processing a file which should clean up all data related to a file, but
1. Boehm GC might not honor the call
2. As Boehm GC has even more false-positives than GUILE, there is no guarantee that BGC will correctly identify all garbage.
Since the warning is a developer tool anyway, you can just remove it completely, I think.
Originally posted by: ianhuli...@gmail.com
Latest status of (not) getting throug initialization using Guile 1.9.12 and 1.9.13.
Apparently successfully compiles the modules loaded in via ly:load until it gets to line 118 or so
(cond
((eq? #t (ly:event-property event 'diminished))
(markup #:slashed-digit figure))
((eq? #t (ly:event-property event 'augmented-slash))
(markup #:backslashed-digit figure))
(else (markup #:number (number->string figure 10)))))
#f))
The compilation barfs in the markup call
at
markup.scm:292 (compile-markup-expression)
with
error: Not a markup command: line.
Any pointers to fixing this?
Ian
Originally posted by: pnorcks@gmail.com
Yes. This has to do with the markup macros *not* being defined before they are used. They need to be with Guile 1.9.
In my branch (http://repo.or.cz/w/lilypond/patrick.git/shortlog/refs/heads/guile), have a look at the commit
"Move markup macros to new file, and reorder load list."
Somehow my commit summary was lost, but I cited a NEWS entry for Guile 1.9 that explains what is happening:
> ** Macros need to be defined before their first use.
>
> It used to be that with lazy memoization, this might work:
>
> (define (foo x)
> (ref x))
> (define-macro (ref x) x)
> (foo 1) => 1
>
> But now, the body of `foo' is interpreted to mean a call to the toplevel
> `ref' function, instead of a macro expansion. The solution is to define
> macros before code that uses them.
Originally posted by: ianhuli...@gmail.com
Patrick,
Have created tracker 1349 for this one, to merge your changes in.
Cheers,
Ian
Originally posted by: ianhuli...@gmail.com
Another thing to think of when we move to Guile 2.0. At the moment we have been relying in on Guile AUTOCOMPILE to create .go files on-the-fly in a private Guile directory.
This means that we are compiling scm/*.scm files as and when they are referenced in lily.scm. Guile itself compiles its scm files as part of its build using
guile-tools compile. There is an interface for this nin the Guile repl ,compile-file, but there is currently nothing we can call from within a .scm file, so we can't tweak ly:load or write a similar procedure to do the compile the .go for us dynamically if it doesn't already exist,
If we do need to compile .scm files during the build }}shudder{{, where would be write the .go files, out/scm? I.e. scm/lily-library.scm compiles to out/scm/lily-library.go, or would we do as the guile build does and put the .go files into the source directory scm/lily-library.scm -> scm/lily-library.go?
I'm thinking about this as we already need to revise the load order to fix T1349.
Cheers
Ian
Cheers,
Ian
Originally posted by: pnorcks@gmail.com
Ian,
I think we should consider compiling .scm files as part of the build process, since it is unsightly (to say the least) to watch Guile autocompile LilyPond's .scm files. When we are closer to full compatibility with Guile 2.0 (if we can), then we can look into this.
Regarding the output dir, I would think the .go files should be in out/scm, or possibly in scm/out with a out/scm being a symlink to this directory.
Originally posted by: ianhuli...@gmail.com
Patrick,
1+,
but . . .
Thinking about this some more, when Guile does its build, how does it register the fact that $GUILE_ROOT_MODULE/ice9/xxx.go is related to
$GUILE_ROOT_MODULE/ice9/xxx.scm? Then how does it how to load the .go file in preference to the .scm file in the absence of AUTOCOMPILE?
Would we have to adjust %LOAD_PATH to include our directory containing our xxx.go files during initialization?
Cheers,
Ian Hulin
Originally posted by: pnorcks@gmail.com
Ian had some responses from the Guile developers a while back. See these threads:
http://lists.gnu.org/archive/html/guile-user/2010-11/msg00037.html
http://lists.gnu.org/archive/html/guile-user/2010-12/msg00012.html
http://lists.gnu.org/archive/html/guile-user/2011-01/msg00052.html
Originally posted by: ianhuli...@gmail.com
Now working on compiling scheme files and loading scm/out/*.go in preference to scm/*.scm under Issue 1686.
Ian
Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Labels: -Maintainability Type-Maintainability
Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Labels: -Type-Maintainability Type-Enhancement