IRC channel logs


back to list of logs

***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)
<ajnirp>i was just curious
<amz3>you mean make-c-struct ajnirp ?
<amz3>you workon on dhcp our gnunet?
<amz3>sorry for the confusion :)
<ajnirp>dhcp :)
<ajnirp>gnunet is remi if i'm not wrong
<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
<ajnirp>remi`bd: great! link please?
<ajnirp>amz3: makes sense
<ajnirp>thank you
<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
<civodul>hi, ajnirp, BTW :-)
<civodul>and hello remi`bd
<civodul>and phant0mas
<civodul>the whole GSoC team is online, yay!
<civodul>and ijp of course ;-)
<phant0mas>haha hey :-)
<amz3>btw, ijp: are you doing source maps?
<remi`bd>hello :)
<ijp>amz3: maybe eventually
<dsmith-work>Morning Greetings, Guilers
<Waqar>I want to know what does (define *nil* "nil") does
<Waqar>what is meant by *nil*
<Waqar>why isn't it, define nil nil
<Waqar>why isn't it, (define nil "nil")
<Waqar>can someone help please?
<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>thanks a lot
<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>Waqar: This convention with adding asterisks before and after a variable name is described here:
<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 ;)
<mark_weaver>guile is more tolerant, however
<Waqar>:) lolz thanks gals and guys :) scheme community is great
*amz3 Waqar I am kidding, I am a man
<Waqar>(#define amz3 "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.
<davexunit>ooh I didn't know about #true and #false
<davexunit>more readable for sure.
<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
<davexunit>it might already be there?
<ajnirp>ugh, missearched
<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.
<davexunit>yeah, too soon I guess.
<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: Scheme callbacks for C funcs:
<dsmith-work>remi`bd: That doesn't address your async question though
<dsmith-work>If you want an example of hwo to do that in C:
<dsmith-work>The above handles exceptions properly. Or at least it did. Not sure about prompts.
<dsmith-work>remi`bd: FWIW that's the code sneek uses.
<dsmith-work>sneek: seen mark_weaver?
<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!
<remi`bd>oh, and what is sneek?
<sneek>Someone once said sneek is a good boy
<ajnirp>sneek: botsnack
<dsmith-work>remi`bd: The current wisdom is to use the ffi instead of hand-rolling C wrappers.
*sneek wags
<davexunit>yes, the FFI is much preferred.
<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>remi`bd:, the following file is the source code of the wrapped code:
<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>not yet
<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>I mean, serialize
<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.
<mark_wea`>so it's best avoided.
<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>(source: )
<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
<dsmith-work>sneek: seen mark_weaver
<sneek>I last saw mark_weaver on Jun 17 at 01:38 pm UTC, saying: *clues.
<dsmith-work>sneek: seen mark_wea`
<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
<dsmith-work>sneek: seen dsmith-work
<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?
<amz3>it's like asm.js 2.0