IRC channel logs
2024-10-05.log
back to list of logs
<rlb>graywolf: what's the broader goal? (And I suspect not from scm, but maybe via scm_gc_{enable,disable} in C -- would have to check.) <graywolf>rlb: I am writing a test to make sure that procedure using internally (pipe), therefore creating file ports, closes them <graywolf>however the tests sometimes (about 50% of time) still passes <graywolf>So I thought disabling the GC for the duration of tests would make the test deterministic <graywolf>Oh! scm_gc_disable leads by grepping to gc-disable <mwette>graywolf: you would make a guardian for those, I think <mwette>But that would require mod of code-under-test. never mind <graywolf>Ugh... I thought (sort! lst proc) should be basically equivalent to (set! lst (sort lst proc)) <graywolf>Yet one (set!) works, but other returns random result each time it is run (sort!). wtf <rlb>graywolf: sort! is just allowed to do destructive (internal) modifications, but otherwise it's the same as sort, so you always have to assign the result. <graywolf>Hm, maybe I should just not code after midnight; thanks a lot <cpli>mwette, re: talking about chasing struct tags using cdata? <cpli>the wrapper and unwrappers for cenums are generated with an `assq-ref`.. <mwette>Right. You're asking of that could be a dict, or perfect hash? <cpli>additionally, #:renamer looping infinitely comes from trying to rename builtin types <mwette>Hmm. I'll have to check that. I should have run into that. <cpli>mwette: to some degree, i don't currently incur enough performance overhead from unwrapping enums; i'm currently upset that cenum fields aren't passed to `renamer`... <mwette>I didn't think about that. I want to think about possible unanticipated consequences. <cpli>would it be possible to additionally pass type information to the renamer? <cpli>mwette: i.e. that a function name is "foo" 'function, a struct is a "Bar" 'struct and a struct field is a "bar_baz" 'field? <rlb>wingo civodul: regarding -fexcess-precision=standard, would you still prefer that to be x86 only for now, and if so, any suggestions for how you'd like to guard it, e.g. a target_cpu match of i?86 or...? (current triple there for debian is i686-pc-linux-gnu). <mwette>cpli: Are you talking about the `#:renamer' form in define-ffi-module or `name-cdata' ? If the former, I don't get it. If the latter, there is `cdata-kind' <civodul>rlb: hi! re -fexcess-precision=standard, Guile is built that on i686 in Guix <civodul>would be nice to have it done by default, but i believe this is an x86-only flag, no? <rlb>Hmm, I didn't think it was, but might have just assumed. <civodul>ah well, it’s listed in the “Optimization Options” section of the GCC manual <civodul>so i guess it’s not x86-specific after all <rlb>ACTION tries it on arm64 <rlb>If it's a general option, I'd imagined it might be the case that guile's numerics expect c99/ieee behavior, and if so, we might want it everywhere, but I think maybe wingo leaned the other way. <rlb>Hence the question about what the correct guard might be wrt the autoconf target_cpu string. <rlb>civodul: not rejected by gcc on arm64 <rlb>But yeah, I'd like to add it to main so debian can drop the numbers.test hack/patch. <sepeth>Hi all, a Guile newbie here, in GOOPS, is there a util function that I can do destructuring like one can do in JS, e.g. let { slotA, slotB } = obj;. With let and slot-ref, it gets a bit repetitive if I want to access like three or more slots. <sepeth>Writing a function for slot-set! that updates multiple fields was easy enough. If there's nothing for slot-ref, maybe another let macro could be a solution, would that be right? <dthompson>I think you'd need to write your own sugar for that <sepeth>Ok thanks. Let me give it a go ^-^ <rlb>civodul: specifically what he said (earlier in the backlog) was "honestly i would prefer an option that only applies to i686 i.e. add flags when on i686. no preference whether it's -mfpmath or -fexcess-precision" <rlb>And then if so, I'll need to know what the right pattern is for the target_os string -- i.e. is i686 right, or should it be i?86 or... <civodul>rlb: do other compiles like Clang support ‘-fexcess-precision’? <civodul>i guess in configure.ac, we should (1) check $host_cpu for i[3456]86, and (2) use ‘-fexcess-precision=standard’ iff it actually works <Arsen> 22:09:52 <civodul> rlb: do other compiles like Clang support ‘-fexcess-precision’? <Arsen>I think clang does but it'd be best to avoid assuming anything <rlb>civodul: I think I tried that, but hang on. <rlb>but yeah, even if it works, we should just test for it. <rlb>(that's what autoconf's for after all :) ) <rlb>civodul: I also got the impression that -sdd=c99 might have a similar (or the same) effect -- if so, then if/when we ever require that, we'd also be set. <Arsen>if ‘-fexcess-precision=standard’ is specified ... <Arsen> ... This option is enabled by default for C or C++ if a <Arsen> strict conformance option such as ‘-std=c99’ or ‘-std=c++17’ <rlb>In any case, unless one of y'all is planning to do it, I can attempt the i[3456]86 configure.ac changes. <rlb>(when I get a chance) <mwette> cpli: I can't produce any issue w/ renamer and size_t <rlb>civodul: in theory, I guess we'd also want `guile-config compile` to include that option in all the "right" cases? But in practice, it doesn't know which compiler, nor what target. <rlb>Or rather, I wondered if we might want that... <civodul>rlb: sounds good to me, though you need to use $fexcess_precision on line 15 <rlb>civodul: no, the var is only a flag. <civodul>it should be taken into account though :-) <rlb>should probably also change the message, i.e. whether we *want* it or not isn't the only question...