1. 29 May, 2017 1 commit
  2. 25 Apr, 2017 2 commits
  3. 18 Feb, 2017 1 commit
  4. 24 Jan, 2017 1 commit
  5. 12 Dec, 2016 1 commit
    • Kenton Varda's avatar
      Support AnyPointer constant values. · 9046dc1a
      Kenton Varda authored
      The trick here is that you must specify the value as a separate constant with a defined type. Then, you can reference that constant where an AnyPointer is expected.
      
      Eventually we should maybe support some sort of inline syntax that specifies a type explicitly...
      9046dc1a
  6. 18 Nov, 2016 1 commit
  7. 18 May, 2016 1 commit
    • Branislav Katreniak's avatar
      capnp/test: add union in generic struct test - compilation error · 682cc0c5
      Branislav Katreniak authored
      Adding union into TestGenerics struct leads to compilation error
      in generated header:
      ````cpp
      In file included from external/capnproto/c++/src/capnp/test_capnp/capnp/test.capnp.c++:4:0:
      external/capnproto/c++/src/capnp/test_capnp/capnp/test.capnp.h:9565:10: error: need ‘typename’ before ‘capnproto_test::capnp::test::TestGenerics<Foo, Bar>::Ug::Reader’ because ‘capnproto_test::capnp::test::TestGenerics<Foo, Bar>::Ug’ is a dependent scope
         inline Ug::Reader getUg() const;
      ````
      Relavant parts in header file:
      
      ````cpp
      template <typename Foo = ::capnp::AnyPointer, typename Bar = ::capnp::AnyPointer>
      struct TestGenerics {
        ...
        struct Ug;
      };
      
      template <typename Foo, typename Bar>
      class TestGenerics<Foo, Bar>::Reader {
        ...
        inline Ug::Reader getUg() const;
      };
      ````
      
      Compiler misses `typename` keyword before Ug::Reader.
      682cc0c5
  8. 14 Aug, 2015 1 commit
  9. 29 Jul, 2015 1 commit
  10. 23 Jul, 2015 1 commit
    • Kenton Varda's avatar
      Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an… · d4cd01e9
      Kenton Varda authored
      Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender."
      
      The problem happened when pipelined calls were made on a promised capability, but then that capability turned out to be null. The promise resolving code incorrectly interpreted this as the remote promise having resolved to a local capability (because the "null" stub capability looks local), and so it would send a Disembargo message to flush the pipeline as required. However, the remote end would receive this Disembargo message and find it is addressed to a null capability, not a capability pointing back to the sender. This was treated as a protocol error, causing the receiver to close the connection.
      
      The solution is to explicitly identity "null" capabilities so that we can distinguish this case. This change also has the benefit that now when you copy a null capability between messages with foo.setCap(bar.getCap()), the pointer will be set null in the destination, rather than becoming a reference to a local broken capability.
      
      Thanks to David Renshaw for narrowing this down.
      d4cd01e9
  11. 22 Jul, 2015 1 commit
  12. 08 Jul, 2015 1 commit
  13. 23 Jun, 2015 1 commit
    • Kenton Varda's avatar
      Fixes #219, with POSSIBLE (but obscure) WIRE FORMAT BREAKAGE. · db7ca960
      Kenton Varda authored
      Unfortunately, the layout algorithm had a bug which caused incorrect layout when declaring a union whose lowest-ordinal field was of type Void and nested in an inner union. That is:
      
          union {
            a :union {
              b @0 :Void
              ...
            }
            ...
          }
      
      In this case, all the fields in the struct after the Void field -- including both unions' discriminants -- would end up misplaced. Although they did not end up overlapping (and therefore the incorrect layout "worked"), the result broke schema evolution rules around "retroactive unionization".
      
      Unfortunately, we must break compatibility with any protocol that happened to contain the above pattern. Luckily, it's a fairly obscure case. Unluckily, Cap'n Proto's own schema format contains such a pattern. Luckily, the use of this pattern was introduced in v0.6.x and therefore has not been in any release build so far.
      db7ca960
  14. 07 May, 2015 1 commit
  15. 06 May, 2015 1 commit
  16. 22 Mar, 2015 1 commit
  17. 29 Jan, 2015 1 commit
  18. 09 Jan, 2015 1 commit
  19. 04 Nov, 2014 1 commit
  20. 25 Oct, 2014 1 commit
  21. 24 Oct, 2014 1 commit
  22. 23 Oct, 2014 1 commit
  23. 20 Oct, 2014 1 commit
  24. 17 Oct, 2014 1 commit
  25. 11 Oct, 2014 1 commit
  26. 16 Sep, 2014 2 commits
  27. 11 Sep, 2014 1 commit
    • Kenton Varda's avatar
      Fix obscure bug where the last outgoing message (and any capabilities therein)… · 26914900
      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.
      26914900
  28. 01 Jul, 2014 1 commit
  29. 20 Jun, 2014 1 commit
    • Kenton Varda's avatar
      Change license to MIT. · 889204fe
      Kenton Varda authored
      For portions currently copyright by Kenton (most of it), transfer copyright to Sandstorm Development Group, Inc. (Kenton's company).
      
      The license change is practically meaningless, as MIT and BSD 2-clause are legally equivalent. However, the BSD 2-clause license is sometimes confused for its ugly siblings, BSD 3-clause and BSD 4-clause. The MIT license is more immediately recognizeable for what it is.
      
      Rémy Blank and Jason Choy (the two non-trivial contributors) are on record as approving this change:
      
      https://groups.google.com/d/msg/capnproto/xXDd2HUOCcc/gbe_COIuXKYJ
      889204fe
  30. 13 May, 2014 2 commits
  31. 12 May, 2014 3 commits
  32. 01 Apr, 2014 1 commit
  33. 22 Dec, 2013 1 commit
  34. 06 Dec, 2013 1 commit
  35. 05 Dec, 2013 1 commit