profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Ralith/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

linebender/druid 4519

A data-first Rust-native UI design toolkit.

quinn-rs/quinn 1716

Futures-based QUIC implementation in Rust

MaikKlein/ash 812

Vulkan bindings for Rust

dpc/rdedup 712

Data deduplication engine, supporting optional compression and public key encryption.

bos/llvm 106

Haskell bindings to the LLVM compiler infrastructure project.

cessen/openexr-rs 22

Rust bindings for OpenEXR

pwn4/dandruffapples 8

dandruffapples

Ralith/blox2d 7

A lisp port of the Box2D physics engine

Ralith/cl-chipmunk 3

Common Lisp CFFI wrapper to the chipmunk 2D physics library

issue commentquinn-rs/quinn

Platform OS Errno 5 Input/Output Error

If this is the issue discussed in #1128, then it shouldn't occur in environments without heterogeneous NICs, which shouldn't happen in production servers. #1129 has a WIP mitigation I'll try to get back to soon. Worst-case, you can always just patch GSO out of quinn by hacking https://github.com/quinn-rs/quinn/blob/main/quinn-udp/src/unix.rs#L527 to always return 1.

BiagioFesta

comment created time in 3 days

issue closeddimforge/rapier

Major cuboid-cuboid interpenetration despite CCD

A 0.2^3 cuboid falling onto a static 20^3 cuboid from a height of 1 unit under 9.81 units/s^2 of gravity has a minimum height of about 0.0435 above the static cuboid's face, i.e. it sinks more than a quarter of the way into the surface. Adjusting the starting height to 100 units (and the number of steps to 300) produces a minimum height of -0.433, i.e. entirely submerged in the static cuboid. The situation slowly gets resolved, but not without a significant amount of sideways motion.

Occurs on current master.

<details> <summary>self-contained repro</summary>

use rapier3d_f64::{
    dynamics::{
        CCDSolver, IntegrationParameters, IslandManager, JointSet, RigidBodyBuilder, RigidBodySet,
        RigidBodyType,
    },
    geometry::{BroadPhase, ColliderBuilder, ColliderSet, Cuboid, NarrowPhase, SharedShape},
    pipeline::PhysicsPipeline,
};

fn main() {
    let mut islands = IslandManager::new();
    let mut bodies = RigidBodySet::new();
    let mut colliders = ColliderSet::new();

    let mut pipeline = PhysicsPipeline::new();
    let integration_parameters = IntegrationParameters::default();
    let mut broad_phase = BroadPhase::new();
    let mut narrow_phase = NarrowPhase::new();
    let mut joints = JointSet::new();
    let mut ccd_solver = CCDSolver::new();

    // Ground box with a surface facing +y at y=0
    colliders.insert(
        ColliderBuilder::new(SharedShape::new(Cuboid::new(na::Vector3::new(
            10.0, 10.0, 10.0,
        ))))
        .position(na::Isometry3::translation(0.0, -10.0, 0.0))
        .build(),
    );

    let cuboid = bodies.insert(
        RigidBodyBuilder::new(RigidBodyType::Dynamic)
            .ccd_enabled(true)
            .position(na::Isometry3::translation(0.0, 1.0, 0.0))
            .build(),
    );
    colliders.insert_with_parent(
        ColliderBuilder::new(SharedShape::new(Cuboid::new(na::Vector3::repeat(0.1)))).build(),
        cuboid,
        &mut bodies,
    );

    for i in 0..40 {
        println!("{}", i);
        pipeline.step(
            &na::Vector3::new(0.0, -9.81, 0.0),
            &integration_parameters,
            &mut islands,
            &mut broad_phase,
            &mut narrow_phase,
            &mut bodies,
            &mut colliders,
            &mut joints,
            &mut ccd_solver,
            &(),
            &(),
        );
        let cuboid = bodies.get(cuboid).unwrap();
        println!("cube: {:?}", cuboid.position().translation.vector.data.0);
    }
}

</details>

closed time in 3 days

Ralith

issue commentdimforge/rapier

Major cuboid-cuboid interpenetration despite CCD

Thanks for having a look! It sounds like this is actually working as intended, then. I expected CCD to forbid interpenetration entirely, rather than only prevent tunneling, which led me to suspect this might be a symptom of more severe misbehavior I've been hunting in my project, but it now sounds unrelated.

  1. We could use the min of the ccd_thickness() of both colliders instead of the sum?

I think this might would the results less surprising, perhaps even combined with 2 so people can reason about what proportion of an object's approximate size should be allowed to interpenetrate in the worst case.

However, now knowing that the current behavior is intended, it's not actually a problem for me; anti-tunneling is all I really want anyway, and if the current approach gets me better performance for that, great! I just need to keep working on a repro for the real issues I've been hunting. The sideways motion during collision resolution is a bit funny but I'll assume it's inconsequential.

Closing since it's not obvious to me that rapier should actually change anything here, though I might send a doc PR later.

Ralith

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentquinn-rs/quinn

