*dsmith is curious how much build times would improve <lafrenierejm>How would one go about getting the value of specific keyword from a list of keyword:value mappings? <lafrenierejm>(Not sure about scheme's terminology. LMK if the question isn't clear.) <mwette>not clear: Guile has make-hash-table, hash-set!, and hash-ref to create hash tables, add items to tables, and retrieve values. Is that enough? <mwette>There are various forms of hash depending on what it takes to match a key. <justin_smith>also, alists are considered keyword:value mappings and use assoc / assq etc. <dsmith-work>However, you can (read) and (write) an alist. Not so a hash. <lafrenierejm>Thanks for the replies. I'm wondering if I have some fundamental misunderstanding... <justin_smith>lafrenierejm: it really matters what the data type is - eg. hash-ref or variant for a real hash-table, assoc for an alist (which is a common alternative in scheme code) <justin_smith>also, it looks like define-package and package are macros which means their documentation would help you <justin_smith>(and makes it hard to say what you need without knowing those macros) <justin_smith>lafrenierejm: the doc says that "arguments" of a given package will be a list, by convention key/value pairs, so it's not even a lookup structure yet <justin_smith>oh wait, I'm wrong - it takes a list as an arg, but that doc doesn't describe how to look things up in it, so who knows what's in there <lafrenierejm>justin_smith: Thanks for taking a look. I'll poke at it some and see if anything gives. <justin_smith>I'm surprised I'm not seeing documentation about accessing the objects created by package definition, maybe I'm just not searching the right thing <justin_smith>that said, you could try things like hash-ref and assoc and see what breaks :D <lafrenierejm>justin_smith: Looking through some implementation details in utils.scm, it appears that arguments really is just a flat list. :/ <daviid>lafrenierejm: fwiw, in (oop goops), (get-keyword key l #:optional default) <daviid>lafrenierejm: so you'd do (get-keyword #:configure-flags (package-arguments sqlite) #f) <daviid>if i understood your quiz correctly <daviid>lafrenierejm: the (guix utils) module also defines a few keywords related utils, strip-keyword-arguments default-keyword-arguments substitute-keyword-arguments ensure-keyword-arguments ***rekado_ is now known as rekado
<rekado>you can also look up things in a keyword list with (and=> (memq #:foo the-list) cadr) <RhodiumToad>(define mylist '(#:key #:otherkey #:otherkey 1)) (and=> (memq #:otherkey mylist) cadr) ;; expected 1, got #:otherkey <rekado>RhodiumToad: I’m assuming a well-formed keyword list that alternates keywords and values. <RhodiumToad>that's exactly what mine is. sometimes the value of a keyword is also a keyword. <rekado>I just saw the Guix context, so I reported what I sometimesdo in Guix. <rgherdt>Hi! I'm getting an error whenever I use a cond-expand inside a r7rs define-library. For example: <rgherdt>I get: Syntax error: unknown location: source expression failed to match any pattern in form ((cond-expand (chicken (import (chicken format))) (else (import srfi-1))) (export my-func) (begin (define (my-func x) (format #f "received ~a" x)))) <rgherdt>I'm importing (scheme base) before loading the definition file ***modula2 is now known as defaultxr
<justin_smith>rgherdt: my reading of the cond-expand doc is that if no case matches it's an error, and I don't see an else, and I'd assume chicken wouldn't match in guile <justin_smith>it's confusing, because the thing in the error message should work, but the literal thing in the paste shouldn't (if I'm reading the docs correctly) <mwette>rgherdt: you may need to close your library form first <rgherdt>RhodiumToad justin_smith: sorry, the error message was from an experiment with else to see if that was the issue <mwette>(library ...) (cond-expand ...) vs (library .. (cond-expand ...)) <rgherdt>mwette: hmm, but that wouldn't be part of the library then, right? <mwette>not sure about library forms, tbh, but that seems to be what is in the Guile manual <rgherdt>according to r7rs cond-expand is allowed inside a define-library (chicken loads this correctly) <mwette>Oh, OK. Then I think you need an else (cond-expand (chicken (xxx)) (else)) <rgherdt>this also didn't work. Actually define-library is not yet documented in Guile's Reference, since r7rs integration is pretty new. I also ran (install-r7rs!) but still get the error <lafrenierejm>Where can I read up on Guile's `and=>` and `memq`? The former in particular is completely new to me. <mwette>paren misplaced ; sqlite) => sqlite)) <lafrenierejm>mwette: Thanks for the sanity check. Moving the paren as suggested gives "ERROR: Wrong type to apply: #:configure-flags". (and=> (memq #:configure-flags ,(package-arguments sqlite)) cadr) <mwette>lafrenierejm: Maybe you want the comma before (and=> , and that may be wrong also. To me it looks like you want to create a list. Maybe work the code (i.e., `(#:phases ...)) in isolation within guile, using a known value for (package-arguments sqlite). <rekado>lafrenierejm: the Guixy thing to do here is to use substitute-keyword-arguments <rekado>(arguments (substitute-keyword-arguments (package-arguments sqlite) …)) <rekado>see the definition of bash-minimal in (gnu packages bash) <rekado>(without substitute-keyword-arguments) <heisenberg-25>Is (ice-9 readline) module removed/moved in guile 3.x? I can't seem to import it <heisenberg-25>ls /usr/local/share/guile/3.0/ice-9/ | grep readline - returns nothing <rgherdt>weird, I also installed from source, and I have /usr/local/share/guile/3.0/ice-9/readline.scm <tohoyn>heisenberg-25: try command "pkg-config --variable=sitedir guile-3.0" <tohoyn>tohoyn: I suspect guile does not like to be installed into /usr/local <rgherdt>tohoyn: here guile seems to be happy inside /usr/local, what issues did you get? <heisenberg-25>tohoyn: the command you sent outputs /usr/local/share/guile/site/3.0 <rgherdt>heisenberg-25: the archive you linked has guile-readline inside <rgherdt>heisenberg-25: I suppose something went wrong with your build <rgherdt>maybe you can try compiling guile-readline from that folder separatelly <tohoyn>heisenberg-25: does that directory contain readline? <rgherdt>heisenberg-25: is libreadline-dev installed in your system? <tohoyn>heisenberg-25: ok. it seems that it is in different directory. <rgherdt>maybe that's the issue, guile-readline depends on libreadline <rgherdt>the dependencies are listed in the README file <heisenberg-25>okay. re-running the build after libreadline installation. will report back in few moments <rgherdt>while running ./configure you should see, if readline was found <justin_smith>heisenberg-25: I'm no expert on guile atomic boxes, but in general, compare-and-swap! type operations are not useful if the data referenced is mutable <heisenberg-25>I see. I was using mutexes but I am switching my threading to use fibers and it doesn't work well with mutexes. The author suggests to use atomic boxes <dustyweb>doing some non-guix guile hacking today :) <justin_smith>heisenberg-25: there is a workaround, if eq? works on your hash, and you are willing to copy the hash, call compare-and-swap and only replace the box contents if its still eq to yoru copy of the original <justin_smith>(this is generally the idea of atomic exchange, not ice-9 atomic specific) <justin_smith>heisenberg-25: you might find it more useful to use a hash where each value is an atomic box, especially if you can guarantee each value is immutable, or comparable with eq? and cheap to copy <justin_smith>then instead of changing the hash, you'd change the box in the val of the hash <heisenberg-25>justin_smith: the hash values aren't comparable with eq? (I am actually using the hashx functions). <justin_smith>this makes the "compare" part of compare-and-swap! much harder to do correctly, but it could be that atomic-box-swap! still works on your vals if you are willing to make new ones instead of updating in place <justin_smith>it won't work on the hash-table itself, as that is always identical to itself, before and after mutation :D <heisenberg-25>that means copying the hash-table each time I update it, right? <justin_smith>right, which is why I mentioned boxing vals of the table, instead of the table itself <justin_smith>there's also vhash (not hashv as I mistakenly said above) which is an immutable hash table <justin_smith>they are more expensive than a standard hash, but I'd hope they are cheaper than copying a whole table over and over <justin_smith>heisenberg-25: aha! you are implementing thread-safe-memoize <justin_smith>so the worst case on a race condition, if you have a thread-safe hash, is that f is called twice on some x instead of once <heisenberg-25>justin_smith: Yes! (although the above code isn't written by me) <justin_smith>if your hash isn't thread-safe, worst case is totally destroying the structural validity of the hash as an object <justin_smith>so you could use atomic-box-swap!, and if you make a lock around the smallest scope (the hash update itself, not the entire calculation) or the hash is known to be thread safe, you are good <justin_smith>if all these things work as documented - I'm very familiar with the version of htese things offered by clojure, and the docs make it look like this is the same <heisenberg-25>"if you make a lock around the smallest scope (the hash update itself, not the entire calculation)" can you please elaborate this? this I am not using mutexes how can I use a lock here? <justin_smith>oh, this would require a mutex, but much simpler logic around the mutex than usual <justin_smith>but you dont' even need a mutex if you know the hash is thread-safe <justin_smith>(and usually that thread safety ends up relying on some very short lived mutex somewhere down the line toward the bare metal) <justin_smith>but the general principle is to keep them very short, and the swap pattern helps you make them extremely short lived <justin_smith>eg. doing nothing inside the mutex except a single change to a pointer <heisenberg-25>if I understand this what you said correctly, using a lock only around the scope I update the hash-table should work? <justin_smith>heisenberg-25: actually I was wrong - the swap functions don't really make sense if you can't compare and retry, and atomic-box-set! only makes sense when replacing one value with another (fundamentally *not* what is happening with a mutable value you are updating) <justin_smith>so you can use the swap functions with an immutable value like a vhash (where identity equality can tell you if anyone elsed touched it so you can retry or abort) or just use a lock around the hash usages and hope everyone else did too <zig>manumanumanu: I republished what I found related to the R7RS libraries I found around my backup laptop <zig>not sure what the status is, but there should be tests <zig>also it is a requirement for babelia (wanna search engine) <zig>this should include the generator things, and people are interested in delimited continuation over the rainbow <zig>zig: happy hacking ;) <cyclopsian>are there any plans to make it so calls to (read) are capable of nonblocking i/o? suspendable-ports doesn't work for this <cyclopsian>I saw an allusion to it in the fibers manual, but checking the implementation it still calls getc in a loop <cyclopsian>my use case is having the repl plug into another event loop <cyclopsian>I know about (system repl coop-server) and I think I can hack it to do what I want, but ideally would like to be able to do it without threads <wingo>would be nice! no immediate plans but a reader implemented in scheme would be swell <wingo>in the context of guile would be nice to have one source file that could compile to C and Scheme, because bootstrapping -- so it's complicated a bit <wingo>but 3rd party read modules could work <cyclopsian>ah okay, figures that porting it to scheme is the plan :) <cyclopsian>wingo: what do you mean have one source file that could compile to C and scheme? like implement it in VM bytecode? <wingo>oh i don't know, either a high level specification that a macro could expand to scheme and some other procedure to take that specification and produce C <wingo>or, a straight-up Scheme reader and a bespoke compiler from Scheme to C -- doesn't have to be general because it only has to work for this program <cyclopsian>I see what you mean. I wonder if that would mean still having calls to read use the C implementation for speed reasons and only falling back to the scheme implementation if there is an escape continuation on the stack