Re: [MirageOS-devel] Blog post on Irmin/CueKeeper

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

Le mardi, 23 juin 2015 Ã 13:24, Thomas Leonard a Ãcrit :
> http://roscidus.com/blog/blog/2015/06/22/cuekeeper-internals-irmin/#problems-with-react
>  
> there is only one output (printf) and it is static (just for demonstration 
> purposes).
Ah yes sorry I couldn't read through the menagerie of operators and inline 
definitions â a well (de)composed sequence of let bindings is easier for my 
small brain.
  
> The problem is with the non-outputting
> (sprintf) S.map callback, which becomes slower and slower as more and
> more instances of it run,

Sure you are making a side-effect here (Thread.delay 1.0) that takes a lot of 
time in an update that is meant to be instantaneous. Whenever the signal is 
switched it will still update until gc'd so all these delay will still be 
performed (and accumulated). Signal definitions should be effect free and 
reasonably quick so that they maintain the illusion of the synchrony 
hypothesis.  

> and either runs out of memory (Javascript, with no weak refs) or
Yes unfortunately you need to fallback to manual memory management which you 
could do by replacing the S.bind by its `S.switch` ing definition and 
introducing a gc'ing signal on the argument of the switch that strongly stops 
the old signals whenever the higher-order signal changes:

let ss = S.map ~eq:(==) (function | 0 -> â) complete_actions
let out = S.map (fun s -> Printfâ) (S.switch ss)
let gc_ss = S.diff (fun _ old -> S.stop ~strong:true old) ss

> crashes (due to a handler that isn't needed still getting called, now with an 
> invalid input).
Well I would argue that this is a problem of your program or your conceptual 
view of signals. There is no such things as "a handler that isn't needed still 
getting called"; that's a "callback" and effectful view of things but that's 
not what the semantics of `S.map f s` tells you. `S.map f s` is a signal such 
that for all point in time t after its creation you have [S.map f s]_t = f 
[s]_t, and so `f` has to deal with this whatever `s` may become.

Now of course you can argue that this is not what you want and that React 
should be able to reason about the end time of signals but I'm not sure that 
this would made things easier as it would certainly mean to fallback to 
manually manage dependency among signals rather than let the natural algebraic 
expressions of your program do so. But I'm open to better suggestions.  

Best,

Daniel



_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel