IRC channel logs


back to list of logs

<picoman>Does guile integrate with zenity of gnome?
<iyzsong>picoman: rain1 has bring, I haven't try it yet :-)
<dsmith-work>day Greetings, Guilers
***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?
<lloda>s/it/is it/
<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
<rain1>grafos, musl?
<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
<grafos>thank you.
<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>i understand if not :)
<civodul>wingo: i can try :-)
<wingo>so there is a test in r6rs-ports.test
<wingo>"make-custom-binary-output-port [partial writes]"
<wingo>it does a put-bytevector
<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>effects rather
<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
<civodul>right, good question!
<wingo>just wondering what to do there, if you have any instinct
<civodul>ACTION looks
<wingo>the more time goes on, the more i like r6rs :)
<civodul>i know that feeling :-)
<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>ah indeed
<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>you mean in Guile?
<civodul>in Guile there's a recent extension whereby 'setvbuf' works for CBIPs
<wingo>i mean in r6rs
<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>setvbuf pour tousĀ ! :-)
<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
<wingo>soft ports are terrible tho
<civodul>we should deprecate them
<civodul>but we lack custom input+output ports
<civodul>at least in 2.0
<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
<wingo>civodul: ^
<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...
<civodul>anyway, good night!