[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] schemas: Add vim modeline
From: |
Markus Armbruster |
Subject: |
Re: [PATCH] schemas: Add vim modeline |
Date: |
Fri, 31 Jul 2020 11:21:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
John Snow <jsnow@redhat.com> 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é <berrange@redhat.com> 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 code though.
>>>
>>> Stress on *can* load. Doesn't mean we should.
>>>
>>> Ancient prior art: Lisp programs routinely use s-expressions as
>>> configuration file syntax. They don't load them as code, they read them
>>> as data.
>>>
>>> With Python, it's ast.parse(), I think.
>>
>> Yes, that could work
>>
>
> I use a similar trick for parsing "Fuzzy JSON" inside of qmp-shell.
>
> It's cute, and I'm not really proud of it.
>
>>
>>>> struct: ImageInfoSpecificQCow2
>>>> data:
>>>> compat: str
>>>> "*data-file": str
>>>> "*data-file-raw": bool
>>>> "*lazy-refcounts": bool
>>>> "*corrupt": bool
>>>> refcount-bits: int
>>>> "*encrypt": ImageInfoSpecificQCow2Encryption
>>>> "*bitmaps":
>>>> - Qcow2BitmapInfo
>>>> compression-type: Qcow2CompressionType
>>>>
>>>>
>>>> Then we could use a regular off the shelf YAML parser in python.
>>>>
>
> I have a prototype where I started this, but I use "---" as a document
> separator to allow us multiple definitions per file so that the
> nesting remains pleasant.
>
> (YAML does not allow you to duplicate field names.)
>
>>>> The uglyiness with quotes is due to the use of "*". Slightly less ugly
>>>> if we simply declare that quotes are always used, even where they're
>>>> not strictly required.
>>>
>>> StrictYAML insists on quotes.
>>
>> I wouldn't suggest StrictYAML, just normal YAML is what pretty much
>> everyone uses.
>> > If we came up with a different way to mark a field as optional
>> instead of using the magic "*" then we wouldn't need to quote
>> anything
>>
>
> I have a YAML prototype branch where I use `?field` to indicate
> optional syntax. It works just fine, at the expense of being slightly
> new to people.
>
> I tested with normal YAML, but I was thinking about adopting strict
> YAML because Markus wanted some assurance we wouldn't get lost in the
> weeds using complex feature of YAML.
>
> (Or, shoot ourselves entirely by accident.)
>
> My prototype doesn't use anything that Strict YAML prohibits, so I
> thought it was a good idea.
>
> IF -- IF IF IF IF IF we decide that actually we need the crazy
> horsepower of standard YAML, or that strict YAML is too buggy -- we
> could always just replace it. No real big deal.
>
>>> I hate having to quote identifiers. There's a reason we don't write
>>>
>>> 'int'
>>> 'main'('int', 'argc', 'char' *'argv'[])
>>> {
>>> 'printf'("hello world\n");
>>> return 0;
>>> }
>>>
>
> Fair enough ... but there's no special meaning to quoting or not
> quoting the RHS in YAML, so maybe it's best to avoid pretending like
> there's a structural semantic between an identifier and a string
> there.
>
> (Since they're both just strings, and the semantic difference is
> picked up inside the QAPI generator post-parse.)
You wish...
An unquoted right hand side is a string, unless it can be interpreted as
something else. For instance, when something else is one of the
eleven(?) ways to say false, you have a variation of YAML's Norway
problem:
https://hitchdev.com/strictyaml/why/implicit-typing-removed/
>>>> struct: ImageInfoSpecificQCow2
>>>> data:
>>>> "compat": "str"
>>>> "*data-file": "str"
>>>> "*data-file-raw": "bool"
>>>> "*lazy-refcounts": "bool"
>>>> "*corrupt": "bool"
>>>> "refcount-bits": "int"
>>>> "*encrypt": "ImageInfoSpecificQCow2Encryption"
>>>> "*bitmaps":
>>>> - "Qcow2BitmapInfo"
>>>> "compression-type": "Qcow2CompressionType"
>>>>
>>>> With the use of "---" to denote the start of document, we have no trouble
>>>> parsing our files which would actually be a concatenation of multiple
>>>> documents. The python YAML library provides the easy yaml.load_all()
>>>> method.
>>>
>
> Nevermind the earlier comment, then.
>
>>> Required reading on YAML:
>>> https://www.arp242.net/yaml-config.html
>>
>> I don't think this is especially helpful to our evaluation. You can write
>> such blog posts about pretty much any thing if you want to pick holes in a
>> proposal. Certainly there's plenty of awful stuff you can write about
>> JSON, and Python.
>>
>>> 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 are any further options
>> to consider that might be viable alternatives.
The sheer complexity of YAML puts me off. The spec exceeds 20k words.
> I guess I'll dust off the work I have already to show the class.
Prototype code should beat guesswork.
- [PATCH] schemas: Add vim modeline, Andrea Bolognani, 2020/07/29
- Re: [PATCH] schemas: Add vim modeline, Markus Armbruster, 2020/07/30
- Re: [PATCH] schemas: Add vim modeline, Markus Armbruster, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, Daniel P . Berrangé, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, John Snow, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, Daniel P . Berrangé, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, Paolo Bonzini, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, Dr. David Alan Gilbert, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, Daniel P . Berrangé, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, Paolo Bonzini, 2020/07/31
- Re: [PATCH] schemas: Add vim modeline, John Snow, 2020/07/31