Various bulk benchmark improvements

 async fn server(mut incoming: quinn::Incoming, opt: Opt) -> Result<()> {         };         trace!("stream established"); -        let _: tokio::task::JoinHandle<Result<usize>> =-            tokio::spawn(async move { drain_stream(&mut stream, opt.read_unordered).await });+        let _: tokio::task::JoinHandle<Result<()>> = tokio::spawn(async move {+            drain_stream(&mut recv_stream, opt.read_unordered).await?;+            send_data_on_stream(&mut send_stream, opt.download_size).await?;

If we use unidirectional streams in each direction, I don't think the actual number of subtasks needs to change, since streams for an unused transfer direction can be dynamically omitted.

That said, I don't see a clear requirement for the capability, so :shrug:, nonblocking.

Matthias247

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentquinn-rs/quinn

Various bulk benchmark improvements

 pub struct Opt {     #[structopt(long = "max_streams", short = "m", default_value = "1")]     pub max_streams: usize,     /// Number of bytes to transmit from server to client-    #[structopt(long, default_value = "1073741824")]+    ///+    /// This can use SI prefixes for sizes. E.g. 1M will transfer 1MB, 10G+    /// will transfer 10GB.

Should say 1MiB and 10GiB, and similar for upload_size.

Matthias247

comment created time in 4 days

Pull request review commentquinn-rs/quinn

Various bulk benchmark improvements

 async fn server(mut incoming: quinn::Incoming, opt: Opt) -> Result<()> {         };         trace!("stream established"); -        let _: tokio::task::JoinHandle<Result<usize>> =-            tokio::spawn(async move { drain_stream(&mut stream, opt.read_unordered).await });+        let _: tokio::task::JoinHandle<Result<()>> = tokio::spawn(async move {+            drain_stream(&mut recv_stream, opt.read_unordered).await?;+            send_data_on_stream(&mut send_stream, opt.download_size).await?;

Should these be concurrent? Sequential seems of limited value, since you could get similar data from just running two tests. Alternatively, use unidirectional streams in both directions, with handlers spawned independently?

Matthias247

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventRalith/hecs

Benjamin Saunders

commit sha 12ac09b3b1f16c7a0969d447f98f7d6e13b89a5c

Add missing reexport, tweak doc

view details

push time in 4 days

issue commentRalith/hecs

Deprecate World::get(_mut) in favor of World::query_one

On review I'm second-guessing the ergonomics of this. get doesn't require an intermediate variable to hold the query, because a single component can be ergonomically exposed via a smart pointer. You can't destructure a temporary smart pointer, so AFAICT there's no way to get let x: &Component = world.query_one::<&Component>(e)?.

Ralith

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentquinn-rs/quinn

Use WorkLimiter also for sending data

 impl WorkLimiter {                 (7.0 * self.smoothed_time_per_work_item_nanos + time_per_work_item_nanos) / 8.0             }; -            self.allowed = ((self.desired_cycle_time.as_nanos()) as f64-                / self.smoothed_time_per_work_item_nanos) as usize;+            // Allow at least 1 work item in order to make progress+            self.allowed = (((self.desired_cycle_time.as_nanos()) as f64+                / self.smoothed_time_per_work_item_nanos) as usize)

1ns is really tiny

Right, the issue is that Instant::now() isn't necessarily anywhere near that accurate, and moving between cores can do weird things. I believe rust only guarantees monotonicity, and even that only with considerable effort!

Matthias247

comment created time in 4 days

PullRequestReviewEvent

push eventquinn-rs/quinn

Chris Connelly

commit sha e63dd773762be3f6c3309955878c71ab6f322967

Make `TransportConfig` setters infallible For most setters this was just a case of changing the signature to take a `VarInt`. `max_idle_timeout` was a bit more involved in order to maintain a usable conversion from `Duration`. The internal representation was changed from `Duration` from `VarInt`, and an `IdleTimeout` newtype was introduced for the setter signature. `IdleTimeout` contains a `VarInt`-encoded millisecond value, and has a fallible conversion from `Duration`. The use of a newtype is preferable to a direct `Duration` -> `VarInt` encoding since there could be other `VarInt`-encoded values in future that use a different resolution than milliseconds. These changes allow callers to avoid the type-level possibility of error if they have a `VarInt` (or a value that can be converted infallibly into one). Fallible conversion from `VarInt` is still convenient with `TryInto`, and callers can handle the conversion errors without the indirection of `ConfigError`. Closes #1176. BREAKING CHANGE: The `max_concurrent_bidi_streams`, `max_concurrent_uni_streams`, `stream_receive_window`, and `receive_window` methods on `TransportConfig` now take `VarInt` arguments and return `&mut Self`. `TransportConfig::max_idle_timeout` now takes an `IdleTimeout` argument and returns `&mut Self`.

view details

push time in 4 days

issue closedquinn-rs/quinn

Suggestion: infallible `TransportConfig` APIs

I'm currently using quinn for the transport layer in another library. This has generally been pretty smooth, and is definitely helped overall by the granularity of error types in quinn 👍

However, I'm finding the TransportConfig API particularly awkward to work with, since many methods can fail with ConfigError::OutOfBounds (e.g. quinn::TransportConfig::max_concurrent_bidi_streams). Since ConfigError non-exhaustive I can't easily wrap it without some kind of catch-all variant, or exposing quinn::ConfigError from my library.

Since all the fallibility comes from converting to VarInts, would you be open to adding relevant 'lower level' methods to TransportConfig that would accept a VarInt and be infallible, so that consumers can do their own validation/sanitisation?

Some other options I considered, but I don't think really solve the issue:

  • Make quinn::ConfigError exhaustive. That makes it easier to hide quinn::ConfigError, but doesn't really help with infallible use (e.g. if I want to simply clamp out-of-bounds values, I'll still end up unwrapping a ConfigError, and/or dealing with other variants (with unreachable etc.)).
  • Use a specific OutOfBounds error, rather than the ConfigError enum. That has the same issue as above, though I'd be more comfortable unwrapping it.

closed time in 4 days

connec

PR merged quinn-rs/quinn

Infallible `TransportConfig` setters

Based on the discussion in #1176, I've updated the relevant TransportConfig setters to take VarInt, so they become infallible. In most cases, this is just a case of applying .into()/.try_into() to the argument (particularly with the addition of TryFrom<Duration> for VarInt).

In that issue one thing suggested was using impl Into<VarInt>, in the end I left that out since it doesn't do much for literal arguments, which still need to be ascribed with a relevant type (e.g. 1u8).


  • 0f840f01 Use VarInt in TransportConfig's VarInt field setters

    Rather than taking a u64 and returning a ConfigError::OutOfBounds, these methods are now infallible by taking a VarInt directly.

    In many cases, call-sites can be updated simply by adding a .into() or .try_into() to the argument.

    BREAKING CHANGE: The max_concurrent_bidi_streams, max_concurrent_uni_streams, stream_receive_window, and receive_window methods on TransportConfig now take VarInt arguments and return &mut Self.

  • 5713ddaf Use VarInt in TransportConfig max_idle_timeout field

    Rather than using Duration internally, max idle timoout is now stored as a VarInt. This avoids some conversions and an internal unwrap.

  • edf1e786 Implement TryFrom<Duration> for VarInt

    This tries to encode a Duration, as milliseconds, into a VarInt.

  • d707827b Use VarInt in TransportConfig max_idle_timeout setter

    This allows the setter to be infallible. The impl of TryFrom<Duration> for VarInt means call-sites can just use .try_into().

    BREAKING CHANGE: The max_idle_timeout method on TransportConfig now takes a VarInt argument and returns &mut Self.

+104 -68

4 comments

14 changed files

connec

pr closed time in 4 days

PullRequestReviewEvent

push eventRalith/hecs

Benjamin Saunders

commit sha 42bb229340bb88fb2258d830a8f8ed8357f1cd3b

Cloneable component specialization of EntityBuilder

view details

push time in 5 days

delete branch Ralith/hecs

delete branch : cloneable-builder

delete time in 5 days

PR merged Ralith/hecs

Cloneable component specialization of EntityBuilder

This is convenient for storing dynamic entity prototypes, which may be used to efficiently spawn individual identical entities on a recurring basis.

Fixes #193.

There's one aspect of the current draft I'm not happy with: a double indirect function call per component when building an entity from a cloneable builder. There's no escaping at least one indirect call per component, but it'd be nice not to have two. This is difficult because we need temporary storage for the cloned component value so that we can construct a pointer to it in DynamicBundle::put which the caller can move out of. If we refactored DynamicBundle::put to take pointers to write into instead, bundles would have to handle random access by TypeId, which is awkward and might compromise performance. Maybe we should allocate reusable scratch space on the heap? Probably better benchmark to be sure...

+235 -90

1 comment

4 changed files

Ralith

pr closed time in 5 days

issue closedRalith/hecs

Feature: re-usable component bundles

I'd like to efficiently re-use component bundles that aren't known statically. Implementing DynamicBundle myself seems painful and not intended. Re-using can only happen if all of the components are Clone. Ideally, we'd have impl DynamicBundle for &'a EntityBuilder if we know that all of the components are cloneable. This would allow me to just keep an EntityBuilder around and use it as a bundle.

closed time in 5 days

kvark

push eventRalith/hecs

Benjamin Saunders

commit sha 968c3815a66effc7f67b6327c03261dd4f648968

Cloneable component specialization of EntityBuilder

view details

push time in 5 days

push eventRalith/hecs

Benjamin Saunders

commit sha 88e4f2461e8c6213d5a64958d68ee18bcff97bca

Introduce EntityRef::has

view details

Benjamin Saunders

commit sha e97efb7d1d9c6f9fece694592069fb251233913c

Cloneable component specialization of EntityBuilder

view details

push time in 5 days

push eventRalith/hecs

Benjamin Saunders

commit sha 88e4f2461e8c6213d5a64958d68ee18bcff97bca

Introduce EntityRef::has

view details

push time in 5 days

delete branch Ralith/hecs

delete branch : entity-ref-has

delete time in 5 days

PR merged Ralith/hecs

Introduce EntityRef::has
+6 -0

0 comment

2 changed files

Ralith

pr closed time in 5 days