IRC channel logs
2025-07-11.log
back to list of logs
<AwesomeA1am54321>For context, I have a simple turn-based IRC game bot that expects blocking input a la `readline`, but IRC messages are async <ttz>mwette: some follow-up on the inner-product topic you helped me with the other day in case you're interested: I realized the fold I was using didn't allow the compiler to inline the lammbda, even though the fold was a macro... removing it gave me a x3-x4 speedup (and less memory pressure since it was not allocated anymore) and brought Guile to a factor 5 of Rust! <mwette>ttz: thanks for the update; that's impressive <sneek>mwette, lechner says: / nvm, i'll go with hash tables for now <janneke>ACTION has a multiple values puzzle/question; this works... <janneke>(let ((foo bar (or (values #f #f) (values 0 1)))) (pk "foo=" foo)) <janneke>(let ((foo bar (or (values #f #f) (values 0 1) (values 'this 'breaks)))) (pk "foo=" foo)) <janneke>;; Wrong number of values returned to continuation (expected 2) <dthompson>without using 'or', that code above is essentially: (if (values #f #f) #f (if (values 0 1) 0 (values 'this 'breaks))) <dthompson>only the first return value is being considered <janneke>ACTION will have to roll their own then, if this is not considered a bug <dthompson>guile will silently drop excess values but throw an error when there are too few values. <dthompson>should the former be an error, too? some think yes, others no. <dthompson>I'm grateful that scheme has them but they leave something to be desired... <ttz>It seems (hash <f32vector> <some-integer>) always returns the same value. this makes storing floating-point vectors in a hash-table linear time (which is how I realized it). I don't think this is an expected behavior, since clearly such two different vectors are not equal? <ttz>(equal? (f32vector 1.) (f32vector 2.)) ; => #f <ttz>(equal? (hash (f32vector 1.) most-positive-fixnum) (hash (f32vector 2.) most-positive-fixnum)) ; => #t <ttz>same fo f64vector, but not for vector. <dthompson>oof that is bad. generalizing a bit, this must be the case for any bytevector <dthompson>guile's hashing code really needs updating. I have found other issues with it in the past. <dthompson>we should switch to a seeded hash algorithm to prevent hash flooding attacks, fix the bug above, and also fix hash composition so that it isn't commutative <ttz>yes indeed, it seems SipHash is the standard nowadays <ttz>which algorithm is Guile using ? <dthompson>I looked into siphash but idk it has some poor performance characteristics <ttz>Yes it does, and I think it is the default in Rust. <dthompson>I'm no expert, though. would like to settle on something and then use it for both guile and hoot. hoot is using a mixture of hash functions depending on the data type (murmur3 for bytevectors) but none are seeded. <dthompson>a global seed generated at boot time is all we need. v8 got into trouble with this approach but that's because they boot from an image. guile doesn't. <ttz>Well, SipHash has been designed by Aumasson and Bernstein so it must be secure against hash flooding. I don't know what are xxHash guarantees about it. <ttz>I am not sure it is only about the seed <dthompson>"xxHash has been tested with Austin Appleby's excellent SMHasher test suite, and passes all tests, ensuring reasonable quality levels. It also passes extended tests from newer forks of SMHasher, featuring additional scenarios and conditions." <ttz>Being designed to produce uniform output on some data is different from being designed to prevent collisions on malicious data. <ttz>Sure, and I am just giving some advice, in case you were the one to make the final choice (I work in cryptography, so I have some basics). <ttz>Should I fill an issue somewhere to "officially" report the bug? <identity>dthompson: the hare programming language comes with 2 hash functions in the standard library, SipHash for untrusted hash map keys and Fowler–Noll–Vo for trusted hash map keys <mwette>janneke: maybe cond will work, and with that you can use a procedure to map values to which one you care about <mwette>is codeberg.org/guile/guile accepting issues? <mwette>(cond ((values 1 2) (lambda (x y) x) => (lambda args (apply values args)))) <janneke>mwette: my or-values works nicely, but thanks <rlb>ArneBab: I wondered, if we're going to have a 4.0 soonish, if we might even want to consider making auto compilation quiet by default. Guile seems a bit noisy there compared to other languages. Perhaps along with stopping/crashing at the first compilation failure for a given request. <dthompson>ttz: you should file a bug. no idea if it has already been reported because searching debbugs is terrible and the issues haven't been migrated to codeberg yet. <dthompson>adopting siphash sounds fine to me if xxhash is not secure enough <rlb>Keywords were broken until after 3.0.0 (always same hash) 8b3cad618314f02ad3921fa104f17ca0f721dfcb, and a few string related bugs have also been fixed more recently fwiw. <rlb>(Some (all?) of the latter can be seen via "git log libguile/hash.c".) We also only "sample" the data (of course) for the has for "trees", etc., which might affect a given use. <ArneBab>rlb: if we do such changes to defaults, we should have a larger vision how Guile is expected to behave <ekaitz>also I have a couple of documentation patches that are not reviewed and are pretty easy to add <rlb>ArneBab: that's what reminded me (your patch) -- and I also vaguely wondered whether there might be some broader approach to verbosity we might want, but have thought no further :) <rlb>My main concern is still just with respect to having a broken newer .scm file with an important fix cause guile to fall back and run stale .go code that's not fixed instead of halting (e.g. a security fix). <rlb>Hence wanting to just halt by default on the first failure. <ArneBab>Doesn’t it fall back to the interpreter? <rlb>Not sure -- I thought I saw it doing what I described, but maybe I was mistaken. <rlb>And it may be more complicated than that given .scm vs .go vs "paths". <ArneBab>I’m also not sure. What I did see is macros in dependencies not taken up <rlb>Oh, if you mean tracking macro-related deps, well that's a whole other level :) Definitely not asking for that atm. <rlb>(Most of the lisp-ish platforms I've messed with don't go that far iirc.) <ArneBab>It’s a problem usually solved via Makefile <rlb>Not that that proscribes anything. <rlb>Thinking further about it -- first I should just create a simple example of the situation I'm concerned about. That'll make sure I'm not off in the weeds. <rlb>ACTION will plan to do that later. <ArneBab>rlb: aside: one reason I wish for GUILE_QUIET to land is that I require that for the source block output export of my website, and I’ve been locally installing a patched version for too many months now. <rlb>No strong opinions there -- just wondered about that vs say a --quiet vs ... e.g. is GUILE_QUIET a broader concept, and if so, what should it cover? May not be important, just wondered... <identity>ArneBab: i think that goes to stderr, can you not just discard it? <rlb>Also of course the evergreen "vebosity level" vs "log levels (trace/debug/info/warn/error)" competitors... <ArneBab>identity: GUILE_QUIET silences the info port which also includes the startup message. <ArneBab>rlb: in my minds eye, GUILE_QUIET silenses all messages except for the ones the application adds. <rlb>Not arguing for either atm, but would something else like say a --quiet also work for your case? <ArneBab>--quiet has to be set for each call, but I actually want to toggle quiet for the process that spawns it without having to do process-level changes. My use-case is that I want my Emacs to run it quiet when I start it to export my website without having to tinker with configurations. <jfred>If anyone here is familiar with guile-config, I'm having a bit of trouble with something... I'm trying to define a subcommand that contains switches specific to that subcommand. How does one access options specific to that subcommand? The docs only seem to show a subcommand whose options are all inherited from the root config <rlb>ArneBab: ahh ok, so whatever happens, you'd want an envt var. <ArneBab>yes -- that’s the best match to the usecase. <ArneBab>And it really is distinct from --quiet and putting something into ~/.guile <jfred>(code snippet of what I've got so far; I know that the `options` I'm passing into `start-boss` is for the root config which isn't quite what I want: https://bpa.st/ROQQ) <ArneBab>jfred: sadly no experience, but I think I’ll have to get experience :-) <jfred>I'm only just trying it out but it seems very nice so far! I'm just stuck on this one thing, haha <jfred>worst case I could make the two parts of my program two separate scripts, but doing them as subcommands feels pretty clean if I can get at the subcommand-specific config somehow <jfred>ArneBab: good idea, will do! <mwette>Currently, the compiler messages go to the info port, by default stderr. The "welcome" message, to be silenced by GUILE_QUIET, goes to stdout; guile's 00-repl-server.test depends on the welcome message going to stdout.