IRC channel logs

<rlb>mwette: I just saw that recently too, and I haven't had a chance to figure out what it's on about. It's "just" a warning though? If so, did it work otherwise?

<rlb>(...and if not, what's the show stopper?)

<mwette>rlb: I couldn't tell, and I commented it out just in case. I wanted to get a build first.

<rlb>I don't think that caused an error for me, just a warning, but I can double-check in a bit.

<rlb>yeah, I see it, but I suspect you can just ignore it for now -- doesn't interfere with the tests passing, anyway.

<rlb>mwette: ok, it's rebased on current main now - https://codeberg.org/rlb/guile/src/branch/utf8

<rlb>(...recursive make issues yet again.)

<rlb>...I *think* I wish we had non-recursive Makefile.am rules where it's feasible, i.e. for libguile, modules, etc. I suspect that would make some of the hacks we have (around say guile-procedures.*) go away.

<rlb>OK, *now* I think I have a fix for the guile-procedures.txt test dependency issue. I'll plan to post a v2 patch tomorrow assuming this clean-tree build works.

<wingo>meep meep

<wingo>am i hearing we need a 3.0.11 followup

<Harzilein>ahoy wingo

<janneke>my daughter is doing simply-scheme and asked my why these work; i don't have an answer other than "i think this is a bug"

<janneke>scheme@(guile-user)> (* 'foo)

<janneke>$1 = foo

<janneke>scheme@(guile-user)> (* 1 'foo)

<janneke>$2 = foo

<janneke>actually, her question was, why can i do (* 1 <word>) but not (* 3 <word>)

<janneke>(fwiw, gnu mes throws 'not-a-number exceptions on these...)

<rlb>wingo: I think so, though (from my perspective), I'd say we want to figure this out first: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71891

<rlb>wingo: I have some fixes for all the other bits I found that I posted to the list (though I have a fixed version of the BUILT_SOURCES fix in there that I'm still working on :) -- should post a revision today).

<rlb>janneke: without looking, I'd assume it's an optimization somewhere, i.e. (* 1 anything) => 1. Whether or not that's what we *always* want...

<janneke>rlb: okay, yeah -- possibly not priority #1

<rlb>I'd imagine it could be in numbers.c or in the compiler, if so.

<janneke>...but it doesn't really help newcomers

<old>I think (* 1 SOMETHING) is optimized to (identity SOMETHING) ?

<old>because it also works with string literal

<old>actually, mul is called in: (define (foo x) (* 1 x))

<old>that's interesting

<old>even: (define (foo x y) (* x y)) works

<old>(foo 1 "foo") => "foo"

<old>I assume there is a quick path somewhere in guile that does: if (IS_ONE(x)) return y; if (IS_ONE(y)) return x;

<rlb>(If the goal is to have it always *fully* optimize, even if we don't know the type until runtime, then I could imagine putting the more aggressive behavior behind an optimization level, or something... If it should still be an error no matter what, then maybe a faster identity-if-number rewriting.)

<rlb>(i.e. a faster helper, but not just identity)

<rlb>dunno

<rlb>It'd be nicer if "make dist" would work from a clean tree, but offhand, I don't see any easy way for us to do that.

<rlb>ACTION will let that go for now

<old>what is weird this does not work with 0

<janneke>ACTION tried to explain that guile (scheme) has strong typing, but not static typing...and then this

<janneke>the universe can be cruel sometimes ;)

<old>janneke: check libguile/numbers.c:5330

<old>at least here on my tree source

<old> https://paste.sr.ht/~old/f3d80504ff5d1b17a847ec9a77f36245f0d074c7

<old>that is what I predicted

<janneke>old: thanks

<janneke> /* This is pretty gross! But (* 1 X) is apparently X in Guile, for

<janneke> any type of X, even a pair. */

<janneke>so, it's not a bug, it's a feature? -- yuck!

<rlb>janneke: Well now you have an excellent segue into a discussion about how guile's special in that if she ever wanted to, she could help sort all that out? :)

<janneke>(not even an optimalization?)

<old>janneke: well a runtime optimization not compile time

<janneke>rlb: beautiful perspective!

<dthompson>that optimization surprises me. I would expect it to do that. guile does not optimize (+ 0 'foo) to 'foo

<old>ask wingo: 9179525a058affd702971a0dd57926acabd5d0cb

<rlb>Guessing the precedent there is ancient.

<rlb>Do we prefer a patch series v2 to be --in-reply-to the original cover letter, or a new thread on guile-devel? (If there's an established convention.)

<Harzilein>ACTION won't segway into discussions, risk of accidents is too high :3

<rlb>Hah -- if nothing else I'll assume a new v2 thread is the safest default.

<dthompson>oops, I meant to say "I *wouldn't* expect it to do that" back there

<rlb>ACTION assumed :)

<rlb>wingo: OK, sent the v2 series

<rlb>(fixes)

<ArneBab>rlb: which xkcd is that? (I only managed to add Bobby Tables into our tests at work ☺)

<rlb> https://xkcd.com/378/

<ArneBab>rlb: Python3’s split of bytes and strings broke a lot of Mercurial extensions, because forced explicit conversion between bytes and strings makes a lot of problems when you do high-performance work at the interface between filesystem, internet, and commandline-UI.

<rlb>All told, I believe I spent many solid weeks (maybe months) off and on dealing with that wrt bup, so I'm very much not a fan.

<rlb>At least they finally conceded more or less, it seems, but much to late to save forcing all that wasted work.

<rlb>"too late"

<ArneBab>I had to port Mercurial extensions — it’s really, really painful, and I hope I’ll never experience something similar again.

<ArneBab>rlb: oh, nice, butterfly! That’s what that meant!

<rlb>For tools where it matters, I strongly recommend testing randomized byte values, i.e. for paths, users, groups. Speaking of which, I need to see if we can finally re-enable that testing in bup. For a good while python3 (in dispute with libc) would just crash on some argv strings...

<rlb> https://bugs.python.org/issue35883 fwiw

<ArneBab>rlb: I maintain the infocalypse extension which enables interaction with Mercurial repositories via decentralized Freenet/Hyphanet. I’m sure that there are bugs left that I just didn’t hit yet …

<ArneBab>If you receive a name via a self-parsed Web API that you need to use as path component on the filesystem and as UI output and also as content for files while other files contain raw bytes that may still be created *from* those names … *shudder*

<ArneBab>Mercurial couldn’t start to port before Python 3 finally enabled using u"..." (as no-op) so different language versions could be supported from the same codebase.

<rlb>Yeah, in many cases, the web stuff doesn't have a happy path for anything other than unicode. But even for tools like tar/cp/ls/find, it's not easy (or remotely standardized). i.e. git has core.quotePath, (gnu) ls has --quoting-style, etc.

<rlb>It's a difficult problem taken as a whole, and if you wanted to get it *right* would I suspect require a fairly complex standard of some sort.

<rlb>...git's quotePath encoding has the disadvantage, I'd say, of not requiring the double-quotes when the path includes spaces. With that, you'd be able to unambiguously read a path in a stream, when you know a path is coming next. Otherwise, it's a plausible "low-key" approach -- and you could always specify that *your* tool does double quote when there are spaces.

<cpli>has anyone written some wrapper for c-ffi out arguments? i.e. something along the lines of: (cut-c-out %f <> u64 <> `(* ,u64))

<cpli>which creates a lambda that takes two arguments and returns two values number? and (pointer? number?)

IRC channel logs

2024-07-03.log