IRC channel logs

2024-02-14.log

back to list of logs

<rlb>3.0.9 finally uploaded to debian
<dsmith>rlb, Wow! I didn't realize it was taking this long
<rlb>...I'd just been somewhat cyclically distracted/swamped, but now I have time.
<rlb>It'll probably take a good while to build on some of the architectures: https://buildd.debian.org/guile-3.0
<apteryx>jpoiret: thanks for the refined version; I was working on such a thing myself. nice to see the solution :-)
<apteryx>jpoiret: I'd leave 'id' singular in the syntax-case pattern, as unlike (ice-9 match), id ... doesn't become a list
<apteryx>it becomes multiple atoms
<old>rlb: I have a little look at the code, but no completely
<old>rlb: the access to t->exited in in scm_sys_join_thread is undefined behavior. Although on strong ordered architecture it works
<old>I would do the load atomicaly with a RELAXED memory ordering and the store with RELAXED also
<old>there are faster pattern for fast wake-up synchornization that does not involve pthread thing. See URCU-wait: https://github.com/urcu/userspace-rcu/blob/master/src/urcu-wait.h
<old>But that would be overkill for join-thread I believe
<old>Note also that if you do a store RELEASE on t->exit _after_ storing non-atomically t->result, you can do a load ACQUIRE on t->exit before loading non-atomically t->result
<old>so the atomic operation can be done on the t->exit flag instead of the result
<apteryx>could we get this merged? https://lists.gnu.org/archive/html/guile-devel/2023-12/msg00003.html
<old>rlb: I'll have a look closer when I can
<apteryx>it's tiny, and useful
<old>apteryx: +1
<apteryx>it's part of R7RS small which is well specified here: https://small.r7rs.org/attachment/r7rs.pdf
<old>would be nice to have R7RS small fully supported
<apteryx>the first commits of https://lists.gnu.org/archive/html/guile-devel/2023-12/msg00003.html makes R7RS usable enough to drop-in R7RS SRFI libraries witOUt needing to tweak things
<apteryx>R7RS small is in actually a rather good shape already in Guile; there are just a few paper cuts I found in the define-library macro
<dthompson>guile fails a few of the r7rs benchmarks. among other things, 'equal?' doesn't seem compliant
<apteryx>I see
<apteryx>it doesn't strike me as a show stopper for actual use :-)
<apteryx>but it'd be nice to be compliant
<old>eeh just saw this define-library from r7rs
<old>library really need to be defined under (begin which is under (define-library?
<old>I see that it is possible to include the file instead ..
<old>kind of weird
<old>Guile modules are far supperior if that's the case
<janneke>bah, /me gets a constant error message
<janneke>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<janneke>merge-lists: Inconsistent precedence graph
<rlb>old: ahh, thanks - I'd actually used some atomics.h operations (e.g. store/load) in a previous formulation that was less pthread-centric... And regarding exited, I assume you mean the "fast path", and if so, yeah -- I'd thought about making that atomic, though iirc I noticed we weren't previously, didn't have the right atomics wrapped yet, and I assumed that worst case, we'd just fall through to the slow path. But more than happy to
<rlb>make it stricter if we like.
<rlb>old: Oh, and thanks for the review (sounds like you're more experienced than I am on this front). While I understand the general principles wrt acquire/release semantics, etc., I've mostly worked with higher level, blunter primitives :)
<old>rlb: It will be a pleasure for me to do a more extensive review whenever I have time (maybe next week ^^)
<old>rlb: I've worked recently on Userspace-RCU to add support for compiler atomic builtins and TSAN annotation because URCU use a memory model close to the Linux kernel one and not the C memory model
<old>rlb: anyhow, I'm very familiar with this topic and would be more than happy to help reviewing :-)
<rlb>excellent
<sneek>tohoyn: Greetings!!
<tohoyn>sneek: botsnack
<sneek>:)
<apteryx>jpoiret: interesting, the Guix API containing syntax means that an application using it cannot "link" to it lazily (at run time), unless byte compiled files are not provided. Does this make sense?
<apteryx>when providing byte compiled files, the Guix support must be determined as available or not at build time.
<apteryx>old: what is weird about define-library? I find it more flexible/elegant than Guile's define-module
<apteryx>here's a recent example, where I made use of its expand-cond feature: https://paste.centos.org/view/bf5a31a3
<apteryx>err, cond-expand*
<cow_2001>daviid: looking at your guile-cv now :|
<cow_2001>(manual)
<jpoiret>apteryx: well, for macros yes, that's an unfortunate side-effect
<old>apteryx: I though everything was needed to be defined under a nested (begin) form
<old>which would have been ugly
<old>like C++ namespace. Everything indented by one level because of scoping
<daviid>cow_2001: oh, nice - please make sure to read 'how to configure guile for guile-cv', otherwise any example, even using small images, will blow your terminal or explode your emacs ... after you do that, guile-cv is very easy to use ... feedback welcome ...