GNU bug report logs - #44460
[PATCH] processes: Optionally normalize recutils output.

Previous Next

Package: guix-patches;

Reported by: John Soo <jsoo1 <at> asu.edu>

Date: Thu, 5 Nov 2020 04:32:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #38 received at 44460 <at> debbugs.gnu.org (full text, mbox):

From: John Soo <jsoo1 <at> asu.edu>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 44460 <at> debbugs.gnu.org
Subject: Re: [bug#44460] Add copyright lines
Date: Thu, 12 Nov 2020 21:33:52 -0800
[Message part 1 (text/plain, inline)]
Hi Ludo,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Yes it does!  Initially I wondered if it was a term used in recutils,
> but apparently it’s not.

Do you think it is the best term to use?

>> An aside - Probably to be entirely honest about normalizing the output,
>> locks really would be in a separate record set too.
>
> Yeah.

I made Lock a separate record set. This exposes a limitation with
recutils. It is not possible to join more than two record sets together
(though they mentioned it as a goal on IRC).

>> Another challenge is making sure the user can understand what
>> "normalized" means.  I am not sure readers of the manual/cli help will
>> be able to infer what it means from context.  On the other hand, it is
>> such a small use case that it seems imbalanced to provide a lot of
>> background for the term "normal". What do you think?
>
> Sure.
>
> Thinking more about it, to me the appeal of recutils is that it’s both
> human- and machine-readable.  But here we end up having a specific
> machine-readable variant.  But yeah, maybe that’s unavoidable.

I suppose the normalized version is a little less human-readable.  It
would be behind a flag, though.  Is that a reasonable compromise?

After some thought I realize that the normalized version isn't that much
more useful than the default, but it does enable things like:

---- Example ----
$ guix processes -f normalized \
  | recsel \
    -t ChildProcess \
    -j Session \
    -p PID,Session.PID \
  | recfmt '{{PID}} {{Session.PID}}'
23607 2356724713 2356725002 23576
---- Example ----

This will format all the (PID, Session) pairs. Whereas the
non-normalized version would only print one PID given the following.

---- Example ----
$ guix processes \
  | recsel -p ChildPID,SessionPID \
  | recfmt '{{ChildPID}} {{SessionPID}}'
23607 23567
---

>>>> I wouldn't be opposed to splitting ChildProcess into ChildPID and
>>>> ChildCommand.  I would like it best if that change was made in addition
>>>> to adding the normalized version, since the normalized version allows
>>>> more functionality.
>>>
>>> I would think it’s OK to break compatibility on just these
>>> “ChildProcess” fields.
>>
>> Ok. Would it be ok if I put that in a separate commit?
>
> Yes (you mean in addition to ‘-f normalized’, right?).

I changed ChildProcess: pid: command to ChildPID and ChildCommand in the
default in a separate commit.

Thanks again,

John

[0001-processes-Put-ChildProcess-and-ChildPID-on-separate-.patch (text/x-patch, attachment)]
[0002-processes-Optionally-normalize-recutils-output.patch (text/x-patch, attachment)]

This bug report was last modified 4 years and 171 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.