Hello, Here is the latest OCaml Weekly News, for the week of November 29 to December 06, 2016.
1) llpp v25 2) ocaml-vdom (pre-release) 3) Android/iOS apps with OCaml 4) Next OUPS meetup, Dec. 6th 2016 5) Base, Stdio and Jbuilder 0.1.alpha1 6) Other OCaml News ======================================================================== 1) llpp v25 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00112.html> ------------------------------------------------------------------------ ** moosotc announced: New version of llpp (tagged v25) is now available at: * <http://repo.or.cz/w/llpp.git> (has "tutorial" videos) * <https://github.com/moosotc/llpp/> (has a bug tracker) ============================================================================ Changes (relative to v23) * improved keyboard link navigation * custom key mappings are shown in the help screen * build.sh script should work again (???? ????) * bugfixes * synced with mupdf 1.10a * reworked handling of keyboard events (pp.sed is gone and porting to other windowing systems should be much simpler now) ============================================================================ Summary v23..v25 67 malc Diffstat v23..v25 BUILDING | 2 +- Shakefile.hs | 83 +- Thanks | 1 + build.sh | 5 +- config.ml | 1474 ++++++------ keys.ml | 7 + link.c | 264 +-- main.ml | 7449 +++++++++++++++++++++++++++++----------------------------- misc/dllpp | 2 + parser.ml | 220 +- pp.sed | 86 - todo.org | 15 +- utils.ml | 50 +- wsi.ml | 1234 +++++----- wsi.mli | 50 +- 15 files changed, 5498 insertions(+), 5444 deletions(-) ======================================================================== 2) ocaml-vdom (pre-release) Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00113.html> ------------------------------------------------------------------------ ** Alain Frisch announced: You might be interested in the ocaml-vdom project which has been used by LexiFi for some time and open-sourced recently. It contains two components which we use to create our browser-side UIs with js_of_ocaml and which might be useful to the community: - Bindings to the DOM and other browser APIs, implemented with gen_js_api. (Partial bindings, expanded on demand.) - An implementation of a "virtual DOM" and the "Elm architecture", i.e. a programming model where the UI is specified by a state type, a view function (producing a functional version of the DOM), and an update function that modifies the state based on messages (generated by UI events or external interactions). Project page: <https://github.com/LexiFi/ocaml-vdom> ** Yaron Minsky and Alain Frisch then discussed: Yaron: >> Alain, this looks awesome! We'll take a look at this and maybe use it >> instead of the javascript library we're currently depending on here: >> >> <https://github.com/janestreet/virtual_dom> >> >> I'm curious if you have any story for making the recomputation of the >> virtual-dom itself more efficient. Right now, we're using incremental >> for this part of the story, as reflected here: >> >> <https://github.com/janestreet/incr_dom> >> >> That said, for small UIs, this kind of incrementality is less >> important, so whether this is worth doing may depend on your >> applications. Alain: > Our story w.r.t. updating the vdom itself is the same as Elm, I believe: > > 1. In the vast majority of cases, the mapping from the "state" to the vdom > is very quick and it is ok to recompute the full vdom on every state change. > > An argument often made in the vdom space is that a UI usable by human-beings > cannot possibly have a very big DOM (moreover, even recent browsers such as > the latest Edge or Firefox struggle with tables starting at a few thousands > rows), and that computing the full vdom "cannot be that costly". I don't > want to enter such discussion here, but in our own use cases, we indeed try > to avoid "overly big UIs" and we don't have strong performance requirements > such as continuous streams of updates pushed by the server; if it takes 10ms > to react on a user UI event, it is perfectly fine for our case. My > intuition is that most applications would be a similar situation, but I > appreciate that you have very different kinds of UIs and performance > constraints that require a more incremental approach. Yaron: I do think for even moderate size views of data (big tables, graphs, etc.) this argument stops working pretty quickly, but I agree there is a large scope of applications for which this is true. It's worth noting that we use Incremental to pull off what we've called "partial rendering", which is to render a table with, say, 10k rows, but only actually rendering the 60 or so that are actually in view. This makes what would otherwise be rather sluggish applications quite zippy. Alain: > 2. The library provides: > > val memo: ?key:string -> ('a -> 'msg vdom) -> 'a -> 'msg vdom > (** Apply the function to generate a VDOM tree only if the function > or its argument have changed (physically) from the previous > synchronization. *) > > (similar to Elm's Lazy: > <http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Lazy> ) > > This is typically used when embedding the view of a "sub-component" derived > from only part of the our current state. If we can ensure this sub-part > remains the same, the previous vdom (at the same "site") is reused, which > skips both the vdom generation and the vdom diffing. Typically, the > generation function would be a toplevel declaration (so it will always be > the same, physically) and we arrange to avoid touching the part of the > global state on which it depends. > > Of course, it is also possible to use any other mechanism (such a > memoization table) to reuse previously computed vdoms. Yaron: One downside of the Elm style approach is that physical equality is brittle, e.g., if you end up constructing something that's logically but not physically equal, you can end up recomputing a lot more than you might have expected. I do think making it possible to add a custom equality function makes this a bit better, and is an easy change to make. Yaron: >> Another thought: you might want to consider the design we used for our >> wrapper on Matt Esch's virtual-dom library. In particular, in our >> design we don't need a type-parameter for vdom nodes determining the >> type of a message, and we don't need the corresponding map >> functions. Instead, we use open types and a registration and dispatch >> mechanism for values thus injected. Alain: > Thanks for the hint. > > Do you have pointers to code examples using the "inject" function? It seems > to me that you will need to apply to it produce any "message" in the view > function. > > In our library, you can write directly: > > input "+" ~a:[value "+"; type_button; onclick `Plus] > > With the "inject" approach, do you need to write it like: > > input "+" ~a:[value "+"; type_button; onclick (inject `Plus)] > > ? Yaron: Here's an example: <https://github.com/janestreet/incr_dom/blob/master/example/incr_decr/counters.ml> And the tradeoffs you imply is indeed there. I find the code without the type parameter easier to use and think about, but I agree that the "lightness" argument isn't 100% clear. Another advantage of the Event approach is that we have combinators like Event.Many that let you deliver a list of events together, and primitive events like Stop_propagation and Viewport_changed, which are always available, independent of the concrete event type. We've found this to be quite useful in separating out the pure and imperative parts of the application. Alain: > If so, this does not seem strictly lighter than using the "map" function > occasionally. Moreover this seems to open the door to possible problems if > a vdom fragment producing some kinds of messages is injected in a "host > application" that cannot process these messages. It also means that one > needs to take the identity of the "inject" function itself into account in > order to memoize vdom-generation functions. Yaron: The issue about the identity of the inject function is real, and the use of Incremental helps us here, making it easy to preserve physical identity. Also, Incremental allows you to be freer in your use of functional programming idioms, letting you pass closures around to the various render functions without destroying physical equality. As far as I understand it, the Elm-style approach tends to require a fairly first-order style in order to make memoization effective. That said, using Incremental is a pretty heavy hammer to solve this problem, so if you don't care about incremental computation more generally, it's not clear it's worth the trouble. Alain: > Basically, we need "map" on "component boundaries", and even not always, > since components can take ad hoc injection functions to wrap their messages > into their "host" own message type (as the SelectionList example in > <https://github.com/LexiFi/ocaml-vdom/blob/master/examples/vdom_ui.mli> ). > > The library does use extensible types (with a registration/dispatch > mechanism) in two other places, though: > > - "Commands" (encapsulation of side-effectul operations). The set > of "command constructors" is small and has a global nature > (e.g. "AJAX query", "timer", etc), while the type of "messages" > is specific to each application and component. Nice. This is part of what we're doing in our Event type. > - "Custom nodes" in the VDOM which allow plugging "native" > components (again, the set of such possible components is more > "fixed" than messages). Interesting. I'll take a look. ** Martin DeMello asked and Alain Frisch replied: > Any tips on setting up a project? For example, with elm I use > elm-webpack-starter [<https://github.com/moarwick/elm-webpack-starter>], > which sets up an asset pipeline and a dev environment with live reloading. I've added a simple "Usage" section to the project's README. But don't expect (yet) a rich ecosystem around the project! ** Vincent Balat asked and Alain Frisch replied: > How would you compare the virtual DOM with a functional reactive > interface, as you can do with Tyxml and React? First, let me insist that I have zero experience with functional reactive interface, Tyxml or React. So I'm not in a very good position to comment on them! My *intuition* is that the tradeoff would be a bit similar to the one with Jane Street's Incremental. Both FRP and SAC require to introduce extra concepts (signals, events, variables, observers; specific maps and binds) which add some weight compared to a simple one-directional "view" mapping from state to vdom. What you gain with those approaches is a more fine-grained notion of update, which can be necessary in some cases. Interestingly, Elm moved away from FRP : <http://elm-lang.org/blog/farewell-to-frp> . This is not just a shift of terminology, and it corresponds to the removal of the "Address" argument on the view function in favor of a parametrized vdom type: <https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md#no-more-signaladdress> (In a sense, the "Address" argument is rather similar to the "inject" function which we discussed with Yaron.) About Tyxml itself: I think that it addresses a rather different set of issues (ensuring that the DOM is "statically correct" w.r.t. definition of HTML5/SVG). We haven't identified those issues as being relevant for us, i.e. we have never hit a bug related to breaking such validity constraints, and the lack of static typing does not seem to make refactoring UI code more difficult or fragile; so it's not clear to us that adding more static typing here would help. If we tried to combine it with our vdom approach, it would probably add some noise, since the vdom type would receive extra type parameters, which would be visible in the interface of all components exposing "view" functions. ** Vincent Balat then said and Alain Frisch replied: > Using Tyxml with React is straightforward and makes your pages reactive > almost for free. > > If your page contains : > p [ text (string_of int i) ] > you juste replace this by > p [ R.text (React.S.map string_of int i) ] > > and it is automatically updated when the value of i changes ... > > And with Eliom you can even created these reactive pages from server side ... I'm not sure to follow: in the "Elm/vdom" approach, the original p [ text (string_of int i) ] has the behavior you describe: the content of the text node will always be equal to "string_of_int i" and you don't have to do any explicit update to achieve that. That's the beauty of the model. I guess this could be qualified as "reactive" as well, except that the entire view is refreshed when any part of the state change (and the vdom diffing approach makes this viable). ** Yaron Minsky also replied to Alain: > First, let me insist that I have zero experience with functional reactive > interface, Tyxml or React. So I'm not in a very good position to comment on > them! > > My *intuition* is that the tradeoff would be a bit similar to the one with > Jane Street's Incremental. Both FRP and SAC require to introduce extra > concepts (signals, events, variables, observers; specific maps and binds) > which add some weight compared to a simple one-directional "view" mapping > from state to vdom. What you gain with those approaches is a more > fine-grained notion of update, which can be necessary in some cases. I think FRP and SAC are pretty different in their roles here. Really, SAC is just a system for optimizing a unidirectional computation --- in the end, your view is pretty close to a function of this signature: val view : Model.t Incr.t -> Vdom.t Incr.t which is really just an incremental version of an ordinary function. You don't have to think about anything signal-like when you consider the semantics of your function: the semantics are exaclty what you get if you replaced every monadic bind with an ordinary let-binding. My somewhat biased view is that SAC addresses performance, which is an issue of fundamental importance for UIs, whereas FRP doesn't address a problem which is similarly central. And the ability to express time-dependent computations (which FRP provides) adds lots of other problems (in particular, monadic FRP is plagued by space leaks.) > Interestingly, Elm moved away from FRP : > <http://elm-lang.org/blog/farewell-to-frp> . This is not just a shift of > terminology, and it corresponds to the removal of the "Address" argument on > the view function in favor of a parametrized vdom type: > > <https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md#no-more-signaladdress> > > (In a sense, the "Address" argument is rather similar to the "inject" > function which we discussed with Yaron.) Having talked to Evan a decent amount about this, my takeaway is that FRP in Elm wasn't really used to improve performance, and without that, it wasn't worth the conceptual weight. Incremental adds some conceptual weight (less, I claim, than traditional FRP libraries), but it also solves a real problem. React and Elm style solutions are simply not capable of implementing highly efficient views of fast changing data; indeed, they typically use special-purpose imperative libraries for implementing applications that require it. Incremental lets you do this kind of optimization in one smooth, functional framework. The cost, obviously, is you need to be comfortable living in a monad. For our developers, this doesn't count as that much of a cost these days, given the proliferation of other monadic abstractions in our code. But it's not trivial. > About Tyxml itself: I think that it addresses a rather different set of > issues (ensuring that the DOM is "statically correct" w.r.t. definition of > HTML5/SVG). We haven't identified those issues as being relevant for us, > i.e. we have never hit a bug related to breaking such validity constraints, > and the lack of static typing does not seem to make refactoring UI code more > difficult or fragile; so it's not clear to us that adding more static typing > here would help. If we tried to combine it with our vdom approach, it would > probably add some noise, since the vdom type would receive extra type > parameters, which would be visible in the interface of all components > exposing "view" functions. We support both TyXML and a simpler, untyped vdom API. My personal view pretty much matches yours, but other users (Hugo Heuzard in particular) prefers it pretty strongly. The lack of an extra type parameter in our approach makes the integration with TyXML easier, I suppose. ** Ashish Agarwal then added: I don't have a strong opinion either way, but one point not mentioned about Tyxml is that you get nice auto-completion when combined with merlin. I've been pleased to learn the possible values for some attributes while coding without having to reference any documentation. ======================================================================== 3) Android/iOS apps with OCaml Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-11/msg00115.html> ------------------------------------------------------------------------ ** Deep in this thread, Vincent Balat announced: The Ocsigen team is going to release Eliom 6 next week, which focuses on mobile apps. We will also release Ocsigen Start, a template with an example of multi platform application: a single code for both your Web app and mobile html5 apps (Android, iOS, Windows). If you want to see an example, download the Be Sport app on Google Play or Apple app store and have a look at the Web app. They are all using Eliom 6 and Ocsigen Start. <https://play.google.com/store/apps/details?id=com.besport.www.mobile> <https://itunes.apple.com/us/app/besport/id1104216922> It is not native code but the performance are good (even if we have some problems on iOS, Apple's webview being very buggy). And this technique requires to write only one code for all your apps (even with server side generated pages for the Web version!). Ocsigen Start will be released probably next week (we are polishing the documentation) but is mature enough for large applications (as you can see with Be Sport). We are also using the Cordova bindings by Danny Willems, for some features. ** Ian Zimmerman then asked and Vincent Balat replied: > Is there (or can there be <grin/>) a place to get the app, other than > the google store? > > I use CyanogenMod and F-Droid exclusively; I'm very curious about this > technology, but not enough to start using google again. If you don't want to use Google Play, you can get the Android application from here: <http://besport.com/besport-103010.apk> ======================================================================== 4) Next OUPS meetup, Dec. 6th 2016 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00014.html> ------------------------------------------------------------------------ ** Bruno Bernardo announced: The OUPS meetup is back. The next one will take place on Tuesday, Dec. 6, 7pm at IRILL on the Jussieu campus. (Sorry for the late announcement!) As usual, we will have a few talks, followed by pizzas and drinks. The talks will be the following: - Hongbo Zhang on BuckleScript - seamless integration with JavaScript ecosystem. - Gabriel Radanne on Tyre : Typed Regular Expressions - Marc Lasson on Landmarks: A Simple Profiling Library Please do note that we are always in demand of talk *proposals* for future meetups. To register, or for more information, go here: <https://www.meetup.com/ocaml-paris/events/235672152/> *Registration is required! Access is not guaranteed after 7pm if you're not registered.* (It also helps us to order the right amount of food.) Slides from previous sessions are available online: <https://www.meetup.com/ocaml-paris/files/> Access map: IRILL - Université Pierre et Marie Curie (Paris VI) Barre 15-16 1er étage 4 Place Jussieu 75005 Paris <https://goo.gl/maps/EjvCFrKSXRs> The meetup organizers. ======================================================================== 5) Base, Stdio and Jbuilder 0.1.alpha1 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2016-12/msg00026.html> ------------------------------------------------------------------------ ** Jeremie Dimino announced: I am pleased to announce the first alpha release of the Base library. Base is a standard library for OCaml. It is not an extension but rather a wholesale replacement of the standard library distributed with the OCaml compiler. In particular, it makes different choices and doesn't re-export features that are not fully portable such as I/O, which are left to other libraries. This release is not production ready, several things are still missing and some APIs will change before the first release. However, all the features we wanted to include to ensure that Base is a serious alternative to the standard library are now setup and working. Most of these features concern the build of Base: 1. Base has zero dependencies, except for its build system. In particular, it doesn?t require ppx rewriters and builds without make or even bash. This is true for both release tarballs and for the git repository itself 2. Base doesn't use module packs, instead it uses module aliases. This means that if you link against Base you will link against only the subset of modules that is needed 3. The layout of the code base is the one you would expect, i.e. Base.String is implemented in src/string.ml The roadmap for the first stable release is described in the README of Base. Along with Base, we are releasing two new packages: Stdio and Jbuilder. Base aims to be fully portable and therefore doesn't provide I/O functions. These are re-exported from the OCaml standard library as the Stdio library. Jbuilder is a build system that interprets the jbuild file format used at Jane Street to describe libraries and executables. It is intended as a release build system; it has zero dependencies outside of the OCaml compiler and aims to be fast and portable. The long term goal is to be able to use the same rules with both Jbuilder and Jenga, so that one can develop comfortably with Jenga and release with Jbuilder. Base, Stdio and Jbuilder are in the main opam repository and their code is available on github: - <https://github.com/janestreet/base> - <https://github.com/janestreet/stdio> - <https://github.com/janestreet/jbuilder> Note that the development versions of Jane Street packages currently don't build against Base 0.1.alpha1. They will be updated next week. ** Malcolm Matalka asked and Jeremie Dimino replied: > What's the relationship between Base and Core? is this another std > library in the mix or does it replace Core as a stdlib alternative? Core is a richer stdlib that supersedes Base. More precisely, Core_kernel supersedes Base and Core supersedes Core_kernel. Core_kernel adds bin_prot as well as some other features that are not necessarily as general purpose than what is in Base. Core adds less portable features and depends on Unix. But the main difference between Base and Core_kernel is that Base comes first in the dependency graph. In particular, we can't use Core_kernel in sexplib, bin_prot or any ppx rewriter used in Core_kernel. As a result we end up reimplementing the same functions over and over again. Moreover improvements to Core_kernel don't benefit sexplib or bin_prot. Now everything has the same base. Given that Base has much less dependencies than Core_kernel, it should also be more attractive to people who want to keep a low number of dependencies. ======================================================================== 6) Other OCaml News ------------------------------------------------------------------------ ** From the ocamlcore planet blog: Here are links from many OCaml blogs aggregated at OCaml Planet, <http://ocaml.org/community/planet/>. Full Time: Software Developer (Functional Programming) at Jane Street in New York, NY; London, UK; Hong Kong <http://jobs.github.com/positions/0a9333c4-71da-11e0-9ac7-692793c00b45> Back End Functional Developer at NYU (Full-time) <https://functionaljobs.com/jobs/8973-back-end-functional-developer-at-nyu> ======================================================================== Old cwn ------------------------------------------------------------------------ If you happen to miss a CWN, you can send me a message (alan.schm...@polytechnique.org) and I'll mail it to you, or go take a look at the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish to receive it every week by mail, you may subscribe online at <http://lists.idyll.org/listinfo/caml-news-weekly/> . ======================================================================== -- OpenPGP Key ID : 040D0A3B4ED2E5C7 Monthly Athmospheric CO₂, Mauna Loa Obs. 2016-10: 401.57, 2015-10: 398.29
signature.asc
Description: PGP signature
_______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly
