From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id YLAhChboNGGGTgEAgWs5BA (envelope-from ) for ; Sun, 05 Sep 2021 17:53:58 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id qLKQBRboNGE8QAAAbx9fmQ (envelope-from ) for ; Sun, 05 Sep 2021 15:53:58 +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 97C861DD60 for ; Sun, 5 Sep 2021 17:53:57 +0200 (CEST) Received: from localhost ([::1]:36444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMuSy-0000YI-Iq for larch@yhetil.org; Sun, 05 Sep 2021 11:53:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMuSn-0000YA-Ul for guix-devel@gnu.org; Sun, 05 Sep 2021 11:53:45 -0400 Received: from libre.brussels ([144.76.234.112]:58528) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mMuSl-0000vx-Ne for guix-devel@gnu.org; Sun, 05 Sep 2021 11:53:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libre.brussels; s=mail; t=1630857214; h=from:from: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: in-reply-to:in-reply-to:references:references; bh=cRjUnX82YPqGxUvICgxtEHtf5kScGZladPbpJsG4VxI=; b=NtDDzkFvXVNN4k01XBfoK6HYF3VLxJ9w7TNhUOg8aVhrN/y1Nk3sdayQ2RsTkHdbZHabJx pZd84WdIPNbOg6b03PB/v0OEpZlINXdARkZgpYjyY5RlFkv7uhLq4MLgeZKLnC5+p6Hej7 9wEf3ACMfhtT3s4gkYDHl+0VW2bLAxk= MIME-Version: 1.0 Date: Sun, 05 Sep 2021 15:53:34 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Jonathan McHugh" Message-ID: Subject: Re: Guix Jargon File (WAS: Rethinking propagated inputs?) To: "Bengt Richter" , "Liliana Marie Prikler" In-Reply-To: <20210905145423.GA3694@LionPure> References: <20210905145423.GA3694@LionPure> <86h7ezkfq9.fsf@mgsn.dev> <382a46ced17110e1bc03b94ba078b38c2669deac.camel@gmail.com> <20210905095018.GA2963@LionPure> <5492ffcdec13bf81cff285e14d0ff49a78e6c5c9.camel@gmail.com> Received-SPF: pass client-ip=144.76.234.112; envelope-from=indieterminacy@libre.brussels; helo=libre.brussels 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, SPF_HELO_PASS=-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: , Cc: guix-devel@gnu.org, Sarah Morgensen Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1630857237; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=cRjUnX82YPqGxUvICgxtEHtf5kScGZladPbpJsG4VxI=; b=r52gnHNi7p8GBvWb+0EdRt9VDA0XSxCNXSF9eVgQqmOXreBnmAHOeAjkZJ4Ke+5QwugFe6 3EHkRmYGClqkg9zB+d4QXvTooObDLejhZ/aXZpiIo4ISOlPKCoTQUvVvW1WlHFiwidlSAw L9voVnp+PjA+FDe/MXTwN0GoVXHcx7gSWy73NvvM0Hfg32/+oSr5dtb82mQcikyLaLtCdm shzcxoWl8svrqjax5OOvTQg/a0RgMakpSe00PryxSZCbqrTtaaXv8lyh9KFH7DNzro1JdN JMCEYOUsygc1CQL1T+e9ar+TCO6ywn2uo3NKM9PbxqCCwG8lNtjle01ZQWLXkw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630857237; a=rsa-sha256; cv=none; b=Cryqg7UkcVoSKBpquJp4FN/xgNZyPT8V7b6gMC6eQwdzbI6s+EyXPd9GZe7UohFwt+2nAH xSuxyrrMNxpljicbNd9ED2xGcUirCfsSIyrGPs85rjbgVOcH+UQVYdCQpinr02G0QcxCLi VdrKMy0QrNFot7TvjbQQVcS86N7MwuZPWlPKByoLHcxa/BnTfOxGNRY+qIVgoUQ4DZaIsF es7oo79nFuSDNbB9LZG9wy6tXFyCZdT0LnLVE/v9lsm059ktQYWkvpcrpE93PpgrDqniIz JeyIug4XMCVqJMvue8LFm2IOas+FaddRZK6mBFWjU6BTBmp3SW8A5MS99SCvuA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=libre.brussels header.s=mail header.b=NtDDzkFv; dmarc=fail reason="SPF not aligned (relaxed)" header.from=libre.brussels (policy=none); 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-Spam-Score: 0.19 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=libre.brussels header.s=mail header.b=NtDDzkFv; dmarc=fail reason="SPF not aligned (relaxed)" header.from=libre.brussels (policy=none); 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: 97C861DD60 X-Spam-Score: 0.19 X-Migadu-Scanner: scn0.migadu.com X-TUID: 6eKWYtTiEgv5 Hi Bengt, I believe that a collection of regular expressions for recognising starti= ng block and closing block for differing formats. It would for instance b= ecome political making a choice between (say): * -a-dangerous-pair-of-scissors--8<--ouch- ; * an Orgmode output; a GemText block; * somebody who uses '=C2=A3' as a delimiter, * et al. That way people can maintain their workflows while still having a better = idea of where other peoples blocks/citations are. FYI, I am looking into parsing manpages and 'cheat' style command tools t= o generate Parsing Expression Grammars - so as to permit people to identi= fy coding, if not perform actions. Hopefully one can then identify inline= content, as well as inferences regarding when coding blocks start and st= op (let alone additional knowledge) I was planning on using the Lisp TXR to do so - if somebody thinks this i= s a mistake please say so! If somebody would like to propose what a Guile= PEG environment should look like I can make an additional grammar. If I = get enough positive feedback I can prioritise it more for a project Im wo= rking on. Kind regards, Jonathan McHugh indieterminacy@libre.brussels September 5, 2021 4:54 PM, "Bengt Richter" wrote: > Hi Liliana, >=20 >=20Thank you for starting this renamed thread (as I should have done). >=20 >=20I think a people who are just looking at _maybe_ installing guix > should have an easy way to look up terms they haven't seen before. >=20 >=20But really I am more interested in promoting the idea of a snippet-qu= oting > convention modeled on a subset of mime email standards. >=20 >=20Very simple, but capable of containing and transferring anything unam= biguously > (if not always with efficient transmission encodings). >=20 >=20We can of course already do that with signed and attached files, and = we can > archive them and retrieve them, but I am interested in retrieving littl= e pieces > and making it easy to mark things in arbitratry contexts (like this ema= il or > a cannibal-friendly program source) so that simple snarfing utilities w= ill be > able to extract snippet-quote info based on tags and identifiers or any= thing > in the headers or content per search options much like for any search e= ngine. >=20 >=20This is to create a simple contribution mechanism as well as a format > for retrieval. >=20 >=20I have seen many code snippets from developers that are tutorial mate= rial > as well as practical how-tos for debugging and browsing guix. >=20 >=20Wouldn't it be nice if they were snip-quoted so that we could extract= them > from mail archives in a better way than searching the raw archives, or = having > to browse though treads and extract nuggets by hand? >=20 >=20simply: > --8<---------------cut here---------------start------------->8--- > header part, ending with blank line >=20 >=20optional content part, encoded and delimited or referenced per header= info > --8<---------------cut here---------------end--------------->8--- >=20 >=20The header part could start with just prefixing GX- like the optional= custom > header X- prefix described in mime rfcs, and we could borrow whatever w= as useful. >=20 >=20Tbc.. So called "real life" demands I postpone making a decent real e= xample > 'til later, sorry ;/ >=20 >=20Please excuse the big top-post. I had intended to comment and edit in= line ;/ >=20 >=20BTW, I know "info guix|grep -i whatever" often gives clues about what= ever, for pursuing > "C-s whatever" once inside "info guix whatever", but though concept and= api indices > are great, they are not a Jargon File, and not as handy for an outsider= :) >=20 >=20On +2021-09-05 12:50:56 +0200, Liliana Marie Prikler wrote: >=20 >>=20Hi, >>=20 >>=20Am Sonntag, den 05.09.2021, 11:50 +0200 schrieb Bengt Richter: >>> We don't call things build-inputs here in Guix land, that's a no-no >>> :P >>=20 >>=20Is there an official guix jargon file or glossary file or texi file >> or wikimedia/wiktionary/wikipedia clone on gnu.org that non- >> cognoscenti could use to get a clue? >> AFAIK no, you more or less have to go by what the manual tells you. As >> for why we have native-inputs and not build-inputs like other distros, >> it's because people often misclassify "build" inputs, so the definitio= n >> actually does more harm than good. Guix knows which files are actually >> "just used for build" by what ends up in the store, with some >> exceptions like UTF-32 encoded strings. >>=20 >>=20Is there a thread that on that topic making any progress on making i= t >> happen? >> AFAIK no. >>=20 >>=20when someone in a thread like this offers a candidate official >> definition, (off-topic sort of, but meta-on-topic for relevant >> documentation) could it be snip-quoted for easy search and >> aggregation for maintainers of official definitions and translations? >> E.g. >> (or actually borrow some rfc0842 or descendant so an attached file >> generates a usuable section in mail archives that can be snarfed >> automatically?) >>=20 >>=20--8<---------------cut here---------------start------------->8--- >> X-Content-type: Cadidate-guix-jargon-definition >> Ad lib comment and metacomment ended by blank line ... >> "> We don't call things build-inputs here in Guix land, that's a no- >> no :P" >>=20 >>=20build-propagated-inputs: >> >> --8<---------------cut here---------------end--------------->8--- >> When you quote someone like that out-of-context, you run a risk of >> misrepresenting what is actually stated. What I mean, is that a >> package field called something along the lines of "build-inputs" is >> likely to confuse Guix veterans and newcomers alike, as evidenced by >> the following reply: >>=20 >>=20Am Sonntag, den 05.09.2021, 10:06 +0000 schrieb Attila Lendvai: >> potentially worthless two cents from a newcomer's perspective: >> 'build-time' and 'run-time' are well established concepts in the >> wider community. >> And one, that is well misunderstood. >>=20 >>=20if i were reading 'linked-inputs' in a package definition, i wouldn'= t >> associate it to being the set of build-time dependencies. >> That's not what linked-inputs are, though. Take the following >> paragraph from propagated-inputs: >>=20 >>=20For example this is necessary when packaging a C/C++ library >> that needs headers of another library to compile, or when a >> pkg-config file refers to another one via its =E2=80=98Requires=E2=80= =99 >> field. >> This use case of propagated inputs explains why they need to be >> propagated when given as a (propagated-)input to a package, but not >> when given as a native input or merely existing in a profile. >>=20 >>=20The =E2=80=93 required if we go by other systems =E2=80=93 use case = of installing >> libraries system- or user-wide is already discouraged by Guix, for it >> is not needed. As long as we can spawn an environment, in which we can >> compile these things, it should be enough. >>=20 >>=20Note, that this is not equivalent to being a "build-time" dependency= . >> Going by Gentoo's definition "Build dependencies are used to specify >> any dependencies that are required to unpack, patch, compile, test or >> install the package", GCC is a build dependency of nearly any C progra= m >> (and a native one at that, i.e. BDEPEND in Gentoo), but it's not a >> linked-dependency, because there are numerous ways in which other >> programs could use it without ever needing to invoke GCC. Guix, of >> course, includes GCC as an implicit native input anyway, but that's a >> different topic. >>=20 >>=20Regards >=20 >=20-- > Regards, > Bengt Richter