***sturm_ is now known as sturm
<rekado>oh my, David Kastrup’s email about the LilyPond 2.20 release process contains so many claims about “the Guile maintainers” and their intentions… <rekado>the good news is that LilyPond already works with Guile 2; bad news is that it’s really slow. <jmd>What's slow? Lilypond or its development? <wleslie>the story was that guile 2.0 broke a very unhygenic interface that wasn't sustainable in the new compiler. janneke ended up doing most of the porting to Guile 2. probably they haven't had much time to polish that. <amz3>paroneayea: the 8sync post on the mailling list is interesting <amz3>I started reading the background theory <amz3>math dual has always been an intersting concept I am wondering how it translates into programming stuff <paroneayea>sneek: later tell amz3 I'm glad you found it interesting :) <ArneBab_>rekado: does "works" mean, it can now create pdfs from ly files? <ArneBab_>rekado: do you mean this? "So I really would urge the Guile-2 warriors to fold their work into the <ArneBab_>mainline. We want it distributed by default, but probably with a <ArneBab_>stronger warning against --enable-guilev2 (or what it was called), <ArneBab_>dropping to a third sounds like it’s solvable <ArneBab_>davexunit: above it some have an unfriendly tone, but much, much less than the past emails I saw <ArneBab_>it sounds like lilypond is finally on track to work with Guile 2.0 <davexunit>I've just read it all now and it's really nasty <davexunit>sorry, the paragraphs were *above* what you quoted, not below. <ArneBab_>maybe I feel it differently, but what I see is a pretty positive message masked by deep frustration <ArneBab_>it could also have been written as "Lilypond on Guile 2.0 now WORKS! It still only gets 30% of the speed, but it works." <davexunit>he has delusions that guile is no longer an extension language <wleslie>it doesn't sound as biting as anything he said on the guile list <ArneBab_>compared to what I was used to, this is really nice <rekado>guess I was just lucky then that I didn't read his other messages on the Guile lists. <davexunit>I try to avoid reading things from him on mailing lists <ArneBab_>He seems to be really frustrated because some hacks required lots of effort to fix due to changes in Guile. I can sympathize with that — likely he also does not have the time (and energy) to address them properly, so that it feels like the carpet got pulled out from under him. <davexunit>he's taken opportunities to put down guile on emacs-devel and stuff <davexunit>the problem is that they relied on some unspecified behavior that just happened to work on guile 1.8 <davexunit>the code should never have worked, and now david expects bug compatibility for major version releases. <ArneBab_>yes, but there’s nothing to be done about that <ArneBab_>the really positive part in his message is, though: please merge guile2 work into mainline <paroneayea>and actors now can have auto-init and auto-cleanup (something to run on shutdown, either of the actor or the whole system) actions <paroneayea>this is going to be the first release I'm going to really ask others to play with <paroneayea>hopefully we can find out how well the ideas of 8sync pass with other people :) <davexunit>when you release I should try to follow the tutorial and see how it goes <davexunit>so you can draw pretty vector lines with guile :) <paroneayea>davexunit: it would be great if you could try it <davexunit>there's more complicated things to do from here, like dashed lines and curves, but this is a good first step. <davexunit>there's several end cap styles to choose from, too. <davexunit>I'd like to do outline polygons, but I need to learn how to render the join points so the result isn't gross. <davexunit>paroneayea: I would read your tutorial if you have it available somewhere, I just can't actually write the code yet. <ArneBab_>lilypond source, general-scheme.cc, line 274: "//scm_protects is available only in Guile versions before 2.1." <ArneBab_>"hey, we found a solution which finally works" … next release … "it got removed…" <paroneayea>davexunit: ok, in about 2 hours I'll have the last section done, and then I'll export it to html :) <paroneayea>davexunit: keep in mind: there's probably more mutation than you'd like, but functional actors will become an option in the future... I put some things in place to make them more possible already <davexunit>everything I've been writing is imperative lately <davexunit>which I've finally developed a pretty nice way of handling <davexunit>and I took a page out of Bagger's (from #lispgames) book for some of the API <davexunit>he made the observation that rendering is applying a function (a shader in OpenGL) to a vertex array with some arguments (known as uniforms) <davexunit>(gpu-apply shader vertices #:uniform-1 foo #:uniform-2 bar) <davexunit>it's as good of a rendering interface as I've ever been able to make. <davexunit>I also made efficient sprite rendering a lot simpler from the user's perspective. <davexunit>just wrap your draw-sprite calls in the with-batched-sprites form and you're good to go! <paroneayea>it's too bad it's on the same day as the decentralized networking track though, those are my two tracks of interest. Oh well, that's how conferences go :) <ArneBab_>paroneayea: that is something I’d really love to see <davexunit>I hope everything gets recorded because I won't be there :) <paroneayea>civodul: dang I wonder if we need to finalize the panel after all if the FOSDEM people want our schedules finalized by Saturday <davexunit>hmm, I wonder if floats need to be boxed before passing them off to the ffi <davexunit>hopefully that can be optimized, will need to read some disassembly to know for sure. <civodul>paroneayea: we should check with Pjotr and Manolis, most likely we'll be scheduled at a different time <davexunit>can guile do anything like common lisp's restarts? <davexunit>the use-case is to redefine a buggy procedure when an exception is thrown and then resume the program at that point <paroneayea>davexunit: I've wondered whether r6rs conditions supported it <paroneayea>there's a raise-continuable thing I looked at but didn't understand <davexunit>paroneayea: I'll look into it, I'm still wrapping my head around it. <davexunit>all I know is that it would really help me with my game engine <dsmith-work>So something blows up in the middle of some procedure. You rewrite it (so now new code). Seem like the restart would continue from where it blew up in the old code. How would it know to restart from the middle of the new code? <paroneayea>davexunit: if you make progress figuring it out, let me know <davexunit>I want to catch an exception, pause the game, spin and poll the REPL server until the user calls a resume function, then restart from where the exception occured. <paroneayea>davexunit: I guess it wouldn't work *in general* though <davexunit>dsmith-work: you'd redefine the buggy function, and then restart from that function call. <davexunit>it wouldn't be *after* that call, it would *on* that call. <paroneayea>it would only work for raise-continuable using procedures <davexunit>maybe there's a trick I can play to deal with it. <paroneayea>davexunit: 8sync's engine is also "failure friendly" but it doesn't drop to a REPL <paroneayea>it more or less spits out errors to the console, propagates them to actors who are waiting on information from other actors, and just keeps running <davexunit>in my case I'd add a hook that the user could set to do whatever <davexunit>most common case would be just poll the repl server for awhile. <paroneayea>that way you can "see" the error in progress and fix it <davexunit>paroneayea: yeah I did something similar in sly <davexunit>the thing I really want and could never figure out though is to make a REPL server that I could pass a stack to and enter the debugger <davexunit>because the exception happened in the game loop, not in the REPL session. <paroneayea>either do the "print and keep running" option, or "drop to a repl" <davexunit>that works as a start, but it's not a very good solution. <paroneayea>though! imagine you're entering some long thing in geiser's repl buffer <davexunit>and then drop back to the console repl and ,q when I'm ready to continue <paroneayea>and suddenly an error happens in the running problem <davexunit>there's all sorts of potential problems like that :) <davexunit>I think it would have to be a new repl command <davexunit>and write a metacommand to open the debugger and use that stack <davexunit>the user, at their already open REPL, runs a metacommand <paroneayea>I could maybe supply this as a feature for 8sync, too. <paroneayea>davexunit: for 8sync's case, I think it won't stop the whole program <paroneayea>just, instead, the terminal will print out "exception caught, see ,debug-8sync" or something <paroneayea>and you can ,debug-8sync which will list a set of stacks to hack on <random-nick>many common lisp REPLs use conditions and restarts when an error occurs <davexunit>the game engine itself will have no knowledge of it, it will just capture the stack upon exception, stash it in a global, and call on-error-hook <davexunit>I'm very excited that this suddenly just clicked. did you know you were a rubber duck, paroneayea? <davexunit>hopefully there's nothing I'm forgetting about the way the stack and debugger APIs work that makes this not possible. <paroneayea>davexunit: happy to be your rubber duck, any time davexunit :) <paroneayea>you too anyway, since now I have a great idea for a new feature :) <davexunit>the guix code has an example of this sub-repl creation <davexunit>it doesn't make a debugger, but it does make a new sub-repl <davexunit>(system repl error-handling) has the code I need <davexunit>I'll write my own version of call-with-error-handling <davexunit>yeah, I can just use a custom on-error procedure for this <davexunit>unfortunately no such option exists for trap-handler, so I wouldn't be able to capture breakpoints. <davexunit>the (debug) case in the (case on-error ...) form is the code I'm gonna snarf <davexunit>I just need to wrap the body of that lambda in another lambda <davexunit>and set! a global so it contains that lambda <davexunit>the repl metacommand will simply apply the thunk and voila! <davexunit>but for now I'm not interested in breakpoints <davexunit>what I want is to be able to stick a call to something like (debugger) anywhere in the code and have that spawn a debugger. <paroneayea>it would be nice to maybe also be able to set a scope where guile didn't optimize away much of the locals on the stack <paroneayea>or run guile like --less-optimized for debugging <davexunit>guix will likely use that when it switches to guile 2.2 <davexunit>so that all of the package modules compile quickly <davexunit>since things compile slower now that there are so many lovely optimizations applied <davexunit>why is mit-scheme in many ways still the best scheme? heh <paroneayea>oh right I think andy rewrote the docs about system asyncs <wingo>happy new year's, guilers :) <tokage>it's still some months till 64 ARMS <paroneayea>wingo: mind seeing if my understanding of suspendable-ports is correct? <paroneayea>wingo: my understanding is, if you do anything that does read/write bytes, it'll always suspend to the scheduler, regardless of whether there is information available yet <paroneayea>so there's no need to manually yield after a read-line or etc <paroneayea>because it'll always have suspended to the scheduler after every call to read-bytes anyway <paroneayea>I'm writing 8sync docs and was about to write documentation as if I was sure of this, and then realized I wasn't totally. The code seems to indicate as much <wingo>let's say you put-u8 on a suspendable port <wingo>if the port has buffering (see Buffering in manual) and there is space in the buffer, then the operation succeeds immediately, without suspending anything <wingo>the suspendable ports facility only calls the current-read-waiter / current-write-waiter if guile tries to read/write on a port, <wingo>there's not enough in the buffer / the buffer is full, <paroneayea>in that case, I *will* put a yield in here, and explain why that's a good idea :) <wingo>as you like :) why do you think it's a good idea? <paroneayea>apparently I'm the one learning from this tutorial :) <wingo>well, i can just read your docs anyway :) <paroneayea>wingo: oh, well... I dunno, it seems like a good idea to prevent one thing from flooding <wingo>but it doesn't seem like a good idea to me <paroneayea>well maybe the existing behavior was just fine, handle as many lines as you can <wingo>if you want line buffering on output, use setvbuf to get that effect <paroneayea>but at the very least, it's a good thing to understand what the behavior is ;) <wingo>or if you want to limit input buffering, similarly setvbuf can give you a maximum to process at once (but in bytes rather than lines) <wingo>just got back home yesterday from holidays <wingo>yes, and likewise for you :) <wingo>did you see the parallel fibers things? regrettably requires dev guile <wingo>i'll release another guile soon, hopefully with davexunit's patches too <paroneayea>wingo: I saw it... I haven't gotten to try it yet <wingo>yeah it's a little half-baked <paroneayea>wingo: btw, it would be useful if you had time to look at the guile-fibers patch I sent to guix <wingo>i tried parallelizing the web server and ran into a problem that needed a deeper fix <paroneayea>I think I'm much more likely to use guile-fibers if properly packaged <paroneayea>I aim to get guile-8sync in guix after next release as well :) <paroneayea>then maybe we can get more guilers actively playing with these things <paroneayea>wingo: anyway, the parallelizing stuff looks fun. :) <wingo>yeah i want to pop this off my plate and release guile 2.2 <wingo>er, stack of plates anyway :) 