IRC channel logs


back to list of logs

<dsmith>I wondered at that in the past. If there is a "constructor" kind of function, could that be used as a reader? No, because you would need to evaluate it, not only read it.
<dsmith>Like if write was applied to a hash it could be something like
<dsmith>(alist->hash-table '((key1 . "value1") (key2 . "value2") ...))
<dsmith>Assuming that the keys and values had a read+write syntax.
<chrislck>sneek: botsnack
<rlb>dsmith: fwiw EDN has an approach to that and I have a reader for guile. There, you specify the tagged element readers as a map to edn/read via :readers
<rlb>Still pretty rough, but:
<daviid>wingo: before i forget, the (C) last date needs to be bumped to 2022 in the guile repl
<daviid>*before the next release that is ...
<daviid>rlb: nice! is edn widely used? doyou actually use it? just curious
<daviid>rlb: emacs-lucid depends on libgdk-pixbuf and libglib as well, which weird isn't it? i'll stick to emacs-lucid, even if it happens that all my problems were related to what I highly suspect to be an xwayland bug, in debian testing, not an emacs-gtk related bug ...
<rlb>daviid: it's basically a "safe" and more portable flavor of clojure's syntax, so it's used at least that widely (clojure and clojurescript), and I think there are some other implementations, but I don't know if they're used much.
<rlb>(and it's built in to clojure, i.e. you should use the edn reader for anything that's not completely trusted)
<wingo>good morning
<wingo>tx daviid
<rlb>daviid: and glad you were finally able to settle things down a bit.
<daviid>wingo: good morning, welcome - i am actually gona go to bed soon, but ... :):)
<daviid>rlb: indeed, i felt 'cursed' haha, but finally, gnome on xorg 'saved my life' :):)
<rlb>And wrt using edn, I prefer it to json when/where I can.
<rlb>(in addition to normal clojure use for source, etc.)
<daviid>i'll follow xwayland next releases ... and check when the bug is fixed ...
<daviid>rlb: edn vs json was what i had in mind wheni asked ...
<daviid>ok, have to rest, bbl
<stis>Hay wingo: WDYT about pausable continuatoins where yo do not unwind the stack
<wingo>like a spaghetti stack or something?
<stis>well, tree's
<stis>2 applications, python-on-guiles generators and prolog code
<wingo>most uses of continuations don't need multiple invocations, we would need to rebase on a kind of coroutine form that doesn't allow multiple reinstatements
<stis>I am playing with that concept now in a branch, very nice work with the compiler
<wingo>anyway it's possible, mostly needs run-time support i think, underflow/overflow handlers like chez or so
<sneek>chrislck: wb!
<stis>anyhow good work witht he compiler. It's a bite tio implement new instructions, but I made a few to test out the concept
<stis>but then if one does it right you will get execellent optimisatoinas and jit
<stis>if you want I can work in a branch else I may put up a branch at gitlab or such
<stis>wingo ^ ^
<stis>Struggeling to make it work though, GC, resizing stacks, dynamic windings, jit, optimisation features, printing ,...
<stis>But I think that guile is an excellent research tool
<stis>we should perhaps document the process to add instructions
<stis>and concepts
***zap1 is now known as zap
<dsmith>rlb: Interesting! (re: edn)
<chrislck>sneek: what is diabetes?
<sneek>From what I understand, diabetes is what you get when you have too many snacks
<civodul>wingo: hey! re bignums in the assembler, now i remember: there was this 'truncate-bits' optimization in 05614f792bfabbc33798863edd0bb67c744e9299
<wingo>civodul: i believe that for 64-bit platforms, that code allocates 1 bignum for a "bits" argument that is signed and outside [-2^31,2^31-1], or unsigned and outside [0,2^32-1]
<wingo>this doesn't happen often afaiu
<civodul>i know of one case where it happens, which prompted to this optimization
<civodul>it's when generating Guix's "package cache", at the end of "guix pull"
<civodul>basically, we're compiling a single literal vector list of vectors
<civodul>roughly 20K vectors (one per package)
<wingo>you mean before the optimization landed, right?
<civodul>i think the optimization reduced the number of bignum allocations, without eliminating them entirely no?
<civodul>my memory is fuzzy
<wingo>(let ((start (assq-ref (gc-stats) 'heap-total-allocated))) (let lp ((n #e1e6)) (cond ((zero? n) (- (assq-ref (gc-stats) 'heap-total-allocated) start)) (else (truncate-bits n 64 #t) (lp (1- n))))))
<wingo>$4 = 0
<wingo>i mean that optimization eliminates bignum allocations when they are not needed
<civodul>ah ok, sounds good
<wingo>what you really want is a better garbage collector for guile :)
<civodul>that may help, but to what extent?
<dsmith-work>{appropriate time} Greetings, Guilers
<civodul>does anyone have experience with tracing à la LTTNG?
<civodul>it'd be sweet to have the ability to insert "trace points" in Guile programs
<dsmith-work>civodul: A year or two ago I was debugging some emacs function. I found that you can step through them! It would be wonderful to have something like that in Guile. I think I needed to instrument the function in question though.
<civodul>dsmith-work: the VM has breakpoints and things like that, but what we're missing is a way to define tracepoints in user code and to collect and dump those traces