IRC channel logs
2023-06-11.log
back to list of logs
<dsmith>rlb, Does bookworm emacs have native compilation enabled? Or do I need to recompile it from source? <dsmith>ACTION currently installing, upgrading, restoring.. <rlb>dsmith: has native compilation. <rlb>(Brace yourself for a wind tunnel the first time you fire it up.) <rlb>It's spendy with the cpu, "all at once, in the background". <rlb>fwiw the data goes into ~/.emacs.d/eln-cache by default and afaik there's no gc, so you might want to prune it every once in a while (i.e. across versions, etc.). <daviid>dsmith: oh nice! let me know how it goes ... <daviid>dsmith: installing g-golf on debian bookworm should be like a 'breeze'- running its examples as well ... <rlb>wingo: so... you got me thinking (contemplating some alternatives, either for the first pass, or a future revision). One question -- up to now I've preserved the in-place mutability of ascii-only stings because it wasn't too hard, and I figured it might help preserve performance for some (maybe?) common-case existing code. But how much do you think we might we want that, if we want it at all? <daviid>dsmith: just a quick reminder though, that to run the guile-cairo based examples (two examples so far), and use guile-cairo to write your own(s), you'll need to manually install from the source tree, and manually apply two patches, <Kolev>RhodiumToad, ./autogen.sh works now, but now I get an error on ./configure -- configure: error: Package requirements (gobject-introspection-1.0 >= 1.72.0) were not met: -- but I installed gobject-introspection <Kolev>RhodiumToad, ah. I was missing `gobject-introspection-devel`. <Kolev>RhodiumToad, but now I'm missing `guile-lib`. <Kolev>Oh no, I have to build that from source too. <Kolev> ../pre-inst-env: line 87: exec: compile: not found <daviid>Kolev: not familiar with fedora, but are you sure there is no guile-lib package? guile-lib is nearly as old as guile itself ... <Kolev>daviid, I haven't been able to find it in the package manager, but I could be clueless as to the package name. I really do not like how package names and upstream names are so different. <daviid>either guile-lib or guile-library <daviid>anyway, the error above is a symptom that it didn't find guils, the guile script .. the command is exec is "... $(GUILD) compile $(GUILE_WARNINGS) $(GUILE_TARGET) -o "$@" "$<"" <daviid>so, are you sure you didn't miss a configure error? <daviid>guile 2.0??? can't you use guile-3.0 ? <daviid>or at least 2.2 - it should work, but ... you might as well get guile 3.0, for your own 'good' <daviid>anyway, can you check in the $prefix/bin repo, if there is a guild script, next to guile <Kolev>daviid, now there is /usr/bin/guild <Kolev>daviid, I still get the same make error. <daviid>line 25 checking for guild2... no, and 26 hecking for guile-config2... no <Kolev>`guile` is 2.0. `guile3.0` is Guile 3.0. <daviid>but it still only finds guile 2.0 <daviid>in in further lines, you see it picks guile 2.0 ... try to fix that <Kolev>⬢[caleb@toolbox guile-lib-0.2.7]$ guile3.0 --version <daviid>i am looking at your configure paste <daviid>line 17 says it only could find guile 2.0 (?) <daviid>going afk, bb in 15min or so ... <Kolev>Great. I don't want to have to modify this build system to get it to see Guile 3.0. I don't know how it works. <Kolev>All I wanted to do was play with the examples. <daviid>Kolev: i would try in a fresh terminal, cd <path-to/guile-lib; ./autogen.sh; .configure --with-guile-site="yes" - i won't be able to further help today, i hope someone else 'shim-in"... good luck <daviid>or maybe just ./configure [but then you may have to augment the GUILE_LOAD_PATH ... as you prefer ...] <wingo>rlb: i think that from scheme, string-set! performance is not important. the kind of interface that builds strings should instead fill a utf-8 bytevector (string builder pattern) <wingo>so if string-set! becomes O(n) instead of O(1), fine with me <wingo>mutable strings in scheme was an error imo :) or at least, is an error now that there is utf-8 and bytevectors <ArneBab>wingo: do you have a theory why guile-wasm code is so much faster than the native one? <wingo>ArneBab: for the loop case, it is register allocation. <wingo>there are cases in which guile-wasm is slower also. a work in progress. <rlb>Some change I've made in my current tree is causing a crash in make during compilation of eval.go, and the stack isn't very revealing. So I'm wondering about other ways to find the culprit: https://paste.debian.net/hidden/fddeeb9a/ (Aside from review, adding print statements, etc. -- been trying that.) <rlb>...fwiw, these are the changes that finally move the internal stringbuf represntation to utf-8, and so have the assembler.scm and types.scm adjustments, etc. <rlb>...answer, revert changes, build, then restore changes (so it's past boostrapping) and then it'll tell you. <rlb>(i.e. now I have a function name) <wingo>when it's that early in the boot it's either prints or bisecting the change :/ <wingo>rlb: or, since it seems it's an arg-count thing, perhaps try compiling assembler.scm with a known-good guile ? <rlb>OK, right -- imagined that might be the case. Just figured out which err fn is printing the message, and so going to try to print a glibc backtrace from there. <wingo>am assuming that this changed code would be in assembler.scm <rlb>What's the preferred way to tell make to use -W2 (if that's plausible)? <rlb>wingo: ...I also suspect this might be an indirect effect, i.e. of the flip to utf-8 in-memory format for stringbufs, but we'll see (might just be something straightforward/silly). <wingo>rlb: i wouldn't use stage0 for warnings, because you need warnings for the compiler itself, but that needs eval.go first <rlb>The error it's settled on is similar, but not quite the same (the wrong number of arguments was a bug I introduced while debugging :) ). <wingo>so i would take a guile you have in /opt/whatever/bin/guild compile -W2 foo.scm. ah but if it's not the wrong number of args i don't know ;) <rlb>wingo: found it - my fault of course, but also, perhaps too many stringbuf types: assembler has one, types has one, and strings.c has one :) Vaguely wondered about changing the names to differ. <rlb>The clue I should have picked up on sooner was in the message since it was looking for an assembly <strinbuf> record (struct), but getting a "real" strings.c <stringbuf>.