IRC channel logs

<lloda>just wasted some time with https://lists.gnu.org/archive/html/libtool/2009-12/msg00057.html :-/

<daviid>anyone has experienced 'make check' remains for ever in 'Running sandbox.test'? this is on stable-2.2, after I commented 3 files in the larceny test-suite (which should not have anything to do with this, but.. )

<daviid>hum, this behavior is related to these files, just reverted my changes ... that is too bad (was trying to help rlb wrt a license problem in these... but it seems they are required to run make check, or would imply more changes ...)

<daviid>sneek: later tell rlb 'make' worked fine but 'make check' remains in 'Running sandbox.test' for ever when commenting thse three gc-benchmark/larceny file we were talking about yesterday, so that approach won't work 'just like that', it might still work but would need a bit more then just commenting these in the Makefile.am

<sneek>Will do.

<daviid>sneek: later tell rlb I recommend you send an email to guile-devel and posibly copy it to guix-devel as well, because it is 'holiday time' i europe and I'm not sure (all) maintainers will see and respond to our irc conversation and attempt to solve it asap for you to introduce 2.2 in debian unstable... better email I think

<sneek>Okay.

<civodul>lloda: bah, that ltdl bug is terrible!

<lloda>civodul: crazy old, too...

<bavier`>is the claim here https://programmingpraxis.com/2017/07/11/my-new-programming-environment/ about guile being "aggressively R5RS" even accurate?

<davexunit>bavier`: that seems a little extreme

<davexunit>considering that guile has r6rs compatibility and r7rs compatibility planned

<bavier`>one can run "pure" r6rs programs in guile, correct?

<davexunit>i'm not sure since i haven't tried

<davexunit>ACTION pays no mind to scheme standards

<cmaloney>iirc there's r6rs support in guile 2.0 with an external library

<cmaloney>but it's not complete and says as much in the manual

<cmaloney>(not complete as in there are philosophical reasons why Guile doesn't support X)

<random-nick>bavier`: see this section in the manual: https://www.gnu.org/software/guile/manual/html_node/R6RS-Incompatibilities.html#R6RS-Incompatibilities

<cmaloney>unrelated: I've been kicking around learning Debian packaging by creating a PPA for guile 2.2 for Ubuntu 14.04 on up

<cmaloney>any reason why that would be a silly idea?

<cmaloney>I built guile 2.2 in a LXC container and it took long enough that I'm not eager to repeat that

<mwette>so I'm working the FFI Helper and peeps suggested the gdbm API but lol that has this:

<mwette>typedef struct { char *dptr; int dsize; } datum;

<mwette>datum gdbm_fetch(GDBM_FILE, datum)

<mwette>So the function gdbm_fetch takes struct values (datum) as argument and returns structs. This is not supported by the current FFI signature scheme.

<mwette>I have not explored the implementation but guessing the guts of calling C functions this way in libguile, registers allocated to argument are spilled onto the C-stack (e.g., as would be done for varargs calls). But what about return values? I'm guessing the FFI pointer->procedure api may need to change. Thoughts?

<mwette>I found on wikipedia "X86 calling conventions" with ref to SysV AMD64 ABI

<mwette>now searching in libffi documentation

<mwette>and guile documentation on ffi. Passing and returning structs may already be supported but how is not clear to me.

<amz3`>via pointers?

<amz3`>actually you pass a pointer, then turn that into a bytevector and convert that to something schemey via bytestructure

<amz3`>but I am not sure about gdbm

<mwette>The issue here is that structs are being passed and returned by value (in C programs).

<amz3`>that's not possible afaik

<amz3`>but that's what does happen in https://github.com/ijp/guile-gdbm/blob/master/gdbm.scm#L72

<amz3`>(define-foreign %gdbm-fetch datum "gdbm_fetch" (list '* datum))

<amz3`>where

<amz3`>(define datum (list '* int))

<amz3`>if this was true, it would make guile bytestructure useless, I am not sure I understand

<amz3`>I need to sleep

<mwette>Ah. From reading parse_ffi_type in libguile/foreign.c I was thinking support might be there already. So I should use the following:

<mwette>(pointer->procedure (list '* int) (dynamic-func "gdbm_fetch" (dynamic-link))

<mwette>(list '* (list '* int))

<mwette>It will get more tricky for code passing unions by value. I will need a routine to compile the largest component (with alignment) of the union.

<mwette>I hope I punt support for passing unions. arrays can be handled via structs:

<mwette>(pointer->procedure ret-arg fctn-pointer (list (list int int int))) for function with one arg declared as "int x[3]"

<amz3`>it only works if there is no specific alignement to do?

<amz3`>?

<faalentijn>Hello, I'm not sure where this is exactly the right place to ask but I want to know for certain that I'm not doing something really stupid before filing a bug (it both scares me and, as a beginner, I presume everything is my fault by default). But when using the (web client) module to do a post request with a body to a service that is TLS only, it will throw the "The TLS connection was non-properly terminated". For example it will do

<faalentijn>(http-get "https://ptpb.pw/R1gC") just fine but will balk when you try to do (http-post "https://ptpw.pw" #:body "hello world!"). I tried multiple different services (http + https seems to be fine), setting the streaming flag, sending it a bytevector, sending it with the length of the bytevector and the like but it hasn't been working.

<faalentijn>I'm I being a dunce or is there something wrong with (web client) or (gnutls). Guile 2.2 and GnuTLS 3.5.14 but I've also tried it using the Guix & Debian packages.

IRC channel logs

2017-07-17.log