From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id aIXNF/ezyV9HcQAA0tVLHw (envelope-from ) for ; Fri, 04 Dec 2020 03:58:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KAB5E/ezyV/eQgAAbx9fmQ (envelope-from ) for ; Fri, 04 Dec 2020 03:58:47 +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 261D794021E for ; Fri, 4 Dec 2020 03:58:44 +0000 (UTC) Received: from localhost ([::1]:48222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kl2F0-00089x-U8 for larch@yhetil.org; Thu, 03 Dec 2020 22:58:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kl2Es-00089b-5r for guix-devel@gnu.org; Thu, 03 Dec 2020 22:58:34 -0500 Received: from knopi.disroot.org ([178.21.23.139]:44268) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kl2Ep-00082i-JK for guix-devel@gnu.org; Thu, 03 Dec 2020 22:58:33 -0500 Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 9A2A45334A; Fri, 4 Dec 2020 04:58:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9faJ0dvzWWxt; Fri, 4 Dec 2020 04:58:28 +0100 (CET) Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1607054308; bh=ZbTuXglbIe+34MSujCGT5Vi7S5EN0bLyVBujttSoSDs=; h=Date:From:Subject:To:Cc:In-Reply-To:References; b=ER+P2NDln74+GdhCoS5YW7twa/vucOgy4SgT/GCk4TBe4bSBSsh05ZJnDgSnF7MGX ndd0lbiGqH/SMG7rbEDzZHYNQRvMdXwhrcJXGUEnFF7eMX/D3OHu84HwEsA3z+8cQZ vaLExx4jxIuL7hTaz14Y3/uAOH/JLQFsVbVYL1AB/cfMp2cIM0/tAbS7zp5i7arUkC WOSoCvkMNEB0PFb8K4Tn1sACXco5I5xld/bD03TIm4uxsto2vb9yS3be6/YG13NOZT oQtl4JhrQpHP6gw72rE2yetwpa+WTVaCwZ1cmTC5f71sqIuLTEi7fL0H6ECtruQkzj E0y46LdaSo9ng== Date: Fri, 04 Dec 2020 03:58:27 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Raghav Gururajan" Message-ID: Subject: Re: Questionable "cosmetic changes" commits To: "Ryan Prior" , "Mark H Weaver" , "Danny Milosavljevic" Cc: "Development of GNU Guix and the GNU System distribution" In-Reply-To: References: Received-SPF: pass client-ip=178.21.23.139; envelope-from=raghavgururajan@disroot.org; helo=knopi.disroot.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, 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: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.49 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=disroot.org header.s=mail header.b=ER+P2NDl; dmarc=pass (policy=quarantine) header.from=disroot.org; 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: 261D794021E X-Spam-Score: -2.49 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: INu6D1pPyP/P Hi Ryan!=0A=0A>> I can tell you that those cosmetic changes I made were 1= 00% irrational, useless and noisy.=0A> =0A> That's certainly a way to fra= me it, but I'd like to hold some space for the idea that the things we=0A= > neuroatypical people do to manage and satisfy our own unusual perspecti= ves are not irrational or=0A> useless if they make sense to us and serve = a purpose for us.=0A=0A+1=0A=0AI meant to say that, the actions were irra= tional by itself. But when contrasted with right reasons, we can see why = sometimes an irrational act can be a rational act, when it benefits the a= gent's overall outcome.=0A=0A>> Due to [clinical conditions], if the pack= ages I am editing is not it in a specific way, I am unable=0A>> to focus = properly. That too, if I am working on multiple package definitions and i= f each pack-defs=0A>> are arranged in different way, it is very very hard= for me.=0A> =0A> That is an interesting use-case I hadn't considered, bu= t a valid one, and it gives me ideas. I'm=0A> going to experiment with so= me tools to make this feasible.=0A=0AThanks Ryan!=0A=0AYeah, my brain lat= erally connects fields of different package definitions. Like a spread-sh= eet, where each columns are different package definitions and each row is= a fields of a package's definition.=0A=0AFor example, if column 1 is gli= b and column 2 is gtk+, my brain spots pattern or errors when [arguments]= field of both the packages are in the same row. Let's say [arguments] fi= eld of glib pack-def (column) is in 4th place (row); and; if the 4th plac= e (row) of gtk+ pack-def (column) is [propagated-inputs]; my brain goes h= aywire. So I first do the cosmetic change of rearranging the fields of gt= k+ pack-def to match with pack-def of gtk+. This is just one example.=0A= =0A> Consider the tooling for Unison[1] which reduces code churn in a num= ber of unique ways.[2] It can=0A> store programs as abstract syntax trees= rather than plain text files, and it's content-addressed,=0A> referring = to functions by their hashes rather than their fixed names. As a programm= er that gives=0A> you the freedom to choose names and language syntax tha= t suit you without imposing on others to=0A> follow suit.=0A=0AThat's ver= y interesting. I'll have a look.=0A=0A> Due to the functional paradigm an= d technical structure of Guix, I think we can build some of the=0A> same = capabilities in our tooling. Like Unison functions, our package definitio= ns are reduced to a=0A> declarative content-addressed form, from which a = textual definition could be generated again using=0A> a reverse process. = By such a process, you & I could edit package definitions in whatever tex= tual=0A> form suits us individually without having to agree on anything, = not even the names of symbols. Then=0A> we can use a tool to automaticall= y canonicalize our code into the form most widely acceptable to=0A> the c= ommunity when it's time to submit a patch.=0A=0A+1=0A=0A> Taking this ide= a to its logical conclusion & building on Guile's multi-language-syntax p= aradigm, I=0A> can picture using a futuristic tool to edit package defini= tions in Emacs lisp or JavaScript, again=0A> without requiring that anybo= dy upstream adopt those languages or even recognize that I'm using=0A> th= em.=0A> =0A> I'll see what I can hack together for a na=C3=AFve implement= ation of this concept and present it for=0A> review.=0A=0AThank you Ryan!= =0A=0A>> Moving forward, I will try hard not to do this. But can I ask yo= u all to allow these cosmetic=0A>> commits for my existing projects (i.e.= commits from wip-desktop and pidgin patch-set) please?=0A> =0A> It doesn= 't bug me, but I know it does bug other people and imagine we want to avo= id creating=0A> unnecessary review work for people who follow the commit = stream.=0A=0AI see.=0A=0A>> I understand that these commits were a burden= to everyone and my sincere apologies for that.=0A> =0A> I appreciate the= grace and consideration you brought to your response & all your contribu= tions to=0A> Guix!=0A=0A:-)=0A=0A> [1] https://www.unisonweb.org=0A> [2] = https://www.unisonweb.org/2020/04/10/reducing-churn/#definitions-getting-= renamed-or-moved=0A=0ARegards,=0ARG.