IRC channel logs
2025-08-16.log
back to list of logs
<kyuvi>@mwette thanks a lot for that <kyuvi>when I try it is complaining about (system foreign-library) <kyuvi>is this supposed to be in guile iteslf? <kyuvi>aha this is in a newer guile, I am still on 3.0.5 <mwette>You are on fedora, right? Redhat does not seem to love Guile. <kyuvi>no on an old debian it is a bit complicated <mwette>try to comment out #:use-module (system foreign-library) and replace the search with (define (foreign-pointer-search name) (let loop ((dll (cons (dynamic-link) dl-lib-list))) (cond ((null? libs) (error "no linkie")) ((false-if-exception (dynamic-func name (car dll)))) (loop (cdr ddl))))) <mwette>also define dl-lib-list with the list in the file (but not #f) <mwette>sorry list of strings needs to be list of (dynamic-link <string>) <kyuvi>is this in the c99/ffi-help-cd.scm <kyuvi>I managed to get 3.0.9 through guix but after producing glib.scm , it states it can not find it <kyuvi>compiling `.local/opt/gu//ffi/gobject.ffi' ... <kyuvi>compile-ffi: error: compiled dependent (ffi glib) not found <mwette>The #:use-ffi-module opt's are commented out in my last .ffi above <mwette>So you should'nt need those now, since no glib stuff is referenced anymore. <mwette>(define dl-lib-list (map dynamic-link '("libwnck-3" "libgtk-3" ...))) <kyuvi>what is the dl-lib-list about? which file should it be put in? <mwette>The mlibwnck.scm, after you create it, before the replacement foreign-pointer-search code I provided above. <kyuvi>ok got the mlibwnck.scm file <mwette>guild compile-ffi -X ffi/mlibwnck.ffi will generate ffi/mlibwnck.scm and not try to generate the .go file; then you edit the .scm and guild compile -O0 ffi/mlibwnck.scm <kyuvi>aha yes I will need that to run it on the fedora machine <kyuvi>sorry can you look at the code above, should "libs" be "dl-lib-list"? <mwette>(null? libs) should be (null? dll) i think; <kyuvi>should there not be an else in the cond? <kyuvi>should it look like that finally? <mwette>can't see it; is the link right? <user>@mwette thanks that will be really helpful <old>I failed to expand a syntax transformer in a match pattern. any possibility of doing so? <old>(define-syntax-rule (or-files) (or "--file")) <user>sneek: later tell mwette, Thanks for all the help, it will be really helpful <old>(match ... ((or-files) ...))) <hadderly> (apply make-shared-array (make-array #t) (const '()) frame) <hadderly> (lambda i (apply op (map (lambda (x) (apply array-slice x i)) x)))) <mwette>Kyuvi: my internet went out for a bit; for 2.03 I'm adding an option to avoid (system foreign-library) as you now have <sneek>Welcome back mwette, you have 2 messages! <sneek>mwette, user says: Thanks for all the help, it will be really helpful <dariqq>hi, is there a convenient way to have one module reexport submodules automatically? i.e. i have (foo bar) and (foo baz) and want both to be reexported in (foo) without keeping track of the exports manually <identity>dariqq: you could (module-use! (module-public-interface (current-module)) (resolve-interface module)), where ‘module’ is the module you want to re-export, though this is pretty ugly <dariqq>yeah i found in serveral guile packages sometimes. In the root guix.scm is is even in a 'eval-when (eval load compile)' and now I dont know if I should add that as well? <dariqq>* the guix.scm inside the guix repository <dariqq>i made it a syntax rule inspired by some of the similar ones i found. It works great thanks <rlb>hadderly: you were just asking what const does? If so, "info guile 'higher-order functions'" should find it. <Kyuvi>mwette``you mean to the main repository? that will be useful as some systems are stuck on guilie 2.0.14 (for security reasons maybe?) I think I should ask them about that <rlb>...hmm, wondering about us passing through libunistring iconveh.h enum values (in strings.h) -- means a change in a libunistring major version could break our ABI, and also means we can't easily/safely add our own failed-conversion-handler values without risking collision? <rlb>Was thinking about it wrt the "noncharacters" r7rs proposal, where I'm thinking we'd need an additional handler. <mwette>Kyuvi: yes `guild compile-ffi -w ffi/mlibwnck.ffi'