IRC channel logs


back to list of logs

***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>Hi Mike121!
<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
<mark_weaver>sounds good!
<Mike121>I know that guile-gnome is a bit behind the times.
<Mike121>w.r.t gtk 3.0
<mark_weaver>right, it's still on gtk 2 and gnome 2.
<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
<mark_weaver>Mike121: tupi made some nice examples for guile clutter:
<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?
<tupi>[i am on debian]
<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>^--- 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.
<mark_weaver>but I'll think about it. thanks!
<ijp>good afternoon
<mark_weaver>sneek: seen wingo
<sneek>wingo was here Mar 28 at 09:36 pm UTC, saying: yes.
<mark_weaver>greetings guilers!
*mark_weaver summons wingo
<mark_weaver>unlikely to work, but worth a try :)
<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>Okie dokie.
<mark_weaver>cky: thanks for working on this! :)
<cky>My pleasure!
<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:
<mark_weaver>if old code *can* handle promises created with the
<mark_weaver>LAZY flag, then why not always add the LAZY flag?
<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>ah, right.
<mark_weaver>I think I understand.
<mark_weaver>well, for now I'll take your word for it that you've thought it through, and await the patch :)
<cky>Excellent. :-)
<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. ;-)
<mark_weaver>indeed, extra bits have saved my ass many times :)
<mark_weaver>cky: btw, regarding the tail call thing: "trampolining" is a common technique. See
<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: makes sense.
<mark_weaver>yes, a plain loop is better if you can do it.
<mark_weaver>cky: where exactly is your new LAZY bit? is it in the SCM_CELL_TYPE word?
<mark_weaver>cky: did you need to change 'scm_promise_p' ?
<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>it's all good.
<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. :-)
<mark_weaver>cky: yeah, it would be nice to have them, I agree.
***adu_ is now known as adu
<mark_weaver>cky: we'll add them to guile at some point.
<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.