[Haskell-cafe] Number of widgets extant and displayed varying over time? (FRP, reactive-banana)

[Heinrich Apfelmus]

Dear Jeffrey,

> Does that mean one has to collect the garbage oneself, or does it
> mean that garbage cannot be collected at all?

At the moment, it means that garbage cannot be collected at all. This 
will change in the next version, reactive-banana-0.9. (There is no 
anticipated release date yet, though.)

> There might never be more than fifty or so frames of text on display
> at any one time, but in a single session I can easily imagine drawing
> hundreds of thousands of them.

I'm not quite sure what you mean by "frame". If it's a text whose 
position can move, then you can probably model it by a

   Behavior (Position, String)

The, "moving text block" is the smallest entity that you would have to 
garbage collect, and I guess there are no more than ~300 of them active 
over the lifetime of a program.

If you create a new Behavior each time the text is moved, then things 
become more resource intensive, of course. Then, it would be necessary 
to garbage collect a Behavior each time that a text is moved, these are 
probably proportional to the number of mouse clicks that the user makes 
over the lifetime of the program.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


Jeffrey Brown wrote:
> Thanks, Heinrich!
> 
> Reactive Banana's front page on Hackage [1] indicates that
> Reactive.Banana.Switch offers "no garbage collection for events that are
> created dynamically". Does that mean one has to collect the garbage
> oneself, or does it mean that garbage cannot be collected at all?
> 
> My eventual goal is to write a mindmap editor, ala Freeplane. There might
> never be more than fifty or so frames of text on display at any one time,
> but in a single session I can easily imagine drawing hundreds of thousands
> of them. (For that estimate I am assuming a single line of text in the
> model would require a new frame each time it is redisplayed; if instead a
> frame could persist invisibly and be redrawn later, most sessions would, I
> imagine, involve fewer than five thousand frames -- but even then it's not
> obvious to me that I could forego garbage collection.)
> 
> [1] https://hackage.haskell.org/package/reactive-banana
> 
> On Tue, Jan 13, 2015 at 11:04 PM, Heinrich Apfelmus <
> apfelmus at quantentunnel.de> wrote:
> 
>> Jeffrey Brown wrote:
>>
>>> Dear list,
>>>
>>> I want to write an application in which the set of widgets in existence,
>>> and the subset of them that is displayed, depends on user input. I am
>>> using
>>> reactive-banana. So far the simplest spec I have imagined for it is this:
>>>
>>>     Initially there is just a text entry box and an empty (hence
>>> invisible)
>>> collection of labels.
>>>
>>>     The user can do two things: enter the word "add", or enter an integer.
>>>
>>>     Entering the word "add" causes a label to be added to the collection,
>>> but not displayed. The labels require no text content.
>>>
>>>     Entering an integer N causes the first N labels to be displayed
>>> onscreen. The text entry box remains visible.
>>>
>>> I am totally baffled. In particular, the Behavior paradigm, though it is
>>> elegant and beautiful whenever I study it, I have no idea how to apply.
>>>
>> This looks like you need "dynamic event switching", i.e. the module
>> `Reactive.Banana.Switch`. It's very cool, but may be more difficult to
>> understand than the standard combinators, mainly because of the additional
>> type parameters.
>>
>> To see how it works, have a look at the `BarTab.hs` example. It implements
>> a program that is very similar to what you describe here.
>>
>>
>> Best regards,
>> Heinrich Apfelmus
>>
>> --
>> http://apfelmus.nfshost.com