* %module-public-interface @ 2010-03-30 20:45 Andy Wingo 2010-03-30 20:56 ` %module-public-interface Ludovic Courtès 2010-03-31 20:42 ` Hierarchical name space Ludovic Courtès 0 siblings, 2 replies; 21+ messages in thread From: Andy Wingo @ 2010-03-30 20:45 UTC (permalink / raw) To: guile-devel Hello, As you might well know, in every module that actually has a public interface (most all of them), there is an extra symbol bound in that module: %module-public-interface. It references, um, the public interface. Also in every module that has submodules, like (language tree-il) and (language tree-il compile-glil), the "supermodule" has a binding for the submodule. Do a (module-ref (resolve-module '(ice-9)) 'threads) sometime. It is, as my southern-US family would say, "turrible". But somehow it normally doesn't affect us. 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. Any ideas on what the right thing to do is? Just leave it? Add fields to modules for the public interface and submodules, but keep the %module-public-interface binding? Throw up our hands and dance around? Let me know, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-03-30 20:45 %module-public-interface Andy Wingo @ 2010-03-30 20:56 ` Ludovic Courtès 2010-03-30 21:07 ` %module-public-interface Andy Wingo 2010-03-31 20:42 ` Hierarchical name space Ludovic Courtès 1 sibling, 1 reply; 21+ messages in thread From: Ludovic Courtès @ 2010-03-30 20:56 UTC (permalink / raw) To: guile-devel Howdy! Andy Wingo <wingo@pobox.com> writes: > Do a (module-ref (resolve-module '(ice-9)) 'threads) > sometime. That’s the hierarchical naming scheme, not related to %module-public-interface but probably worth a discussion. > 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? > Any ideas on what the right thing to do is? Just leave it? Add fields to > modules for the public interface and submodules, but keep the > %module-public-interface binding? Throw up our hands and dance around? Yeah! 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? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-03-30 20:56 ` %module-public-interface Ludovic Courtès @ 2010-03-30 21:07 ` Andy Wingo 2010-03-30 21:52 ` %module-public-interface Ludovic Courtès 0 siblings, 1 reply; 21+ messages in thread From: Andy Wingo @ 2010-03-30 21:07 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel On Tue 30 Mar 2010 22:56, ludo@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 >> Any ideas on what the right thing to do is? Just leave it? Add fields to >> modules for the public interface and submodules, but keep the >> %module-public-interface binding? Throw up our hands and dance around? > > Yeah! > > 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? Dancing? OK! Also back compatibility. Er, yeah :) Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-03-30 21:07 ` %module-public-interface Andy Wingo @ 2010-03-30 21:52 ` Ludovic Courtès 2010-03-30 22:20 ` %module-public-interface Andy Wingo 2010-04-02 0:11 ` %module-public-interface Ian Hulin 0 siblings, 2 replies; 21+ messages in thread From: Ludovic Courtès @ 2010-03-30 21:52 UTC (permalink / raw) To: guile-devel Hello, Andy Wingo <wingo@pobox.com> writes: > On Tue 30 Mar 2010 22:56, ludo@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: --8<---------------cut here---------------start------------->8--- (let* ((m (resolve-module which)) (m-public (module-ref m '%module-public-interface))) (module-map (lambda (sym var) sym) m-public))) --8<---------------cut here---------------end--------------->8--- and: --8<---------------cut here---------------start------------->8--- (let* ((m (resolve-module ',module)) (p (module-ref texmacs-user '%module-public-interface)) (r (module-ref p ',name #f))) (if (not r) (texmacs-error "lazy-define" ,(string-append "Could not retrieve " (symbol->string name)))) (apply r args)))))) --8<---------------cut here---------------end--------------->8--- Solution: use ‘resolve-interface’. Gossip does: --8<---------------cut here---------------start------------->8--- (append! (delq! '%module-public-interface (module-map (lambda (sym var) sym) mod)) (hash-fold (lambda (k v r) (cons k r)) '() blocks))) --8<---------------cut here---------------end--------------->8--- This snippet won’t see any difference. >> 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? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-03-30 21:52 ` %module-public-interface Ludovic Courtès @ 2010-03-30 22:20 ` Andy Wingo 2010-04-02 0:11 ` %module-public-interface Ian Hulin 1 sibling, 0 replies; 21+ messages in thread From: Andy Wingo @ 2010-03-30 22:20 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel On Tue 30 Mar 2010 23:52, ludo@gnu.org (Ludovic Courtès) writes: >>> 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. Hm. I guess you're right. In the case with deprecated foo enabled, we can add a %module-public-interface definition in the root module, which maps to a module with a binder procedure that will raise an error. That way we can catch apps that we don't know about. Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-03-30 21:52 ` %module-public-interface Ludovic Courtès 2010-03-30 22:20 ` %module-public-interface Andy Wingo @ 2010-04-02 0:11 ` Ian Hulin 2010-04-02 9:37 ` %module-public-interface Ludovic Courtès 2010-04-27 20:34 ` %module-public-interface Andy Wingo 1 sibling, 2 replies; 21+ messages in thread From: Ian Hulin @ 2010-04-02 0:11 UTC (permalink / raw) To: guile-devel; +Cc: lilypond-devel@gnu.org, guile-devel Hi Ludovic, On 30/03/10 22:52, Ludovic � wrote: > Hello, > > Andy Wingo<wingo@pobox.com> writes: > >> On Tue 30 Mar 2010 22:56, ludo@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: <snip> >>> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-02 0:11 ` %module-public-interface Ian Hulin @ 2010-04-02 9:37 ` Ludovic Courtès 2010-04-02 11:58 ` %module-public-interface Ian Hulin 2010-04-27 20:34 ` %module-public-interface Andy Wingo 1 sibling, 1 reply; 21+ messages in thread From: Ludovic Courtès @ 2010-04-02 9:37 UTC (permalink / raw) To: Ian Hulin; +Cc: lilypond-devel@gnu.org, guile-devel Hi Ian, Ian Hulin <ian@hulin.org.uk> writes: > On 30/03/10 22:52, Ludovic � wrote: >> Andy Wingo<wingo@pobox.com> writes: >> >>> On Tue 30 Mar 2010 22:56, ludo@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: > <snip> >>>> 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. ;-) When is the new Lilypond release due? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-02 9:37 ` %module-public-interface Ludovic Courtès @ 2010-04-02 11:58 ` Ian Hulin 2010-04-02 18:50 ` %module-public-interface Patrick McCarty 2010-04-06 14:00 ` %module-public-interface Han-Wen Nienhuys 0 siblings, 2 replies; 21+ messages in thread From: Ian Hulin @ 2010-04-02 11:58 UTC (permalink / raw) To: Ludovic Courtès; +Cc: lilypond-devel@gnu.org, guile-devel On 02/04/10 10:37, Ludovic � wrote: > Hi Ian, > > Ian Hulin<ian@hulin.org.uk> writes: > > >> On 30/03/10 22:52, Ludovic � wrote: >> > >>> Andy Wingo<wingo@pobox.com> writes: >>> >>> >>>> On Tue 30 Mar 2010 22:56, ludo@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: >>> >> <snip> >> >>>>> 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 (graham@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 (pnorks@gmail.com). Cheers, Ian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-02 11:58 ` %module-public-interface Ian Hulin @ 2010-04-02 18:50 ` Patrick McCarty 2010-04-03 0:52 ` %module-public-interface Graham Percival 2010-04-06 14:00 ` %module-public-interface Han-Wen Nienhuys 1 sibling, 1 reply; 21+ messages in thread From: Patrick McCarty @ 2010-04-02 18:50 UTC (permalink / raw) To: Ian Hulin; +Cc: Ludovic Courtès, guile-devel, lilypond-devel On 2010-04-02, Ian Hulin wrote: > > 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. This is really just a stricter adherence to the Scheme R5RS. (if ...) can only contain *expressions*, IIUC, and (define ...) is a top-level definition, not an expression. But yes, either LilyPond will need to adapt to these stricter guidelines, or Guile will loosen its policy with respect to (if ...) statements. > 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. I think almost everything is fixed on the C++ side now. > Graham, Vincent, is it worth opening a tracker to capture > forward-compatibility issues with Guile? We already have one (sort of): http://code.google.com/p/lilypond/issues/detail?id=963 > Thanks for your feedback so far, Ludo. The other Lily developer who > has done anything with Guile 1.9/V2.0 is Patrick McCarty > (pnorks@gmail.com). That's <pnorcks@gmail.com>. I don't want any email reaching the wrong mailbox. :-) -Patrick ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-02 18:50 ` %module-public-interface Patrick McCarty @ 2010-04-03 0:52 ` Graham Percival 0 siblings, 0 replies; 21+ messages in thread From: Graham Percival @ 2010-04-03 0:52 UTC (permalink / raw) To: Patrick McCarty Cc: Ian Hulin, Ludovic Courtès, lilypond-devel, guile-devel On Fri, Apr 02, 2010 at 11:50:08AM -0700, Patrick McCarty wrote: > On 2010-04-02, Ian Hulin wrote: > > > > Graham, Vincent, is it worth opening a tracker to capture ITYM Valentin. > > forward-compatibility issues with Guile? > > We already have one (sort of): > http://code.google.com/p/lilypond/issues/detail?id=963 Not really; that's intended for things like "we need to use fontforge 2010.03.02 or higher!". And it'll be closed in a few weeks. I've added issue 1055: http://code.google.com/p/lilypond/issues/detail?id=1055 Cheers, - Graham ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-02 11:58 ` %module-public-interface Ian Hulin 2010-04-02 18:50 ` %module-public-interface Patrick McCarty @ 2010-04-06 14:00 ` Han-Wen Nienhuys 2010-04-06 14:32 ` %module-public-interface Ludovic Courtès 1 sibling, 1 reply; 21+ messages in thread From: Han-Wen Nienhuys @ 2010-04-06 14:00 UTC (permalink / raw) To: Ian Hulin; +Cc: Ludovic Courtès, guile-devel, lilypond-devel@gnu.org On Fri, Apr 2, 2010 at 8:58 AM, Ian Hulin <ian@hulin.org.uk> wrote: >>>>>> How do they use it? >>>>>> >>>>> >>>>> Linking to the evil empire: >>>>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search (ehh?) >> 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 (graham@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. Is Guile 2.0 already released? I think it makes sense to forget about guile 2.0 for the 2.14 release, and require 2.0 for the 2.16 release. We could scrap lots of hairy GC code if we could move to 2.0 (2.0 supports boehm GC, right?) > 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. There may be lots of hairiness in the module interface; I sort of made up functions as I went along, since it was largely undocumented. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-06 14:00 ` %module-public-interface Han-Wen Nienhuys @ 2010-04-06 14:32 ` Ludovic Courtès 0 siblings, 0 replies; 21+ messages in thread From: Ludovic Courtès @ 2010-04-06 14:32 UTC (permalink / raw) To: hanwen; +Cc: Ian Hulin, guile-devel, lilypond-devel@gnu.org Hi, Han-Wen Nienhuys <hanwenn@gmail.com> writes: > On Fri, Apr 2, 2010 at 8:58 AM, Ian Hulin <ian@hulin.org.uk> wrote: [...] >> I'm not the ReleaseMeister for Lilypond; you'll get a better picture by >> talking to Graham Percival (graham@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. > > Is Guile 2.0 already released? No. 1.9 pre-releases are available from alpha.gnu.org (make sure to give it a try!); 2.0 should happen within a couple of months. > I think it makes sense to forget about guile 2.0 for the 2.14 release, > and require 2.0 for the 2.16 release. We could scrap lots of hairy GC > code if we could move to 2.0 (2.0 supports boehm GC, right?) Yes. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-02 0:11 ` %module-public-interface Ian Hulin 2010-04-02 9:37 ` %module-public-interface Ludovic Courtès @ 2010-04-27 20:34 ` Andy Wingo 2010-05-15 20:32 ` %module-public-interface Ian Hulin 1 sibling, 1 reply; 21+ messages in thread From: Andy Wingo @ 2010-04-27 20:34 UTC (permalink / raw) To: Ian Hulin; +Cc: lilypond-devel@gnu.org, guile-devel Hi Ian, On Fri 02 Apr 2010 02:11, Ian Hulin <ian@hulin.org.uk> 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 -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-04-27 20:34 ` %module-public-interface Andy Wingo @ 2010-05-15 20:32 ` Ian Hulin 2010-05-21 9:48 ` %module-public-interface Andy Wingo 0 siblings, 1 reply; 21+ messages in thread From: Ian Hulin @ 2010-05-15 20:32 UTC (permalink / raw) To: guile-devel; +Cc: lilypond-devel Hi Andy, On 27/04/10 21:34, Andy Wingo wrote: > Hi Ian, > > On Fri 02 Apr 2010 02:11, Ian Hulin<ian@hulin.org.uk> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: %module-public-interface 2010-05-15 20:32 ` %module-public-interface Ian Hulin @ 2010-05-21 9:48 ` Andy Wingo 0 siblings, 0 replies; 21+ messages in thread From: Andy Wingo @ 2010-05-21 9:48 UTC (permalink / raw) To: Ian Hulin; +Cc: lilypond-devel, guile-devel On Sat 15 May 2010 22:32, Ian Hulin <ian@hulin.org.uk> writes: > Please can you confirm that module-export-all! will be supplied in Guile > V2.0. Yep, it's in git. Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Hierarchical name space 2010-03-30 20:45 %module-public-interface Andy Wingo 2010-03-30 20:56 ` %module-public-interface Ludovic Courtès @ 2010-03-31 20:42 ` Ludovic Courtès 2010-03-31 22:31 ` Andy Wingo 1 sibling, 1 reply; 21+ messages in thread From: Ludovic Courtès @ 2010-03-31 20:42 UTC (permalink / raw) To: guile-devel Hey, Andy Wingo <wingo@pobox.com> writes: > Also in every module that has submodules, like (language tree-il) and > (language tree-il compile-glil), the "supermodule" has a binding for the > submodule. Do a (module-ref (resolve-module '(ice-9)) 'threads) > sometime. I think I found a possible use case for the hierarchical name space. :-) Suppose we want something like PLaneT or Eggs, let’s call it GUMM (Guile’s Unified Module Machinery). Ideally, we’d want to be able to write this: (use-modules (gumm foo bar)) Such that: - If a (foo bar) module exists locally, it is used - else if ftp://example.org/gumm/foo/bar.scm exists it is downloaded and ‘resolve-interface’d - else an error is raised. The hierarchical name space allows the (gumm) module to have a lazy binder procedure that will catch all such lookups so that it can actually do its job. QED? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Hierarchical name space 2010-03-31 20:42 ` Hierarchical name space Ludovic Courtès @ 2010-03-31 22:31 ` Andy Wingo 2010-04-07 22:42 ` Julian Graham 0 siblings, 1 reply; 21+ messages in thread From: Andy Wingo @ 2010-03-31 22:31 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel On Wed 31 Mar 2010 22:42, ludo@gnu.org (Ludovic Courtès) writes: > Hey, > > Andy Wingo <wingo@pobox.com> writes: > >> Also in every module that has submodules, like (language tree-il) and >> (language tree-il compile-glil), the "supermodule" has a binding for the >> submodule. Do a (module-ref (resolve-module '(ice-9)) 'threads) >> sometime. > > I think I found a possible use case for the hierarchical name space. :-) > > Suppose we want something like PLaneT or Eggs, let’s call it GUMM > (Guile’s Unified Module Machinery). Ideally, we’d want to be able to > write this: > > (use-modules (gumm foo bar)) Ew. I even forgot that I did this with slib a while back. I'm still inclined to think that the module namespace hierarchy (and it is a hierarchy) should not impinge on the environment of an evaluation. But, not something we can change right now. A -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Hierarchical name space 2010-03-31 22:31 ` Andy Wingo @ 2010-04-07 22:42 ` Julian Graham 2010-04-07 23:01 ` Ludovic Courtès 0 siblings, 1 reply; 21+ messages in thread From: Julian Graham @ 2010-04-07 22:42 UTC (permalink / raw) To: Andy Wingo; +Cc: Ludovic Courtès, guile-devel Hi Andy and Ludo, > I'm still inclined to think that the module namespace hierarchy (and it > is a hierarchy) should not impinge on the environment of an evaluation. > But, not something we can change right now. This is actually causing me some difficulty -- I'm implementing the R6RS composite library, which imports and then re-exports the bindings of a lot of the individual R6RS standard libraries. I'm running into a problem with `(rnrs syntax-case)', which exports `syntax-case'. Using the conventional set of module system introspection procedures (`module-ref', `module-variable', etc.), there's no way to see the syntax transformer and not the module -- to obtain the former, you need to use `nested-ref' (or some other workaround) instead. Any ideas? Regards, Julian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Hierarchical name space 2010-04-07 22:42 ` Julian Graham @ 2010-04-07 23:01 ` Ludovic Courtès 2010-04-08 7:29 ` Andy Wingo 0 siblings, 1 reply; 21+ messages in thread From: Ludovic Courtès @ 2010-04-07 23:01 UTC (permalink / raw) To: Julian Graham; +Cc: Andy Wingo, guile-devel Hi, Julian Graham <joolean@gmail.com> writes: >> I'm still inclined to think that the module namespace hierarchy (and it >> is a hierarchy) should not impinge on the environment of an evaluation. >> But, not something we can change right now. > > This is actually causing me some difficulty -- I'm implementing the > R6RS composite library, which imports and then re-exports the bindings > of a lot of the individual R6RS standard libraries. I'm running into > a problem with `(rnrs syntax-case)', which exports `syntax-case'. Unfortunately I don’t think a module names can contain ‘syntax-case’, just like they can’t contain ‘eval’, ‘+’, etc. :-( I can’t think of a work around. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Hierarchical name space 2010-04-07 23:01 ` Ludovic Courtès @ 2010-04-08 7:29 ` Andy Wingo 2010-04-08 8:39 ` Ludovic Courtès 0 siblings, 1 reply; 21+ messages in thread From: Andy Wingo @ 2010-04-08 7:29 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel Hi, On Thu 08 Apr 2010 01:01, ludo@gnu.org (Ludovic Courtès) writes: > Julian Graham <joolean@gmail.com> writes: > >>> I'm still inclined to think that the module namespace hierarchy (and it >>> is a hierarchy) should not impinge on the environment of an evaluation. >>> But, not something we can change right now. >> >> This is actually causing me some difficulty -- I'm implementing the >> R6RS composite library, which imports and then re-exports the bindings >> of a lot of the individual R6RS standard libraries. I'm running into >> a problem with `(rnrs syntax-case)', which exports `syntax-case'. > > Unfortunately I don’t think a module names can contain ‘syntax-case’, > just like they can’t contain ‘eval’, ‘+’, etc. :-( Explain more? > I can’t think of a work around. We need to separate module namespaces from value namespaces. Lazy binding / module lookup can be implemented differently from lazy binders. Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Hierarchical name space 2010-04-08 7:29 ` Andy Wingo @ 2010-04-08 8:39 ` Ludovic Courtès 0 siblings, 0 replies; 21+ messages in thread From: Ludovic Courtès @ 2010-04-08 8:39 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel Hi, Andy Wingo <wingo@pobox.com> writes: > Hi, > > On Thu 08 Apr 2010 01:01, ludo@gnu.org (Ludovic Courtès) writes: > >> Julian Graham <joolean@gmail.com> writes: >> >>>> I'm still inclined to think that the module namespace hierarchy (and it >>>> is a hierarchy) should not impinge on the environment of an evaluation. >>>> But, not something we can change right now. >>> >>> This is actually causing me some difficulty -- I'm implementing the >>> R6RS composite library, which imports and then re-exports the bindings >>> of a lot of the individual R6RS standard libraries. I'm running into >>> a problem with `(rnrs syntax-case)', which exports `syntax-case'. >> >> Unfortunately I don’t think a module names can contain ‘syntax-case’, >> just like they can’t contain ‘eval’, ‘+’, etc. :-( > > Explain more? Well, the problem has apparently vanished in 1.9: --8<---------------cut here---------------start------------->8--- $ cat foo.scm (define-module (foo) #:export (bar)) (define bar 1) $ cat foo/eval.scm (define-module (foo eval) #:export (foo)) (define foo 2) $ guile -L . GNU Guile 1.9.9 Copyright (C) 1995-2010 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (use-modules (foo)) ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-autocompile argument to disable. ;;; compiling ./foo.scm ;;; compiled /home/ludo/.cache/guile/ccache/2.0-0.P-LE-8/home/ludo/src/nixpkgs/foo.scm.go scheme@(guile-user)> (use-modules (foo eval)) ;;; compiling ./foo/eval.scm ;;; compiled /home/ludo/.cache/guile/ccache/2.0-0.P-LE-8/home/ludo/src/nixpkgs/foo/eval.scm.go scheme@(guile-user)> $ ./result/bin/guile -L . guile> (use-modules (foo)) guile> (use-modules (foo eval)) ERROR: In procedure struct-vtable: ERROR: Wrong type argument in position 1 (expecting struct): #<primitive-procedure eval> ABORT: (wrong-type-arg) guile> (version) $1 = "1.8.7" --8<---------------cut here---------------end--------------->8--- Fishy... Thanks, Ludo’. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2010-05-21 9:48 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-03-30 20:45 %module-public-interface Andy Wingo 2010-03-30 20:56 ` %module-public-interface Ludovic Courtès 2010-03-30 21:07 ` %module-public-interface Andy Wingo 2010-03-30 21:52 ` %module-public-interface Ludovic Courtès 2010-03-30 22:20 ` %module-public-interface Andy Wingo 2010-04-02 0:11 ` %module-public-interface Ian Hulin 2010-04-02 9:37 ` %module-public-interface Ludovic Courtès 2010-04-02 11:58 ` %module-public-interface Ian Hulin 2010-04-02 18:50 ` %module-public-interface Patrick McCarty 2010-04-03 0:52 ` %module-public-interface Graham Percival 2010-04-06 14:00 ` %module-public-interface Han-Wen Nienhuys 2010-04-06 14:32 ` %module-public-interface Ludovic Courtès 2010-04-27 20:34 ` %module-public-interface Andy Wingo 2010-05-15 20:32 ` %module-public-interface Ian Hulin 2010-05-21 9:48 ` %module-public-interface Andy Wingo 2010-03-31 20:42 ` Hierarchical name space Ludovic Courtès 2010-03-31 22:31 ` Andy Wingo 2010-04-07 22:42 ` Julian Graham 2010-04-07 23:01 ` Ludovic Courtès 2010-04-08 7:29 ` Andy Wingo 2010-04-08 8:39 ` Ludovic Courtès
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).