[capnproto] 0.6.1 released

Hi all, I rolled up some bug fixes into a 0.6.1 release. These include: - Work-around GCC 4.9.2 bug that caused test case "Capability/DynamicServerPipelining" to segfault. The bug is fixed in GCC 4.9.4 but Debian Jessie is stuck at 4.9.2. The bug only affected the test. - Work around SFINAE bug

Re: [capnproto] Re: Making a Cap'n Proto Github organization

Hi Thomas, I've given you write access and given Anil admin access. Sorry, I'd assumed Anil already had admin. -Kenton On Wed, Jun 7, 2017 at 1:59 AM, Thomas Leonard wrote: > We've moved the OCaml repository to https://github.com/capnproto/c > apnp-ocaml but I can't commit

Re: [capnproto] Making a Cap'n Proto Github organization

OK, I've sent out invites and started populating the org. On Mon, Jun 5, 2017 at 8:48 AM, Ross Light wrote: > SGTM. For Go, I will need to hack my vanity URL resolver so that " > zombiezen.com/go/capnproto2" will resolve to the org repository before I > can do the move.

Re: [capnproto] RPC pipelining on a struct's union members

Hi Johannes, Thanks for the feedback. I'm curious: In your use case, does the caller somehow know in advance when getValue() is going to return an interface, thus allowing pipelining? If so, would it make sense to have a separate method, e.g. getInterface(), for that case, which just returns the

Re: [capnproto] Build Cap'n Proto failure with Clang 3.5

Hi LuckyBoy, It looks like your compiler is crashing, which is definitely a bug in the compiler, not in Cap'n Proto. Is this really an unmodified build of Clang 3.5? Are you targeting an unusual architecture, or is there anything else unusual about your compiler configuration? I tested 0.6.0

Re: [capnproto] build w/ yocto

On Fri, May 26, 2017 at 12:54 PM, Schwarz, Eric wrote: > Well, there exist different branches for Yocto which bring along different > versions of tools needed to build the stuff e.g. autotools. Obviously the > versions are not compatible as it is in the case of e.g. LaTeX

Re: [capnproto] build w/ yocto

Hi Eric, On Fri, May 26, 2017 at 11:37 AM, Schwarz, Eric wrote: > Hello Kenton, > > many thanks for the fast reply and check-in. - I will give it a try and > get back to you. > Three things are really near to my heart: > 1.) Please abstract the usage of commands >

Re: [capnproto] build w/ yocto

Hi Eric, I don't know why the behavior would differ on your system (maybe automake changed?), but I imagine this should fix it: https://github.com/sandstorm-io/capnproto/commit/5f20b5cc1032df29d830409433c7d7a0c71266e5 Let me know if that helps. -Kenton On Fri, May 26, 2017 at 3:08 AM,

Re: [capnproto] Build Cap'n Proto failure with Clang 3.5

Hi, Clang 3.5 should be OK. In the build log you gave, the "-std=gnu++1y" flag is not being passed to the compiler, which explains the errors that follow. One reason this could happen is if you are building from source and you are using an older version of libtool. libtool is known to drop

Re: [capnproto] Error reporting with async/push interfaces?

Ah. Two things: 1) If the stream is dropped without done() ever having been called, you know at least that the data is incomplete. 2) Usually, I would recommend that the method you call to say "write data to this stream" should not return until all data is written. get @0 (filename :Text,

Re: [capnproto] Error reporting with async/push interfaces?

Hi Ian, I'm not sure I understand. write() can throw an exception. Does that not solve the problem? -Kenton On Mon, May 22, 2017 at 5:01 PM, Ian Denhardt wrote: > Are there established best practices for handling errors that occur with > async/push style interfaces, such as

Re: [capnproto] Problems with 0.6.0 header files on Windows Visual Studio 2015

Another possible solution is to convert macros into proper symbols in the global scope. E.g. #ifdef VOID typedef VOID VOID_; #undef VOID typedef VOID_ VOID; #endif This approach then allows the application to use both the Windows VOID symbol and capnp::VOID without doing its own macro tricks.

Re: [capnproto] Ez Rpc deprecated import/exportCap

Hi Mark, There's currently no way to avoid the warnings except to disable them with pragmas or compiler flags. For example: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" // ... call importCap here ... #pragma GCC diagnostic pop I would like to remove

[capnproto] 0.6 release candidate!

Hi all, There's a release candidate! https://capnproto.org/capnproto-c++-0.6.0-rc1.tar.gz https://capnproto.org/capnproto-c++-win32-0.6.0-rc1.zip Please play with it and tell me what happens. Highlights: - *All* of Cap'n Proto now works on MSVC! That includes the dynamic library, RPC, schema

Re: [capnproto] Need help making pycapnp/capnproto work across python and extension boundaries

Hi, I think what you want here is for pycapnp to be extended with some API that other Python extensions can use to interact with it in order to wrap and unwrap builders. pycapnp builders are actually wrapping a capnp::DynamicStruct::Builder under the hood, which is easy to cast back and forth to

Re: [capnproto] Need help making pycapnp/capnproto work across python and extension boundaries

Hi, Since regionImpl is an AnyPointer, it doesn't have a direct setter. Instead, do: regionProto.getRegionImpl().setAs(_writePyRegion()); -Kenton On Tue, Apr 25, 2017 at 11:17 AM, wrote: > Hi Kenton, I thought I was almost there, but got stuck here: > > One of the

Re: [capnproto] capnp Readers and Builders: how to write what I've read

You don't need the `.getRoot()` on the last line. Do: builder.setRoot(pyRegionImplProto); -Kenton On Mon, Apr 24, 2017 at 5:50 PM, wrote: > Hi Kenton, I got into a pickle trying to convert a reader into a builder > in C++. The relevant code looks like this: > > ```

[capnproto] Cap'n Proto security advisory CVE-2017-7892

Hi all, (This was announced in various places early Monday but I forgot to send it here -- doh!) I discovered a vulnerability in Cap'n Proto C++. It appears to affect only 32-bit builds, seemingly only when built with Apple's compiler, and I think it's only a DoS -- but my analysis could be

Re: [capnproto] Detecting broken message and recovering from it

Hi Stepan, No, there's no easy way to detect the corruption your describe. In fact, for most serialization formats, there's no solution to this problem. Once you've lost track of message boundaries, it's impossible to tell the difference between the start of a new message vs. data in the previous

Re: [capnproto] Re: Can not build capnp from master. Linking error.

(Ugh the Google Groups web interface apparently doesn't know how to CC the right people.) On Wed, Apr 12, 2017 at 8:30 PM, kenton via Cap'n Proto < capnproto@googlegroups.com> wrote: > Hi Iryna, > > I am not able to reproduce this failure, BUT I did find an error in the > Makefile which looks

<    1   2   3   4   5