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

[Drup <drupyog+caml@xxxxxxxx>]

> The only other (very minor) problems I had were:
>
> 1. Wanting to refer back to an element in a callback, for animations
> or form values. There is some code like this:
>
>      let item_ref = ref None in
>      let callback ev = ... (use !item_ref) ... in
>      let item = a ~a:[a_onclick callback] [...] in
>      item_ref := Some item;
This is the typical example where you want to use Lwt_js_events, which 
avoids the recursion (and the reference)
    let item = a [ ... ] in
    let dom_item = Tyxml_js.To_dom.of_a item in
    Lwt.async (fun () -> Lwt_js_events.clicks dom_item (fun _ev 
_handler -> .... use dom_item/item ...))
We could implement Lwt_js_event (and a mutation module similar to 
Eliom_content.Manip[2]) directly on Tyxml_js's nodes, but it's not done 
right now.
And it would need more functors...

[2]: http://ocsigen.org/eliom/4.1/api/client/Eliom_content.Html5.Manip

> 2. Some workarounds were needed for MSIE. e.g.
>
>    
> https://github.com/talex5/cuekeeper/blob/90a12e71834ae10416e0ec86ce15408ec25d33e6/js/ck_template.ml#L27
> > For the GC issues, Lwt_react[1] helps a bit, in particular E.keep and
> > S.keep. It basically implements your "global sink" idea. Doesn't solve the
> > space leaks in javascript, though. Lwt_react in general is a very nice
> > improvement over React when used in conjunction with Lwt.
> Yes, but the global sink is only useful if unused handlers get freed.
> Otherwise, it just stops things getting GC'd at all.
Well, here is the implementation of keep:

    let keeped = ref []
    let keep e = keeped := map ignore e :: !keeped

(that's React's ignore)

So you should be able to have several "keepers" like that, and the 
lifetime of signals would be the lifetime of the keeper.

> > You didn't seem to use Lwt_js_events (or just didn't talked about it) in
> > jsoo, is there a reason ?
> Handling events seemed simple enough with a_onclick attributes. I only
> used Lwt_js_events for the "async" method. Would it have helped?
It avoids recursion issues (see earlier) and occasionally offer very 
interesting control over the buffering and the sequentiality of events.
You can also do complex stuff very easily, like receive event A, wait 
for event B, then on receiving B, start waiting for A again.
That's quite useful sometimes.


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