IRC channel logs

2021-08-24.log

back to list of logs

<flatwhatson>sneek: later tell apteryx the problem is calling the continuation multiple times, (next-line (read-line* port cont)) should be (next-line (read-line* port #f)). with that fixed it works for me :)
<sneek>Will do.
<apteryx>leoprikler: not according to looking at strace output
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, flatwhatson says: the problem is calling the continuation multiple times, (next-line (read-line* port cont)) should be (next-line (read-line* port #f)). with that fixed it works for me :)
<apteryx>flatwhatson: oh! then leoprikler was on something! I'll give it a try, thanks!
<flatwhatson>it's not an infinite loop, but yeah. i think the call resumes after it would check the port's buffer, and then select also ignores the port's buffer, which is why it waits between every line
<flatwhatson>actually it is an infinite loop, derp
<apteryx>it works indeed! thanks a lot to both of you
<apteryx>Now I still need to figure out what in the original code (more complicated, but same idea) was wrong
<apteryx>but looking at it again knowing that it ought to work is motivating :-)
<flatwhatson>apteryx: not sure what you're working on, but i had good results with suspendable-ports + fibers
<apteryx>I'm adding some better logging facility to GNU mcron
<apteryx>it already has a main loop, so I'm building on that
<apteryx>I think I've found the problem, which is similar
<apteryx>the cont is captured in a scope and not refreshed upon reading a next line
<apteryx>problem fixed! woohoo!
<apteryx>the output is looking sharp now
***notzmv is now known as zimmybot
***zimmybot is now known as notzmv
<flatwhatson>nice!
***janneke_ is now known as janneke
<leoprikler>apteryx: gz
<vijaymarupudi>daviid: That's great news, thank you!
<sneek>vijaymarupudi, you have 3 messages!
<sneek>vijaymarupudi, manumanumanu says: 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.
<sneek>vijaymarupudi, mwette says: if you want to dig into macro expandsion https://legacy.cs.indiana.edu/~dyb/pubs/bc-syntax-case.pdf
<sneek>vijaymarupudi, daviid says: I fixed g-golf so, finally, guilemay GC <gobject> instances when applicable - please pull/make/install/try (devel branch)
<vijaymarupudi>thanks sneek!
<dsmith-work>UGT Greetings, Guilers
<vijaymarupudi>o/
<vijaymarupudi>manumanumanu: Yeah... I wish there was something similar in guile, without using gensym or generate temporaries all the time
<vijaymarupudi>Thanks mwette, I'll look at it soon!
<stis>heya guileres!
<ArneBab>Hi stis
<str1ngs>Hello, I'm looking for something like php's pack and unpack. I need to take an integer convert it to binary then convert it to a hex string. I'm assuming I can do this with bytevectors? But I'm not sure how.
<ArneBab>str1ngs: do you need the intermediate binary representation?
<str1ngs>basically I need this php code implode (unpack('H*',pack("V*",1))) which returns 01000000
<ArneBab>there’s -- Scheme Procedure: uint-list->bytevector lst endianness size
<ArneBab> -- C Function: scm_uint_list_to_bytevector (lst, endianness, size)
<ArneBab> Return a new bytevector containing the unsigned integers listed in
<ArneBab> LST and encoded on SIZE bytes according to ENDIANNESS.
<ArneBab>in (rnrs bytevectors)
<str1ngs>ahh that helps I actually looked at that quickly. unfortunately this is more low level then I'm used to.
<ArneBab>and format #f "~16,2'0r" byte
<ArneBab>from (ice-9 format)
<ArneBab>I used that in wisperis for base16 encoding (a strange missing piece in ice-9)
<str1ngs>I have bytevector->base16-string from gcrypt which I need for sha256 anyways
<ArneBab>if anyone wants to take base16 and base32 into ice-9: https://hg.sr.ht/~arnebab/wisperis/browse/eris/base32.w#L69
<ArneBab>base32-decode is still missing, because I have not needed that yet
<ArneBab>and compared to how much it is used, base32 is quite some beast
<ArneBab>would be cool to have format with ~32 just work as base32
<lloda>in Guile, typed vectors are bytevectors
<lloda>so if your numbers are in an #s32() or something then you can just get the bytes from that
<str1ngs>ArneBab: (bytevector->base16-string (uint-list->bytevector (list 1) (endianness little) 4)) works it returns 01000000 as it should!
<str1ngs>ArneBab: I'll have to rewrite this in wisp to show my appreciation :)
<str1ngs>"01000000" to be more precise
<str1ngs>lloda: that's what I was thinking but how would you get the bytes from the vector?
<dsmith-work>Recently upgraded to Debian bullseye. Guile make check is now failing test-out-of-memory. Both 3.0.7 and current git
<dsmith-work>Wonder what's going on there.
<dsmith-work>istr something about mmap and friends recently. Is this the same problem?
<dsmith-work>Looks like this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969707
<dsmith-work>Ahh. Just expect to fail.
<dsmith-work>And this: https://lists.gnu.org/archive/html/bug-guile/2021-01/msg00001.html
<ArneBab>str1ngs: yas! :-)
<ArneBab>yay!
<lloda>strings: you can just do (bytevector-u8-ref #s32(1 2 3) 0) or w/e
<ArneBab>lloda: wow, nice! I did not know that.
<dsmith-work>So, is a libgc 8.0.4 issue?