[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Blog post on Irmin/CueKeeper
On 23 June 2015 at 13:07, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote: > Le lundi, 22 juin 2015 Ã 20:58, Daniel BÃnzli a Ãcrit : >> Even if weak references are no longer used you will still get into problems >> with side effectful events/signals as you will never have any control on the >> order their update since by the very semantics of React all of these effects >> are supposed to happen simultaneously (synchrony hypothesis) but won't in >> practice. >> > > With respect to this I somehow claim that while side effectful events/signals > may exist they should be hidden by interfacing libraries (int the very same > that they should hide the update step machinery). [...] Well, I completely agree with this. Making each output a single sink and requiring the user to combine the signals explicitly is something I really like about FRP. And in the case of CueKeeper, TyXML does this nicely. However, in my example 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). The problem is with the non-outputting (sprintf) S.map callback, which becomes slower and slower as more and more instances of it run, and either runs out of memory (Javascript, with no weak refs) or crashes (due to a handler that isn't needed still getting called, now with an invalid input). You could replace the final output with a TyXML DOM element or your Stdout.set and it would still fail, I think. -- Dr Thomas Leonard http://roscidus.com/blog/ GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |