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 ms0.migadu.com with LMTPS id QBY1GTG7q2AuhAEAgWs5BA (envelope-from ) for ; Mon, 24 May 2021 16:41:53 +0200 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 8PooFDG7q2CddQAAbx9fmQ (envelope-from ) for ; Mon, 24 May 2021 14:41:53 +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 A46AB1D6BB for ; Mon, 24 May 2021 16:41:48 +0200 (CEST) Received: from localhost ([::1]:37638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llBm7-0006dv-5Q for larch@yhetil.org; Mon, 24 May 2021 10:41:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llBlP-0005wP-Hz for guix-patches@gnu.org; Mon, 24 May 2021 10:41:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:60210) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llBlP-0002KQ-8j for guix-patches@gnu.org; Mon, 24 May 2021 10:41:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1llBlP-00056s-2P for guix-patches@gnu.org; Mon, 24 May 2021 10:41:03 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#48463] gnu: Add j. Resent-From: Leo Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 24 May 2021 14:41:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48463 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: elaexuotee@wilsonb.com, x@wilsonb.com Cc: 48463@debbugs.gnu.org Received: via spool by 48463-submit@debbugs.gnu.org id=B48463.162186720719528 (code B ref 48463); Mon, 24 May 2021 14:41:03 +0000 Received: (at 48463) by debbugs.gnu.org; 24 May 2021 14:40:07 +0000 Received: from localhost ([127.0.0.1]:43518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llBkU-00054u-H1 for submit@debbugs.gnu.org; Mon, 24 May 2021 10:40:06 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:40905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llBkQ-00054V-UT for 48463@debbugs.gnu.org; Mon, 24 May 2021 10:40:05 -0400 Received: from nijino.local (91-114-247-246.adsl.highway.telekom.at [91.114.247.246]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Fpfxp64PRz3wbn; Mon, 24 May 2021 16:39:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1621867199; bh=ZeiL2Zl9xGRRJeo7WzBaEFm3I1WGK5U6Y1gMMJptCHY=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=u4oOVhXCtVh+C2jmOg4NeFysobrk0OD5tFOrmRFSpMYJnC/K4h8vHCkvpK9dRadDu rsGg+DRlXedUiCtxrolzmFsGmgYbbTAa/nWNBy/078kpZALsIPPycODniuSfbaSOMK guCQp4XZHut453jAK5moGTMKdQWMirBncbqqbZWM= Message-ID: <5d30160bd2a4592459cd407f99cbd3edadb1db1b.camel@student.tugraz.at> From: Leo Prikler Date: Mon, 24 May 2021 16:39:57 +0200 In-Reply-To: <293L8YPQS4CLB.3VK1B1A36XNAY@wilsonb.com> References: <3LOAUDT0FLL4U.2SOD925YP915T@wilsonb.com> <8b853d0585505ce29c9afc638b644fa34805e6c0.camel@student.tugraz.at> <293L8YPQS4CLB.3VK1B1A36XNAY@wilsonb.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1621867309; 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: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=ZeiL2Zl9xGRRJeo7WzBaEFm3I1WGK5U6Y1gMMJptCHY=; b=KotRoNb2vZdhHSPI731r0QMKWvrazFuqs9EmFEm2OPQEE5bBGapcPM4bUV2YECfh0I/GVY rucOgXwze4M7O7Rmjhzo7BL7qt+6k+/SH0XCEFhBn72fyXs79xl08is1eVYwa0urckd1nh 76orFawjuHjm0Zi9moRAyESe79dYR1rTXn6LB9ZxnJkw9o5cv/97Ujf2/SDXPuhKoiGWmZ 2BFusEmR/qLVpfXUH7v1/7NfHsE1+mygGjlR6KmdM9jBg68OI2WLS6wnMKo0H40QJfQBZo oG9/QSVr6QjiIYCIV/0FIQniw8m6u6zYHzh0lv1znYcsUPtdfxRH9HVt9MS5JQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1621867309; a=rsa-sha256; cv=none; b=OgpM2/pD9h4QUeSq10vaxfRYqyYvqAc0fTm8bLhtLX02nHbhprnEGEDqecdWa0yY8FstsF eSVyk5Ayk0ibKMMTl/TUh687X9bqrIrxBhZtSnTBma1Y0PoG3Uzd7TCVPtz2oEEUKkKBiw 33PgmzrgbkKuHki2Y7pNgj6J3yUCQOLmOrB2/8wnhvz3uZ107iStzC7SNxp/R7KUme0dRP EMt25gwSgA3GjZyL4oBxH+7MRagBVi8mAqC7tpT8UMH/Ug0dSJ1kZrk7BAlTu3UsGoUY+4 2iNELytKlkkkADh+D213rzvWtYgb1FmXRPFPFplWtWNTUovNTvsCWjhKPOdBlQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=u4oOVhXC; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.33 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=u4oOVhXC; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: A46AB1D6BB X-Spam-Score: -1.33 X-Migadu-Scanner: scn0.migadu.com X-TUID: 3rKX1Z90DeSs Hi, Am Montag, den 24.05.2021, 22:37 +0900 schrieb elaexuotee@wilsonb.com: > > Are fat binaries the accepted HPC way? I'm not up-to-date to this. > > I believe so? Don't quote me on that though. For this particular > package the > overhoad is just ~8MB, so I don't think it's much of an issue either > way. It > would probably be more of a hassle to split j into a package for each > variant. In that case it will probably be fine. > > Both sound like good ideas, although I'm a little less sure about > > the > > texlive one. Would a meta-package like gnome also be acceptable? > > A metapackage is certainly practical. The entire set of J addons > currently weighs in at a whopping 50MB. hehe. However, there are > about 125 addons in total, so it simply feels "more correct" to let > the user also choose just the addons they want, which I think would > require something like jsoftware-union. > > That said, either way, an "all batteries include" package would be > good to have, and since this is way easier than packaging the addons > separately, I'll definitely work on the metapackage first. stuff-union usually implies, that stuff can't just be put into a profile and expected to work (like texlive), whereas in other cases (e.g. the gnome metapackage) people can use its parts on their own provided that they have the right combination (which typically implies having icons etc.) > > As above, I'd prefer if it was one procedure and one package > > pointing to the latest j80x, assuming all of our added patches can > > also be applied to earlier versions. > > Yeah, that would definitely be ideal. > > Unfortunately, it's not so straigthforward. The the "major versions" > are the xxx part of jxxx-y, with large changes between each, e.g. > j902 introduced and non-compatible API change over j901. So, from a > pure J user perspective, having all jxxx versions available is ideal. > > However, each version seems to require its own set of build flags and > sometimes version-specific patches (like in the j901 case). We > probably don't want to push those settings out into user manifest > specs. > > On the other hand, there are already 10 versions from j801 to j903. That's less than the number of Rust versions we need just for bootstrap, but still a few too many in my opinion. Are all of those still used in production or would it be wiser to to put some of them into Guix-Past [1]? > > > +(define make-jlib > > > + (match-lambda > > > + (($ > > > + builder jversion revision hash type patches extra-inputs > > > extra-envars) > > Please try to use keyword arguments. > > Actually, maybe these "build configuration" records could solve the > above "too many versions" problem. We could offer only the latest J > (and J beta?) packages in the repo, but let (gnu packages jsoftware) > export a set of "default configurations" for old versions to be used > with the make-j procedure. I don't think there's much to be gained if we provide packages without packages. > Any particular reason to avoid using records though? Currently, its > letting us share configuration options between j902 and j903 that > don't work in j901. > Personally, I thought this felt like a nice declarative, scheme-y way > to go, but my Scheme is still very amateurish. Definitely wanting to > rectify any strange ideas I may have. Having keyword lists is also nice and declarative, but more importantly, it lets you call the function as a normal function without having to worry about constructing some record in a particular way. The configuration you're using doesn't have a specific setting? Just override it with your own. It's as simple as calling (append old- config extra-config). > > > + (properties `((jversion . ,jversion) > > > + (jrevision . ,revision) > > > + (jtype . ,type))) > > Are those used anywhere? Can jversion and jrevision not be parsed > > from (package-version jlib)? > > The make-j procedure uses them. We'd have to parse out these from > both the version string and package name with a what's essentially > the inverse of the jname procedure. I found it a lot more readable > and less hassle to just propagate this data directly. > > However, if there's a particular reason why using properties is > problematic, I'll try to see what I can do. I find this way of mistreating the version field very weird. You're not adding anything new by doing this and you're not making anything more secure (I'd argue, that it's less secure, because you could update the version and forget about the property or vice versa). First of all, do you even need all this info? `j' is an objectively bad name for a package. `j-beta' is not better in any way, it only avoids the user installing a potentially unstable "J" package. (Note, that we typically use "-next" for that, however). However, this info is meaningless when hardcoded into a procedure. You can just inherit from the package that's generated and override the name as needed. Next, should ijconsole not simply be a package like jlib (both properly prefixed with jsoftware- of course)? Then you can take whatever version bits you need from the package version itself. Regards, Leo [1] https://gitlab.inria.fr/guix-hpc/guix-past