IRC channel logs

<amz3>héllo

<stis>hey

<stis>if a C function returns a long long, or as an argument how do I then use that function with the FFI in guile?

<stis>64bit int?

<manumanumanu>uint64

<manumanumanu>no. int64

<manumanumanu>long long is guarranteed to be no smaller than a 64 bit int.

<manumanumanu>stis: int64 is the answer

<manumanumanu>long long is guaranteed to be at least 64 bit, and most often it is 64 bit

<dsmith>sneek: botsnack

<sneek>:)

<stefano`>Hi!

<stefano`>if I write something like: (define a (bytevector->pointer (make-bytevector 10)))

<stefano`>what should I expect to be garbage collected?

<stefano`>The scheme object bytevector but not the memory?

<civodul>stefano`: the bytevector remains live as long as 'a' is live

<stefano`>Ok. Thank you!

<manumanumanu>stefano`: the problem arises when you do (pointer->bytevector a [...]) and a then gets garbage collected.

<manumanumanu>civodul: can a pointer keep another object alive? Say if I do (define a (make-bytevector 10)) (define b (bytevector->pointer a)) and I leave a to die, but keep b?

<civodul>manumanumanu: yes, that's roughly the same as the example above

<manumanumanu>neat.

<manumanumanu>thanks

<civodul>essentially the pointer there's a weak reference from the pointer object to the bytevector

<berndj>can someone help me understand when a guile program's output gets written(2) out? from my printf debugging + strace it looks like the output leaks out during exit(3)

<berndj>problem is: one in every few hundred runs, there is no output

<lloda>berndj: are you flushing? (force-output port) or ~! with format

<berndj>i'm almost certain this program isn't flushing

<berndj>lloda, i'm mostly curious why the program's intended output goes missing only *sometimes*

<berndj>and apparently never when i use setarch(8) to disable ASLR. also never when i run the program under valgrind

<berndj>well calling scm_flush_all_ports() before exit seems to make it work. 3000+ runs now and no failures. still curious about mechanism

<Sleep_Walker>is anywhere reported problem with guile-2.2.3 i18n tests when built against recent glibc?

<Sleep_Walker>wingo: could you please confirm that license of guile-charting is LGPL-2.1+? (I checked guix, but commit was added by Ludo) why you also put GPL-3.0 license there?

<OrangeShark>Sleep_Walker: it is recommended to include the GPL file even if you distribute it as LGPL as the LGPL just adds ontop of it

<Sleep_Walker>OrangeShark: thanks for explanation

<OrangeShark>it should be stated in the README usually

<Sleep_Walker>there is:

<Sleep_Walker>Distribution of Guile-Charting is under the LGPL. See the COPYING file for

<Sleep_Walker>more information.

<Sleep_Walker>COPYING contains GPL-3.0, COPYING.LESSER contains LGPL-2.1

<OrangeShark>should probably say see COPYING.LESSER

<OrangeShark>the repo has LGPL-3.0

IRC channel logs

2018-03-09.log