Re: New debugger
Hi Andy, I've just been involved with writing some guile debug support in LilyPond using V1.8.7 (ice-9 debugging). On 29/12/09 20:45, Andy Wingo wrote: Hey folks, First off, happy solstice :) Hope all are well. If you're following git, you might have noticed that if you get an error, you're now dropped into a debugger, instead of getting a backtrace at the console. That's pretty much all you can do at this point. It's still pretty weak, but being able to do bt #:full? #t #:width 1000 is already quite useful. Here's my TODO list regarding the debugger: ;; eval expression in context of frame ;; set local variable in frame ;; step until next instruction ;; step until next function call/return ;; step until return from frame ;; step until different source line ;; step until greater source line ;; watch expression ;; break on a function ;; remove breakpoints ;; set printing width ;; (reuse gdb commands perhaps) ;; disassemble a function ;; disassemble the current function ;; inspect any object Thoughts? Should this thing be on by default? There should certainly be a way to turn it off... ;; step and then eval an expression. Maybe add commands to interface to tracing in the debugger as well ;; set trace on procedure entry/exit ;; set trace for each instruction in a procedure or procedure callees ;; suppress trace for calls above/below a certain stack frame index How above setting/resetting default module context for symbols from within the debugger? Will the new debugger be backwards compatible with (ice-9 debugging) in V1.8.7? Cheers, Ian Hulin
Re: Backward compatibility status
Hi Ludo, On 14/03/10 23:38, Ludovic � wrote: Hi Patrick, Patrick McCarty writes: 2010/3/6 Ludovic Courtès: [...] | Name | Cause | |---+-| | lilypond-2.13.9 | `scm_internal_hash_fold'& `scm_t_hash_fold_fn' | Is this something that should be fixed in LilyPond? I think so, yes (especially since ‘scm_internal_hash_fold’ was intended to be sort-of internal.) For reference, I'm fairly certain this build failure was introduced with Guile commit a07010bf1828704edd9a40cadb0eaf820b8f3638. Yes, that’s the one. If I add the typedefs to the appropriate LilyPond header file and use them, the problem goes away, but I don't know if there are unexpected side effects of this. I think you want a fix that retains compatibility with 1.8. How about having a ‘configure’ test checking for this typedef? I am unable to test any further, because there are more build failures down the pipeline. :-) Heh. Let us know what other Guile-related failures you stumble upon! I patched the Lilypond header files and code calling them to get round the above problem, but then hit this one: Code like this which dynamically declares procedures,and works fine in V1.8.7 but barfs with V1.9.9 ;;; This is OK (define-public PLATFORM (string->symbol (string-downcase (car (string-tokenize (utsname:sysname (uname))) ;;; This is OK ;;; This fails, but works in 1.8.7 (case PLATFORM ((windows) (define native-getcwd getcwd) (define (slashify x) (if (string-index x #\\) x (string-regexp-substitute "//*" "/" (string-regexp-substitute "" "/" x (define-public (ly-getcwd) (slashify (native-getcwd (else (define-public ly-getcwd getcwd)))
Re: %module-public-interface
Hi Ludovic,
On 30/03/10 22:52, Ludovic � wrote:
Hello,
Andy Wingo writes:
On Tue 30 Mar 2010 22:56, l...@gnu.org (Ludovic Courtès) writes:
I'm pretty sure that the submodule thing can be changed without any
problem. But it seems that the %module-public-interface is used
explicitly, at least by texmacs and lilypond.
How do they use it?
Linking to the evil empire:
http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search
Lilypond does:
--8<---cut here---start->8---
mod = scm_call_0 (maker);
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
--8<---cut here---end--->8---
Solution: do something like:
--8<---cut here---start->8---
#ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
scm_set_module_public_interface_x (mod, mod);
#else
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
#endif
--8<---cut here---end--->8---
(We just need to add that function.)
TeXmacs does:
And we could add a ‘public-interface’ slot to ‘module-type’ and have
‘module-public-interface’ and ‘set-module-public-interface!’ refer to
it; for backward compatibility we’d also initialize the
‘%module-public-interface’ binding. How does it sound?
Actually the trick wouldn’t work in cases where the
‘%module-public-interface’ binding is mutated, as with Lilypond.
Given this and the above examples, I’d suggest dropping that binding
completely and sending patches to the Lilypond/TeXmacs people.
> What do you think?
If you do add scm_set_module_public_interface_x, could you back-port it
to Guile V1.8.6 and V1.8.7?
Those are the lowest versions of Guile the upcoming stable release of
Lilypond will support.
Cheers,
Ian Hulin
Re: %module-public-interface
On 02/04/10 10:37, Ludovic � wrote:
Hi Ian,
Ian Hulin writes:
On 30/03/10 22:52, Ludovic � wrote:
Andy Wingo writes:
On Tue 30 Mar 2010 22:56, l...@gnu.org (Ludovic Courtès) writes:
I'm pretty sure that the submodule thing can be changed without any
problem. But it seems that the %module-public-interface is used
explicitly, at least by texmacs and lilypond.
How do they use it?
Linking to the evil empire:
http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search
Lilypond does:
--8<---cut here---start->8---
mod = scm_call_0 (maker);
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
--8<---cut here---end--->8---
Solution: do something like:
--8<---cut here---start->8---
#ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
scm_set_module_public_interface_x (mod, mod);
#else
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
#endif
--8<---cut here---end--->8---
(We just need to add that function.)
TeXmacs does:
And we could add a ‘public-interface’ slot to ‘module-type’ and have
‘module-public-interface’ and ‘set-module-public-interface!’ refer to
it; for backward compatibility we’d also initialize the
‘%module-public-interface’ binding. How does it sound?
Actually the trick wouldn’t work in cases where the
‘%module-public-interface’ binding is mutated, as with Lilypond.
Given this and the above examples, I’d suggest dropping that binding
completely and sending patches to the Lilypond/TeXmacs people.
What do you think?
If you do add scm_set_module_public_interface_x, could you back-port
it to Guile V1.8.6 and V1.8.7?
We could back-port it to the 1.8 series, but not to the already-released
1.8.7 and 1.8.6. We’d have to make a 1.8.8 release, but I’m not sure
that would really help anyway since that would force Lilypond users to
switch to that version.
Those are the lowest versions of Guile the upcoming stable release of
Lilypond will support.
How about doing #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X in your
code?
We still have to agree on the change and actually implement it, the
latter being easy. ;-)
I'm sure that would be easy enough, if guile provided
HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X in the V2.0
guile-config (or the pkg-config guile-2.0 data which I believe is
replacing it), that looks like it would be the most painless route for
both projects.
When is the new Lilypond release due?
I'm not the ReleaseMeister for Lilypond; you'll get a better picture by
talking to Graham Percival (gra...@percival-music.ca).
But FWIW it looks like we're on our few last development releases before
the stable V2.14 comes out. It's near enough for a spoof release
announcement to have gone out on the mailing list on April 1st which
suckered me!
I reckon plans are for Lilypond to stick with Guile V1.8.7 at least
until the next Lilypond stable version after V2.14, but again, mileage
may vary if you talk to more experienced Lilypond people.
Currently there are only a couple of people in the Pond looking at
Lilypond/Guile V2.0 transition, and there are a few compatibiilty
breakages we've identified.
1. Lilypond configure looks at guile-config --version to get the guile
version - the guile V2.0 guile-config says it's being deprecated in
favour of pkg-config --atleast-version/--exact-version/--max-version.
2. Lilypond has *lots* of guile code which it needs to build the project.
3. There's a restriction introduced in Guile V2.0 whereby dynamic use
of define, define-public and variants will cause the guile compilation
to fail with diagnostics. We have these in our basic Scheme files
(lily.scm and lily-library.scm). These compilation failures currently
stop Lilypond building altogether.
4. We've already seen the %module-public-interface thing in the Lily
C++. There's probably more smelly stuff lurking in the C++ interface,
which won't surface until we start trying to use Guile 2.0 more.
Graham, Vincent, is it worth opening a tracker to capture
forward-compatibility issues with Guile?
Thanks for your feedback so far, Ludo. The other Lily developer who has
done anything with Guile 1.9/V2.0 is Patrick McCarty (pno...@gmail.com).
Cheers,
Ian
Re: %module-public-interface
Hi Andy,
On 27/04/10 21:34, Andy Wingo wrote:
Hi Ian,
On Fri 02 Apr 2010 02:11, Ian Hulin writes:
On 30/03/10 22:52, Ludovic � wrote:
Lilypond does:
--8<---cut here---start->8---
mod = scm_call_0 (maker);
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
--8<---cut here---end--->8---
Solution: do something like:
--8<---cut here---start->8---
#ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
scm_set_module_public_interface_x (mod, mod);
#else
scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
mod);
#endif
--8<---cut here---end--->8---
(We just need to add that function.)
As it appears here that you are trying to export everything from that
module (in a somewhat incorrect formulation -- I can explain if you
like), and that seems to be a sort of pattern, I'd suggest that instead
we offer a module-export-all! function. Here is some code to provide
such a function for pre-2.0 guile:
(cond-expand
((not guile-2)
(define (module-export-all! mod)
(define (fresh-interface!)
(let ((iface (make-module)))
(set-module-name! iface (module-name mod))
;; for guile 2: (set-module-version! iface (module-version mod))
(set-module-kind! iface 'interface)
(set-module-public-interface! mod iface)
iface))
(let ((iface (or (module-public-interface mod)
(fresh-interface!
(set-module-obarray! iface (module-obarray mod))
Use that to export all bindings instead. As it is, there are some shims
for %module-public-interface hackery to keep on working if deprecated
code is compiled in, but you should migrate to calling
module-export-all!, I think.
Then your C code would unconditionally:
scm_call_1 (scm_variable_ref (module_export_all_var), mod);
Regards,
Andy
Lilypond currently has a patch submitted to use your suggested guile
code to avoid using the reference to %module-public-interface in
Lilypond C++ code.
Please can you confirm that module-export-all! will be supplied in Guile
V2.0.
Cheers,
Ian Hulin
Re: summary: lilypond, lambda, and local-eval
Hi Andy and Guile developers, As the original OP about (local-eval) getting withdrawn please accept my thanks for the excellent work going on in these threads. I still follow it even though I barely understand a lot of the stuff that's being discussed. Thanks a million, guys, and compliments of the season, Cheers, Ian Hulin (LilyPond Guile V2 Migration troll)
Re: add-relative-load-path ? - scm_add_load_path too?
Hi Andy, Ludo,
I've just seen the add-load-path scheme function in the new git
documentation.
Please, please, pretty please can we have a scm_add_load_path API
equivalent callable from C/C++? The LilyPond initialization code
currently does disgusting things like faking
(eval (set! %load-path cons ( %load-path ) ) )
a call such as
(scm_add_load_path (scm_from_locale_string (" Hi all,
>
> In the following thread:
>
> http://thread.gmane.org/gmane.lisp.guile.user/8298/focus=8403
>
> there was a concern that it's difficult to set up the load path
> for simple one-off scripts.
>
> I had a proposal that we add something like this:
>
> (define-syntax add-relative-load-path (lambda (x) (syntax-case x
> () ((_ path) (string? (syntax->datum #'path)) (let* ((src
> (syntax-source #'x)) (current-file (or (and src (assq-ref src
> 'filename)) (error "Could not determine current file name")))
> (vicinity (dirname (canonicalize-path current-file))) (path-elt
> (in-vicinity vicinity (syntax->datum #'path #`(eval-when
> (compile load eval) (set! %load-path (cons #,path-elt
> %load-path
>
> Then in your script you would (add-relative-load-path ".").
>
> Maybe we need an `add-to-load-path' form that handles the
> eval-when, actually, so it would be
>
> (add-to-load-path (dirname (current-source-filename)))
>
> or something like that. (We'd have to define
> current-source-filename as well, in terms of
> current-source-location.)
>
> What do folks think? Is it work it?
>
> Andy
Re: add-relative-load-path ? - scm_add_load_path too?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Mark,
On 31/01/12 16:10, Mark H Weaver wrote:
> Replying to myself...
>
>> Probably the easiest option here is to simply prepend the
>> desired directories onto the GUILE_LOAD_PATH environment variable
>> before calling scm_boot_guile.
>
> On second thought, this is probably not a good idea, because you
> don't want this setting to propagate to other subprocesses. This
> is probably the best thing:
>
>> SCM var = scm_c_lookup ("%load-path"); scm_variable_set_x (var,
>> scm_cons (scm_from_locale_string (dir), scm_variable_ref
>> (var)));
>
> Does that work for you?
Yup, I've been able to turn it into a more general-purpose routine so
I can similarly prefix %load-compiled-path.
Thanks for the tips.
Cheers,
Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPKcslAAoJEBqidDirZqASwAwH/344eRUPqVP4kb405MfEIGNy
TcK6P+1BOFKCh5O6Kz6mYkGszi+OCqB/DNHAGR37vqTCm5Kbo7fbR1tVLulPGB3w
vdPsA4xTe0IzDI/jdmIb4B+cJ1aM+MlvokBZLafyCesF8/nYWi934NCbK0ze+aZY
jZoF1rzr2tDore8hGRam2p/zaN9rv7iY2FiuMAmjIsLVOqXu05TiSF5k6q2NNr1x
xf8hzjzR6TnjFnFQC4wMPcbct9bHPOpJx9HEdakHsGx7ECh8pMtam3EyuHlMr38u
DZ5v0LyjT85hOSTf+6hys9jscx65pz/ZdiInL6FDe7vHy0a8uawoOY2i6bC+mTE=
=TVBM
-END PGP SIGNATURE-
Re: Autocompilation/LilyPond
Hi David, Mark, I am still around, I've not had much time for hacking lately as I've been getting sick again, and the meds tend to sap the higher brain functions. On 09/03/12 19:27, David Kastrup wrote: > Mark H Weaver writes: > >> David Kastrup writes: >> >>>> In the long run, I think this is probably your best way >>>> forward, but admittedly it would require more work to make >>>> this transition. >>> >>> The main problem is that it requires such a large >>> reorganisation of the LilyPond sources that the attempts to do >>> it in that manner tended to consist of outdated nontrivially >>> rearranged parts before getting through peer review >>> successfully. LilyPond is quite a moving target. >>> >>> Ian Hulin has mostly worked on Guilev2 migration in that >>> manner, and it has caused him to do lots of futile work, a >>> major cause of frustration for him and of worry for others >>> because the large reorganisations made the work hard to >>> verify. >>> >>> So while this might be the "if everything was written from >>> scratch, it would make most sense to do it this way" approach, >>> it has proven less than fabulous as a migration strategy [...] >> >> Okay, understood. The other alternatives are workable, with the >> build script written in Scheme probably being the most >> future-proof of the remaining options. > > Sounds somewhat like it. > >> It occurs to me that if the "lilypond module" has not already >> been set up, > The module is '(lily). It's set up in the Lily initialization code in C++ thus: 1. main routine calls scm_boot_guile with callback to C++ routine main_with_guile. 2. main_with_guile 2.1 sets up scheme LOAD_PATH to prepend our local LilyPond root directory and the /scm subdirectory (this is so the modules declared in our kit's scheme files (like scm/display-lily.scm get autoloaded correctly). 2.2 calls ly_c_init_guile to define the '(lily) module in code and specify ly_init_ly_module as a callback. 2.2.1 ly_init_ly_callback 2.2.1.1 sets up some internal initialization functions, 2.2.1.2 dumps out some trace code, if required, about what it's doing 2.2.1.3 does the equivalent of (primitive_load_path "lily.scm") from code. 2.2.2 (now we're back in ly_c_init_guile). scm_c_define_module has returned a handle to the new module, step 2.2.1.3 has loaded and evaluated all the stuff in lily.scm - including the load loop with all the component scheme file held in scm/*.scm with their problematic interactions. 2.2.3 do equivalent of (use_modules '(lily)) 2.3 (now we're back in main_with_guile). Set up local C++ constructors 2.4 set up fonts stuff 2.5 set up for multi-file compilation 2.5 process command-line options 2.6 set up handling to operate in server (jail) mode 2.7 look up and call the scheme entry-point in the '(lily) module to actually do the LilyPond compilations - there is no normal exit point from here, exiting the image is handled by scheme (exit) calls in the '(lily) code. So the "lilypond module" *is* normally set up when running with Guile 1.8, providing nothing breaks when lily.scm is loaded. > I think it will be. > >> then it will be completely empty and not suitable for compiling >> anything, so in that case you'll want to do something closer to >> this: >> >> (define lilypond-module (make-fresh-user-module)) (module-use! >> lilypond-module (resolve-interface '(guile))) (set-module-name! >> lilypond-module '(LILYPOND MODULE NAME)) (set-current-module >> lilypond-module) (for-each (lambda (base-name) (let >> ((scm-file-name (string-append base-name ".scm")) (go-file-name >> (string-append base-name ".go"))) (compile-file scm-file-name >> #:output-file go-file-name #:env (current-module) #:opts >> %auto-compilation-options) (load scm-file-name))) >> ) >> >> BTW, if I wanted to take a look to try to get it working myself, >> what branch of the lilypond git repo should I look at? > > Believe it or not, master. There is nothing in the public > repository that would have more progress regarding Guilev2 > migration (it might make sense to ask Ian whether you can pull > something from him). master is always kept in a state where it > compiles, passes regtests, and builds the documentation, and should > not trail the "staging" branch (where new changes get pushed) for > more than a day. Unless "staging" does not pass the tests, in > which case the automated push does not proceed. > > You can look for open issues regardi
