IRC channel logs
2026-09-03.log
back to list of logs
<old>graywolf: good question wrt to exception .. I don't know hmm <old>will investigate but I think it would be a good addition if not present <old>is there something like this in common lisp? <old>AFAIK, select only filter the binding that are puts in the current module from the module used <old>it should not, not work <rlb>I felt sure I'd selected re-exports before. Might poke around later. Maybe I'm imagining things. <JohnCowan>ieure: Without wildcard imports you have to begin with (import-from (base) car cdr cons pair? +- <old>graywolf: there is the new `with-modules` syntax also that you can use to scope <graywolf>I think taking whatever is in (guile) and scope just my import is fine compromise. ; I will check out with-modules, though I hope Guix will finally catch up, default guile is still 3.0.9 :/ <graywolf>Actually, maybe a sane middle ground is to use wildcard import from "standard libraries" and #:select for anything else. So e.g. (srfi srfi-1), but ((web client) #:select (http-request)); All libraries in (srfi ...) and (rnrs ...) namespaces should be final and not be getting additional public binding with new Guile versions, so risk is low, but modules without final spec (e.g., (web ...), (json), <graywolf>(guix ...), (gnu ...)) it is safer to be selective about what is imported. <haugh>Can anyone recommend a relatively pitfall-free path to array visualization for someone with basically no graphics experience? My only real domain constraint is good compatibility with distributed systems, i.e. 10-100 independent data sources across 1-10 LANs <haugh>specifically I'm representing slices of arrays as matrices of service categories populated by arbitrary numbers of objects <ArneBab>graywolf: what I’d love to have is an autofix: during active development use wildcard import, and then run a tool that slims down the imports to only what I really use. Basically walking over all imported module exports and checking whether the symbols are either (re-) exported or used in the current file. <ArneBab>I usually use (import (only (…) …) …) because I want to be able to see in the file I’m working on where a given symbol comes from. <graywolf>I agree such tool would be nice to have. <dthompson>it would be nice to introduce a define-module v2 syntax that combines the good parts of the library, define-library, and define-module syntax <dthompson>define-module is kinda bonkers compared to define-library and library. the latter two are better for explicitly importing only what you need. <dthompson>and define-module doesn't support conditional imports, which I use a lot now that I'm writing code that runs on both the guile vm and on the web <dthompson>the one thing define-module does better, syntactically, is not having all top-level definitions be nested within the library definition <dthompson>implicitly importing (guile) is one of the bigger mistakes of define-module imo <graywolf>I admit I am somewhat glad I get list?, cons, ... out of the box <dthompson>(scheme base) and (rnrs base) by contrast are much more reasonable <JohnCowan>When I was writing a lot of Scheme code for SRFIs and so portability was foremost in my mind, I would normally import (scheme|srfi|rnrs *) libs with wildcards, and import from implementation-specific libs (controlled where possible by cond-expand) very selectively. <old>ArneBab: this is easily done <old>I could try to hack something just as a POC <graywolf>How can I set custom printer for an applicable structure? I am trying to mimic how <parameter> and make-parameter are done, but parameter uses the default printer. <old>hmm what is difficult is the syntaxes. would be nice to have a source-code -> tree-il without any expansion <old>currently, it is psyntax that when doing expansion will emit tree-il <old>wonder how hard it would be to just emit tree-il from the source directly <old>hm we have tree-il->scheme but no scheme->tree-il <dthompson>iirc tree-il only makes sense once all macros have been burned off <old>if you only want to have a tree of lexical values and global reference <old>then I think it would work. then you can pass the tree into modulify and resolve to get module reference <ArneBab>old: a POC for that would be pretty neat. <rlb>Who doesn't love a good race condition? <old>took my 3 days to fix this <old>happy to say now primitive-fork won't fall under you <old>I have been stress testing it for one hour now without problem <old>will confirm in 23 hours ;) <rlb>Nice, though sorry it took so long. <old>no worries, this was stimulating! <old>and I got a good grasp understanding of how these workers thread work