From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 8PqYK/njeWB4XQAAgWs5BA (envelope-from ) for ; Fri, 16 Apr 2021 21:22:33 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 8D/2JPnjeWC7XgAAB5/wlQ (envelope-from ) for ; Fri, 16 Apr 2021 19:22:33 +0000 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 19ED41F2C9 for ; Fri, 16 Apr 2021 21:22:33 +0200 (CEST) Received: from localhost ([::1]:48210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXU2y-0000T6-1a for larch@yhetil.org; Fri, 16 Apr 2021 15:22:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53808) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXTyW-0001lD-Ub for guix-devel@gnu.org; Fri, 16 Apr 2021 15:17:57 -0400 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]:55987) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXTyR-0005EE-Cb for guix-devel@gnu.org; Fri, 16 Apr 2021 15:17:56 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:8ac0:b4c7:f5c8:7caa]) by mira.cbaines.net (Postfix) with ESMTPSA id ACE6027BC6C; Fri, 16 Apr 2021 20:17:48 +0100 (BST) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id d5c66bd4; Fri, 16 Apr 2021 19:17:48 +0000 (UTC) References: <20210414164859.7acc631f@lubrito> <87wnt4x7e3.fsf@cbaines.net> <20210415130947.7387a546@lubrito> <87o8efxhil.fsf@cbaines.net> <20210416120740.05a819ca@lubrito> <87czuuxmdd.fsf@cbaines.net> <20210416154600.62c4a97d@lubrito> User-agent: mu4e 1.4.15; emacs 27.1 From: Christopher Baines To: Luciana Lima Brito Subject: Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page In-reply-to: <20210416154600.62c4a97d@lubrito> Date: Fri, 16 Apr 2021 20:17:45 +0100 Message-ID: <87a6pyxcme.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1618600953; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=E1mlTQCaP3iw0CoC9xm9yr0MHG52eUlr3dFfKZr/oX0=; b=TorxL/n/0I46JQ3Pi/fA7+POZhbvv/t/JhgBs2pqxp72aXYCpLuKagiA7g9Zxlj9Cxl0xi 7HjqkCFg08GquRN8lAzqPKqZW50198r/VJXdQJgSKlxXyuvxkQd6hUNDYnmJ19AvDVu7Ql aV2Jv1Fg3H73bIhbkr6rte8fSLET+FYllXUCxeb3WGGQJ9tbBMW16hNU/MlsjMdaK8oack xYYkhjrCffJl/2jb+1+/Cg4HRQ/HZWrGfrOQVrEbkXaZ6a5naNmuQiTPa+S0jSBvlikPS2 Y5JEc2L97Q6a9H5pYaSrpFrjngZRqeg9beRedy/DGDFngZX+bBNSoVTbF47Img== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618600953; a=rsa-sha256; cv=none; b=iWoG+qAfvWKye5t76sjhiUQDBdnW3qIR+7xZPz1wjR0hX9ORQgRUDIS32bobr5wncuiTMp qzGAtFmaDO4x9g4vS3PZCMoAy1jU96Y2xVTSm+t3ZQUd8tsRQefMNDEL5t4UtNIS0KeKvS ihj4C//uxRs5yebtluWcC/mTSZnmDVb68F12N3dP2elgqoBbXU+Pcd7s32y3/DlJO9Tn+W mwiFXDMoP0G3eNcBttMZniT1RKEfpjXa9pzDM6OA2daV2zWLe1N/J9UguIoi8BLDK1SdZn hkGAguM37cBS27+5blLPE+kAyB9Qt+uKRlNvTSOlvLTpwmlfNUU8+NyW0wgpXw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -4.54 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 19ED41F2C9 X-Spam-Score: -4.54 X-Migadu-Scanner: scn0.migadu.com X-TUID: 39RLCzr32Ifx --=-=-= Content-Type: text/plain Luciana Lima Brito writes: > On Fri, 16 Apr 2021 16:47:10 +0100 > Christopher Baines wrote: > >> >> On the get-derivation-data function, I wouldn't use the same >> >> function to process the inputs, outputs and sources. The data for >> >> each is different, so I would separate the code as well. >> > >> > I understand that, but the logic to map the values for these three >> > bindings is the same, wouldn't it generate redundancies implementing >> > the same logic separately? >> >> I'm unsure three bindings are you referring to, can you clairfy? > > The bindings I was talking about are "outputs", "inputs" and "sources", > the only difference between them are the number of elements each one > has, that is why I simply made a match clause for each one. If you think > it is better I can separate them. Also, do you think it would be clearer > if I move each one inside the json case branch? Ok, I think the data in the inputs, outputs and sources will be quite different, because they're different things, right? Looking at this page as an example [1], the inputs are each a derivation and a string saying which output of that derivation is being used as the input. The outputs have a number of bits of information, the name, path, hash algorithm, hash and whether it's recursive, and the sources are just a single string, the file. 1: https://data.guix.gnu.org/compare/derivation?base_derivation=/gnu/store/5s9mi0k3mk6cmakyckj2fcp4qb75rn79-debootstrap-1.0.123.drv&target_derivation=/gnu/store/vqhfs0dmfm4q0lr1w6sdhrbc2pa2jrar-debootstrap-1.0.123.drv If it's the same function being used to process the inputs, outputs and sources, then it's harder to quickly tell from the code what's going on, as you don't know which code inside get-derivation-data applies to the inputs, outputs or sources. Matching the code up directly with the data it should process will make this much more obvious. >> >> To avoid having to call a procedure three times, on the base, >> >> target and common items, I'd consider following the same pattern >> >> in the HTML generating code, map over a list of the lists, so >> >> something like: >> >> >> >> (map (lambda (name data) >> >> (cons name >> >> (match data >> >> ((name path hash-alg hash recursive) >> >> ...)))) >> >> '(base target common) >> >> (list (assq-ref outputs 'base) >> >> (assq-ref outputs 'target) >> >> (assq-ref outputs 'common))) >> >> >> >> Does that make sense? >> > >> > Actually I did it in a similar way before, but it resulted in a list >> > with all the values for base, target and common together, in which >> > I had to have another way to separate them and render on json, for >> > example, I tried appending "base", "target" or "common" names to >> > each list (similar to your function?), but them I had to convert >> > this list to a vector. >> >> Getting a list with all of the values in individually was possibly due >> to using append-map rather than map. >> >> > Calling the function for each separately gave me a cleaner >> > output. Also, I think that sometimes you might have more than one >> > output for base, target like it does for common, and I fail to see >> > how your example function addresses this. In short, I couldn't see >> > the benefit of this over calling the function three times. Is it for >> > organizational purpose or am I simply wrong? This time I'm just not >> > understanding. >> >> It's an organisational thing, code is generally more readable if the >> scope for variables is tight and there's less indirection. Defining a >> procedure is one form of indirection. It's often really helpful, but I >> think it's unnecessary here. >> >> You're right though about the above example not handling data being a >> list, I think that's a fixable problem though, rather than the (match >> data ...) bit, I'd suggest using map with match-lambda, probably >> wrapped with list->vector if you want a vector which will be >> outputted as a JSON array. >> >> Does that make sense? > > I still don't quite get it. The function I had before was like this > (using inputs as example): > > (append-map > (lambda (label items) > (map > (match-lambda > ((derivation output) > (...)) > (or items '())))) > (list "base" "target" "common") > (list (assq-ref inputs 'base) > (assq-ref inputs 'target) > (assq-ref inputs 'common))) > > Which indeed I made based on the html code. However this outputs me > something like: > > (("base" derivation output) > ("target" derivation output) > ("common" derivation output) > ...) > > where "..." are lots of different ("common" derivation output) lists. > > The only way I could think of showing this, was transforming it to a > vector, which gives us the indexes from 0, and inside each one we > would have the label showing where it came from. Is that the way you > think it is better? (is this what your proposed function should > accomplish?) > > I think the above output produces a bit less clean json, > that is why I changed this function to the last one I sent you, so I > don't need to pass any labels, because if I pass the base, target, and > common lists separately the output is already correct and we don't need > any vectors. So, append-map expects the procedure it runs on the elements in the lists its provided to return a list. Whereas map would give you a list of lists in this case, append-map effectively runs append on that list of lists, so you end up with a list. While a flatter list is what you want when building an HTML table, I think you were looking to get a JSON object separating the common, base and target elements, right? If so, then map, rather than append-map should be more useful to you here. Since above you're passing in two lists of three things, if the procedure passed to map returns a pair with a string in the first position, you'll end up producing the scheme version of a JSON object (an alist). --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmB54tlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XdyqA/+PdYhJSFqNbIBK/5qGE8zdwsEt8Duo9x5 YPvs8iLJ8f/amMBY34knBPjfWYu2BUsKUNhtrq6JcLdBTk4DSFen/7SfqoYFFnbn duYS6ZjGJ1X72Y1iw6/11tAEkqpbBDNV5cfK2JALT31+/o1WI/vyFyVZRdlNVfod 3X3ia5DBvdjYVX6+9qJTj2BoiayOGUyBxcOuYnwtwk7BxkUffSLUBi2pWpUJGfHo 1hVzGl5b7P0NQ/q/rqL1YluWytAmazfOTgXS//IhE2u2W0ok+OuCyWzw5F8LZtBo l69IiEK299tb9hItjiArVdfXW+ersC6GPlpjeWQw650HHu5T2EsKlMPdjsQkAjCt J3bt/OhQkhwnLgTEjj5WPw8TNtxQ7eRsgZ+KAHNByBPV3gcICIUtTc9pFncVvQ4l NOm07zh2ijmHuxGOYvNVePvf+9PgvxitaSSdcPHxENpS7Z+MclM1+o6xJyXThnw1 TNXBps9W/KDczojfR3uwwW1fiQvM1fzv+zKPAamZvlFupBagHIentWcvJ+2lfgC3 ZfPKCNP0bX3trhq+1tOrTID1SRPVuhHBtzAtVfhqKkbNVuUeW3yQfv3CCHp9OxT2 OE258ARCW8TFHxyUFPxSp1GoMWmgSafoK+th0hpWjKaI0gsJoxB+n6Rw9LvCC+zU SrMqAomMpos= =+3Ey -----END PGP SIGNATURE----- --=-=-=--