IRC channel logs
2026-05-12.log
back to list of logs
<rlb>jcowan: r7rs says that it's an error for its string-map fn to return anything other than a char, I'm wondering if that means we shouldn't directly share our srfi-152 compliant string-map as (scheme base) string-map, i.e. should base have a wrapper to reject strings? <JohnCowan>rlb: remember that "it is an error" in R7RS just means the behavior is undefined by the standard, so it's fine to allow 152 compatibility <rlb>OK, and thanks again --- clearly I need to stop reading it so pessimistically. <rlb>jcowan: fwiw I was looking at srfi-130 a bit, and while I'm not considering it for guile atm, I'm contemplating whether or not it might be useful to add a least a bit of it with utf8, say string-cursor-{start,end,next,prev} and string-ref/cursor, or something. <rlb>Basically, I realized I might need something hackish like that at least, and then I noticed srfi-130 was already a superset... <rlb>Is srfi-130 "recommended"? I could also see about supporting the rest of it at some point... <JohnCowan>rlb: Chibi, which has always used UTF-8 as its internal format, provides a subset of 130 as part if the primitive (chibi) library, so that might be a reasonable thing to adopt <JohnCowan>it pre-dates the internal every-nth-char index, which Chibi was the first to adopt IIRC <ArneBab>sneek: later tell dthompson: since rnrs isn’t optimized like core stuff, but it’s often similar, would "optimize rnrs where it needs the same approach as core stuff" be a good starting task for people who want to improve Guile? <ArneBab>sneek: later tell dthompson: that could also benefit Scheme as a whole, because it would nudge people towards writing more portable code. With experience many will converge on using the fastest patterns. <lilyp>hi folks, is there a way of getting a non-GOOPS, non-SMOB invocable record? <tohoyn>daviid: Where is the procedure cairo-pointer->context needed? I tried to run G-Golf examples with guile-cairo and guile-cairo-dev version 1.11.2-5 and I got no errors. <lloda><applicable-struct-with-setter-vtable> isn't documented but the other stuff is <lloda>the first field is the applicator the others are up to you <lilyp>hmm… in my case, a regular <applicable-struct-vtable> would probably suffice, provided I can stuff a case-lambda in there <rlb>With current guile (main) should there be any significant preference for logior/logand/etc. vs +, -, etc. when you're concerned about performance (e.g. if say decoding utf-8 bytes on the scheme side), or should they perform/optimize about the same? <rlb>...wonder how difficult it might be to have even a naive optimization of multiple vector/array/etc. index checks, e.g. you only need one (> len 2) check for this, not three specific checks: https://paste.debian.net/hidden/c90073cb <rlb>Oh, I'm not sure I compiled that with optimization... <sham1>With fibers, how could I have an operation that would represent a computation in a non-fiber thread? I'm trying to do things like TLS and parsing network input in a thread pool to avoid congestion on the fiber thread <TheTaoOfSu>Anyone familiar with NixOS? I'm trying to get guile-ncurses working for a small project, and I'm having a rough time getting it where guile can find libguile-ncurses.so. I tried adding it to my system config, and I've tried several ways to include it in a shell.nix, but I'm clearly missing something, and I'm starting to wonder if there's something else I'm missing <sham1>Do you have the load paths and such set up properly? <TheTaoOfSu>No. I thought NixOS was supposed to set those sorts of things up if I got the shell.nix right, but I also don't have much experience writing the shell.nix <rlb>I *think* a quick way to check that might be to try "GUILE_EXTENSIONS_PATH=parent-of-the-so guile ..." <rlb>if you know where the .so is <TheTaoOfSu>I echo'd the variable and found it's including the path to the .scm files, but it doesn't include the directory with the .so files. That's the right variable for them? <TheTaoOfSu>Yeah, okay, if I set GUILE...=/extra/path:$GUILE..., it actually works, so the issue is that the environment variable isn't set properly. Interesting, thanks for the pointer <daviid>tohoyn - it's use in the (demos nuclear-icon), used by the simple-pantable and animated-paintable examples, which I rewrote to use Gdk, but kept the previous cairo based version, which you can run passing either -c or --cairo as the example script cmd line option <ArneBab>sham1: I guess you’ll need a channel and the fiber waits on that channel until the non-fiber thread writes into it. <sham1>Hm. Channels would sound like a way to do it, I just can't tell if they can actually be used from outside of a fiber <resica>I've heard guile's conservative "stop the world" garbage collection makes it difficult to really optimize for high speed games compared to lua or C#. How true is that in reality? I've never gone this level of depth of memory usage. <sneek>resica, ArneBab says: windows support of Guile is being fixed at the moment. There are still problems with the JIT compilation that the Lilypond folks solved (they embed Guile for high-performance text work) but that still need to be merged back into Guile itself. <rlb>I don't have a really general answer to that specific question, offhand, though. <old>Say we add something akin to common lisp declare <old>something like: (declare (type fixnum? x)) <old>what if X is not a fixnum at runtime <old>should the compiler trust the user here and just assume X is a fixnum without doing any check <old>Or should the compiler insert a check for you can optimize in consequence <rlb>It's been a long time, did declare have some way to indicate what you wanted along those lines, i.e. safety too? <rlb>i.e. in an ideal world I could imagine even wanting a way to say "no *really* trust me", even if that causes very bad things to happen if I'm wrong. <rlb>But I suspect you might not want that very often. <rlb>(And of course in an ideal world you would never need it...) <rlb>"sufficiently smart oracle" :) <old>not a common lisp expert here <old>to me declare is pretty much: Trust me bro <rlb>iirc it's pretty fancy <old>I think having something like: (declare (noinline foo) (type number? x)) would be a good start <old>and for type check, I would emit them. I think that the compiler could remove redundant check with facts propagation <rlb>I don't know where they define those safety levels... <rlb>Do you happen to know how hard it might be to teach the compiler about multiple "nearby" vector/arrray/etc. refs? <rlb>i.e. that example where you're grabbing n adjacent bytes from the same bytevector <rlb>(only need one check against the max length) <rlb>...if it's common enough to care --- in that case with utf-8 it'd "only' matter for non-ascii. <resica>Thinking about it, it be less fighting the machine if I moved everything hard number crunching that might activate the garbage collector in high stakes games, to C. Keep the rest in scheme. <sham1>That is often the thing you might want to do, but then you also need to keep in mind the cost of crossing the boundary between C and Scheme