[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Thomas Leonard <talex5@xxxxxxxxx>
  • From: Drup <drupyog+caml@xxxxxxxx>
  • Date: Mon, 22 Jun 2015 18:06:13 +0200
  • Cc: "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 22 Jun 2015 16:06:42 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:cc:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=epELVBLmpRMxUeS87ej30hQoGuEQUT+c0aZP0X4iookoCXeXfv5PHNT6vvADLXsLuN0TX+VlzUt0 Q0WqueSha7pR5Du+2IPJwQpieYVv1X5iFINLMll1IzKtng6yu/5Y
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

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.

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.