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

e other maintainers, it will be much easier to do so with >> the repos under an organization. >> >> I've gone ahead and created the org here: >> https://github.com/capnproto >> >> I propose that the following repositories be moved into the org: >

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

Reply inline. On Mon, Jun 5, 2017 at 10:02 AM Kenton Varda wrote: > 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

Re: [capnproto] What happens on kj::joinPromises failure?

It's worth noting that Go's errgroup package, which fulfills a similar need, will block until all tasks have completed, then return the first error. The trick is that once the first error is found, the rest of the remaining tasks ought to be cancelled

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

>>> people to find all the code in one place. And if a maintainer wants to step >>> down or designate other maintainers, it will be much easier to do so with >>> the repos under an organization. >>> >>> I've gone ahead and created the org here: >&g

Re: [capnproto] [Java] Failing to read multiple messages from a single file

Yeah, I remember hitting that bug in the Go implementation. I feel like the security implications docs should also mention limits on number of segments, since I can't imagine a case where you would use the full 2^32 space. On Mon, Jul 10, 2017, 6:15 PM David Renshaw wrote: > It looks like there'

Re: [capnproto] [Java] Failing to read multiple messages from a single file

I'll mention too: the way I discovered this crash was when an HTTP client connected to a Cap'n Proto RPC port. The "GET " string now triggers the segment limit. On Mon, Jul 10, 2017, 6:18 PM Ross Light wrote: > Yeah, I remember hitting that bug in the Go implementa

Re: [capnproto] Some questions about the RPC spec

Replies inline (with the disclaimer that I'm not Kenton, my only credentials are that I have stared at this file for a long time): On Wed, Jul 19, 2017 at 1:46 PM Thomas Leonard wrote: > Hi, > > I'm trying to write an implementation of the RPC spec (level 1, in OCaml). > I found a few parts of t

Re: [capnproto] Some questions about the RPC spec

bly result in an update of the spec file. Searching mailing > list history is great but... oh wait never mind searching mailing list > history is terrible :-) > > On Wed, Jul 19, 2017 at 2:57 PM, Ross Light wrote: > >> Replies inline (with the disclaimer that I'm not Kent

Re: [capnproto] Some questions about the RPC spec

h some of those implications now, but I'll start a separate thread. On Wed, Jul 19, 2017 at 9:19 PM Kenton Varda wrote: > On Wed, Jul 19, 2017 at 2:57 PM, Ross Light wrote: > >> Replies inline (with the disclaimer that I'm not Kenton, my only >> credentials are that

[capnproto] Concurrency model in RPC protocol

So in this old thread , it's stated that the "call is received" event requires calling into application code. From an implementation standpoint, this is declaring that receiving a call in the RPC system is a critical section that

Re: [capnproto] Concurrency model in RPC protocol

make the Go capabilities act serially to preserve E-Order. It could be provided in an opt-out manner, but I'm not even sure how I would write code that avoids the recursive mutex lock problem. I'm open to other ideas on how to solve this. Thanks for the read, -Ross On Thu, Jul 20, 2

Re: [capnproto] Concurrency model in RPC protocol

Correct. There's no happens-before relationship between goroutines without an explicit synchronization point. I have been thinking about this more, and I think I have a solution. Instead of making the call to the capability directly in the critical section, the connection could have a goroutine th

Re: [capnproto] Concurrency model in RPC protocol

Replies inline. On Mon, Jul 24, 2017 at 10:52 AM Kenton Varda wrote: > On Fri, Jul 21, 2017 at 1:52 PM, Ross Light wrote: > >> (Sorry for the long response. I did not have time to make it shorter.) >> >> I see your point about how "a call returns happens b

[capnproto] Why is List(AnyPointer) not supported?

Hopefully a straightforward question: why does `capnp compile` have a special case to error out on List(AnyPointer) and variants thereof? I don't have a bu

Re: [capnproto] Why is List(AnyPointer) not supported?

supporting lists of any type, as long > as all the elements are the same type. > > -Kenton > > On Sat, Aug 26, 2017 at 8:31 PM, Ross Light wrote: > >> Hopefully a straightforward question: why does `capnp compile` have a >> special case to error out >> <https:

Re: [capnproto] Concurrency model in RPC protocol

One thing I'm currently curious about in the C++ implementation: does the RPC system provide any backpressure for sending calls to the remote vat? AFAICT there's no bound on the EventLoop queue. On Wed, Jul 26, 2017 at 10:38 AM Kenton Varda wrote: > On Wed, Jul 26, 2017 at 9:16 AM

Re: [capnproto] Implementing Level-3 Protocol (in Go)

I'm available next Friday (Oct 2) from 1p PT onward. On Friday, September 25, 2020 at 7:36:07 AM UTC-7 lthibault wrote: > Sounds good to me — looking forward to it. > > - Louis > > > On Sep 24, 2020, at 17:17, Ian Denhardt wrote: > > > > I just opened an issue: > > > > https://github.com/capnp

[capnproto] Weird constant edge case

Not that this has practical use, but I noticed a weird edge case with constants, unions, and default values: @0xf5c9d5529d822584; struct Foo { union { first @0 :Void; second @1 :Text = "mydefault"; } } // Now I want to construct Foo with the discriminant set to second, but using th

[capnproto] Go Now Supports Converting To and From Plain Structs

Hello Cap'n Proto users! If you're using go-capnproto2 , there's a new subpackage: pogs (Plain Ol' Go Structs). It exposes two easy-to-use functions that convert Cap'n Proto structs to and from plain Go structs using reflection. This means that you can

