Hi Bengt!
> ┌──┐
> │ "So I removed the comments." │
> └──┘
> Raghav, I think you may not grok the social signalling of a statement like
> that :)
My apologies! I didn't mean that with a negative connotation.
> It sounds like you are
Hi Mark!
> Thanks for the explanation.
>
> Please keep in mind that every comment in Guix was deliberately put
> there by a Guix developer, which means that at least one developer
> thought the comment was worth including.
>
> I'm concerned that you felt so confident in your assessment that
Hi Chris!
> In the context of writing Guix packages, propagating the necessary
> inputs to support other packages finding the library via pkg-config is a
> serious thing, not trivial. If it breaks, dependent packages will likely
> change in behaviour or stop building entirely.
I understand. I
Hi Christopher and Raghav,
On +2020-12-05 21:54:36 +, Christopher Baines wrote:
>
> Raghav Gururajan writes:
>
> > Hi Mark!
> >
> >> Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds
> >> of changes made in these commits.
> >>
> >> Do you have an explanation for why
Hi Raghav,
I asked:
>> Do you have an explanation for why you are removing comments in your
>> "cosmetic changes" commits?
"Raghav Gururajan" replied:
> I think the comments are useful for non-trivial cases. In these
> definitions, the inputs were propagated because they were mentioned in
>
Raghav Gururajan writes:
> Hi Mark!
>
>> Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds
>> of changes made in these commits.
>>
>> Do you have an explanation for why you are removing comments in your
>> "cosmetic changes" commits? For example, the following two commits
Hi Mark!
> Meanwhile, you've only provided a rationale for 1 out of 3 of the kinds
> of changes made in these commits.
>
> Do you have an explanation for why you are removing comments in your
> "cosmetic changes" commits? For example, the following two commits
> remove comments that explain why
I wrote:
> I just hacked up a little script to determine which ordering is more
> common. For simplicity, it only considers top-level declarations of the
> form (define-public (package ...)).
To be more precise, it only considers packages of that form where the
'...' contains both 'home-page'
Hi Raghav,
"Raghav Gururajan" writes:
> Yeah, my brain laterally connects fields of different package
> definitions. Like a spread-sheet, where each columns are different
> package definitions and each row is a fields of a package's
> definition.
>
> For example, if column 1 is glib and column
Hi Raghav,
first, let me say that as far as I'm concerned, you did nothing wrong--although
it caused a lot of work for you to do the rearranging in the first place
(and also some work for us).
Guix irregularities also annoy the hell out of me. You can check out some
earlier patches by me (when
Hi Ryan!
>> I can tell you that those cosmetic changes I made were 100% irrational,
>> useless and noisy.
>
> That's certainly a way to frame it, but I'd like to hold some space for the
> idea that the things we
> neuroatypical people do to manage and satisfy our own unusual perspectives
>
On December 4, 2020, Raghav Gururajan
wrote:
> I can tell you that those cosmetic changes I made were 100%
> irrational, useless and noisy.
That's certainly a way to frame it, but I'd like to hold some space for
the idea that the things we neuroatypical people do to manage and
satisfy our own
Hello Mark and Others!
Thank you for your concern.
I can tell you that those cosmetic changes I made were 100% irrational, useless
and noisy.
I have clinical OCD [1] and ADHD [2], for which I regularly take Fluoxetine and
Methylphenidate to keep things under control. Due to this, if the
Hi Ryan, Mark, et al,
On +2020-12-02 20:13:56 +, Ryan Prior wrote:
> Hi Mark!
>
> On December 2, 2020, Mark H Weaver wrote:
> > We all have our own personal preferences of how best to indent scheme
> > code, but if more of us adopted the habit of needlessly reordering
> > fields and
Hi Ryan,
Ryan Prior writes:
> I do think it's important to acknowledge that the commits written by
> Raghav were part of his internship and advised by his mentors who signed
> off on the commits, so it's not like these changes were unsolicited and
> materialized out of nowhere.
If those
Hi Martin,
Am 02.12.20 um 19:55 schrieb Mark H Weaver:
> I think that commits like this are best avoided for several reasons.
[…]
> Should I change those things back the next time I update that package?
My main project (PyInstaller) has the policy to not accept any
white-space changes and
Ryan Prior 写道：
I don't particularly hold any opinion about stylistic commits
except
that I prefer tools like gofmt, Python's Black and standard.js
which
enforce uniform code style, and would use such a tool for my
Guile code
if it exists.
Guix already has a uniform code formatter -- GNU
Hi Mark!
On December 2, 2020, Mark H Weaver wrote:
> We all have our own personal preferences of how best to indent scheme
> code, but if more of us adopted the habit of needlessly reordering
> fields and reindenting code of every package we touch, as one of us
> seems to have done, it could get
Hello fellow Guix,
In recent months there have been several "cosmetic changes" commits that
I find questionable. These commits reorder package fields and reindent
code that was already ordered and indented according to our conventions,
apparently in order to match the author's personal
19 matches
Mail list logo
