***linas_ is now known as linas
***TravisD_ is now known as TravisD
<davexunit>I'm writing some almost modern opengl with figl. :) <wingo>i am compiling the particle-demo inner loop to x86-64 assembly :) <wingo>i am trying to see what the cpu can do in that regard <davexunit>I plan to write a particle system at some point. <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>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... <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? <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 :) <foeniks>Can I register an existing type with GOOPS? <wingo>foeniks: use class-of on the value <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. ;) <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 *civodul is on a tiny potluck hack <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>#:pure makes it so that you have no "default modules" imported <wingo>so you have to import them explicitly <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>looks like writing a register allocator has become something trivial for you ;-) <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 <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 :-) <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>Are there examples of Guile-RPC usage other than these ones that come with Guile-RPC itself? <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 <wingo>i think i'm just going to re-use the assembler and linker *wingo going ahead and making a dlopen-able elf, hopefully <civodul>wingo: maybe we'll skip 2.2 and release directly Guile 3 :-) *ggrant can't wait till guile-wm gets proper tiling support. :^) <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. ***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>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. <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. <ggrant>So would I just leave tinywm and append tiling to wm-modules? <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! <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 <madsy>But that beats writing 550 of them manually <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 *artyom-poptsov prepares a patch <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 <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! ;) *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 :-) <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>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>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>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. <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>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. <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>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). <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. <madsy>mark_weaver: Didn't mean to criticize ;) <madsy>I just removed the two offending functions <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>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. <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>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 