Search
Saturday, 13th of October 2018, 11:14:27 UTC
14:22:14
Posterdati
still no fix for iolib under openbsd...
15:55:40
Posterdati
iolib is not usable on bsd systems, due to wrong error constants definitions in sockets/grovel.lisp and syscalls/ffi-types-unix.lisp
16:25:29
White_Flame
no-defun-allowed: specifically, 32-bit ieee floats have 7.22 decimal digits of precision
22:32:56
no-defun-allowed
Morning, LdBeth
22:38:16
russellw
what's the recommended way to check if a character is whitespace?
22:39:03
Shinmera
find + an array that contanis all characters you consider whitespace
22:40:33
emaczen
https://pastebin.com/zJVfpq0h -- I can't determine the inconsistent results here...
22:40:54
kristof
I was going to suggest a range check on char-int
22:41:03
Bike
your implementation might provide checking for the unicode WSpace property
22:41:25
emaczen
it will work 99% of the time for me on OSX and 1% of the time on raspbian
22:42:17
emaczen
I get a memory access error in local function get-family when evaluating the form (cffi:foreign-slot-value addr '(:struct sockaddr) 'sa-family)
22:42:58
russellw
I think I like kristof's solution best. thanks to everyone who replied!
22:43:25
Shinmera
it's also not portable but who cares
22:43:42
|3b|
what do your struct defs look like?
22:44:20
|3b|
also, (cffi:foreign-type-size :pointer)
22:44:46
|3b|
(and use cffi to allocate it rather than mixing in some other FFI and manual malloc/free)
22:44:58
emaczen
|3b|: ffi is my own code
22:45:15
emaczen
It is just c functions defined with defcfun
22:45:32
|3b|
if so, write a (ffi:with-malloc ... ) macro :)
22:45:46
emaczen
|3b|: Yep, I will get to it eventually
22:45:46
|3b|
ACTION would still just use cffi:with-foreign-object (buf :pointer) though
22:46:43
emaczen
|3b|: I'll make another paste for my struct definitions
22:46:57
|3b|
c code works reliably on both?
22:50:18
emaczen
https://pastebin.com/iuwCtc8F -- struct definitions
22:50:53
emaczen
The only type difference I am aware of are between sa_family and sin_family
22:51:08
emaczen
I forgot to try the c code on my pi. Give me a sec
22:52:53
emaczen
yep, C code works fine on my pi too
22:54:34
|3b|
hmm, does (get-family (cffi:mem-ref buf :pointer)) work any better?
22:55:00
|3b|
ACTION wouldn't expect it to work at all if that was the problem (or at least give nonsense results), but doesn't look right
22:55:19
emaczen
what doesn't look right?
22:55:25
russellw
when you don't specify in-package, your symbols are defined in :cl-user, aren't they?
22:55:46
|3b|
ACTION is confusing things
22:55:48
emaczen
they are interned in the current package
22:56:10
russellw
right, but what is the current package by default?
22:56:35
|3b|
ok, try (setf buf (cffi:mem-ref buf :pointer)) before the loop
22:57:22
emaczen
|3b|: That seems to have done it....
22:57:27
|3b|
i think it was working by luck if it happened to have 0s in the right place after the pointer, since setf buf ... ifa-next would be same as above
22:57:49
|3b|
but that happens after first call to get-family, so would depend on what was in memory there
22:58:29
|3b|
in cl you had equivalent of struct ifaddrs** buf; getifaddrs(buf);...
22:58:54
|3b|
so first time you were passing pointer to the pointer returned by getifaddrs to the other things
22:59:18
emaczen
|3b|: wait, I don't see how I had ** instead of just *
22:59:28
|3b|
and buf->ifa_next happens to be the same as *buf, so if it survives the first iteration, it works OK
22:59:53
|3b|
well, CFFI doesn't really distinguish
23:00:25
|3b|
so you could think of it as struct ifaddrs* buf; getifaddrs(buf); too (minus any warnings from static typing)
23:00:47
|3b|
you pass a pointer to getifaddrs, it stores a pointer in the memory pointed to by the passed pointer
23:00:49
emaczen
that is what my c code looks like
23:01:44
|3b|
cffi tends to have 1 extra layer of pointers than corresponding C code, which can be confusing to get used to :/
23:02:30
|3b|
ACTION supposes you should check for null pointer before that first dereference of buf too
23:02:49
|3b|
in case you happen to be on an odd system without even a loopback interface :)
23:04:02
emaczen
|3b|: I see the difference between my C code and my Lisp code but I don't quite see why cffi:mem-ref does the trick
23:04:24
|3b|
that gets rid of the extra pointer
23:05:12
emaczen
|3b|: but I thought I was missing a pointer... since the C code passes the address via & and in my lisp code I just passed the pointer
23:12:08
emaczen
getifaddrs expects a struct ifaddrs**
23:12:17
emaczen
in CFFI we only give it a :pointer
23:12:53
|3b|
well, you could allocate another pointer if you wanted, but doesn't really matter
23:13:10
emaczen
so for cffi we have to get rid of an extra pointer because getifaddrs thinks it is a **
Saturday, 13th of October 2018, 23:14:27 UTC