***leoprikler_ is now known as leoprikler
<ArneBab>rekado_: sorry for not being able to come back to you earlier :-) <wingo>gnulib update seems to have gone ok <ArneBab>then I won’t take up more — happy hacking! And thank you for your work on Guile! ***apteryx_ is now known as apteryx
<brine>Hey, I am trying to use libguile.h in a program but unable to because a file libguile/scmconfig.h is missing. I looked in the /usr/include/guile/2.2/libguile/ and scmconfig.h is right there. This is an error thrown by gcc when the C program is compiled. I am on Linux, guile version 2.2.6, gcc 10.2.0. Any help would be appreciated. Thank you. ***rekado_ is now known as rekado
<rekado>brine: how do you set up the CPATH or C_INCLUDE_PATH? <brine>I havent set up any paths, I am including with #include <guile/2.2/libguile.h> <brine>rekado: That did it! I set up CPATH. Turns out gcc wasn't able to find libguile.h. Thank you <spk121>do y'all feel that you reached consensus on having mkstemp/mkdtemp just return the name of the temp file/directory and not mutate any string arguments? <leoprikler>to add one more take to the mix: leave it with ! now, make it no ! in 3.2 :) <nly>any library for FUSE? <davexunit>does anyone know what kind of overhead is associated with define*? I'm wondering if it's a good idea to use it in performance sensitive code. <wingo>davexunit: it makes procedure entry more costly. optionals are almost free. keyword arguments are more expensive. but measure, if it matters. <wingo>inside the function there is no difference tho <davexunit>wingo: cool, thanks. that's the kind of stuff I was looking for before I go benchmarking. I'm using optionals, in this case, so that's good news. <rlb>spk121: I think maybe we were leaning toward switching to the non ! variants, and either deprecating mkstemp! (or really, could just leave it around for backward compat indefinitely, with suitable, docs suggesting you prefer mkstemp). i.e. it's not much code, and then we don't have to push work off on to all downstreams. <spk121>rlb: I think that is sensible. I've got time today to take that action, if everyone's okay with that <spk121>I guess the question now is what should non-mutating mkstemp return? Just the filename string? Or return the filename string and the port as multiple values <wklew>Hi Guile, I had trouble finding an answer to this online: are promises thread-safe? <wklew>if the promise itself makes no mutations <spk121>because the analog between the two isn't perfect in C either. in the C mkstemp returns a FD, the C mkdtemp does *not* return a DIR handle <leoprikler>wklew: everything in guile should be thread-safe to the extent that it does not crash, promises included <leoprikler>however, there's no safety as to whether you're producing garbage or not <leoprikler>if your promise does not mutate anything however, there's no way it would ever be thread-unsafe <manumanumanu>davexunit: a define* where you don't use the extra features over define is free, since a define* without #:optionals or #:key becomes a regular define <manumanumanu>wingo: regarding define*: is a define* using only optionals any different from case-lambda? <davexunit>manumanumanu: I wouldn't use define* if I wasn't going to have optional or keyword args. <manumanumanu>davexunit: I have ended up with define* without any extra features when refactoring, and noticed that it becomes define at expansion. I sometimes write some functions as define* when I maybe intend to extend them. I'm just lazy, and I thought of it as a simple FYI :D <davexunit>it's good to know. I didn't know that the trivial case would do that. <spk121>wingo: ok I'm going to push a mkdtemp! -> mkdtemp patch. We can do mkstemp! -> mkstemp later once there is consensus about what mkstemp should actually return. <manumanumanu>oh, this seems to be a known thing. guile 3 is unsupported <civodul>spk121: what we discussed yesterday is that we could deprecate mkstemp! and provide mkstemp <civodul>so mkstemp! would be removed in 3.4, i think <spk121>civodul: the question for mkstemp, though, it what it should return. Just the filename? or both the filename and the file port? The mutating mkstemp! returns an open file port <rlb>I think? i.e. the fd is important -- perhaps just (values ...)? <spk121>rlb: I think both via values is the way to go with the port being primary, so that if you just do (define pt (mktemp "XXXXXX")) it picks up the port <spk121>And then you could just implement it in (ice-9 posix) without having to write any new C <wklew>leoprikler: I wasn't sure of the interaction between forcing promises in different threads, maybe thread-safe is not the right word but i was wondering if people have run into issues with it <leoprikler>forcing promises in different threads should be safe <wklew>analogously, I was wondering about how promises interact with delimited continuations, like throwing away a continuation or resuming it more than once <wklew>does each thread have its own cache of forced promises? sorry if im asking basic questions i wasnt sure where to look <wklew>ok, i guess that's all i was wondering <rekado>I built guile-commonmark with guile 3.0.5 <rekado>needs to changes: one is in configure to allow building with 3.0, the other is to remove the (exit …) forms at the end of every test file.