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>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 <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 ... <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 <janneke>eof-object is not a character, apparently <manumanumanu>amz3: well... it is not unlike how you would do it in C.