<davexunit>civodul: I basically removed everything that was high-level like that <davexunit>given the concurrency renaissance we're seeing, you ought to be able to take the library of your choice (fibers, 8sync, etc.) and hook it up to chickadee's kernel. <davexunit>I haven't done it, but Sly's FRP system can be built on top as well. <davexunit>I feel more free working on this than I felt with Sly. <civodul>i don't like to think in terms of threads so FRP had some appeal to me <davexunit>but I took another swing at writing the rendering engine and I think things are much improved this time around. <davexunit>people seem to still be interested in sly so I ought to rebase it on chickadee. <davexunit>but since this is a guile library I think it's fine <daviid>weird! on my machine everything is fine, then i try to compile guile-cv on another machine, it fails with the weirdest situation i faced in years :). it's been hours I try to understand where the problem comes from, but so far so bad! here is the 'problem': <daviid>david@chatotorix:/opt2/vigra_c/lib 5 $ nm -g libvigra_c.so | grep subimage <daviid>0000000000368de6 T vigra_subimage_c <daviid>this file which uses this symbol compiles fine: <daviid>but the compilation of another module which uses (cv imgproc) fails with this message <daviid> 3 (primitive-load-path "cv/imgproc" #<procedure 55dbb67a4…>) <daviid>ice-9/boot-9.scm:762:26: In procedure dispatch-exception: <daviid>ice-9/boot-9.scm:762:26: In procedure dynamic-pointer: Symbol not found: vigra_subimage_c <paroneayea>ACTION writes the worst "skribe-like" tiny-dsl ever <enderby>does guile have an equivalent to emacs' new if-let? <paroneayea>enderby: I don't know what emacs' is, but maybe and-let*? <paroneayea>another one of those useful abstractions that when I look at it again I'm like <paroneayea>oh shit right I should be using that like everywhere <enderby>awesome yes, this is what i wanted :) <linas>so ... what are thoughts for support of gnu MP floats for guile? <linas>there was an email conversation with mark_weaver, 5-6 years ago about using mpfr for guile arbitrary-precision functions ***Guest38107 is now known as micro`
<daviid>scheme@(guile-user)> (dynamic-link "libvigra_c") <daviid>$2 = #<dynamic-object "libvigra_c"> <daviid>scheme@(guile-user)> (dynamic-func "vigra_imagewidth_c" $2) <daviid>ERROR: In procedure dynamic-func: <daviid>ERROR: In procedure dynamic-pointer: Symbol not found: vigra_imagewidth_c <daviid>the above error is 'impossible', unless $2 would be 'empty': does anyone has an idea on how I could track this problem? I'm totally lost here <daviid>the above works fine on my machine, let's call it machine A, then I copied the exact same libvigra_c.so on machine B, it fails <daviid>avid@chatotorix:/opt/vigra_c/lib 12 $ uname -a <daviid>Linux chatotorix 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux <daviid>david@capac:~/gnu/guile-cv/git 34 $ uname -a <daviid>Linux capac 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux <dsmith-work>Dynamic loading usually provides totally useless error messages. <spk121>dmith-work: how does the func appear in the list returned by "nm -g libvigra_c.so"? <daviid>i don't know what to look for in the strace, it lokks fine: <daviid>... read(7, "(dynamic-func \\"vigra_imagewidth_"..., 4096) = 64 ... <daviid>but in the end it fails printing the error <spk121>daviid: that line is saying that your guile interpreter is reading your scheme source code line, so it isn't the source of the problem <spk121>daviid: Two suggestions. try "nm -g libfoo.so" to see if the function is a "T" or text function <spk121>daviid: or, set environment variable LD_DEBUG=all to get a huge spew of linking debug info <daviid>david@chatotorix:/opt/vigra_c/lib 23 $ nm -g libvigra_c.so | grep imagewidth <daviid>00000000003a494d T vigra_imagewidth_c <daviid>in the trace i can see it loads that lib: <daviid>open("/opt/lib/libvigra_c.so", O_RDONLY|O_CLOEXEC) = 7 <daviid>spk121: tx, trying the LD_DEBUG=all then <daviid>why is it lookinf for libvigra_c_LTX_vigra_imagewidth_c? <spk121>daviid: when you use libtool primitives for dynamic loading, it first looks for funcs that follow the libtool convention, if you've used a libtool module option <spk121>daviid: that's what the LTX is from <daviid>but it anyway report it can't find vigra_imagewidth_c, but that symbol is there <daviid>could it be something wrong with my env variables? or a bad installation (I have guile-2.0 and guile-2.2 (on both machines by the way, but maybe somethng is wrong on machine B ... <spk121>daviid: a few lines ago, you typed "david@chatotorix:/opt/vigra_c/lib" and just now you gave an error for "/opt/lib/libvigra_c.so" <spk121>daviid: did you need to add /opt/vigra_c/lib to your LD path? <daviid>spk121: that is the source of the problem, many thanks!! it appears i had 2 libvigra_c.so, and blindingly tought i had 1, _not_ reading properly, my brain interpreting what i was reading ... /opt/lib/libvigra_c.so and /opt/vigra_c/lib/libvigra_c.so ... wow wow