Weird module behaviour
Hi all, I'm trying to use Aleix Conchillo's guile-redis module for my project, and it revealed a surprising use-case. Namely, guile-redis consists of several modules that are put together in one meta-module, which looks more or less like this: (define-module (redis) #:use-module (redis main) #:use-module (redis commands connection) #:use-module (redis commands hashes) #:use-module (redis commands keys) ...) (define-syntax re-export-modules (syntax-rules () ((_ (mod ...) ...) (begin (module-use! (module-public-interface (current-module)) (resolve-interface '(mod ...))) ... (re-export-modules (redis main) (redis commands connection) (redis commands hashes) (redis commands keys) ...) So basically the meta-module adds the interfaces of its child modules. This isn't particularly surprising, because another way of creating a meta-module would be to enumerat all bindings from its child modules, which is a lot of work that would create an opportunity for desynchronization. However, it turns out that the modules export some names that would interfere with another names used in my project. Therefore, I decided to use the dedicated feature for avoiding such conflicts -- namely, renaming. If I (use-modules (redis)), everything works perfectly fine. However, if I try to use #:select, e.g. (use-modules ((redis) #:select (redis-connect))), I get an error: "no binding `redis-connect` in module (redis)". Furthermore, when I try to use the #:renamer feature, like (use-modules ((redis) #:renamer (symbol-prefix-proc 'redis:))) then I get neither redis-connect nor redis:redis-connect exported. I am almost certain that this weird behaviour stems from the way the meta-module is built (although I don't know the module system implementation well enough to point to the exact reason). However, the questions are: - if "resolve-interface" and "module-use!" are documented in the manual, shouldn't they inter-operate with #:select and #:rename features of use-modules? - if the above are to be considered dirty hacks, then what would be the proper way of creating meta-modules (other than listing all the exported bindings explicitly)? - or am I getting something wrong? Best regards, M.
Re: Weird module behaviour
Panicz Maciej Godek writes: > Furthermore, when I try to use the #:renamer feature, like > > (use-modules ((redis) #:renamer (symbol-prefix-proc 'redis:))) > > [...] Just a tip: you can do e.g. (use-modules ((foo) #:prefix foo-)). It seems many people don't know of it. Taylan
Re: Weird module behaviour
2014-09-25 16:25 GMT+02:00 Taylan Ulrich Bayirli/Kammer : >> [...] > > Just a tip: you can do e.g. (use-modules ((foo) #:prefix foo-)). It > seems many people don't know of it. No wonder, since there's not a single mention in the documentation, which is perceived as the document that makes things official.
Re: Weird module behaviour
Panicz Maciej Godek writes: > No wonder, since there's not a single mention in the documentation, > which is perceived as the document that makes things official. Oh snap. :-) The stable-2.0 branch has it documented. I also checked and it's even in 2.0.5 which Debian stable has so the feature should be fine to use in production code already. Taylan
Re: Weird module behaviour
Panicz Maciej Godek skribis: > I'm trying to use Aleix Conchillo's guile-redis module for my project, > and it revealed a surprising use-case. > Namely, guile-redis consists of several modules that are put together > in one meta-module, which looks more or less like this: > > (define-module (redis) > #:use-module (redis main) > #:use-module (redis commands connection) > #:use-module (redis commands hashes) > #:use-module (redis commands keys) > ...) > > (define-syntax re-export-modules > (syntax-rules () > ((_ (mod ...) ...) > (begin >(module-use! (module-public-interface (current-module)) > (resolve-interface '(mod ...))) > ... > > (re-export-modules > (redis main) > (redis commands connection) > (redis commands hashes) > (redis commands keys) > ...) > > So basically the meta-module adds the interfaces of its child modules. > This isn't particularly surprising, because another way of creating a > meta-module would be to enumerat all bindings from its child modules, > which is a lot of work that would create an opportunity for > desynchronization. As a side note, FYI I have some stuff called ‘generate-reexporter’ to help deal with the desync problem, at https://bitbucket.org/sortsmill/sortsmill-core-guile I almost always use R⁶RS-style modules but there is some support for Guilish notation in the stuff that is being re-exported.
Re: smob mark functions in 2.0
Hi Andy, Reviving a 3-year-old thread... Andy Wingo wrote in November 2011: > If you do implement a SMOB marking function, and you touch Scheme > objects in that marking function, you need to be very careful. > > Specifically, there is a warning in gc/gc_mark.h: > > /* WARNING: Such a mark procedure may be invoked on an unused object*/ > /* residing on a free list. Such objects are cleared, except for a */ > /* free list link field in the first word. Thus mark procedures may*/ > /* not count on the presence of a type descriptor, and must handle this */ > /* case correctly somehow. */ > > So, your mark function might see freed objects. This is terrible, but > it is the way that it is. The key is that, if you touch a Scheme object > in your mark function, to first do a check on that object, to see that > it is valid. You can check the TC bits of the first word, or otherwise > check that other words are non-NULL. Andy Wingo later replied to Ludovic: > On Thu 24 Nov 2011 00:12, l...@gnu.org (Ludovic Courtès) writes: > >>> So, your mark function might see freed objects. This is terrible, but >>> it is the way that it is. The key is that, if you touch a Scheme object >>> in your mark function, to first do a check on that object, to see that >>> it is valid. You can check the TC bits of the first word, or otherwise >>> check that other words are non-NULL. >> >> What about making that check in libguile before invoking the user’s mark >> function? > > Yes, we do that. I think you wrote that code! The problem was in a > mark function, accessing *other* Scheme objects. Mark H Weaver writes: > Andy Wingo writes: >> Specifically, there is a warning in gc/gc_mark.h: >> >> /* WARNING: Such a mark procedure may be invoked on an unused object >> */ >> /* residing on a free list. Such objects are cleared, except for a >> */ >> /* free list link field in the first word. Thus mark procedures may >> */ >> /* not count on the presence of a type descriptor, and must handle this >> */ >> /* case correctly somehow. >> */ >> >> So, your mark function might see freed objects. > > How can this happen? If you are marking an object, then presumably it > is still reachable, and therefore the objects it references are also > still reachable. If any of those reachable objects has been freed, > isn't that already a bug of a different kind? What am I missing? I never received an answer to this question. At the time it was merely a curiosity, but now I have a more pressing need to understand what's going on here. Regards, Mark
