<unknown_lamer>so, if *you* were going to bind an image loading library, would it be ... GEGL, ImageMagick, imlib2, other? <unknown_lamer>I really just want to be able to load bitmaps into uniform arrays and pass them onto opengl <unknown_lamer>unless secretly someone already has scheme bindings for GEGL lying around <davexunit>unknown_lamer: I wrote some minimal bindings for freeimage in guile-2d <davexunit>perhaps I should've chosen another library, but it worked well for me. <unknown_lamer>figl should probably have an LGPLed contrib for loading images to textures, but your (2d textures) + freeimage bindings stuff is enough for me for now <davexunit>I'm not sure if figl should be concerned with that. <davexunit>just provide the GL bindings and other libraries can build what they need. <unknown_lamer>luckily I am far too lazy to care now that I can load an image using guile-2d <davexunit>look forward to a 0.2 release... sometime in the future. <davexunit>unknown_lamer: I might be able to use that. :) <unknown_lamer>hence openal, because I found ALURE while looking for alternatives to libsndfile <unknown_lamer>davexunit: do you know anything about the SDL frame rate manager? <unknown_lamer>mostly if it actually does work to throttle the frame rate and prevent the dreaded swap,swap,swap->block! bit in opengl <davexunit>unknown_lamer: no I don't know anything about that, sorry. <unknown_lamer>the implementation was pretty obvious: start the frame manager with an idealized fps, it forces itself to block, and then time begins... <unknown_lamer>then you call it whenever you are done displaying a frame, it runs a supplied idle function until the frame should be on screen <davexunit>guile-2d draws as fast as possible and updates with a fixed timestep. <unknown_lamer>I'm not doing anything interactive *yet* but ±10ms jitter is kind of ... hrm <unknown_lamer>I just need to rewrite libgc to do wall-clock realtime operation, duh <davexunit>animation jitter can be dealt with via some math. <unknown_lamer>If I am productive, I should have all of the texture related functions bound with figl tonight <zRecursive>I give up building 2.0.9 on freebsd as it is VERY slow to compile *.go files. I will have to use 1.8.8 from freebsd repo. <davexunit>zRecursive: 2.0.9 takes awhile to compile, yes, but I don't see why that should stop you from using it. it's far superior to 1.8.x. <unknown_lamer>zRecursive: it should only be very slow building the first few <zRecursive>davexunit: i will use 2.0.9 until there is package in freebsd repo. i just donot want to compile it from source <davexunit>are you on fairly old hardware? it takes me maybe 10 minutes to compile on my laptop. <zRecursive>davexunit: yeah, it is an old box with only 512M RAM. but it is fast to compile petite,etc. <ArneBab_>(and it’s time for bed … happy hacking!) <whmark>hi, I'm having trouble with guile-ncurses. I've got it installed and guile can find it but I get this error after using `use-modules'. "ERROR: In procedure dynamic-link: file: "libguile-ncurses", message: "file not found"" <davexunit>whmark: dynamic-link is a procedure used to load shared library files. it seems that libguile-ncurses is not in a place that guile can find. <whmark>yeah its in '~/downloads/guile-ncurses/ncurses" but nowhere in /usr <davexunit>whmark: you'll need to do some work to get guile to search that directory. <whmark>there's a bunch of libguile_ncurses*.la/lo files in that directory if I knew where to put them I could get it to work <davexunit>I haven't used dynamic-link in awhile so I can't remember to how to load that file off the top of my head. <davexunit>I've never used guile-ncurses, it's a third party library so perhaps you could try emailing the maintainer for assistance. <davexunit>to do some more debugging yourself, you should read the documentation for dynamic-link in the manual. <whmark>I was able to get it to work. I copied the libraries to /usr/lib and it works <whmark>of course but for reason they didn't get copied or they did but to the wrong place <davexunit>if so it would be a good idea to ping the maintainer to fix their install script. <whmark>yeah I found them there for some reason `find' couldn't find them maybe I entered the command wrong <whmark>but anyway guile didn't find them in /usr/local/lib and so I copied them to /usr/lib <whmark>oh I see I didn't use the * after 'libguile-ncurses' <davexunit>might be an environment variable problem re: /usr/local/lib *davexunit sent updated coop repl patch to the ML. <mark_weaver>whmark: libltdl, the library we use to dynamically load shared libraries, reports "file not found" for pretty much any problem whatsoever, so don't take that error at face value. it could be any kind of linker error. <mark_weaver>for example, if that guile-ncurses was linked against a different major version of guile (e.g. 1.8 vs 2.0) than the one you're using, that's how it would show itself. <linas>I'm confused .. what am I doing wrong? <linas>(catch #t (/ 1 0) (lambda (key . args) (display "ehhhhh"))) <linas><unnamed port>:1:0: In procedure #<procedure f03380 at <current input>:1:0 ()>: <linas><unnamed port>:1:0: Throw to key `numerical-overflow' with args `("/" "Numerical overflow" #f #f)'. <mark_weaver>so you want (catch #t (lambda () (/ 1 n)) (lambda (key . args) (display "ehhhhh"))) <mark_weaver>catch is a normal procedure, so its arguments are evaluated before it gains control. <adhoc>mark_weaver: so leading on from that, if its evaluating the arguements first you want to pass in that list/form in quoted instead? <mark_weaver>adhoc: no, you pass in a thunk (a procedure that takes no arguments). catch invokes the procedure with an error handler established in that dynamic environment. <mark_weaver>e.g. (catch #t (lambda () (/ 1 0)) (lambda (key . args) ...)) <dje42>I can't get (dynamic-link "libc") to work. Blech. <dje42>[trying libc gives me "file not found", yikes] <dje42>Ah. On fc19 /usr/lib64/libc.so is a GNU ld script and libtool apparently doesn't like that. <dje42>libtool doesn't even like my simple .so I created with gcc -fpic -shared (guile calls lt_dlopenext to open the library) <ArneBab>mark_weaver: if you want to test the wisp REPL again sometime, you can now do it with a single shell call: `hg clone http://bitbucket.org/ArneBab/wisp && cd wisp && autoreconf -i && ./configure && make && guile -L . && ,L wisp` <ArneBab>mark_weaver: what does not work is using guile -L . --language=wisp. It complains that it cannot compile ./language/wisp/spec.scm <ArneBab>after running ,L wisp once it works, though. <ArneBab>If I could get this fixed, trying wisp with Guile would become really convenient (I could simply provide a script for running the REPL with guile) <ArneBab>mark_weaver: never mind - I just fixed it myself. It sufficed to ask about it to find a solution ☺ <sneek>I last saw taylanb on Jan 22 at 08:51 am UTC, saying: sneek: seen taylanub. <ArneBab>taylanb: your last message was 2014-01-21 23:49:35, and you left 07:46:24 UTC today <ArneBab>taylanb: wait - are you taylanub? (changed username) <taylanb>Yeah, my "server" at home disconnected (again) apparently. <ArneBab>☹ — that happened for me over the holidays. No backlog for a week… <ArneBab>wingo: congrats on the level3 access! <mark_weaver>hi ArneBab! thanks for the pointer. I even have hg on my homebuilt system thanks to Guix :) <mark_weaver>alas, it seems that proper handling of modules in multiple languages will have to wait until .11. <ArneBab>I don’t have a problem with that. I worked around the issues by adding an implicit pre-compilation step to the repl ☺ <mark_weaver>I've reluctantly decided that .10 is already far too late, and the list of things I hoped to get into it is far too big. <ArneBab>(autotools magic - I grow more and more fond of autotools) <mark_weaver>civodul: there are two major problems that I haven't even looked into yet, but I think should at least be investigated before .10 goes out. <mark_weaver>civodul: one is that apparently Guile doesn't play well with libgc 7.4 (which is now released, btw) unless GC_MARKERS=1 is set. <mark_weaver>and the other is that according to Hydra, Guile compiled with new LLVM/clang just segfaults. 1.8, 2.0, and master all crash on first run. <mark_weaver>this started happening when they made some big change to the LLVM package.. <mark_weaver>btw, there's also libgc-7.2e now, which is actually the one recommended as "most stable" now on Boehm's page. <davexunit>didn't know that hydra was building guile with clang <mark_weaver>civodul: they were released about the same time, so obviously they must be different branches. I remember hearing something about parallel marking by default, or something. dunno! <mark_weaver>civodul: for example, bu^ recently tried building guile from source using GC 7.4, and the compile spent about 8 hours and wasn't going anywhere. setting GC_MARKERS=1 fixed the problem. <wingo>yes we need to disable parallel markers on 2.2 until we figure out what's wrong <wingo>is it also a problem with 2.0? <wingo>bu^'s problem was with master <wingo>for me when i have run into that problem, all cpus are being used by the gc marker and no progress is being made <mark_weaver>hmm, I don't know if it affects 2.0 or not. if it doesn't, we don't have to worry about it right now, I guess. <mark_weaver>but if 2.0.10 would be affected, it would be good to find a solution. *mark_weaver goes afk for a while... <wingo>well i can kick off a build here... <wingo>works fine for me with guile 2.0 <wingo>it could be a guile 2.2 problem, dunno <wingo>i could never reproducibly cause the problem tho ***sneek_ is now known as sneek
*civodul hereby claims that Guile 2.0.4 Works Fine with libgc 7.4.0