*nalaginrut rewrite template of Artanis with LALR, seems work fine ;-) <dje42>Is there some way for a module to export a value such that other modules that import it see their own copy? [kinda like fluids for modules, roughly speaking] <dje42>Could one use parameters for this? <dje42>[the importing module would have to use (parameterize ...) everywhere it needs to set its own value of the parameter, I think. <dzu>wingo: what was the question? ;) <dzu>that looks more like an aswer to me :) <madsy>Does it look okay from a design perspective? <madsy>with-mgl is a macro that ensures that a mutex is locked and unlocked before and after all OpenGL calls <madsy>So the code can run in a separate thread <dzu>do you really want to work at such a low level? I was just wondering the other day if there were OpenSceneGraph bindings for guile... <madsy>dzu: This is low-level? Have you ever tried working with straight OpenGL in C or C++ ? <madsy>davexunit: No, but I'm embedding scheme, so I don't think guile-figl would work for my purposes <dzu>madsy: Yes I tried that a long time ago and don't want to repeat this actually ;) <madsy>davexunit: Guile calls functions my program has made available. So I can do OpenGL graphics in a second thread <davexunit>oh you're embedding guile into an existing program, gotcha. <dzu>madsy: I came to the conclusion that I really would want to concentrate on the objects in the scenery so I was looking for higher levels and found the scenegraph libraries (there are lots of them) - OSG seems to be a good candidate for Free Software <madsy>davexunit: Which means during testing my application can never lock up. And I can hide all the performance-critical stuff <davexunit>all of the game stuff I do is single-threaded <madsy>I'm going to use this later for a game, where scripting is a part of the game <madsy>Where the application connects to its own guile server <madsy>In essence, thread communication is done over a socket <madsy>And during testing, I can connect to the scheme server with Geiser <madsy>I hope. Haven't tested Geiser yet <davexunit>I have actually done a good amount of work around making a REPL server work with a single threaded game. <davexunit>the REPL uses a coroutine that yields to a thread that reads user input. <madsy>If you want the REPL server to control the graphics in that case, you have two options <davexunit>my REPL can control everything. graphics included. <madsy>Oh, so the REPL server runs on the only thread? <madsy>With (start-server) not (spawn-server) <davexunit>the server still runs in its own thread, and each client still has a thread. <davexunit>but the client threads are *only* used to read user input, everything else happens in the main thread. <davexunit>so no race condition or other threading problems. <madsy>I'm using OpenGL context sharing <davexunit>yeah I looked at that approach and decided against it. <davexunit>since SDL will blow up when called in another thread anyway. <madsy>The main thread renders a framebuffer object that is filled by the server REPL thread <madsy>The main thread also polls input <madsy>So the main thread is really lightweight, like yours <davexunit>my main thread does all of the work, so it's pretty heavy weight. all this multithreaded business is just so that I can use the REPL while the game is running. <madsy>I'll just spawn new threads in the server REPL and change functions on the fly there <davexunit>I have a patch that will hopefully make it into guile 2.0.10 <davexunit>that allows me to do all of the stuff that I'm doing. <madsy>By the way, Clojure has a really handy plugin which saves all your REPL history (except duplicated) to file. Does Guile have something similar <ijp>readline will do that if you enable it <madsy>For example if you set! a variable 'foo' twice, it only saves the last one. So if you do RAD development, you can save your current work <madsy>I'll look into Geiser later tonight, thanks <davexunit>random idea to add to figl - a DSL to translate scheme into GLSL shaders. <add^_>davexunit: that would be sweeeet <madsy>davexunit: I was thinking of that as well <madsy>But I don't know enough about reader macros yet <madsy>add^_: If you want to drastically change the syntax, a normal macro isn't enough is it? <dzu>davexunit: I just tried cloning guile-figl and compiling it but I get makeinfo errors (makeinfo 5.1). Is that already known? <add^_>madsy: I know what a reader macro is, I'm just confused, is it called that in Scheme? <add^_>Also, define "normal" macro :-P <ijp>the less you know about reader macros the happier you will be <add^_>I think we can use a "normal" scheme macro for that job.. <madsy>add^_: An ordinary macro is a normal macro. One that doesn't override the reader rules <add^_>Explain why it can't be done with a normal macro :-P <madsy>I don't know if it can be done without read macros or not. I haven't tried. <ijp>because normal macros are evaluated after the file has already been read <ijp>I have nothing good to say about that one either <madsy>eval-when is evil according to many <add^_>eval in general is evil according to some IIRC <ZombieChicken>Is guile a reasonable scheme implementation to use when working through Structure and Interpretation of Computer Programs? <wingo>it's fine; it doesn't have the picture language tho <wingo>other than that i don't know of any problems <ijp>wingo: a few definitions maybe <ijp>I think there are a couple of concurrency primitives you need in one of the chapters <ijp>ZombieChicken: if you find anything missing, just ask. it probably already exists under a different name <madsy>Hm, is there a simple macro for SCM->c-string? I'm not able to find it in the docs ***alexei is now known as amgarchIn9
<stis>vhashes are genious, but not suatable for a functional lookup table of variable bindings <stis>very good to represent stes that are built and teared down in batches. <civodul>that's what the peval uses, for instance <stis>it looks like one need to remove a (k,v) befor entering a (k,v2) <wingo>depends on your algorithm; you can shadow, or you can always use fresh names <stis>does it really shadow if you hash-cons a new (k,v2) ? <mark_weaver>it acts like an association list, except with asymptotically better performance. <stis>yes mark_weaver, you are right. really cool, ive missed that trick, yes I see ... <stis>(k,v2) => add new next link to old ref by hash, mutate hash position to point at new value. <stis>so it mutates but sematically it is a functional update. Really really cool! <civodul>the mutation is not really cool in practice, because it's not thread-safe :-/ <stis>if one asoc on k it will see that the ref is in a larger pos then size and then go to the link and retry. <stis>Oh, yes, you are right on that part.. <stis>one need a syncronization primitive which is slow. <wingo>woo hoo! with rtl primitives, eval.go seems around twice as fast on a simple count-down loop <wingo>well, tough comparison -- you end up penalizing one or the other <wingo>but currently at least 50% more throughput <wingo>and the throughput will get better i think <wingo>i'll try to pull this together into a branch <wingo>will take a little bit of time to separate it out nicely <wingo>i have some problem where goops doesn't do the right thing, currently... oh wells ***anderson is now known as Anderson