<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. <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) <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 ... <stis>Hay wingo: WDYT about pausable continuatoins where yo do not unwind the stack <wingo>like a spaghetti stack or something? <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 <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>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 ***zap1 is now known as zap
<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? <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>i mean that optimization eliminates bignum allocations when they are not needed <wingo>what you really want is a better garbage collector for guile :) <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