Reviewed-by: Wenchao Xia
I didn't expect dot in schema before.
On Mon, 14 Jul 2014 12:31:32 -0600
Eric Blake wrote:
> On 07/14/2014 12:12 PM, Luiz Capitulino wrote:
> Agree. Let's ditch nested structs and see whether there are any misuses
> of c_var() left.
> >>>
> >>> This is an honest question: do we really want to drop nested struct
> >>> supp
On 07/14/2014 12:12 PM, Luiz Capitulino wrote:
Agree. Let's ditch nested structs and see whether there are any misuses
of c_var() left.
>>>
>>> This is an honest question: do we really want to drop nested struct support,
>>> wasn't it added by the block layer or am I just confused?
>>
>>
On Fri, 11 Jul 2014 15:22:24 -0600
Eric Blake wrote:
> On 07/11/2014 12:51 PM, Luiz Capitulino wrote:
>
> { 'type': 'VersionInfo',
> 'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'},
> + '__com.redhat.crap': {'major': 'int', 'minor': 'int',
> '
On 07/11/2014 12:51 PM, Luiz Capitulino wrote:
{ 'type': 'VersionInfo',
'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'},
+ '__com.redhat.crap': {'major': 'int', 'minor': 'int', 'micro':
'int'},
'package': 'str'} }
>>>
>>> And th
On Fri, 11 Jul 2014 18:01:50 +0200
Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 07/11/2014 08:42 AM, Markus Armbruster wrote:
> >
> Can anybody think of a use of c_var() that needs '.' preserved?
> >>>
> >>> Doing the replace in c_var() breaks some struct accesses in the generate
Eric Blake writes:
> On 07/11/2014 08:42 AM, Markus Armbruster wrote:
>
Can anybody think of a use of c_var() that needs '.' preserved?
>>>
>>> Doing the replace in c_var() breaks some struct accesses in the generated
>>> code. I didn't look deeper to determine the users though.
>>
>> Feels
On 07/11/2014 08:42 AM, Markus Armbruster wrote:
>>> Can anybody think of a use of c_var() that needs '.' preserved?
>>
>> Doing the replace in c_var() breaks some struct accesses in the generated
>> code. I didn't look deeper to determine the users though.
>
> Feels like a misuse of c_var() to m
Luiz Capitulino writes:
> On Thu, 10 Jul 2014 16:31:38 +0200
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>>
>> > The event code generator barfs when it sees a dot in an event
>> > argument, this makes it impossible to support vendor extensions
>> > in event arguments as they always
On Thu, 10 Jul 2014 16:31:38 +0200
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > The event code generator barfs when it sees a dot in an event
> > argument, this makes it impossible to support vendor extensions
> > in event arguments as they always contain dots. Fix this by
> > repla
On 07/10/2014 08:31 AM, Markus Armbruster wrote:
> Luiz Capitulino writes:
>
>> The event code generator barfs when it sees a dot in an event
>> argument, this makes it impossible to support vendor extensions
>> in event arguments as they always contain dots. Fix this by
>> replacing dots by hyph
Luiz Capitulino writes:
> The event code generator barfs when it sees a dot in an event
> argument, this makes it impossible to support vendor extensions
> in event arguments as they always contain dots. Fix this by
> replacing dots by hyphens in the generated code.
Code replaces by underbar, no
The event code generator barfs when it sees a dot in an event
argument, this makes it impossible to support vendor extensions
in event arguments as they always contain dots. Fix this by
replacing dots by hyphens in the generated code.
PS: Event names and QMP command arguments may suffer from the
s
13 matches
Mail list logo
