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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 29 June 2015 at 11:04, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> Le samedi, 27 juin 2015 Ã 12:32, Thomas Leonard a Ãcrit :
>> Hmm, yes, this could be a problem for handlers that expect to see all states.
>
> I wouldn't put it in these terms (handlers, state) but yes it breaks the 
> semantics of signals. This needs more thinking.
>
>> S.diff would be a problem too (and sometimes you might want to diff
>> against the last seen value of the signal rather than the previous
>> actual value).
>
> I don't understand this comment.

I mean, if the output of an S.diff stops being used then it would stop
monitoring its input, but when re-enabled it would need to know the
previous value of its input, which might no longer be available.

>> In the case of CueKeeper, it would be an advantage though. For
>> example, there are multiple tabs, each of which shows a different
>> query. The FRP code (since replaced) was something like this:
>>
>> let tab_content =
>> S.bind current_tab (function
>> | `Process -> process_tab
>> | `Work -> work_tab
>> ...
>> ) in
>>
>> The problem was that it recalculated every tab's query each time,
>> whereas I only wanted it to calculate the elements for the tab that
>> was currently selected.
>
> Isn't this a matter of not creating the queries in the binding function but 
> rather outside of it ?

Yes, that would probably work too.


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