IRC channel logs
2023-05-13.log
back to list of logs
<mwette>bjc: not sure what you are going ; your top-level lambda is just defining two variable, it's not executing anything. Did you mean to add (apply utime args) after the utime define? <bjc>utime was being used subsequently by another procedure <mwette>ah. OK. Not knowing more details of your constraints it's hard to suggest anything more <bjc>it's fine. tracing is probably the right way to do it anyway, i just need to figure out how to get it working the next time i run into something like this <bjc>more immediately, having ‘utime’ throw the name of the file along with the exception would be good =) <mwette>there is guile-jtd in guix i believe <old>hmm tracing is working for procedure defined in Guile <old>does not seem to work for the ones defined in C <old>(trace-calls-in-procedure thunk) will work for C function like utime <old>but (trace-calls-to-procedure utime) does not work <old>is this a known limitation ? <RhodiumToad>ugh. FFI doesn't define a symbol for the "bool" type? <mwette>that's not the only one: char wchar_t char16_t char32_t _Bool (bool is not a C type) "float _Complex" "double _Complex" <mwette>^ bool.h will #define bool _Bool <Arsen>bool will be a type too, in C23 <mwette>Arsen: thanks. Any others, like complex? <gnucode>I am trying to install GNU Haunt on the hurd... <gnucode>I have guile installed, but the ./configure for guile-commonmark is not working so well <gnucode>it says that I do not have guile installed, but I do. <gnucode>ahhh, apparently I need to install guile-dev or something... <gnucode>well some of the guile common mark tests failed, which is to be expected I guess <gnucode>hmmm seems like common mark is not installing. <rlb>RhodiumToad: I'd like to see guile eventually provide "full" support for all the really common types, including posix types like off_t, size_t, ssize_t, uid_t, gid_t, C(99) types like intmax_t..., etc. I've thought about working on it (assuming there's interest), but haven't gotten around to it. <rlb>I'd like us to have both sign and size information available for all of them. <rlb>And perhaps some types would be optional, and if we don't already have a way to test for their existence on the current host (other than catching sizeof unbound variable exceptions), I'd like to fix that too. <mwette>these are supported: intptr_t uintptr_t size_t ssize_t ptrdiff_t <mwette>because I use nyacc c parser to figure out struct offsets for non-host architectures <rlb>Ahh, interesting, though I'd definitely want this in guile itself eventually, and I think I'd want all the values to be captured at compile time (guaranteed correct, etc.). <mwette>I think there are needs for cross-compling other than mine, so the compile-time thing seems limiting. <rlb>...in truth, I've wondered if it might be possible to make it so that some subset of programs could eventually just rely on guile instead of autoconf. One thing that got me contemplating it is that bup's able to lean on python for some things that python already captures wrt the host, but I'd want something much more principled/complete. <Arsen>IMO it'd be unfortunate to reinvent a build system for guile packages <Arsen>if anything, more guile support should be added to the auto*s <mwette>and I was also thinking of something to map types to { int/float, signedness, bits } so one can map to the bytevector routines easily <rlb>Right, this definitely wouldn't be sufficient for programs "lower down" in the dependency tree, i.e. wrt cross compilation, but anyway, that's just idle speculation. The main thing I'd want it for is really solid C API wrapping, etc. <rlb>i.e. to_from_guid_t, etc., though perhaps support for maxiumum signed/unsigned integer types would be enough, if coupled with the expectation that everyone uses intprops.h macros (or equivalent) carefully. <rlb>Arsen: perhaps, though I've had an awful lot of conversations with very good hackers for whom autoconf/automake is perceived as much too high a bar. <Arsen>sure, but adding first class support would help a lot with that <rlb>first class support for what? <Arsen>AC_PROG_GUILE + some primary for guile in automake <Arsen>right now, building and installing guile packages is a rather ad-hoc thing <Arsen>(or AC_PROG_GUILD, I suppose) <rlb>In any case, I think it might be plausible to add support for the really common types to say guile's (sizeof x) first, along with some friendly way to avoid an error if the type isn't available, and also some way to ask about the signs of at least the types that don't specify (though perhaps easiest to just do it for all of them). i.e. I'd like that even if that's all we did. <ArneBab>anything that depends on Guile for the build system wouldn’t work with the bootstrap via MES anymore, right?