profile
viewpoint

capnproto/capnproto-rust 1083

Cap'n Proto for Rust

capnproto/capnproto-java 286

Cap'n Proto in pure Java

capnproto/capnp-rpc-rust 122

Cap'n Proto RPC for Rust

capnproto/capnpc-rust 77

Cap'n Proto code generation for Rust

capnproto/capnp-futures-rs 20

async serialization for Cap'n Proto messages in Rust

dwrensha/acronymy 19

user-editable, acronym-only dictionary

dwrensha/capnp-zmq-rust 10

Rust library for using ZeroMQ with Cap'n Proto serialization

dwrensha/BrowserQuest 6

A HTML5/JavaScript multiplayer game experiment

dwrensha/aione 1

game for ludum dare 22

push eventcapnproto/capnproto-rust

David Renshaw

commit sha aafaac6b368fd186ecc32f21ddccd0b651138a31

remove unneeded lifetime parameter

view details

push time in 4 days

delete branch dwrensha/serdebench

delete branch : capnp-scratch-space-easier

delete time in 7 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 207c6ed7b22a9a153df0742164895135831dcfa6

expand documentation of Allocator::deallocate_segment()

view details

push time in 7 days

pull request commentllogiq/serdebench

Optimize the capnproto benchmarks.

@dureuill thanks for pushing on this. Here's an even better version: #6.

dwrensha

comment created time in 7 days

PR opened llogiq/serdebench

[capnproto] update for simpler buffer reuse enabled by capnp-v0.13.6

After implementing #5, I realized that some simplifications were possible in capnproto-rust's API. I implemented those simplifications in https://github.com/capnproto/capnproto-rust/commit/8257850c8ba5eace0d208316f8515a92895ff30f and released a new crate version.

This pull request updates the benchmark to take advantage of the new simpler API. In particular, the allocator can just be borrowed by the message builder -- no need to move it around.

+7 -13

0 comment

3 changed files

pr created time in 7 days

create barnchdwrensha/serdebench

branch : capnp-scratch-space-easier

created branch time in 7 days

delete branch dwrensha/serdebench

delete branch : scratch-space-allocator

delete time in 7 days

created tagcapnproto/capnproto-rust

tagcapnp-v0.13.6

Cap'n Proto for Rust

created time in 7 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha b736f2b571f155bdc1630bd49e0c7cd4a92055d1

prepare for 0.13.6 release

view details

push time in 7 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 8257850c8ba5eace0d208316f8515a92895ff30f

Add blanket impl Allocator for &mut A where A: Allocator

view details

push time in 7 days

pull request commentllogiq/serdebench

Optimize the capnproto benchmarks.

@dureuill I opened #5 to show how ScratchSpaceHeapAllocator works. I initially thought it would be unfair to allocate outside of the main iteration loop, but it looks like the flatbuffers code is doing that too.

dwrensha

comment created time in 9 days

PR opened llogiq/serdebench

use capnp::message::ScratchSpaceHeapAllocator to amortize allocation costs

This speeds things up a bit more and avoids the need to specify first_segment_words.

+14 -11

0 comment

1 changed file

pr created time in 9 days

push eventdwrensha/serdebench

David Renshaw

commit sha 9ffc2a9daef6318b01d60d8375f4007d7468baad

use capnp::message::ScratchSpaceHeapAllocator to amortize allocation costs

view details

push time in 9 days

create barnchdwrensha/serdebench

branch : scratch-space-allocator

created branch time in 9 days

pull request commentllogiq/serdebench

Optimize the capnproto benchmarks.

  1. Even a more generous first-segment allocation like capnp::message::HeapAllocator::new().first_segment_words(100) would be a big improvement over the default allocation, which is 1024 words.

  2. capnproto-c++ has a type-based sizeInWords function, but that has not been implemented yet for capnproto-rust yet.

  3. Another approach would be to use capnproto-rust's ScratchSpaceHeapAllocator to reuse a buffer between iterations. In that case, the size of the buffer is not important, because its allocation only happens once.

dwrensha

comment created time in 9 days

delete branch dwrensha/serdebench

delete branch : capnp-optimize-2

delete time in 9 days

issue commentcapnproto/capnproto-rust

Is there any benchmark?

On closer examination, the utf-8 validation does not look as significant as I had initially thought. I now suspect it's mainly the pointer indirection that's expensive for capnproto-rust, and reading a List(Text) involves a lot of pointer indirection.

Praying

comment created time in 10 days

push eventdwrensha/serdebench

David Renshaw

commit sha 1444c49feab7550142d74e7e6d4be87a5b6dbbe2

