IRC channel logs
2023-07-08.log
back to list of logs
<RavenJoad>Is it possible to decompile a .go file to view its strings? <spk121>RavenJoad: from the command line, 'guild disassemble yourfile.go | grep make-non-immediate <rlb>wingo: (and of course anyone else) I've been attempting to preserving an "ascii mutation" optimization for "internal" code, i.e. if the string is ascii-only, you can still mutate in place. But that's further limited of course to just cases where the (possibly much larger) underlying buffer itself is pure ascii (i.e. an ascii-type strinbuf), and of course it's only useful for cases where you know you're only going to be making <rlb>ascii-compatible mutations. <rlb>It's not all that "hard", but it is extra complexity, and it does complicate the semantics for the public behavior, i.e. if you want to reason about costs, or try to diagnose issues. So I'm wondering about cost/benefit. Any strong opinions? <rlb>Of course it's also a little disconcerting to make a full copy of an entire string buffer just so a substring can modify a byte in place :) (i.e. if we drop the optimization). <rlb>(I suppose an additional argument on the side of not optimizing mutable ascii is that we'd end up leaving ourselves with a future question about if/when it might be OK to remove it, as compared to making a firmer transition now...) <rlb>wingo: ...also, given that utf-8 mutation is now always going to be a stringbuf swap I wondered (if it's feasible), if we might want to make it a compare-and-swap operation, so that code that wanted to could cheaply coordinate atomic string changes. In that world, we'd want ascii to behave exactly the same, i.e. no in-place mutation. <rlb>(i.e. it's a cell swap) <ArneBab>rlb: if you want to look at costs this would create, you can benchmark (only ((ice-9 string-fun) string-replace-substring). That has been optimized to the brink for the current cost of string operations and any slowdown there wil have real impact on existing code. <rlb>OK, thanks, though if it's doing any in-place mutations, it'll have to just be completely rewritten, i.e. it will have to work "in bulk". <rlb>(string-builder-ish) <rlb>Otherwise, yeah, it'll have terrible performance. <rlb>(Not sure if I've looked at that one yet...) <rlb>(currently in srfi-13) <spk121>huh. the reason JIT crashes on 64-bit MinGW seems to be that the abort-to-prompt longjmp is using a jmp_buf whose contents don't match any previous setjmp's jmp_buf <spk121>but the strange thing is that the contents of the bad jmp_buf look very reasonable, as if it were a valid jmp_buf that got lightly mangled <ArneBab>rlb: that sounds like it would completely break lilypond — if that’s the case, I’d be against merging it. We cannot break lilypond. <ArneBab>(lilypond is the one project that uses Guile and is the best tool of its domain — Guix is big and great, but it is one of many distros. Lilypond is hands down the best music engraver in existence, and it is built on Guile) <ArneBab>(and we also cannot make lilypond 20% slower: people are building huge works with it where every bit of performance counts) <ArneBab>⇒ please test how this would affect lilypond.