IRC channel logs
2026-05-13.log
back to list of logs
<old>rlb: I think the compiler is supose to already hoist bound check and merge them if needed ? <old>do you have an example in mind <old>JohnCowan: pre-scheme is already available for Guile <old>tho we haven't heard from the person who's doing the port for more than a year now <ekaitz>ACTION hopes the guy is in a sabbatical <lechner>Hi, how may I ask Guile to expand the ellipses in error messages, please? <rlb>Rather "it appeared to keep three length checks". <apteryx>lechner: you could try setting COLUMNS to some larger value, e.g. 200 <rlb>I thought there was probably a setting wrt the truncation, but I can't recall/find it atm. <rlb>(and perhaps I'm conflating guile with something else) <old>rlb: yes for meta/guild <old>I was going to fix that one day <old>had to do GUILE=./meta/guile <old>you can merge it to main <rlb>I wonder if all the scm_init_{array_handle,dynwind,ioext,...} functions that we call during scm_i_init_guile really ought to be SCM_INTERNAL and scm_i_init_array_handle, etc... <rlb>jcowan: is it feasible to assume that a string encoding will never produce more than one characters for a single encoded byte when decoding? <rlb>(i.e. is that "guaranteed" anywhere relevant?) <JohnCowan>rlb: yes, unless yu count edge cases like BCD numbers, compression, etc. <JohnCowan>there are some 6-bit codes, but usually they are padded to 8 bits internally and sent out a serial line <rlb>OK, thanks. I was specifically just concerned with whether (ice-9 iconv) bytevector->string could ever produce a string longer than the input bytevector. <JohnCowan>safe to assume not less than 1 nor more than 10 bytes per char <JohnCowan>4 bytest to specify a sub-encoding + 3 bytes to select the current encoding(s) + 1-3 bytes for the char itself <JohnCowan>utf32 is the only 4-byte encoding and it is stateless <rlb>If I read the docs right, it sounds like bytevector oriented variants of the (ice-9 rw) read/write functions may still be useful, if they're the main/only way to make a nonblocking read/write. Anyone happen to know if that's correct? i.e. from surveying our docs, it sounds like all the other reads/writes will block one way or another (perhaps via suspension). <rlb>Asking because I have added read-bytevector!/partial and write-bytevector/partial, but then realized I should double-check. <rlb>(and implemented the existing string functions in terms of those, and have moved the string functions to deprecated.c...) <old>hmm I think that suspendable port kind of work only with bytevector ? <old>there's some low level things that are require for peeking byte <old>not sure if that's relevant <rlb>old: I'm not sure, but I have a suspicion that rw is bypassing much of the normal stuff, but if it's not, then perhaps there's little reason to keep it. <rlb>direct call to read(2).