IRC channel logs

2021-08-21.log

back to list of logs

<apteryx>racket throws an exception when it detects a dependency cycle between modules; can we have this in Guile please? :-) c.f.: https://docs.racket-lang.org/reference/Module_Names_and_Loading.html and search for 'dependency cycle'.
<apteryx>sneek: later tell maximed I tried the abort-to-prompt thing with the a suspendable port, but unfortunately the continuation cannot be resumed; it fails with "ERROR: In procedure abort: Abort to unknown prompt" and (suspendable-continuation? 'continue) returns #f. See https://notabug.org/apteryx/mcron/commit/982422d9a01792773565aaadd15f7cba96f13e72.
<sneek>Got it.
<maximed>sneek: later tell apteryx: you need to wrap the call to 'cont' in a 'call-with-prompt' and 'parameterize ((current-read-waiter ...))'
<sneek>Welcome back maximed, you have 1 message!
<sneek>maximed, apteryx says: I tried the abort-to-prompt thing with the a suspendable port, but unfortunately the continuation cannot be resumed; it fails with "ERROR: In procedure abort: Abort to unknown prompt" and (suspendable-continuation? 'continue) returns #f. See https://notabug.org/apteryx/mcron/commit/982422d9a01792773565aaadd15f7cba96f13e72.
<sneek>Will do.
<maximed>apteryx: 'abort-to-prompt TAG' can only do something when it's inside a 'call-with-prompt' (dynamically speaking, not lexically)
<maximed>sneek: later tell apteryx: 'abort-to-prompt TAG' can only do something when it's inside a 'call-with-prompt' (dynamically speaking, not lexically)
<sneek>Got it.
<maximed>sneek: later tell apteryx: 'abort-to-prompt TAG' will ‘abort’ to the nearest ‘call-with-prompt’ on the stack. Likewise, (SOME-PARAMETER) will return the VALUE of the nearest (parameterise ((SOME-PARAMETER VALUE)) ...)
<sneek>Okay.
<dokma>Can I show function definition from repl
<dokma>?
<apteryx>dokma: if you use Emacs + Geiser, you can do M-, to go to the definition
<sneek>Welcome back apteryx, you have 3 messages!
<sneek>apteryx, maximed says: you need to wrap the call to 'cont' in a 'call-with-prompt' and 'parameterize ((current-read-waiter ...))'
<sneek>apteryx, maximed says: 'abort-to-prompt TAG' can only do something when it's inside a 'call-with-prompt' (dynamically speaking, not lexically)
<sneek>apteryx, maximed says: 'abort-to-prompt TAG' will ‘abort’ to the nearest ‘call-with-prompt’ on the stack. Likewise, (SOME-PARAMETER) will return the VALUE of the nearest (parameterise ((SOME-PARAMETER VALUE)) ...)
<apteryx>maximed: thanks, that helped! It seems to work now. I'll send a v3 for the mcron patch!
<apteryx>hmm, for the job I'm testing (a rsync backup), it misses some output, perhaps because rsync splits into 3 processes but it only looks at one
<apteryx>bah, still buggy it seems :-(
<dokma>apteryx: I'm trying to debug a tcp/ip server from the guile repl. Is there a way to see where a function is defined from the repl itself
<dokma>leoprikler: ^^^
<apteryx>',a name' I think
<dokma>let me try
<leoprikler>that lists all the procedures (variables?) with name in it
<dokma>I get: (system repl server): stop-server-and-clients! #<procedure stop-server-and-clients! ()>
<dokma>So I suppose it is a procedure in system/repl/server.scm ?
<leoprikler>ahh, right, the module is the first thing
<leoprikler>dokma well duh, we already knew that
<dokma>true that
<dokma>Funny thing is that I've added a (display "stop-server-and-clients! called!\n") as the first thing in stop-server-and-clients! and it never gets printed.
<dokma>Even when I manually call the function from the repl...
<dokma>Is there some simple way to print a list with sockets and functions in it?
<apteryx>pk is your friend I think
<apteryx>it's *the* Guile debugger
*apteryx hides
<dokma>What is pk?
<leoprikler>peek
<leoprikler>it's printf debugging on legs
<apteryx>I sometimes use ,trace as well (careful in Geiser, it's not very good at mass output).
<apteryx>I'd like to use ,debug more but either I or it is too dumb to make it a satisfying experience.
<apteryx>I meant ,break your-proc
<stis>hello guilers
<apteryx>hi!
<apteryx>maximed: I think my problem is related to \r; I print lines everytime I encounter a newline (\n), but now that I print everything including rsync's output which contains \r, it seems to mask/mess the expected output.
<apteryx>I guess I should treat \r as newlines and print there 'updates' on distinct lines to avoid garbled output (at the cost of extra noise/verbosity)
<apteryx>their*
<maximed>apteryx: Maybe you could just delete the \r
<maximed>They don't provide any additional value. (Unless you're on a system that uses \r outside \r\n)
<maximed>Didn't some version of Mac do that?
<maximed>(some old version)
<apteryx>maximed: at least for rsync, the \r are used to 'refresh' its progress output; so it'd seem better to have each updates appear on their own line (sed 's/\r/\n/'). Not sure if that's wise in general
<apteryx>I see in systemd they strip some stuff when viewing the output data via the 'strip_tab_ansi' procedure in string-util.c
<apteryx>they do something a bit elaborate w.r.t. carriage returns
***emacsoma1 is now known as emacsomancer
<dokma>Will this: (set! *open-sockets* (cons *open-sockets* (cons s force-close)))
<dokma>be a problem is *open-sockets* is an empty list on the first invocation?
<dokma>It won't be a proper list if I'm not mistaken.
<dokma>leoprikler: ^^^
<dokma>I want the server-socket to be first in the open sockets list to see if anything will change.
<leoprikler>maybe your cons-order is wrong, I have no idea what you're trying to do there
<dokma>leoprikler: I'm trying to have server-socket always remain the first in the list.
<dokma>So that it is closed first.
<dokma>Through debugging I've discovered that stop-server-and-clients! never even tries to close the server-socket.
<dokma>Apparently it bogs down while closing one of the client sockets.
<leoprikler>I mean the easier way would be to just simply reverse *open-sockets* before trying to call stop-server-and-clients!
<dokma>How do you revers a list in scheme?
<dokma>Is there a standard function for it?
<leoprikler>idk maybe there's something called reverse, you would have to read SRFI-1
<dokma>Will try.
<dokma>Awesome. Works...
<dokma>The only problem is that this is an associative list.
<dokma>leoprikler: If I just reverse it the pairs will get flipped.
<dokma>it's a (socket shutdown-procedure socket shutdown-procedure ...) type of list
<dokma>I know what I'll do... I'll add the pairs in revers so that when I reverse them they will be in the right order.
<leoprikler>ehm
<leoprikler>are you sure that's how reverse works?