From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id eDeLBqXbeWCpSgAAgWs5BA (envelope-from ) for ; Fri, 16 Apr 2021 20:47:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 6NP7AaXbeWA3IwAA1q6Kng (envelope-from ) for ; Fri, 16 Apr 2021 18:47:01 +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 9A4101DD9B for ; Fri, 16 Apr 2021 20:47:00 +0200 (CEST) Received: from localhost ([::1]:52278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXTUZ-0007cG-OP for larch@yhetil.org; Fri, 16 Apr 2021 14:46:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47254) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXTU5-0007b3-2z for guix-devel@gnu.org; Fri, 16 Apr 2021 14:46:30 -0400 Received: from mout02.posteo.de ([185.67.36.66]:48803) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXTTz-0004R9-Us for guix-devel@gnu.org; Fri, 16 Apr 2021 14:46:28 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id E108E2400FD for ; Fri, 16 Apr 2021 20:46:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1618598779; bh=K/6WAv1PnwwFG3qy0LP0AXbOhrXjYhxnZKc+HEmBQgM=; h=Date:From:To:Cc:Subject:From; b=H8kG1u4JQdOgEFl9WbPql00SiXmW7C4fdzynT81QTz0OA2c27uWvNY906LMJBnESb aQRbTTtk1+8MugEGBnDZXqXAeB1z+EWRwdOjeNBYsYmiJ7Pc/ZgTwKlgzuSxyiWac+ Wz9y2OEFbBbWeY8qbRiBNyR1U/JIYhQLzVq5qEqZYb/XIXV22/ovinXi+hn8mJEUyD LU45GN2k7uo1yTKjUh1irJUuxrsZUBoi6vljzQdwoOO7wfU6e0Gle9tfNQky/QsAuw SZJ1WwgxduFLT0h7yiE4bUJRDqlEk08dJJFEI4U2NleQKyTri3cIPbSME25dJggRvY 2iuzsXKwmVmtg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FMQCT2CR4z6tmK; Fri, 16 Apr 2021 20:46:12 +0200 (CEST) Date: Fri, 16 Apr 2021 18:46:00 +0000 From: Luciana Lima Brito To: Christopher Baines Subject: Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page Message-ID: <20210416154600.62c4a97d@lubrito> In-Reply-To: <87czuuxmdd.fsf@cbaines.net> References: <20210414164859.7acc631f@lubrito> <87wnt4x7e3.fsf@cbaines.net> <20210415130947.7387a546@lubrito> <87o8efxhil.fsf@cbaines.net> <20210416120740.05a819ca@lubrito> <87czuuxmdd.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=185.67.36.66; envelope-from=lubrito@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=1618598820; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=47fRT/YHzXgV9E8o6ChRQd+wCZUYShe1qtbC+b74+lY=; b=oNg4EvBZrKxuAChrBhIbVfLlz4KtM6Zl7p8L5Wa37hLJkyMO7EgYGo5U+Ztcfk4qhxYU8H 32VUDFIm+pVBUw9T/eoCagn2uXsASYmy3UJvowdOI2vPtEcsYpHBMnVs2CPx4bbl7JwOZv 4gMYK6ghgYitn+KKujQSk7/WiZee3S1b9GGOoixBQZypxNBBMVOGTxfllW9GNW7ZV8p908 QQaBZYrlciT4ondDH/nutJIgbQ/jcpDk9Hfk0yU3s+fwRTHI+4ubAk+WVPYvIbf9u6eqWx ZLBLcGDwml67bDyedVRwqJQGZOP+iliaz/FkswY1Xx8D5JvUhX0EFblU4F6lJw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618598820; a=rsa-sha256; cv=none; b=G0tVcgY4c0hJFtESZ7XJn5uF/82P+C0qhQwgnyiHf0mQ5XVi+kga7KMvIkHm4rz0dL25ax prLMfj7b/ju0XnJjt+Ygz+R2O69MmSdyK7FbFrZgaIu9/tIqNXElYDZZ1YUONLX9pLsYgu BOJOhI3WjL5u/rjS95TwcFhau8iOxngvq6NArawcebwo7r8+fvbZLimaHsRRaIxwAn7pQg ZiGAWmaE2pZmihGy7RnUK3PKjFqQ6tSs5Y9xoEk+yqz2YxKlymvB1qpXO8AjF+OsI1f1zQ +d8t82yrtKz+LPTdNf1YExTcQBn0jvp6EQ7Y8n6mKRqxCGRXRKM8Twmm1JBq9A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=H8kG1u4J; 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: -2.64 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=H8kG1u4J; dmarc=pass (policy=none) header.from=posteo.net; 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: 9A4101DD9B X-Spam-Score: -2.64 X-Migadu-Scanner: scn0.migadu.com X-TUID: P0bgYX9F8Fjt On Fri, 16 Apr 2021 16:47:10 +0100 Christopher Baines wrote: Hi > From looking at the content of your commits, I think they should be > merged together. > > There's some information about that here for example: > > https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing Thanks, I'll look into it. > >> 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? > >> 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. -- Best Regards, Luciana Lima Brito MSc. in Computer Science