IRC channel logs
2024-06-24.log
back to list of logs
<mwette>congrat's on that; looks like a big delta <apteryx>rlb: OK! That's fine. Perhaps you could mark it as reviewed in Debbugs (no builtin support for that I reckon, in Guix we adoped the Linux/git 'Reviewed-by:' git trailer which can be added in a review reply in the email body. <apteryx>tools such as 'b4 am' then know to pull these trailers in the commit messages <apteryx>rlb: if you are keen on reviewing another simple syntax fix in the same file (r7rs-libraries.scm), #67255 has a v2 patch fixing the reported issue <apteryx>(define-library does not support 'rename' directives) <apteryx>what happens if I use a variable having a symbol as value in a match pattern? <apteryx>seems to not work as I would expect: (match value ('%unset-marker% "unset") ((? string?) "a string")) -> "a string" <apteryx>but, (define %unset-value '%unset-marker%) (match "/tmp/file.log" (%unset-value "unset") ((? string?) "a string")) -> "unset" <mange>I don't think match looks at global/lexical names in its expansion. Thus your second example is "unset" because it matches "/tmp/file.log" by binding it to the %unset-value name. I'm not aware of a way to get match to care about existing bindings other than using a predicate match with something like (lambda (x) (eq? x %unset-value)). <wingo>thanks to all who have been maintaining guile over these last couple years :) <wingo>lmk if i messed anything up, we can cut another any time <wingo>manual updated too. i think this one is done <ArneBab>wingo: thank you also for the website! That’s an often underestimated task! <civodul>00-repl-server.test: repl-server: HTTP inter-protocol attack - arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32))) <wingo>ld: cc1plus: final close failed: No space left on device <wingo>right the guile-procedures.txt thing should be fixed <wingo>1120efe3759908c84817f45d317d8704769371d3 <trev>wingo: thanks for the tips yesterday. i was able to get my macro to generate all the setters for a json record type <trev>ran into another issue where i want to generate a proc for a record type that maps all the fields to keywords, i.e (define-record-type <foo> ... (bar) (baz) => (foo #:key (bar) (baz)), but i can't seem to figure out how to go from the list of fields as keywords (my mapping symbol->keyword over record-type-fields) to pasting the contents of that list into #:key [keys go here] <trev>nevermind, the answer is to use ,@keys to take the elements of a list <civodul>wingo: it’s really 00-repl-server.test though, AFAICS <wingo>there were a few bugs, one was that check-guile would race to create guile-procedures.test <wingo>which would happen for the first tests run, of which 00-repl-server is one of them <wingo>dunno, point me at a failure for current git if i am wrong :) <rlb>wingo: wrt gnulib choices, another potential concern is the effect on distributions. i.e. increasing the size of the source archive by 100+ MB would be "a lot" if that were to happen. It would, by default, for debian (except that I suspect the ftpmasters might well reject it) because I currently (and would like to continue to) ignore the archives and package directly from a shared git repo. <rlb>It sounded like one option (in wingo's recent post to the list) was to include all of gnulib in the source tree, but not the archive. <Arsen>oh, I didn't see the list post (but we discussed it here) <rlb>Packaging directly from git makes it easier to just cherry-pick, merge, etc. <rlb>The list post is more extensive. <rlb>But might or might not be something we'd want to sway us too much upstream. <rlb>Oh, and to clarify, debian (still) requires upload of an orig.tar.* and so I (or dgit for emacs) build one via "git archive ..." from the debian "upstream" branch after merging the new release. <cpli>are you expected to write every field of a c-array to a bytevector manually? <Arsen>rlb: is the orig not the dist tarball? <Arsen>that was always my impression <graywolf>Is it possible to suppress the `;;; Failed to autoload with-store in (guix store):' messages from the compiler? I want to have a "soft dependency" and thought I could use the #:autoload for it, but it spams the build log a bit too much for my taste... <rlb>Arsen: not necessarily. It's up to the package maintainer, and for guile and emacs I've ignored the dist tarballs for a long time. I prefer it for a number of reasons, including ease of reviewing release diffs (esp wrt ground truth), cherry-picking, using git to help rebase debian patches for a new release, etc. And it's even more important if debian can't use the upstream dist directly anyway (e.g. used to be guile, and still is <rlb>emacs) for various reasons (e.g. a main/contrib or main/non-free split, etc.). <rlb>In that case, I'd much prefer to let git merge help handle the split across releases. <rlb>Of course, there *are* tradeoffs. <rlb>(And if you use dgit -- I don't entirely yet, haven't decided about the workflow vs my current one, and it's not yet able to handle split packages cleanly -- you can upload a new package by just pushing a signed tag, rather than building and uploading release artifact files, some of which are now discarded (the .debs).) <rlb>(Though it still does have to eventually upload an orig.tar.gz too.) <dthompson>someone tripped over an ethernet cable at the fsf data center and the server went offline <graywolf>ACTION has no idea if that is a joke or post-mortem... <dthompson>unfortunately the connector stayed lodged in the ethernet port and they needed needle nose pliers to get it out and have to crimp a new cable <dthompson>and to make matters worse rms showed up at the same time and said that he did a dist-upgrade on trisquel and now it doesn't boot so who knows when gnu.org is gonna be back online <cpli>alright, i've heard of rms both in #scheme and now here. dthompson, is there some saucy blog-post i can read on the drama, how do i not know about this at all?? <cpli>you're.. lmao ok stallman's still around?? <dthompson>idk the status of rms. he's not my AIM buddy list. <cpli>neither is it on mine, but people asked why there isn't some extern "GUILE" { /* ... */ } implemented for gcc, and people asked whether or not they were advocating for rms to have reasons to hinder guile development <dthompson>I don't really follow but guile should be sprinting away from C not adding further integration <dthompson>hehe I agree in general that guile benefits from not attracting the attention of rms <cpli>oh! the puzzle pieces slowly fade into place, gosh <cpli>dthompson: re "sprint away from c": any far off musings anywhere on self-hosting; or is there a line? <dthompson>well, the pre-scheme project provides a hope that we can move away from C in the future <cpli>oh and there's an old wingo blog-post <dthompson>but also I'm of the opinion that no one should use guile's C api for new code. <cpli>why *is* the channel for prescheme called #guile-scheme <cpli>but it's prescheme, did the announcement go into that? <dthompson>guile steel -> Guy L. Steele -> steel = bare metal -> scheme for low-level systems programming <cpli>there's that one talk where guy defines every word before he uses it, i have to think of that every time they're mentioned <cpli>dthompson: i'm mostly using guile right now for wrangling glfw and webgpu implementations <cwebber>I don't think rms ever had much involvement in Guile other than declaring it the extension langauge of GNU <dthompson>neat. I'm (sort of) writing a webgpu implementation in guile <dthompson>or at least an api that maps cleanly to webgpu for browser deployment via hoot. <cwebber>dthompson: oh is this a library on top of Hoot I assume? I'm curious <dthompson>chickadee's new graphics api (wip, no timeline, don't @ me) <cpli>cwebber citing faultlore <cpli>those replacements leave: " Aria is great" <cpli>(yes, the whitespace prefix is untentionally intended..) <haugh>congratulations on the release! <haugh>the old soft port interface hurt my brain