IRC channel logs
2025-03-03.log
back to list of logs
<sneek>I've been aware for one month and 13 days <sneek>This system has been up 6 weeks, 1 day, 9 hours <rlb>I think we should add srfi-197 -- has it been proposed? <old>would it be possible to add custom conditions to `eval-when' ? <old>I really would love to have something like (eval-when (testing) (use-modules (srfi srfi-64)) (test-begin ...) ....)) <old>that I can put at the end of my modules for unit testing <old>I guess that I could do (eval-when (eval)) for this <fnat>Re Guile Haunt, is there any plan to potentially add any more readers as part of the repository? I think I'd generally like the idea of writing Org files, for instance. I see there's an Org reader developed by a third party, but it'd be nice to have an official Org reader, either in the main repo or in some sort of affiliated repository. <dariqq>hello, does someone know whether the cpu family is the only relevant option in the --target triplet of guild compile? Tried diferent os strings and always got the same resulting outfile? Or are there some edge cases where the os part matters? (trying to mkae cross compilation work without autotools/AC_CANONICAL_HOST) <rlb>dariqq: not sure about the broader question, but wrt the .go files, there should only be 4 flavors with respect to 32/64 bit and big/little endian. And hopefully we don't capure anything else arch-specific at compile time in the .scm code, though that'd be an interesting test to add if/when guile's fully reproducible (perhaps via a couple of vms). <freakingpenguin>If I have a procedure like (lambda* (#:key a #:rest b) (a b)), how can I remove #:a <value> from the rest list b? (guile) lambda* and define* only says this behavior is intended, but not what to do when it's undesirable. <freakingpenguin>Also how can I write wasm compiled via hoot's compile procedure to a file? <dariqq>rlb: great, thanks. was looking through (system base target) and found cpu-endianness and triplet-pointer-size. It seems to be deduced mostly via the cpu field but there are edge cases like x86_64-*-gnux32 <dariqq>bigger problem is crafting a correct enough gnu triplet from another completely incompatible system of describing a target machine <rlb>...If you're only concerned about go, then suppose you could pick 4 characteristic triplets, and just categorize everything as one of those, *if* your source info can easily provide endianness and width. <rlb>Though I'm not promising that'll always be "fine" :) <rlb>I *think* it may work atm, but not sure exactly what we promise. <rlb>Or, if you're not concerned about cross-compiling and you have a c compiler handy, as a hack you might just run a program to figure those values out, I suppose... <rlb>(e.g. trivial program to probe) <dariqq>rlb: I am currently trying to build my guile project with meson instead of autotools. I am definitly enjoying writing the build definition a lot more but there are some annoyances to make it fully compatible <rlb>I imagine you've poked around? I'd guess that meson might have some way to get similar info and/or someone might have already had to hack up some kind of "triplet adapter" or something... <rlb>But that's just a totally unfounded guess :) <dariqq>well yes, when you want to cross compile you need to pass an ini file specifying things like the cross cc , host os , endiannes, cpu, ... but converting this information to a close enough triplet is annoying. But good to know that I dont need to get it exactly right <rlb>dariqq: could you just keep config.guess in your repo (is it standalone?)? <rlb>i.e. and just run that to get the triplet you need <rlb>(it's not as big as I'd feared it might be...) <rlb>Oh, wait, that doesn't help if you're cross-compiling. <dariqq>rlb: exactly, for the native one i can jus ask guile with %host-type . I could just accept a triplet as a configure option and make it the problem of the person cross compiling but a bit overkill when meson has similar information in another format. Probably need to write a little script to convert it <rlb>Yeah, if meson knows the right info for the other platform, then I might just create an adapter to some "canonical" triples for now. <rlb>If we were willing to commit to it, I suppose guild compile could support an alternate specification of just the relevant values. <dariqq>i cant be the first person to have this problem of converting meson->triplet. Ill see if i can find and adapt someelses script. thanks for your help rlb