From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 088A77EE20 for ; Wed, 14 Nov 2012 18:01:02 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of marek@xivilization.net) identity=pra; client-ip=178.63.18.39; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of marek@xivilization.net designates 178.63.18.39 as permitted sender) identity=mailfrom; client-ip=178.63.18.39; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="marek@xivilization.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@coaxial.xivilization.net) identity=helo; client-ip=178.63.18.39; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="marek@xivilization.net"; x-sender="postmaster@coaxial.xivilization.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHbNo1CyPxIn/2dsb2JhbABEwz6BCIIeAQEEAToGAQE4BAsLRiE2GRQHh10DCQoHp1yENwEFdYRQDYlOAgSLRGkFgwCDJ5QqgVSLM4URgnA X-IronPort-AV: E=Sophos;i="4.83,251,1352070000"; d="scan'208";a="162474891" Received: from coaxial.xivilization.net ([178.63.18.39]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 14 Nov 2012 18:00:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xivilization.net; s=xiv; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=2pupUi5Fhj9UaZ2ZIEQNOFcz1NJXK65wAgJtu0vTsac=; b=A3DH9ofhLERKy1ZWF4H+FhrxblYnNNJjZvNU5lip3WxO0jQzRmf3PgxAXEgC8bzSPErLkBFkHmMBqdAoUJManIZhhIu50nkRLfwPphyz//yAveAwLcwNw6e2m94dHb28; Received: from ppp-93-104-184-234.dynamic.mnet-online.de ([93.104.184.234] helo=localhost.localdomain) by coaxial.xivilization.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TYgK0-0001W7-Jh for caml-list@inria.fr; Wed, 14 Nov 2012 18:00:16 +0100 Date: Wed, 14 Nov 2012 18:00:12 +0100 From: Marek Kubica To: caml-list@inria.fr Message-ID: <20121114180012.68bf06df@xivilization.net> In-Reply-To: <50A3ADC1.5090402@gmail.com> References: <20121114124355.7e8ca762@xivilization.net> <50A3ADC1.5090402@gmail.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Preferred layout for new packages On Wed, 14 Nov 2012 09:42:09 -0500 Edgar Friendly wrote: > The community is trying to standardize on Oasis, which generates > ocamlbuild-based build systems. In the future, this may generate > some other build system if a better one comes out. So OASIS it is. Fine. > > 2. Unit tests: I used OUnit which was okay, but maybe there are > > better solutions? I've seen that there is Kaputt and I have seen > > that there is https://github.com/camlunity/ocaml-quickcheck as well > > as https://github.com/vincent-hugot/iTeML which was extracted from > > batteries recently. > iTeML is more of a test extraction framework, and builds on top of > OUnit and a hacked version of the Jane St. quickcheck library. It > can easily support other frameworks, and it would be interesting to > explore a custom framework designed with iTeML in mind. I actually like test extraction frameworks, tools like nose and py.test have made writing tests with Python much nicer, that's why I'm somehow unimpressed how verbose OUnit is. But having the test code in a comment seems ugly to me. Maybe there could be some CamlP4 hack to exclude it on normal compilation? > > 3. Stdlib: I don't mind depending on batteries and/or core, are > > there any reasons against? Especially in the unit tests it drove me > > nuts that I wasn't able to display results without writing > > printers, and I know batteries has at least a generic printer. > Batteries' dump function is a terrible printer for anything beyond > the most basic of purposes, just as the Pervasives.compare is also > terrible. Batteries' printer combinators (`List.print Int.print > stdout [1;2;3]`) are what I use for most purposes. That's a great hint, thanks! regards, Marek