IRC channel logs

2022-09-21.log

back to list of logs

<daviid>sneek: later tell tohoyn of course I will provide proper support for GVariant as well, it's just that I wish to finalize the VFunc support first, which is a bit more complex then it seems, and I was kept afk more then I wish ... but I am back to this goal now ... no ETA, but making good progress towards that goal ... thanks for your patience
<sneek>Got it.
<daviid>later tell tohoyn as you said, but just 'in case', here is a concrete example, following a simple example based on your own code but (re)written in a more scheme/goops/g-golf idiomatic way works fine - https://paste.debian.net/1254521/
<daviid>sneek: later tell tohoyn as you said, but just 'in case', here is a concrete example, following a simple example based on your own code but (re)written in a more scheme/goops/g-golf idiomatic way works fine - https://paste.debian.net/1254521/
<sneek>Will do.
***taiju` is now known as taiju
<tohoyn>sneek: botsnack
<sneek>tohoyn, you have 3 messages!
<sneek>tohoyn, daviid says: i won't spend time on anything else then proper support for VFunc, unless bug(s) while using implemented feature(s), GVariant are not supported 'proper' (and very far from) in g-golf current (as you know already ...)
<sneek>tohoyn, daviid says: of course I will provide proper support for GVariant as well, it's just that I wish to finalize the VFunc support first, which is a bit more complex then it seems, and I was kept afk more then I wish ... but I am back to this goal now ... no ETA, but making good progress towards that goal ... thanks for your patience
<sneek>tohoyn, daviid says: as you said, but just 'in case', here is a concrete example, following a simple example based on your own code but (re)written in a more scheme/goops/g-golf idiomatic way works fine - https://paste.debian.net/1254521/
<sneek>:)
<tohoyn>daviid: thank you for information about variants. what about g-action-map-add-action?
***rgherdt_ is now known as rgherdt
<flatwhatson>i did a bit of a dive on the terminal-width / COLUMNS situation, basically the problem is that readline is responsible for setting COLUMNS, which is why we usually see it working in a repl with (ice-9 readline) loaded
<flatwhatson>we can't do the easy solution of just using readline directly, so that leaves us with replicating the same behaviour with ioctl(TIOCGWINSZ) or using a hacky wrapper script to get bash (which is using readline) to export COLUMNS as a normal environment variable
<flatwhatson>huh, guix has everything necessary already in guix/build/syscalls.scm
<civodul>flatwhatson: i agree we can do better than COLUMNS :-)
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, apteryx says: looks like it'll be faster to plug an extra storage device (in a pinch, a USB key will do) to balance overdrive1.
<wingo>civodul: wrt bdw and interior pointers, that switch affects intraheap edges
<wingo>istr that all edges from the stack and registers are always considered as possibly interior
<taw10>flatwhatson: May have been some duplication of effort here. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55568
<civodul>wingo: ah, could be!
<flatwhatson>taw10: thanks for that, i'll update there if i get anywhere further with it :)
<taw10>I think that we just need everything to work acceptably when we don't know the terminal width (not giving errors, as it does currently in certain circumstances, see the bug report). Too bad that there's no portable/nice way of finding the width without readline, but it seems likely that any use case that *is* interested in nicely wrapping to the terminal width, would already be using readline
<flatwhatson>taw10: interesting, false-if-exception should be sufficient to suppress errors from string->number
<flatwhatson>if you add a line (format #t "COLUMNS: ~a\n" (false-if-exception (getenv "COLUMNS"))), it prints "COLUMNS: #f"
<flatwhatson>somehow your continuation code is preventing false-if-exception from working?!
<taw10>Wow, that's interesting. The test code is just copied from the examples in the manual
<taw10>Is it because of start-stack?
<civodul>taw10, flatwhatson: similar issue: https://issues.guix.gnu.org/57095#5
<flatwhatson>nasty!
***attila_lendvai_ is now known as attila_lendvai
***NullPointerErro1 is now known as NullPointerError
<attila_lendvai>i'm looking for some example guile code that opens a pipe, execs a child process, and communicates with it using its stdin/stdout. any pointers are appreciated!
<unmatched-paren>attila_lendvai: https://www.gnu.org/software/guile/manual/html_node/Pipes.html
<attila_lendvai>unmatched-paren, thanks!
<avp>Hello, Guilers!
<dsmith-work>Wednesday Greetings, Guilers
***NullPointerErro1 is now known as NullPointerError
***NullPointerErro1 is now known as NullPointerError