From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4rHdNj+UNWEg5AAAgWs5BA (envelope-from ) for ; Mon, 06 Sep 2021 06:08:31 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SCLwMT+UNWENJQAAB5/wlQ (envelope-from ) for ; Mon, 06 Sep 2021 04:08:31 +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 21BC5BC8D for ; Mon, 6 Sep 2021 06:08:31 +0200 (CEST) Received: from localhost ([::1]:40544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mN5vq-0005Ul-5q for larch@yhetil.org; Mon, 06 Sep 2021 00:08:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mN5vY-0005UV-KT for guix-devel@gnu.org; Mon, 06 Sep 2021 00:08:13 -0400 Received: from imta-38.everyone.net ([216.200.145.38]:33926) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mN5vT-0006G4-U7 for guix-devel@gnu.org; Mon, 06 Sep 2021 00:08:10 -0400 Received: from pps.filterd (omta003.sj2.proofpoint.com [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 186481Ob015059; Sun, 5 Sep 2021 21:08:01 -0700 X-Eon-Originating-Account: 6F2kyWs7hzoBQI7BoOAWs62lknkatlXYehXbwRuMtpA X-Eon-Dm: m0116953.ppops.net Received: by m0116953.mta.everyone.net (EON-AUTHRELAY2 - 53b92649) id m0116953.611f98b5.155858; Sun, 5 Sep 2021 21:08:00 -0700 X-Eon-Sig: AQMHrIJhNZQgyHNmcwIAAAAE,24fe05150bfd33d7b2e76e74ffc4da3f X-Eip: 9M6FoeZWv8xJdFCnLGoYW-XwCoLQqtruLB_TqTv2bNs Date: Mon, 6 Sep 2021 06:07:50 +0200 From: Bengt Richter To: Jonathan McHugh Subject: Re: Guix Jargon File (WAS: Rethinking propagated inputs?) Message-ID: <20210906040750.GA2465@LionPure> References: <20210905145423.GA3694@LionPure> <86h7ezkfq9.fsf@mgsn.dev> <382a46ced17110e1bc03b94ba078b38c2669deac.camel@gmail.com> <20210905095018.GA2963@LionPure> <5492ffcdec13bf81cff285e14d0ff49a78e6c5c9.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-ORIG-GUID: c7A4syaQf90PLtJAN0i342rqop23Lkqb X-Proofpoint-GUID: c7A4syaQf90PLtJAN0i342rqop23Lkqb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-06_01:2021-09-03, 2021-09-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 bulkscore=0 clxscore=1034 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2108310000 definitions=main-2109060025 Received-SPF: pass client-ip=216.200.145.38; envelope-from=bokr@oz.net; helo=imta-38.everyone.net X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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: , Reply-To: Bengt Richter Cc: guix-devel@gnu.org, Sarah Morgensen , Liliana Marie Prikler 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=1630901311; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=YJ+i9jbGI6rJ8QO99x0SJzebxCA4iwr4j9Bnx0E8CJg=; b=XD0GpUG9ZaH7I47D7sJz6opxVOSaRahnWge2SrH7A6j5xP05j8sB0s3ICliPzaFmSqaMOA qoO1rBEKRBBBwGy5cEE+L8Bx8Df0XWQIP4k/ZYVpV2+e29oDGpxLkPoL1rkz+20gp7/bMf 49ofrlZMz+ZxW9qP7GzhlOVRX+b8x5nUlR1sN6CcZzgnM0BJOfvbjKMdNrBWHn4fvMAi+a tQRQrpxSQ7v/3HMyrZDu0Zg4urZV4CY3+FVDyHGMiNNjFiz/FOJEiZ9CpUCd3lpysD7cwB PRxSShTUfltInpIIlGcifr+rAWssKzrxcRfhYhfn1n0e1SQ7x3v8RgBylPbmcA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630901311; a=rsa-sha256; cv=none; b=dFs0Wdnv3PoD2+tT4Kc8pM3CTIB0s4oLF3b1qL8gvPHckguidbpNAimeDiD0F7YSssQHDq zu7EqRqjNFotMSnkCh6vW5m/fKRwXtZzOnowtObEkXjW8dCQ9D/9hyn19N/EUMubH3slIq vogc+UotfgYbHoFdvuiHP+X2MNf/biJKXjbESDstYr6P3D5AJwXLyqQ0+iGMOM5w/Ivz9p qeGyJCjnGjKwjIp3Q65jxCo+WlpQRaH1Ud3oCV4kWfiF8uySRsheg9NyO2eRsDjxnZ4nY0 aBIq5cI3Fv05AZuR4Hew2vK8prOJYK8h/6hWYYAW7ZBTY+6XmMx0Nmz7Dncb3g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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.41 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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: 21BC5BC8D X-Spam-Score: -0.41 X-Migadu-Scanner: scn1.migadu.com X-TUID: DdhGlyu6YpV8 Hi Jonathan, Thanks for the TXR reference, I will have to look into it. Just on the basis of the author name "Kaz Kylheku" I would check it out. I have encountered his posts 'way in the past, and they were always intelligent and interesting. (If he is older than me, I'd like to know more about his diet and habits ;-) Anyway, if you are interested in PEGs in any guix connection, I think you should look at Guile's PEG implementation and syntaxes (scheme and string/regex styles). Type "info guile" (not guix), and then "Ctrl-s Peg Parsing" which will take you to an index, and either use that link (hit Return) or hit Ctrl-s again and you should be at the beginning of some interesting reading ;-) Note that guix is built on top of guile and its infrastructure of libaries (mostly C still where they aren't scheme, UIAM, but that may be changing to include more, I'm not sure -- I am not insider enough to follow ;-) Maybe you can make a guile-txr.scm package for a txr wrapper module using foreign function or your own C extension loadable by guile scheme. Have fun! Maybe my best strategy is to see what you come up with before re-inventing things you may already be way ahead in :) Oh, if you haven't already, also check into guile's regular expressions, e.g. "info guile Ret Ctrl-s regular expressions Ret Ret" And also try guile's repl by just typing "guile Ret" and then ",help" Mvh, Bengt Richter On +2021-09-05 15:53:34 +0000, Jonathan McHugh wrote: > Hi Bengt, > > I believe that a collection of regular expressions for recognising starting block and closing block for differing formats. It would for instance become political making a choice between (say): > * -a-dangerous-pair-of-scissors--8<--ouch- ; > * an Orgmode output; a GemText block; > * somebody who uses '£' 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 to generate Parsing Expression Grammars - so as to permit people to identify coding, if not perform actions. Hopefully one can then identify inline content, as well as inferences regarding when coding blocks start and stop (let alone additional knowledge) > > I was planning on using the Lisp TXR to do so - if somebody thinks this is 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 working on. > > Kind regards, > > > Jonathan McHugh > indieterminacy@libre.brussels > > September 5, 2021 4:54 PM, "Bengt Richter" wrote: > > > Hi Liliana, > > > > Thank you for starting this renamed thread (as I should have done). > > > > I 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. > > > > But really I am more interested in promoting the idea of a snippet-quoting > > convention modeled on a subset of mime email standards. > > > > Very simple, but capable of containing and transferring anything unambiguously > > (if not always with efficient transmission encodings). > > > > We 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 little pieces > > and making it easy to mark things in arbitratry contexts (like this email or > > a cannibal-friendly program source) so that simple snarfing utilities will be > > able to extract snippet-quote info based on tags and identifiers or anything > > in the headers or content per search options much like for any search engine. > > > > This is to create a simple contribution mechanism as well as a format > > for retrieval. > > > > I have seen many code snippets from developers that are tutorial material > > as well as practical how-tos for debugging and browsing guix. > > > > Wouldn'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? > > > > simply: > > --8<---------------cut here---------------start------------->8--- > > header part, ending with blank line > > > > optional content part, encoded and delimited or referenced per header info > > --8<---------------cut here---------------end--------------->8--- > > > > The header part could start with just prefixing GX- like the optional custom > > header X- prefix described in mime rfcs, and we could borrow whatever was useful. > > > > Tbc.. So called "real life" demands I postpone making a decent real example > > 'til later, sorry ;/ > > > > Please excuse the big top-post. I had intended to comment and edit in line ;/ > > > > BTW, I know "info guix|grep -i whatever" often gives clues about whatever, 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 :) > > > > On +2021-09-05 12:50:56 +0200, Liliana Marie Prikler wrote: > > > >> Hi, > >> > >> Am 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 > >> > >> Is 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 definition > >> 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. > >> > >> Is there a thread that on that topic making any progress on making it > >> happen? > >> AFAIK no. > >> > >> when 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?) > >> > >> --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" > >> > >> build-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: > >> > >> Am 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. > >> > >> if 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: > >> > >> For 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 ‘Requires’ > >> 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. > >> > >> The – required if we go by other systems – 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. > >> > >> Note, 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 program > >> (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. > >> > >> Regards > > > > -- > > Regards, > > Bengt Richter