From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id eBLOKZh1rGBXWgEAgWs5BA (envelope-from ) for ; Tue, 25 May 2021 05:57:12 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id EKxuJZh1rGBDHgAAbx9fmQ (envelope-from ) for ; Tue, 25 May 2021 03:57:12 +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 CDFC72A658 for ; Tue, 25 May 2021 05:57:11 +0200 (CEST) Received: from localhost ([::1]:37524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llOBq-0007dl-BX for larch@yhetil.org; Mon, 24 May 2021 23:57:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llOBi-0007ZQ-2B for guix-patches@gnu.org; Mon, 24 May 2021 23:57:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:32768) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llOBh-0006tB-QH for guix-patches@gnu.org; Mon, 24 May 2021 23:57:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1llOBh-0008C8-PV for guix-patches@gnu.org; Mon, 24 May 2021 23:57:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#48463] gnu: Add j. Resent-From: elaexuotee@wilsonb.com Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 25 May 2021 03:57:01 +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.162191497731447 (code B ref 48463); Tue, 25 May 2021 03:57:01 +0000 Received: (at 48463) by debbugs.gnu.org; 25 May 2021 03:56:17 +0000 Received: from localhost ([127.0.0.1]:44314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llOAy-0008B8-NE for submit@debbugs.gnu.org; Mon, 24 May 2021 23:56:17 -0400 Received: from m42-5.mailgun.net ([69.72.42.5]:43198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llOAv-0008Aq-7k for 48463@debbugs.gnu.org; Mon, 24 May 2021 23:56:16 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.wilsonb.com; q=dns/txt; s=krs; t=1621914973; h=Content-Transfer-Encoding: Content-Type: MIME-Version: Message-Id: In-Reply-To: References: From: Subject: Cc: To: Date: Sender; bh=y2vyrRi1hcS8zWjfTJqwwKaWSpRHQ1y7mTy3DuyUxks=; b=DfZ9V4J3mAL1Js55jZBqH9mzOKv/gUFIQHXhq6cmhPWjqWsqcQ1ak9B7Z8UvYaPdBvwe7AtY SbKoa5kkT5T70onfC5QE9VPj+CKsHwMRnFfihcb0w/e/fY/FznSMIfEOfrvndSjJn86AGVxm M4bvTkY+dpoyXfLiuem+QBAMsOMfaN841b9CWnqXimmWzwRmRMV+vSXsTgVHlVsCpiOpyH2s je7AW5UYVJ5EJ22iikX7ezlxHMzYxAiFplkzlj3GclWUpv/765J9SFse+mmKgCWZWgBJZz9B bCZMUFvCf3QULyzYCbX0I3gbjuNyc9ljc9tDWbsKDqNUeBIlpx7krw== 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-n07.prod.us-east-1.postgun.com with SMTP id 60ac75578dd30e785fc2c759 (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Tue, 25 May 2021 03:56:06 GMT Received: from localhost (ac134152.dynamic.ppp.asahi-net.or.jp [183.77.134.152]) by wilsonb.com (Postfix) with ESMTPSA id 5FF47A2F84; Tue, 25 May 2021 03:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wilsonb.com; s=201703; t=1621914964; bh=y2vyrRi1hcS8zWjfTJqwwKaWSpRHQ1y7mTy3DuyUxks=; h=Date:To:Cc:Subject:From:References:In-Reply-To:From; b=za04dQm0Hmos1YDZhBGqhU88eCcnrojU5U6P3qjm6O23HqPlt78k04GJJ8pL49XCK CUOE36zC6PX58mfYEYw6IkVbEmUyu3L7zKCGh9w+0z9+jzccA6CH52HEXL3mx1EmAp 5BzCm8Hn0oZpMJ6/777l4qZn/SjF3jPxOEv9Ido6ZNoLrAWlABYEIH4sp6agEQalQp rKIELgXoggR9fJq2tuvjiOtYSAatiF3QkYbjCSSi4ImttrPCroYUc26lsNyoX3q/Zb BSo9slibTBOTGOpenQxJ5IpjCR9hzzISS+GVJ8VtbW3gjfUdLr8gW/MUh9rJG2ELN8 0ECqF2zWmdQdFOiceSKetZssAeRXRKrA9Ul80FDrbFzPyY3q4vlq5lY3Qba0hcmibA r6odIeV7E0lhgSF6rQLxsmAeRWxVkJNky6/P2O7SiVINXShyOSgNQZQVIFdlTlv3kO CguqQTCV7nBCLv2sLKp9DuulvLXcNKkFaNZS1dWj1cbSnWSe5XK/DBdSABq4bwTMJi 91YfpnVTykCAs+/96kAoWsGXVOyrUERKN+RasHaYT6jk6b6hdbTIfyGdQARMmHE9Lh OhDPmosgqGwFiCAPa5S87UwmsaQNpVZH7e2MHR7TXhNqj64R4lo3C6bVVJDiSR4NI6 EXw+n5PvcNEGmBvktgUuznKA= Date: Tue, 25 May 2021 12:57:36 +0900 References: <3LOAUDT0FLL4U.2SOD925YP915T@wilsonb.com> <8b853d0585505ce29c9afc638b644fa34805e6c0.camel@student.tugraz.at> <293L8YPQS4CLB.3VK1B1A36XNAY@wilsonb.com> <5d30160bd2a4592459cd407f99cbd3edadb1db1b.camel@student.tugraz.at> In-Reply-To: <5d30160bd2a4592459cd407f99cbd3edadb1db1b.camel@student.tugraz.at> Message-Id: <27DCD25Y68ZWJ.2HRC4G65PWIA7@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=1621915032; 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=y2vyrRi1hcS8zWjfTJqwwKaWSpRHQ1y7mTy3DuyUxks=; b=WtRL2dYfxrGQk8wuTr2pHd5nsv341+sqd6vv4AsxrwFBNxBLrbOo8oEezmqixYwAzu63Fl e6XxfcPa6ctCXsjaJ5seBb0bLh40tIQFT9hG3mSG5j//pOamu+F3xg9mT8rgyA5gXWM1jp 7HJzOWm1Fqv/lvUZSp+ftRqrw48V+K88eNotQr10bixP6phQx+bNSi6fIoJMf3yTl72RVu px3jl5xE/gqVXIBW11eA0tpzkS3F8YIGUlJFQ9pYmRgFc5+PU4SODs2lv0I3wciEj2SHlm c4WK18Mm8a8NpensszYLcgnbrQjwvcUx9BJ9YeIbkz+QrvFQ0MD64A4gDLretw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1621915032; a=rsa-sha256; cv=none; b=SzX9rAZSt7jLsIhNNIasaEAvNhNXSEogPkHqN4i1BNYmCeiairXBxrM4HWLlsrsLZXGtD/ QZY25G4qrIhjc60rtECPN3lnPz/wOc/WUk6rT+qMeID5I4eq/JXzvwTbdwkZHZcvzpTtdg dnuWBVw7PJWTnLRAnByxqaTY/fVWMA/lcWnKODp6YNAYVgcxEAL8Vy5K1dePNgzIDq3P2J TbGefTy2VtmJg0WV0Me0mdSBymCn4HQJhEnymVOexA3kFL1HQaNuQplq7QbyQEJxsuylle xemzqlgA/Gv1V+0aeO6s8feVjChz6PE+NBJlXeV90FvEw5KHI74xfSDHZBWOgw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mg.wilsonb.com header.s=krs header.b=DfZ9V4J3; dkim=fail ("headers rsa verify failed") header.d=wilsonb.com header.s=201703 header.b=za04dQm0; 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: -2.93 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mg.wilsonb.com header.s=krs header.b=DfZ9V4J3; dkim=fail ("headers rsa verify failed") header.d=wilsonb.com header.s=201703 header.b=za04dQm0; 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: CDFC72A658 X-Spam-Score: -2.93 X-Migadu-Scanner: scn0.migadu.com X-TUID: L6LgMkAZVV6Q As always, thanks for the quick turnaround. Leo Prikler wrote: > 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.) Oh, okay. For some reason, I was just imagining "metapackage" to mean "all= batteries included", but your description makes a lot more sense. In this case, having addons without the J interpreter is pretty useless, so IIUC a jsoftware-union makes more sense than a metapackage in this case? Just to be clear, J looks for addons at a path burned into $store/...-jlib-$version/etc/j/profilex.ijs. Currently, that points to $HOME/.j/$jversion/addons, but we'll need to change that to a single store output path that contains the union of all desired addons, hence why I was thinking the *-union approach is needed. For now, instead of messing with the union, would it make sense to just cre= ate a (non-public?) jsoftware-addons package that contains all addons and point= jlib at those? > 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]? Oh cool. Guix Past might be a better solution! Thanks for sharing. I don't have any solid data, since "in production" J is mostly dominated by= the financial sector from what I hear, but just going by my impression from lur= king on the J mailing list, the j80x series (and even earlier non-free versions)= does still have a user base. Personally, I just want to make these older versions available to the community but am agnostic about the *how* so will defer to whatever you (an= d others) think is best. > 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.=20 > 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). Oh! (append old-config extra-config) is exactly the kind of thing I was try= ing to achieve; however, I'm not sure I quite grok the usage you are describing= =2E Something like this? (define* (proc #:key foo bar) ...) (define old-config '(#:foo 0)) (define extra-config '(#:bar 1)) (apply proc (append old-config extra-config)) > 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). I agree the version stuff is a bit crappy. It's something that got munged badly over time and deserves more thought. Here are the issues I'm trying = to solve: 1) The source URLs look like ../j-- or ../j-, where is either "beta" or "release", and depending on whether a patch-level exists; 2) The type string ("release" or "beta") is a build setting; and 3) ijconsole installs to something like ../bin/ijconsole-902, without including the patch-level, like ../bin/ijconsole-902-b. 4) Users should probably be able to easily install the latest J release a= s well as J beta concurrently without caring about exactly which version= these are. Those imply that , , and are indeed handled separate= ly, no matter concrete method utilized. My thinking was that 4 means we want a separate *-beta package, meaning tha= t the version field should probably just look like "-". Additionally, relating back to the above discussion about multiple versions= 5) It would be nice to be able to install the latest j901 without having= to know that this corresponds to patch level f, i.e. currently j@901-f. > 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 use= r > installing a potentially unstable "J" package. =20 Yeah, "j" is pretty short but it does mirror "r". I'm agnostic about packa= ge name, though. Suggestions welcome. > (Note, that we typically use "-next" for that, however). Thanks for pointing out this convention. > However, this info is meaningless when hardcoded into a procedure. You c= an > just inherit from the package that's generated and override the name as > needed. I see what you mean in a general sense but not quite how to apply it in thi= s case. I am all ears if you have a simpler, cleaner solution that addresses = the constraints listed above! > Next, should ijconsole not simply be a package like jlib (both properly > prefixed with jsoftware- of course)? This is effectively what make-j does, no? ijconsole needs to know the path = to jlib, so make-j points it at the correct one and wraps everything up into a= package. Anyway, thanks again for taking a look!