IRC channel logs
2017-11-21.log
back to list of logs
<daviid>anyone kows where mwette ffi-helper source code is hosted? <daviid>if i go the variadic 'route', for example: int f32vector_add_vectors_c (int n_cell, float *to, int n_vectors, ...) how would I buid the call in scheme? <daviid>anyone has a variadic example, from C to calling it from scheme? <daviid>back, in case someone can help (many are sleeping i guess) <daviid>i'm trying to build a vector of addresses to f32vectors so I can pass it to C ... and I don't know what a pointer address stype is in C. i can't find a good answer on stackoverflow either, some says they are unsigned int, others says they are system dependent <plll[m]>Hey, reading through the Fibers manual. Noticing this example from 2.1 doesn't display anything in the REPL: (run-fibers (lambda () (spawn-fiber (lambda () (display "hey!\\n"))))) <amz3>plll[m]: I am working on a search engine! <numerobis>Hi! Is there an identity mapping in guile? I am trying to do something along the lines of ((if condition? transform identity) x), that would return (transform x) or x depending on condition. I thought begin would do, but that doesn't seem to work. Thanks! <numerobis>(I know it's trivial to write one as (lambda (x) x), but I am just wondering if there exists a predefined function for this) <wingo>ACTION wrote a new compiler pass, whee <daviid> yesterday I wrote a bunch of comments (after moving fom working place that do not appear in the log, funny! <lloda>daviid: re f32vector_add_vectors_c, if you can write dedicated C for interfacing with Guile, then I would pass the list or vector as a Scheme object (SCM type) and pick it apart on the C side instead of messing with variadics <lloda>if that C function doesn't already exist I mean <daviid>lloda: I wrote it: so far, it uses a s64vector where I store the addresses of the f32vectors to add. Maybe this is not portable though? <daviid>(s64vector-set! v-ptr i (pointer-address (bytevector->pointer chan))) <daviid>(f32vector-add-vectors-c (bytevector->pointer to) n-cell (bytevector->pointer v-ptr) n-chan) <daviid>this works very well, but i need to confirm with C expert that the code is portable (the size of a pointer address... <daviid>lloda getting im-add and im-add-channel from pure scheme (good) code to C (just for the vectors addition, all mem alloc is in scheme), get things from 2.5sec to 0.06 seconds, for adding two image snipsets, 2718 x 1732 (4707576 access and addition of two f32vectors) <lloda>passing SCM would keep the interface mess on the C side, but if you've already written it and it works... <lloda>re: times, I'm not surprised :-\\ <daviid>lloda: so far, my libguile-cv.c does not include libguile, but maybe i should <daviid>let paste, I did not push this change yet, i'd be happy to be reviewed :), it is very short <lloda>not including libguile in a Guile wrapper is strange ;-p <lloda>if you want to try BLAS, the function you want is (saxpy! a X Y), which does a*X + Y -> Y, a is a real number and X and Y are f32 vectors (can be general f32 rank-1 arrays, but f32 vectors also work). You can keep accumulating on Y <amz3>I found a new job, I will work with datascientist people building somekind of open data database <amz3>I hope we will be able to free some software... prolly not in guile yet... <daviid>lloda: so far, i wrote a few lines of pure C code, only using basic types and returing int ... no need yet to include libguile... <lloda>daviid: no, of course, if you write C to be called from the FFI, then libguile isn't needed <lloda>it's just that the purpose of the FFI (one of them anyway) is to avoid writing C <lloda>more than there already is I mean <OrangeShark>I give it a couple of months and everything will probably be written in guile there :P <daviid>I think this code is not portable, because I assume a pointer address is uint64 ... <daviid>which i think is system dependent <amz3>OrangeShark: I would love too, but it will be hard to convince the only other developer... which wants to do nodejs <daviid>wdyt? (any C expert can help me to get this snipset 'safe'...) <amz3>maybe mwette knows about that or taylan but both are not here right now <OrangeShark>amz3: yeah I understand. Wish I could add some lisp at my work too. <lloda>using libguile would fix that. It's what I would do. You can use libguile only for the list argument and keep using the FFI for the rest <daviid>lloda: could you tell me what to write? <lloda>the list argument is a void * instead of an s64vector, and the C side declares that as SCM <lloda>then you use scm_vector_ref or scm_car / scm_cdr to get at the elements <amz3>OrangeShark: I figured, that what I am doing with my search engine stuff is useless in a professional context, I mostly do it because that what I want to do aka. I want to use wiredtiger. In a professional context, people would use C/C++ and wiredtiger or Python/JavaScript with elastic search to do the same thing I do <amz3>even if there is many good sides to use guile and wiredtiger like ACID transactions accross data models (graph, document, keyvalue, invertex index, you-name-it) <amz3>multiple threads with guile <amz3>and most of all, I did not really benchmark enough wiredtiger, wiredtiger is still alpha, I see it more clearly, there is many issues with it <OrangeShark>amz3: I use C++ at work, but I think there is always the potential to use guile or other lisps for tools. <amz3>but what tools? I don't need any tools, anything I would write is re-inventing the wheel <OrangeShark>Well at my work we have various data files that would be nice to have some tools to interact with them <amz3>I have the feeling I did not do the best I can do in terms of engineering, I leave many good pratices behind when I code on my free time <lloda>daviid: or rather scm_c_vector_ref. Then you would use [scm_array_get_handle / scm_array_handle_f32_writable_elements / scm_array_handle_release] on each element of the vector more or less like you use [bytevector->pointer / pointer-address] in your ffi code <daviid>lloda: first it does not find my libguile.h, which here /opt2/include/guile/2.2 <amz3>which is actually my goal <amz3>now my goal is to have a good enough search algorithm with a pratical set of indexed websites <amz3>basicaly I lowered my goals <amz3>OrangeShark: for me work, feel like I could do much more if I had the libertity to do it, like if I was in control... <OrangeShark>there is a lot of things I would like to improve at work but we are never given enough time <lloda>daviid: I think, for your example, the easiest thing is actually to use saxpy! although that won't work for other functions such as * and xor w/e <daviid>lloda: I'd like to write all these myself, but my C 'ecosystem' knowledge is zero, i still don't know why it does not find my libguile.h, i though my Makefile.am was correct, but probably not ... <daviid>there only a few, it will be a good exercise for me to <lloda>you use pkg-config? what does pkg-config guile-2.2 --cflags say <daviid>lloda that works fine, but i think there is a bit mising or a tipo in either my guile.am or Makefile.am of the libguile-cv subdir <daviid>lloda: I added these two lines in my guile.mk (which is included in the Makefile.m of libguile-cv) <daviid>GUILE_FLAGS = `pkg-config guile-2.2 --cflags` <daviid>GUILE_LIBS = `pkg-config guile-2.2 --libs` <daviid>libguile_cv_LIBS = $(GUILE_LIBS) <daviid>in the libguile-cv Makefile.am, autogen, configure, make still fails <lloda>I think I just put PKG_CHECK_MODULES([GUILE], [guile-2.2]) in configure.ac ! <lloda>I'm not comfortable with the autotools, though <daviid>lloda: I use the guile macros for that, in this case, <daviid>there must be a stupid thing in my Makefile.am <daviid>I've changed line 41 -> libguile_cv_LIBS = $(GUILE_LIBS) [ not libguile_cv_LIBADD = $(GUILE_LIBS) ] <daviid>line 43 seems incomplete as well <daviid>I actually don't know how to debug this kind of bugs <daviid>I added a target to print the content of both libguile_cv_CFLAGS and libguile_cv_LIBS, they look prety ok to me: <daviid>david@capac:~/gnu/guile-cv/git/libguile-cv 10 $ make printe <daviid>printf ' -pthread -I/opt2/include/guile/2.2\\n' \\ <daviid>printf '-L/opt2/lib -lguile-2.2 -lgc -L/opt2/lib -lguile-2.2 -lgc\\n' <daviid> -pthread -I/opt2/include/guile/2.2 <daviid>-pthread -I/opt2/include/guile/2.2 <daviid>david@capac:~/gnu/guile-cv/git/libguile-cv 12 $ gcc `pkg-config --cflags guile-2.2` \\ <daviid>> -shared -o libguile-cv.o -fPIC libguile-cv.c <daviid>libguile-cv.c:27:10: fatal error: libguile: No such file or directory <daviid>#include <libguile.h>, not #include <libguile> <daviid>then gcc pass, but not when I use my autotool config ... <daviid>david@capac:~/gnu/guile-cv/git 101 $ make <daviid>make[1]: Entering directory '/usr/alto/projects/gnu/guile-cv/git/libguile-cv' <daviid>libguile-cv.c:27:10: fatal error: libguile.h: No such file or directory <daviid> how can I trace how the autotool chain compiles my tiny libguile-cv.c <amz3>ACTION doing git bisect to find out what commit introduced the http-get bug that forbids fetch https pages <daviid>have to go afk for a bit, bbl, if anyone knows how to link libguile in a tiny project using autotool, ping me, thanks <amz3>Ok, I think the bug is fixed in stable-2.2 but that version is not released yet <amz3>but the git log says a bug was fixed about https <amz3>rekado: fwiw http-get works correctly with the branch stable-2.2 <daviid>i'm back :) any autotool, libguile and C debug news? <daviid>too bad, since this works gcc `pkg-config --cflags guile-2.2` -shared -o libguile-cv.o -fPIC libguile-cv.c <daviid>propely displays the right content for these variables, I deduce that autotool does not either call gcc or does not passs these flags and libs as I expect <daviid>i've asked on #autotools, but so far nobody answered (any of my quiz) either, generally they are very helpfull <bavier>daviid: what does `make V=1` say? <daviid>bavier: it reports a bug, but let me paste <bavier>daviid: 'libguile_cv_CFLAGS' -> 'libguile_cv_la_CFLAGS' <bavier>and similarly for _LIBS and SOURCES <daviid>and this applies for libguile_cv_LIB -> libguile_cv_la_LIB <daviid>and the other as well, so i'd have libguile_cv_la_CFLAGS, libguile_cv_la_LIBS, libguile_cv_la_LDFLAGS ? <bavier>because those definitions apply to the libtool archive target <bavier>daviid: automake manual section 3.5 <daviid>bacier, perfect! that solved the problem, man I would never found this by myself <daviid>bavier: yeas, though as usual, I would have to know what to look for to identify the section of the manual I should have red ... then to be honest, I read and forgot, because I do this once in ever years ... but now, that it is solved, I can work on making this libguile-cv.c 'safe', like lloda suggested <daviid>bavier: i was reading our manual, which has a C example, I thought I was doing 'au pied de la lettre', but there was no la example ... <daviid>maybe I should write one and send a patch ... I'm surely not the only casual, not very good C programmer that still needs to write a few thing in C ... and link it usig libguile ... <bavier>daviid: yeah, it takes some skimming <bavier>yeah, an autotools example in the guile manual would be nice, if it's not already there <daviid>but it does not show how to build an 'la' ... so no _la_ example ... I did not know about that subtility ... <daviid>5.2.4 Building the Example with Autoconf <daviid>I was my nose in this the all tie :) <daviid>now I need the help of lloda to improve my f32vectors_add_vectors snipset <daviid>bavier: by the way, my target seems wrong as well <daviid>it works but it reports an error <daviid>ah no, it works fine, sorry for the noise <daviid>bavier what about this variable: libguile_cv_SOURCES <daviid>you see I thought these names 'just' add to have the name of the directory they were in <daviid>I woner if I should update nodist_libguile_cv_SOURCES _ nodist_libguile_cv_la_SOURCES <daviid>and libguile_cv_SOURCES -> libguile_cv_la_SOURCES <bavier>daviid: the directory only comes into play with primaries like PROGRAMS or SCRIPTS, otherwise the variables use the canonicalized form of the target <bavier>daviid: so yeah, it should be nodist_libguile_cv_la_SOURCES <daviid>but the first line should stay unchanged right? lib_LTLIBRARIES = libguile-cv.la <daviid>ok, man your need a phd in autotool to know all these things ... :) <daviid>hum, bavier, since I made the last 2 changes, I have a bug compiling <daviid>make[1]: Entering directory '/usr/alto/projects/gnu/guile-cv/git/libguile-cv' <daviid> CC libguile_cv_la-libguile-cv.lo <daviid>.libs/libguile_cv_la-libguile-cv.o: In function `float_to_int_c': <daviid>/home/david/gnu/guile-cv/git/libguile-cv/libguile-cv.c:34: multiple definition of `float_to_int_c' <daviid>.libs/libguile_cv_la-libguile-cv.o:/home/david/gnu/guile-cv/git/libguile-cv/libguile-cv.c:34: first defined here ... <daviid>yep, these two lines should just be nodist_libguile_cv_SOURCES and libguile_cv_SOURCES <daviid>lloda: so, in my f32vector_add_vectors_c, the third argument, float *v_ptr[], needs to change wrt your proposal? <daviid>lloda: I don't know what to do, my intention before you suggested to use libgule, was to write another C snipset to ask for the size of a pointer address, then call that in scheme to know what vector type to initialize, s32vector or s64vector <daviid>trying to talk to #c but I can not paste, any knows a freenode C channel I could try? <daviid>what is the valid arg_types for a C function that takes 0 argument ? <daviid>lloda: I went another route, I wrote a C function that returns the size of a pointer address, then I don't depend on libguile and the code is (to my opinion) cleaner