IRC channel logs


back to list of logs

<davexunit>found a haskell game engine that uses functional reactive programming.
<davexunit>I will have to borrow some ideas for guile-2d
<davexunit>functional reactive programming library in haskell.
<davexunit>would be cool to port to Guile.
<shanecelis>FRP I still haven't wrapped my head around; it is intriguing though.
<davexunit>I haven't either, but I intend to
<davexunit>since it will save me from the inevitable callback hell that I will be in otherwise. :)
<taylanub>shanecelis: It just means that you can bind together values via a certain relationship, so changing one will change the other according to the relationship. Like you could define (define ten-seconds-later (+ current-time 10)) and as time passes and current-time changes, ten-seconds-later would change in accordance and keep conforming to the "+10" relation.
<davexunit>the implementation details are confusing to me.
<davexunit>I'm not sure how to do it.
<shanecelis>taylanub: That sounds wonderful. Like a having a baked in redo/make for propagating changes.
<davexunit>in the case of a game, I'd like say something like (define player-shooting (key-pressed? 'z)) or something
<davexunit>and getting the value of player-shooting at any time will yield #t/#f depending on if the key is pressed.
<shanecelis>davexunit: First enter into the monad, then realize there is no way out of the monad. Enlightenment is sure to follow. ;)
<davexunit>gah monads
<taylanub>I found this *awesome*:
<davexunit>will I need monads to do frp?
<davexunit>so much to learn!
<taylanub>davexunit: I don't think so ..
*didi jabbers incomprehensibly.
<taylanub>But Haskell people like to implement everything with monads so maybe they implemented FRP through monads too. :P
<taylanub>I skimmed through countless monad tutorials, and they were all too boring, too dense, too crazy, too lame, whatever, but that "for schemers" one was perfect to me. :D
<dsmith-work>Could it be that s/like to implement/have to implement/
<davexunit>I imagine that there is a bunch of mutation involved in FRP
<davexunit>given that you're implementing event listeners
<davexunit>I was trying to think about how to do it without mutation, but I can't see a way.
<didi>davexunit: Mutation can be good too. Don't fight it too much.
<davexunit>yeah, I realized that I was fighting it too much.
<davexunit>but it's so nice when you can write something purely. :)
<wingo>i think the "all mutation is evil" is just a phase most of us pass through :)
<davexunit>wingo: I'm on the tail end of that phase I think
<shanecelis>The dream that you can stick with a substitution model forever is alluring.
<shanecelis>lol. Great comic.
<xdje>Hi. I have some smob questions ...
<davexunit>let's hear 'em :)
<xdje>okie doke ...
<dsmith-work>Sooner or later, someone might answer.
<xdje>Can smobs be inherited in some way, e.g. with goops? Or do I have to make a smob a member of the class and provide accessors (kinda like the difference between "is a" and "has a").
<davexunit>a smob is *not* a class
<xdje>2) If I construct a smob in C but not always expose it to scheme (and thus there is no scheme reference to the SCM object) how do I prevent the smob from being garbage collected (assume the function has returned and there's no longer any stack references to it).
<dsmith-work>xdje: Think of smobs as new opaque scheme types that the only accessors are defined in C.
<davexunit>xdje: so you want the "is a" relationship
<xdje>Re. inheritance: one can do that kind of thing in Python, and I was wondering if there was an equivalent in guile.
<davexunit>xdje: OOP is a core part of python.
<davexunit>it isn't a core part of scheme.
<davexunit>though the paradigm is supported.
<xdje>The reason I'm asking is that I have gdb+guile "working", and am trying to finish up the low level details.
<davexunit>via GOOPS, as you have found.
<davexunit>what is gdb+guile ?
<xdje>guile scripting from inside gdb
<davexunit>xdje: re: #2, the way you keep a smob alive from within C is if a top-level C structure has a reference to the smob.
<davexunit>the GC will traverse those pointers
<xdje>davexunit: thx. does the reference have to be to the SCM that enclosed the smob, or can the reference be to the smob itself?
<civodul>xdje: sounds like a neat project
<xdje>[also, is there a specific meaning to "top level C" structure? or can the reference be anywhere in the heap?
<xdje>last question (for now :-)): does the "free" routine of the smob have to call scm_gc_free for each scm_gc_alloc call (explicitly) made when constructing the smob? The docs are a bit unclear.
<xdje>[e.g. the "image" example from libguile-smobs.texi does scm_gc_free (image)]
<civodul>xdje: are you using Guile 2 or 1.8?
<civodul>(or supporting both?)
<civodul>in Guile 2 anything allocated with scm_gc_ is GC-managed, so it doesn't need to be explicitly freed
<civodul>that wasn't the case in Guile 1
<xdje>civodul: I was intending to support only guile 2. at least for now.
<xdje>civodul: ah. thx
<civodul>in Guile 2 the mark function is useless if things were allocated with scm_gc_malloc
<davexunit>xdje: from what I know (which might not be much), the GC will your C structures.
<civodul>info "(guile) Garbage Collection Functions"
<davexunit>the GC will traverse*
<davexunit>so, you need the SCM to be referenced somewhere.
<davexunit>I wish I could explain this better.
<davexunit>I worked around this issue when I was still writing C extensions (I've since moved to pure Scheme)
<xdje>thx. that's what I was looking for: "need the SCM to be referenced somewhere"
<davexunit>good luck.
<shanecelis>xdje: There is also scm_gc_protect_object to stop it from being garbage collected.
<davexunit>oh neat
<xdje>thx. The C code knows when the object is going away (e.g. the user deletes a breakpoint), so it could unprotect it then. I would still need the SCM to pass to unprotect() I guess.
<shanecelis>xdje: Yes. One other trick you can do though is add them to a guardian.
<xdje>yeah, saw Guardians. I was hoping to get buy with just judicious use of the smob protocol.
<xdje>How well does Guile's GC work with large malloc heaps? [large as in 10G or higher]
<xdje>gdb can be used to debug some really large programs.
<civodul>xdje: the BDW-GC does not scan the malloc heap (or mmap anonymous mappings)
<civodul>see for all the details
<xdje>That does mean saving SCM's in gdb data structures won't protect them from GC.
<civodul>unless GDB's data structures can be allocated with scm_gc_malloc
<xdje>I think it'll be easy enough to have a side table that holds references so they're protected.
<civodul>yes, typically a weak-key hash table