golang bindings dirty in tree after libxl build

golang bindings dirty in tree after libxl build

[Andrew Cooper]

Hello,

I've just done a libxl build and got things such as:

--- a/tools/golang/xenlight/helpers.gen.go
+++ b/tools/golang/xenlight/helpers.gen.go
@@ -431,14 +431,14 @@ x.Evtch = int(xc.evtch)
 x.Rref = int(xc.rref)
 x.Connection = ChannelConnection(xc.connection)
 switch x.Connection{
-case ChannelConnectionUnknown:
-x.ConnectionUnion = nil
 case ChannelConnectionPty:
 var connectionPty ChannelinfoConnectionUnionPty
 if err := connectionPty.fromC(xc);err != nil {
  return fmt.Errorf("converting field connectionPty: %v", err)
 }
 x.ConnectionUnion = connectionPty
+case ChannelConnectionUnknown:
+x.ConnectionUnion = nil
 case ChannelConnectionSocket:
 x.ConnectionUnion = nil
 default:

dirty in tree.  They are all case labels, and only their order in the
switch has changed.

Does the current binding generation rely on the order of entries in a
python dictionary by any chance?

~Andrew

Re: golang bindings dirty in tree after libxl build

[George Dunlap]

> On Jun 12, 2020, at 12:00 PM, Andrew Cooper <Andrew.Cooper3@citrix.com> wrote:
> 
> Hello,
> 
> I've just done a libxl build and got things such as:
> 
> --- a/tools/golang/xenlight/helpers.gen.go
> +++ b/tools/golang/xenlight/helpers.gen.go
> @@ -431,14 +431,14 @@ x.Evtch = int(xc.evtch)
>  x.Rref = int(xc.rref)
>  x.Connection = ChannelConnection(xc.connection)
>  switch x.Connection{
> -case ChannelConnectionUnknown:
> -x.ConnectionUnion = nil
>  case ChannelConnectionPty:
>  var connectionPty ChannelinfoConnectionUnionPty
>  if err := connectionPty.fromC(xc);err != nil {
>   return fmt.Errorf("converting field connectionPty: %v", err)
>  }
>  x.ConnectionUnion = connectionPty
> +case ChannelConnectionUnknown:
> +x.ConnectionUnion = nil
>  case ChannelConnectionSocket:
>  x.ConnectionUnion = nil
>  default:
> 
> dirty in tree.  They are all case labels, and only their order in the
> switch has changed.
> 
> Does the current binding generation rely on the order of entries in a
> python dictionary by any chance?

Not explicitly, but obviously somewhat implicitly.

Is this a python2/3 issue, or would different versions of python within 2/3 end up with different sort orders?

If python3 will always put them in the same order, then we might consider just switching the script to being explicitly python3.  Otherwise, we’ll probably have to add sorts.

 -George

Re: golang bindings dirty in tree after libxl build

[Andrew Cooper]

On 12/06/2020 12:59, George Dunlap wrote:
>
>> On Jun 12, 2020, at 12:00 PM, Andrew Cooper <Andrew.Cooper3@citrix.com> wrote:
>>
>> Hello,
>>
>> I've just done a libxl build and got things such as:
>>
>> --- a/tools/golang/xenlight/helpers.gen.go
>> +++ b/tools/golang/xenlight/helpers.gen.go
>> @@ -431,14 +431,14 @@ x.Evtch = int(xc.evtch)
>>  x.Rref = int(xc.rref)
>>  x.Connection = ChannelConnection(xc.connection)
>>  switch x.Connection{
>> -case ChannelConnectionUnknown:
>> -x.ConnectionUnion = nil
>>  case ChannelConnectionPty:
>>  var connectionPty ChannelinfoConnectionUnionPty
>>  if err := connectionPty.fromC(xc);err != nil {
>>   return fmt.Errorf("converting field connectionPty: %v", err)
>>  }
>>  x.ConnectionUnion = connectionPty
>> +case ChannelConnectionUnknown:
>> +x.ConnectionUnion = nil
>>  case ChannelConnectionSocket:
>>  x.ConnectionUnion = nil
>>  default:
>>
>> dirty in tree.  They are all case labels, and only their order in the
>> switch has changed.
>>
>> Does the current binding generation rely on the order of entries in a
>> python dictionary by any chance?
> Not explicitly, but obviously somewhat implicitly.
>
> Is this a python2/3 issue, or would different versions of python within 2/3 end up with different sort orders?
>
> If python3 will always put them in the same order, then we might consider just switching the script to being explicitly python3.  Otherwise, we’ll probably have to add sorts.

Python 3.6 now guarantees that the insert order of elements will be
preserved.  Before that, there are no guarantees at all.

It sounds like some sprinkling of sorted() will be needed.

~Andrew

Re: golang bindings dirty in tree after libxl build

[Nick Rosbrook]

On Fri, Jun 12, 2020 at 8:15 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 12/06/2020 12:59, George Dunlap wrote:
> >
> >> On Jun 12, 2020, at 12:00 PM, Andrew Cooper <Andrew.Cooper3@citrix.com> wrote:
> >>
> >> Hello,
> >>
> >> I've just done a libxl build and got things such as:
> >>
> >> --- a/tools/golang/xenlight/helpers.gen.go
> >> +++ b/tools/golang/xenlight/helpers.gen.go
> >> @@ -431,14 +431,14 @@ x.Evtch = int(xc.evtch)
> >>  x.Rref = int(xc.rref)
> >>  x.Connection = ChannelConnection(xc.connection)
> >>  switch x.Connection{
> >> -case ChannelConnectionUnknown:
> >> -x.ConnectionUnion = nil
> >>  case ChannelConnectionPty:
> >>  var connectionPty ChannelinfoConnectionUnionPty
> >>  if err := connectionPty.fromC(xc);err != nil {
> >>   return fmt.Errorf("converting field connectionPty: %v", err)
> >>  }
> >>  x.ConnectionUnion = connectionPty
> >> +case ChannelConnectionUnknown:
> >> +x.ConnectionUnion = nil
> >>  case ChannelConnectionSocket:
> >>  x.ConnectionUnion = nil
> >>  default:
> >>
> >> dirty in tree.  They are all case labels, and only their order in the
> >> switch has changed.
> >>
> >> Does the current binding generation rely on the order of entries in a
> >> python dictionary by any chance?
> > Not explicitly, but obviously somewhat implicitly.
> >
> > Is this a python2/3 issue, or would different versions of python within 2/3 end up with different sort orders?
> >
> > If python3 will always put them in the same order, then we might consider just switching the script to being explicitly python3.  Otherwise, we’ll probably have to add sorts.
>
> Python 3.6 now guarantees that the insert order of elements will be
> preserved.  Before that, there are no guarantees at all.
>
> It sounds like some sprinkling of sorted() will be needed.

George,

Unless you have a burning desire, I can take care of this patch today
or tomorrow.

-NR