IRC channel logs

<euouae>Although I go to church I shouldn't pretend that I know a lot about psalms and chants and the music theory behind them

<euouae>my nick does not refer to something I'm knowledgeable about

<ieure>Same (my nick is my name)

<dsmith>!nickometer euouae

<sneek>"euouae" is 0% lame

<dsmith>!nickometer ieure

<sneek>"ieure" is 0% lame

<dsmith>!nickometer unknown_lamer

<sneek>"unknown_lamer" is 68.71% lame, because matched special case /lame/, 1 extraneous symbol

<Noisytoot>!nickometer Noisytoot

<sneek>"Noisytoot" is 0% lame

<Noisytoot>!nickometer [

<sneek>"[" is 15.66% lame, because 1 unbalanced bracket, 1 extraneous symbol

<sneek>Welcome back ArneBab!!

<rlb>euouae: regarding pr 14, I'm not sure about that one -- if api-control.texl is supposed to match the source (?) then whether he meant to or not, Andy didn't actually change the argument type in throw.h.

<rlb>"api-control.texi"

<euouae>rlb: <https://codeberg.org/guile/guile/pulls/14>?

<rlb>sorry, I meant 12

<rlb>and for scm_c_catch (haven't checked the others yet)

<euouae>Right, 12, so what exactly do you mean? I did not understand, what argument type is not changed?

<euouae>scm_t_catch_body is changed to scm_t_thunk

<rlb>Look in main at libguile/throw.h

<rlb>at scm_c_catch

<euouae>that's a mistake

<euouae>he typedef'd one type to the other, so they are equivalent, but the definition (throw.c) and the declaration (throw.h) are incognruent

<euouae>so yeah that needs to be corrected, he means scm_t_thunk in throw.h

<euouae>I'll add an addendum to the patch

<rlb>It might be, but if api-control.texi is supposed to match the code (don't know), then we shouldn't change it without changing both.

<rlb>And ideally, I'd prefer for Andy to tell us it's a mistake

<rlb>(I suspect you're right.)

<euouae>I'll put the addendum in anyway so that it's there

<rlb>sounds good

<euouae>I'll probably do it a bit later to go more carefully over all the signatures, I think the others have the same issue

<rlb>sounds even better :)

<euouae>scm_t_thunk was introduced in f4ca107f7fe0b6f1ca2c03b558f16077fc89db04 in 2019 and scm_t_catch_body in 92c2555f6972b5fbc2236fe486e9432040b43812 in 2001 for what it's worth

<euouae>so I think we have the right order too

<rlb>yep - I was looking at the former, I think.

<rlb>and it's probably fine regardless, since I think scm_t_thunk is defined as exactly the same thing scm_t_catch_body was.

<euouae>yes; and now I'm wondering if I should replace scm_t_catch_body in every file or just throw.h

<euouae>IDK, maybe it's best to get input first

<euouae>I'll just write a comment in PR 12

<rlb>dsmith: imagine we should have a bug for https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282534 -- would you like to file it, or should I plan to?

<dsmith>rlb, Hah. Was just reading the config.ac for that.

<dsmith>rlb, How about you file it.. it will have more.. somthing

<ekaitz>hi! how does (eval-when (expand compile) (...)) work if it's not added in the global scope?

<rlb>Sure --- it'll definitely have "something" (whether we want it or not is another question) ;)

<ekaitz>!nickometer ekaitz

<sneek>"ekaitz" is 0% lame

<ekaitz>ACTION is relieved he doesn't need to make the paperwork for name change

<identity>!nickometer identity

<sneek>"identity" is 0% lame

<identity>yay!

<dsmith>The nickometer is from the dpkg bot that was in freenode #debian 20 years or so ago. People have nicks like --<<!!>>-- or something

<dsmith>!nickometer --<<!!>--

<sneek>"--<<!!>--" is 99.98% lame, because 9 consecutive non-alphas, 5 extraneous symbols

<identity>ekaitz: i assume it works the same way?

<ekaitz>hm!

<ekaitz>identity: i don't know what to say

<dsmith>Thought it would be fun to have around. But most people don't use lame nicks here

<ekaitz>i'm trying and it looks like it's just removed...?

<identity>!nickometer ʙᴏʙ

<sneek>"ʙᴏʙ" is 97.05% lame, because 3 consecutive non-alphas, 3 extraneous symbols

<identity>i guess that works

<ekaitz>!nickometer Борис

<sneek>"Борис" is 99.93% lame, because 5 consecutive non-alphas, 5 extraneous symbols

<ekaitz>okay it's racist. Great.

<ekaitz>identity: my question goes more around something crazy like (define (f a) (eval-when (...) (something a)) (more-to a))

<ekaitz>the eval-when wouldn't know what `a` is, right?

<identity>it does not seem to care about that, for some reason

<ekaitz>so... it might just don't do it?

<ekaitz>I'm not asking just out of curiosity, i'm trying to implement this for GNU Mes

<ekaitz>and i'm starting to realize this has a lot of weird corner cases I can't even imagine

<ekaitz>hmmm

<ekaitz>the (eval-when (eval) whatever) => whatever during macro expansion

<ekaitz>so that's reasonable

<ekaitz>maybe I'm overthinking this?

<identity>it seems ‘eval-when’ does not actually ‘eval-when’ apart from ‘eval’

<identity>inside of bodies, that is

<ekaitz>and what if we define a macro inside of that eval-when?

<ekaitz>nah, it just ignores

<ekaitz>macros can only be in top level

<ekaitz>great

<ekaitz>thank god

<dsmith>Pretty sure the bot only knows ascii

<dsmith>So non-7bit utf-8 chars are probably extra-lame

<ekaitz>dsmith: and that is a shame

<dsmith>Indeed

<dsmith>But irc has (or had) some limitaions on what can be used as a nick. The non-alpha chars allowed were some nordic chars in some encoding, IIRC

<old>!nickometer old

<sneek>"old" is 0% lame

<old>sneek: botsnack

<sneek>:)

<dsmith>!nickometer [

<sneek>"[" is 15.66% lame, because 1 unbalanced bracket, 1 extraneous symbol

<dsmith>Only 15% ?

<old>!nickometer sneek

<sneek>"sneek" is 0% lame

<sneek>ACTION grins sheepishly

<dsmith>Valid nick chars in rfc2812: a-zA-Z0-9 and []\`_^{|}

<dsmith>The freebsd date command has different args than gnu date.

<dsmith>Would would be better, test for *bsd and use different args, or depend on gdate being installed?

<dsmith>gnu: date -u -d @xxxxx +'timespec'

<dsmith>bsdL date -j -u -r xxxxx +'timespec'

<dsmith>Where 'xxxxx' is seconds-since-the epoch

<dsmith>s/bsdL/bsd:

<rlb>I suppose I'd probably favor detection, so that we don't have to deal with gdate vs date?

<rlb>(or requiring gnu date to be *the* "date" in the path for guile)

<rlb>i.e. prefer detecting so we avoid those issues maybe?

<dsmith>Already need to use gm4 and gmake,

<rlb>Do we already have some place for compat wrappers?

<rlb>Or maybe autoconfery-wise, that'd better just be some substitution? Dunno.

<dsmith>I'm leaning toward some check for what args /usr/bin/date supports, and conditionally use one set of args or the other.

<dsmith>There is also some sed differences.

<rlb>yep

<dsmith>The best would be some compatible set of args.

<rlb>right -- maybe in some cases we can rework to a common (posix) subset...

<rlb> https://codeberg.org/bup/bup/src/branch/main/dev/checksum :)

<rlb>e.g.

<rlb>wrt papering over *bsd vs linux, etc.

<rlb>or simpler https://codeberg.org/bup/bup/src/branch/main/dev/sort-z

<dsmith>`date --version` is probably a reliable check for gnu date

<dsmith>fbsd date doesn't support that

<rlb>Might also be able to just run an actual command an if that fails, try the other -- not sure if that'd be preferable.

<rlb>"and of"

<rlb>"and if"

<rlb>(Though of course only if we think the commands would be "safe everywhere", even when wrong.)

<dsmith>Hey. It worked.

<rlb>nice

<dsmith>or maybe not...

<dsmith>Works

<dsmith>In configure.ac: AM_CONDITIONAL([GNU_DATE], [date --version >/dev/null 2>/dev/null])

<dsmith>And then in libguile/Makefile.am have an `if GNU_DATE` and use the two different date command args.

<dsmith>Inspired by MINGW_LIBPATH

<dsmith>Need to test all that on Linux..

<dsmith>Wooo! make check passes on Linux too.

<dsmith>rlb, So I'm planning on submitting one or more PRs. Wondering how fine grained they should be.

<dsmith>Should all the *.test be in one, or for each .test file?

<rlb>dsmith: not sure I follow exactly -- ideally (but not categorically) have semantically distinct commits with the tests for the changes in each relevant commit, but might not be as important (to me) whether there's one pr or multiple, unless we think there's a notable chance certain commits might not make it for now.

<rlb>(Or maybe everything goes together well enough to all go in one commit...)

<rlb>Does that help?

<rlb>ACTION may be away in a bit

<dsmith>Yes

<rlb>And if you're up for it, there are the changelog headers (still required I think?) and maybe NEWS (if it's "user visible" fsvo "user"), but I can also add those if I'm the one that reviews/merges.

<rlb>(I tend to just look back at some recent commits, e.g. Ludovic's or Andy's for reference.)

<dsmith>Yes. Looking back at other commits. Been a while.

<dsmith>ISTR there used to be a magit command that auto-generated a changlog entry.

<dsmith>Filled in the '* filename (function):` bit

<dsmith>Ok. Sammple PR created. Woo.

<dsmith>Bah. A changed sed command sneaked in there too..

<rlb>...there may also be some tooling in the tree, but I'm not very familiar with it (and have forgotten)

<rlb>bbl

IRC channel logs

2025-09-17.log