<ajarara>hello guile! Is there a syntax for defining lambdas that ignore their arguments? (lambda* (#:allow-other-keys), (lambda (_ . _), (lambda* () don't work <ajarara>I guess I could hack it with (match-lambda ((_ <lilyp>ajarara: if you want to return a constant you can also use const <manumanumanu>I have been removing ugly macros to ensure cross-module inlining for a personal project (with only personal use) since updating to 3.0.8 <manumanumanu>and I actually got a speed increase in another piece of the code, probably due to cross-module-inlining and some kind of type check removal <manumanumanu>of about 5%, which translates to about 2s in the actual real world. <lilyp>Speaking of cross-module inlining, is it true that define-inlinable now does more harm than good in that respect? <lilyp>(Given that the inliner should detect simple function calls and inline them) <manumanumanu>but renaming it is not an option, of course. Documentation should maybe be clarified <manumanumanu>I am probably going to stop using it, though. Most of my uses have been rendered useless by declarative modules and CMI. <stis>I have found the vector extension in gcc really wonderful. clocks now at 10G elemetns/s when scaanning an assoc for a match <stis>assuming precompiled hash values <stis>so if it can gccc makes use of SIMD instructutions in the CPU ***rgherdt_ is now known as rgherdt
<conjunctive>Hi, I noticed guile does not include srfi-113 support. Does the language bundle similar functionality (unique collections type)? <lilyp>conjunctive: you can treat lists as sets using the lset-* functions from srfi 1 <lilyp>of course srfis are meant to be implemented, so if lsets are too slow you might want to roll your own and share it with others :) <conjunctive>Out of curiosity: I noticed that Guix has a less restrictive contribution policy (no paperwork (?), legal name requirement, etc). Is it a possibility for Guile to adopt something similarly? <lilyp>I'm not in a position to decide this, but I don't think it'd be wise to do so. <lilyp>Guix is under the GPL, so it doesn't matter too much that the license can't be changed easily. <lilyp>For Guile, which is under the LGPL, that does matter imo. <conjunctive>Interesting, thank you for pointing out the difference in licensing. <sneek>From what I understand, stis is a wizard <rlb>wingo civodul etc.: if you get a chance, could you take a look at https://debbugs.gnu.org/45214 It proposes adding "-Oresolve-primitives -Ocps" to GUILE_OPTIMIZATIONS in bootstrap/ <rlb>Makefile.am on 32-bit (not sure if it's BE-only) architectures to fix a build crash. I'm leaning toward including it in debian's 3.0.8-1. <rlb>currently affects guix powerpc, and debian m68, powerpc, hppa, etc. <rlb>iirc it may not be (easily) possible to do a numeric comparison there... <rlb>What's the relationship between bootstrap/Makefile.am and stage0/Makefile.am? <rlb>(Oh, and that paste won't work -- switched to an AM_CONDITIONAL to satisfy automake's simpler if/else requirements.) <civodul>rlb: sorry, haven't had a chance to look into it yet <sneek>Welcome back civodul, you have 4 messages! <sneek>civodul, lilyp says: re racket I'm only doing review on a machine without commit access atm. This shouldn't be an issue, because I'll have more time next week to apply them, but someone else could take over if it falls into my office hours <sneek>civodul, lilyp says: i don't think v2 can be pushed as-is, but I expect v3 can. If you disagree and say v2 is fine, though, I'm not going to gatekeep. <sneek>civodul, vivien says: my gcrypt ECC problem was because I did not set the rfc6979 flag in the data sexp, and I used "dsa" as a signature type instead of the expected "ecdsa" <sneek>civodul, apteryx says: after experimenting with the original idea, relying on a version field was easier and cleaner; I was able to also rename the --system, --load and --repl initrd options: https://issues.guix.gnu.org/40998#5 *civodul is back from vacation <lilyp>re racket, it's almost done :) <lilyp>after some back and forth, the patches have been much simplified, so I feel a little more comfortable now <rlb>fwiw, I've come up with a more flexible AM_CONDITIONAL based patch, assuming we decide that those GUILE_OPTIMIZATIONS are plausible for now for 32-bit BE. I'm going to upload 3.0.8-1 without the patch so that they can re-test the new version. Also, since the bootstrap process has changed, we'll need to figure out which of the new Makfile.ams need the adjustment (i.e bootstrap vs stage{0,1,2}). <lilyp>the only thing that's keeping me from pushing v6 is a minor cosmetic issue that I could fix on my own, but I'm currently busy with other stuff and waiting whether Philip sees this the same way I do <lilyp>guix topic that sneek carried here <rlb>guile-3.0 3.0.8-1 has been uploaded to debian unstable.