***karswell` is now known as karswell
<pallagun>very basic question, but I can't find it in the manual: What do I have to do to be able to use the make-bytevector function? (section 6.6.6.2 of the manual)? I did a (use-modules (rnrs io ports)) but that didn't work or make sense to me. <mark_weaver>pallagun: hi! you need to import the (rnrs bytevectors) module <pallagun>mark_weaver: Well then, that did the trick. Thanks <mark_weaver>Section 6.6.6 (Bytevector) mentions (rnrs bytevectors) near the top. <pallagun>hah! It does, on the first line too... sorry about that. <pallagun>more open ended question. I've got some C that spits out a pile of floats (for vertex data), am I going down the right path here with the bytevectors? <pallagun>I was hoping I could get a grip on a float * in C somehow and populate it that way. <mark_weaver>pallagun: yes, I think bytevectors are the right tool for that. see 'bytevector-ieee-double-native-ref <mark_weaver>once you have the float* as a SCM pointer object, you can use 'pointer->bytevector' to access it as a bytevector for Scheme. <pallagun>mark_weaver: I did see the ieee single/double functions, they looked promising. <mark_weaver>and there are lots of ways to get that float* to the Scheme world. <pallagun>I'm still not too great with the scheme -> C transition. I know the SMOB interface just enough to limp along. <mark_weaver>it might be the right tool for this job, but there are many others. <pallagun>probably not, but I use the SMOBs for the other objects in the program <mark_weaver>how would you prefer to do it? would you like the C code to call a Scheme procedure, or Scheme to call into C, or access a float* global variable? <pallagun>Presently, I've got a C program that calls some SMOB init code (very similar to the manual's example) then drops me into a scheme prompt <pallagun>from there I can get quite a bit done. I'm working on getting an OpenGL display now. I have one working for some constant data I defined in a .scm file. <pallagun>I do, and I'm using it. So far so good on that front (I think). <pallagun>my task now is to get my SMOBs (geometry) to take the place of the const data (in a .scm file) as the thing to be rendered <pallagun>I will give the bytevectors a shot. But first it's bedtime. <mark_weaver>I should have suggested 'bytevector-ieee-single-native-ref' of course (single not double) <nicferrier>I am just compiling bipt's guile for his emacs and I got through configure and then started make and it failed because of a flex depend. <nicferrier>perhaps this is something about bipt's repo only? <mark_weaver>nicferrier: flex is required when building from git, but not when building from a tarball. <mark_weaver>but there are no tarballs yet for guile-emacs, so I guess you need flex. sorry about that :-/ <nicferrier>I wonder if that could be checked in configure. I guess it could (is there a .git in the configure script directory? we need flex) <mark_weaver>nicferrier: when building guile from git, you normally start by running ./autogen.sh, and that runs "flex --version", so I guess you should have seen an error message at least. <nicferrier>aha. good point. I didn't do that. I was following someone else's instructions and did autoreconf -vif and automake --add-missing instead. <mark_weaver>and autogen.sh does "set -e" as well, so I guess that should have aborted the entire script, no? <mark_weaver>well, the HACKING file asks users to run ./autogen.sh, anyway. <mark_weaver>if it's relevant, we only use flex to tokenize our own C code when "snarfing". we don't use flex to create any lexer that is used outside of the build process. <nicferrier>I'm trying to write an installation script because no one else has right now. <nicferrier>quite a few people want to try it but it's in one of those "only the developer can build this right now". <nicferrier>I am basing this off a pasetbin somebody else did. I was taking to him/her on #emacs <nicferrier>and didn't say what her/his name was on the wiki page or the pastebin. <nicferrier>I am making instructions for doing it in a prefix <mark_weaver>sounds good. in that case, skip the ldconfig, but you'll need other things... <nicferrier>and you know guile compilation very well I'm sure. <mark_weaver>you'll need to arrange for emacs to find the correct libguile shared library <nicferrier>I was planning on running emacs configure to see if there's an option <mark_weaver>you'll want to set ACLOCAL_PATH to PREFIX/share/aclocal before running the autotools bootstrap for emacs, so that it has the right guile.m4 to incorporate. <mark_weaver>and you'll want to set PKG_CONFIG_PATH to PREFIX/lib/pkgconfig before running the emacs ./configure, to get the right CFLAGS and LDFLAGS for linking to libguie <mark_weaver>and now I'm wandering into areas where my knowledge is less clear, but it *might* be sufficient to set LD_RUN_PATH to PREFIX/lib while building the emacs, to arrange for it to find the right libguile without setting LD_LIBRARY_PATH. <mark_weaver>(civodul would be the best person to ask about rpaths, from his work on Guix) <taylanub>I wonder how many implementations will support the "\\<whitespace><line-ending><whitespace>" backslash escape in string literals. (whitespace after the \\ on the upper line, and leading whitespace in the continuation line, are all removed) <taylanub>it seems like a good idea to me (R7RS specified it) <lloda>what do you do if you want leading spaces on the next line? <taylanub>lloda: you break the line at another point. makes sense IMO <taylanub>hm, call-with-port closes the given port, but with-(input-from|output-to)-port don't <taylanub>nvm, guile has no call-with-port (yet), that's just r7rs <mark_weaver>jordonbiondo: set ACLOCAL_PATH to /opt/local/share/aclocal and then rerun autoreconf -vfi and ./configure <mark_weaver>(the .m4 files are needed when ./configure is created) <jordonbiondo>mark_weaver: thank you, configure is running now! make is failing... but that's a different issue <lloda>morning mark_weaver, about running the tests under both interpreter & compiler <lloda>the tests produce errors but the test suite doesn't count them as failures. Is there a different way to write these tests? *sneek concentrates *really* hard, but doesn't even generate a brain drizzle, let alone a brainstorm <paroneayea>also, the bottom part doesn't work yet, because those tasks don't exist, and neither does run-tasks yet <paroneayea>the idea is you define tasks and give it the arguments that will be passed into the body, but they aren't executed immediately... the reason not using just currying is that the task classes might provide some other methods like needing to define how they're displayed when the tasks are run, etc <paroneayea>(define-task) works, you can see copy-this-file as an example, it's pretty dumb <paroneayea>I don't have anything about sending results back <paroneayea>I'm somewhat thinking about having some results object that tasks report back by filling out, not sure if that's too heavy <paroneayea>maybe something simpler can be done, I'm not really sure <davexunit>I'm curious if you need to define a new data type for each type of operating <paroneayea>davexunit: I'm not so sure it's the best design myself :) <davexunit>I'd try to define a single data type to represent tasks and write some functions on top of it <paroneayea>could just be that the task itself stores the exec-task method <davexunit>a task could have a field that stores the procedure that does the work, yeah <davexunit>a data type is only necessary if there's more data than that, though <davexunit>right now it seems like plain ol' procedures would be enough. <paroneayea>davexunit: tasks don't yet, but the design is that they also need to store their representation <paroneayea>otherwise else, procedures probably would be enough <paroneayea>I keep trying to pair this down to just functions but I keep hitting some issue with the requirements I spec'ed up. There's not metadata yet, but there would be if I did this whole thing. <davexunit>paroneayea: gotta go! would be happy to talk more later <rlb>mark_weaver: sent s390x and sh4 patch to guile-devel. Shout if the commit message is still not quite right.