IRC channel logs
2025-05-22.log
back to list of logs
<mwette>wingo: I think we need to have bytevectors with pointers: e.g., for allocateing C-based structs to pass to FFI'd C functions. Should a call to make-bytevector/pointers (<= I hope to have) take an argument that somehow indicates where the pointers are? <dthompson>rlb: sneek delivered your message in a different channel re: persistent hashes. yes, I read through fash.scm while implementing our own. <dthompson>since we were including something directly in goblins we wanted something that we understood well so we wrote our own thing. <rlb>Ahh, ok (did I direct sneek wrong?) - if y'all already have deletes, then any idea offhand whether yours might be a reasonable replacement for lokke? <dthompson>I sent a message in #spritely before #guile, and sneek is in #spritely, so it sent me your message there <rlb>I was thinking of trying to add deletes to fash, but assuming I'd be able to (with reasonable effort), I haven't gotten to it yet. <wingo>sneek replies to the first channel you write to <rlb>I forgot sneek worked that way (if I knew). <rlb>For now lokke does something "questionable" (just assocs a "nothing to see here" value for deletes -- much less than ideal). <dthompson>but we lack some other things that fash.scm has, most notably transients <rlb>I guess I'd need to check the license too :) <rlb>Ahh, ok -- transients may be desirable for lokke. In any case, thanks. <dthompson>I didn't want to bite off too much, so I kept things simpler <dthompson>we don't currently have a situation where not having transients is hurting us <rlb>completely understood -- and if I'd known about wingo's matching vectors, I might not ought to have written the clj-style C-based vectors I did... <rlb>(Was educational, but might have been unnecessary.) <dthompson>ah yes, those are nice too. we would like to have a persistent vector type in goblins, as well. but hashes were the big one so we started there. <rlb>(I just need to bribe wingo to add a delete somehow :) -- I'm still wondering if I should (and have the time to) put fash/fector on codeberg or wherever with the bug fixes.) <rlb>yeah, that was one of the stumbling blocks :) <dthompson>I did a little microbenchmark comparison between what is now in goblins and fash.scm and they were similar. <rlb>I knew you wanted that, and agree. <dthompson>getting something into guile itself would be best, of course <rlb>wingo: if we're going to have a backward incompatible release (and not asking for bandwidth right now), I'd really love to include a plan for "binary system data" in that if there's a chance we can come up with and agree upon a plan, i.e. paths, env vars, etc. that aren't "strings". <rlb>Right now we just quietly corrupt the data. <rlb>for cmdline args, etc. <rlb>And I *do* have srfi-207 for us now if we want it. <rlb>Still notable questions, though. <rlb>And unless something changes for me, I *am* likely volunteering to work on "the plan" if/when there is one. <rlb>I also think it'd be plausible to proceed in stages, maybe first make it at least *possible* to dtrt (and enable writing real system utilities in guile without ffi/c), even if it's more awkward than it'll eventually be. <lechner>Hi, is there a general strategy to debug "unknown location: unexpected syntax in form ()"?