IRC channel logs

2018-01-04.log

back to list of logs

<rlb>amz3: if nothing else, you might need to create C wrapper functions.
<rlb>Don't know if swig and/or g-wrap are still a thing -- been a long time since I was inclined to automate that sort of thing.
<daviid>amz3: yes, one write a C wrapper, then use the dynamic ffi ... see vigra_c (used by guilecv) as a good and relatively simple example on how they do this
<daviid>amz3: https://github.com/bseppke/vigra_c the README even explain how (and a bit of why) to do it ...
<daviid>rlb: g-wrap works fine with all version ofguile, including 2.2.3, and is used by guile-gnome, guile-clutter, both working fine with the latest guile as welll. but we do not recommend new bindings to use it, but rather to use the dynamic ffi instead ...
<rlb>I've always been wary of dynamic ffis -- though haven't looked at guile's. i.e. how does it know how big a foo_t is?
<daviid>rlb: you write a C function that return that info, and binds it using the ffi
<rlb>Ahh, ok, the api has to be designed for that. Fair enough.
<rlb>But a lot of them aren't.
<daviid>if not, you just add these bits... here is a simple example
<daviid> https://git.savannah.gnu.org/cgit/guile-cv.git/tree/libguile-cv/libguile-cv.c line 38
<rlb>sure - just can't be used for wrapping an api without (some) compilation.
<daviid>I actually need to add one, because size_t itself my return 32 or 64 (4 or 8) ...
<rlb>yep, I've noticed ffis have started to add more of the types you might want like size_t, ssize_t, etc., which is handy, and was always a pain in the past.
<daviid>rlb: true, but fair enough - and by all means, a couple of order of mag simple and cleaner then g-wrap (not a critique, but g-wrap is obscur and quite 'heavy'), the dynamic ffi is the way to go now ...
<rlb>bbl
<daviid>and g-wrap generate C code anyway, so you won't escape compiinge ... 'obscur' and difficult to maintain code: just the gtk binding generate 30 to 40 thousands lines of C code, and then you need a lot of work still, scheme and C for all the exceptions g-wrap could not handle ... in the lng run, 10x more work (at least) totally lost time imo ...
<daviid>it is so difficult that, as an example, beside myself and wingo, nobody knows how to maintain guile-gnome
<amz3>I need to rewrite part of culturia again, because my model is wrong, using column storage to have autoincrementing primary keys is not a good idea
<amz3>also, I need to figure whether using directly a graph database makes sens
<janneke>TIL: (with-input-from-string "" (lambda () (char? (read-char)))) => #f
<janneke>mes said: #t, that makes nyacc 0.80.40 fail on parsing tcc, in tricksy ways
<manumanumanu>janneke: what? Why is that?
<janneke>eof-object is not a character, apparently
<manumanumanu>ah, of course
<manumanumanu>i didn't look at the string :D
<manumanumanu>amz3: well... it is not unlike how you would do it in C.