***michel_mno_afk is now known as michel_mno
<ajnirp>civodul: how does define-c-struct handle unions? <ajnirp>it's not a big deal, btw, since the only union field in struct getifaddrs is just union { type* name1; type* name2 } (same types) <amz3>you mean make-c-struct ajnirp ? <amz3>you workon on dhcp our gnunet? <amz3>sorry for the confusion :) <amz3>ah ok so you use c struct to create the packet to be sent or parse the packet you receive <ajnirp>but this question was in the context of adding FFI wrappers for getifaddrs (3) in (guix build syscalls) <amz3>i don't think it handles union I'm check what union is <ajnirp>it isn't really necessary in this case actually, i was just curious. it would have been a problem if the union was over fields with differently sized types <ajnirp>in this case it's not even two similarly sized types, it's just the same type (no idea why they had to give it two different names :/ ) <amz3>that's what I was going to say :) <remi`bd>ajnirp: I had to handle unions myself, thus I wrote a wrapper around make-c-struct & sizeof that adds a “union” type specifier <amz3>ajnirp: maybe they have the same time now, but did not in the past <remi`bd>(uses (system foreign) (ice-9 match)) <civodul>ajnirp: it doesn't handle unions, but in this case these are all pointers, so that's fine <amz3>btw, ijp: are you doing source maps? <ijp>amz3: maybe eventually <Waqar>I want to know what does (define *nil* "nil") does <Waqar>why isn't it, define nil nil <Waqar>why isn't it, (define nil "nil") <amz3>*nil* is a variable name <amz3>it the same as nil but with two stars before and after <amz3>There might be convention regardings star char in names, I don't know <amz3>for instance (define (%some-procedure ...) ...) is a way to explain that %some-procedure is for internal use <amz3>I mean that percent character is used to say that the procedure or variable is internal <mark_weaver>Waqar: in scheme, the following characters are treated exactly the same as letters: ! $ % & * + - . / : < = > ? @ ^ _ ~ <nee>amz3: I think it's a convention in common lisp to surround globals with stars <ijp>(define *this!i$@valid_<variable>:name? 3) <ijp>heh, encoding perl in id names <Waqar>it was a great help. I am trying to understand a code I know not too much about at the moment. Its written in guile Scheme <Waqar>I will seek help from this channel in that. Thanks a lot for instant help guys. I am grateful. <artyom-poptsov>Basically adding asterisks means that this is a global mutable variable. <mark_weaver>actually, I need to qualify my comment somewhat, because there are some special cases: '.' by itself is special, and with the exceptions of '+' '-' and '...', standard scheme doesn't allow symbols that start with a character that might start a number, which includes '+' '-' and '.'. <amz3>Waqar: your welcome, but I'm a girl ;) <Waqar>:) lolz thanks gals and guys :) scheme community is great *amz3 Waqar I am kidding, I am a man <ijp>that one will error though <ijp>#foo is a whole other mess <mark_weaver>yeah, because # is not one of the characters I mentioned <mark_weaver>(the characters I mentioned are known as the "extended alphabetic characters") <mark_weaver># introduces many other kinds of literals, e.g. #t is true, #f is false, #\\a is the character 'a', #\\space is the character ' ', #(1 2 3) is a vector, etc. <mark_weaver>recent versions of guile, and r7rs, also allow #true and #false, which I find much more readable, but they haven't yet become popular. <mark_weaver>in guile, #:foo is a keyword, which is similar to a symbol but "self-quoting". <ajnirp>i didn't either, maybe we can add a line in the manual mentioning #true and #false <mark_weaver>and we provide convenient ways to define procedures to accept "keyword arguments", using 'define*' and 'lambda*'. <mark_weaver>davexunit: yeah, I'd like to see #true and #false more widely used at some point, but given that even guile 2.0.9 didn't have them, I guess it's too soon. <mark_weaver>also, if one chooses to go for r6rs compatibility, it's a no-go. <remi`bd>is there a special way to handle asynchronous calls in Guile Scheme? <remi`bd>my question is too general; I have an asynchronous C API that makes heavy use of callbacks, and I’m wondering if keeping this API in scheme is idiomatic and, if not, what would be? <davexunit>remi`bd: writing callback heavy code would resemble "continuation passing style" <davexunit>in Scheme, we could add new syntax to make asynchronous programming readable. <davexunit>I know Guile has some built-in async primitives, but I haven't used them, so I won't be of much help. <dsmith-work>remi`bd: That doesn't address your async question though <dsmith-work>The above handles exceptions properly. Or at least it did. Not sure about prompts. <sneek>I last saw mark_weaver on Jun 17 at 01:38 pm UTC, saying: *clues. <remi`bd>well I’m using the Dynamic FFI only, and my question was not specifically about the FFI though, but thanks! <sneek>Someone once said sneek is a good boy <dsmith-work>remi`bd: The current wisdom is to use the ffi instead of hand-rolling C wrappers. <davexunit>the less C we collectively have to write, the better. <amz3>I found the bug of my ffi program, it wasn't guile obviously <amz3>I've prepared a small article to use dynamic ffi with function pointer in struct <amz3>well, this is obvious when you know dynamic ffi. <amz3>using array-ref instead of bytevector-*-ref is a savior <amz3>also you need to manully parse struct: 1) convert pointer to bytevector 2) array-ref the field 3) convert to scm <amz3>and also dereference pointer if any <remi`bd>amz3: I’m interested in your article <remi`bd>for instance, why do you favor array-ref over bytevector-u8-ref? <amz3>I don't know I think mark_weaver told me to do so. I will push it as draft <amz3>I was using bytevecotr-u64-native-ref and it wasn't fetchting the correct pointer, the first pointer was ok, the second and last pointer was truncated <amz3>the article is basicaly those files, with french comments <amz3>I just tested them it works <mark_wea`>amz3: I wouldn't have recommended array-ref over bytevector-u8-ref. <mark_wea`>although I don't know the details of what you're doing, so I won't argue against it either :) <amz3>remi`bd: it was someone else that told me to use array-ref, because "bytevectors are indexed by byte" and in a #u64 vector there several bytes <civodul>remi`bd: BTW, did you try pushing to the guix/gnunet.git repo? <remi`bd>when using a vcs, I usually make a lot of small commits, but since in this case each commit/push will send a message to the mailing-list and be reviewed, I should take especially care of what I do <amz3>is it possible to (write) a <record> ? <mark_wea`>amz3: yes. see 'set-record-type-printer!' in the guile manual. <mark_wea`>there is a default printer, but it's not very helpful. <davexunit>you can write a record, but you cannot read one. <amz3>it's a not like lists and assoc <mark_wea`>yeah, the standard 'read' procedure won't read records. <amz3>btw, I stumbled upon (srfi srfi-9 gnu) set-field and set-fields is cool <mark_wea`>it is possible to extend the reader, but it's global and doesn't compose well with other things. <mark_wea`>well, what I mean is that code the extends the reader is likely to conflict with other code that extends the reader in an incompatible way. <amz3>i have another solution maybe <davexunit>mark_wea`: some would argue that reader extensions shouldn't be allowed at all because of those issues. what do you think? <remi`bd>maybe readtables could be added to Guile (a sort of “package” for reader extensions in CL) <amz3>I don't if what i've done is good. I've created a graph datastructure that works on top of lists and a specific assoc that's called "store" where (store-ref store key) returns #nil if the key is not found. Also, (store-set) returns a copy and doesn't grow when the key is already there but delete the old key entry and add a new one <amz3>since it's only lists I can (write) it in a file and then well (read) back <amz3>I did not read other scheme implementations of graphs <remi`bd>(sorry, I may be stating the obvious) <amz3>I should read about this reader thing more, seems like a significant matter in scheme/lisp <ijp>readtables aren't a good solution ***michel_mno is now known as michel_mno_afk
<ijp>there is no reason to duplicate the work of modules for reader extensions when you could just make readers module local <amz3>ijp: isn't guile-reader doing that? <civodul>remi`bd: regarding commits, don't be afraid of review and all <civodul>it's mostly so we can discuss things <mark_wea`>amz3: I've never looked closely at guile-reader, but it sounds like the right solution to this kind of problem, and since civodul wrote it I have confidence that it's quite good :) ***karswell` is now known as karswell
<sneek>I last saw mark_weaver on Jun 17 at 01:38 pm UTC, saying: *clues. <sneek>mark_wea` was here Jun 17 at 06:34 pm UTC, saying: (one to fix the bug, another to memoize 'machine-load'). <sneek>Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux <sneek> 15:02:14 up 4 days, 22:03, 0 users, load average: 0.00, 0.01, 0.05 <sneek>I last saw dsmith-work on Jun 17 at 07:02 pm UTC, saying: sneek: seen dsmith-work . <amz3>ijp: have you seen the thing about webassembly or wasm?