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 D56257EF0D for ; Fri, 12 Feb 2016 07:44:55 +0100 (CET) IronPort-PHdr: 9a23:nN7aahM1oaGdDMV9BX4l6mtUPXoX/o7sNwtQ0KIMzox0KPj6rarrMEGX3/hxlliBBdydsKIbzbGL+PG+EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35vxjL35qsObSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6Lpyv/JHBK7zeqB9Sb1DEBwnNXo07Yvlr0rtVwyKs1cVTGQapT9lJTT/TVmuUpL8tDfgu8J52S+HLYj4V7kyUjnk6L1kHky7wBwbPiI0pTmEwvd7i7hW9Uqs Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=dmentre@linux-france.org; spf=None smtp.mailfrom=dmentre@linux-france.org; spf=None smtp.helo=postmaster@tempura.bentobako.org Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dmentre@linux-france.org) identity=pra; client-ip=94.23.39.64; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dmentre@linux-france.org"; x-sender="dmentre@linux-france.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dmentre@linux-france.org) identity=mailfrom; client-ip=94.23.39.64; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dmentre@linux-france.org"; x-sender="dmentre@linux-france.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@tempura.bentobako.org) identity=helo; client-ip=94.23.39.64; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dmentre@linux-france.org"; x-sender="postmaster@tempura.bentobako.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqBQBJfr1W/0AnF15egzoVPW2IW7MjIYVsAoE1OxEBAQEBAQEBAYEJgi2CFQEBAwEyAUURCyEMCg8JAwIBAgENOBMIAQEbh3MMAQmyIoEFjXIBCxoEiUx7hHENg24FlncThT2RKYVSRI16NiyCAhmBSmkBiB4BAQE X-IPAS-Result: A0AqBQBJfr1W/0AnF15egzoVPW2IW7MjIYVsAoE1OxEBAQEBAQEBAYEJgi2CFQEBAwEyAUURCyEMCg8JAwIBAgENOBMIAQEbh3MMAQmyIoEFjXIBCxoEiUx7hHENg24FlncThT2RKYVSRI16NiyCAhmBSmkBiB4BAQE X-IronPort-AV: E=Sophos;i="5.22,435,1449529200"; d="scan'208";a="164423425" Received: from tempura.bentobako.org ([94.23.39.64]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 12 Feb 2016 07:44:55 +0100 Received: from [192.168.0.18] (114.196.8.109.rev.sfr.net [109.8.196.114]) by tempura.bentobako.org (Postfix) with ESMTPSA id C87E73320 for ; Fri, 12 Feb 2016 07:44:53 +0100 (CET) To: caml-list@inria.fr References: <1FE0ECD4-BBD6-48DA-95BD-BB240E07484C@yahoo.com> <56BB694D.1030306@linux-france.org> <5F24126F-5082-42B8-9FCF-87F924892CA5@yahoo.com> From: =?UTF-8?Q?David_MENTR=c3=89?= X-Enigmail-Draft-Status: N1110 Message-ID: <56BD7F65.1050909@linux-france.org> Date: Fri, 12 Feb 2016 07:44:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5F24126F-5082-42B8-9FCF-87F924892CA5@yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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?= Hello Anton, Thank you for your detailed explanations. Le 2016-02-10 20:27, Anton Bachin a écrit : >> * l. 110, 'f x' is not green? 'f' seems to be called if the previous "try" is green. >> > https://rleonid.github.io/bisect_ppx/coverage/file0004.html#L110 > The “f x” in try is evaluated if and only if the whole try-expression is > evaluated – unless, perhaps, the *implementation* of exception handling can > cause a memory or stack overflow exception to occur between these two points – > can someone knowledgeable comment? However, assuming my previous statement is > correct, it’s not necessary to have a mark in both places. We chose to put the > mark on “try” because it is technically very slightly easier to do so. However, > we could be convinced to move it to the expression instead. Well I would have marked the "f x". My reasoning is simple, if f is executed, it should be green. And f is more important than try regarding coverage. >> > Overall, I would expect all code lines to be either green, red or yellow, not without colour (except for comments and type and exception definitions). > Bisect_ppx colors expressions and not lines – the line colors just indicate > whether there is a colored expression on each line. So, yes, while many lines in > expressions should be colored, some won’t be – for example, from above, lines > containing only delimiters such as “then”, “else”, and “end”. Two remarks: * If expressions are marked (which I suspected), then the HTML output should color at expression granularity level and not line granularity level. Therefore you would have only green or red and never orange[1] (which would be simpler and clearer); * You could do some post-processing to look for such keywords as “then”, “else”, and “end” and color them accordingly. It might be more a hack than a clean approach, but I think it would make the output more readable. All that said, I'm not using your tool (for now), so I would understand that you not take my remarks into account. ;-) Best regards, david [1] Or maybe only in the summary on the left side of file display.