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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id B7F767EF0D for ; Wed, 10 Feb 2016 22:48:57 +0100 (CET) IronPort-PHdr: 9a23:acPFcRfefjhyJ8qiPxt6HlaFlGMj4u6mDksu8pMizoh2WeGdxc6yZx7h7PlgxGXEQZ/co6odzbGG7Oa7AydZvcvJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbvipNuIOU4R2Gf1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHkOz4S41VHkRlFJiCgPF7ReyCp73riz8vON22CicFdz/TbczHz+l6vE4ZgXvjXIoOiQ1uFrLjchoiatdplr1phpxxKbbbZuZceFieafFeNocQyxNU5ACBGR6HoqgYt5XXKI6NuFCoty4/gNWoA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=info@gerd-stolpmann.de; spf=None smtp.mailfrom=info@gerd-stolpmann.de; spf=None smtp.helo=postmaster@mout.kundenserver.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=217.72.192.75; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=217.72.192.75; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=217.72.192.75; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APAQDTr7tWmUvASNlehAxtiFypcYdAgWYXDIUgSgKBODoSAQEBAQEBAQEQAQEBAQEGDQkJIS6CLYIVAQEEVSQQCxguITYGEwkLBgGHawMWAQmyDm+Idg2ERAEBAQEBAQEDAQEBAQEBAREIhRmFMII3ggaCPQtAgScFh1OFVIlRgRkChDGCbIMmA4FwgVxKg3mCfwSFUkSFK4EPh0EnA4JMgVFpAYhSAQEB X-IPAS-Result: A0APAQDTr7tWmUvASNlehAxtiFypcYdAgWYXDIUgSgKBODoSAQEBAQEBAQEQAQEBAQEGDQkJIS6CLYIVAQEEVSQQCxguITYGEwkLBgGHawMWAQmyDm+Idg2ERAEBAQEBAQEDAQEBAQEBAREIhRmFMII3ggaCPQtAgScFh1OFVIlRgRkChDGCbIMmA4FwgVxKg3mCfwSFUkSFK4EPh0EnA4JMgVFpAYhSAQEB X-IronPort-AV: E=Sophos;i="5.22,427,1449529200"; d="asc'?scan'208";a="164253430" Received: from mout.kundenserver.de ([217.72.192.75]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2016 22:48:56 +0100 Received: from office1.lan.sumadev.de ([178.4.66.40]) by mrelayeu.kundenserver.de (mreue102) with ESMTPSA (Nemesis) id 0LvSFP-1a2IcO1ZUR-010gVD; Wed, 10 Feb 2016 22:48:55 +0100 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 6BA6CDC05D; Wed, 10 Feb 2016 22:48:54 +0100 (CET) Message-ID: <1455140917.23513.156.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: Anton Bachin Cc: Gabriel Scherer , caml users Date: Wed, 10 Feb 2016 22:48:37 +0100 In-Reply-To: <16829156-57F5-4517-8263-A367BB552732@yahoo.com> References: <1FE0ECD4-BBD6-48DA-95BD-BB240E07484C@yahoo.com> <1455130851.23513.140.camel@e130.lan.sumadev.de> <16829156-57F5-4517-8263-A367BB552732@yahoo.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-DnB+PlX+iCRt9aba0Fc8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:aYwFswZSU3kob1riPr1d96w/yuKyXced9CCPN6RbOHhN0VezAmm 1hUuB0fmmCJyZSg2q72QbV0fAzhrFT9UrHphkVGBigdAsSmPtow9Y3XjzoCg+IL0I9/MvjT DTSwtxMkHzf2eL93b3x38Wqpc7LVLUgE3yGbfKBxp/domUeEf/JlbROK70r6eOR7my8KrC3 a3GGok7TByjdxoFMJxgXw== X-UI-Out-Filterresults: notjunk:1;V01:K0:69RieKw0ebI=:zHo687d4gv763Y23Edmjlb azJ4Yme0O0Njy/wFnIN9RSG+urXXanl+hoFHsFPfiIvhlX2+m9BEN5SFK43rhDgS/axAIb10t 70E+fax4SoL9igmYQKNvSAeYcnReoN53PVu+YKddiEL5DMG6sER2uKhoDAwk1KxFoGdctTdYi BujId5fmpXXysb/YaaGsdnhEf3I6pFTd0cNWIpiDCIHTBkXdafANr+jxf1cbTYt+jRl9x3C+4 /ceDFYMCrzGirtBzpo24Inz6UTKA6h+4NXx40HStwaTcukLHrxLHSZ1iyVMVqYIsncyLL+XNy q+4CPkWokKO9oez6o6ByvAUxgiMiiedKIGuqSW9DiWFbzH3o1KmOIyzcyUGsgHxlYH5MBw1Fp EuXuxup5zAXyfnpzoe+I+jgic4JUhygwruWexjKzXL9SStqwV/4euaie2bc7LJsmd12aU01v7 9+KcnJm7Gsfo6fBjYKQNZklngmIvma+l4zPuA440aY90KC+KwzGTuIEcQd2eGIBD/9bz3Rdr/ aQdaiicSSx9KZCCTWL8OArRlF5nDclxRKds90uEARBFrHCifS1cGYp57i7OWYwf8FwaGqzdmD z7CA3jaw2ZV7p0XmgyMXOh/LRcFo79NbO1wfrH4SfD/QBufUDPcb9Ai0RaXzpty7/jE8QKGaw HiyVjZHntK9Gas19FnH8sOIR6pEoaSVIODhsIuUdd8zsCInNsyfDNIBGpIZHiraIY4V8= Subject: Re: [Caml-list] =?UTF-8?Q?=5BANN=5D_Bisect=5Fppx_1=2E0=2E0_?= =?UTF-8?Q?=E2=80=93_Modernized_code_coverage_for_OCaml?= --=-DnB+PlX+iCRt9aba0Fc8 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Yes, we used BISECT_MARK a lot to resolve this, but it is a cumbersome and incomplete solution. Well, error paths are special: some errors must not occur at all, and some only in certain configurations, and some errors can be tested out, and others cannot. What I have in mind, is something like: - a new tag NEVER - it is an error if the code is executed. NEVER automatically extends to inner blocks. E.g. if error then begin=20 (* NEVER *) if debug_enabled then debug_log "error"; failwith "error" end An "assert false" automatically counts as NEVER. In contrast, a MARK/VISIT only ignores code and AFAIK it doesn't extend to inner blocks. - conditional sections that can be turned off and on via command-line switches, and that either count as positive (normal) sections or negative sections like NEVER. Something like: (* BEGIN(name) *) ... (* END(name) *) and then a command-line switch (or env variable) -section name=3D(ignore|expect|never) The background for conditional sections is that (1) sometimes certain features are only testable in certain configurations, and (2) you want to have some control for managing testing - let's first focus on feature X but ignore Y for a while. In particular for larger code bases this is very helpful. But anyway, thanks for listening. Bisect was very helpful for testing code. Gerd Am Mittwoch, den 10.02.2016, 13:33 -0600 schrieb Anton Bachin: > Assuming this is what Gerd is indeed looking for, I can confirm that > Bisect_ppx > still supports it. See >=20 >=20 > https://github.com/rleonid/bisect_ppx/blob/master/doc/advanced.md#unreach= able-code >=20 >=20 > We preferred to document only BISECT_VISIT (which does the same > thing), in order > to have only option. But both Bisect_ppx and Bisect support > BISECT_MARK and > BISECT_VISIT. >=20 > > On Feb 10, 2016, at 13:23, Gabriel Scherer > > wrote: > >=20 > >=20 > >=20 > > On Wed, Feb 10, 2016 at 2:00 PM, Gerd Stolpmann > > wrote: > > That's interesting news. In my last job I used (the old) > > bisect > > frequently. > >=20=20=20=20=20=20=20=20=20 > > What I really would love to see is negative coverage: Mark > > code sections > > where you expect that they are never executed. That could be > > a simple > > "assert false" but also more extensive error handling. > > Ideally, the tool > > would automatically recognize certain patterns. > >=20 > >=20 > > The old bisect supports special (*BISECT-MARK*) comment to mark dead > > code for this reason. Do you have something else in mind? > >=20=20 > > That's especially useful when you have a management that is > > after high > > coverage numbers... > >=20=20=20=20=20=20=20=20=20 > > Gerd > >=20=20=20=20=20=20=20=20=20 > >=20=20=20=20=20=20=20=20=20 > > Am Mittwoch, den 10.02.2016, 09:33 -0600 schrieb Anton > > Bachin: > > > Hello, > > > > > > We would like to announce the release of Bisect_ppx 1.0.0, > > a code coverage tool > > > for OCaml with appealing reports: > > > > > > https://github.com/rleonid/bisect_ppx > > > > > > > > > You can see a live coverage report here: > > > > > > http://rleonid.github.io/bisect_ppx/coverage/ > > > > > > Reports can also be submitted to Coveralls.io using > > ocveralls [1]. See an > > > example here [2]. > > > > > > > > > Bisect_ppx is a fork of the original Bisect by Xavier > > Clerc, with extensive > > > further development. Differences from Bisect, and from > > earlier versions of > > > Bisect_ppx, include: > > > > > > - the nicer and more legible HTML reports, > > > - more thorough instrumentation, now including nested > > functions and or-patterns, > > > - improved compatibility with other PPX rewriters, > > > - an Ocamlbuild plugin, > > > - many bugfixes, and > > > - usage, performance, and documentation improvements. > > > > > > > > > Bisect_ppx was originally forked to update and maintain > > Bisect's PPX mode, with > > > the OCaml community moving to PPX. Bisect_ppx does not > > have Bisect's Camlp4 > > > dependency. We do not believe that the original Bisect is > > being actively > > > maintained. > > > > > > > > > Regards, > > > Anton & Leonid > > > > > > > > > P.S. If you are working on a project that uses Bisect_ppx, > > please let us know! > > > > > > > > > [1]: https://github.com/sagotch/ocveralls > > > [2]: > > https://coveralls.io/builds/4913198/source?filename=3Dsrc% > > 2Fsyntax%2FinstrumentPpx.ml > > > > > > > >=20=20=20=20=20=20=20=20=20 > > -- > > ------------------------------------------------------------ > > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > > My OCaml site: http://www.camlcity.org > > Contact details: http://www.camlcity.org/contact.html > > Company homepage: http://www.gerd-stolpmann.de > > ------------------------------------------------------------ > >=20=20=20=20=20=20=20=20=20 > >=20 > >=20 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-DnB+PlX+iCRt9aba0Fc8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJWu7A1AAoJEAaM4b9ZLB5TOkEH/iLG+GYVioD38A3h12gKnjGJ X5VNEytayAV4zQmdqj3J7jLWMgqFAeEWX8d4pHXgTF3CPN1LNpUnPwBvC+6rkGug fq/QP2fYBcSRBmpE8zS+ogMVJNzbl7MWmYz3+Knc06hu3NkDuBiNQudqTUuInNMk VH4yG9oUwzPRLAV3uspewQwY2Q2vpBYb1fh+RbnR2ZLPCcs5GCGCKzpvbFN/E6WT eRp5BaQZkSYdNCMXSiU/PIP7tT5vR5AMveCfM/Ace9G39cTxNLe96qp/De1ZXRec hk3W0b6MzyBIG15/7Jg3k8xxsiTBx/ACPfzEF/yPpwqb3mJW9k7n8YT/gBsC7M8= =k4yX -----END PGP SIGNATURE----- --=-DnB+PlX+iCRt9aba0Fc8--