<zv>is there any way for me to get the 'result' from `(format #t whatever)'? <zv>you are the man as usual mark_weaver <zv>i owe you dozens of beers at this point <zv>i'm asking for debt forgiveness <mark_weaver>write some cool free software and it will have been worth it :) <zv>i'm writing a weechat extension now! <zv>transalte between a gateway and a "real" irc name <zv>yeah, forgive me, just started to learn lisp a few months ago <zv>so i'm sure theres some horrors in there, but i did my best <mark_weaver>at a first glance, it looks like reasonable code to me <zv>yeah, i saw cut used in srfi source and i use it all the time, such a usual piece of code <zv>that is the cool thing about guile, tons of really mindblowingly cool stuff <mark_weaver>zv: I have some suggestions for how to simplify 'replace-privmsg' <zv>i am definitely all ears <mark_weaver>to begin, why not add some parentheses to the regexps so that 'message' and 'hostmask' are fetchable via 'nth-match' ? <mark_weaver>but going a bit further, it seems to me that 'regexp-substitute' could perhaps be used here. <mark_weaver>but I suppose it's a matter of preference whether to use that. <zv>i didn't know there was a function called regexp substitute <zv>i would definitely use that <mark_weaver>in the emacs info reader, you can just type i regexp-substitute RET <zv>i didnt even know about that keybinding <zv>this changes everything <zv>yeah, i mean, texinfo as a format I hear kindof blows <paroneayea>I'm not sure about texinfo as a markup language, or info as a non-emacs user :) <paroneayea>though sirgazil recently did a really nice theme for texinfo's html export ***octo_ is now known as octophore
<wilfredh>what's the status of R7RS-small in Guile these days? <sneek>wilfredh, you have 2 messages. <sneek>wilfredh, wingo says: such patches are welcome :) i think we should use texinfo as the format; there is a facility to turn texinfo in docstrings to ARGUMENTS-IN-CAPS etc <sneek>wilfredh, wingo says: but we haven't enabled it yet <mark_weaver>wilfredh: we have a branch in our git repository that is pretty close to a complete R7RS-small implementation, with just a few missing bits. <mark_weaver>but it's been lingering there for a while on those missing bits <mark_weaver>the trickiest one being a serious regression in the efficiency of 'write' after adding support for writing cyclic data. <mark_weaver>I think I know how to fix that, but I haven't yet found the time to get it done. <wingo>mark_weaver: when you are back :) what memory_model should we be using for atomic boxes? right now it is using the default sequentially consistent model <wingo>ACTION pushed atomic boxes, whee <wingo>the compiler will not optimize that, on purpose :) <wingo>so on this laptop with 2 cores and 2 threads per core, spawning 5 threads that do (set! x (1+ x)) 1e7 times each results in a final count of around 1.5e7 (it varies of course) and takes about 1 second (about 4 of run-time). <wingo>doing the same with atomic boxes and a little compare-and-swap loop for the add (i don't know how to do atomic-add! otherwise given that we need to overflow to bignums) takes more like 20s wall-clock time and 75s run-time <wingo>but, it actually computes the right number (5e7) <wingo>i wonder how many retries were needed... <wingo>i guess it means that under contention on this laptop i can do about 600K compare-and-swaps per thread per second <wingo>maybe i should try with uncontended cas <wingo>i don't know what the effect of relaxing the memory model would be <wingo>maybe that means that guile is the bottleneck here, or that the compiler barriers introduced by the atomics are the bottleneck <paroneayea>today I'm building an emacs client for ActivityPub <paroneayea>it's weird to hack in elisp after all this time in guile! <davexunit>wingo: neat re: atomic boxes. I haven't really used boxes in Guile, but I feel like they could help me. what doyou (or anyone else reading this) use them for? <wingo>davexunit: normal boxes are just assignables. anywhere you have set!, guile compiles it to a box already. <wingo>you can use boxes if you have a functional data structure to which you need to introduce mutation <wingo>atomic boxes are similar but are a separate data type (so that you only use them atomically) <davexunit>wingo: I think I could use them to simplify my "functional reactive programming" implementation <wingo>except that they have actual semantics when they are being accessed by multiple threads <davexunit>I didn't know that there was a box data type around all this time <davexunit>it feels weird to use variable objects in that way... <wingo>there is also this srfi-111 thing but i don't recommend it because it will be slow. dunno tho :) <davexunit>wingo: are you saying that boxes are an implementation detail rather than a public interface? <wingo>variables are certainly a public interface <wingo>and they have the semantics of boxes <paroneayea>wingo: is this similar to racket's immutable boxes? <wingo>i.. don't think so? dunno tho <wingo>the whole point of a box is to be a place to mutate <paroneayea>wingo: I only know about racket's immutable boxes because of that very point being made in SRFI 111 :) <paroneayea>Racket and Chicken provide immutable boxes, which look like boxes to box? and unbox but which cannot be mutated. They are not considered useful enough to be part of this SRFI. If they are provided nevertheless, the recommended constructor name is immutable-box. <wingo>they have vm support so as to go as fast as possible <davexunit>wingo: could we expose an interface like Clojure's atoms? <wingo>but they are a compiler barrier, so they prevent some code motion <wingo>could do that before with mutexes and strutures but atomics are better for that <rekado>wingo: will they be used for channels? <rekado>I'm thinking of MVars in Haskell, which are used as synchronisation primitives. <davexunit>guile almost got an mvar module a few years ago <davexunit>IIRC, there was some issue with the way threading works that violated the semantics of mvars and thus the patch was never applied <wingo>that's why i implemented them anyway <lfam>And they do confirm a problem <paroneayea>as a convention for a foo method of mu4e that's not a public interface? <paroneayea>sorry, that's an emacs question not a guile one, I just realized :) <wingo>ACTION pushed mostly-untested channels impl to fibers <sapientech>OrangeShark: paroneayea mark_weaver thanks guys! ill def be using haunt <OrangeShark>sapientech: I am glad it is working for you :) I think haunt should be easy enough to extend to do whatever you want, davexunit did a pretty good job in the design.