IRC channel logs


back to list of logs

***linas_ is now known as linas
***TravisD_ is now known as TravisD
<zacts>morning guilers
<davexunit>howdy wingo
<davexunit>I'm writing some almost modern opengl with figl. :)
<wingo>nice :)
<wingo>i am compiling the particle-demo inner loop to x86-64 assembly :)
<davexunit>I'm writing a basic sprite shader.
<wingo>yay shaders
<davexunit>pushing all of the matrix math to the GPU
<wingo>i am trying to see what the cpu can do in that regard
<davexunit>I am interested in that as well.
<davexunit>I plan to write a particle system at some point.
<davexunit>I learned about "point sprites" recently.
<wingo>the result will be a completely unboxed type-inferred loop, so that should work out fairly well -- the problem as always is bandwidth to the gpu
<wingo>i have the type inference working, just need to write out the assembly now :)
<wingo>also i have the best project name i've come up with in a while, "compost"
<wingo>because it is a leaf function compiler
<wingo>and also it's a steaming pile of bugs :)
<davexunit>haha I like it
<davexunit>now I need to move this hardcoded orthographic projection matrix out of the shader...
<davexunit>and to do that, I need to write a 4x4 matrix record type...
<ft>btw. if someone wants to play with serial devices using Guile, there's now
<wingo>ft: neat!
<davexunit>wingo: if you were writing a 4x4 matrix implementation with performance in mind, would you use a f32vector or something else?
<wingo>davexunit: depends... you are doing the math in guile or on the gpu?
<davexunit>wingo: guile.
<wingo>f32vectors cause allocation on ref because of flonum boxing (at least if you're not composting :)
<wingo>but many other flonum ops box, so dunno
<davexunit>mainly going to use it for computing a projection matrix to hand off to shaders via a uniform.
<wingo>the most expressive thing is to use a uniform array :)
<wingo>make-typed-array 'f32 0 4 4
<davexunit>perfect. thank you.
<foeniks>Can I register an existing type with GOOPS?
<wingo>foeniks: use class-of on the value
<foeniks>great, thanks
<ft>wingo: When writing that, I was wondering if there are any plans on having support in the dynamic FFI for parsing C headers (for defines and typesets and such). Right now, I got a scheme script, that generates a C program, that generates a scheme module, that contains the stuff you need to pull out of the termios.h header. :)
<wingo>ft: dunno :) have you seen what civodul does in libchop?
<ft>wingo: Nope, I don't even know what it is... but google seems to know directions. ;)
<ft>looking now
<wingo>ft: he does something similar to what larceny does,
<wingo>i would like to parse dwarf instead, but maybe that's a terrible option for portability &c
<ft>wingo: Yeah, I found your blogpost on dltool when I was looking into possible routes.
<wingo>running the c compiler is the most robust i think -- terrible, but certainly correct
<wingo>the problem with dwarf is that you might not have CPP defines that you need, and if you do they might be C expressions and not values
<ft>yeah. I'm using offsetof() to determine the layout of struct termios.
<ft>wingo: True. #defines would be a problem with dwarf
<ft>so, libchop actually runs the c-compiler in the guile-compiler run. clever. :)
<ft>Great. Now I'm tempted to do that as well...
<ijp>a trick ludovic stole from larceny, I think
<ijp>.oO(yo dawg, I heard you like compilers)
*wingo writing a register allocator, whee
<wingo>mostly re-using guile's slot allocator, for the moment, and aborting on spill :P
<wingo>yay x86-64
<civodul>Hello Guilers!
*civodul is on a tiny potluck hack
<wingo>heya civodul :)
*wingo too
<civodul>hey wingo
<civodul>cool :-)
<foeniks>(use-modules ..) offers to use a #:renamer
<foeniks>can I also use a renamer on the prelude?
<mark_weaver>if by "prelude" you mean 'define-modules', the answer is yes.
<foeniks>What I mean is, prefixing the rnrs functions etc. something like std:map std:let etc
<wingo>foeniks: you want #:pure
<wingo>#:pure makes it so that you have no "default modules" imported
<wingo>so you have to import them explicitly
<wingo>e.g. (guile)
<foeniks>thanks wingo
<taylanub>Ooh, that C header-parsing stuff is of interest to me too, I had it on my TODO for bytestructures to create a tool like that.
<davexunit>can I use a uniform array like a bytevector to pass a pointer to the CFFI?
<wingo>davexunit: use array-contents to get the backing bytevector
<wingo>ok, register allocation is done, it seems
<wingo>now just instruction emission; fingers crossed
<civodul>yee :-)
<civodul>looks like writing a register allocator has become something trivial for you ;-)
<wingo>haha nope :)
<wingo>the slot allocator was basically what i needed
<wingo>with the restriction that the set of slots is finite
<wingo>and the happy restriction that i just abort if there are too many live values :)
<civodul>yeah, i guess that makes a difference
<civodul>heh :-)
<davexunit>wingo: thank you!
<madsy>Woo.. I can finally generate scheme functions for all the OpenGL functions
<davexunit>I just wrote a 4x4 transformation matrix data type.
<civodul>sounds like you're both doing crazy things :-)
<davexunit>GLSL shaders :)
<civodul>"shaders" is one of those terms that i still find a bit scary ;-)
<davexunit>it's been a pretty painful process trying to figure them out.
<davexunit>broke out my linear algebra text book to remember how to do matrix multiplication today.
<artyom-poptsov>Hi Guilers
<artyom-poptsov>Are there examples of Guile-RPC usage other than these ones that come with Guile-RPC itself?
<civodul>hey artyom-poptsov
<civodul>oh, Guile-RPC :-)
<civodul>i had some code using it, but never published it
<civodul>there's an NFSv2 server in the repo IIRC
<civodul>i would do that differently nowadays
<artyom-poptsov>I did some search on the internet but found no examples yet.
<artyom-poptsov>OK, I'll take a look on NFSv2 implementation.
<wingo>i think i'm just going to re-use the assembler and linker
<stis>evening guilers!
<wingo>heya stis :)
*wingo going ahead and making a dlopen-able elf, hopefully
<civodul>wingo: maybe we'll skip 2.2 and release directly Guile 3 :-)
<wingo>haha :)
*ggrant can't wait till guile-wm gets proper tiling support. :^)
<ft>write it! :)
<ggrant>ft: Not skilled enough, yet, sadly.
<artyom-poptsov>Hmm... Probably I'm doing something wrong, but it seems that Guile-RPC's XDR compiler produces wrong calls to `make-synchronous-rpc-call' from a RPC description -- `arg-type' and `result-type' are passed to the procedure in the wrong order. I've changed `rpc-program-code/client' procedure from `compiler.scm' file so now `arg-type' and `result-type' are swapped, and it seems that generated RPC client procedures work properly.
<artyom-poptsov>I think I can prepare a patch that fixes that.
***TravisD_ is now known as TravisD
<stis>3 predicates is remaining, then iso-prolog will be complete
*stis thinks that supporting abother language is really not a small work
<stis>then i need modules to work, and some sanitizing ideoms that can get rid of some of prolog's quirks that I don not like
<stis>e.g. lambdas and constructs that will remove the need of retract for dynamic variables and hashes based on a modified vhash structure
<stis>err dynamic functions, not dynamic variables, that is something else
<davexunit>ggrant: guile-wm 1.0 has tiling!
<davexunit>I've been meaning to email mark witmer it, though. I haven't quite gotten the hang of tiling.
<ggrant>davexunit: Not just that weird snapping functionality?
<davexunit>ggrant: mark witmer says that guile-wm has stumpwm-like tiling support.
<ggrant>davexunit: Hm, I've yet to see it then. :^P
<ggrant>If that's the ultimate goal of guile-wm, I wonder why the floating wm is enabled by default.
<davexunit>it's goal is to be whatever you want.
<ggrant>davexunit: Well yeah, but isn't there a bias to be a modern, lightweight, scheme stumpwm?
<davexunit>and that's what the tiling module does. guile-wm requires a module to be imported to be a floating wm, too.
<davexunit>that's the tinywm module.
<ggrant>So would I just leave tinywm and append tiling to wm-modules?
<davexunit>you would remove tinywm
<davexunit>they don't mix well, I'm sure you can imagine why.
<ggrant>davexunit: Yeah, that's what I thought -- must have misread you then.
<ggrant>I'll hopefully brb, I'm going to try this.
<madsy>Woo.. I just generated 8000 lines of code
***TravisD_ is now known as TravisD
<madsy>Probably saved me 2 weeks of work
<ggrant>davexunit: Yah! Now to write some commands, to actually make this useful!.
<madsy>Now maybe I should add libxml to this generator so I can automatically generate docstrings from the OpenGL manual XML
<davexunit>I just git reset hard with unstaged work! oops!
<madsy>davexunit: ouch
<madsy>Did you lose a lot of work?
<davexunit>I don't think so... I committed a bunch of stuff before doing it, at least.
<davexunit>I think I'm almost done rewriting what I lost...
<madsy>Have to write about 20 of the OpenGL functions manually because they return pointers, or take double-pointers as arguments
<davexunit>very cool stuff.
<madsy>But that beats writing 550 of them manually
<davexunit>I suck at writing code that writes code :P
<civodul>artyom-poptsov: seems like you found a bug, you can email the patch to bug-guile-rpc
<madsy>davexunit: Me too. I wrote a nasty hack
<madsy>I didn't even use regex
*artyom-poptsov prepares a patch
<madsy>Fire-and-forget code
<wingo>madsy: you know that figl does all of this, right? :)
<wingo>texi documentation from the upstream xml, etc....
<davexunit>wingo: madsy has decided to do all of this with C for some reason that I keep forgetting.
<davexunit>I think he's dealing with embedding guile into an existing piece of software or something...
<wingo>i don't get it though, it would be easier to modify figl to generate c instead
<wingo>but whatever :)
<davexunit>I tried my best to push madsy towards figl :)
*mark_weaver tried a little too
<davexunit>I would like to see an official figl release sometime! ;)
<mark_weaver>yeah, then we could add it to GNU Guix :)
*davexunit has a working GLSL sprite shader
<davexunit>had to sacrifice sprite batches for now, but that's okay.
<artyom-poptsov>civodul: Done. It seems that my patch is the first message posted in Guile-RPC Bugs mailing list since 2010 :-)
<civodul>artyom-poptsov: yeah, it's not been terribly active :-)
<civodul>i'm glad you found it
<artyom-poptsov>I'm going to make use of Guile-RPC in some of my projects, so probably I can fill the gap in examples of Guile-RPC usage in this way.
<madsy>wingo: But figl is for guile itself. I'm using libguile
<madsy>A C++ mainloop runs my application, not guile
<mark_weaver>madsy: I don't see why that matters here. C code can call scheme code, and you're apparently writing wrappers to call GL functions from Scheme, no?
<mark_weaver>and anyway, as wingo pointed out "it would be easier to modify figl to generate c instead"
<madsy>But you two assume I want to expose everything to Scheme. I don't :)
<madsy>For example, the window creation is hidden from Scheme here
<mark_weaver>what's the harm in exposing more to scheme?
<mark_weaver>you can still makes calls from C++ when you want to, no?
<mark_weaver>exposing everything to Scheme doesn't mean that you have to do everything from Scheme.
<ijp>(define-module (madsy-code gl) #:use-module (madsy-code gl private-dont-touch) #:export (madsy-proc1 madsy-proc2 ...))
<madsy>Anyone have an idea what went wrong here?
<madsy>My application bails now because of some error that occurs while registering functions
<madsy>Does it complain about the number of arguments a function has, and that Scheme functions can't take 11 mandatory arguments?
<mark_weaver>madsy: 10 is the max
<mark_weaver>scheme functions can take arbitrary numbers of arguments.
<mark_weaver>so can C functions called from Scheme by the dynamic FFI.
<mark_weaver>but functions defined from C, exposed to Scheme, can take a max of 10.
<mark_weaver>(figl uses the dynamic FFI, so no limit)
<madsy>Hm.. what do I do then.. I have two generated OpenGL bindings that take 11 parameters
<davexunit>I thought there was a patch to allow more than 10 parameters in 2.0.9?
<mark_weaver>davexunit: yeah, I definitely did something like that, but I think that was for the dynamic FFI.
*mark_weaver looks
<mark_weaver>madsy: you could move the last two arguments into a single 'rest' argument, which will become a scheme list of the two arguments.
<mark_weaver>the constraint is: the sum of those three numbers (req+opt+rst) must be no more than 10.
<madsy>Yeah. That's a bit ugly but it will work
<madsy>Because they aren't really optional
<mark_weaver>davexunit: I just checked, and the unlimit patch I did was for the dynamic FFI only.
<davexunit>ah, okay. thanks for checking.
<mark_weaver>madsy: yeah, you'll have to check that the list has length 2.
<madsy>Oh well, these aren't functions I'll be using a lot anyway
<mark_weaver>the issue, btw, is that each arity of C function has an associated VM stub that handles the transition. currently, those are statically provided in gsubr.c.
<madsy>So you need one specific stub for every possible prototype
<madsy>For 1 to N parameters
<madsy>Should be easy enough to make it higher
<mark_weaver>and it's actually worse than that, because there's one for each combination of values (req,opt,rst).
<mark_weaver>so the number of combinations gets rather large.
<mark_weaver>well, O(n^2) anyway.
<mark_weaver>(rst can only be 0 or 1)
<madsy>I'll take these two offending functions out of my generator and provide them manually
<madsy>Maybe I can shave off an argument or two
<mark_weaver>we could dynamically generate larger ones, and keep them in a hash table or something.
<mark_weaver>but my TODO is already full of more important things to do.
<mark_weaver>patches welcome though.
<madsy>mark_weaver: Didn't mean to criticize ;)
<madsy>Anyway, this works now:
<madsy>I just removed the two offending functions
<mark_weaver>madsy: cool!
<madsy>Only thing I wish I could do better is to support actual guile strings instead of using bytevectors for everything
<madsy>My generator is stupidly simple. If it sees a pointer argument, it turns it into a bytevector argument
<madsy>Even for const GLchar* and stuff like that
<madsy>So to use the functions, you have to copy strings into bytevectors and pass that
<davexunit>madsy: is that going from C to Scheme?
<davexunit>because for Scheme to C you can use string->pointer
<madsy>davexunit: Scheme to C. The problem here is that I don't treat char* different from any other pointer in my generator
<madsy>And I don't really know if char* always is a string argument. It depends on the context
<davexunit>so string->pointer won't work for your case?
<madsy>Uh, another random question: Why does guile simply list arguments as _ instead of the argument name?
<madsy>Underscores aren't very descriptive
<davexunit>bah, looks like I'll have to change how I'm doing font rendering in guile-2d.
<davexunit>pango + cairo maybe...
<ijp>madsy: they just don't get snarfed in C, presumably because it was more work, and it never got done
<ijp>if you read the actual documentation, with ,d etc. you will see the names
<madsy>ijp: Right
<madsy>They are in the texi if someone bothered to add the argument names to the documentation, I know :)
<ijp>I don't mean the texi, but the docstrings
<ijp>e.g. ,d setgroups (chosen arbitrarily)
<ijp>the first line gets automatically constructed by SCM_DEFINE I think
<ijp>I'm not sure which table you'd need to poke at to get this information in the print representation