Re: Guix Jargon File (WAS: Rethinking propagated inputs?)

[Jonathan McHugh]

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" <bokr@bokr.com> 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:
>> <please fill in :) >
>> --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