IRC channel logs

<graywolf>Does Guile still take patches on the mailing list or is it codeberg only now?

<old>graywolf: as you wish but I prefer on codeberg

<old>(I tend to review things on codeberg faster)

<apteryx>where is it explained in the guile ref manual that [:character-class-name:] can be used inside regexps, e.g. [[:graphic:]]+ ?

<apteryx>I see loose references to libc, which only documents the likes of isblank

<apteryx>looks like an undocumented feature

<apteryx>is there a handy (ice-9 format) construct to insert a constant (held in a variable) into an iteration form, e.g. (format #f ~{$my-constant ~a~} some-list)

<apteryx>ACTION reads about ~_

<apteryx>oh, variable parameter, 'v'

<apteryx>ah no, that's useful to take a width as an argument to format, e.g. (format #f "~v_" 4) -> " "

<apteryx>the context: https://paste.guixotic.coop/gnome-362903-363460.scm.html, if you'd like to crack the puzzle of finding an elegant (ice-9 format) solution to that

<rlb>apteryx: I believe right now we're "whatever the platform regcomp does, so for linux regex(7), basically "posix", so this also applies https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09 and does mention classes in 9.3.5, but not graphic as far as I see.

<apteryx>rlb: thanks, I had forgotten that the [:class-name:] was a BRE standard rather than some Guile specific. Perhaps we could point to reference users wanting to learn more about regexps to (info "(sed) Character Classes and Bracket Expressions"), which is about the most complete and Texinfo available regexp documentation I've found.

<old>So I have some weird behavior wrt the signal delivery thread when forking

<old>I sometime end up with a abort in the post-fork phase checking that the signal delivery state is indeed STOPPED

<old>but it is in the STOPPING phase

<old>that's unexpected :/

<rlb>old: not sure exactly what you're describing, but if we're checking to be sure a thread has stopped after the fork, that's too late, unless it's just a double-check? i.e. I'd assume we have to be certain it's stopped before we fork, if that matters.

<old>it's a state check

<old>the pre-fork will stop the thread and the state should be stopped

<old>and post-fork ensure the state is stopped and create the thread again

<rlb>OK, right. Does the pre-fork ensure it's stopped before proceeding, or just initiate it?

<rlb>ACTION goes to find it...

<rlb>So now that I look, did you mean that you think you're seeing that abort in stop_signal_delivery_thread? i.e. that's what you meant by "stopping" rather than stopped?

<rlb>And if so, perhaps you could annotate signal_delivery_thread with fprintfs, or assignments to some temp diagnostic state variable to figure out where it's dying before reaching the STOPPED assignment...

<old>rlb: I am adding more abort check between state transition

<old>something is odd

<Arsen>hmm, haunt 0.4.0 apparently exists but I don't see a tarball

<rlb>old: sounds good. Imagine you thought about this, but to find out where it is could also just create a static global int, and assign 0, 1, 2, 3, ... to it at various points in signal_delivery_thread, and then when you hit the "signal_delivery_thread_state != STOPPED" situation, print the value, and you'll know something about where the signal thread was when it died.

<rlb>plus or minus inter-thread visiblity questions wrt the assignments...

<rlb>but if you make the integer atomic...

<rlb>(well, depending on how I suppose)

IRC channel logs

2026-08-30.log