IRC channel logs
2023-09-03.log
back to list of logs
<apteryx>if I want to use a macro argument in a unhygienic way, I must use syntax-case, right? <apteryx>I was trying to have some macro or procedure that generates Guix packages; turns out if I leave the (define-public some-name ...) to be done manually, a procedure suffices <RhodiumToad>(you do realize that define-public is itself a macro...?) <daviid>RhodiumToad: i found and fixed another (nasty) bug, related to the mechanism that allows to expose goops slot(s) as g-property(ies) - if the user defines an init-keyword for such a slot, and uses it when instantiating the derived class they are working on, it would raise an exception saying 'a slot is unbound ...' <daviid>RhodiumToad: if you save this test module, add-to-load-path ... ,use (add-property) - then try (make <foo> #:bar 7) it should fail, where here after the fix (i still need to clean and push, it works fine (make <foo> #:bar 7) => $3 = #<<foo> 7fb3a73673c0> (!bar $3) => 7 <daviid>you may have to coment lines 43 - 46, i locally added support for #:g-param `(object ...) and also need to push ... will let you know when pushed :) <daviid>RhodiumToad: pushed, both the g-param-spec-object support and the fix to the above described bug (for info, #:g-param exposed slots currently support int, enum and object g-param-spec ... wip) <apteryx>is there something in Guile to help me reason with top level (module) dependency cycles? <apteryx>I'm struggling to figure out the root cause of why using a binding from module A in module B causes the LOAD phase to fail with an unbound variable from C, that later variable being used by A <mwette>I don't know of anything. Are you suspecting a circular dependency? I ran into that issue before. <civodul>apteryx: one trick is to do (resolve-module '(A)) at the REPL and then look at the backtrace <civodul>another option is to (set! %load-verbosely #t) prior to loading the module (though the output is flat) <apteryx>oh! thanks, I didn't know about these tricks! <apteryx>mwette: yes, I suspect a circular dependency <apteryx>I'll open a guix report about it, and try the new tricks I learnt here, so as to "document" these in the process <apteryx>RhodiumToad: It wasn't clear to me in the first place whether define-public was some macro or something taken for granted "in the core", but that explains why you'd have to use a macro to expand to some (define-public ...) expression. <apteryx>The hygiene issue had to do with computing the first argument of define-public based from the argument of the syntax (a package variant name), e.g. (make-ergodox-firmware dvorak-kinesis-mod) -> (define-public ergodox-firmware-dvorak-kinesis-mod (package ...)) <apteryx>I think it's usually prohibited to expand a macro binding (its argument) into its surrounding scope for hygiene, if I got this right. <RhodiumToad>(symbol-append (syntax->datum #'symbol1) '- (syntax->datum #'symbol2)) or something like that, in place of (string->symbol ...) <RhodiumToad>I wanted to see if it was possible to do with syntax parameters instead, but haven't managed to make it work yet <mwette>apteryx: Are you AVRs? I have been off for a year or so but played much before. Wrote a multi-MCU simulator in C and use guile as front end. <RhodiumToad>daviid: question, is it strictly necessary for (g-golf) to re-export quite as much as it does? specifically it re-exporting all of (system foreign) is causing some nuisance to me <daviid>RhodiumToad: no, strictly necessary certainly not, but it is extremely practical i would say, at least it is for me :), as as things are, ,use (g-golf) and i have everything i need to work ... <RhodiumToad>yeah, but exporting so much leads to a big problem with collisions <daviid>RhodiumToad: you mean with your own module(s) i guess? the collision g-golf has to deal with are inherent to the use of so called short method names, hence connect, map, delete, are 'promoted' generic functions, with their default method beingthe one provided by core guile or the module that provides the functionality <RhodiumToad>the one causing me an issue at the moment is 'void from (system foreign) <apteryx>mwette: not much into it, just have a 2015 Massdrop ergodox keyboard box I had never assembled, and just started looking into it, haha <apteryx>it apparently has an AVR microcontroller <RhodiumToad>hm, also specifying a #:prefix on the import seems to negate all re-exports? <RhodiumToad>or maybe I just don't understand the module system enough <daviid>RhodiumToad: void? are you redefining void in your own module? - anyway, i would suggest, as a 'temporary measure', is to locally copy (g-golf) to (g-golf-minimal) [or a better name ...] - i'll try to find some time to work on this to, but to get you 'solved' immediately ... <apteryx>civodul: the module loads from the REPL, so I'm trying with (set! %load-verbosely #t) now <apteryx>I've put it in (guix config) and it prints loading info! <daviid>RhodiumToad: it could be, i never tried the re-export macro (which i did snarfed fro guile-gnome) against the #:prefix option <daviid>RhodiumToad: i would suggest you make your own g-golf-minimal module, when i can find sometime, i'll will also provide such a module ... <daviid>but what i would do, if in your position, is to name or prefix things in my own modules ... and avoid any clash with anything that comes from guile or a gule module, except if you promote those as generic functions - but void is a costant, so that would not solve this clash <apteryx>the modules appear loaded twice according to the output, which is weird <apteryx>nevermind the last paste, it was with a local (unfinished) change turning avr-gcc into a proc, in an atempt to delay its evaluation <RhodiumToad>daviid: ok, so the way you're doing re-export (or indeed the way I myself have done re-export in other modules) does not play well with #:prefix for some reason <RhodiumToad>symbols listed in #:re-export (...) do get prefixed, but stuff referenced by module-use! or module-use-interfaces! does not <RhodiumToad>(with a prefix specified, they just don't get imported at all) <RhodiumToad>this obviously is because specifying any of select, prefix, renamer causes the creation of a custom interface, and that includes only the symbols directly from the module public interface, not from other interfaces used by that one <RhodiumToad>soooo. it looks like re-exporting a whole module by adding a 'uses' to its public interface only half works. <RhodiumToad>the half that works works because module-variable is recursive when traversing the uses list of the specified module <RhodiumToad>but the code in resolve-interface that makes a new custom interface for the requested module does not recurse <apteryx>does the order of use-module directives matter in modules? <apteryx>is Guile able to resolve gracefully what should be loaded first? <dsmith>apteryx, Somewhere I remember seeing some code to make dot graphs of Guile module dependencies. I think ttn wrote it <dsmith>I kind of remember it being in examples/scripts/ But I don't see it there. <rlb>(different import issue) <rlb>iirc you can also have multiple expressions for the same module for different effects. <rlb>(Or rather, I think that "works", and I needed it in the past.) <apteryx>dsmith: sounds useful, but I can't find it <apteryx>RhodiumToad: thanks for confirming that <daviid>RhodiumToad: i don't use #:re-export, only once actually, in (g-golf hl-api events) - the way the public insterface of a module is re-exported is by calling module-use!, see (g-golf support module) - i would recommend you define your own g-golf 'minimal' module, and/or avoid name clashes in your own modules (that is what i would do) <dsmith>apteryx, I can't find it either. Yet. But I'll keep looking. <apteryx>I guess I could adjust the regexp ^^' <dsmith>I know I had one at one time. Was untangling all the circular dependencies in scwm modules <daviid>RhodiumToad: by waht means, i am curious - no, but happy to provide support for ... i never had to disconnect a signal, quite honestly i wasn't aware of the functionality :) <RhodiumToad>the old guile-gnome returned the id value from (connect), and allowed (disconnect obj id) <RhodiumToad>one use-case is for signals needed only once, such as at first map of the toplevel <daviid>RhodiumToad: it's been decades i didn't 'map' windows myself <daviid>:) you're porting really old stuff :) <RhodiumToad>I'm not mapping the window myself, it's for stuff in the app that needs to be started only after the toplevel window is displayed <daviid>g_object_disconnect - This method is not directly available to language bindings. - though it's possible 'to cook' something anyway, but is it really worth it? are you having a problem if you can't disconnect? <daviid>i'll do something better, but can you try (gi-import-by-name "GObject" "signal_handler_disconnect" #:force? #t) <daviid>you should be able to retreive the signal id using the signal cache <daviid>RhodiumToad: again i'll cook something better, but as in, for example - (gi-signal-cache-ref '<adw-demo-page-leaflet> 'next-page) => $7 = #<<signal> 7f875b3ded70> (!id $7) => $8 = 87 <daviid>RhodiumToad: looking at guile-gnome, it seems to me connect returns the handler_id (?), which is an gulong, the signal_id is a guint [ i am a bit confused because the gsignal.c code in guile-gnome defines both the signal_id and the handler_id as gulong ]