IRC channel logs


back to list of logs

<daviid>anyone kows where mwette ffi-helper source code is hosted?
<OrangeShark>happy_gnu[m]: use (setlocale LC_ALL "")
<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)
<amz3``>numerobis: values
<numerobis>amz3``: Thanks!
<numerobis>ft: Oh thanks, should have tried that ;)
<OrangeShark>hello everyone
<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
<daviid>lloda, here
<OrangeShark>amz3: congrats :)
<amz3>OrangeShark: tx :)
<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
<amz3>btw I stumbled upon intersting slides about conceptual search
<daviid>lloda: first it does not find my libguile.h, which here /opt2/include/guile/2.2
<amz3>which is actually my goal
<OrangeShark>amz3: I feel like I don't do my best at work :(
<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>amz3: have you heard of hoogle?
<amz3>OrangeShark: no
<OrangeShark>it a search engine for haskell functions
<amz3>it seems fun
<OrangeShark>there is a lot of things I would like to improve at work but we are never given enough time
<amz3>that's it
<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 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 or of the libguile-cv subdir
<daviid>yes, it does not seems ok :)
<daviid>lloda: I added these two lines in my (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>then libguile_cv_CFLAGS = \\
<daviid>libguile_cv_LIBS = $(GUILE_LIBS)
<daviid>in the libguile-cv, autogen, configure, make still fails
<lloda>I think I just put PKG_CHECK_MODULES([GUILE], [guile-2.2]) in !
<lloda>I'm not comfortable with the autotools, though
<daviid>lloda: I use the guile macros for that, in this case,
<daviid>GUILE_PKG([2.2 2.0])
<daviid>there a re all there
<daviid>there must be a stupid thing in my
<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>hum, what a newbie I am :)
<daviid>i don't understand why this does not work:
<daviid>anyone has an idea?
<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>very frustrating
<daviid>pkg-config --cflags 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>
<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>Making all in libguile-cv
<daviid>make[1]: Entering directory '/usr/alto/projects/gnu/guile-cv/git/libguile-cv'
<daviid> CC libguile-cv.lo
<daviid>libguile-cv.c:27:10: fatal error: libguile.h: No such file or directory
<daviid> #include <libguile.h>
<daviid> how can I trace how the autotool chain compiles my tiny libguile-cv.c
<daviid> file?
<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>ACTION still compiling
<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?
<amz3>nop sorry
<daviid>too bad, since this works gcc `pkg-config --cflags guile-2.2` -shared -o libguile-cv.o -fPIC libguile-cv.c
<daviid>and since this target printe:
<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
<amz3>can some close is not useful sorry for the noise et al.
<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: your primary is wrong
<daviid>what is a primary
<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
<bavier>daviid: np
<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>bavier it is there
<daviid>but it does not show how to build an 'la' ... so no _la_ example ... I did not know about that subtility ...
<bavier>ah, ok
<daviid>5.2.4 Building the Example with Autoconf
<daviid>I was my nose in this the all tie :)
<daviid>anyway, thank you so much!
<bavier>good luck
<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>after printing the values
<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>just had
<daviid>here is how my libguile-cv/ looks now:
<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 =
<daviid>ok, man your need a phd in autotool to know all these things ... :)
<kristofer>hello #guile
<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> CCLD
<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>ah it is ##c, not #c
<daviid>what is the valid arg_types for a C function that takes 0 argument ?
<daviid>the empty list ...
<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
<daviid>lloda: here is what I have know which I beleive is portable