From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id YIXpF9cxuGVDPgEAqHPOHw:P1 (envelope-from ) for ; Tue, 30 Jan 2024 00:16:39 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id YIXpF9cxuGVDPgEAqHPOHw (envelope-from ) for ; Tue, 30 Jan 2024 00:16:39 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706570199; a=rsa-sha256; cv=none; b=F42mG7c4GMcl9ymJXfO0pglMdAON/mCfn5DpPwI2LQujOQYZ3GJwiByvGzK84DdaJXPcNw 3C5ZnPkta26fIqgsN7Mc0JBQr44VIHt13tZc7acoTp/WySXKeCoR2Mn+GyWjkdsvLv/jD5 onmpl1L9z0WWYBiaCRp+mnCo7FLtyCPCvMg6WYwoJPu+rrF2XeCxCcfORlhkt4QVi8aMnM h92FW2z5fkZCfWOB4Y/lE/gmrLMrK8Q7OMXwAPCoDBpWSCrMEFwnz1Sgjh+RWj/3ig2zbc Apf7sUqhnCQH7aCOwE/35n3bgzb0HTsogMs2BeSNCEwkAuyC8mJHdeP8GBcRow== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706570199; 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=5VUJsfQh3zdD5ehCtnE7kQPmFq7f9BT3HGmDsKz2foI=; b=BnVeWhW6Dt0PJ6xIc0nHpKTlv6T1Ds9ghOEhuUhEP1qzu3NyZMOUs0YzlSf3aEdsEWZS0J 3g3EiLQlKZl0Rlkyuprr3MzS6NbOPlnC7dA2X0Fs3kIm2GTM+UhScwq0FZIWdjCSgM3d87 6oxc9EmZ7czwbPI1DPHjg5j5Xa+J7A3YoA1md2c0XiPzF10yd7oYzGZH8M6cZw8YKwdg4c H3MOiUK1BlaPfM1OVCjroYqla1APUALlqO/1XNUrU+iOMW7/UzepO6v4m996sh53yTA7y8 GD5WJTe0K1m7CHSUswPor6e3FY5J8bL0xuc10pxUAJ21c1kO3eme5rCjeKbfew== 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 3E3308FBA for ; Tue, 30 Jan 2024 00:16:39 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUarB-00012X-Lz; Mon, 29 Jan 2024 18:16:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUar8-00012A-Oj for guix-devel@gnu.org; Mon, 29 Jan 2024 18:15:59 -0500 Received: from vmi993448.contaboserver.net ([194.163.141.236] helo=mutix.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUar6-0002RV-Dg for guix-devel@gnu.org; Mon, 29 Jan 2024 18:15:58 -0500 Received: from [192.168.1.169] (host86-132-246-87.range86-132.btcentralplus.com [86.132.246.87]) (Authenticated sender: cdo) by mutix.org (Postfix) with ESMTPSA id 9A545A635DC; Tue, 30 Jan 2024 00:15:52 +0100 (CET) Content-Type: multipart/alternative; boundary="------------DMrDBkffCfJq8YCAxTlpE86e" Message-ID: Date: Mon, 29 Jan 2024 23:15:51 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 From: Christina O'Donnell Subject: Re: Golang mudules to follow common grouping To: Sharlatan Hellseher Cc: guix-devel@gnu.org References: <87ede1htac.fsf@gmail.com> Content-Language: en-US In-Reply-To: <87ede1htac.fsf@gmail.com> Received-SPF: pass client-ip=194.163.141.236; envelope-from=cdo@mutix.org; helo=mutix.org X-Spam_score_int: -61 X-Spam_score: -6.2 X-Spam_bar: ------ X-Spam_report: (-6.2 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-4.241, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx10.migadu.com X-Spam-Score: -6.66 X-Migadu-Queue-Id: 3E3308FBA X-Migadu-Spam-Score: -6.66 X-TUID: 27OjZofSjBXT This is a multi-part message in MIME format. --------------DMrDBkffCfJq8YCAxTlpE86e Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Oleg, > I've pushed the split III to master. Fantastic work! > I think you may help! The identification of the group is still human > decision making process and I'm not sure it may be automated in any point. I can certainly help with this then. I'll have some free time on Friday and I can coordinate with you then. > Each of the module header contains a short annotation which packages it > expects to have, feel free to improve it to make it even more clear > for others. > > - golang-check > - golang-web > - golang-crypto > > TBA: > - golang-compression :: Anything related to that subject, see > python-compression, java-compression, perl-compression. > > - golang-build or golang-extension :: Any low level golang add-ons not > included in core distribution see or > any 0 dependencies high reference modules. > > - golang-xyz :: As any other *-xyz module would absorb anything else >   left behind. This all sounds sensible to me. >> 1. Put a magic comment above each package that you would like to move. >> 2. Run a simple script that makes a note of all of these into a >> to-move-list. >> 3. Then stash the change with the comments you made (in case you need >> to change things) >> 4. Run another script that takes the package list and performs the >> move in one's repository. >> 5. Sort out the use-package declarations manually and run tests. >> 6. When satisfied, stash the change and keep just the use-package >> changes. >> 7. Run a final script that loops through all the packages and commits >> each one in turn. >> 8. Rebase to suit. > > We may extend handy script accelerating committing process, see > "etc/committer.scm" Okay, cool, I'll have a look at it on Friday. >> - I'm not a scheme programmer, but I did use Haskell at university so >> I'm familiar with thinking in a functional style. > Me too =), but you still can help by just providing some review to > existing code base and available packages in golagn.scm and trying to > identify close group for each of them. > >> I'm also imagining some the possibility of having a script that can >> remove redundant #:use-module's in the future, though I don't know if >> we care about a few unneeded modules being included. > The clean up task may be organasied after sort process is completed, having > not required #:use-module does not hurt too much but for keeping modules > tidy and fast to load it definitely beneficial. This makes sense. Not a priority at present but a nice-to Looking forward to hacking golang.scm to pieces! Kind regards,  - Christina --------------DMrDBkffCfJq8YCAxTlpE86e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
Hi Oleg,

