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

[Thomas Leonard <talex5@xxxxxxxxx>]

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