From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id RAhdLxZV7GGrQQAAgWs5BA (envelope-from ) for ; Sat, 22 Jan 2022 20:03:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id uDFdJxZV7GFOVAEAG6o9tA (envelope-from ) for ; Sat, 22 Jan 2022 20:03:50 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 02EEB2DBAD for ; Sat, 22 Jan 2022 20:03:49 +0100 (CET) Received: from localhost ([::1]:36888 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBLfv-0003s7-29 for larch@yhetil.org; Sat, 22 Jan 2022 14:03:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBLYw-0005Mw-UW for guix-patches@gnu.org; Sat, 22 Jan 2022 13:56:35 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:44991) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nBLYQ-00008v-En for guix-patches@gnu.org; Sat, 22 Jan 2022 13:56:09 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nBLYQ-0003QX-CJ for guix-patches@gnu.org; Sat, 22 Jan 2022 13:56:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#53389] [PATCH 0/9] Replace some mocking with with-http-server*, avoid hardcoding ports, Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 22 Jan 2022 18:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53389 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 53389@debbugs.gnu.org Received: via spool by 53389-submit@debbugs.gnu.org id=B53389.164287774213142 (code B ref 53389); Sat, 22 Jan 2022 18:56:02 +0000 Received: (at 53389) by debbugs.gnu.org; 22 Jan 2022 18:55:42 +0000 Received: from localhost ([127.0.0.1]:37894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBLY6-0003Pu-9q for submit@debbugs.gnu.org; Sat, 22 Jan 2022 13:55:42 -0500 Received: from albert.telenet-ops.be ([195.130.137.90]:41920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBLY0-0003Pi-MN for 53389@debbugs.gnu.org; Sat, 22 Jan 2022 13:55:41 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by albert.telenet-ops.be with bizsmtp id luva260154UW6Th06uvaAq; Sat, 22 Jan 2022 19:55:35 +0100 Message-ID: <687d96c300852e684422de877cd87769daae7ccd.camel@telenet.be> From: Maxime Devos Date: Sat, 22 Jan 2022 19:55:30 +0100 In-Reply-To: <87lez7zpgf.fsf_-_@gnu.org> References: <6b1c1d98514b2547907a81a04c1241d9b865d6fa.camel@telenet.be> <20220120130849.292178-1-maximedevos@telenet.be> <87lez7zpgf.fsf_-_@gnu.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-t1ikULqiam0IUqcycun8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1642877735; bh=vTNFJEHcNWUdpQTRkWdMxXbiaWBpm00AO8E6Hi/Qj5M=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=NGIIWV/rvRIamQzOf7BnQbPwgyeBSfrxL4oOEjU1jsmTM8/cnNyJPTYfWXYDnzORX bnA6DEo7ia9mQddDrthShbERrJakz4QHmUvLFkhtr10uAvdwKawKXpKQx5GnmcjeQ+ HiJTAjR/AtR9fFsl958E6VNksxnDqaeqBpzMhNzy7fOAKEBAE9oNgEKSAftOBD9XpJ 9S58vBnQgK+Ge9gIAw5BJ45MW46l3ZCTPy80wqHJqeWDmXaxcVRzaJJ0L6+6nmbmxz Yib8K5PpoTEfVLKyzUlL3bOFRnQxhFNTKL+pNKeVFgiPPBm4AO46tPdqyTx86GtSrI NrCnxUUO1h1Qg== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1642878230; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=vTNFJEHcNWUdpQTRkWdMxXbiaWBpm00AO8E6Hi/Qj5M=; b=gFyCqis0bbzbWsKjx6dA8YB8GF+bXLbbwzWxq7U92/tQN2zfmeqRgYX3fqo22Ff6HHl1WJ tzoI9RBO+4fmFEn1GBYbh5W7Uv8DTQMBbbnM1HJodcT/xng7e2V2of3JtkNiJ+PfuvYC7K 4KgLOHuxsSQiyhLCpRZrOAZUyMF5G12WytWTswJX88fAHvODsKuv5VjVPmxl8XX5hrydn2 pH95Tis5C/5V2YB1sfpQTI517XxeL29luwQGhUyrvYN+JrIfUy3x7YjN5UDSfEPZ1BWMtY MgW+G6RpX0XU4pFDOBfv+pEYWXc7iYzc2S9aDD6Xr2V1dWaThN/s68yTuGZ4lw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1642878230; a=rsa-sha256; cv=none; b=QHcRYLboPkJJYEJbsBY3L7jBB03ihL4RmqFX5XGAYhxURgsvvmOovBqwXfpI6xQn1+znlQ tGIkhiWruq13HzRa4IYn9a9y/WRD/km36DXyncVAhmfHZkcRLXpnyOfyt0rxTE+IdEb8xB ZhZD6vK/YacNeyRsVQinfTuynfaBU0Q9ZnxnlLLG9K/yNiMXD8nCdYD6p7gRvhdrllgz9I Hoz9CBVSxj9Cnsf3lhPDlJ4NHDLOSMHP4i1m1gwVzMEoaP8ZlfC5KVU4uoUxJafP2+BV2w 9iTQTJ4o/eCTmoCcw7Txdupwt/eCyuNVwTCIBtmfbixwZJvheUaGjryW2Aqwsg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r22 header.b="NGIIWV/r"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.13 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r22 header.b="NGIIWV/r"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 02EEB2DBAD X-Spam-Score: -4.13 X-Migadu-Scanner: scn0.migadu.com X-TUID: nxalBtufLoeQ --=-t1ikULqiam0IUqcycun8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Ludovic Court=C3=A8s schreef op za 22-01-2022 om 17:48 [+0100]: > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (unless keep-lingering? > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; exit the ser= ver thread > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (system-async-m= ark (lambda () (throw 'quit)) server)) >=20 > When do we need =E2=80=98keep-lingering?=E2=80=99? In tests/challenge.scm (call-mismatch-test), due to how the store monad work, the thunk technically returns (*) before we are done with the querying the server. Perhaps this can be resolved with sufficient monadology, but I don't quite see how. (*) a monadic value. > So far, all uses of =E2=80=98with-http-server=E2=80=99 expected that the = server would > quit once the last response has been sent. AFAIK, they don't expect that the server quits. But they don't expect that the server does not quit either. Rather, they need the server to keep running as long as needed -- i.e., after the last request has been answered. The only reason that the server quits, is to perform a form of garbage collection, to avoid accumulating threads and server ports. There appear to be two criteria for deciding when to exit the server: (a) Exit when the thunk returns.=20 This is similar to 'call-with-port' and 'call-with-output-file' automatically closing the port when the procedure returns. There don't seem to be any drawbacks with this criterium. (b) Exit when there are no responses left. This is problematic when there is no list of reponses but rather some function mapping requests to responses without any limitations on how often a resource is requested, or when there are multiple resources available and the =E2=80=98client=E2=80=99 is a= llowed to query a proper subset ... E.g., the way the tests in tests/minetest.scm are written, the tests don't care in which order resources are accessed and whether a resource is accessed multiple time. Furthermore, the procedure for creating a testing model of ContentDB (call-with-packages) has no idea what parts of the model will be accessed. That is, the same model can be used for searches (either sorted by score or download), for requesting a description of a ContentDB =E2=80=98package=E2=80=99 and for requesting a specific rele= ase of a package. Furthermore, the space of resources is even infinite (due to the search API). In principle, that procedure could be modified to accept a few arguments specifying what things will be asked and with which parameters, but doing that and figuring out the arguments for each test would be rather tedious. Aside from verifying that no more traffic than strictly necessary happens (which would be a nice property but not really required), I don't see the point of verifying which resources exactly are queried. Furthermore, which resources precisely are queried and how often, seems more of an implementation detail to me. I would rather focus on the end result: verifying that the imported package definition is what is expected. Most tests in tests/minetest.scm are like that: they tell call-with-packages to create a ContentDB model with some data (using make-package-json etc.) ask (guix import minetest) to import some package from the model and compare the result with a prediction (make-package-sexp) (can this called integration testing?). These tests do not care how (guix import minetest) works -- they don't care about which resources are queried. Instead, they simply test that the end result (the package definition) is as predicted. While criterium (b) might suffice for various unit tests (e.g. in tests/lint.scm), it is rather impractical and limiting for the kind of tests that tests/minetest.scm does. OTOH, criterium (a) not only suffices for tests/lint.scm-style tests, but also for tests/minetest.scm-style tests. It seems to work everywhere, except for the single exception tests/challenge.scm.=20 > It would be nice if we could keep it that way. Compare (a) and (b), then I think it will be easy to infer what I would prefer =F0=9F=98=89. Greetings, Maxime. --=-t1ikULqiam0IUqcycun8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYexTIhccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7itTAQD1YOZJg2DKpV6zRoGJMI/YjFQ8 rnvcCyQmVDqdauZQvAEAxWD+Il+A8dyjdRcIgS5EQhFN0Xpkh85nwzpz3Tx8ZQc= =ozOG -----END PGP SIGNATURE----- --=-t1ikULqiam0IUqcycun8--