***Guest43756 is now known as jao
***sneek_ is now known as sneek
<Mike121>Hey Kids!!! Does anyone know what the state of Guile Clutter is these days? <mark_weaver>Guile Clutter is quite new. I've built it and played with it a bit. <mark_weaver>I built it a few months ago (around the new year). I'd be surprised if it doesn't still work. <Mike121>So it is working, then. I'm thinking about doing a few weeks of GUI on Guile 100 <Mike121>I know that guile-gnome is a bit behind the times. <Mike121>I'll have to check it clutter some time in the next few weeks. <Mike121>Now that I finally have a free video driver that'll make my graphics card work <tupi>Mike121: i was just about to say so :) <Mike121>thx tupi. I'll totally give it a go. <tupi>right now, the fact that guile-gnome is still using gtk2 does not matter while writting guile-clutter code. it will be necessary for guile-clutter-gtk, but that's another story... <Mike121>that's what I was thinking. I know clutter is up to date, and so is SDL. <tupi>well, actually not up-to-date but not bad :) clutter stable is 1.18, we are still using 1.10 <tupi>i personally need a scroller in a scene, which is part of 1.12 <tupi>it will come along, i need to talk to mark_weaver and wingo about the best schema to get a guile-gnome-platform based on gtk3 and implement the bindings with clutter-gtk, oh well, some time this year... <mark_weaver>yes, I'd still be interested in helping with that. one of these months I'll be able to breathe :) <Mike121>there is a project, 'gnome-gir' that I know nothing about that is supposed to do gobject introspection <tupi>there are both very very busy with guile and i have limited funding resources <mark_weaver>Mike121: yes, ideally we would make more use of that in guile-gnome. <mark_weaver>Mike121: it should make our job a lot easier, going forward, but it would be non-trivial work to adapt it. <tupi>mark_weaver: i had a chat with wingo a month ago or so and said i would email you both ... will do asap <tupi>Mike121: what distro are you using ? <Mike121>Fedora, mostly. But I've got no fear of building from source. <tupi>did you install guile-gnome already? <Mike121>On an old version. F15 or 16. But I haven't tried it on the latest <tupi>ok. in order to build guile-clutter, you will need the latest guile-cairo [also required by guile-gnome], and i think it means a got clone because it's been patched to run the bouncer.scm example i wrote and i don't think that the guile-cairo tarball is up-to-date <tupi>s / a git [not a got :) / <Mike121>Can't dig into it today, but, I definitely want to do some GUI tasks for my little contest, so maybe I can try to donate cycles to clutter in a few weeks. <cky>mark_weaver: Oh, yes, I have a way to do a fully binary-compatible SRFI-45-compatible promise implementation in our C code. :-) <cky>#define SCM_F_PROMISE_COMPUTED (1L << 0) <cky>#define SCM_PROMISE_COMPUTED_P(promise) \\ <cky> (SCM_F_PROMISE_COMPUTED & SCM_SMOB_FLAGS (promise)) <cky>^--- this is the key: note, only the bottom bit of the flags is used by existing code. <cky>All I need to do is make the second bit be a flag saying whether it's a new-style promise. Voila! <cky>I'm going to go to sleep now, since it's 3am here, but I will work on this some tomorrow. :-D <cky>Granted, SCM_SET_PROMISE_COMPUTED, as used by existing code, would nuke off the second bit. But that's okay, since such code is expected to only touch old-style promises anyway. <mark_weaver>hmm, interesting. I can't evaluate it yet because I'm really not very familiar with this part of the code. <sneek>wingo was here Mar 28 at 09:36 pm UTC, saying: yes. *mark_weaver summons wingo <cky>mark_weaver: How do you tail-call something in a C procedure? :-) *cky is working on the SRFI-45-compatible promises now. <mark_weaver>cky: you can't. you need to turn it into an actual loop somewhere. <cky>mark_weaver: My implementation technique is this: I use bit 1 of the flags as SCM_F_PROMISE_LAZY, and force checks that flag to decide how to handle the contained thunk. I also create a new procedure, make-lazy-promise, as the procedure backing the lazy macro. <cky>mark_weaver: The only difference between make-promise and make-lazy-promise is whether SCM_F_PROMISE_LAZY is set. <mark_weaver>is there a reason to ever create a promise without that bit set? <cky>No, except we need full binary compatibility with existing modules, remember. :-) <cky>That flag is purely to enable backward compatibility, nothing more. <mark_weaver>yes, I remember. however, that means that existing code compiled against the old header (using the old macros) needs to be able to deal correctly with any promise that's created by the new code. <cky>Yes, that will still work correctly. <mark_weaver>so if old code can't handle promises created with the LAZY flag, then we're already screwed. <cky>So, here's my assumptions: <cky>1. Only "force" will actually evaluate the thunk. Other code will simply check whether the promise is already materalised, and perhaps retrieve the materialised value. <cky>2. The materialised value is retrieved exactly the same way regardless of whether LAZY is set. <cky>3. The procedure for checking whether a promise is materialised is also the same regardless of whether LAZY is set. <cky>The _only_ difference between LAZY vs not is how the thunk's return value is handled. <cky>And due to assumption 1, that means only "force" needs to care. <mark_weaver>sounds good, but I still don't understand why you don't just change 'make-promise' to make a promise with the LAZY flag set? why do you need to add a new function? <cky>mark_weaver: Because old .go files will be macro-expanded to have force => make-promise, with the old behaviour. <cky>mark_weaver: It won't be (make-lazy-promise (lambda () (eager expr))). <cky>*will already have been macro-expanded <mark_weaver>ah, I think I begin to understand. what is the exact difference in the thunk's API between LAZY and not LAZY? <cky>mark_weaver: old behaviour: thunk returns the promised expression's result. new behaviour: thunk returns a promise that's either lazy or eager, and in the case of eager, then it contains the promised expression's result. <mark_weaver>well, for now I'll take your word for it that you've thought it through, and await the patch :) <mark_weaver>this is great stuff, btw. thanks again for taking this on :) <cky>My pleasure! I'm glad that we have enough bits left in the smob flags to be able to handle all this in a backward-compatible way. ;-) <cky>mark_weaver: I think I need to a make-eager-promise procedure too, which will take any number of arguments. It will be the procedure backing the eager macro. <cky>mark_weaver: I think in this case a loop will be more readable than trampolining, but thanks for the heads-up. :-) <mark_weaver>cky: where exactly is your new LAZY bit? is it in the SCM_CELL_TYPE word? <mark_weaver>i.e. will SCM_TYP16_PREDICATE (scm_tc16_promise, obj) still work with the new promises? <mark_weaver>oh, nevermind. the flag is in the SCM_SMOB_FLAGS, not the SCM_CELL_TYPE. <mark_weaver>(they actually are in the same word, but the type bits are in the low 16 bits, and the smob flags are in the next higher high 16 bits) <cky>I wish Guile had atomic variables. :-( <cky>It's okay, though. Not the end of the world. :-) ***adu_ is now known as adu
<taylanub>I'm really greatful that Guile implements delimited continuations with a prompt mechanism that explicitly takes a handler. The order of things is really messed up when using reset/shift; I could only get how they work after reading prompt/abort first.