IRC channel logs

<lloda>ekaitz: i'd use match for that

<ekaitz>lloda: yep! that I did!

<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

<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...

IRC channel logs

2024-10-21.log