> I've pushed the split III to master.

Fantastic work!

> I think you may help! The identification of the group is still human
> decision making process and I'm not sure it may be automated in any point.

I can certainly help with this then. I'll have some free time on Friday and
I can coordinate with you then.
> Each of the module header contains a short annotation which packages it
> expects to have, feel free to improve it to make it even more clear
> for others.
>
> - golang-check
> - golang-web
> - golang-crypto
>
> TBA:
> - golang-compression :: Anything related to that subject, see
>   python-compression, java-compression, perl-compression.
>
> - golang-build or golang-extension :: Any low level golang add-ons not
> included in core distribution see <https://pkg.go.dev/golang.org/x> or
> any 0 dependencies high reference modules.
>
> - golang-xyz :: As any other *-xyz module would absorb anything else
>   left behind.

This all sounds sensible to me.

>> 1. Put a magic comment above each package that you would like to move.
>> 2. Run a simple script that makes a note of all of these into a
>> to-move-list.
>> 3. Then stash the change with the comments you made (in case you need
>> to change things)
>> 4. Run another script that takes the package list and performs the
>> move in one's repository.
>> 5. Sort out the use-package declarations manually and run tests.
>> 6. When satisfied, stash the change and keep just the use-package
>> changes.
>> 7. Run a final script that loops through all the packages and commits
>> each one in turn.
>> 8. Rebase to suit.
>
> We may extend handy script accelerating committing process, see
> "etc/committer.scm"

Okay, cool, I'll have a look at it on Friday.
>> - I'm not a scheme programmer, but I did use Haskell at university so
>> I'm familiar with thinking in a functional style.
> Me too =), but you still can help by just providing some review to
> existing code base and available packages in golagn.scm and trying to
> identify close group for each of them.
>
>> I'm also imagining some the possibility of having a script that can
>> remove redundant #:use-module's in the future, though I don't know if
>> we care about a few unneeded modules being included.
> The clean up task may be organasied after sort process is completed, having
> not required #:use-module does not hurt too much but for keeping modules
> tidy and fast to load it definitely beneficial.

This makes sense. Not a priority at present but a nice-to

Looking forward to hacking golang.scm to pieces!

Kind regards,
 - Christina


 --------------DMrDBkffCfJq8YCAxTlpE86e--