<stis>got a nice serializer made for guile with quite good performance. <ArneBab>stis: do you plan to share/blog the approaches how you realized that? ***lithium.libera.chat sets mode: +o ChanServ
<manumanumanu>vijaymarupudi: the road to pain for expanding macros is called syntax-local-binding. Note however that it limits hygiene. <manumanumanu>using that you can recursively expand a body completely, but if you expand two macros that happen to introduce the same binding they will collide since syntax-case only guarantees outwards hygiene <manumanumanu>but I believe you can compile from tree-il to scheme, which if your use-case allows it will be A LOT simpler. <ArneBab>wingo: I only now found your cross-module-inlining blog-post — really nice! Thank you for both: Improving Guile and explaining it so wonderfully! <vijaymarupudi>manumanumanu: Ooo, that might work! Are there any readings for what outward hygiene means? <apteryx_>would someone have an example to share with using suspended ports? ***apteryx_ is now known as apteryx
<apteryx>I tried something naive here, but it didn't work as expected (I was assuming I could change the return value of the suspendable read-line procedure via its callback, but that seems designed only to escape to somewhere outside the current thread or something? *apteryx goes back to $work but will peek in later <sneek>I've been running for 15 days <sneek>This system has been up 4 weeks, 1 day, 57 minutes <maximed>sneek: later tell roptat: afaik the return values of (current-read-waiter) are ignored. Likewise for current-write-waiter <maximed>sneek: later tell roptat: that procedure is supposed to wait for the port to actually be ready for reading <roptat>maximed, sorry, what's the context? <sneek>roptat, you have 2 messages! <sneek>roptat, maximed says: afaik the return values of (current-read-waiter) are ignored. Likewise for current-write-waiter <sneek>roptat, maximed says: that procedure is supposed to wait for the port to actually be ready for reading <maximed>sneek: later tell apteryx: afaik the return values of (current-read-waiter) are ignored. Likewise for current-write-waiter <maximed>sneek: later tell apteryx: that procedure is supposed to wait for the port to actually be ready for reading <maximed>sneek: later tell apteryx: Or use the 'prompts' to suspend the current fiber in guile-fibers, and reschedule it when the port is ready. <maximed>sneek: later tell apteryx: for your use case, maybe you need something like (call-with-prompt 'tag (lambda () (parameterize ((current-read-waiter (lambda (_) (abort-to-prompt 'tag)))) (read-the-line))) (lambda (partial-continuation) (cons 'suspended partial-continuation)))) <maximed>sneek: later tell apteryx: (untested) it should return the complete string, or (suspended . <the continuation>) if suspended <maximed>sneek: later tell apteryx: To continue, call the continuation when the port is ready. <roptat>you're gonna get sneek banned :/ <apteryx>maximed: thanks a lot! will give it a try later :-) <sneek>Welcome back apteryx, you have 6 messages! <sneek>apteryx, maximed says: afaik the return values of (current-read-waiter) are ignored. Likewise for current-write-waiter <sneek>apteryx, maximed says: that procedure is supposed to wait for the port to actually be ready for reading <sneek>apteryx, maximed says: Or use the 'prompts' to suspend the current fiber in guile-fibers, and reschedule it when the port is ready. <sneek>apteryx, maximed says: for your use case, maybe you need something like (call-with-prompt 'tag (lambda () (parameterize ((current-read-waiter (lambda (_) (abort-to-prompt 'tag)))) (read-the-line))) (lambda (partial-continuation) (cons 'suspended partial-continuation)))) <sneek>apteryx, maximed says: (untested) it should return the complete string, or (suspended . <the continuation>) if suspended <sneek>apteryx, maximed says: To continue, call the continuation when the port is ready. <maximed>roptat: For sending too many messages at once? <taylan>does ChanServ do automatic flood detection or what? <roptat>I thought so, but maybe not after all? <taylan>I've seen flood detection take effect on #debian the other day but I think it was a bot of their own and not ChanServ <roptat>I might confuse with another network <maximed>fwiw, Debian is on OFTC, #guile is on Libera <taylan>well there's a #debian on Libera, I meant that one <taylan>on-topic: has anyone else thought about the merits of vector-resize! / bytevector-resize! which was mentioned on the ML a week or two ago? <taylan>I was meaning to make a patch during my vacation, though now I'm more busy with taking care of my grandma than anything else. might still come around to doing it but not sure if the procedures are a good idea in the first place. <maximed>taylan: That seems pretty on-topic to me <maximed>I don't think vector-resize! & bytevector-resize! should be added, as they inhibit optimisations. However, <apteryx>taylan: that's very generous of you, kudos! <maximed>What about a (ice-9 resizable-vectors) module, which provides objects that function just like vectors and bytevectors, but are resizable? <taylan>maximed: I'm pretty sure it wouldn't offer the same performance, e.g. by not being able to use realloc() on the C level <maximed>(with as cost that the optimiser won't be able to optimise much) <maximed>taylan: Are you referring to the proposed (ice-9 resizable-vectors) module? <maximed>I don't see any reason why it couldn't use C's realloc. It can be implemented in C. <taylan>ah, I assumed you meant they would be implemented as Scheme, with normal vectors/bvs under the hood. <maximed>taylan, do you have any numbers on performance gains by using 'realloc' instead of malloc+memcpy+free? <taylan>we'd need to test gc_realloc in particular, against gc_malloc/memcpy/free <maximed>Is there any reason to use 'realloc' instead of GC_REALLOC? <taylan>no, I just meant those (the gc_... functions) are the ones we'd want to test, if anything, since we'd be using them <maximed>taylan: apparently, there is a scm_gc_realloc C function <taylan>wingo: do you have any wisdom for us w.r.t. hypothetical {vector,bytevector}-resize! operations? :-) <maximed>wingo: Are there any plans for optimising out bytevector bounds checks? E.g., try ,x (lambda (bv) (unless (>= (bytevector-length bv) 2) (error "x")) (bytevector-u8-ref bv 0) (bytevector-u8-ref bv 1)) <maximed>The bounds checks by "bytevector-u8-ref" should ideally be optimised out ... <vijaymarupudi>maximed, taylan: regarding resizeable-vectors, a new type similar to vectors would work for me. I wonder if they can be hooked to the generic array interface of guile? <vijaymarupudi>Although my fingers are crossed to let traditional vectors and bytevectors be resizeable, if optimizations are not prohibited <taylan>I was about to start writing a little Scheme library called dvector, good thing you linked SRFI-214 which already does exactly what I had in mind :D <vijaymarupudi>:) I think it might be a good frontend to base the realloc based backend <dsmith-work>taylan: The bobot code has some kind of flood prevention. <manumanumanu>sneek: later tell vijaymarupudi two symbol=? bindings will become the same identifier in the extent of one application of a syntax-case transformer. That racket procedure solves those issues for racket.