IRC channel logs
2023-07-04.log
back to list of logs
<rlb>ACTION is back on track wrt the utf-8 conversion. Finally figured out how to just remove all the string-ref/set (encoding dependent) compiler optimizations for now -- we can reformulate those at the end. (I'd missed something in my earlier attempt, which was causing those "meet" failures.) <wmedrano>Is there a way to pretty print values in the REPL? <wmedrano>I'm aware of manually using (pretty-print exp) but can this be the default <wmedrano>Perfect thanks! I'll dig in more into commands <rlb>What's the best way to compute the "natural alignment" of the current system in C? Wondered if sizeof(void *) was plausible... <rlb>wingo: in our code, what is "sz" intended to mean, i.e. is it always meant to indicate a byte count? (Asking because I'd been using foo_bn and foo_cn in places to indicate the byte and char counts.) <mwette>rlb: _Alignof() is C11 but I believe guile is coded to C99. <rlb>Now I'm *finally* back to adding the sparse utf-8 indexes, and think I might have raised this a while back, but if the index is aligned, in-line after the utf-8 bytes in the stringbuf, I'm contemplating whether it'd be preferable to compute the position of the index every time we need it, or to add one more cell to every utf8-string that'd hold the pointer to the first byte of the index. <rlb>Of course the latter makes all of them 8-bytes bigger, but it's faster, and the former requires a bit of math (u8 byte count + compute alignment). <rlb>We could also only have a hybrid where the index only exists when the string is longer than some minimum. <rlb>For now I'm just going with the fairly simple computation. <graywolf>Hi, I do not have much first hand experience with FFI (in any language), so I want to ask, are there performance benefits in creating guile module in C compared to doint the same using (system foreign)? <RhodiumToad>my guess is that it depends on how thickly you're wrapping the foreign API <RhodiumToad>and how much work is needed for parameter conversion, etc. <graywolf>So if both would be just basically doing the same thing, there will not be much of a diffirence in practice? <rlb>I'd guess that there's a difference, but I don't know enough about how foreign works to have any good idea how much. But (I think what RhodiumToad was suggesting) if the functions you're wrapping do very much at all, it won't matter. It'll only matter if you're trying to call fine-grain C functions. <rlb>i.e. perhaps a lot of simple accessors, etc. Though that's all based on an assumption that foreign is reasonably efficient... <graywolf>Since most C functions in my case will be doing network calls I will go with the (system foreign) since it seems easier and will see how it goes <rlb>Sounds reasonable -- I'd imagine something might be terribly wrong if you could tell the difference there :) <mwette>I think the C coded ones will be a little faster, libffi needs to do more to shuffle the args into the right registers, but not worth it IMO; also (system foreign) can't do variadic args well; I mostly prefer to use (system foreign)