IRC channel logs

<davexunit>found a haskell game engine that uses functional reactive programming. http://helm-engine.org/guide/

<davexunit>I will have to borrow some ideas for guile-2d

<davexunit> http://hackage.haskell.org/package/elerea

<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*: http://www.ccs.neu.edu/home/dherman/research/tutorials/monads-for-schemers.txt

<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.

<dsmith-work> http://www.lisperati.com/landoflisp/panel01.html

<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>neat

<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.

<shanecelis>xdje: http://www.gnu.org/software/guile/manual/guile.html#Guardians

<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 http://www.hpl.hp.com/personal/Hans_Boehm/gc/ for all the details

<xdje>thx.

<xdje>That does mean saving SCM's in gdb data structures won't protect them from GC.

<civodul>right

<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

IRC channel logs

2013-09-03.log