IRC channel logs

<sapientech>wingo: got everything set up!

<wingo>sapientech: oh good :)

<amz3>paroneay`: did you try the demo of factorio, it seems like it use something like what sussman created

<amz3>the state machine kind of stuff

<amz3>let me know if it rings a bell

<ng0>hi, is the guile web site out of sync or is the 2.0.12 maintenance release not important? gentoo assumes 2.0.11 is still the stable release ( https://bugs.gentoo.org/show_bug.cgi?id=355355#c84 )

<paroneayea>ruste: to answer your question from earlier, there *are* some issues with openssl, if you have a GPL'ed application. You generally need to add an exemption https://people.gnome.org/~markmc/openssl-and-the-gpl.html

<paroneayea>not so if you use gnutls

<ruste>paroneayea: I suspected as much. I gave gnutls a try again yesterday evening.

<ruste>Figured out why I didn't use it last time.

<ruste>Best I can tell, the documentation for gnutls is outdated compared to the library.

<ruste>Some of the functions in the examples don't exist anymore.

<ruste>I think I can use the guile-oath module for reference. I'll look at taking the "ambient" route.

<ruste>oath uses an https call.

<ruste>and gnutls

<dsmith-work>{appropriate time} Greetings, Guilers

<ruste>o/

<ruste>Morning.

<avoine>what should I use if I want to start two functions in parallel and when one finish stop the other one?

<avoine>hooks maybe?

<wingo>in theory thread cancellation. realistically probably cause an async signal on the thread

<wingo>read about asyncs in the manual

<avoine>ok

<ruste>wingo: You mentioned yesterday only supporting https if gnutls was installed.

<ruste>How would you conditionally import the module?

<ruste>(catch (use-modules (gnutls))...?

<ruste>Or search for it first to see if it's there before importing?

<wingo>(let ((mod (false-if-exception (resolve-interface '(gnutls))))) ...)

<wingo>something like that

<wingo>dunno

<wingo>that would be part of the mechanism anyway

<ruste>Alright. I'll check it out once I can bend gnutls to my will.

<paroneayea>hey neat

<paroneayea>and=> is a fun procedure.

<paroneayea>I wonder if I'll ever remember to use it :)

<wingo>mewp

<daviid>hello! wingo is there any chance you could find some time to patch g-wrap for 2.2?

<galex-713>Hi

<galex-713>Do you think it’s a bad idea to learn RDBM and OpenGL with Guile first (instead of, say C, or, worse, C++)?

<galex-713>davexunit: where did you learnt OpenGL first?

<wingo>good evening daviid :)

<wingo>i'll push it onto the list

<daviid>wingo: thanki you! since it's mostly the C part, I'm badly equiped to help... it would be nice if you could...

<wingo>ACTION implements custom binary input/output ports, finally

<paroneayea>wingo: :D :D :D !!!!!!!!!!!

<paroneayea>hell yeah!

<wingo>paroneayea: i could use some help fwiw from a tests perspective :)

<paroneayea>wingo: hm sure, I can help

<paroneayea>wingo: point me to the repo once you have it up and give me some ideas on what to test maybe? :)

<paroneayea>I can try myself on the ideas if that's what you're missing, otherwise if it's just implementing, sure :)

<paroneayea>yay! anyway, this is exciting

<wingo>i think making sure that the custom binary input and output tests work on the i/o ports

<wingo>and making sure that buffering works

<paroneayea>wingo: that makes sense

<wingo>and the buffers are flushed when switching between input and output

<paroneayea>wingo: on a higher level, I wonder if we could run an https server over localhost and connect to it?

<paroneayea>or is it a bad idea to connect to a port during tests maybe

<paroneayea>I guess that tls might not come *immediately* after binary ports :)

<wingo>ah so i think this facility doesn't directly touch on https fwiw

<paroneayea>wingo: do you think it'll remove the blocker?

<wingo>i think it will, yes, afaiu anyway

<paroneayea>okay

<paroneayea>so, yeah, not related to these tests

<paroneayea>still just as exciting then :)

<wingo>hum, i wonder whether to flush the buffer between reads and writes...

<wingo>for a file that's what you would want to do, but not necessarily for a socket

<wingo>see third para here: https://www.gnu.org/software/guile/docs/master/guile.html/Buffering.html#Buffering

<wingo>civodul: you have any thoughts here? i am thinking about adding an optional random-access? parameter to `open-custom-binary-input/output-port', dunno

<wingo>alternately we could add a `set-port-random-access?!' proc or so

<wingo>gotta love the interrobang

<civodul>wingo: i think i miss some context :-)

<dsmith-work>Heh. interrobang

<wingo>sorry :) implementing make-custom-input/output-port.

<civodul>aah!

<wingo>hopefully that will allow gnutls bindings to be written entirely in scheme

<civodul>yes, indeed

<wingo>wondering about third paragraph of https://www.gnu.org/software/guile/docs/master/guile.html/Buffering.html#Buffering in that context.

<civodul>hmm, dunno, i haven't really thought about random access ports

<civodul>i suppose it's a rare use case, no?

<wingo>dunno

<wingo>i think for something like GIO / GVFS it is rather common

<wingo>and of course that is the case for files

<wingo>if they are seekable anyway

<wingo>maybe i make it random-access only if set-position! is provided

<wingo>i guess that's the right thing

<wingo>that's what the ports code does for C port types where the seek function is either statically provided or not

<wingo>so i guess that's the behavior we should have for this port type based on whether a seek function is provided for the individual port or not

<civodul>oh sorry

<civodul>i was thinking more about how buffering should work when you read and write to the port

<civodul>as for random-accessness, yeah, it can be determined statically based on whether a set-position! procedure was provided

<wingo>well

<wingo>buffering is related to random-accessness :)

<wingo>for a random-access port, you want to ensure the write buffer is flushed before reading

<wingo>and vice versa

<wingo>but not for a non-random-access port like a socket

<wingo>there are exceptions but that is the general rule i think

<wingo>(to flush buffered input, you have to be able to seek.)

<civodul>hmm probably

<wingo>ok i have an implementation, entirely untested la la

<wingo>paroneayea: you think you will be able to give it a go?

<wingo>you can get tests from test-suite/tests/r6rs-ports.test

<wingo>that would probably be sufficient for an initial impl, just copying and pasting tests; dunno

<wingo>i pushed, whee

<wingo>making tests a blocker bug for 2.1.4 :)

<wingo>mark_weaver: wdyt about http://bugs.gnu.org/24102 ?

<wingo>makes sense to me fwiw, i like the patch

<daviid>i wonder why not box-ref box-set! instead of unbox set-box!

<daviid>I mean I wonder why srfi-111 did not choose these names... but maybe we could re-export both? i would re-export as make-box as wel?

<wingo>i think srfi-111 support is a case of just "whatever names they put in the srfi"

<wingo>it's a separate module so no impact on guile itself

<wingo>ok, zzz

<wingo>night :)

<daviid>night

<paroneayea>wingo: oh cool, pushed to master I'm guessing? I'll take a look soon

IRC channel logs

2016-08-04.log