Re: [capnproto] Re: Working on Swift support

Just pointer fields. Data section fields are always "non-optional". On Tue, Sep 20, 2016, 6:48 PM Dan Appel wrote: > Does this mean that every field (including lists) is nullable? That's > quite a shame. Looks like all my generated fields are going to be > implicitly-unwrapped-optional, then (re

Re: [capnproto] pycapnp

I'm not sure about b), but a) is a known issue: #363 On Fri, Dec 16, 2016 at 6:36 AM Andreas Stenius wrote: > Hi, > > Been working with pycapnp a while now. And when it works, it is really > nice, but when I make a mistake, it can be a bit h

Re: [capnproto] Is Cap'n Proto appropriate for large amounts of tabular data?

You may want to look in https://capnproto.org/encoding.html for low-level details, but if you represent each "row" as a struct, then most of the efficiency gains you describe happen without much effort. Booleans are lumped together as bits, lists can be tightly packed, and you can mmap the file fo

[capnproto] File extension for binary Cap'n Proto data?

This is an entirely pedantic question, but what extension do/should folks use for serialized Cap'n Proto files on disk? -Ross -- 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

Re: [capnproto] File extension for binary Cap'n Proto data?

ile. I don't think > it's particularly useful to give a file an extension that indicates "Cap'n > Proto encoding" without also indicating the specific type. (I have the same > opinion about Protocol Buffers.) > > -Kenton > > On Sat, Feb 25, 2017 at 9:03 AM,

Re: [capnproto] Proto3 removed field presence detection, has CapNProto done the same?

https://capnproto.org/faq.html#how-do-i-make-a-field-optional On Thu, Mar 9, 2017, 4:01 AM wrote: > I couldn't find an explicit mention of this on the website, curious if > CapNProto has also removed field presence detection - it's a really useful > feature to have! > > -- > You received this me

Re: [capnproto] Proto3 removed field presence detection, has CapNProto done the same?

Correct. In this respect, Cap'n Proto is very close to proto3 semantics. On Thu, Mar 9, 2017 at 10:08 AM Sam Duke wrote: > Looks like there's no hasX methods for scalars? > > On Thu, 9 Mar 2017, 15:57 Ross Light, wrote: > > https://capnproto.org/faq.html#how-do-i-mak

Re: [capnproto] Proto3 removed field presence detection, has CapNProto done the same?

Is it for less space on the wire? > Field presence seems an excellent way to guard against regression as protos > evolve. > > On Thu, 9 Mar 2017, 18:20 Ross Light, wrote: > > Correct. In this respect, Cap'n Proto is very close to proto3 semantics. > > On Thu, Mar 9,

Re: [capnproto] Proto3 removed field presence detection, has CapNProto done the same?

nitions of messages hard to > read. It suppose some syntactic sugar around this might be useful :/ > > Thanks for your prompt replies and help BTW. And sorry for my poor reading > of your docs :) > > On Thu, 9 Mar 2017 at 19:15 Ross Light wrote: > > Quite the opposite: it&#

Re: [capnproto] Re: Reviving the JavaScript implementation

I have had somebody use GopherJS to read data client side. It works, but I can't vouch for how well. What parts are you having difficulty with representing in JS? Are you still on serialization or the RPC part? I found that for Go I would look at the C++ implementation to get the spirit of a featu