IRC channel logs
2026-05-20.log
back to list of logs
<JohnCowan>ieure: that makes it ironic that emacs is billed as a modeless editor as against vi(m), whereas vim has only 6 modes and emacs has hundreds <daviid>mwette: do you have a project that uses nyacc, the ffi-helper, that is autotool chained an that generates the *.scm files (from the *.ffi files) at build time, so I could look at and snarf the setting? <old>janneke: you have found a compiler bug btw <old>as far as I can tell <old>It looks like the compiler is hoisting the string-length primcall in the LICM phase <old>but this hoisting seems to not carry the type check as well <old>then string-length is lowered to a word-immediate loading. Without the type check, this basically load garbage which by chance here is triggering a segfault <mwette>lechner uses nyacc for several project, I believe, but I'm not sure he's using autotools <apteryx>JohnCowan: maybe modeless in terms of "modal", e.g. you have this edit vs view modes in Vi at all times, while there's no such clear distinction globally in Emacs (but could be depending on which modes you use). <daviid>mwette: ah ok, i'll look at it, tx <janneke>old: ouch, well done -- now for a fix ;) <probie>Has anyone tried to write a shell in Guile? <probie>Thanks. gash is the sort of thing I was looking for. <off-topic>I dislike Google, but DuckDuckGo can be pretty useless at times; it did find gash, it was just on the third page of results so I'd already given up</off-topic> <wehlutyk86>dthompson, (or others!), I'm reading guile-bstruct and trying to grasp the difference between pack/unpack and wrap/unwrap <wehlutyk86>are pack!/unpack for a kind of compression, leaving all unused u8's aside? <probie>Silly question; what does `(activate-readline)` actually do? If I `,L sh` (where the language is `sh` is defined by gash) in the repl after calling it, any attempt to run a command fails with Throw to key `match-error' with args `("match" "no matching pattern" #<input: string 7f38825860e0>)' <wehlutyk86>dthompson, or since they're both used in `bstruct-alloc`, is it used for creation of a bstruct when taking an array of bstructs? <wehlutyk86>which would explain why `packed` is in the `(define-bstruct <enemy> ...)` example, as the enemy can't be decoded? <dthompson>wehlutyk: pack/unpack and wrap/unwrap are orthogonal. <dthompson>packing affects the layout of the bytes. packed structs do not conform to C struct alignment rules. <dthompson>bstructs can operate on binary data that is wrapped in a record type or on raw bytevectors <dthompson>wrapped values are nice when type checks are valuable and you want to give the illusion of a regular scheme data type <dthompson>operating on unwrapped data is useful when maximum throughput is required as there is less overhead <ArneBab>mwette: there is currently only a small info about wisp as SRFI-119 in the Guile manual. I’d gladly contribute anything I’ve already written -- I didn’t want to overload the manual, but all I wrote about wisp can be included if that’s what’s the right thing for Guile (I have copyright assignment on paper). <mwette>I was thinking maybe an additional writeup, but didn't know about SRFI-119. I'll check that. Thanks. <ArneBab>we just need to decide together what should be in the manual, then the doing is easy. <mwette>Maybe there should be a SRFI-119 section in the manual with just a url reference. <mwette>Also, if working the manual maybe the section "Transducers" should be "SRFI-171 - Transducers". <identity>mwette: that is what is already in the manual for SRFI 119, no? <identity>also, «In files using Wisp, *Note SRFI-105 (Curly Infix) is always activated.» should be «[…], Curly Infix (see SRFI-105) is always activated[/active].» <mwette>maybe I'm looking at an old manual -- I will check -- thanks <mwette>identity, ArneBab: I was looking at an old version of the manual. Thanks. <mwette>line 6601 of srfi-modules.texi has `@subsection Transducers'; guess that should be `@subsection SRFI-171 - Transducers' <ArneBab>(at least that’s how I see it in other SRFI subsections) <ArneBab>⇒ there are more srfi subsection titles to fix <ArneBab>mwette: I sent you a suggestion for the menu for 207 as /msg <identity>if we are fixing SRFI subscetions, might we change from SRFI-### to SRFI ###? <mwette>I use the PDF version a lot and in the TOC 171 is inconsistent. <ArneBab>identity: then we’d have to change all SRFIs and take care not to break any links, so we couldn’t do it fully automatically, so I’d rather not. <ArneBab>also in (use-modules), it’s (srfi srfi-###) <yarl>I wonder why (cons 1 (cons (cons 2 3) 4)) at the repl gives '(1 2 . 3 . 4) but one cannot enter '(1 2 . 3 . 4) at the repl? <identity>that gives (1 (2 . 3) . 4), not (1 2 . 3 . 4) <identity>well, i just tried that too, and it gives (1 (2 . 3) . 4) and not (1 2 . 3 . 4) <rlb>I also see the latter. <rlb>scheme@(guile-user)> (cons 1 (cons (cons 2 3) 4)) <rlb>$1 = (1 (2 . 3) . 4) <yarl>with guile -q I get what you get <yarl>parentheses are gone, colors are too close for me and I didn't know or remember colorized does this <yarl>thank you anyway, shame on me <rlb>No worries; glad it's fixed. <yarl>Do you see any color difference between 1 and (2 and 3)? <yarl>I wonder if its just a bug in colorized. <yarl>It's not mentionned in the documentation <yarl>And it's in the guix %default-dotguile <rlb>I don't think guile colorizes anything in the repl by default, and I see only my terminal's foreground text color. <yarl>I meant the package guile-colorized <yarl>this provides (ice-9 colorized) <yarl>you activate it using (activate-colorized) <rlb>Ahh, didn't know about it. <yarl>It's used by default by guix through the %default-dotguile <mwette>I guess . is right-associative but the reader is not looking for that. <mwette>Are there RnRS rules for the reader wrt this? <mwette>R5RS, at least, seems to indicate only one `.' is allowed prior to last element of a literal list.