<unknown_lamer>bipt explained what the compiler does... it stores the boxed float on the stack <unknown_lamer>I think the packed-struct unpacking stuff is spewing garbage actually <davexunit>well what about the floats resulting from regular math operations? <unknown_lamer>intermediates that are not mutated should end up in the local object table iirc <davexunit>so they should be in the local object table? <unknown_lamer>I almost have a basic and very poorly implemented vertex/fragment shader loader <davexunit>I have written some code around that awhile ago. <davexunit>was bipt referring to what the rtl compiler does? <davexunit>I'm going to compile guile master and see if guile-2d programs even run. <davexunit>I've been really having a hard time with coming up the right API to describe pieces of a game (main menu, battle screen, etc.) <davexunit>and I'm also working on how to reduce GC runs <nalaginrut>besides, since it's named guile-2d, maybe support HTML5 in the future? <davexunit>nalaginrut: I don't know how I could possibly do that. <davexunit>you could write a small rpg from with what is in master, though. <davexunit>there's still tons of rough edges. been trying hard to figure out an elegant API and having trouble. <davexunit>nalaginrut: there are probably bugs, but there is an audio module. <davexunit>in fact I know there are bugs in it, but sound is very low on my priority list. <davexunit>I've also been working on why animation was looking really choppy and unpleasant looking. <davexunit>right now it's a really really simple wrapper around SDL <davexunit>thank you. I would love suggestions for how to make things better. <davexunit>like I said, I've been having a difficult time designing some things lately. <nalaginrut>I understand, I'm facing a hard time for Artanis, I have to learn much about ORM <nalaginrut>davexunit: I think there's actually no (sdl mixer) which appears in audio.scm ? <nalaginrut>maybe this: GUILE_SDL_OPTLIB([mixer],[Mix_OpenAudio]) <davexunit>yeah, I didn't know how to enforce guile-sdl being installed <davexunit>could you explain what that line does? I can't make sense of autotools. <nalaginrut>davexunit: it's actually a macro defined in guile-sdl <nalaginrut>use it to checkout if guile-sdl was installed and contains mixer feature ***fangism is now known as fangism-shadow
***linas_ is now known as linas
<nalaginrut>it seems strange that '(a b . c) ==> (a . (b . c)) in Guile, for other Scheme I've tested, it's '(a b . c) <nalaginrut>although it's same result for car/cdr, I don't know if it'll effect 'match' <kindahero>hi there, I like to use guile to prototype a scientific application. it <kindahero>requires to read and write netcdf files. is there any netcdf4 binding for guile.? <b4283>wow, never heard of such a file format until just now <b4283>nalaginrut: what's even more is that you could find a guild binding right away :P <kindahero>@nalaginrut ohh Thanks. do a web search before asking questions. :/ <madsy>nalaginrut: Do you happen to know how to do docstring snarfing? <madsy>Or do I have to eyeball the libguile sources? :) <nalaginrut>ah, unfortunately I never tried snarf, but I'd like to <madsy>I already do normal snarfing. But it seems it's also required to get docstrings from the C procedures <madsy>But how to do that isn't documented <madsy>I'll look around in the sources <mark_weaver>nalaginrut: can you elaborate on your comment "it seems strange that '(a b . c) ==> (a . (b . c)) in Guile, for other Scheme I've tested, it's '(a b . c)" ? <mark_weaver>when I type '(a b . c) in guile, it prints back (a b . c) <mark_weaver>anyway, (a . (b . c)) is the exact same data structure, and thus cannot be distinguished from (a b . c) <nalaginrut>mark_weaver: what's your version? mine is 2.0.9.92-d3606 <nalaginrut>anyway, I realized it won't effect my program, but it's strange <madsy>'(a b . c) => (a b . c) here, in 2.0.9 <mark_weaver>nalaginrut: is this stock guile 2.0.9, or are you using your custom print hook with highlighting? <mark_weaver>(I've forgotten the details of your REPL extensions, but it seems a likely cause for this) <madsy>mark_weaver: I'm using stock 2.0.9 and get the same results as you, even in Geiser <nalaginrut>mark_weaver: hmm...you mean guile-colorized, yes I'm using it <mark_weaver>nalaginrut: I suspect the bug is in guile-colorized. <mark_weaver>my guess is that you're checking whether to print '.' by seeing if the cdr is a 'list?', but you should rather be checking if the cdr is a 'pair?'. <nalaginrut>I never know that the dot could hide when cdr is pair of null <madsy>Hooray for rainbow-delimiters mode <madsy>I forgot to install it after getting a new laptop <lloda>Hello there, could I get some feedback about those old array patches? yesterday I tried rebasing on master and I had conflicts with compile-assembly (which is gone) where I had fixed some of the array syntax read bugs. If the patches are good, it'd be better to merge before master diverges further... <lloda>I'd also like to finish the deprecation of the generalized-vector stuff... <wingo>would you mind sending me a mail again? i will do it tomorrow <wingo>apologies again for the delay <wingo>but now since rtl landed my brain is more free <civodul>lloda: apologies, i think i'm guilty <wingo>thank you for your patience! <wingo>civodul: i can take it if you like -- i have time tomorrow <lloda>sure, will send an email with a summary today :D <wingo>lloda: also any failing test cases on master would be great <wingo>i was surprised that more array things didn't fail <wingo>which probably means that we are lacking in tests <lloda>the patches add a fair amount of testing <madsy>Hah, awesome! I got the doc snarfing working <madsy>But I stole the scripts and tool from the guile 2.0.9 sources <madsy>nalaginrut: I can make one, as soon as I actually get this .doc file loaded <madsy>Not entirely working until the last step works <madsy>Oh, wait.. I have to compile the doc files <wingo>see libguile/Makefile.am, or the corresponding thing in guile-gnome <madsy>I thought ice-9 documentation could use the .doc files directly <wingo>no it needs a text-rendered texinfo file <madsy>Also, "documentation-files" in ice-9 documentation takes absolute paths. Ew <madsy>Wonder if I can change that when I need libguile self-hosted <madsy>wingo: They seem to have their own tools <madsy>So: doc->tex->txt ? Seems to be the steps. <madsy>wingo: Do you know which format the .doc files are in? <madsy>Maybe it's a custom format only used by the guile build process <madsy>Aha! guild has an undocumented parameter "snarf-check-and-output-texi" <madsy>wingo: Finally works now. Making a HOWTO now :) ***goto is now known as anderson
<dsmith-work>wingo: Speaking of doc snarfing... Did you mention something about keeping docstrings in a special section of .go files? <wingo>they are in the .guile.docstrings section, or something like that <unknown_lamer>I have a slightly better (well, uglier still) version that eliminates use of the standard vertex and color arrays <wingo>unknown_lamer: neat :) now the trick is to do the particle effect with the vertex shader instead of with guile <unknown_lamer>all of this by the seat of your pants error checking is for losers <wingo>yes i would start with debugging things first, tbh <wingo>checking linking/compilation errors for shaders, getting out the error string from the driver <wingo>otherwise you're gonna have a bad time... <wingo>ah ok, perhaps i missed that <unknown_lamer>if shader source loading / compilation or program linking fail, it extracts the gl diagnostic <wingo>anyway be careful with garbage though, don't make lists on the hot path if you can avoid it <unknown_lamer>there are limited cases where you can even really detect errors! <unknown_lamer>and if you have more than one gl context in a program in different threads, afaict you literally cannot determine what set the error state <davexunit>I'm really interested to see if you can reduce the amount of garbage, unknown_lamer <davexunit>I was curious if the new rtl version of guile would magically reduce GC runs for the particles demo. It did not. <wingo>haha, then you can't complain about stuttering then :) <wingo>davexunit: right, i had the same experience <wingo>i guess the garbage is all flonums <wingo>well, there will be ways to fix that i think -- but they will take a little longer <wingo>with rtl though we can think about having unboxed values on the stack <wingo>that would totally fix this issue <davexunit>if you're confident that it can be addressed, then I will not do what I was planning: writing a C extension for particle simulations. <davexunit>unknown_lamer: with unboxed values, the GC runs will reduce to almost nothing. <wingo>davexunit: i'm confident that we can fix it but writing a c extension might still be a good idea ;) depends on what you want to do... <wingo>if i were to do it i would compile to asm directly... <wingo>but that's getting ahead of myself i think <davexunit>I would like to keep things in pure guile if possible, but batch rendering sprites or particles or anything that is moving is expensive. <wingo>i would do scheme -> tree-il -> cps, optimize the cps, verify that it type-checks, then use the cps to emit unboxed C or assembly <davexunit>each frame: move sprites, fill a vertex array, draw it, watch the GC run. <wingo>which would create a foreign function that could operate on a scheme bytevector <wingo>that way you're still programming in scheme <wingo>you can still use lovely macros, you have control over your toolchain, etc <davexunit>that would be very nice. do you see this as something that could arrive for 2.2 or something much farther down the road? <madsy>I want to make a small DSL for shaders <wingo>davexunit: dunno, i would do it on the side i think -- it wouldn't have to ship with guile <madsy>Can't be that difficult, can it? <wingo>madsy: should be fairly straightforward i would think <madsy>At least if I keep it simple. Just turn a bunch of symbols into strings and concaternate them together <unknown_lamer>after getting a bit more of a handle on using shaders, I want to do GLSL sexp notation <davexunit>wingo: okay. I'm just trying to gauge which route I should go. maybe I'll write the C extension in the meantime and happily delete it should the given optimizations come along. <davexunit>unknown_lamer: I think that is what madsy is talking about. <unknown_lamer>similar to parenscript, before the current maintainer forcibly took over the project (grumble grumble) and ruined it <unknown_lamer>rather than trying to compile scheme -> glsl, I just want glsl in scheme <madsy>unknown_lamer: What's the difference? I don't follow <unknown_lamer>you'd lose the entire standard library etc because glsl program sizes are pretty limited, so why bother trying to fit scheme semantics on glsl ... <madsy>I was thinking of just making a macro which lets you write shader code without putting everything inside strings <wingo>davexunit: well, if you assume functions that take some sequence of f32vectors and float32 variables and return some error or success code it would be possible to go from optimized cps -> assembly in a weekend <wingo>for a subset of scheme anyway <madsy>Though wouldn't use of quotes and parantheses be a problem when handed to a macro? <wingo>you could hook that up to fork/exec of gas and be on your way <madsy>(define-shader shader (void main(){ gl_FragColor = vec4(1.0); })) <wingo>of course eventually we want to do native compilation for everything and we'll have an assembler in guile, so you can make machine code directly <madsy>Wouldn't "()" mess up stuff? <wingo>doing some special-purpose code generation in the meantime seems appropriate <wingo>you get to use all the xmm registers you want :) <madsy>unknown_lamer: I don't see a reason to take a shader type :) <unknown_lamer>where &body is something like (define (main -> void) (set! gl-frag-color (vec4 ...)) <davexunit>wingo: native compilation will be very nice, and I agree with you about some special code generation as a short-term solution. <madsy>unknown_lamer: Okay, so you want a scheme dialect for GLSL <madsy>I quite like the GLSL language :) <unknown_lamer>now I'm kind of wondering, since GLSL has limited data types and is really oriented toward float processing... <wingo>unknown_lamer: don't get distracted! :) <unknown_lamer>wingo: naturally, step one is "can set uniform variables" :) <unknown_lamer>step two is "do something more than screw around with the particle demo" <davexunit>is it possible to ship off all of the particle effect computation to the gpu? <madsy>Billboarded particles can be passed to OpenGL as GL_POINTS. If you set glPointSize to greater than 1, you get quads <davexunit>madsy: now what about moving the particles? can the shader do that as well? <madsy>davexunit: Sure. Just pass in a matrix to transform the points with <unknown_lamer>just pass time to the vertex shader, then integrate velocity over time to compute the current position <madsy>davexunit: Again, yep. Billboarded GL_POINTS also have texture coordinates <davexunit>madsy: but you're still doing the movement in scheme, right? <davexunit>ideally, I would like to just make the vertex array and let the shader do the rest. <madsy>davexunit: What? Nope. Just pass a shader and transform the points in the vertex shader <madsy>If you need to move individual points, store the matrices in a texture buffer and read it in the vertex shader <davexunit>yeah, I would want to move each particle around. <madsy>Or rather, a position vector. A matrix is overkill <davexunit>but all of the vertex mutation should be done in the shader, seems in scheme it will cause tons of gc runs. <madsy>davexunit: Are you familiar with buffer objects in OpenGL? <madsy>Okay. Buffer objects is just an object abstraction for a chunk of video memory. You upload a bunch of data to the GPU, and it resides in vram. <madsy>Then you can refer to that data via a buffer object name <madsy>Texture buffers are the same thing, only you can actually access the data inside shaders <madsy>So to translate individual points, you could do something like: void main(){ int id = gl_VertexID; vec4 pos = texelFetch(sampler, id); gl_Position = projectionModelviewMatrix * pos; } <madsy>To update the matrix array on the fly, you would use glMapbufferRange() <madsy>I got matrices on my mind, it seems <davexunit>so glMapbufferRange would do the actual mutation? <madsy>glMapBufferRange maps a portion of video memory to a C pointer, so you can read/write data in a buffer object <madsy>The copying of the data, yes <madsy>The positions have to come from somewhere <davexunit>moving particles is what costs so much in GC. <madsy>Well, what is your suggestion? How do you want to move them? Procedurally? <davexunit>doing 5000+ floating point operations per frame is painful in Guile right now. <madsy>You can do that in a shader too. Just add some sine waves or something. <davexunit>I don't have a suggestion. I was just wondering what my possibilties were. <madsy>Well, if you want to do different stuff per point (sprite), gl_VertexID is a counter that is unique to each point <madsy>You can use that for lookups or as a scale <davexunit>moving everything by a given velocity would be enough. <davexunit>anyway, I have to head out for a bit to get a city parking pass. <unknown_lamer>wingo: can you generate a program in one thread and then have another thread execute it without weirdness happening? <wingo>unknown_lamer: you mean a shader program or a guile program? <unknown_lamer>what I would like to do that might be Wrong (tm): spawn the glutMainLoop in a dedicated thread, use a queue to send code to that thread's display or on-idle handler for evaluation <unknown_lamer>there wasn't some sort of lockless queue hiding guile that I've missed was there? <wingo>if it's just every frame and there is low contention you don't need it to be lockless <wingo>you just need an async queue <wingo>which is basically the same thing <civodul>oh i hadn't noticed that mark_weaver had added other ASM_* macros in the VM <wingo>ah neat, i hadn't seen that either <wingo>dunno, i think ijp is curating it currently <unknown_lamer>I saw the mvar in core email, seems like a reasonable module to throw in there <davexunit>unknown_lamer: come to the dark side. (are we the dark side?) <unknown_lamer>I think hacking everything I miss onto guile is slightly less effort than the eventual need to write a common lisp compiler if I don't ;) <davexunit>wingo: you wrote guile-gnome, correct? would you be able to briefly explain why you used GOOPS? I'm still trying to understand the use-cases for object oriented programming in Scheme. <wingo>i used goops because the gnome libs are object-oriented <wingo>also the project was originally started by someone else <davexunit>wingo: okay. that makes sense. have you used GOOPS outside of that project? <wingo>dunno, i usually don't reach for goops, but it's nice to know that it's there <wingo>i've used goops for some things and i would do it again, anywhere I want MOP-like extensibility <wingo>rather than functional composition <wingo>i was going to use it for a ggplot2-alike in guile but didn't finish it <davexunit>maybe I should just use GOOPS for what I'm doing. <wingo>it was the reason i got involved with guile's compiler, because i realized goops would never be fast without scheme being fast <davexunit>I'm slightly worried by the overhead of GOOPS, but it might be the only nice way to design certain things. <unknown_lamer>at least once upon a time it was optimized highly, not sure how much of that is true in the 2.0 world <unknown_lamer>IIRC generic dispatch is still cached and goops classes don't have much overhead over records <davexunit>I'm trying to figure out the best way for someone using guile-2d to say: "this is the main menu scene. it has it's own special data that guile-2d couldn't possibly know about. here is how to draw it, update it, and respond to input." <davexunit>right now, I have a "scene" record that holds the callback procedures and has one slot called "data". <unknown_lamer>I'm toying with the idea of wrapping things like shaders in objects and using a guardian + after-gc-hook to "garbage collect" them (taking advantage of being able to mark things for deletion that GL owns and GL supposedly being smart about it) <wingo>unknown_lamer: that way lies badness <wingo>you have no guarantees about the context that the finalizer runs in <davexunit>to me, it seems like what I've done is written a crappy vtable. <wingo>the finalizer will likely be called from a different thread entirely <wingo>davexunit: right, maybe goops is the thing. dunno :) <davexunit>or it could be that I have the wrong idea of how to do something. <gjanssens>Hi, I'm having some issues in gnucash with guile2 <gjanssens>It looks like the-environment has been redefined since guile 1.8 <ijp>is this a problem in your code, or in gnucash itself? <gjanssens>One of the gnucash reports using this parameter is bailing out with a back trace <gjanssens>There is a bug report on the gnucash bug tracker for this: <gjanssens>I didn't write the gnucash report, but I worked a lot on getting gnucash to work with guile 2 <gjanssens>(continuing on the patches Andy Wingo kindly provided quite some time ago) <gjanssens>I'm trying to get this bug fixed, but the errors are in some fairly low level regions of guile <gjanssens>Lower than my current experience goes unfortunately <ijp>can you point me to where in gnucash this code is? <wingo>gjanssens: does gnucash do guile 2 already? neat <gjanssens>This is one of three files using the-environment <wingo>gjanssens: probably you just have to import the (ice-9 local-eval) module into whatever environment that report runs in <wingo>the-environment and local-eval moved to that module <gjanssens>wingo: I did include it, but that got me a different back trace <ijp>well, the problem will be that eguile isn't using local-eval, but regular eval <ijp>assuming I haven't grossly misremembered those patches <wingo>ijp: the-environment should work anywhere, no? <wingo>you can only use it as an arg to local-eval <wingo>but i think that was the case already in guile 1.8 <gjanssens>From the eguile-gnc.scm: (local-eval s-expression (or env (the-environment))) <wingo>gjanssens: yes, just add a (use-modules (ice-9 local-eval)) to the right place <wingo>using the usual cond-expand trick <gjanssens>wingo: that was my last attempt before I came here <wingo>what a nasty backtrace, sorry 'bout that <wingo>ERROR: Wrong type to apply: #<syntax-transformer the-environment> <wingo>that means that when compiling a scheme file, the expanded looked to see if the-environment was a macro or not <wingo>so it residualized a call to a variable that wasn't known at compile-time <wingo>but you modified a separate file, to provide the-environment <wingo>the definition you provided wasn't a procedure -- it's a macro <wingo>this problem can occur when you have separate compilation (as we do) without proper dependency tracking (as we unfortunately don't have) <wingo>probably if you remove your guile compilation cache it will try again <wingo>though of course, fingers crossed :) <wingo>this is assuming that you have auto compilation enabled <wingo>s/a scheme file, the expanded/the taxreport.scm file, the expander/ <gjanssens>The syntax-transformer error didn't happen once I used the (cond-expand trick... <gjanssens> (use-modules (ice-9 local-eval))) ; for the-environment <wingo_>gjanssens: right, you need to use cond-expand <gjanssens>ERROR: source expression failed to match any pattern <wingo_>there should be a couple more frames there <wingo_>gah, we have two backtrace printers, and the one that case uses is terrible <wingo_>well, even worse than the other, rather ;) ***wingo_ is now known as wingo
<gjanssens>How can I make guile print the full backtrace ? <wingo>don't know; usually the frame count should go down to 0 instead of stopping at 3 <wingo>can you paste a link to where the eguile files are? <gjanssens>the updated files are only in my local git repo <wingo>so the bt mentions entry in entries <wingo>where is that for macro defined? <wingo>is that a gnucash thing somewhere? <wingo>otherwise it could simply be a report that hasn't worked for a long long time -- guile 1.8 treats "do" as a value as a normal thing, but to guile 2.0 it's an early syntax error *gjanssens is looking where the for syntax comes from... <gjanssens>That's a branch with the cond-expand changes included <wingo>have you tried removing your .cache/guile ? <wingo>gjanssens: are you sure that the eguile-utilities module is imported when evaluating reports? <gjanssens>wingo: on top of the taxinvoice.scm file is this: <gjanssens>(use-modules (gnucash report eguile-utilities)) <wingo>this could be a local-eval vs use-modules problem <wingo>use-modules is designed to be run at top level <wingo>or could it somehow be that the-environment isn't capturing the module.... hummm <wingo>gjanssens: can you show me the code that loads taxinvoice.scm? <wingo>it looks like it should be fine tho <gjanssens>wingo: I have to look for it a bit as well, but part of it happens here: <wingo>gjanssens: actually i think i found it <wingo>so hard to read scheme without proper indentation :) <wingo>gjanssens: do you have a tree i can check out? <wingo>DerGuteMoritz: thin syntax-rules layer over for-each, it seems <ijp>DerGuteMoritz: if we had a beer for every time a lisper wrote a loop macro, we'd all die of alcohol poisoning *ijp chugs his cup of tea <gjanssens>I'll come back later, so I'll check for other questions/suggestions ***gjanssens is now known as gjanssens-afk
<stis>ijp: I've parted loop and racket matcher, drink that! muhahahahahaha... <ijp>stis: I've used the matcher, and for the sake of politeness, I will not comment on CL's loop <stis>ijp: no the CL loop port was really a ploy. <stis>also the racket matcher is nonfunctuional, which means that it can destroys tricks with delimited continuations <stis>but still nice to have if one is porting over code from racket. <stis>anyway, i'm fighting my way right now on implementing prolog! <stis>funnily the hardest part is to get references of functions in any sane way, still enabling normal prolog programs to work. <stis>Also I do not want to pay for aiso specification so the documentation is very thin. <davexunit>wingo: just saw your latest tweet and instantly new what HN comment section it must have been from. <wingo>i try not to read it but sometimes i go into troll mode :) <davexunit>HN is one of those places that I sort of hate but keep going back to anyway... <wingo>i like twitter much more -- i get to hear from people i care about and block others *tupi would like a sip of wingo's wine :) <wingo>ruthless, but i think it's the right thing. *DerGuteMoritz opens beer <davexunit>apparently hacking is seeking venture capital for the web application your startup is making. *wingo passes the cheap "club des sommeliers languedoc" to tupi, far from his home :) <wingo>davexunit: of course, get with the program dude :) <davexunit>wingo: yeah, I think I just need to subscribe to more interesting RSS feeds and follow more interesting folks on twitter/identi.ca/etc. <davexunit>I'm done with all this guile stuff. I'm going to write some more HTML/CSS/JS. *wingo hacks on firefox for the day job <ijp>wingo: please bring back the three coloured go/stop/reload button kthxbai <wingo>three colors? reformist. WE DEMAND MANY COLORS <ijp>I think they got rid of that about 20 versions ago now :( <wingo>after the revolution there will be 100000000000000 colors <wingo>each one will have a name, i think ijp you are alloted about 500 to name <TaylanUB>How does one find jobs where one can work on free software ? <wingo>either you find some free software project that someone is paying for, or you sneak in free software things in your work hours <wingo>it happens most often with corporate-controlled free software, but it can happen elsewhere <wingo>mozilla does a fairly good job fwiw, perhaps that could be a thing <ijp>wingo: did you see the bug report from the guy running guile on a blue gene? <wingo>the things i miss by ignoring my email :) ***ijp is now known as Ijp
***Ijp is now known as ijp
<ijp>it's plausible, because there is actually a bluegene/q at the university of rochester <tupi>mark is not around, snif :( *tupi is concerned about a possible solution before the end of this week for the (ice-9 popen) not thread safe bug <wingo>tupi: poke me tomorrow evening if it isn't solved <wingo>i kinda miss debug-mode-only assertions <wingo>compared to other projects i work on. <wingo>of course it's a complication, but still sometimes i don't do certain checks because they just ensure that things are like i expect them to be <wingo>and the way they should be, in production... ***tristan_ is now known as Guest61926
<Guest61926>I'm trying to test building guile-snmp with current master and am seeing an odd error <Guest61926>even though strace indicates that the extension is being loaded, and I can't see any obviously failing opens in a strace ***fangism-shadow is now known as fangism
<Guest61926>The best I can tell at the moment, it is because I have an eval-when (eval load compile), but the load-extension is getting called, and as best as I can tell, it is working ***sneek_ is now known as sneek