IRC channel logs


back to list of logs

<paroneayea>mark_weaver: woohoo!
<paroneayea>it works :)
<paroneayea>thanks for your help :)
***karswell` is now known as karswell
<nalaginrut>morning guilers~
<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 of the manual)? I did a (use-modules (rnrs io ports)) but that didn't work or make sense to me.
<pallagun>also, good morning.
<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.
<mark_weaver>you're welceom!
<pallagun>hah! It does, on the first line too... sorry about that.
<mark_weaver>no worries :)
<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>and you can use the dynamic FFI to get that float *
<mark_weaver>(secion 6.20 of the manual)
<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.
<pallagun>Ah, ok. Makes sense. Thanks!
<mark_weaver>and there are lots of ways to get that float* to the Scheme world.
<mark_weaver>glad to help...
<pallagun>I'm still not too great with the scheme -> C transition. I know the SMOB interface just enough to limp along.
<pallagun>(and C -> scheme)
<mark_weaver>you don't need to use SMOBs for this.
<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.
<mark_weaver>okay. do you know about guile-opengl?
<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.
<pallagun>mark_weaver: Thanks!
<mark_weaver>okay, sleep well!
<mark_weaver>I should have suggested 'bytevector-ieee-single-native-ref' of course (single not double)
<nicferrier>hey chaps
<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>shouldn't configure capture flex dependency?
<nicferrier>perhaps this is something about bipt's repo only?
<nicferrier>mark_weaver: hi mark
<mark_weaver>nicferrier: flex is required when building from git, but not when building from a tarball.
<nicferrier>ah. so tricky.
<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)
<nicferrier>but probably not worth the effort.
<mark_weaver>nicferrier: when building guile from git, you normally start by running ./, 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 does "set -e" as well, so I guess that should have aborted the entire script, no?
<mark_weaver>ah, okay.
<nicferrier>I should probably alter the instructions.
<nicferrier>which means I need to recompile probably. :-(
<mark_weaver>well, the HACKING file asks users to run ./, anyway.
<nicferrier>yes. makes sense.
<mark_weaver>why would you need to recompile?
<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>mark_weaver: I mean to test the installation
<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".
<mark_weaver>ah, okay, sounds good!
<mark_weaver>thanks for working on it.
<mark_weaver>we should really add guile-emacs to GNU Guix
<nicferrier>yeah. probably.
<nicferrier>I am basing this off a pasetbin somebody else did. I was taking to him/her on #emacs
<nicferrier>but he/she didn't leave a name.
<nicferrier>and didn't say what her/his name was on the wiki page or the pastebin.
<nicferrier>so I'm not going to attribute whoever it is.
<mark_weaver>can I see the pastebin?
<nicferrier>it's on the wiki page but sure.
<nicferrier>I am changing it somewhat
<mark_weaver>they forget run to "ldconfig"
<nicferrier>where do you do that?
<mark_weaver>after the guile "make install"
<mark_weaver>and "ldconfig" has to be run as root also.
<nicferrier>I am making instructions for doing it in a prefix
<nicferrier>so no need for root
<nicferrier> - my instructions so far
<mark_weaver>sounds good. in that case, skip the ldconfig, but you'll need other things...
<nicferrier>though I am doing it as I compile
<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
<mark_weaver>there are a couple of ways to do that.
<nicferrier>of course.
<mark_weaver>okay, I'll assume you know about that, then :)
<nicferrier>I was planning on running emacs configure to see if there's an option
<nicferrier>and if not setting LD_LIBRARY_PATH
<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)
<mark_weaver>anyway, time for me to sleep. happy hacking!
<nicferrier>thanks mark_weaver
<civodul>Hello Guilers!
<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
<jordonbiondo>I'm trying to build guile and running into this issue:, I have gettext 0.19.2 installed and gettext.m4 is in /opt/local/share/aclocal/gettext.m4, but it seems from what I'm reading that ./configure won't find it there, how can I specify which location to look? (if that even is the problem)
<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
<mark_weaver>sounds like progress :)
<jordonbiondo>wow these .go files.....
<lloda>morning mark_weaver, about running the tests under both interpreter & compiler
<lloda>could you have a look at the 1st patch here
<lloda>the tests produce errors but the test suite doesn't count them as failures. Is there a different way to write these tests?
<dsmith-work>"Morning" greetings, guilers
<stis>hej dsmith-work
<paroneayea>hei, *
<mark_weaver>hi paroneayea!
<paroneayea>hey mark_weaver :)
<paroneayea>davexunit: around?
<paroneayea>want to brainstorm with me for a second?
<davexunit>paroneayea: hey! sure.
*sneek concentrates *really* hard, but doesn't even generate a brain drizzle, let alone a brainstorm
<davexunit>sneek: botsnack
<paroneayea>davexunit: I wonder what you think of this
<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
<paroneayea>I like thow results come back in ansible
*davexunit looks
<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>or rather procedures that use that type.
<paroneayea>rather than using generic methods in goops
<davexunit>a task could have a field that stores the procedure that does the work, yeah
<paroneayea>now I remember why that was trouble though.
<davexunit>a data type is only necessary if there's more data than that, though
<davexunit>does a task have any meta-data?
<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.
*paroneayea shrugs :)
<davexunit>paroneayea: gotta go! would be happy to talk more later
<paroneayea>davexunit: have a good one!
<rlb>mark_weaver: sent s390x and sh4 patch to guile-devel. Shout if the commit message is still not quite right.