IRC channel logs
2023-11-05.log
back to list of logs
<RavenJoad>haugh: I think use let- prefix when you want a form to behave like a let. Otherwise, a with- prefix is better? <RavenJoad>I have no idea at all though. I'm just going off the code I have read and the tiny amount I have written. <haugh>word up, I appreciate your input <haugh>I shouldn't fixate on this stuff <RavenJoad>In my inexperienced opinion, use the one that READS better. I think (with-db "db" (query1) (query2) ...) reads better than (let-db "db" (query1) (query2) ...) in this case. <haugh>yeah currently I have (with-promise p expr . body) expanding to (let-promise ((p expr)) . body) <haugh>but then again there's with-syntax for example. I need a vacation <haugh>I don't know the history but if I had to guess I'd say this disctinction arouse in regards to bindings with side effects <apteryx>is it possible to define an srfi library as an r6rs 'library' ? <apteryx>maybe stage0 doesn't know about r6rs library syntax yet? <apteryx>rnrs library must be compiled by that same stage0... so maybe the prefix has to do with it <apteryx>(if under rnrs/ install r6rs library syntax or some similar hack[ <apteryx>hm, that works: BOOTSTRAP(stage0) GUILEC rnrs/base.go <haugh>does your library have a body? <haugh>I've never used this syntax but my understanding was that you need to put all the code for that library in the tail of that expression, unlike define-module <apteryx>haugh: ah, found it, the export form must appear before the import form <haugh>guix has a bunch of stuff like this too, where syntactic parameters are both named and ordered <haugh>paramters as in "arguments to a macro", not syntax-parameters <apteryx>it documents the form with exports appearing before imports <apteryx>are there people working on r7rs define-library? <apteryx>also, in r6rs' 'library', there can be only a single export and import forms <haugh>I have r7rs define-library available by default in (guile-user) on 3.0.5 <haugh>you can check it out in ice-9/r7rs-libraries.scm and it has a partitioning system you might adapt for the `library' syntax <haugh>frankly Guile has enough redundant systems for me without getting into this stuff so I'll just keep generating define-modules statements with my editor <apteryx>define-library is not documented in guile? <apteryx>I may want to revisit how I've adapted srfi-125, 128 and 126 earlier... could have been better perhaps to use define-library to match what upstream used <apteryx>usually that'd work with include-from-path, but define-library doesn't understand that form <apteryx>(include-from-path is guile-specific) <euouae>and I'm not speaking necessarily of just the language spec, I mean the entire toolchain <haugh>euouae, Guile is quite mature. _Multiple built-in XML parsers_ mature. Depending on what you're doing with it, your toolchain could look quite different from someone else's. For example I don't integrate with C so I completely ignore the entire autotools system. <haugh>euouae, if you're trying to understand how most people use Guile today, you should probably investigate Guix. <haugh>I was getting into it with no serious interest in learning Guile and then Guile's depth completely derailed all my plans. <haugh>I just wanted "less disgusting Nix" and now I write syntax-case every day <euouae>The scheme-primer mentions macros briefly but I'm looking into the guile manual now <euouae>haugh: I entered a lisp game jam and I wrote my game in fennel <euouae>some others wrote it in guile with guile hoot, using nightly browser features (wasm tc etc) <euouae>so I was kind of impressed by that sort of thing <haugh>yes the spritely kids are extremely cool around here <euouae>fennel is just lua in lisp form so it doesn't actually have heavy features <euouae>fennel (or lua) has a very cool game library called LOVE <euouae>I'm not sure if guile has something that easy to work with, but guile is definitely the better lisp <haugh>I only know it by name but maybe have a look at dthompson/chickadee. Dave is one of the spritely folks involved with hoot <apteryx>re 'include', the doc (info '(guile) Local Inclusion') says: "path relative to the current directory at compile-time" <apteryx>but earlier it says: "If FILE-NAME is a relative path, it is searched for relative to the path that contains the file that the ‘include’ form appears in." <apteryx>seems it'd be preferable if it actually resolved relatively to the file include is used from <apteryx>hm, Guile uses (dirname filename) according to call-with-include-port <apteryx>ah, my problem is due to %file-port-name-canonicalization which defaults to 'relative <apteryx>it strips the prefix from the source file being byte compiled <apteryx>'include' from r7rs 'define-library' is kinda useless with the current behavior of 'include' + the %file-port-name-canonicalization used, at least in a compilation context <wklew>I also had a lot of trouble getting inclide to behave, ended up having to use a lot of cond-expands and treating guile specially <wklew>for example, include-library-declarations on a file whoch itself calls include does not seem to be possible in guile <apteryx>I'm trying to understand if having a current-load-relative-directory fluid set to the original directory of the source in compile-file (then honored by include) would help. that seems to be what racket does <sneek>apteryx, you have 2 messages! <sneek>apteryx, podiki says: I didn't realize ungrafting libx11 means rebuilding python and thus basically everything. should I not ungraft on mesa-updates then? or just fold it all into core-updates instead? <sneek>apteryx, podiki says: that means nghttp2 and curl get rebuilt and should be ungrafted at the same time too. ...which I guess makes it core-updates then. what do you think? <apteryx>would be nice if sneek had per-channel memory <old>in theory, if multiple instances of sneeks run, one per-channel, that ought to do it? <old>The current problem I believe is that there is one sneek for multiple channels <lilyp>that would work, but it'd also require multiple IRC connections <lilyp>though perhaps you could wire something with a bouncer in-between <apteryx>seems it should be relatively simple (TM) to track per-channel? <apteryx>without having to run one instance per channel <apteryx>do we have something similar to Racket's split-path? <old>idk have not look at the code, but I assum that yes <apteryx>it's to know whether a path is relative or not <old>absolute-file-name? ought do that? <apteryx>I guess so; split-path seems overkill for the task at hand <apteryx>some idea I had while looking at fixing 'include' relative file names when using compile-file, which strips the file prefix found in %load-path <apteryx>perhaps we could canonicalize the syntax-dirname extracted from the syntax in the include macro? <apteryx>ah, no that's done by fport_canonicalize_filename and it's relative on purpose by default to avoid baking a wrong source file name in the .go <apteryx>that file name is expected to be found on the load path <sneek>I've been a process for 19 days <sneek>This system has been up 31 weeks, 22 hours, 58 minutes <elevenkb>Hello there, suppose I have a script which should use current-source-directory? <elevenkb>sorry I meant to say `current-source-directory'. <elevenkb>Ok, so how does one test such a script in the Guile REPL, given that (current-source-directory) evaluates to #f in the REPL? <elevenkb>Do I have to substitute a concrete literal value for it, or is there a better alternative?