Hi Vaci,
`anyReader.as(structSchema)` should do it.
-Kenton
On Tue, Nov 30, 2021 at 2:54 PM Vaci wrote:
> Apologies if there is an obvious answer, but f I have a
> capnp::StructSchema, and a capnp::AnyStruct::Reader, then can I create a
> capnp::DynamicStruct::Reader from them, and if so,
It sounds like what Go is providing today would be equivalent to a KJ API
that returns two promises: once which waits for backpressure, and one which
waits for the RPC return value. In principle, we could provide a new
version of `send()` in C++ which provides this. But if it only recognizes
On Tue, Nov 23, 2021 at 5:01 PM Ian Denhardt wrote:
> Ok, I think I get it, let me know if I have this right:
>
> The correct thing to do is to handle congestion/flow control for
> multiple calls on each object individually, using something like
> the mechanisms provided by the C++
On Tue, Nov 23, 2021 at 3:59 PM Ian Denhardt wrote:
> What are apps *supposed* to do here? It isn't clear to me where else the
> backpressure is supposed to come from?
>
Apps should cap the number of write()s they have in-flight at once. (`->
stream` helps a lot with this, as it'll
On Tue, Nov 23, 2021 at 12:41 PM Ian Denhardt wrote:
> Wouldn't releasing it on return allow the caller to cause runaway memory
> usage by just never sending the finish? the return entry needs to be kept
> around in case calls are pipelined on it, and itself might take up some
> space (arguably
Hmm, I think the intention was that the flow limit should be released on
Return, independent of Finish. But I can totally believe I implemented it
wrong. Could we just change it to be based on Return?
FWIW by default there is no flow limit, it's only enabled in the Sandstorm
supervisor to defend
Hi Mitsuo,
I recommend designing the interface like this:
interface EventPublisher{
interface Subscriber {
updateEvent @0 (event: Int32) -> ();
}
interface Subscription {}
subscribe @0 (subscriber: Subscriber) -> (result: Int32, subscription:
Subscription);
# To
No, there's no fundamental limitation here. I think we just need an
overload of `clone()` for this that accounts for the subtle API differences
with `DynamicStruct`, e.g. passing the `Schema` in various places.
-Kenton
On Thu, Nov 18, 2021 at 6:31 AM Vaci wrote:
> Hi,
>
> Should it be possible
Once the capnp subproject build is done, you should be able to invoke the
`capnp` compiler straight from the subproject location. I think you'd have
to write a raw make rule that invokes the compiler. You can see how Cap'n
Proto's own build does this here:
It should work as a subpackage. See:
https://www.gnu.org/software/automake/manual/html_node/Subpackages.html
-Kenton
On Thu, Oct 21, 2021 at 12:45 PM SR D <
software.research.developm...@gmail.com> wrote:
> I would like to make use of capnproto in an autotools project and
> wondering if anyone
Hi Leon,
Abstractly, what you describe should be easy with Cap'n Proto. One client
can send a capability (interface reference) to the server, and the server
can freely send that capability on to some other client. Cap'n Proto will
automatically arrange to proxy messages from one client to the
Hi folks,
I just put up release 0.9.1 which fixes a number of small platform-specific
build issues that were present in 0.9.0.
If you had any compile issues with 0.9.0, hopefully they are fixed now.
Also, FreeBSD and OpenBSD should work! (Thanks @sobomax and @ZhanYF.)
-Kenton
--
You received
Hi all,
Release candidate out. Please let me know if you spot any problems. (But
our CI is pretty thorough these days so it seems unlikely.)
https://capnproto.org/capnproto-c++-0.9.0-rc1.tar.gz
https://capnproto.org/capnproto-c++-win32-0.9.0-rc1.zip
-Kenton
--
You received this message
I think this could be implemented as a regular old code generator plugin
that directly produces the deps files. No need to integrate with the C++
plugin nor output an intermediate representation.
Note that `capnp compile` supports passing multiple `-o` flags to run
multiple plugins, so you can
Hi Alessandro,
KJ doesn't currently have any built-in thread pool implementation. The KJ
async / Promise framework is centered around single-threaded event loops,
so probably isn't what you're looking for.
I guess if I were implementing this I'd write a class that creates threads
using
Cool stuff!
The C++ implementation has test.capnp that should cover everything, but is
pretty messy, having evolved slowly together with the C++ implementation.
Definitely nice to have a separate test repository that is clean and really
meant to be consumed by multiple implementations.
-Kenton
Sorry, I'm not sure what you mean. `myns::Person` isn't a real type, it's
just an empty class that acts as a namespace containing the `Reader` and
`Builder` types. `Reader` is your "handle to the data", and its getters are
the only way to read the underlying data (the getters read directly from
There is no way to find out a message's type if you don't know it already.
So, you'll need to arrange to communicate the type yourself. The easiest
way is to write an "envelope" message that is a union of all your other
messages.
struct OuterMessage {
union {
foo @0 :FooMessage;
bar @1
Ideally, you'd update the implementation of `getBuff()` so that it
allocates an aligned buffer. Note that malloc() always returns aligned
buffers, so if you can make it so that the pointer returned by getBuff() is
one that was allocated directly by malloc(), then it should work. Probably,
though,
Hi Kenny,
Avoiding malloc should be easy. With custom subclasses of MessageReader and
MessageBuilder, you can do your memory management any way you want. Cap'n
Proto's serialization layer is very good about avoiding memory allocation
unless you ask for it.
(The RPC layer, on the other hand, does
Hi Kenny,
The code is fairly modular, so I think it should be possible to pull out a
subset that has a reasonably small code footprint. However, this is
admittedly not a well-traveled path, so you'll be a bit on your own. The
maintainers of the C++ implementation (such as myself) mainly use it on
Yes, I agree there's some missing overview docs regarding Cap'n Proto RPC.
The web page is not very detailed.
FWIW, I recently wrote an overview/tour of KJ:
https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md
But that doesn't cover Cap'n Proto itself.
> If I use the setupAsyncIo
Hi Björn,
Instead of Ez RPC, try using kj::setupAsyncIo() and capnp::TwoPartyClient /
capnp::TwoPartyServer. These APIs give you more control. In particular,
kj::setupAsyncIo() returns an kj::AsyncIoProvider which, among other
things, provides a kj::Timer API which you can use for timeouts.
KJ's
I see. There isn't a great API for this right now. The problem is, once a
struct Builder is already allocated, the struct can't be resized. But if
you're trying to copy the content of another struct into it, it's possible
that other struct was originally created with a newer version of the schema
Hi Vaci,
An RPC request is always a struct type, not a list, so I assume what you
really mean here is that you want to use the list as a field of the
request? E.g. you have:
struct Foo {}
interface Bar {
foo @0 (foos :List(Foo));
}
Then you would do:
auto req = bar.fooRequest();
auto
Hi Kyle,
I think you need to convert `capnp_path` back into a string before passing
it to `capnp.load()`. Currently it appears you are passing a `Path` object
that you constructed using pathlib, but `capnp.load` doesn't know how to
deal with those, it wants a plain string.
-Kenton
On Tue, Jun
Hi Pratik,
When you run the Cap'n Proto code generator, it produces two files: a
header (ending in `.capnp.h`) and a source file (ending in `.capnp.c++`).
Did you make sure to compile the source file into your project?
I'm guessing the missing symbol is from there, since it seems to be
Hi Pepijn,
Yeah, forking won't work well. I don't recommend that. One problem is that
if you fork() with an event loop running, both the parent and child
processes will end up with the same epoll FD and so will receive each
other's events, which will likely lead to chaos.
So I recommend spawning
The tables are used to support the "schema" and "dynamic" APIs (aka
"reflection"). These APIs are useful for a bunch of things, and in
particular they are used to implement text stringification of messages
(e.g. for debugging) and JSON conversion.
I think some code is also generated in the .c++
I would say that when you are distributing a precompiled binary copy of
your library, you should distribute the `.capnp.h` header along with it, if
you want programs using your library to be able to use that type. Those
programs will need to link against the exact version of the schema that you
You need your `SubscriberImpl` to hold a regular C++ pointer back to the
`MediaLibraryImpl` that created it, so that you can access its
`publishers_` set through that pointer. You can pass the pointer to
`SubscriberImpl`'s constructor.
You'll also want to make sure the pointer doesn't become a
Hi Théophile,
Take a look at CapabilityServerSet:
https://github.com/capnproto/capnproto/blob/6b5bcc2c6e954bc6e167ac581eb628e5a462a469/c++/src/capnp/capability.h#L607-L633
When you convert your `Server` object to a `Client`, you need to do it
using a CapabilityServerSet. Later, you can use the
Hi Brando,
It's hard for us to guess what might be the problem without seeing more
code.
-Kenton
On Tue, Mar 30, 2021 at 12:56 PM Brando Miranda
wrote:
> Hi,
>
> I am doing machine learning with captain proto (because captain proto is
> good at communicating between python and different
FWIW someone (not me) wrote this plugin to generate POCS:
https://github.com/nickolasrossi/podgen
I haven't used it nor carefully reviewed it yet, but based on the readme it
looks pretty thorough. Note it uses std types rather than KJ types which
may or may not be to your liking.
-Kenton
On
Hi Topher,
Unfortunately, Cap'n Proto is not well suited to representing mutable data
structures in-memory. Generally, MessageReaders are read-only, and
MessageBuilders are write-only. While technically you can modify builders
over time, the memory allocation patterns this tends to lead to are
On Thu, Mar 25, 2021 at 11:38 AM pepij...@gmail.com
wrote:
>
> Hey,
>
> Another one of these things that's probably good design but somewhat
> puzzling.
> How do I obtain a timer in my RPC server?
> I found you need to get them from the async IO provider.
> The easyrpc server has a method to get
Yeah, you probably need to recompile the python module against the new
version of Cap'n Proto. Unfortunately, it's very hard to remain
ABI-compatible across versions in C++, so KJ and Cap'n Proto don't try.
-Kenton
On Sun, Mar 21, 2021 at 1:13 PM pepijn de vos wrote:
> I rewrote my queue for
Yes, Executor is a good way to communicate between threads. FWIW you might
also check out newCrossThreadPromiseAndFulfiller(), which was added very
recently. Sometimes it's a better fit than kj::Executor.
"Level 2" turns out to be something that can't really be built into
libcapnp itself because
On Tue, Mar 16, 2021 at 2:26 PM Zach Lym wrote:
> I might say: "As of March 2021, three-party handoff and capability
equality -- two advanced-but-important features of CapTP -- are not yet
supported by Cap'n Proto."
>>>
>>> That sounds a bit too massaged. I think it should flatly
On Tue, Mar 16, 2021 at 12:13 AM Zach Lym wrote:
> Is that last sentence CC0 licensed?
>
Sure, feel free to reuse anything I wrote verbatim. CC0 license, or public
domain, whichever you prefer.
> I might say: "As of March 2021, three-party handoff and capability
>> equality -- two
Hi Zach,
Thanks for doing this!
A few nitpicks:
> the former maintainer of Google's popular Protocol Buffers RPC framework
Technically Protocol Buffers is a serialization framework, not RPC. gRPC
and Stubby are RPC frameworks built on Protobuf, but I never worked on
either of them.
> #@n
Hmm when I say "async I/O" I mean the same thing as "non-blocking I/O".
I haven't worked in C#, but have done some stuff with the Win32 C API,
where they call it "overlapped" I/O.
-Kenton
On Wed, Mar 3, 2021 at 3:54 PM John Demme wrote:
> I think in Windows, async IO is different from
On Wed, Mar 3, 2021 at 2:11 PM John Demme wrote:
> Some operating systems (*cough* Windows *cough*) don't support
> non-blocking file (or inter-process pipe) I/O without some unreliable
> hacks. AFAICT.
>
Hate to say it, but my understanding is that Windows has much more robust
async filesystem
Hi Pepijn,
The full comment you refer to says:
// DO NOT CALL THIS except at the top level of your program, e.g. in
main(). Anywhere else, you
// should instead have your caller pass in a Filesystem object, or a
specific Directory object,
// or whatever it is that your code needs. This ensures
Hi Yojiro,
It would be best if you could reduce the problem to a minimal
self-contained test case. If your program is multiple files then it is
probably too big for us to look at. All I really need is for you to add a
main() function to the code you sent before, so I can see exactly the code
that
Hi,
Sorry for the slow reply.
Just going to throw out a guess here, but seeing that you're using windows,
did you make sure to use O_BINARY when opening the file descriptor? If you
didn't, then the C library will silently corrupt your data by converting
line endings.
If that's not it, then
Hi Owen,
KJ is actually designed to allow its event loop to sit on top of some other
event loop, for this very reason. But, it's not easy. You have to implement
a custom subclass of `kj::EventPort` and probably all of the interfaces
(that you care about) in `kj/async-io.h`.
The node-capnp
Sorry, I really don't know since I haven't tried it yet. There's a lot of
potential to eliminate copies and syscalls here, but how much impact that
really makes would of course depend on what else your system is doing.
(Note that I go by "Kenton", not "Ken"...)
-Kenton
On Fri, Feb 5, 2021 at
Ah, cool.
FWIW, this is still just an issue with the design of this particular test
case. Having socket buffer set large should be no problem in general. I
suppose this test case should probably be rethought but I'll probably wait
for a second complaint before I mess with it.
-Kenton
On Mon,
Hmm, well I'm not sure what to say here. Maybe your unix sockets have
larger buffers for some reason? Are you running a weird kernel version?
What architecture is this?
In any case, this error doesn't indicate a problem with Cap'n Proto, only a
problem with the test, so you should be safe
It looks like this error occurs when the number of file descriptors sent on
a unix socket exceeds `ulimit -n`.
Admittedly, the test tries to send lots of file descriptors over a unix
socket, stopping only when the socket buffer seems to be full. So depending
on the system configuration, it could
Hi John,
Was there anything in the log before the fail line? Usually there should be
some sort of error message describing what went wrong, and maybe a stack
trace.
-Kenton
On Mon, Feb 1, 2021 at 3:53 PM John Wang wrote:
> I'm seeing a failure on the following test. Did a quick search of the
(Dupe message happened because one got stuck in the moderation queue.)
On Mon, Dec 7, 2020 at 10:20 AM Lena Lötter wrote:
> Thanks for the quick response and direction. The example comes in handy as
> I opted for the longer route.
>
> On Wednesday, December 2, 2020 at 10:56:13 PM UTC+2
Awesome, I'm very glad to hear you've been paying attention to ordering --
it's tricky to get right but turns out to be very important.
I'm hoping David weighs in at some point and we can decide whether it makes
sense to merge this back into the main repo.
-Kenton
On Tue, Dec 1, 2020 at 7:23 AM
Hi Lena,
`WaitScope` has a method called `poll()` which checks for new I/O and
handles it without blocking. Maybe you can get away with calling that from
time to time.
If that doesn't work, then it sounds like you may need to implement your
own kj::EventPort to use in place of kj::UnixEventPort.
Yes, it's straightforward to implement a load-balancing proxy server that
redirects each call to a different back-end. To do this in C++, you'd
implement capnp::Capability::Server, implementing the generic
`dispatchCall()` method such that it chooses a back-end and then uses
`context.tailCall()`
This is great!
Out of curiosity, do you have a specific use case you're building for?
Do you have any RPC-specific documentation or examples yet?
I notice this is implemented as a fork of the existing capnproto-java. Did
you have to make changes to the existing code? Is the API compatible?
I
Hi Kevin,
You are correct that if you avoid passing interface types in your RPC
messages, you will never have the opportunity to take advantage of promise
pipelining, at least as the protocol is defined today.
But I'm not sure I understand the motivation for your question. Why do you
want a
On Wed, Nov 25, 2020 at 3:43 PM Matt Stern wrote:
> When I try to run capnp compile, I get the following:
>
> error: Import failed: /capnp/java.capnp
>
You will need to specify the same -I flags (import path) that you normally
specify to `capnp compile` when running the Java code generator.
If
Erin is correct.
For #2, the command-line syntax to have the compiler echo back capnp format
(with all type IDs defined explicitly) is:
capnp compile -ocapnp foo.capnp
This of course requires that `capnp` and the generator plugin
`capnpc-capnp` are in your $PATH, which they should be after
Hi Sundar,
Note that the step that is failing is when the build tries to invoke the
capnp binary that it just built -- so it would be invoking an aarch64
binary.
Does this environment use qemu-user to emulate aarch64? I've noticed in the
past that qemu-user has a lot of bugs emulating certain
Hi Sundar,
Can you tell us the set of commands that led to this? I.e. what was your
command-line for `configure` and `make`? And what directory did you run
them in, relative to the source directory?
-Kenton
On Sun, Nov 15, 2020 at 6:22 PM Sundar Palani
wrote:
> I have the following error
Yep, that looks like a smoking gun to me.
-Kenton
On Mon, Nov 9, 2020 at 2:41 PM Zachary Dremann wrote:
> This looks related:
> https://lists.debian.org/debian-glibc/2014/01/msg00023.html
>
> I rebuilt everything in the same way on an ubuntu 16.04 VM, and I don't
> get the segfault. I don't
Hi Zachary,
It looks like the segfault is happening in glibc's backtrace() function
while gathering the stack trace for an exception. An exception is actually
expected here (the test case tests throwing an exception). Since it
happened specifically in fiber-related tests, my guess is that glibc's
I probably did it for consistency. It's true that, at least at present,
it's not in any way meaningful for an enum to be parameterized. Moreover,
you cannot declare parameters in an enum declaration. However, an enum
could be nested within a parent scope that is parameterized, and in theory
Hi Erin,
In Cloudflare Workers, we've had some success attaching certain kinds of
metadata by having a wrapper object which is called first, like:
interface Endpoint {
startCall @0 (metadata :Metadata) -> (dispatcher :CallDispatcher);
}
interface CallDispatcher {
foo @0
Hi Dmitriy,
I had a long set of answers typed up for you, but then I came to your last
paragraph:
> PLEASE DO NOT BE LIKE STUPID AMERICANS. Do not answer for any question
> with "Yes". US citizens likes answer for complex question with non related
> answer.
> Please be as more verbose as you
I guess this means that under ASAN, the stack is not allocated in the
traditional way. For some reason there's a 1MB offset between where the
ExceptionCallback was allocated and where a local variable inside its
constructor was allocated.
The check there is pretty hacky and probably technically
On Tue, Oct 13, 2020 at 5:15 AM Erin Shepherd wrote:
> > I think that ThreadSanitizer is having trouble recognizing that the
> initialization of `brokenCapFactory` is thread-safe, due to the awkward way
> in which it is initialized. It may end up being initialized by multiple
> threads, but all
hat's carefully tuned
>
> On Fri, Oct 9, 2020 at 10:00 AM 'Kenton Varda' via Cap'n Proto <
> capnproto@googlegroups.com> wrote:
>
>> It looks like the writes are done atomically, but the reads aren't. TSAN
>> is right to be suspicious of this. In practice there is
It looks like the writes are done atomically, but the reads aren't. TSAN is
right to be suspicious of this. In practice there is no bug here, but
showing that requires higher-level reasoning that TSAN wouldn't be expected
to figure out.
-Kenton
On Fri, Oct 9, 2020 at 11:52 AM Vitali Lovich
I think that ThreadSanitizer is having trouble recognizing that the
initialization of `brokenCapFactory` is thread-safe, due to the awkward way
in which it is initialized. It may end up being initialized by multiple
threads, but all threads will initialize it to the same value, hence no
atomics
Was someone going to send out a meeting invite or something?
On Wed, Sep 30, 2020, 4:11 PM Louis Thibault wrote:
> Alright, it seems like everyone is eager to meet this Friday, so let’s do
> that. :)
>
> See you all on Friday, as initially planned.
>
> - Louis
>
> On Sep 30, 2020, at 17:08,
On Wed, Sep 23, 2020 at 11:52 PM Ryan Patterson
wrote:
> Hi Kenton, thanks for weighing in!
>
> > I don't think the generated code would implement the getSchema() RPC
> directly for each type. Instead I think I'd add a new method to the
> `Capability::Server` and `ClientHook` like:
>
> I think
Hi Ambrase,
copyToUnchecked() does not write a segment table at the beginning of the
message. That's probably why you're seeing a message 8 bytes shorter.
copyToUnchecked() and readMessageUnchecked() are difficult to use correctly
(and are insecure when used incorrectly). I strongly recommend
I'm still happy to chat this Friday.
-Kenton
On Wed, Sep 30, 2020 at 3:41 PM Louis Thibault wrote:
> 100% agree — let’s not lose momentum. I’ll send out another invite when
> we hear back from Ross.
>
> Cheers,
> Louis
>
> On Sep 30, 2020, at 16:27, Ian Denhardt wrote:
>
> I'm okay
Sorry for the very slow response this time. We had a big launch on Monday
and I haven't had much time to reply to e-mail.
Incidentally that launch is vaguely relevant here.
https://blog.cloudflare.com/introducing-workers-durable-objects/
We built the infrastructure for this on Cap'n Proto. When
Hi Louis,
This is somewhat embarrassing, but there is no level 3 implementation of
Cap'n Proto today, in any language. It's likely that when I get around to
implementing it in C++, the protocol spec will change to solve
unanticipated problems. As such, trying to implement the spec as-written in
Hi Jeremy,
The `Which` enums are intentionally not `enum class` because I wanted the
enumerants to appear as constants in the containing class, as this enum
actually represents the union tags for the containing class, so the `Which`
part is sort of superfluous. All other enums, though, are
Hi Robert,
> message has too many segments error.
This basically means the data is corrupted somehow. You'll need to track
down why the bytes you're receiving are not the same as the bytes you are
sending. To debug, you might try reading the bytes into a regular byte
buffer and logging them, and
Hi Mostafa,
Nope, we don't have that yet. We have JsonCodec to translate JSON to Cap'n
Proto, but no one has put it together into an HTTP service just yet.
It's more complicated for Cap'n Proto compared to gRPC because of
capabilities and promise pipelining. There isn't an obvious way to expose
Hmm, would `Bar` be allowed to be used as a type in schemas? If so, when
you receive an arbitrary `Bar` on the wire, how would you figure out which
layout to use?
If `Bar` is not allowed on the wire then I can imagine how to implement
this, but I think a lot of people would be surprised by such a
It's true, currently TwoPartyVatNetwork doesn't feature any flags to enable
these. You could write a custom VatNetwork implementation that does it.
I'd be happy to accept a PR adding the features to TwoPartyVatNetwork.
-Kenton
On Thu, Jul 30, 2020 at 7:57 PM wrote:
> I can't seem to find out
Hey, sorry for the delayed response, it's been a really busy time.
And TBH I'm not sure I really have an answer.
The Windows async bindings are definitely very very different from the Unix
ones, since Windows uses overlapped I/O and Unix uses readiness I/O and,
well, they work totally
Hi Emyr,
You can use capnp::writeMessage() to write to any kind of stream.
https://github.com/capnproto/capnproto/blob/7e2f70f354e2ca3d9de73ddaf974408ddbd98866/c++/src/capnp/serialize.h#L162
This function writes to a `kj::OutputStream`, which is an abstract
interface that you can implement any
If you have a struct Foo whose fields are a strict superset of some other
struct Bar (with matching field numbers and everything), then you can
convert one to the other like:
Foo::Reader foo = ...;
Bar::Reader bar = capnp::AnyStruct::Reader(foo).as();
(Or vice versa.)
But the big
On Mon, Jul 6, 2020 at 10:54 AM Vitali Lovich wrote:
> I think a potential middle ground for this might be to have the stream
> give you the fd and a fulfiller. Any I/O operations on the stream then are
> blocked from executing until after the promise to return the FD is
> fulfilled.
>
That's
Hmm I don't understand what you're doing with paf.promise.fork(), it looks
like you're merely attaching it to another promise, not actually waiting on
it or anything.
I am a little concerned about your use of shutdownWrite() / abortRead() in
a way that assumes these functions will cause any
On Mon, Jul 6, 2020 at 10:22 AM Vitali Lovich wrote:
> I don't feel great about the duplication approach (or allowing retrieving
> the raw handle directly) as it can be subtly tricky to actually use
> correctly. For example, if you dup & make the dup'ed FD blocking, that will
> impact correct
On Mon, Jul 6, 2020 at 9:28 AM Vitali Lovich wrote:
> Yeah, that's what I figured. The KJ API is s much more user friendly
>>> though :). It would be cool to be able to consume the raw file
>>> descriptor/socket out of the pipes the LowlevelIoProvider constructs to
>>> simplify code/error
Almost. Two issues I can think of:
1. After each pump completes, you probably want to call shutdownWrite() to
propagate the EOF.
2. `joinPromises()` always waits for all promises to resolve. I've often
found that this turns out to be the wrong behavior when one of the joined
promises throws an
On Mon, Jul 6, 2020 at 8:02 AM Vitali Lovich wrote:
> On Sun, Jul 5, 2020 at 3:02 PM Kenton Varda wrote:
>
>> On Sun, Jul 5, 2020 at 1:48 PM Vitali Lovich wrote:
>>
>>> Yeah, so I'm still working through getting executeSync working. I do
>>> wish executeAsync would still be able to do the
On Sun, Jul 5, 2020 at 1:48 PM Vitali Lovich wrote:
> Yeah, so I'm still working through getting executeSync working. I do wish
> executeAsync would still be able to do the right thing when invoked from
> off-thread to avoid creating artificial synchronization points, but I can
> see it being
I posted an answer on Stack Overflow.
On Fri, Jul 3, 2020 at 10:47 PM Vitali Lovich wrote:
> I'm trying to integrate cap'n'proto with surrounding threads that don't
> use KJ event loops. On Android it's easier because I have an event loop to
> adapt to with ALooper (albeit it's crashing -
In fact, it is technically possible to use interfaces independently of the
RPC system. Study capnp/capability.h to see the interfaces you'd need to
define.
However, I guess you'd end up repeating a lot of the work of the RPC
implementation. So I don't recommend that. I guess it probably makes the
Hi Dmitry,
You should be able to accomplish this by writing a custom implementation of
VatNetwork. You can look at TwoPartyVatNetwork for an example.
That said, if you're thinking about optimizations like lock-free ring
buffers, you may find that the RPC system itself adds too much overhead for
Hi Vaci,
I suspect pycapnp currently lacks support for specifying generic type
parameters. You might want to file an issue on pycapnp's github about that.
However, I suspect you can work around it by defining the type
specializations you need in a .capnp file (which could be a private file
used
Hi Christian,
It's intentional that you can't see the event in this case. Eventually, we
expect that the third server will be able to form a direct connection to
the first server here, so the second server is cut out of the loop.
There are three design patterns you can use to get what you want
`schema.getProto().getNestedNodes()` returns a list of
`capnp::schema::Node::NestedNode`, which has `name` and `id` fields. So
that gives you the names of the nested declarations, which you can get plug
into `getNested()`.
It's a little ugly, but in general, the C++ schema classes only have
Hi John,
`capnp::SchemaParser` will parse capnp files and give you a
`capnp::ParsedSchema`, which is like `capnp::Schema` but also has the
`getNested()` method which allows you to traverse the whole tree of child
nodes. So it's not just the root node.
That said, it's true that it's not
101 - 200 of 420 matches
Mail list logo
