Okay, found the problem. It turns out the tarball version is quite old (> 2 years as far as I can tell) so when I let pycapnp build the c++ code itself it uses a version that doesn't have DynamicStruct::Reader::as<AnyStruct>. When I get the c++ code from git and install it myself it's there. So that was an easier fix than I expected :)
Thanks a lot for the help! c On Mon, Feb 20, 2017 at 10:17 AM, Christian Plesner Hansen < [email protected]> wrote: > Thanks for the quick response! > > I'll play around with it some more to see exactly why it worked before but > doesn't anymore. I'm doing this through pycapnp which has its own way of > getting the c++ library so there could be something going on there. > > > c > > On Mon, Feb 20, 2017 at 10:11 AM, Kenton Varda <[email protected]> > wrote: > >> Hi Christian, >> >> If we've written the code right, both of the following should work: >> - Implicitly converting DynamicStruct::Reader (or, indeed, T::Reader for >> any struct type T) to AnyStruct::Reader. >> - Calling dynamicStructReader.as<AnyStruct>(). >> >> If one or both of these doesn't work, it's a bug. >> >> Is it possible that when you switched machines, you also switched >> versions of Cap'n Proto? This may be something we fixed somewhere along the >> way. I think AnyStruct only exists in git (not in 0.5.x), but maybe your >> machines are at different git revisions... >> >> -Kenton >> >> On Mon, Feb 20, 2017 at 1:01 AM, Christian Plesner Hansen < >> [email protected]> wrote: >> >>> Thanks for the suggestion. I'm having a little trouble applying it in >>> practice though -- it may just that I'm having trouble navigating the api. >>> >>> Is the relevant AnyStruct::Reader constructor I'll want to call >>> Reader(_::StructReader reader)? A DynamicStruct::Reader (which is what I >>> have) does have a _::StructReader field but I can't see any way to get >>> access to it. It also has an as<> method which, if I could call is as >>> as<AnyStruct> would do exactly what I want but that triggers a static >>> assertion because kind<AnyStruct>() is Kind.OTHER, not Kind.STRUCT. >>> >>> I did actually manage to implement the scheme I had in mind using >>> as<AnyStruct> and it worked just as expected -- but the code broke when I >>> tried to compile it on a different machine. I must have been using a >>> compiler that didn't check static_asserts initially. So I hope there's a >>> way to work around the problem. >>> >>> >>> c >>> >>> On Fri, Feb 17, 2017 at 11:03 PM, Kenton Varda <[email protected]> >>> wrote: >>> >>>> Hi Christian, >>>> >>>> One way to do this: >>>> >>>> capnp::AnyStruct::Reader(myStructReader).getDataSection() >>>> >>>> This will return a kj::ArrayPtr<const byte> that points at the "data >>>> section" of the struct, which contains the non-pointer fields. .begin() >>>> gives you a direct pointer to the first byte. The data section comes before >>>> the pointer section, so this is essentially a pointer to the start of the >>>> struct. >>>> >>>> -Kenton >>>> >>>> On Fri, Feb 17, 2017 at 12:19 AM, <[email protected]> wrote: >>>> >>>>> Hi, >>>>> I've been looking at the reflection api for a way to inspect the >>>>> layout of the encoded data. Specifically what I've been looking for is a >>>>> reliable way to find the word-offset of the beginning of a given struct. >>>>> Is >>>>> there a way to do that? >>>>> >>>>> For context, the reason I need it is that I need to keep some >>>>> proto-encoded data up to date with small changes that come in >>>>> occasionally. >>>>> So I need a mechanism for representing just the deltas between two >>>>> versions >>>>> of a proto, and ideally a really simple way that works just on the binary >>>>> encoded data. The data is mainly flat lists of structs. A simple approach >>>>> I >>>>> wanted to try was to simply xor the entire before- and after- binaries and >>>>> then zipping the result. Before and after will be very similar so the xor >>>>> should be mostly 0 and so zipping should shrink it down to hardly >>>>> anything. >>>>> Except there's a hitch: if just one of the structs changes size the other >>>>> elements will shift around and not line up, and xor'ing won't cancel them >>>>> out. But if I could determine where in the binary each element starts I >>>>> can >>>>> line corresponding elements up by 0-padding (which would be removed again >>>>> when applying the update) and then the scheme should work. >>>>> >>>>> >>>>> c >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Cap'n Proto" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/capnproto. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "Cap'n Proto" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>>> pic/capnproto/2aPc1--JQtM/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> Visit this group at https://groups.google.com/group/capnproto. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Cap'n Proto" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> Visit this group at https://groups.google.com/group/capnproto. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Cap'n Proto" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/capnproto/2aPc1--JQtM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> Visit this group at https://groups.google.com/group/capnproto. >> > > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
