From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id GNX6NX2sq2ByZQEAgWs5BA (envelope-from ) for ; Mon, 24 May 2021 15:39:09 +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 wKatMX2sq2BpDgAAB5/wlQ (envelope-from ) for ; Mon, 24 May 2021 13:39:09 +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 661271D0D4 for ; Mon, 24 May 2021 15:39:09 +0200 (CEST) Received: from localhost ([::1]:53434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llAnU-0004Xl-FG for larch@yhetil.org; Mon, 24 May 2021 09:39:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llAnO-0004XX-EF for guix-patches@gnu.org; Mon, 24 May 2021 09:39:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:59272) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llAnO-0004od-6o for guix-patches@gnu.org; Mon, 24 May 2021 09:39:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1llAnO-0003N9-5Q for guix-patches@gnu.org; Mon, 24 May 2021 09:39:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#48463] gnu: Add j. Resent-From: elaexuotee@wilsonb.com, x@wilsonb.com Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 24 May 2021 13:39:02 +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: Leo Prikler Cc: 48463@debbugs.gnu.org Received: via spool by 48463-submit@debbugs.gnu.org id=B48463.162186349712910 (code B ref 48463); Mon, 24 May 2021 13:39:02 +0000 Received: (at 48463) by debbugs.gnu.org; 24 May 2021 13:38:17 +0000 Received: from localhost ([127.0.0.1]:42585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llAme-0003MA-QD for submit@debbugs.gnu.org; Mon, 24 May 2021 09:38:17 -0400 Received: from m42-5.mailgun.net ([69.72.42.5]:10908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llAmZ-0003Lt-No for 48463@debbugs.gnu.org; Mon, 24 May 2021 09:38:15 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.wilsonb.com; q=dns/txt; s=krs; t=1621863494; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-Id: In-Reply-To: References: From: Subject: Cc: To: Date: Sender; bh=PzXlBkfxE7SBTd6LUovlC4UTxaWh4/CGNB8gMT3YtSs=; b=sQErGkZZJrn/lE+nUEe8sKjR60YcrWkWDiPqTiY5uN7f3QUHdRb1YErWP1bj8moNYGh+U7+h cRTs316u2owvOl/H+0OhxmvcJSkGFKG0GThyBk3OqVcsWO8jigMHPxc4QzV7Rr9EYjHw5jfc iU7h78X1KcVvpShlS0GTf8Eqg74YuPnf70a3htLD/vRWsgmy42NmxiPuUtlDXD99tTO9NUR6 LmfK/6W4VZMOzhPrjx6UnooAhsK5YZM+x289bxuLXkaEo3gEXoNEe9t17QcTPWB4JPqNa7GG YZXhlkBoPYVO/tSJDV3/WLpQvttKSB7p6obsxf9YqLuwq7krYNg3aA== X-Mailgun-Sending-Ip: 69.72.42.5 X-Mailgun-Sid: WyJjZGI4NCIsICI0ODQ2M0BkZWJidWdzLmdudS5vcmciLCAiMDg1NDdhIl0= Received: from wilsonb.com (wilsonb.com [104.199.203.42]) by smtp-out-n03.prod.us-west-2.postgun.com with SMTP id 60abac2a67d156359ac485d4 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Mon, 24 May 2021 13:37:46 GMT Received: from localhost (ac134152.dynamic.ppp.asahi-net.or.jp [183.77.134.152]) by wilsonb.com (Postfix) with ESMTPSA id B5B4CA2FB1; Mon, 24 May 2021 13:37:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wilsonb.com; s=201703; t=1621863464; bh=PzXlBkfxE7SBTd6LUovlC4UTxaWh4/CGNB8gMT3YtSs=; h=Date:To:Cc:Subject:From:References:In-Reply-To:From; b=mLT+qxXK20D8CnIlSbhbTVCDoktFyfaZBS2dmEbPduOVvo3aD3E0FkwnjcULw4xtX R9i+maj22INcmejlQXxxyEdIWPfOBC12w8QRFRiE12wFS8KvKSm61WLs2DNwGBHfFm 5vR1IDXTWtUm4JKr9mhD2a7TS8EuEz1NDISxSnG58VP/KrkW3rjzt2S+hUiDT51kfx SSfMJg6JV/4kLYNdYRWFdt9wLAQYsfbGeTlm/iUXiVVVc9aQWikqY1TgfBddH6ENsr wokDzvPdZ53U03wnUzBvJqd44LIpzUeb0TdSF+1G6MbtzYbIQMsTXAoRmCk2OYizz7 926Z2/JkFBCcp6KgcavKBAQMl5acbuAkuoe1IJagayXe3p4qAZGXjtg6vW7Xlc6bqF QTdNGsaIe7k0P77VoxrK+GqMvefXGCQj9acbtFlm11A6bvkmsbda2bpdF+d4DDHKRQ lJE2saaFxJK5ny4CN9glEKl9wr1hJn8r6feKYkPsEbRENeHDPCwa7ninnqyzOjGV4L mJVAfDK8+H+J7vyAayRBaS7cvd5mci3+LdgVfM+UZ24HsLv1cbKG+57+WYtSEJhVUy GQkFrnA7YCrn3Dxuxk95qC2O8oYfTkG3U5mwbfSGGOchAyxYznibp9+1R/MwfJkJlr rGlJl6jTuXVR4OQmmymqcwsg= Date: Mon, 24 May 2021 22:37:41 +0900 References: <3LOAUDT0FLL4U.2SOD925YP915T@wilsonb.com> <8b853d0585505ce29c9afc638b644fa34805e6c0.camel@student.tugraz.at> In-Reply-To: <8b853d0585505ce29c9afc638b644fa34805e6c0.camel@student.tugraz.at> Message-Id: <293L8YPQS4CLB.3VK1B1A36XNAY@wilsonb.com> User-Agent: mblaze/1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" Reply-to: elaexuotee@wilsonb.com X-ACL-Warn: , elaexuotee--- via Guix-patches From: elaexuotee--- via Guix-patches via X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1621863549; h=from:from:sender:sender:reply-to: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=PzXlBkfxE7SBTd6LUovlC4UTxaWh4/CGNB8gMT3YtSs=; b=pOZK+9Nb41xDvzU3SYxLxhf4uE8aZPfRYwZEM9rJWTNdQjlGqM2SCbJTO5bpuAYki/kbaN xLq/RtQcDYFFw2z6dllvRB9LSeZMEfLWb0wjEvBuijByn3jc+t7RRFChLPF0mwtB5EfqRc DUqchq2VrrECXOyCvnp0uvqa/EAs1zvd84AxMAtK+QgiJCjw6FwmJmX6WkIsZnr309wGtb SFE2WTQ8bf5tvMWmqBOfee02Jfj3KFoShARHNhcKm/upXDA1d6JHXDhSsqv7SmpIqaJfIg 4O2tML16HKElDY5eoRZ3g8QLqV/chEVYGS+r+2ByUpBTSjYMIB81VvP1eMbrAw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1621863549; a=rsa-sha256; cv=none; b=LIgb2gc0/PMgcFv8WrCyC3esDiJ+NrIwEbgchw7t3snOLTpQersr3oG238A8O28Qg1sHLn SNyD91pZOCBCqKeLLrr9TooaoSsbQB2c1yAabVZOzfass0F5dM2/MKn9leqFwzKvDZVBFT ZikiWuISWUp4iGFkCjH4zV7zB7X+RYmw+tusrmjWCE3llIw2Qnt6OkbU+gEJFU8sADR3Cc bhe/a8HOC22Kn+3Bixx4gfxGChvbDbpe6m4juqJIEv1T7jy8Z7wcnwjccLyw+xL9P98w4P lUB4VyaNpGoKoz6r/baRdTgiczqTnWfKkxonhDnzAYfQez3Qk3uyuTw/IjN5SA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mg.wilsonb.com header.s=krs header.b=sQErGkZZ; dkim=fail ("headers rsa verify failed") header.d=wilsonb.com header.s=201703 header.b=mLT+qxXK; dmarc=pass (policy=none) header.from=gnu.org; 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.43 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mg.wilsonb.com header.s=krs header.b=sQErGkZZ; dkim=fail ("headers rsa verify failed") header.d=wilsonb.com header.s=201703 header.b=mLT+qxXK; dmarc=pass (policy=none) header.from=gnu.org; 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: 661271D0D4 X-Spam-Score: -1.43 X-Migadu-Scanner: scn1.migadu.com X-TUID: Ooi6/eusOWGK Thanks for taking a look! Leo Prikler wrote: > That should be fine, we provide multiple versions for other packages > where applicable as well. Do note, that we should try to keep the > number limited, though. You may perhaps want to export make-jlib, so > that the user can build their own. Cool. I like the idea of exporting the build procedures. > 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 th= e overhoad is just ~8MB, so I don't think it's much of an issue either way. I= t would probably be more of a hassle to split j into a package for each varia= nt. > 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 t= he addons they want, which I think would require something like jsoftware-unio= n. 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. > 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 th= e xxx part of jxxx-y, with large changes between each, e.g. j902 introduced a= nd non-compatible API change over j901. So, from a pure J user perspective, ha= ving all jxxx versions available is ideal. However, each version seems to require its own set of build flags and somet= imes 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. > > +(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 "def= ault configurations" for old versions to be used with the make-j procedure. 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. > > + (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 th= e 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.