IRC channel logs
2024-12-27.log
back to list of logs
<dodoyada>to use an srfi my understanding is that for the repl I can pass `--use-srfi=123` but if I'm defining a module I should explicitly `#:use-module (srfi srfi-123)`, is that right? Is there somewhere within a module structure that I could put a bunch of use-modules so I don't have to include srfis everywhere? <lechner>dodoyada / i am a newbie, so I put (use-modules ...) wherever I want! <lechner>but maybe your question is about something else <rlb>dodoyada: fwiw, I favor making modules "self contained", but I also favor clojure-style namespace conventions, making it very explicit where everything comes from (i.e. always use a prefix/ or select). <rlb>It's more work up front, but that's a one-time cost in most cases. <rlb>And it's quite nice when grepping, and or reading a module -- also means you can't ever be surprised by new exports from your deps. <dodoyada>lechner: I can get srfis to work but I want to consider them more or less "base level", things that should be baked into the language, so I don't like `#use-modules (srfi srfi-1)` because I want to be able to use `fold` etc without needing to call for it <dodoyada>rlb: I'm the same, I just don't like it for things that would be equivalently in clojure.core <rlb>That one's kind of excessive because it *is* more or less clojure.core :) <dodoyada>should I be doing something similar for -r7rs? As in just call `install-r7rs!` in project entry points? I just have it as a repl option atm <lechner>dsmith / Thanks for those code samples! Is the 'let' enough for a global variable, or do I have to use set! on it in the beginning, too? <lechner>actually, I'm not sure that question made any sense <lechner>I do use set! to modify %load-path for the excursion <dsmith>There is a different way. Make it have let syntax, So (let ((global newvalue) ...) your code) <dsmith>Don't know how to write that though <Ironsmith>hello, is there a helper or predefined mechanism to separate out keyword arguments from positional arguments that come in #:rest? that is to say, if i use both #:key and #:rest in my define* procedure definition, is there a shorthand way to just get the positional arguments? currently #:rest includes both <Ironsmith>for example, this: `(define* (modify-json #:key (file "package.json") #:rest modifications) (display "modifications: ") (display modifications))` called with `(modify-json "test" #:file "testo.json" "blah" )` will output `modifications: (test #:file testo.json blah)` <Ironsmith>while i'm looking for `modifications` to just be `(test blah)` in this case <lechner>dsmith / Hi, may I use an earlier version of the macro in my shell interaction helper Guile-Exec, please? Did I give proper credit? https://bpa.st/DRSA <to-hu>I think I found a bug in the srfi-64 implementation of test-group. Are there any guidelines how to file a bug report? Thank you :) <mwette>Seems like a BUG that #:rest arg includes keywords, keyword vals and rest vals. <mwette>OK. I confused with #:optional, I think that's what OP wants <mwette>maybe not, I never realiazed #:rest works that way, I should check my stuff <dthompson>it's odd but section 6.7.4.1 explains why it is this way <mwette>makes sense from that perspective: one could make a loop to filter out the keyword-value pairs <lechner>dthompson / mwette / from what i remember that happens---in my opinion, unnecessarily---somewhere in the Guix booloader code. it's a total mess <dariqq>hello, is anyone here familiar with g-golf? <dariqq>I am trying to use it via libguile and as soon as i link my c program with gobject things break down and I get lots of glib warnings and errors <dariqq>glib is starting to complain that classes dont have a property they definitly have, a guile exception for 'no applicable method ' and various other fun things <ekaitz>dariqq: i have had that issue in the past and I don't know why that happened <ekaitz>in my case i think it was because I had two glibs in my system, one from the system itself and another from the guix shell i was at <dariqq>ekaitz: Thanks a lot, that looks like the problem. At least my very simplified test example works without issues on fedora <dariqq>Now i just need to convince guix to use the same glib for both <dariqq>adding --no-grafts to guix shell seems to do the trick, would have never thought that that was the problem/solution. Thanks again ekaitz <lechner>Hi, is the lowercase 'guile-systems-extensions-path' still a thing? The manual mentions it, as well as GUILE_SYSTEM_EXTENSIONS_PATH, but I get "Unbound variable" when trying to parameterize it <rlb>Did you select it? use-modules ((system foreign-library) #:select (guile-system-extensio <rlb>(use-modules ((system foreign-library) #:select (guile-system-extensions-path))) <daviid>dariqq: you don't need libguile, can you just try any example, there are quite a few, and here, as well as on every distro i am aware of, there not a single warning ... <daviid>dariqq: ah guix, i missed that msg, so you're ok now <daviid>dariqq: what is the version of g-golf in guix these days? <daviid>it used to be quite out dated, if that's still is the case, i highly recommend you grab the latest <dariqq>daviid: Everything is fine now. Problems arise when the %libglib & friends used by g-golf are different than the glib I link my c program with (which is a guix specific issue to which I found a workaround for) <daviid>dariqq: ok great - can you confirm you are using the latest g-golf version? guix packages report 0.8.0-a1, you really want to use 0.8.0-rc9 <dariqq>daviid: Yes, in my desperation i upgraded the package locally so I am using 0.8.0-rc9 now <Ironsmith>hi mwette / dthompson / lechner thanks for your response, yeah i added a loop in my code to remove the keyword parameters, i guess it would be cool especially if this was used in other places to be able to extract just the positional parameters, maybe some helper procedure <Ironsmith>yeah i considered using #:optional but i explicitly only want to use #:key for one parameters and #:rest <Ironsmith>i ended up doing this: `(define* (modify-json #:key (file "package.json") #:rest all-arguments) (let ((modifications (let loop ((arguments all-arguments) (modifications (list))) (cond ((null? arguments) (reverse modifications)) ((keyword? (car arguments)) (loop (cddr arguments) modifications)) (else (loop (cdr arguments) (cons (car arguments) <Ironsmith>modifications))))))) #! now modifications doesn't have #:file !# )` <Ironsmith>using reverse because when i construct `modifications` i use `(cons (car arguments) modifications)` since this is O(1), and then reverse is O(n) making it O(n) overall, instead of appending to the end which would cause O(n^2) overall <mwette>Ironsmith: just what I was thinking; you can avoid the reverse using (let loop ((args all-args)) (cond ((null? args) '()) ((keyword? (car args)) (loop (cddr args))) (else (cons (car args) (loop (cdr args))))))