Here is the latest OCaml Weekly News, for the week of March 13 to 20, 2018.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-03/msg00040.htmlNicolás Ojeda Bär announced:
I am happy to announce a new caml-list mirror, accessible at: https://inbox.ocaml.org/caml-list Some advantages with respect to the official archive (sympa): - threads are not broken at month boundaries; - powerful search; - more usable interface (in my opinion); - it is easy to get a copy of the full archive: git clone --mirror https://inbox.ocaml.org/caml-list. The new mirror is powered by https://public-inbox.org/, where you can go to learn more about it. If you run into trouble or have any comments at all, do not hesitate to get in touch either directly or via caml-list.
Archive: https://discuss.ocaml.org/t/ann-bap-1-4-release/1711/1Ivan Gotovchits announced:
After six months of active development, the BAP Team is proud to announce the release of the Binary Analysis Platform 1.4. The Carnegie Mellon University Binary Analysis Platform ([CMU BAP]) is a reverse engineering and program analysis platform that works with binary code and doesn't require the source code. BAP supports multiple architectures: ARM, x86, x86-64, PowerPC, and MIPS. BAP disassembles and lifts binary code into the RISC-like BAP Instruction Language (BIL). Program analysis is performed using the BIL representation and is architecture independent in a sense that it will work equally well for all supported architectures. The platform comes with a set of tools, libraries, and plugins. The main purpose of BAP is to provide a toolkit for implementing automated program analysis. BAP is written in OCaml and it is the preferred language to write analysis, we have bindings to C, Python, and Rust. The Primus Framework also provides a Lisp-like DSL for writing program analysis tools. The new release brings quite a few new features and several bug fixes. All summarized below. We would like to especially thank Anton Kochkov (aka [XVilka]) for contributing the MIPS lifter, and [SoftSec Lab] for extensive testing and verification of our lifter semantics. BAP v1.4 can be installed via the OCaml Package Manager ([opam]) and NixOS package manager ([nix]). You can also use prebuilt deb, rpm, or tgz [packages] or build BAP manually from sources. A good selection of [docker] and [vagrant] recipes is also available, with some prebuilt docker images uploaded to [DockerHub]. BAP is a moving target, so we are also encouraging everyone to use our rolling releases opam repository, that will give you access to the newest features and bug fixes as soon as they got merged into the master branch. Just add it to your opam with ``` opam repo add bap-testing \ https://github.com/BinaryAnalysisPlatform/opam-repository.git#testing ``` # Release Notes ## Features * MIPS and MIPS64 lifters * PowerPC and PowerPC64 lifters * LLVM 5.0 compatibility * BARE Binary Analysis Rule Engine * New Taint Analysis Framework * Primus Lisp 2.0 with symbols and methods * Recipes * Primus Test Framework * Dataflow and Abstract Interpretation Framework * Progress Reports and Profilers * New primitives for BML ## Bug fixes * Incorrect error handling in x86 lifter * Failure to decode ICC binaries * Fixes equiv type in Graphlib * Unhardcodes llvm backed in the linear sweep disassembler * Fixes the memory printer * Fixes handling relocations in reconstructor * Fixes race condition in the source merge procedure * Restores the source-type command line option * Proper handling of tail calls in IR lifter * Fixes segment registers in mov instruction * Fixes xor in the BIL simplfication procedure * Fixes flag calculation in the x86 sub instruction * Fixes numerous missed sign extensions in x86 lifter * Adds modulo operation to x86 rot/rol instructions * Fixes operands order in the x86 xadd instruction * Fixes segment duplication : https://github.com/BinaryAnalysisPlatform/bap : https://github.com/XVilka : https://softsec.kaist.ac.kr/ : https://opam.ocaml.org/packages/bap : https://github.com/NixOS/nixpkgs/pull/36194 : https://github.com/BinaryAnalysisPlatform/bap/releases : https://github.com/BinaryAnalysisPlatform/bap/tree/master/docker : https://github.com/BinaryAnalysisPlatform/bap/tree/master/vagrant : https://hub.docker.com/u/binaryanalysisplatform/
Archive: https://discuss.ocaml.org/t/ocaml-git-git-design-and-implementation/1718/1Calascibetta Romain announced:
May be you don't know but we have a pure implementation of `git` in OCaml. This big work started by @samoht a few years ago will be change a lot internally and on the API to fit on MirageOS and, more generally, as a server software. The final goal is to use (but it's already done in some cases like [Canopy](https://github.com/Engil/Canopy)) `ocaml-git` as a data-store of a MirageOS with [`Irmin`](https://github.com/mirage/irmin). By this way, it's easy to tracking any update of your data-store, `revert` them (if you find any problem) and replicate to an usual `git` repository (on GitHub for example). It stills an experimental project which we have open questions about design, interface and implementation. The good news is we are able to change before the expected big release (which add lot of stuffs on `ocaml-git` and fix some bugs about memory consumption). However, find the better way for any use-case it's not easy for a single or two brains. So currenlty, we have some pending questions about design and implementation which need feedback. As a good community manager, i try to explain at any step my choice, the context and possibilities. For a long time, these discussions did in OCamllabs (because they are particularly technical) but we across a big step when `ocaml-git` can be use now. This topic could be a good place to report any strong update which breaks API, semantic and a good way to explain step by step what is **really** `git` internally (specification, details, limitations and so on ...). Finally, it could be a good entry point to participate in any way (question, explanation, documentation, or c0d3) to this big project. And, as the first design question, you can follow this issue: https://github.com/mirage/ocaml-git/issues/286 And because I'm currently on the MirageOS retreat in Marrakech, I would like to say: good hacking! PS: this big project is a part of a huge project, MirageOS. So, for many people, it's difficult to see links between `ocaml-git` and others project (like `irmin`, `wodan`, etc.) and constraints. But don't be afraid, we are here to help to understand globally all.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-03/msg00048.htmlFrancois BERENGER announced:
I created a thin wrapper around the xgboost R package. The code is here: https://github.com/UnixJunkie/orxgboost The interface is close to my precedent SVM package (orsvm-e1071). Background: https://en.wikipedia.org/wiki/Gradient_boosting Paper: Chen, Tianqi, and Carlos Guestrin. "Xgboost: A scalable tree boosting system." Proceedings of KDD'16. ACM, 2016. DOI: 10.1145/2939672.2939785.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2018-03/msg00051.htmlBe Sport announced:
Archive: https://discuss.ocaml.org/t/what-is-the-reason-of-separation-of-module-implementation-and-signatures-in-ocaml/1735/29Deep in this huge thread, Ivan Gotovchits said:
In the ML module system, modules represent [abstract data types] with existential types, as shown in the [foundational work by Mitchel and Plotkin]. Compare with conventional languages, such Java or C++, where abstract data types are (poorly) modeled with classes (and interfaces) that bind together the nominal abstraction with the set of methods (operations). The ML module system does not invent any ad-hoc constructs, such as classes, but relies on mathematics to deliver proper definitions that are well-tested by time. In the ML module system, structures denote [mathematical objects], and their types are denoted by the [signatures]. The separation between abstraction and implementation is the essential part of modular programming in particular and reasoning in general. Properly chosen abstractions reduce the amount of information that we need to reason about and allow us to build complex systems from smaller parts. One of the responsibilities of the modular system in programming languages is to protect the abstractions by ensuring that modules depend on abstractions, not implementations. Consider Python, Common Lisp, and many other dynamically typed languages that do not protect the abstractions as they do not provide mandatory information hiding mechanisms. As a project evolve, the diffusion process rots through the module binaries, that essentially leads to projects that are hard to maintain and hard to understand. Of course, the ML module system is not the only mechanism for implementing abstract data types. We have also classes and interfaces (as in Java,C++), another option is to use type classes as in Haskell (they all basically differ in the way how the represent polymorphism - that's a completely different topic). But in any case, just having types of definitions, without providing a mechanism to define types of mathematical structures (i.e., sets of operations) is not enough. Whether or not to have a separate mli file for signatures that is a design question. I personally like it, though it poses some technical problems and doesn't play well with namespaces. In OCaml, you can consider mli files as a shorthand and even consider them optional. Some projects (e.g., ocamlbuild) define all their abstractions (module types) in one ml file, that is used then, in different implementations. Although that's not common today, it's a viable option. : https://en.wikipedia.org/wiki/Abstract_data_type : http://delivery.acm.org/10.1145/50000/45065/p470-mitchell.pdf?ip=18.104.22.168&id=45065&acc=ACTIVE%20SERVICE&key=A792924B58C015C1%2E5A12BE0369099858%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&__acm__=1521472465_27441f74c41007e12833a005cbd35aad : https://en.wikipedia.org/wiki/Signature_(logic) : https://en.wikipedia.org/wiki/Mathematical_structureXavier Leroy then added:
Many very good points were raised already, so I'll just add a couple of historical notes and personal preferences. The "one compilation unit = one .mli interface file + one .ml implementation file" design goes back to Caml Light and was taken from Modula-2, Wirth's excellent Pascal successor. As previously mentioned, it works great with separate compilation and parallel "make". But the main point in favor, in my opinion, is that it clearly separates the user's view of the module (the .mli file) from the implementor's view (the .ml file). In particular, documentation comments on how to use the module go to the .mli file; comments about the implementation go to the .ml file. This stands in sharp contrast with most of the Java code I've written and read, where comments are an awful mixture of documentation comments and implementation comments, and serious IDE support is needed to see just the user's view of a class and nothingelse. Also, in the .mli file declarations can be listed in the most natural / pedagogical order, starting with the most useful functions and finishing with less common ones, while definitions in .ml files must come in bottom-up dependency order. OCaml combines this Modula-2 approach to compilation units with a Standard ML-like language of modules, featuring nested structures, functors, and multiple views of structures. The latter is a rarely-used but cool feature whereas a given structure can be constrained by several signatures to give different views on the implementation, e.g. one with full type abstraction for use by the general public and another with more transparent types for use by "friend" modules. Again, and perhaps even more than in Modula-2, it makes sense to separate structures (implementations) from signatures (interfaces) that control how much of the implementation is visible.
Here are links from many OCaml blogs aggregated at OCaml Planet, http://ocaml.org/community/planet/. Release of Alt-Ergo 2.1.0 http://www.ocamlpro.com/2018/03/14/release-of-alt-ergo-2-1-0/
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.