Optimize the capnproto benchmarks. - Move opt_bool into a union, rather than a separate struct. - Tell `HeapAllocator` how many words to expect per message. - Use read_message_from_flat_slice() to avoid unnecessary copies.

view details

push time in 10 days

issue commentcapnproto/capnproto-rust

Is there any benchmark?

I suspect one of the reasons that flatbuffers deserialization appears to be faster is that capnproto-rust is doing utf-8 validation but (as far as I know) flatbuffers is not. I wonder if we should adjust the API of capnp::text::Reader so that consumers don't need to perform that validation if they don't want to. (This isn't the first time that the validation has noticeably shown up in a benchmark.)

Praying

comment created time in 10 days

push eventdwrensha/serdebench

David Renshaw

commit sha d89c4387abd5de2871818ac7647f5088f1cfa6bb

Optimize the capnproto benchmarks. - Move opt_bool into a union, rather than a separate struct. - Tell `HeapAllocator` how many words to expect per message. - Use read_message_from_flat_slice() to avoid unnecessary copies.

view details

push time in 10 days

issue commentcapnproto/capnproto-rust

Is there any benchmark?

@dureuill Thanks. I opened https://github.com/llogiq/serdebench/pull/4.

Praying

comment created time in 10 days

PR opened llogiq/serdebench

Optimize the capnproto benchmarks.
  • Move opt_bool into a union, rather than a separate struct.
  • Tell HeapAllocator how many words to expect per message.
  • Use read_message_from_flat_slice() to avoid unnecessary copies.
  • Fix build breakage from #3.
+651 -802

0 comment

3 changed files

pr created time in 10 days

create barnchdwrensha/serdebench

branch : capnp-optimize-2

created branch time in 10 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 1d76ce134c38e52321c69a2b05642eb3f6950cdc

update hello-world rpc example to use tokio 0.3.0

view details

David Renshaw

commit sha a0bf5bb1f58d579b48ad81cf9d731fe8a2cb8b4b

update calculator rpc example to use tokio 0.3.0

view details

David Renshaw

commit sha fb230d4b514666064264b6325189410088503dd9

update pubsub example to use tokio 0.3.0

view details

push time in 13 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 9c2a11bfb65f95475651386e5aeb6c11cb99d055

add comment for get_connection_state

view details

push time in 13 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 7fb33a31a09811b3c36bc37f16e417b9905d50eb

minor simplification in twoparty::VatNetwork::connect()

view details

push time in 13 days

created tagcapnproto/capnproto-rust

tagcapnp-v0.13.5

Cap'n Proto for Rust

created time in 14 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha d7b179176e439a2ddd02f7eda335a9d9ad7684bb

prepare for capnp-v0.13.5 release

view details

push time in 14 days

issue closedcapnproto/capnproto-rust

capnp::serialize::compute_serialized_size_in_words returns size in bytes?

Does capnp::serialize::compute_serialized_size_in_words return the size in bytes instead of 8-byte words? The documentation for it says "Returns the number of words required to serialize the message." I think that the similar function in other languages returns the 8-byte word size.

closed time in 14 days

6xzo

issue commentcapnproto/capnproto-rust

capnp::serialize::compute_serialized_size_in_words returns size in bytes?

Fixed in 5afd805528ae8df5eb78407c926fb615e1e5fe97.

Thank you!

6xzo

comment created time in 14 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 5afd805528ae8df5eb78407c926fb615e1e5fe97

fix bug in capnp::serialize::compute_serialized_size_in_words() In the 0.12 release, we changed the interface of ReaderSegments to be in terms of bytes rather than words. compute_serialized_size_in_words() did not get updated correspondingly and has therefore been returning bogus values.

view details

push time in 14 days

issue commentcapnproto/capnproto-rust

capnp::serialize::compute_serialized_size_in_words returns size in bytes?

It should return the number of 8-byte words, but it's possible that the 0.12 release introduced a bug.

6xzo

comment created time in 15 days

push eventcapnproto/capnproto-java

dependabot[bot]

commit sha 44a8c1e859ee2a70fdb88591eb1fc8a2721cb732

Bump junit from 4.12 to 4.13.1 in /compiler Bumps [junit](https://github.com/junit-team/junit4) from 4.12 to 4.13.1. - [Release notes](https://github.com/junit-team/junit4/releases) - [Changelog](https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.12.md) - [Commits](https://github.com/junit-team/junit4/compare/r4.12...r4.13.1) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 16 days

PR merged capnproto/capnproto-java

Bump junit from 4.12 to 4.13.1 in /compiler dependencies

Bumps junit from 4.12 to 4.13.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/junit-team/junit4/releases">junit's releases</a>.</em></p> <blockquote> <h2>JUnit 4.13.1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.1.md">release notes</a> for details.</p> <h2>JUnit 4.13</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md">release notes</a> for details.</p> <h2>JUnit 4.13 RC 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 RC 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 3</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66"><code>1b683f4</code></a> [maven-release-plugin] prepare release r4.13.1</li> <li><a href="https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2"><code>ce6ce3a</code></a> Draft 4.13.1 release notes</li> <li><a href="https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24"><code>c29dd82</code></a> Change version to 4.13.1-SNAPSHOT</li> <li><a href="https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567"><code>1d17486</code></a> Add a link to assertThrows in exception testing</li> <li><a href="https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9"><code>543905d</code></a> Use separate line for annotation in Javadoc</li> <li><a href="https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944"><code>510e906</code></a> Add sub headlines to class Javadoc</li> <li><a href="https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae"><code>610155b</code></a> Merge pull request from GHSA-269g-pwp5-87pp</li> <li><a href="https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec"><code>b6cfd1e</code></a> Explicitly wrap float parameter for consistency (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1671">#1671</a>)</li> <li><a href="https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646"><code>a5d205c</code></a> Fix GitHub link in FAQ (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1672">#1672</a>)</li> <li><a href="https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8"><code>3a5c6b4</code></a> Deprecated since jdk9 replacing constructor instance of Double and Float (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1660">#1660</a>)</li> <li>Additional commits viewable in <a href="https://github.com/junit-team/junit4/compare/r4.12...r4.13.1">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 16 days

push eventcapnproto/capnproto-java

dependabot[bot]

commit sha 9d06495851b946241622e667d60b16d899554d09

Bump junit from 4.12 to 4.13.1 in /runtime Bumps [junit](https://github.com/junit-team/junit4) from 4.12 to 4.13.1. - [Release notes](https://github.com/junit-team/junit4/releases) - [Changelog](https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.12.md) - [Commits](https://github.com/junit-team/junit4/compare/r4.12...r4.13.1) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 16 days

PR merged capnproto/capnproto-java

Bump junit from 4.12 to 4.13.1 in /runtime dependencies

Bumps junit from 4.12 to 4.13.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/junit-team/junit4/releases">junit's releases</a>.</em></p> <blockquote> <h2>JUnit 4.13.1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.1.md">release notes</a> for details.</p> <h2>JUnit 4.13</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit/blob/HEAD/doc/ReleaseNotes4.13.md">release notes</a> for details.</p> <h2>JUnit 4.13 RC 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 RC 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 3</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 2</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> <h2>JUnit 4.13 Beta 1</h2> <p>Please refer to the <a href="https://github.com/junit-team/junit4/wiki/4.13-Release-Notes">release notes</a> for details.</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/junit-team/junit4/commit/1b683f4ec07bcfa40149f086d32240f805487e66"><code>1b683f4</code></a> [maven-release-plugin] prepare release r4.13.1</li> <li><a href="https://github.com/junit-team/junit4/commit/ce6ce3aadc070db2902698fe0d3dc6729cd631f2"><code>ce6ce3a</code></a> Draft 4.13.1 release notes</li> <li><a href="https://github.com/junit-team/junit4/commit/c29dd8239d6b353e699397eb090a1fd27411fa24"><code>c29dd82</code></a> Change version to 4.13.1-SNAPSHOT</li> <li><a href="https://github.com/junit-team/junit4/commit/1d174861f0b64f97ab0722bb324a760bfb02f567"><code>1d17486</code></a> Add a link to assertThrows in exception testing</li> <li><a href="https://github.com/junit-team/junit4/commit/543905df72ff10364b94dda27552efebf3dd04e9"><code>543905d</code></a> Use separate line for annotation in Javadoc</li> <li><a href="https://github.com/junit-team/junit4/commit/510e906b391e7e46a346e1c852416dc7be934944"><code>510e906</code></a> Add sub headlines to class Javadoc</li> <li><a href="https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae"><code>610155b</code></a> Merge pull request from GHSA-269g-pwp5-87pp</li> <li><a href="https://github.com/junit-team/junit4/commit/b6cfd1e3d736cc2106242a8be799615b472c7fec"><code>b6cfd1e</code></a> Explicitly wrap float parameter for consistency (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1671">#1671</a>)</li> <li><a href="https://github.com/junit-team/junit4/commit/a5d205c7956dbed302b3bb5ecde5ba4299f0b646"><code>a5d205c</code></a> Fix GitHub link in FAQ (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1672">#1672</a>)</li> <li><a href="https://github.com/junit-team/junit4/commit/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8"><code>3a5c6b4</code></a> Deprecated since jdk9 replacing constructor instance of Double and Float (<a href="https://github-redirect.dependabot.com/junit-team/junit4/issues/1660">#1660</a>)</li> <li>Additional commits viewable in <a href="https://github.com/junit-team/junit4/compare/r4.12...r4.13.1">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+1 -1

0 comment

1 changed file

dependabot[bot]

pr closed time in 16 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 385c81dc2080e7717999b0137c1f5a6390706b65

impl Drop for async_byte_channel::Receiver

view details

push time in 17 days

pull request commentcapnproto/capnproto-java

Allow CXX to be overriden via enviroment or Make variable.

capnpc-rust is written in Rust: https://github.com/capnproto/capnproto-rust/tree/master/capnpc

capnpc-go is written in Go: https://github.com/capnproto/go-capnproto2/tree/master/capnpc-go

capnpc-ocaml is written in OCaml: https://github.com/capnproto/capnp-ocaml/tree/master/src/compiler

All of these do use the capnp tool, which is written in C++, but the target-language-specific logic is written in the target language.

See https://capnproto.org/otherlang.html#how-to-write-compiler-plugins.

litghost

comment created time in 18 days

push eventcapnproto/capnproto-java

Keith Rothman

commit sha ad460a4723363885461d00d02183270038fb7b38

Allow CXX to be overriden via enviroment or Make variable. Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>

view details

push time in 20 days

pull request commentcapnproto/capnproto-java

Allow CXX to be overriden via enviroment or Make variable.

LGTM.

Also, this reminds me that it would be good to rewrite capnpc-java in Java, so that we don't need to futz with C++ compilation.

litghost

comment created time in 20 days

issue commentcapnproto/capnproto

UBSAN violation in kj::Vector/ArrayBuilder? Also uninitialized variable in ArrayBuilder::disposer

Related: #549, which was reverted in #578.

vlovich

comment created time in 21 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha aaaaa622a3887d57b9aa7b7505d330b6549e64fd

suppress unused_mut warning

view details

push time in 23 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 92093a3bf65ad33d20377715800dc0a9cdf7616c

Add async-byte-channel and use it to avoid needing Unix sockets in tests.

view details

push time in 24 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 3ab5512543c7f364bec1ca7496a17342baec0946

fix typo: capabiity -> capability

view details

push time in 24 days

issue commentcapnproto/capnproto-rust

Is it easy to remove "crate::~" from generated code?

Yes, I think that would be possible. The new option could be named default_parent_module, and it could apply whenever the Rust.parentModule annotation is not present.

However, I'm a little bit worried that such an option might interact poorly with schemas that have cross-crate dependencies. If a schema from crate A wants to import some types from a schema defined in crate B, how will it know the Rust path at which to expect the imported types? (Admittedly, my worry here is rather abstract, because rust-lang/cargo#3544 is blocking cross-crate capnp schema dependencies from actually working.)

soarcreator

comment created time in 25 days

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 0f6049ca1a6c9629d11c8296410c81ff7577267d

get rid of some unneeded 'extern crate'

view details

push time in a month

created tagcapnproto/capnproto-rust

tagcapnp-v0.13.4

Cap'n Proto for Rust

created time in a month

push eventcapnproto/capnproto-rust

David Renshaw

commit sha b807025fdbabf17d6602a80c0aa9128c9e1c6e03

prepare for capnp-v0.13.4 release

view details

push time in a month

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 1431ea8526a078da81f29dd9976cf69a5bf50869

Remove depedendencies on async-std, because futures-lite is breaking the rust-1.44.0 build on Travis.

view details

push time in a month

issue closedcapnproto/capnproto-rust

Unsound use of unsafe

https://github.com/capnproto/capnproto-rust/blob/7ecb112614f2ddb355800f85e32720107112df78/capnp/src/data.rs#L37

This is an extremely unsound use of unsafe. Exposing it publicly makes it possible to write unsound code from safe rust. This function should be marked as unsafe. Uses of this function should be wrapped in an unsafe block.

https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html

closed time in a month

benaubin

issue commentcapnproto/capnproto-rust

Unsound use of unsafe

Thanks for the report!

Fixed in be7beab6091b7ac830bed72c6fb25295980b03fc.

benaubin

comment created time in a month

push eventcapnproto/capnproto-rust

David Renshaw

commit sha be7beab6091b7ac830bed72c6fb25295980b03fc

deprecate unsafe functions data::new_reader() and data::new_builder()

view details

push time in a month

pull request commentcapnproto/capnproto-rust

Sync ReadLimiter

I was curious about which targets support which atomics, so I tried cross compiling the following program on a sampling of targets:

#![no_std]

pub fn foo() {
    let x = core::sync::atomic::AtomicUsize::new(0);
    let x = core::sync::atomic::AtomicU64::new(0);
    let x = core::sync::atomic::AtomicU32::new(0);
}

targets that support AtomicUsize, AtomicU64, and AtomicU32

x86_64-unknown-linux-gnu arm-unknown-linux-gnueabi i686-unknown-linux-gnu wasm32-unknown-unknown aarch64-unknown-linux-gnu

targets that support AtomicUsize and AtomicU32, but not AtomicU64

arm-linux-androideabi powerpc-unknown-linux-gnu thumbv7em-none-eabihf

targets that do not support AtomicUsize, AtomicU64, or AtomicU32

riscv32i-unknown-none-elf


These results are more or less what I expected: while the most important targets support AtomicU64, there are some targets that we should care about that don't support it.

I'm not sure what's going on with riscv32i-unknown-none-elf.

appaquet

comment created time in a month

push eventcapnproto/capnproto-java

Keith Rothman

commit sha e96448d3f5737db25e55cd268652712b69db5cc0

Add install target for capnp-java and the java.capnp include file. Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>

view details

David Renshaw

commit sha b60bc1e7148893ad584e369b7bd3c1717f1d2cb0

Merge pull request #86 from litghost/add_install_target Add install target for capnp-java and the java.capnp include file.

view details

push time in a month

PR merged capnproto/capnproto-java

Add install target for capnp-java and the java.capnp include file.

This fix is in reference too https://github.com/capnproto/pycapnp/issues/231

+7 -0

1 comment

1 changed file

litghost

pr closed time in a month

pull request commentcapnproto/capnproto-java

Add install target for capnp-java and the java.capnp include file.

LGTM. Thanks!

litghost

comment created time in a month

issue commentcapnproto/capnproto-rust

Reduce the amount of unsafe code

The recent Miri testing mostly had to do with preventing undefined behavior having to do with alignment: https://dwrensha.github.io/capnproto-rust/2020/01/19/new-feature-to-allow-unaligned-buffers.html

I have not set up coverage analysis for the fuzz tests. That would be interesting to see!

Cargo Klee sounds pretty useful too.

DemiMarie

comment created time in a month

pull request commentcapnproto/capnproto-rust

Sync ReadLimiter

Thanks!

Having thought about this some more, I think I prefer option 2 above, i.e. switching to AtomicU32. You are correct that it would be a breaking change, so it would require a version bump. We would probably want to wait until we have other pending breaking changes, so things can be batched together and we minimize version churn. I'm not sure when that would be, but historically it has been something like every six months.

If we want to quickly land a fix/workaround, then maybe your feature flag is the way to go. I hesitate because I don't like adding this kind of complexity, but maybe it's worth it.

Are you able to workaround the problem on your end by sharing an OwnedSegments or SegmentArray object rather than a message::Reader object?

appaquet

comment created time in a month

pull request commentcapnproto/capnproto-rust

Sync ReadLimiter

Some options:

  1. We could use some kind of conditional compilation (feature flag or platform detection) to control when the AtomicU64 is used. I worry that this approach might add unpleasant surprises for downstream users, with things becoming !Sync in unexpected situations.

  2. Assuming that AtomicU32 is sufficiently widely supported, we could use it instead of AtomicU64. The downside is that the read limiter would then capped at 32 gigabytes, but, come to think of it, that doesn't seem too bad, as long as we provide an explicit way to opt out of read limiting. It seems reasonable to expect that all untrusted messages people care about will be smaller than that (though maybe there are some use cases that I have not imagined).

  3. We could make read limiting customizable via a trait, perhaps folding it into the ReaderSegments trait. Then message::Reader<S> could be Sync or not depending on whether S is Sync. It's unclear to me exactly what the new API would look like, but this feels doable to me.

appaquet

comment created time in 2 months

startedjsm28/bmo2-2020-lean

started time in 2 months

Pull request review commentcapnproto/capnproto-rust

Sync ReadLimiter

 use crate::{Error, OutputSegments, Result}; pub type SegmentId = u32;  pub struct ReadLimiter {-    pub limit: Cell<u64>,+    pub limit: u64,+    pub read: AtomicU64, }  impl ReadLimiter {     pub fn new(limit: u64) -> ReadLimiter {-        ReadLimiter { limit: Cell::new(limit) }+        ReadLimiter { +            limit,+            read: AtomicU64::new(0),+        }     }      #[inline]     pub fn can_read(&self, amount: u64) -> Result<()> {-        let current = self.limit.get();-        if amount > current {+        let read = self.read.fetch_add(amount, Ordering::Relaxed) + amount;

This potentially allows self.read to overflow and wrap around.

appaquet

comment created time in 2 months

PullRequestReviewEvent

pull request commentcapnproto/capnproto-rust

Sync ReadLimiter

Thanks!

Do you know which platforms support AtomicU64? This async-std pull request seems to suggest the Arm, MIPS, and Powerpc do not support it. I would prefer not to break capnp on those platforms.

appaquet

comment created time in 2 months

push eventdwrensha/rust

bors

commit sha 5f88bea878767abf2e4305bbb60116b4b57f6eb3

Auto merge of #75014 - Amanieu:fix_asm_reg, r=nagisa Work around LLVM issues with explicit register in inline asm Fixes #74658

view details

5M1Sec

commit sha be1fc40b1d473e8c1b22662d58e631c4f586d881

Allowing raw ptr dereference in const fn Change `UnsafetyViolationKind::General` to `UnsafetyViolationKind::GeneralAndConstFn` in check_unsafety.rs Remove unsafe in min_const_fn_unsafe_bad.rs Bless min_const_fn Add the test case from issue 75340 Co-authored-by: lzutao <taolzu@gmail.com>

view details

bors

commit sha 49d39e55917a7cdfefddd499c09a7b6118851485

Auto merge of #75568 - ehuss:cloudabi-tier3, r=Mark-Simulacrum Move CloudABI to tier 3. The CloudABI target hasn't had much work done on it in a while, and it doesn't appear to be in active use. It has a fairly substantial amount of code, particularly in the [sys module](https://github.com/rust-lang/rust/tree/5addb135edc2653b07670482a430aac9b655a86b/library/std/src/sys/cloudabi) that requires actively supporting. I contacted @EdSchouten who indicated that many of the CloudABI concepts are now in WASI, and that they are OK with the target being moved to tier 3.

view details

bors

commit sha 94d7660d59fadf0ec7887e7a82c32bf1d8f84fb4

Auto merge of #75468 - poliorcetics:intra-links-fs, r=jyn514 Move to intra doc links in std/src/fs.rs Helps with #75080. @rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc

view details

bors

commit sha 67e7b9b8cf776222825dbbd4cb1e39b7765ef27c

Auto merge of #75535 - denisvasilik:intra-doc-links-any, r=jyn514 Move to intra-doc links for /library/core/src/any.rs Helps with #75080. @rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc Known issues: * Links from `core` to `std` (#74481): * `[Box]: ../../std/boxed/struct.Box.html`

view details

Matthias Krüger

commit sha 262db3b5e6c3f3278c9fb2a91817f3a66cf0a5e2

deps: bump cargo_metadata and semver cargo_metadata 0.9.1 -> 0.11.1 semver 0.9.0 -> 0.10.0

view details

Sasha

commit sha bdbb995df331e6bdd49b182d4f24577e18df7abd

Mark x86_64-linux-kernel as *

view details

Tim Diekmann

commit sha c619b36975c399880eb87edb9a62d93c1732b2af

Remove fast path in reallocation for same layout sizes

view details

Ralf Jung

commit sha 6da8503dff7b8792916bf6cd489e92c49ea7e868

fix typo Co-authored-by: Oliver Scherer <github35764891676564198441@oli-obk.de>

view details

bors

commit sha 8cdc94e84040ce797fd33d0a7cfda4ec4f2f2421

Auto merge of #75592 - RalfJung:miri-int-align, r=oli-obk miri engine: add option to use force_int for alignment check This is needed for https://github.com/rust-lang/miri/issues/1074. The Miri-side patch is at https://github.com/rust-lang/miri/pull/1513. r? @oli-obk

view details

Ralf Jung

commit sha edb39c0d208ef7850116bd3c931df091730c0e7f

attempt to improve span_label docs

view details

Tim Diekmann

commit sha 93e074bc8a0766afbe3594f8663d702638ec0c35

Add `as_uninit`-like methods to pointer types and unify documentation of `as_ref` methods Fix example in `NonNull::as_uninit_slice` Rename feature gate to "ptr_as_uninit" Make methods more consistent with already stable methods Make `pointer::as_uninit_slice` return an `Option` Fix placement for `// SAFETY` section Add `as_uninit_ref` and `as_uninit_mut` to pointers Fix doctest Update tracking issue Fix doc links Apply suggestions from review Make wording about counterparts consistent Fix doc links Improve documentation Fix doc-tests Fix doc links ... again Apply suggestions from review Apply suggestions from Review Apply suggestion from review to all affected files Add missing words in safety sections in `as_uninit_slice_mut` Fix safety-comment in `NonNull::as_uninit_slice_mut`

view details

bors

commit sha 838c201af9a4d44cd93d2003ee06b6319067d5b0

Auto merge of #5915 - matthiaskrgr:deps_, r=Manishearth deps: bump cargo_metadata and semver cargo_metadata 0.9.1 -> 0.11.1 semver 0.9.0 -> 0.10.0 changelog: none

view details

David Wood

commit sha f1ce2948dba9b314b3f0205a6e9b125bdf186b8e

clippy: support `QPath::LangItem` This commit updates clippy with the introduction of `QPath::LangItem` so that it still compiles. Signed-off-by: David Wood <david@davidtw.co>

view details

David Wood

commit sha f13d2bfd9be6e8f7c8930b5590a634d8807c139b

clippy: support `QPath::LangItem` This commit updates clippy with the introduction of `QPath::LangItem` so that it still compiles. Signed-off-by: David Wood <david@davidtw.co>

view details

Tim Diekmann

commit sha c48f7844185cadc51af6ac5fd4db48324fd02882

Fix typo in comment

view details

David Wood

commit sha 5703b2863e1b4b815007b5a3380734634acd1f37

polymorphize: ∃ used param ∈ predicate → all used This commit modifies polymorphization's handling of predicates so that if any generic parameter is used in a predicate then all parameters in that predicate are used. Signed-off-by: David Wood <david@davidtw.co>

view details

Guillaume Gomez

commit sha cbc13c5eb72ffd470a3e4a59c96c85e004268584

Clean up E0754 explanation

view details

Oliver Scherer

commit sha daf7a375105b55de7a808aa096194280249f0fc5

Make a test platform independent

view details

Ellen

commit sha 509cad7f2f8e6c8985b707cab4ab9e1cd78f63c8

Switch to intra-doc links for std/src/error.rs

view details

push time in 2 months

push eventdwrensha/fuzz-rustc

David Renshaw

commit sha 601efb25de5ab9a314e20e243d313891f3824b02

update for new paths of compiler crates

view details

push time in 2 months

PullRequestReviewEvent

pull request commentixchow/fluint8

Review my code

This change is bad and you should feel bad.

tom7

comment created time in 2 months

push eventdwrensha/sharelatex

Ian Denhardt

commit sha bf4f1c1a64fdffcf1ec72d34596af330adaf47bb

Add a section to the top of the README, re: monkeypatched spk.

view details

David Renshaw

commit sha f3a8565d9711137e46370b28c4957cace6a62877

Merge pull request #16 from zenhack/readme-link-to-patch-scripts Add a section to the top of the README, re: monkeypatched spk.

view details

push time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

https://github.com/zenhack/patch-sharelatex/pull/1

I would accept a pull request adding a note to this repo.

ocdtrekkie

comment created time in 2 months

push eventdwrensha/patch-sharelatex

David Renshaw

commit sha c6e26747ca4fb26fd845b3e4c8a667ca32170fab

add changelog entry, bump versions, fix alwaysInclude

view details

push time in 2 months

fork dwrensha/patch-sharelatex

"Build" scripts for sandstorm's legacy sharelatex package.

fork in 2 months

issue commentcapnproto/capnproto

Unaligned Stores in BuilderArena/ReaderArena constructors

@kentonv I think that property is not universal. Consider, for example, 32-bit RISC-V https://godbolt.org/z/16Gcz7

erikmchut

comment created time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

Done -- I've run spk publish on the new spk with an updated changelog.

ocdtrekkie

comment created time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

OK, let me make a version that updates the changelog too.

ocdtrekkie

comment created time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

I'm reading the documentation at https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/package.capnp

It looks like alwaysInclude refers to package paths (rather than source paths) and resolves relative to root, so I think this is correct, but I'd like @zenhack to double check this.

ocdtrekkie

comment created time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

I needed to change something because otherwise I got the error

Destination (in-package) path must not start with '/': /
ocdtrekkie

comment created time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

hm... now I'm worried that alwaysInclude = "." was the wrong thing.

ocdtrekkie

comment created time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

@zenhack thanks for setting all of that up. I ran your scripts and updated the version numbers. I also needed to change alwaysInclude = ["/"] into alwaysInclude = "." (I think that might include more than is actually necessary, but I don't think it's a problem.) I then did spk publish, so I think this is up to the App Market review team now.

ocdtrekkie

comment created time in 2 months

issue commentpypa/setuptools

setuptools 50.0 cannot import distutils in python 3.5.1

The workaround described in the changelog worked for me:

export SETUPTOOLS_USE_DISTUTILS=stdlib
gavincyi

comment created time in 2 months

issue commentdwrensha/sharelatex

ShareLatex broken by client-side loading changes in 0.270

Can Sandstorm implement an allow-list of package IDs for which the content security policy should not be enforced? Then we wouldn't need to dig into this kind of update.

ocdtrekkie

comment created time in 2 months

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 7ecb112614f2ddb355800f85e32720107112df78

remove some unnecessary 'extern crate' lines

view details

push time in 2 months

created tagcapnproto/capnproto-rust

tagcapnp-futures-v0.13.1

Cap'n Proto for Rust

created time in 2 months

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 3b7421962283fa51ff42580b2022d13650106ee8

prepare for capnp-futures-v0.13.1 release

view details

push time in 2 months

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 9b52ad766e189a5aed8d0e6ce97d1e9f6fb2f317

remove accidentally-included executor feature from futures dependency

view details

push time in 2 months

push eventcapnproto/capnproto-rust

David Renshaw

commit sha 39a6695c348abf1bb057c570e4be5ee30bc137cf

improve allocator documentation

view details

push time in 2 months

issue commentcapnproto/capnproto-rust

Best way to add more more data to a List(Data)

The problem with the above solution is that I'm not sure how to "convert" the reader struct into a builder one without allocation a brand new builder which would probably defeat the whole strategy.

There's currently no way to avoid copying the bytes into a new builder. Note that you can precisely control the size of the new builder's initial allocation via first_segment_words.

sezaru

comment created time in 2 months

issue commentcapnproto/capnproto-rust

Best way to add more more data to a List(Data)

There may be more details to your setup than the example code shows, but it looks to me like you can avoid the separate copy into new_list by directly copying into builder, like this:

// Retrieve the serialized `Bucket` struct and deserialize it

... Get binary data from RocksDB to variable value ...

let mut reader = &*value;
let message =
  capnp::serialize::read_message(&mut reader, ReaderOptions::new()).unwrap();

let root = message.get_root::<SerializedBucket::Reader>().unwrap();
let old_items = root.get_items().unwrap();
let mut builder = Builder::new_default();
{
   let root = builder.init_root::<SerializedBucket::Builder>();
   let mut items = root.init_items(old_items.len() + new_values.len());

   // TODO use iterators
   for ii in 0..old_items.len() {
      items.set(ii, old_items.get(ii));
   }
   for ii in 0 .. new_values.len() {
      items.set(ii + old_items.len(), new_values[ii]);
   }
}

let mut buf = Vec::new();
capnp::serialize::write_message(&mut buf, &builder).unwrap();

sezaru

comment created time in 2 months

pull request commentcapnproto/capnproto-rust

Reduced number of dependencies pulled from futures

Good idea!

Travis indicates that cargo test -p capnp-futures is failing.

Unfortunately, it seems my rustfmt didn't agree with yours - do you have any idea why?

Heh, I don't actually use rustfmt.

Would it be possible to avoid the formatting changes in this pull request? It looks like a bunch of the lines that are changing are only formatting changes.

kabergstrom

comment created time in 2 months

issue commentcapnproto/capnproto-rust

Supporting async reads of message segments

My initial reaction is that you should try breaking you message into smaller pieces, to avoid the need for this feature.

I'd be curious to hear more about the details of your use case. How many segments do you foresee needing? Where do they need to be fetched from?

kabergstrom

comment created time in 3 months

issue commentcapnproto/capnproto-rust

Is it easy to remove "crate::~" from generated code?

Currently, the only documentation is inline: https://github.com/capnproto/capnproto-rust/blob/d58b59de4493ddc4a8b422460572fe144831d066/capnpc/rust.capnp#L17

I agree that it would be good to add some documentation elsewhere.

soarcreator

comment created time in 3 months

issue commentcapnproto/capnproto-rust

Is it easy to remove "crate::~" from generated code?

Aside from the implementation difficulty of using relative paths, here's another reason I prefer absolute paths in the generated code. Suppose that you have two schemas foo.capnp and bar.capnp and you want to include them in your crate like this:


mod a {
   mod b {
       mod foo_capnp { /* ... generated code */ }
   }
  
  mod bar_capnp { /* ... generated code */ }
}

Suppose moreover that bar.capnp imports foo.capnp and uses some of the types from it.

I don't see a way to make that work if the generated code relies on relative paths. How would the bar_capnp generated code know about the b module?


To take this a step further, imagine that you could import across crate boundaries. Then you could factor your common schema into its own crate, and all downstream users of it would just need to include it as a Cargo dependency and import it in their schemas, without needing to perform a duplicate codegen step.

I believe that is the ideal world we should be striving for.

To get it to work, we'll need to add crate annotation to rust.capnp

annotation crate (file) :Text;

and we'll need Cargo to support something like https://github.com/rust-lang/cargo/issues/3544.

soarcreator

comment created time in 3 months

more