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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 22 June 2015 at 13:01, Drup <drupyog+caml@xxxxxxxx> wrote:
>
>> Finally got around to writing this up:
>>
>> http://roscidus.com/blog/blog/2015/06/22/cuekeeper-internals-irmin/
>>
>> I'd be particularly interested to hear about suggestions for avoiding
>> the React GC issues.
>>
>
> Very nice write up! I was eagerly waiting for it; especially the tyxml/react
> part, since we didn't got much feedback on that. I'm rather happy to see
> that you used it and enjoyed the convenient combinators and the additional
> type safety. I agree that the documentation is less than satisfactory, I
> have yet to find a nice way to document such complex typing.
> I'm surprised you understand it by *reading the code* given the
> functorization and the typing. :D

Yeah, it's really nice! I think it just needs a little introduction
(maybe not much more than is in the blog post).

> Apart from the typical react issues, what was your feeling on the tyxml
> react things, from a GUI building aspect ?

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;

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.

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

> Otherwise, the contribution of the indexedDB api to jsoo's api would be very
> welcome. ;)

The problem here is I only implemented the bits I used. But if anyone
wants to take it forward the skeleton is here:

https://github.com/talex5/cuekeeper/blob/master/js/indexedDB.mli

BTW, that reminds me: there's a typo in the HTML storage (dom_html.ml):

  method keynewValue : js_string t opt readonly_prop

(should be just "newValue").

> The bigstring and bin_prot primitives have been implemented in js now (part
> of hhugo's effort to make Async work on jsoo), so you shouldn't need them
> any more.

Cool - thanks!

> [1]: http://ocsigen.org/lwt/2.4.8/api/Lwt_react


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