[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: golang bindings dirty in tree after libxl build


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Fri, 12 Jun 2020 11:59:01 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "rosbrookn@xxxxxxxxx" <rosbrookn@xxxxxxxxx>
  • Delivery-date: Fri, 12 Jun 2020 11:59:23 +0000
  • Ironport-sdr: zidYHVXBfNDD4xFyXnV9hDXUTyeqAFkTwjc4nqf3H8qd+GvAa1eLSm+BOPcLfRMrK0rBN/zOQy 4NESGKO2UfRla7ORtdJ/1VCl4ul3UGL3/lYt3es2oqDzolv7W3YMdOro/Xmjs9vYH4m5fwtUxG zg729RRLXHek+zsM3FpCjCWtGG5SjC3chFh70XU+qDVqQ92y9UTvJdz67LZhdR+xgiOi/N0W8p qggoE6morBeehuvrkiXZaGh6OyVEQY2iuA5k1S+BinyQcjkTiJaU8LQlB6PALj9bGo/oBz+5WF mQw=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWQKioQYeQbI0+WE2BPJ46VizvQajUvuCA
  • Thread-topic: golang bindings dirty in tree after libxl build


> On Jun 12, 2020, at 12:00 PM, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.