IRC channel logs
2023-06-10.log
back to list of logs
<civodul>rekado: there are discussions on integrating Wisp in Guile <sneek>civodul, you have 2 messages! <sneek>civodul, spk121 says: in your gc-benchmarks commit, gc-benchmarks/local.mk should "EXTRA_DIST +=" not "EXTRA_DIST =" <sneek>civodul, attila_lendvai says: respawn-service in shepherd doesn't seem to check whether the service is disabled or not. i got into a state where my service was stopped according to `herd status`, i also issued a `herd disable`, but the process is still running, and whenever i terminate it with a kill -TERM, shepherd keeps respawning it. <civodul>rekado: since GWL is an important user, you might want to chime in! <dsmith>daviid, News Debian release. Soon I'll be able to take a look at the g-golf stuff <Kolev>Are there any apps written with G-Golf? Can they be easily Flatpak'd? <rlb>It'd be handy atm to have a C bulk bytevector copy, i.e. in lieu of scm_c_bytevector_set_x, avoiding the redundant type-checking etc. on every byte. Any chance I just overlooked it? <rlb>I'd like to be able to effectively "memcpy" a uint8_t* (with proper checks). <old>rlb: you can actually use memcpy in Guile <old>there's an example with the FFI interface <rlb>wingo: in this case I'm working at the C level, i.e. I have a uint8_t * (within a stringbuf), and I want to copy it into a region of a bytevector (e.g. assembler.scm :) ). <wingo>don't work at the c level ;-) <rlb>BYTEVECTOR_CONTENTS will be fine there -- I'd forgotten that bytevectors were simpler. <rlb>I'd normally favor the scm side more, but figured that string handling might be a case where it's worth the hassle, since they're so central. At least that's how I've been handling things so far. <rlb>But there are plenty of debatable cases, so be happy to rework during review, assuming we get there. <wingo>yeah. "as much as needed but not more" should be the thing... <wingo>certainly anything that needs per-codepoint callouts like string-any etc should be in scheme <rlb>Agreed, and I'm not at all sure where that line is an a bunch of cases :) <wingo>so generally speaking bytevector-slice from (rnrs bytevectors gnu) is going to be useful here <wingo>i.e. many operations can be coded as "get the bytevector corresponding to the string and interpret its utf-8 in scheme" <rlb>Hmm, wrt string-any, etc. then depending on what you mean I may have drawn the line poorly. i.e. I tried to keep some of the more commonly used bulk operations in C so that we could avoid per-item (type) checks, etc. <rlb>But can always re-work once it's actually working. Ended up on a notable side track until I figured out what was going on with assembler (i.e. that that's what I'd missed), and now fixing it up... <rlb>If we get to the point (are we there now?) where the scheme compiler's smart enough to elide redundant type checks, then that'd make my choices even worse :) <rlb>Also, so far, more or less the only thing I've exposed outside of strings.c (on the C side) is access to a utf8 uint8_t* and a bulk (currently C variadic, but I'm reconsidering that as possibly a bad idea) uint_t* offset retriever). i.e. you can give it the utf8 bytes and ask for utf8_t pointers to char offsets x, y, z, in one call. <rlb>Anyway, planning to finish getting everything in strings.c converted, and then I'll likely have questions about things that might need reworking. <rlb>(...everything outside strings.c is converted, though in some cases will still need rewriting, i.e. to avoid use of string_set_x, etc.) <wingo>the scheme compiler can certainly elide redundant type checks. <rlb>hmm, I didn't realize that (clearly). <rlb>wingo: another thing that I've wondered is (maybe even relevant to doing more on the scm side) if we might want to expose stringbufs more, since they're the "safe" bit, i.e. they're always utf-8 (currently mutable only if ascii), and can't "change length" suddenly like strings can wrt utf-8 offsets and concurrent string-set!... <wingo>well, one of the attractive things to me about utf-8 strings is that it will allow more schemeliness <wingo>but, we don't have to start with that <rlb>Or something something, note that the semantics have changed there... <wingo>rlb: what is the difference between stringbufs and bytevectors? <wingo>it's known that they are utf-8, that's something i guess. and the breadcrumbs at the tail of the buffer if i understand what you are doing <wingo>mutability, we have that in bytevectors. we don't have the "shared" flag tho <rlb>mutability wrt changing length for utf-8 when you change a char. <wingo>ACTION will read answers after an unconscious period :) <rlb>i.e. we atomically swap the buf pointer in the string. <rlb>I was just thinking about that... So right now a stringbuf is one contiguous block, and for ascii it's the type cell, the length cell (which is both byte and char count), and then the inline bytes. For non-ascii, it's the type cell, the char-length cell the byte-length cell, the inline bytes, then the variable-grain offset index. <rlb>(thinking about that wrt bytevectors) <rlb>And I've clearly been assuming it'd be worth the complexity to have everything inline in one C blob wrt cache locality, etc. <rlb>The incredible spew I saw, even during compilation, when I added some debugging printfs into the string constructors did not disabuse me of that notion :) <rlb>wingo: also been trying to balance even more radical overhaul vs reviewability (with undetermined success). Assumed that there'd be more reworking/removal/etc. later.