IRC channel logs

2024-10-21.log

back to list of logs

<lloda>ekaitz: i'd use match for that
<ekaitz>lloda: yep! that I did!
<lloda>+1
<ekaitz>also I'm interested on how performant are match vs case
<lloda>,optimize (match a ('a 1) ('b 2)) and ,optimize (case a ((a) 1) ((b) 2)) give p much the same thing
<ekaitz>oh great!
<lloda>the new srfi-64 is breaking my tests, here are some things i did that don't work anymore
<lloda>- test-log-to-file is gone (i stopped using this for the most part when i stopped using the default test runner, but i still had it in a couple places)
<lloda>- test-begin and test-end require a string (the old impl accepted a symbol)
<lloda>- test-approximate require real arguments (the old impl accepted complex arguments)
<lloda>i never found a good way to test-approximate other types. I do something like (test-approximate 0 (compute-error a b) tol) which isn't ideal bc when it fails it doesn't show a and b. I think a test-with-predicate is sorely missing
<civodul>lloda: could you report that in https://issues.guix.gnu.org/73605, making sure Tomas is Cc’d?
<civodul>i think test-begin was always supposed to take a string, but perhaps it’s a case where we should be flexible to favor backward compatibility over spec conformance
<lloda>will do, although these aren't bugs, really
<civodul>yeah, but it’s best not to break actual use cases
<lloda>i can see that
<graywolf>Hello! I am here to drawn upon your wisdom again. I wrote my own wrapper for spawn (called spawn*), and for environment I am using #:key (env (environ)). But on 3.0.10 I am getting warning about call to environ while multiple threads are running.
<graywolf>But when I look at the documentation at `spawn', I see [#:environment=(environ)].
<graywolf>(And spawn works without the warning from multiple threads.)
<graywolf>So it *should* be possible to do this, but I am unsure how. Any suggestions? How can I get (environ) in multithread program without the warning?
<graywolf>Oh, so it seems the documentation is imprecise, and it works when spawn sees environment as SCM_UNBNDP.
<graywolf>Right, so it technically also does not work (in case of concurent modifications of environ), it just does not bother printing the warning.
<graywolf>So I just need to change the the default value fo #f instead of (environ) and the call to (spawn* ... #:environment env) into (apply spawn* ... (if env (list #:environment env) (list))).
<graywolf>Thanks for rubber ducking for me.
<lloda>i was using this... (define-syntax test-gt (lambda (x) ((@@ (srfi srfi-64) %test-comp2) (syntax >) x)))
<lloda>can't complain that it broke
<lloda>but i don't see how to do it properly with the interface there is
<lloda>(or was)
<graywolf>lloda: I am trying to understand what the snippet did originally. So you could then use something like (test-gt 2 1) for pass, and (test-gt 1 2) for fail?
<graywolf>Maybe using test-thunk would work? Is will not be as succient as yours version, but should be reasonable still. You will still need the @@ to get syntax->source-properties I guess, that one is not exported.
<lloda>hmm i'll have a look
<lloda>i've just replaced those by (test-assert (> a b)) for the time being :-/
<graywolf>Looking at how I implemented test-eq and friends, I guess (%test-2 test-gt (lambda (expected actual) (> actual expected))) could work?
<graywolf>Not tested though
<civodul>graywolf: re ‘environ’, see commit 84bf84032208e21d20ad13f3033d4fca3a512014
<lloda>would you consider adding a documented (test-compare cmp ref value tol) kind of thing? i'd rather avoid @@ after this
<civodul>in short, it’s not thread-asfe
<civodul>*safe
<graywolf>Yeah, but I would think what scm_spawn_process does is not thread safe either, so it feels unfair that it is not uglified by the warning :/
<civodul>scm_spawn_process *is* thread-safe, that’s the whole point
<civodul>it’s the only safe way to create new processes from a multi-threaded program
<graywolf>Btw, thanks for merging myu patches :)
<graywolf>Hm, but if one thread does putenv, and another does the spawn, where the spawn references environ, is that thread safe?
<graywolf>I should re-read the man pages
<graywolf>lloda: test-compare sounds reasonable, however I am not sure what `tol' is. (test-compare > 1 (1+ 1) <what-here?>)
<lloda>right
<lloda>i thought maybe (test-compare cmp a b) and a separate (test-compare-approximate cmp a b tol) for complex & the like
<graywolf>Ah, so `tol' is like epsilon, or acceptable error? I need to think about that the approximate variant would work. Gut feeling is not to have it, and let it to the user via custom cmp procedure.
<lloda>right, i'd be equivalent to (test-compare (lambda (a b) (<= (compare a b) tol) a b)), but this wouldn't show what the error is. It's the same reason test-approximate exists and not just test-assert
<lloda>anyway just test-compare would be good to have!
<graywolf>The custom compare procedure can put any properties it wants into test result properties using test-result-set!, that is documented part in SRFI-64. So it could just add the error itself.
<graywolf>Will try to send patch with test-compare later (not sure if today or tomorrow).
<lloda>hmm that sound good
<lloda>thx a lot!
<graywolf>I would recomment checking how test-approximate is implemented in the current version. Should give good idea how to do this.
<graywolf>All the tests are actually just using test-thunk with custom procedure for each of them.
<lloda>if within-epsion was (lambda (a b) (<= e (magnitude (- a b)))) then test-approximate would work with complex i think
<lloda>i realize the 'spec' says it takes reals and even gives a explicit def of the check... i'd say that's a defect in the spec
<lloda>+1 on using test-result-set! i'll try that
<lloda>i mean (<= (magnitude (- a b)) e) above ofc
<lloda>i'm not proposing this change tbc
<rlb>dsmith: hmm, wasn't paying attention and just msg'ed sneek a "later tell" rather than saying it here -- does that mean it'll reply here, or (guessing) privately?
<dsmith>rlb, In the past, it was in whatever channel the nick posts a message in. I don't think I ever updated that to the channel from the "later tall" command
<rlb>Oh, ok -- so if I msg'ed from here, it'll show up here? If so, then that's just fine, and thanks.
<dsmith>ACTION looks at the code...
<rlb>I mean it's fine in this case either way, so don't worry about it -- was just curious. Though if it's not going *anywhere* I'd want to try again :)
<dsmith>Nope, The message is delivered to the channel where the reciepient next posts a message
<rlb>Even some other channel? If so, interesting...
<dsmith>The channel isn't saved
<dsmith>Just the sender the recipient and the message
<dsmith>hey
<sneek>Welcome back dsmith, you have 1 message!
<sneek>dsmith, dsmith says: Some Message
<rlb>So it could show up in a different channel I'm not even in -- definitely interesting.
<dsmith>Yes
<dsmith>No. Only in a channel where the bot sees you send a message
<rlb>Sure, but that's a channel the *recipient* is in, not the sender -- i.e. iiuc interesting that it could show up in an unrelated channel, perhaps one I couldn't even post to, myself.
<rlb>(or one that was much more public than the original, etc.)
<rlb>Glad to know that, not that it's ever mattered for me :)
<dsmith>I think the logis there was if the recipeint jsut posted something, then they are active there and will see the message from the bot.
<dsmith>Back in the day, freenode used to have a message bot. I wonder if libera has one.
<dsmith>(Heh, right now there are 246 messages waiting to be delivered)
<rlb>Neither snow nor rain nor heat nor gloom of night...