Eduardo Habkost writes:
> On Wed, Aug 05, 2020 at 06:23:23PM +0200, Kevin Wolf wrote:
>> We're basically weighing "git blame" against syntax highlighting
>> defaults. I don't think the latter has an obviously higher weight.
>
> I think "syntax highlight defaults" is far from being an accurate
> d
John Snow writes:
> On 8/5/20 3:36 AM, Markus Armbruster wrote:
>> John Snow writes:
>>
>>> On 8/4/20 4:03 AM, Markus Armbruster wrote:
The pain of tweaking the parser is likely dwarved several times over by
the pain of the flag day.
>>>
>>> You mention this often; I wonder if I misund
On Wed, Aug 05, 2020 at 06:23:23PM +0200, Kevin Wolf wrote:
> Am 05.08.2020 um 12:08 hat Daniel P. Berrangé geschrieben:
> > On Wed, Aug 05, 2020 at 11:11:55AM +0200, Cornelia Huck wrote:
> > > On Wed, 5 Aug 2020 10:05:40 +0100
> > > Daniel P. Berrangé wrote:
> > >
> > > > On Wed, Aug 05, 2020
Am 05.08.2020 um 12:08 hat Daniel P. Berrangé geschrieben:
> On Wed, Aug 05, 2020 at 11:11:55AM +0200, Cornelia Huck wrote:
> > On Wed, 5 Aug 2020 10:05:40 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> > > > On 05/08/20 10:39, Dr.
On 8/5/20 3:36 AM, Markus Armbruster wrote:
John Snow writes:
On 8/4/20 4:03 AM, Markus Armbruster wrote:
The pain of tweaking the parser is likely dwarved several times over by
the pain of the flag day.
You mention this often; I wonder if I misunderstand the critique,
because the pain of a
On Wed, 5 Aug 2020 11:08:02 +0100
Daniel P. Berrangé wrote:
> On Wed, Aug 05, 2020 at 11:11:55AM +0200, Cornelia Huck wrote:
> > On Wed, 5 Aug 2020 10:05:40 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> > > > On 05/08/20 10:39
Markus Armbruster writes:
> Paolo Bonzini writes:
>
>> On 05/08/20 09:36, Markus Armbruster wrote:
>>> There's also the longer term pain of having to work around git-blame
>>> unable to see beyond the flag day.
>>
>> Do you really use "git blame" that much? "git log -S" does more or less
>> t
On Wed, Aug 05, 2020 at 11:11:55AM +0200, Cornelia Huck wrote:
> On Wed, 5 Aug 2020 10:05:40 +0100
> Daniel P. Berrangé wrote:
>
> > On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> > > On 05/08/20 10:39, Dr. David Alan Gilbert wrote:
> > > >> Do you really use "git blame" that
On Wed, 5 Aug 2020 10:05:40 +0100
Daniel P. Berrangé wrote:
> On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> > On 05/08/20 10:39, Dr. David Alan Gilbert wrote:
> > >> Do you really use "git blame" that much? "git log -S" does more or less
> > >> the same function (in a differ
On Wed, Aug 05, 2020 at 10:49:35AM +0200, Paolo Bonzini wrote:
> On 05/08/20 10:39, Dr. David Alan Gilbert wrote:
> >> Do you really use "git blame" that much? "git log -S" does more or less
> >> the same function (in a different way) and is not affected as much by
> >> large code movement and tra
Paolo Bonzini writes:
> On 05/08/20 09:36, Markus Armbruster wrote:
>> There's also the longer term pain of having to work around git-blame
>> unable to see beyond the flag day.
>
> Do you really use "git blame" that much? "git log -S" does more or less
> the same function (in a different way) a
On 05/08/20 10:39, Dr. David Alan Gilbert wrote:
>> Do you really use "git blame" that much? "git log -S" does more or less
>> the same function (in a different way) and is not affected as much by
>> large code movement and transformation patches.
>
> I use it a lot! Following stuff back to find
On Wed, 5 Aug 2020 10:25:30 +0200
Paolo Bonzini wrote:
> On 05/08/20 09:36, Markus Armbruster wrote:
> > There's also the longer term pain of having to work around git-blame
> > unable to see beyond the flag day.
>
> Do you really use "git blame" that much? "git log -S" does more or less
> th
Markus Armbruster writes:
> Paolo Bonzini writes:
[...]
>> That said, after a bit more research I'm skeptical about the possibility
>> of using an off-the-shelf parser because most of them either don't
>> support comments, or are based on YAJL which simply discards comments.
>>
>> Since '//' com
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 05/08/20 09:36, Markus Armbruster wrote:
> > There's also the longer term pain of having to work around git-blame
> > unable to see beyond the flag day.
>
> Do you really use "git blame" that much? "git log -S" does more or less
> the same functio
On 05/08/20 09:36, Markus Armbruster wrote:
> There's also the longer term pain of having to work around git-blame
> unable to see beyond the flag day.
Do you really use "git blame" that much? "git log -S" does more or less
the same function (in a different way) and is not affected as much by
lar
John Snow writes:
> On 8/4/20 4:03 AM, Markus Armbruster wrote:
>> The pain of tweaking the parser is likely dwarved several times over by
>> the pain of the flag day.
>
> You mention this often; I wonder if I misunderstand the critique,
> because the pain of a "flag day" for a new file format se
On 8/4/20 4:03 AM, Markus Armbruster wrote:
The pain of tweaking the parser is likely dwarved several times over by
the pain of the flag day.
You mention this often; I wonder if I misunderstand the critique,
because the pain of a "flag day" for a new file format seems negligible
to me.
I do
Paolo Bonzini writes:
> On 03/08/20 18:03, Markus Armbruster wrote:
>>> In general it seems like a good idea to use a standard file format and
>>> not "a standard file format except for two characters". :) We also
>>> wouldn't be having discussions on editors.
>>
>> No argument. But towards wh
Kevin Wolf writes:
> Am 03.08.2020 um 18:03 hat Markus Armbruster geschrieben:
>> Paolo Bonzini writes:
>> > This means the two parts might be considered separately:
>> >
>> > - replacing single-quote with double-quote strings
>> >
>> > - replacing # comments with //
>>
>> If all we want is dec
On 8/3/20 3:54 PM, Nir Soffer wrote:
On Mon, Aug 3, 2020 at 9:19 PM John Snow wrote:
On 8/3/20 2:16 PM, Paolo Bonzini wrote:
On 03/08/20 20:10, John Snow wrote:
Heresy:
Docstrings could become part of the data format so they can be parsed,
analyzed and validated. Parsers largely treat comme
On Mon, Aug 3, 2020 at 9:19 PM John Snow wrote:
>
> On 8/3/20 2:16 PM, Paolo Bonzini wrote:
> > On 03/08/20 20:10, John Snow wrote:
> >> Heresy:
> >>
> >> Docstrings could become part of the data format so they can be parsed,
> >> analyzed and validated. Parsers largely treat comments like non-sem
On 8/3/20 2:16 PM, Paolo Bonzini wrote:
On 03/08/20 20:10, John Snow wrote:
Heresy:
Docstrings could become part of the data format so they can be parsed,
analyzed and validated. Parsers largely treat comments like non-semantic
information and discard it. Round-trip parsers that preserve commen
On 03/08/20 20:10, John Snow wrote:
> Heresy:
>
> Docstrings could become part of the data format so they can be parsed,
> analyzed and validated. Parsers largely treat comments like non-semantic
> information and discard it. Round-trip parsers that preserve comments in
> any language are extremel
On 8/3/20 8:01 AM, Paolo Bonzini wrote:
That said, after a bit more research I'm skeptical about the possibility
of using an off-the-shelf parser because most of them either don't
support comments, or are based on YAJL which simply discards comments.
Heresy:
Docstrings could become part of the
On 03/08/20 18:03, Markus Armbruster wrote:
>> In general it seems like a good idea to use a standard file format and
>> not "a standard file format except for two characters". :) We also
>> wouldn't be having discussions on editors.
>
> No argument. But towards which standard file format should
Am 03.08.2020 um 18:03 hat Markus Armbruster geschrieben:
> Paolo Bonzini writes:
> > This means the two parts might be considered separately:
> >
> > - replacing single-quote with double-quote strings
> >
> > - replacing # comments with //
>
> If all we want is decent editor support out of the b
Paolo Bonzini writes:
> On 03/08/20 13:28, Markus Armbruster wrote:
We could remove them from the QAPI schema language. Flag day, and
git-blame becomes pretty much useless for a couple of years.
>>> Is that a nack or a "whatever"?
>> It's "is this really worth the trouble?" I guess th
On 03/08/20 13:28, Markus Armbruster wrote:
>>> We could remove them from the QAPI schema language. Flag day, and
>>> git-blame becomes pretty much useless for a couple of years.
>> Is that a nack or a "whatever"?
> It's "is this really worth the trouble?" I guess that's halfway between
> NAK and
Daniel P. Berrangé writes:
> On Mon, Aug 03, 2020 at 10:18:29AM +0200, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>> > - the single-quote strings, which are not particularly useful in QAPI
>> > schema
>>
>> Every single string in the QAPI schema uses them, though.
>>
>> I have no i
Paolo Bonzini writes:
> On 03/08/20 10:18, Markus Armbruster wrote:
>>> - the single-quote strings, which are not particularly useful in QAPI schema
>> Every single string in the QAPI schema uses them, though.
>>
>> I have no idea why Anthony put them in the QAPI schema language.
>>
>> We could
On Mon, Aug 03, 2020 at 10:18:29AM +0200, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
> > - the single-quote strings, which are not particularly useful in QAPI schema
>
> Every single string in the QAPI schema uses them, though.
>
> I have no idea why Anthony put them in the QAPI schema
On Fri, Jul 31, 2020 at 07:42:52PM +0200, Paolo Bonzini wrote:
> On 31/07/20 19:27, Daniel P. Berrangé wrote:
> > You say "main feature", I say "biggest flaw" ;-P
> >
> > Doing checks on patches is the single worst thing about the way
> > we do code style validation, at it means the bulk of commit
On 03/08/20 10:18, Markus Armbruster wrote:
>> - the single-quote strings, which are not particularly useful in QAPI schema
> Every single string in the QAPI schema uses them, though.
>
> I have no idea why Anthony put them in the QAPI schema language.
>
> We could remove them from the QAPI schem
Paolo Bonzini writes:
> On 31/07/20 17:07, Daniel P. Berrangé wrote:
>> The QAPI JSON-but-not file format is a case where I think we should just
>> adopt a standard file format no matter what. A conversion will have some
>> short term work, but this is really simple data to deal with and the code
On 31/07/20 19:27, Daniel P. Berrangé wrote:
> You say "main feature", I say "biggest flaw" ;-P
>
> Doing checks on patches is the single worst thing about the way
> we do code style validation, at it means the bulk of committed code
> is never in compliance. The need to check patches is precisely
On Fri, Jul 31, 2020 at 07:16:54PM +0200, Paolo Bonzini wrote:
> >>> Another example would be adopting a standard code style and using a
> >>> tool like clang-format to enforce this for entire of existing code
> >>> base and future contributions and throwing away our checkpatch.pl
> >>> which near
On 31/07/20 19:05, Daniel P. Berrangé wrote:
> NB our files are not JSON documents, they are a concatenation of a list
> of JSON documents.
This is not something that editors generally have problems with.
> If you use javascript mode, then emacs will highlight all the javascript
> language keywo
On Fri, Jul 31, 2020 at 06:28:06PM +0200, Paolo Bonzini wrote:
> On 31/07/20 17:07, Daniel P. Berrangé wrote:
> > The QAPI JSON-but-not file format is a case where I think we should just
> > adopt a standard file format no matter what. A conversion will have some
> > short term work, but this is re
On 31/07/20 17:07, Daniel P. Berrangé wrote:
> The QAPI JSON-but-not file format is a case where I think we should just
> adopt a standard file format no matter what. A conversion will have some
> short term work, but this is really simple data to deal with and the code
> involved is nicely self co
40 matches
Mail list logo
