IRC channel logs

<jj>i have a little guile library i'd like to make usable by other people. what are the best practices for 1) packaging and 2) documentation?

<jcowan>The best practice for documentation is to write it!

<daviid>jj: most of us use the autotool chain, and for the doc, we write using texinfo - you may look at some projects to get started ... and ask here for some help ...

<JohnCowan>daviid: What purpose does autotools serve if you are writung in guile?

<daviid>JohnCowan: it is the best tool to make a lib/app available to others, no matter what lang it's written in, imo anyway

<shawnw>If writing a C program that embeds guile, or a C library meant to be loaded in guile, autotools are useful (Especially autoconf)

<jcowan>Sure. But I would understand jj to mean a library written entirely in Guile.

<jcowan>In which case there is nothing to configure.

<jcowan>It's not like there are a bunch of slightly different variants of guile.

<shawnw>Gotta figure out where to install files.

<rlb>old: I was wrong (hadn't actually checked) --- it's not web*.test that's slowing down the tests (and acting as a long pole wrt parallelization), it's (at least) srfi-42.test, and it looks like it's really just the (erastosthenes 100000) call in there.

<rlb>Without that srfi-42.test takes about half a second. With it, it takes 15.

<rlb>Do we actually need to test a value that large?

<rlb>(That one call is a good chunk of the entire "make check" run time when running in parallel.)

<rlb>Also got a notable speedup by moving threads.test to the top --- I knew it had a number of notable sleeps in there, but didn't follow that to the obvious conclusion. Here, that and leaving out that one srfi-42.test call takes "make -j5 check" time from ~45s to 25.

<lloda>yay

<old>I don't know what that test it hm

<old>s/it/is

<old>wrt to threads.test with sleep?? that sounds like fragile synchronization to me?

<yarl>hi

<mwette>I'm trying the networking example in the manual https://www.gnu.org/software/guile/manual/html_node/Internet-Socket-Examples.html and running into this: when the server closes the connection the client gets an exception (fport_read: Connection reset by peer) instead of an eof-object. There seems to be a disconnect between the example coding and the behavior. Which side is off?

<rlb>old: wrt threads.test, might well be that it could be improved/acellerated, but for now I'll ad a pending patch that moves threads.test near the top of TESTS.

<rlb>And wrt srfi-42.test, unless that larger erastothenes call is really important to the test somehow, I think we should reduce or remove it. I haven't learned/used eager comprehensions yet, so no idea offhand, but I vaguely suspect the test just picked "a large value" incidentally.

<rlb>...and if so, that's a waste of power/time as often as I've been running the suite lately ;)

<jcowan>Something must be seriously wrong: the time complexity of the sieve is O(n log(log n)), which is just barely above linear.

<jcowan>A modern CPU should just be tearing through it.

<rlb>no idea; I barely looked at it. Just got suspicious when I saw the "large value" and so tried commenting it out.

<old>rlb: Would need to check the test, but sounds like GC to me ?

<rlb>dunno, but if that large value isn't actually relevant to "testing srfi-42", then we can also just reduce/remove it.

<rlb>If someone already knows that, great. If not, then I suppose we'll have to delve.

<dsmith>rlb, Guessing it's in there because the srfi has that as an example?

<rlb>sounds likely

IRC channel logs

2026-04-24.log