Markus Armbruster writes:
> Andrea Bolognani writes:
>
>> The various schemas included in QEMU use a JSON-based format which
>> is, however, strictly speaking not valid JSON.
>>
>> As a consequence, when vim tries to apply syntax highlight rules
>> for JSON (as guessed from the file name), the
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
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
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
>>
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
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)
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
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 '//'
* 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
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
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
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
Daniel P. Berrangé writes:
> On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote:
>> Andrea Bolognani writes:
>>
>> > The various schemas included in QEMU use a JSON-based format which
>> > is, however, strictly speaking not valid JSON.
>> >
>> > As a consequence, when vim
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
Paolo Bonzini writes:
> On 01/08/20 01:12, Nir Soffer wrote:
>> I think inventing DSLs and developing tools is wrong. Use standard
>> format and tools and spend time on the core of the project.
>
> Please don't apply 2020 standards to choices that were made in 2009. Or
> if you do, be ready to
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
On Mon, Aug 3, 2020 at 3:23 PM Daniel P. Berrangé wrote:
>
> On Mon, Aug 03, 2020 at 02:16:19PM +0200, Paolo Bonzini wrote:
> > On 03/08/20 13:36, Daniel P. Berrangé wrote:
> > >>> Given that QEMU needs to pass
> > >>> uint64 values, JSON was simply the wrong choice of format for QMP.
> > >
> > >
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
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
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
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
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
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
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
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
Daniel P. Berrangé writes:
> On Mon, Aug 03, 2020 at 02:16:19PM +0200, Paolo Bonzini wrote:
>> On 03/08/20 13:36, Daniel P. Berrangé wrote:
>> >>> Given that QEMU needs to pass
>> >>> uint64 values, JSON was simply the wrong choice of format for QMP.
>> >
>> > I wasn't refering to RFC7159. The
On Mon, Aug 03, 2020 at 02:33:36PM +0200, Paolo Bonzini wrote:
> On 03/08/20 14:23, Daniel P. Berrangé wrote:
> > We'd really love to move off YAJL for JSON parsing
>
> What are the issues with YAJL?
It is abandonware for more than 5 years now, with an ever growing list
of bug reports and pull
On 03/08/20 14:23, Daniel P. Berrangé wrote:
> We'd really love to move off YAJL for JSON parsing
What are the issues with YAJL?
>> It could be avoided by using a schema in Libvirt, just like QEMU has no
>> problem with it on the other side; it's just a different design choice
>> with different
On Mon, Aug 03, 2020 at 02:16:19PM +0200, Paolo Bonzini wrote:
> On 03/08/20 13:36, Daniel P. Berrangé wrote:
> >>> Given that QEMU needs to pass
> >>> uint64 values, JSON was simply the wrong choice of format for QMP.
> >
> > I wasn't refering to RFC7159. The problem of undefined integer
On 01/08/20 01:12, Nir Soffer wrote:
> I think inventing DSLs and developing tools is wrong. Use standard
> format and tools and spend time on the core of the project.
Please don't apply 2020 standards to choices that were made in 2009. Or
if you do, be ready to contribute code.
Paolo
On 03/08/20 13:36, Daniel P. Berrangé wrote:
>>> Given that QEMU needs to pass
>>> uint64 values, JSON was simply the wrong choice of format for QMP.
>
> I wasn't refering to RFC7159. The problem of undefined integer precision
> with JSON came up right at the very start when QMP was first designed
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
On Mon, Aug 03, 2020 at 10:41:22AM +0200, Paolo Bonzini wrote:
> On 31/07/20 17:44, Daniel P. Berrangé wrote:
> > I'd consider the runtime protocol separately. In terms of what's on the
> > wire, we use genuine JSON format. The runtime problem is simply that JSON
> > standard is useless when it
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
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
Paolo Bonzini writes:
> On 31/07/20 17:44, Daniel P. Berrangé wrote:
>> I'd consider the runtime protocol separately. In terms of what's on the
>> wire, we use genuine JSON format. The runtime problem is simply that JSON
>> standard is useless when it comes to integers, leaving behaviour
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:47:01PM +0200, Paolo Bonzini wrote:
> On 31/07/20 19:20, Daniel P. Berrangé wrote:
> > It also means QMP isn't easily extensible. eg if we used
> > HTTP as our base, then we'd get remote TLS support for free from
> > whatever library we used.
>
> ... and we would lose
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
Kevin Wolf writes:
> Am 31.07.2020 um 11:01 hat Markus Armbruster geschrieben:
>> Kevin Wolf writes:
>>
>> > Am 30.07.2020 um 17:11 hat Eric Blake geschrieben:
>> >> > JSON is a exceptionally poor choice for a DSL, or even a configuration
>> >> > language.
>> >> >
>> >> > Correcting our
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
On 31/07/20 17:44, Daniel P. Berrangé wrote:
> I'd consider the runtime protocol separately. In terms of what's on the
> wire, we use genuine JSON format. The runtime problem is simply that JSON
> standard is useless when it comes to integers, leaving behaviour undefined
> in the standard if you
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
Paolo Bonzini writes:
> On 31/07/20 19:53, John Snow wrote:
>> You have misunderstood me.
>>
>> The critique I am relaying, but not raising, is that we already use a
>> custom JSON parser in two or more places, and so replacing one instance
>> of this with a new format actually complicates QEMU
Daniel P. Berrangé writes:
> On Fri, Jul 31, 2020 at 11:26:28AM -0400, John Snow wrote:
>> > The long answer is that as a general philosophy I'm in favour of
>> > agressively
>> > eliminating anything that is custom to a project and isn't offering an
>> > compelling benefit over a functionally
On Thu, Jul 30, 2020 at 12:38 PM Daniel P. Berrangé wrote:
>
> On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote:
> > Andrea Bolognani writes:
> >
> > > The various schemas included in QEMU use a JSON-based format which
> > > is, however, strictly speaking not valid JSON.
> > >
>
On 31/07/20 19:53, John Snow wrote:
> You have misunderstood me.
>
> The critique I am relaying, but not raising, is that we already use a
> custom JSON parser in two or more places, and so replacing one instance
> of this with a new format actually complicates QEMU instead of
> simplifies it.
>
On 7/31/20 12:35 PM, Paolo Bonzini wrote:
On 31/07/20 17:26, John Snow wrote:
I saw the critique that we still use JSON-ish for the runtime QMP
protocol, and moving the QAPI IDL to a standard wouldn't remove all
instances of a custom format from our tree.
Sorry, but "still using JSON" is not
On 31/07/20 19:20, Daniel P. Berrangé wrote:
> It also means QMP isn't easily extensible. eg if we used
> HTTP as our base, then we'd get remote TLS support for free from
> whatever library we used.
... and we would lose events, unless we do something with HTTP/2 and
streaming responses. We
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
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
On Fri, Jul 31, 2020 at 06:35:23PM +0200, Paolo Bonzini wrote:
> On 31/07/20 17:26, John Snow wrote:
> > I saw the critique that we still use JSON-ish for the runtime QMP
> > protocol, and moving the QAPI IDL to a standard wouldn't remove all
> > instances of a custom format from our tree.
>
>
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
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
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 31/07/20 17:26, John Snow wrote:
> > I saw the critique that we still use JSON-ish for the runtime QMP
> > protocol, and moving the QAPI IDL to a standard wouldn't remove all
> > instances of a custom format from our tree.
>
> Sorry, but "still
Am 31.07.2020 um 17:07 hat Daniel P. Berrangé geschrieben:
> On Fri, Jul 31, 2020 at 02:55:34PM +0200, Markus Armbruster wrote:
> > Daniel P. Berrangé writes:
>
> > >> Some of the criticism there doesn't matter for our use case.
> > >
> > > Yeah, what matters is whether it can do the job we
On 31/07/20 17:26, John Snow wrote:
> I saw the critique that we still use JSON-ish for the runtime QMP
> protocol, and moving the QAPI IDL to a standard wouldn't remove all
> instances of a custom format from our tree.
Sorry, but "still using JSON" is not a critique that makes any sense.
99% of
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
On Fri, Jul 31, 2020 at 11:26:28AM -0400, John Snow wrote:
> > The long answer is that as a general philosophy I'm in favour of agressively
> > eliminating anything that is custom to a project and isn't offering an
> > compelling benefit over a functionally equivalent, commonly used / standard
> >
On 7/31/20 11:07 AM, Daniel P. Berrangé wrote:
On Fri, Jul 31, 2020 at 02:55:34PM +0200, Markus Armbruster wrote:
Daniel P. Berrangé writes:
Some of the criticism there doesn't matter for our use case.
Yeah, what matters is whether it can do the job we need in a way that is
better than
On Fri, Jul 31, 2020 at 02:55:34PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
> >> Some of the criticism there doesn't matter for our use case.
> >
> > Yeah, what matters is whether it can do the job we need in a way that is
> > better than what we have today, and whether there
Daniel P. Berrangé writes:
> On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé writes:
>>
>> > modify them so that we can load the
>> > files straight into the python intepretor as code, and not parse
>> > them as data. I
Am 31.07.2020 um 11:01 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 30.07.2020 um 17:11 hat Eric Blake geschrieben:
> >> > JSON is a exceptionally poor choice for a DSL, or even a configuration
> >> > language.
> >> >
> >> > Correcting our mistake involves a flag day and a
On Fri, Jul 31, 2020 at 11:21:35AM +0200, Markus Armbruster wrote:
> John Snow writes:
>
> > On 7/30/20 9:24 AM, Daniel P. Berrangé wrote:
> >>> Some of the criticism there doesn't matter for our use case.
> >>
> >> Yeah, what matters is whether it can do the job we need in a way that is
> >>
John Snow writes:
> On 7/30/20 9:24 AM, Daniel P. Berrangé wrote:
>> On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote:
>>> Daniel P. Berrangé writes:
>>>
modify them so that we can load the
files straight into the python intepretor as
Kevin Wolf writes:
> Am 30.07.2020 um 17:11 hat Eric Blake geschrieben:
>> > JSON is a exceptionally poor choice for a DSL, or even a configuration
>> > language.
>> >
>> > Correcting our mistake involves a flag day and a re-learn. We need to
>> > weigh costs against benefits.
>> >
>> > The
On Fri, Jul 31, 2020 at 09:15:13AM +0200, Kevin Wolf wrote:
> Am 30.07.2020 um 17:11 hat Eric Blake geschrieben:
> > > The QAPI schema language has two layers:
> > >
> > > * JSON, with a lexical and a syntactical sub-layer (both in parser.py)
> > >
> > > * QAPI, with a context-free and a
Am 30.07.2020 um 17:11 hat Eric Blake geschrieben:
> > The QAPI schema language has two layers:
> >
> > * JSON, with a lexical and a syntactical sub-layer (both in parser.py)
> >
> > * QAPI, with a context-free and a context-dependend sub-layer (in
> >expr.py and schema.py, respectively)
> >
On 7/30/20 9:24 AM, Daniel P. Berrangé wrote:
On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote:
Daniel P. Berrangé writes:
modify them so that we can load the
files straight into the python intepretor as code, and not parse
them as data. I feel
On 7/30/20 11:11 AM, Eric Blake wrote:
JSON5 would also let us get rid of some quotes, if that is considered a
desirable goal of the representation (although I'm not sure that quote
avoidance should be driving our decision, so much as automated conversion).
There's no JSON5 parser built in to
On 7/30/20 11:11 AM, Eric Blake wrote:
Agreed on that front.
Thirded:
Reviewed-by: John Snow
On 7/30/20 6:51 AM, Markus Armbruster wrote:
Given that we already have emacs mode-lines, I see no reason to
not also have vim mode-lines, so regardless of the deeper discussion
I think this is patch is fine to merge in the short term
Reviewed-by: Daniel P. Berrangé
Agreed on that front.
On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > modify them so that we can load the
> > files straight into the python intepretor as code, and not parse
> > them as data. I feel unhappy about treating data as
Andrea Bolognani writes:
> The various schemas included in QEMU use a JSON-based format which
> is, however, strictly speaking not valid JSON.
>
> As a consequence, when vim tries to apply syntax highlight rules
> for JSON (as guessed from the file name), the result is an unreadable
> mess which
Daniel P. Berrangé writes:
> On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote:
>> Andrea Bolognani writes:
>>
>> > The various schemas included in QEMU use a JSON-based format which
>> > is, however, strictly speaking not valid JSON.
>> >
>> > As a consequence, when vim tries
On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote:
> Andrea Bolognani writes:
>
> > The various schemas included in QEMU use a JSON-based format which
> > is, however, strictly speaking not valid JSON.
> >
> > As a consequence, when vim tries to apply syntax highlight rules
> >
Andrea Bolognani writes:
> The various schemas included in QEMU use a JSON-based format which
> is, however, strictly speaking not valid JSON.
>
> As a consequence, when vim tries to apply syntax highlight rules
> for JSON (as guessed from the file name), the result is an unreadable
> mess which
The various schemas included in QEMU use a JSON-based format which
is, however, strictly speaking not valid JSON.
As a consequence, when vim tries to apply syntax highlight rules
for JSON (as guessed from the file name), the result is an unreadable
mess which mostly consist of red markers
78 matches
Mail list logo
