<dsmith-work>Anyone know of any cheap (think rpi) ppc/ppc64 systems/boards? <wingo>rlb: i think some degree of increased GC allocation is acceptable. sometimes it even makes things faster. and in future we'll probably have a generational gc which will make short-lived allocations even cheaper <wingo>so, something to worry about, but not like a deciding factor to choose between different implementations <everstone>I sidestepped my issue from earlier via a translation table <manumanumanu>why is the write-line that was just documented in a recent commit so badly named? :P <wingo>would rather deprecate it tbh <manumanumanu>seems like a decent idea. write-line uses display semantics :'( <dsmith-work>Probably a mental echo of someting from a camelbacked language with impoverished identifiers. <wingo>or something like that, right? <wingo>i mean the idea of "print this then make a newline" is not so uncomment ***jao is now known as Guest78507
*wingo has working cross-module inlining, whee <wingo>some work remaining to do tho <wingo>like, actually benchmark it :P <wingo>& figure out what user expectations are <wingo>but would allow us to make more first-class definitions across a module boundary without define-inlinable <wingo>seems to compile guile fine & pass test suites, but guile's code is biased in that we know that modules are optimization boundaries and code around it ***Guest78507 is now known as jao
<rlb>wingo: thanks - I've ended up pursuing variants, e.g. sometimes preallocating a utf-32 array up front, populating that, traversing it to compute the final utf-8 size, allocating that sized string, and then filling it in via memcpy (e.g. string-tabulate), or using a dynamically resized (doubling as needed) array for either utf-32 or utf-8, and copying that to a properly-sized, indexed utf-8 string at the end. In the latter case, it <rlb>starts optimistically with a stack buffer (currently 1024) so it only needs scm_gc_malloc_pointerless resizing when that's insufficient. <rlb>(e.g. string-map, unfold, etc.) <rlb>We could of course do the same thing(s) somewhat less efficiently in scheme by accumulating a list of fragments (possibly reversing it) and then (apply string-append items)...