Hi George,
> Just going through in detail, I notice one thing about your
> implementation of Defbool: you simply copy over the value of
> libxl_defbool. The header says of libxl_defbool:
>
> * Users should treat this struct as opaque and use the following
> * defined macros and accessor
On 9/24/19 1:33 AM, Nicholas Rosbrook wrote:
> Hi George,
>
> I made the changes that we discussed WRT C to Go type marshaling. See [1] for
> generated code.
>
> In addition, I took a pass at implementing Go to C type marshaling. The
> generated toC functions are also in [1].
>
> Finally, I
Hi George,
I made the changes that we discussed WRT C to Go type marshaling. See [1] for
generated code.
In addition, I took a pass at implementing Go to C type marshaling. The
generated toC functions are also in [1].
Finally, I made the necessary changes[2] to the existing xenlight.go so
> FWIW checked with Ian after I wrote this mail, and he confirmed that
> that field (`link` in `libxl_event`) was only meant to be used
> internally, and ideally we wouldn't even have that available in the Go
> version of the struct (since it's not actually part of the public
> interface).
>
>
On 9/12/19 6:35 PM, Nicholas Rosbrook wrote:
> I'm not strongly opposed to the struct duplication, but I do prefer the
> ability
> to perform type assertions as a way to determine which field is "valid."
Fair enough.
>> So the advantage of this is that you can just call:
>>
>> fromC(, )
>>
> That looks about like we expected -- tolerable and functional, to be
> certain, but LotsOfReallyLongTypeNames.
Yeah that's definitely a down side...
> The only purpose of unions in these structures is to save space (as
> opposed to other kinds of unions are specifically designed to allow
>
On 9/11/19 9:25 PM, Nicholas Rosbrook wrote:
> Hi George,
>
> I made some more progress on gengotypes.py [1].
[snip]
> What are your thoughts on these implementations so far?
Great! Overall it looks like it's really making progress, which is
exciting.
> First, I implemented the KeyedUnion
Hi George,
I made some more progress on gengotypes.py [1].
First, I implemented the KeyedUnion translation that we talked about.
You can see an example of the generated code in [2].
Second, I took a first pass at the C-to-Go type marshaling. I defined a
"marshaler" interface in [3], which
> Unfortunately this would mean the type assertion would be pretty long as
> well:
> hvm := di.TypeUnion.(xenlight.DomainBuildInfoTypeUnionHvm)
> hvm.[element]
Made worse by the fact that you really should check the type assertion first:
hvm, ok :=
> Yes, I think that's really the only option. Poking around, it looks
> like a lot of different people have recommended it; and the fact that
> it's in use by gRPC means it can't be too terrible a solution.
Yeah, having worked with generated gRPC code I don't think it's too bad.
> The interface
On 9/4/19 5:52 PM, George Dunlap wrote:
> On 9/4/19 1:36 AM, Nicholas Rosbrook wrote:
>> George,
>>
>>> Are you up for taking a stab at something like `gengotypes.py`?
>>
>> I have was able to make a bit of progress on this over the weekend. I've
>> started
>> `gengotypes.py` in my branch[1]; the
On 9/4/19 1:36 AM, Nicholas Rosbrook wrote:
> George,
>
>> Are you up for taking a stab at something like `gengotypes.py`?
>
> I have was able to make a bit of progress on this over the weekend. I've
> started
> `gengotypes.py` in my branch[1]; the portion which generates
> `xenlight_types.go`
George,
> Are you up for taking a stab at something like `gengotypes.py`?
I have was able to make a bit of progress on this over the weekend. I've started
`gengotypes.py` in my branch[1]; the portion which generates `xenlight_types.go`
(the counterpart to _libxl_types.h) is mostly working.
The
> IOW, in response to GP, I was going to counter-suggest what you suggest
> in this email. :-)
>
> Are you up for taking a stab at something like `gengotypes.py`?
Yes, I think I can handle that.
-NR
___
Xen-devel mailing list
On 7/31/19 10:22 PM, Nicholas Rosbrook wrote:
>> I looked at the thing about naked returns, and didn't really understand
>> it; but anyway I'm happy to have things modified to be more Go-like. I
>> definitely "speak" Go with a funny accent.
>
> TL;DR: Naked returns exist; don't use them (with
On 8/1/19 7:59 PM, Nicholas Rosbrook wrote:
>> With that said, what are your expectations for the generated Go code at this
>> point?
>> Do you think we should try to generate the pieces that call into libxl? Or,
>> do you think
>> the code generation should be limited to the structs and
> With that said, what are your expectations for the generated Go code at this
> point?
> Do you think we should try to generate the pieces that call into libxl? Or,
> do you think
> the code generation should be limited to the structs and boiler-plate C <->
> Go "type
> marshaling?"
[...]
>
> I return to the question I stated before. At the moment, your bindings
> have the following call chain:
>
> * DomainInfo(), hand-crafted. Calls domainInfo().
> * domainInfo(), automaticall generated. Calls C.libxl_domain_info().
>
> The in-tree bindings have the following call chain:
>
> *
On 7/30/19 7:39 PM, Tamas K Lengyel wrote:
> On Tue, Jul 30, 2019 at 9:49 AM George Dunlap
> wrote:
>>
>> On 7/30/19 2:48 PM, Tamas K Lengyel wrote:
>>> On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
>>> wrote:
Hello,
As a follow up to the presentation that Brendan
On 7/30/19 10:52 PM, Nicholas Rosbrook wrote:
>> All that said, the first question I think is, what the generated code
>> needs to look like. Then, if c-for-go can be configured to do that,
>> then we can consider it; otherwise, making our own generator from the
>> IDL will be the only option.
>
> All that said, the first question I think is, what the generated code
> needs to look like. Then, if c-for-go can be configured to do that,
> then we can consider it; otherwise, making our own generator from the
> IDL will be the only option.
Writing a custom Go code generator means that all C
On Tue, Jul 30, 2019 at 9:49 AM George Dunlap wrote:
>
> On 7/30/19 2:48 PM, Tamas K Lengyel wrote:
> > On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
> > wrote:
> >>
> >> Hello,
> >>
> >> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> >> summit earlier this
On 7/30/19 2:11 PM, Nicholas Rosbrook wrote:
> Hello,
>
> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> summit earlier this month, "Client Virtualization Toolstack in Go", I would
> like to open
> a discussion around the development of Go bindings for libxl. George
On 7/30/19 2:48 PM, Tamas K Lengyel wrote:
> On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
> wrote:
>>
>> Hello,
>>
>> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
>> summit earlier this month, "Client Virtualization Toolstack in Go", I would
>> like to open
>>
On 7/30/19 2:11 PM, Nicholas Rosbrook wrote:
> Hello,
>
> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> summit earlier this month, "Client Virtualization Toolstack in Go", I would
> like to open
> a discussion around the development of Go bindings for libxl. George
On Tue, Jul 30, 2019 at 7:32 AM Nicholas Rosbrook
wrote:
>
> Hello,
>
> As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
> summit earlier this month, "Client Virtualization Toolstack in Go", I would
> like to open
> a discussion around the development of Go bindings for
Hello,
As a follow up to the presentation that Brendan Kerrigan and I gave at Xen
summit earlier this month, "Client Virtualization Toolstack in Go", I would
like to open
a discussion around the development of Go bindings for libxl. George Dunlap,
Nicolas Belouin and I have had some discussion
27 matches
Mail list logo
