- 18 Oct, 2014 1 commit
-
-
Philip Quinn authored
-
- 15 Oct, 2014 5 commits
-
-
Kenton Varda authored
add fix for older cmake versions
-
Joshua Warner authored
-
Kenton Varda authored
Add initial cmake build support
-
Joshua Warner authored
-
Joshua Warner authored
* Move binaries into the bin directory and libs into the lib directory in the output * Make sure the actual binary output file of capnp-tool is just capnp * Remove need for deprecated cmake get_property function
-
- 14 Oct, 2014 3 commits
-
-
Joshua Warner authored
-
Joshua Warner authored
-
Joshua Warner authored
-
- 12 Oct, 2014 1 commit
-
-
Ahmed Charles authored
-
- 11 Oct, 2014 2 commits
-
-
Joshua Warner authored
-
Joshua Warner authored
-
- 07 Oct, 2014 1 commit
-
-
Kenton Varda authored
Add ReaderOptions configurability to EzRpc
-
- 26 Sep, 2014 2 commits
-
-
Kenton Varda authored
Fix typo in grammar.capnp.
-
Ahmed Charles authored
-
- 24 Sep, 2014 1 commit
-
-
Matthew Maurer authored
Add a defaulted ReaderOptions argument to the constructors for EzRpcServer and EzRpcClient to allow large/deep message uses more easily.
-
- 16 Sep, 2014 2 commits
-
-
Kenton Varda authored
Actually, let's use single digits for these otherwise they'll actually be printed in scientific notation with a '.', defeating the purpose of the test.
-
Kenton Varda authored
Appending 'f' to an integer literal doesn't make it a float. We have to add '.0' first. Fixes #119.
-
- 11 Sep, 2014 3 commits
-
-
Kenton Varda authored
This only happened if the Finish message indicating cancellation and the Return message happened to cross paths. If the Finish arrived before the Return was sent, then the server would send an empty response. If the Return was received before the Finish was sent, the client would properly record caps in the response. But if they crossed paths, the server would send back a full response with caps, but the client would never bother to inspect that response, thus leaking the caps. Fix is to set the flag to release all returned caps in the Finish message when cancelling.
-
Kenton Varda authored
-
Kenton Varda authored
Fix obscure bug where the last outgoing message (and any capabilities therein) would not get released (until a new message was sent, replacing it as the last). This took hours to track down, because it initially looked like "Release" messages weren't being honored in some cases (when they happened to be releasing a capability from the last message, and no subsequent messages were sent). Initial attempts to capture this in a unit test failed because the test of course used a subsequent call to detect if the capability had been released, which succeeded.
-
- 08 Sep, 2014 3 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
Fix link to 'Capability Myths Demolished' paper
-
- 06 Sep, 2014 1 commit
-
-
dharmatech authored
The old link isn't currently working.
-
- 30 Aug, 2014 1 commit
-
-
Kenton Varda authored
Fix typo
-
- 29 Aug, 2014 2 commits
-
-
Kenton Varda authored
Replace AC_PROG_LIBTOOL with LT_INIT in configure.ac
-
Morten Hustveit authored
AC_PROG_LIBTOOL is a deprecated name for older versions of LT_INIT.[1] 1. http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html
-
- 28 Aug, 2014 1 commit
-
-
Jim Puls authored
-
- 19 Aug, 2014 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
Bug 1 ----- If a Resolve message indicated that the promise had been rejected, the code would see the error cap as a local cap and erroneously believe that the promise had resolved back to a local capability, thereby requiring a Disembargo to be sent. The peer, on receiving the nonsensical Disembargo, would throw an exception and close the connection. The error message seen was: "expected target->getBrand() == this; 'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender." Bug 2 ----- Disembargos are sent not only in response to Resolves, but also Returns, since capabilities in a returned message were previously accessible as PromisedAnswers. This means that we must apply the same rule that states that once a promise has been resolved, the promise must from then on forward all messages it receives strictly to the object to which it resolved, even if that object is itself a promise which later resolves to somewhere else. The code which sends Resolve messages was doing this correctly, but the code sending Return messages was not. They now both operate correctly. I've also added more explanation to the documentation in rpc.capnp. The error message seen was: "expected redirect == nullptr; 'Disembargo' of type 'senderLoopback' sent to an object that does not appear to have been the object of a previous 'Resolve' message."
-
- 07 Aug, 2014 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
- 22 Jul, 2014 1 commit
-
-
Kenton Varda authored
Support for printing exception backtrace symbols on OS X.
-
- 20 Jul, 2014 2 commits
-
-
Philip Quinn authored
-
Philip Quinn authored
-
- 16 Jul, 2014 1 commit
-
-
Kenton Varda authored
Add configured includedir as a default import path
-
- 15 Jul, 2014 1 commit
-
-
Philip Quinn authored
-
- 13 Jul, 2014 1 commit
-
-
Geoff Reedy authored
Protected by an ifdef to avoid tripping up non-autotools builds
-
- 12 Jul, 2014 1 commit
-
-
Kenton Varda authored
-