IRC channel logs
2023-06-24.log
back to list of logs
<rlb>wingo: hmm, is it maybe not safe to call dynwind functions "too early"? I'd put some in string= to guard some allocations (that'll eventually go away after the full utf-8 transition), and that caused a crash in scm_init_struct. So I tried moving prehistory and dynwind init earlier than that, but it still crashed (though dynwind was at least initialized at that point). <rlb>...I'll see if I can rework some interim things to avoid having to worry about it. <rlb>Don't know if it's OK, but if I move scm_init_struct() after scm_init_eq(), no more crash, and the tests all pass, even with dynwind use in srfi-13 string=. <RhodiumToad>don't kill 0 anywhere except in a process group you created yourself <cow_2001>even in this tiny program there are a thousand things one has to get right ~_~ <cow_2001>it's like origami folding. twist that fold a lil' bit and everything's wonky <mwette>rlb: in your new code, is there a discernible difference between ascii and utf-8 strings, like `(ascii-string? "foo")' ? <rlb>sneek: later tell mwette currently not in the public C apo, or on the scheme side (regarding some ascii? predicate), but on the C side you can find out pretty cheaply by comparing the char len to the byte len of the relevant region, since getting the offsets is fairly fast via the sparse index. <rlb>(and for stringbufs, detecting it if it's *all* ascii is currently "free" -- indicated via a type bit) <rlb>...to refresh, strings are just (char indexed-only) pointers into stringbufs, so strings themselves don't know anything about the byte locations. <rlb>wingo: it looks like the string-ref primcall converter moved away from the lower level wide/narrow distinction, i.e. maybe I don't need to disable it during the transition anymore? <rlb>(and if so, thanks :) )