<picoman>Does guile integrate with zenity of gnome? ***cojy_ is now known as cojy
***mjl_ is now known as mjl
<lloda>would take some pointers on scm_gc_free(). I assume it is never required, it worth using it at all? <grafos>I am having trouble cross building GNU guile for/with my toolchain/build system <grafos>seems like there is anot a current release, and then in the end it requires the same version of guile to compile itself <grafos>I have been reading up a bit on the measures that are taken to make scheme portable to many platforms (namely ones that are not POSIX compliant ) <grafos>my question is: how can i make all this work. so that people can easily and consistenly build GNU guile from my build system <davexunit>grafos: I probably can't help you much, but I want to make a correction: Guile does not need Guile to compile itself. <davexunit>it bootstraps itself from an interpreter written in C. <grafos>davexunit: i figured as much. that must be some incorrect build depency i am triggering. thank you. that helps <grafos>rain1: ah yes, hello!. well, i use 3 libc for linux stuff. but yeah musl is leading the way in my system. then i play catch up with glibc and uClibc <grafos>perhaps doing some glibc based builds will reveal a better configuration for me <rain1>i just ask because I heard that the garbage collector guile uses doesn't work with musl <rain1>this information might be out of date though <grafos>yeah i see alpine has a guile package. assuming it is built with musl. so i guess it's doable <grafos>rain1: nah, any information helps. if it's out of date, my own fault for piecing the story together <rain1>if it works on alpine that's really good news! <wingo>civodul: do you have a neuron available for me <wingo>the topic is r6rs custom binary output ports, and the default buffering behavior <wingo>so there is a test in r6rs-ports.test <wingo>"make-custom-binary-output-port [partial writes]" <wingo>then expects to see the effects of the write! procedure <wingo>i think to be fully correct it should (force-output port) before checking the effecs <wingo>because r6rs ports are block-buffered by default, and it could be the write has been buffered and not yet flushed out <wingo>but, i am not sure if i can make that change to the tests <wingo>because maybe there is user code that expects r6rs custom binary output ports to be unbuffered <wingo>just wondering what to do there, if you have any instinct <wingo>the more time goes on, the more i like r6rs :) <civodul>r6 doesn't say anything about buffering for make-custom-binary-output-port <civodul>so there could be buffering, i guess <civodul>in which case the test should indeed call force-output or close-port <wingo>buffering is only described for file ports <civodul>as for whether users depend on non-buffering, that's harder to determine <wingo>so buffering exists for all ports, but you can only explicitly control it for file ports? i get a bit lost sometimes :) <civodul>in Guile there's a recent extension whereby 'setvbuf' works for CBIPs <wingo>i have a pending patch to make setvbuf work on all ports <wingo>this force-output issue on custom binary output ports is the only remaining failing test <civodul>i found a user of make-custom-binary-output-port: 'open-sha256-port' in (guix hash) <civodul>i think it doesn't matter for this one whether input is buffered or not <civodul>not sure if that's a representative sample ;-) <wingo>i disabled write buffering on soft ports for somewhat similar reasons <civodul>but we lack custom input+output ports <wingo>i think with this refactor it will be easier in 2.2 <wingo>to have custom input+output ports i mean <wingo>anyway, for the future... for the present there are oddly many uses of soft ports, at least in the test suite <wingo>ok, given that more buffering is better when writing to custom binary output ports from scheme (because it's a shorter path for write-char etc to fill a buffer, compared to calling the callbacks), i will turn on buffering for custom binary output ports <wingo>we can later turn it off by default or something if we hear of problems, but probably a solution that's just as good is for people to call force-output as appropriate, or otherwise call setvbuf <wingo>sound ok to you? then i add force-output in these tests <civodul>yes, let's try it this way and document it in NEWS <civodul>having ports in Scheme sounds really exciting <civodul>hacking with this C API has always been sooo frustrating...