IRC channel logs


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>should just work
<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,
<daviid>dsmith: you'll find both patches in this thread - and - then (but you are an expert in these matters i think, augment your LD_LIBRARY_PATH (if necessary) with your $prefix/lib path ...
<Kolev>I'm having issues installing G-Golf on Fedora.
<RhodiumToad>missing gnulib, probably
<Kolev>RhodiumToad, ./ 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
<RhodiumToad>what version?
<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
<Kolev>daviid, no matches found.
<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>*it didn't find guild
<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'
<Kolev>`dnf install guile30`
<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>try guild in a 'frseh' terminal
<daviid>line 25 checking for guild2... no, and 26 hecking for guile-config2... no
<Kolev>Usage: guild COMMAND [ARGS]
<daviid>it still looks for guile 2.0
<Kolev>`guile` is 2.0. `guile3.0` is Guile 3.0.
<daviid>but it still only finds guile 2.0
<daviid>see lines 14 - 17
<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
<Kolev>guile (GNU Guile) 3.0.7
<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; ./; .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 ...]
<sneek>dsmith: Greetings
<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.
<ArneBab>wingo: thank you!
<chrislck>sneek: botsnack
<rlb>wingo: OK thanks.
<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: (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>just to get the warnings
<wingo>-W2 or so
<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>guild compile -W2 foo.scm
<wingo>there is a var...
<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>This is the "real" one:
<rlb>OK, thanks.
<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>.