Add Jolt Physics as an alternative 3D physics engine

Closes godotengine/godot-proposals#7308.
This pull request adds a new engine module (found under modules/jolt_physics) which integrates Jolt Physics, a 3D physics engine developed by Jorrit Rouwe (@jrouwe) with a focus on games and VR applications, used in titles such as Horizon Forbidden West.
Users of this new module should (generally, but not always) be able to expect better physics performance, both in terms of CPU performance and simulation stability, when compared to Godot Physics.
This new module is a port of the Godot Jolt extension, developed by myself over the past two years, in large part as a personal project, but with the last year (including this port) being sponsored by W4 Games. I've also received a significant amount of assistance and contributions from @jrouwe during this development, which I'm very grateful for. In fact, several major features have been added to Jolt largely to cater to the needs of Godot.

[!WARNING]
Note that while this code has gone through a fair amount of battle-testing as part of the Godot Jolt extension there have been non-trivial refactorings done as part of this port that have not been tested much at all. As such, this module should be considered experimental for now. This module is also not at feature parity with Godot Physics just yet, nor at feature parity with the Godot Jolt extension either.

This does not replace Godot Physics as the default 3D physics engine. You will need to opt in by setting the physics/3d/physics_engine project setting to JoltPhysics3D.
Notable differences to Godot Physics
While the goal is to have this new module be a drop-in replacement for Godot Physics (within reason), Jolt inherently differs from it in a number of ways, which means that it is unlikely that you will see the exact same behavior when switching between the two. There are also several higher-level decisions taken within the module that deviate further from how Godot Physics does things.
Area3D and static bodies
[Click to expand/collapse]

When using Jolt, Area3D will not detect overlaps with StaticBody3D (nor a RigidBody3D frozen with FREEZE_MODE_STATIC) by default, for performance reasons. If you have many/large Area3D overlapping with complex static geometry, such as ConcavePolygonShape3D or HeightMapShape3D, you can end up wasting a significant amount of CPU performance without realizing it.
For this reason this behavior is opt-in through the project setting physics/jolt_physics_3d/simulation/areas_detect_static_bodies, with the recommendation that you set up your collision layers/masks in such a way that only the relevant Area3D are able to detect collisions with static bodies.
This should probably be made into an Area3D property instead, through something like what's been suggested here.

Joint properties
[Click to expand/collapse]

The current interfaces for the 3D joint nodes, which seem to be derived from the Bullet Physics library, don't quite line up with the interface of Jolt's own joints. As such, there are a number of joint properties that are not supported, mainly ones related to configuring the joint's soft limits.
The unsupported properties are:

PinJoint3D: bias, damping, impulse_clamp
HingeJoint3D: bias, softness, relaxation
SliderJoint3D: angular_*, *_limit/softness, *_limit/restitution, *_limit/damping
ConeTwistJoint3D: bias, relaxation, softness
Generic6DOFJoint3D: *_limit_*/softness, *_limit_*/restitution, *_limit_*/damping, *_limit_*/erp

Currently an error is emitted if you set these properties to anything but their default values.
In the Godot Jolt extension I exposed alternative joint nodes that better matched Jolt's interface, but these have not been included in this module. Instead, the above mentioned properties should probably be removed and replaced by properties more fitting for Jolt, through something like what's been suggested here.

Single-body joints
[Click to expand/collapse]

You can, in Godot, omit one of the joint bodies for a two-body joint and effectively have "the world" be the other body. However, the node path that you assign your body to (node_a vs node_b) is ignored. Godot Physics will always behave as if you assigned it to node_a, and since node_a is also what defines the frame of reference for the joint limits, you end up with inverted limits and a potentially strange limit shape, especially if your limits allow both linear and angular degrees of freedom.
This is arguably a bug and should be changed. This is also not how single-body joints behaves with Bullet in Godot 3, which behaves as if you assigned the body to node_b instead. It's not clear why this changed in Godot 4.
For this reason this module will, like Bullet in Godot 3, behave as if you assigned the body to node_b instead, with node_a representing "the world".
There is a project setting called physics/jolt_physics_3d/joints/world_node that lets you toggle this behavior, if you need compatibility for an existing project.

Collision margins
[Click to expand/collapse]

Jolt (and other similar physics engines) uses something that Jolt refers to as "convex radius" to help improve the performance and behavior of the types of collision detection that Jolt relies on for convex shapes. Other physics engines (Godot included) might refer to these as "collision margins" instead. Godot exposes these as the margin property on every Shape3D-derived class, as a leftover from the Bullet integration in Godot 3, but Godot Physics itself does not use them for anything.
What these collision margins sometimes do in other engines (as described in Godot's documentation) is effectively add a "shell" around the shape, slightly increasing its size while also rounding off any edges/corners. In Jolt however, these margins are first used to shrink the shape, and then the "shell" is applied, resulting in edges/corners being similarly rounded off, but without increasing the size of the shape.
To prevent having to tweak this margin property manually, since its default value can be problematic for smaller shapes, this module exposes a project setting called physics/jolt_physics_3d/collisions/collision_margin_fraction which is multiplied with the smallest axis of the shape's AABB to calculate the actual margin. The margin property of the shape is then instead used as an upper bound.
These margins should, for most use-cases, be more or less transparent, but can sometimes result in odd collision normals when performing shape queries. You can lower the above mentioned project setting to mitigate some of this, including setting it to 0, but too small of a margin can also cause odd collision results, so is generally not recommended.

Compound shapes
[Click to expand/collapse]

Compound shapes (i.e. bodies with more than one shape) are implemented differently from Godot Physics.
Jolt offers the choice of two compound shapes, one called MutableCompoundShape and one called StaticCompoundShape. The former trades in runtime performance for faster construction/modification time, and vice versa for the latter.
Godot Physics maps closer to Jolt's MutableCompoundShape, but I decided to go with StaticCompoundShape for this implementation, as it simplified things a bit (with being able to discard and rebuild the whole thing when modified) and I figured more people would benefit from the improved runtime performance as opposed to mutation performance.
To mitigate the cost of this potentially expensive rebuild, I made it so that shape changes are only ever "committed" to Jolt when the body has entered into a scene tree. This means that you can make shape changes (including adding/removing shapes) very quickly so long as the body isn't attached to the scene tree. However, if you do in fact add the body to a scene tree, and then start adding/removing/changing shapes on the body, you can end up with worse performance than Godot Physics. This is prominently visible in the "Voxel Game" demo project, as one example.
The plan I have in mind for this (discussed in jrouwe/JoltPhysics#1165) is to replace StaticCompoundShape with a custom compound shape that wraps StaticCompoundShape, but which will always defer its building/committing only until absolutely necessary, meaning either right before a simulation step or when performing queries against the body.
If the use of StaticCompoundShape within this new custom compound shape still ends up being a problem for some use-cases it would likely be trivial to expose some setting or property that lets you use MutableCompoundShape instead.

Scaling shapes/bodies/queries
[Click to expand/collapse]

Godot Physics supports scaling the transform of collision shapes, shape queries, as well as static and kinematic bodies, meaning StaticBody3D, CharacterBody3D, AnimatableBody3D and frozen RigidBody3D. It does not however support scaling simulated/dynamic bodies, such as a non-frozen RigidBody3D, and will effectively discard any such scaling, instead treating it as (1, 1, 1).
Jolt does however support scaling everywhere, and I've tried my best to utilize that, which means that RigidBody3D will support scaling when using Jolt, despite the warning shown on the node currently.
Jolt also supports non-uniform scaling, so long as the inherent primitive shape is preserved. For example, you can scale a cylinder along its height axis but not along its other axes. You will however currently see warnings on the shape node when doing this, due to Godot Physics not supporting this.
Since invalid scaling can cause a number of weird artifacts, and sometimes outright crash the simulation, there are runtime error checks that "sanitize" all scaling to be valid for that particular shape arrangement, and then reports an error if the difference is above an arbitrary threshold. These errors have however proven to be a bit frustrating for some users, who might not care about the sometimes minor corrections that this error-checking applies, so this likely needs a different approach.

Shape-casting
[Click to expand/collapse]

Due to Godot having a "safe" and "unsafe" fraction in the results of cast_motion (and ShapeCast3D), meaning the distances at which the cast shape was found to be colliding and not colliding respectively, it was not viable to rely on Jolt's own shape-casting (which uses conservative advancement) to implement cast_motion. Instead cast_motion is implemented with a binary search, similar to how Godot Physics does it.
However, in Godot Physics this binary search is hardcoded to 8 steps, which tends to result in quite jittery output over even moderate distances. With Godot Jolt (and consequently this module) I chose to instead dynamically calculate the number of steps based on the cast distance, aiming for roughly millimeter precision, and then clamp it between 4 and 16 steps, which seems to have worked out well.
This does however mean that cast_motion will technically, when using Jolt, cost more CPU performance the farther you cast the shape.
Note that this also applies to body_test_motion, and consequently move_and_collide and move_and_slide.

Baumgarte stabilization
[Click to expand/collapse]

Jolt employs a technique in its solver called Baumgarte stabilization, which is meant to mitigate constraint drift within the simulation, resulting in a more stable simulation. This technique can however result in some artifacts, like piles of bodies not separating as quickly as one might expect.
The strength of this stabilization can be tweaked using the project setting physics/jolt_physics_3d/simulation/baumgarte_stabilization_factor. Setting this project setting to 1.0 will effectively disable the technique, resulting in a simulation that more closely resembles Godot Physics, but which is also more unstable.

Motion queries (move_and_slide, etc.)
[Click to expand/collapse]

Physics servers in Godot are meant to implement the PhysicsServer3D.body_test_motion method, which in turn powers methods like PhysicsBody3D.move_and_collide and CharacterBody3D.move_and_slide, which are largely meant to be used for moving player characters around.
PhysicsServer3D.body_test_motion is split into three parts, the first being depenetration (called "recovery" in Godot), the second being a shape-cast from the "recovered" position, and the third being the actual collision check, at the "unsafe" fraction of the shape-cast.
The "recovery" step in Godot Physics is hardcoded to always do 4 iterations with 40% depenetration per iteration. I figured these constants might be useful to expose, so when using this module they can be configured in the project settings as physics/jolt_physics_3d/motion_queries/recovery_iterations and physics/jolt_physics_3d/motion_queries/recovery_amount respectively.
The implementation of PhysicsServer3D.body_test_motion in this module also differs slightly from the Godot Physics implementation, as replicating the Godot Physics version resulted in a prohibitive amount of ghost collisions for move_and_slide.
The discrepancies are as follows:

There is no TEST_MOTION_MIN_CONTACT_DEPTH_FACTOR.
There is no epsilon added to the safe margin during recovery.
Contacts with normals that are not opposing the motion vector are discarded from the final collision check.

While these discrepancies do seem to result in less ghost collisions when using Jolt, they also introduce new problems:

move_and_slide is generally slower than in Godot Physics, due to CharacterBody3D::_snap_on_floor triggering on every call.
CharacterBody3D will not report wall collisions unless you're moving towards them.

It's not clear to me how to fix these issues, but I suspect they will require changes to move_and_slide on the scene side of things.

Ghost collisions
[Click to expand/collapse]

Jolt employs two techniques to mitigate ghost collisions, meaning collisions with internal edges of shapes/bodies.
The first technique, called "active edge detection", marks edges of triangles in ConcavePolygonShape3D or HeightMapShape3D as either "active" or "inactive", based on the angle to the neighboring triangle. When a collision happens with an inactive edge the collision normal will be replaced with the triangle's normal instead, to lessen the effect of ghost collisions.
The angle threshold for this active edge detection is configurable through the project setting physics/jolt_physics_3d/collisions/active_edge_threshold.
The second technique, called "enhanced internal edge removal", instead adds runtime checks to detect whether an edge is active or inactive, based on the contact points of the two bodies. This has the benefit of applying not only to collisions with ConcavePolygonShape3D and HeightMapShape3D, but also edges between any shapes within the same body.
Enhanced internal edge removal can be toggled on and off for the various contexts to which it's applied, using the physics/jolt_physics_3d/*/use_enhanced_internal_edge_removal project settings.

Memory usage
[Click to expand/collapse]

Jolt uses a stack allocator for temporary allocations within its simulation step. This stack allocator requires allocating a set amount of memory up front, which can be configured using the physics/jolt_physics_3d/limits/temporary_memory_buffer_size project setting.
Jolt also makes use of aligned allocations for some of its memory usage, which it acquires through function pointers that the implementer assigns. Aligned allocations were recently added to Godot in the form of Memory::alloc_aligned_static, Memory::realloc_aligned_static and Memory::free_aligned_static, which have all been hooked up to Jolt. However, these aligned allocation functions don't currently touch Memory::mem_usage, which means that some of Jolt's memory won't be tracked, and thus the performance monitors in Godot won't be accurate.

Ray-cast face index
[Click to expand/collapse]

The face_index property returned in the results of intersect_ray and RayCast3D will by default always be -1 with Jolt, with a project setting (physics/jolt_physics_3d/queries/enable_ray_cast_face_index) to enable them. The reason for this being that Jolt does not store these indices, and for them to be stored we need to enable the per-triangle userdata, which adds about 25% extra memory usage to the underlying Jolt implementation of ConcavePolygonShape3D.
This should maybe be made into a ConcavePolygonShape3D property instead, through something like what's been suggested here.

Kinematic RigidBody3D contacts
[Click to expand/collapse]

When using Jolt, a RigidBody3D frozen with FREEZE_MODE_KINEMATIC will by default not report contacts from collisions with other static/kinematic bodies, for performance reasons, even when setting a non-zero max_contacts_reported. If you have many/large kinematic bodies overlapping with complex static geometry, such as ConcavePolygonShape3D or HeightMapShape3D, you can end up wasting a significant amount of CPU performance without realizing it.
For this reason this behavior is opt-in through the project setting physics/jolt_physics_3d/simulation/generate_all_kinematic_contacts.
This should probably be made into an RigidBody3D property instead, through something like what's been suggested here.

Contact impulses
[Click to expand/collapse]

Jolt is not able to provide any impulse as part of its contact data, due to how it orders its simulation step, and instead provides a helper function for estimating what the impulse would be based on various parameters. While this is probably fine for most use cases, like emitting a sound based on how hard something collided, it won't be accurate if a body is colliding with multiple bodies during a simulation step.

Area3D and SoftBody3D
[Click to expand/collapse]

This module does not currently support any interactions between SoftBody3D and Area3D, such as overlap events, or the wind properties found on Area3D. Support for this has been added to Jolt recently, and @jrouwe also did some work towards the extension part of it, but it has not been included in this pull request.

ConvexPolygonShape3D
[Click to expand/collapse]

Godot Physics currently skips calculating a proper center-of-mass and inertia for ConvexPolygonShape3D, and instead always uses the shape's local position as its center of mass, while crudely estimating the inertia. Jolt on the other hand does calculate a more accurate center-of-mass and inertia for them. As a result a non-frozen RigidBody3D with such a shape in it can behave differently when comparing the two engines.

WorldBoundaryShape3D
[Click to expand/collapse]

WorldBoundaryShape3D, which is meant to represent an infinite plane, is implemented a bit differently in Jolt compared to Godot Physics. Both engines have an upper limit for how big the effective size of this plane can be, but this size is much smaller when using Jolt, in order to avoid precision issues.
You can configure this size using the physics/jolt_physics_3d/limits/world_boundary_shape_size project setting.

Axis-locking
[Click to expand/collapse]

The PhysicsBody3D.axis_lock_* properties in Godot Physics are implemented by simply zeroing out the velocities for the selected axes. Jolt instead implements these by calculating a new inverse mass/inertia, similar to how RigidBody3D.lock_rotation works in Godot Physics, which seems to better mitigate energy loss during simulation.
However, Jolt does not allow locking all axes, meaning both linear and angular axes, and an error will be emitted from this module when trying to do so, with the recommendation that you instead freeze the body entirely. While this is a simple enough workaround for RigidBody3D, you cannot currently freeze a PhysicalBone3D, so if you want to lock all axes of a PhysicalBone3D you're forced to resort to calling PhysicsServer3D.body_set_mode yourself.

Notable differences to Godot Jolt
While this module is largely a straight port of the Godot Jolt extension, with a lot of cosmetic changes, there are a few things that are different.
Project settings
[Click to expand/collapse]

All project settings have been moved from the physics/jolt_3d category to physics/jolt_physics_3d.
On top of that, there's been some renaming and refactoring of the individual project settings as well. These include:

sleep/enabled is now simulation/allow_sleep.
sleep/velocity_threshold is now simulation/sleep_velocity_threshold.
sleep/time_threshold is now simulation/sleep_time_threshold.
collisions/use_shape_margins is now collisions/collision_margin_fraction, where a value of 0 is equivalent to disabling it.
collisions/use_enhanced_internal_edge_removal is now simulation/use_enhanced_internal_edge_removal.
collisions/areas_detect_static_bodies is now simulation/areas_detect_static_bodies.
collisions/report_all_kinematic_contacts is now simulation/generate_all_kinematic_contacts.
collisions/soft_body_point_margin is now simulation/soft_body_point_radius.
collisions/body_pair_cache_enabled is now simulation/body_pair_contact_cache_enabled.
collisions/body_pair_cache_distance_threshold is now simulation/body_pair_contact_cache_distance_threshold.
collisions/body_pair_cache_angle_threshold is now simulation/body_pair_contact_cache_angle_threshold.
continuous_cd/movement_threshold is now simulation/continuous_cd_movement_threshold, but expressed as a fraction instead of a percentage.
continuous_cd/max_penetration is now simulation/continuous_cd_max_penetration, but expressed as a fraction instead of a percentage.
kinematics/use_enhanced_internal_edge_removal is now motion_queries/use_enhanced_internal_edge_removal.
kinematics/recovery_iterations is now motion_queries/recovery_iterations, but expressed as a fraction instead of a percentage.
kinematics/recovery_amount is now motion_queries/recovery_amount.
queries/use_legacy_ray_casting has been removed.
solver/position_iterations is now simulation/position_steps.
solver/velocity_iterations is now simulation/velocity_steps.
solver/position_correction is now simulation/baumgarte_stabilization_factor, but expressed as a fraction instead of a percentage.
solver/active_edge_threshold is now collisions/active_edge_threshold.
solver/bounce_velocity_threshold is now simulation/bounce_velocity_threshold.
solver/contact_speculative_distance is now simulation/speculative_contact_distance.
solver/contact_allowed_penetration is now simulation/penetration_slop.
limits/max_angular_velocity is now stored as radians instead.
limits/max_temporary_memory is now limits/temporary_memory_buffer_size.

There might be some discussion to be had with regards to migrating the settings values for projects who have previously been relying on the extension.

Joint nodes
[Click to expand/collapse]

The joint nodes that are exposed in the Godot Jolt extension (JoltPinJoint3D, JoltHingeJoint3D, JoltSliderJoint3D, JoltConeTwistJoint3D and JoltGeneric6DOFJoint) have not been included with this module.
Instead of exposing bespoke joint nodes, the existing joint node interfaces should be modified by the physics server, through something like what's been suggested here.

Thread-safety
[Click to expand/collapse]

Unlike the Godot Jolt extension, this module does have experimental thread-safety, including support for the physics/3d/run_on_separate_thread project setting. This is achieved by utilizing the same wrapper server that's used by Godot Physics, called PhysicsServer3DWrapMT, as well as introducing a mutex around the rebuilding of shapes, since concurrent shape-casts could otherwise trigger a race condition.
This has however not been tested very thoroughly, so should be considered experimental.

Query performance
[Click to expand/collapse]

The Godot Jolt extension utilizes a custom container (typically referred to as an "inline vector" or "small vector") in order to avoid heap allocations for physics queries that return more than a single hit, meaning intersect_point, intersect_shape, collide_shape, get_rest_info, cast_motion, body_test_motion, move_and_collide and move_and_slide.
For the sake of simplifying this port I chose to just use LocalVector for the query collectors instead, which means that these queries will now always allocate on the heap, likely making them noticeably slower.
It should be trivial to make some bespoke container for the query collectors that behaves like an inline/small vector.

Debug renderer
[Click to expand/collapse]

Jolt provides an interface called JPH::DebugRenderer for rendering its view of the physics simulation. In the Godot Jolt extension I expose this as a custom GeometryInstance3D node called JoltDebugGeometry3D, which proved to be very useful during development, but I figured this module should probably take a different approach, so I have omitted that code.

Debug snapshots
[Click to expand/collapse]

The Godot Jolt extension has the ability to generate what Jolt refers to as "snapshots", where it serializes the state of the physics simulation to a file. These can then be loaded in Jolt's own Samples application, to debug issues more closely there, without needing to deal with Godot itself, which has proved to be quite useful when reporting issues upstream to Jolt.
The code for this is technically included with this module, and can be found as JoltPhysicsServer3D::dump_debug_snapshots, but it wasn't clear to me how to best expose this, so I've left it unexposed for now.

Things left to do
Just to give people an idea about the state of this module, and perhaps encourage future contributions if/when this pull request is merged, here is a rough copy of my to-do list:
Must-have

Add the ability for physics servers to add/remove/change node properties.
Using the ability to modify node properties, change the joint interfaces to better match Jolt.
Using the ability to modify node properties, move some of the project settings to instead be per-body/per-shape properties.
Add support for interactions between Area3D and SoftBody3D.
Implement the deferred compound shape mentioned above.
Add memory usage tracking for aligned allocations.
Add support for freezing PhysicalBone3D.
Investigate issues with motion queries mentioned above.
Resolve frustrations with invalid scaling.

Nice-to-have

Add migration for the project settings.
Get rid of heap allocations in shape queries when requested hits are less or equal to default.
Expose Jolt's debug rendering somehow (maybe as a viewport mode?).
Expose Jolt's debug snapshots somehow, if only just for dev_build.
Resolve discrepancy with single-body joints mentioned above.
Get rid of the body accessors in jolt_body_accessor_3d.h, in favor of just storing the JPH::Body* in JoltObject3D.
Try remove the use of JPH::PhysicsSystem::GetBodies, to avoid the overhead of iterating over static/sleeping bodies.
Maybe consider adding a temporary memory allocator that doesn't pre-allocate memory.
Link Jolt's Jolt.natvis file in MSVC builds for easier debugging.

What about the extension?
If/when this pull request is merged, the Godot Jolt extension will officially be considered to be in maintenance mode going forward, with only bug fixes backported to it, but so long as this engine module doesn't have full feature parity with the extension there will be new releases of the extension to ensure that projects relying on its additional features can continue to function.
If/when this engine module reaches full feature parity with the extension then the extension will be discontinued and its GitHub repository archived.
Attribution
In the interest of not cluttering every file in this new module with the copyright notice of Godot Jolt, as required by its MIT license, consider this my permission to omit it entirely. I have obtained permission from the applicable copyright holders (@jrouwe) to do so as well.

(This port is based on godot-jolt/godot-jolt@8f1212e19a1bdc76ce34b5ddcfabbfd6e409ef9c, meaning the latest commit of Godot Jolt as of writing this.)

Looking good to me! The diff between godot-jolt and this module is much bigger than I anticipated, must have been a lot of work!

Will the addon discontinue and only this will continue? Have the tests for godot physics (can't remember the repo name) and/or https://github.com/fabriceci/Godot-Physics-Tests been ran on this to see if they match the results godot physics has? I think I ran them sometimes in an older version and there were some problems, but haven't ran lately). Just so there is a clear way to compare the two and see in the future if there are issues, what they are.

The diff between godot-jolt and this module is much bigger than I anticipated, must have been a lot of work!

Yeah, I thought I had a somewhat Godot-like codebase already, but getting rid of all my not-so-Godot idiosyncrasies was a lot of work indeed. I'm sure there's a few left that I've missed.

The functionality from this PR: #96740 seems to be broken. Looks like it's not filtering out the RID for the selected node anymore and repositioning it over itself.

Thanks, I'll take a look!

Will the addon discontinue and only this will continue?

Assuming this module is actually merged and reaches some kind of feature parity with the extension, yes. I don't see the need to maintain both at that point.

Have the tests for godot physics (can't remember the repo name) and/or https://github.com/fabriceci/Godot-Physics-Tests been ran on this to see if they match the results godot physics has? I think I ran them sometimes in an older version and there were some problems, but haven't ran lately). Just so there is a clear way to compare the two and see in the future if there are issues, what they are.

I'll admit I had forgotten that the physics tests in the demo projects repository even existed, but yeah, they seem fine. Although the performance tests seem to crash with either engine for some reason.
I did run the tests in fabriceci/Godot-Physics-Tests beforehand though, and they seem to report the same failures that I've seen before:
1. CollisionShape3D | testing precision moving [CONVEX 2050V] on static [SPHERE] mouvement [LEFT_TO_RIGHT] > Testing stability

The collision normal generated in this test is indeed slightly off when using Jolt, but I'm not sure it's worth getting hung up on.
2. RigidBody3D | testing Continuous Collision Detection (CCD) > Rigid moving in x with CCD detects collision
3. RigidBody3D | testing Continuous Collision Detection (CCD) > Rigid moving in y with CCD detects collision
4. RigidBody3D | testing Continuous Collision Detection (CCD) > Rigid moving in x with CCD detects collision
5. RigidBody3D | testing Continuous Collision Detection (CCD) > Rigid moving in y with CCD detects collision

These fail because the impulse is applied before the body has been added to the physics space, meaning there's no underlying Jolt body to actually apply the impulse to, which I emit an error for currently. You can make these tests pass if you just swap these two lines around.
The problem is you need to calculate the mass properties in order to apply impulses correctly, which can be expensive. In fact, Godot Physics defers this calculation as well, but still lets you apply impulses, resulting in incorrect behavior, as seen in #75934.
6. PhysicsBody3D | testing the collision between a CharacterBody sphere and a big static cylinder > move_and_collide for sphere and cylinder are detected correctly

This fails because the position error exceeds the tolerance by ~0.006 units. I'm not sure it's worth getting hung up on. It's possible that this is caused/worsened by one of the several discrepancies in body_test_motion as well, but those won't be resolved in this pull request either way.
7. RigidBody3D | testing the Sphere stack stability > The bodies are sleeping

Stacked spheres do seem to oscillate more in Jolt, even when setting the Baumgarte stabilization to 1.0. It might be that there's some other setting that can help alleviate this, but this doesn't strike me as a scenario you'll see in a lot of games either way. Stacked boxes seem to behave about as well as with Godot Physics.

Great job mihe, jrouwe, and everyone else involved.
Guess we now only have to wait for a Godot physics maintainer to review and approve this ....
...
...
:)
Bad jokes aside, I build this and master and spend some time testing both by running the jolt module and godot physics in parallel on the same scenes and projects.
The good thing so far I did not encounter anything that I would really worry about, no error spam or really broken behavior issues swapping the physics in any of my test projects. In fact a few things that I knew were a little brittle and easy to make explode felt a lot more robust with the jolt module. Yes I encountered a few random issues but ad hoc I am not sure if they are even caused by the physics or just some weird editor or script code.
Having the two run next to each other it was actually difficult to spot actual difference in most situations. The most noticeable for me was the joint behavior. For some reason the joints in the "official" Godot physics tests demo project loved to spin in circles when moved with the jolt module. Do you know what would cause such a difference and if anything can be done about it?
Here is the link for the demo git (or asset lib was already posted).
https://github.com/godotengine/godot-demo-projects/tree/master/3d/physics_tests
The "official" Godot physics test demo showed some other issues. It actually crashes in the performance test of that demo as the jolt body count of 10240 gets exhausted by that test. Instead of just an error it actually crashes the entire engine in the JoltBody3D::_update_group_filter() function. If that error can not be avoided it should at least happen more gracefully without an engine crash.
So yeah I would recommend definitely trying out all those tests in that demo project so the most "obvious" things can be ironed out before this gets into more hands. I am sure there will be some smaller sweet-n-nasty things discovered by more broad testing (as always). I think that will be unavoidable by such a huge module change and why it is not handled as an immediate replacement of the other physics so there is some time to fix and adapt.

The collision normal generated in this test is indeed slightly off when using Jolt, but I'm not sure it's worth getting hung up on

Yes there are some tiny differences in the return values between the two physics or in general but seriously we are talking about an "error" margin that I find totally negatable in context of game engine physics. I know some people can be really riled up about such details but a friendly reminder this is a game engine and not a scientific simulation, the physics need to work in game engine context. It is not about simulating stuff so we can shoot and bounce stuff with pinpoint accuracy to the moon, it is about making games work without the physics exploding left, right and center at every shape seam or step while also not running at 1 fps ... or at least that should imo be "humble" goal before we worry about those other things.

Yes I encountered a few random issues but ad hoc I am not sure if they are even caused by the physics or just some weird editor or script code. Need to investigate and test some more.

Please do try to share repros of whatever issues you run into.

For some reason the joints in the "official" Godot physics tests demo project loved to spin in circles when pushed or moved with the jolt module. Do you know what would cause such a difference in behavior compared to the godot physics and if anything can be done about it?

I would need to see some kind of repro of this. I haven't had any reports about this for the extension that I can remember, nor have I seen any regressions for joints when using this module.

The "official" Godot physics test demo showed some other issues. It actually crashes in the performance test of that demo as the jolt body count of 10240 gets exhausted by that test. Instead of just an error it actually crashes the entire engine in the JoltBody3D::_update_group_filter() function. If that error can not be avoided it should at least happen more gracefully without an engine crash.

I had glossed over this due to Godot Physics also crashing for me in the broadphase performance test (which seems to be from a stack overflow) so I figured it was something with the test itself, but it seems that the crash with this module was indeed a sloppy regression on my part. That's been fixed now, and you should instead get a "graceful" outcome in the form of error spam about needing to increase the body limit.

The functionality from this PR: #96740 seems to be broken. Looks like it's not filtering out the RID for the selected node anymore and repositioning it over itself.

@ryevdokimov You should find that this works now.

@ryevdokimov You should find that this works now.

Looks good, I'll mark the comment I made as resolved.

I confirm this fixes the original problem in #69137, but not the one I reported in https://github.com/godotengine/godot/issues/69137#issuecomment-2498852480 so that is likely user error, e.g. too small a collider.

Is this still true regarding shape creation as well?

@Zylann Yes, this applies to shape creation in general as well, same as with the extension.

In my voxel terrain, I regularly create a lot of ConcavePolygonShape3D at runtime for each chunk, but it's expensive because it involves BVH calculations. The inability to do this from inside my own meshing threads has limited streaming performance for a long time, since I had to defer it to the main thread. I did this originally because previous physics engines in Godot had no guarantee that this was safe. Now even if this is made safe, I need a way to have control over when the heavy lifting happens (see also godotengine/godot-proposals#483, though a bit old).

@Zylann I'm all for finding some solution to this, but I'm not entirely sure what that would be. Since we're now relying on the same synchronization mechanism as Godot Physics, any shape_set_data call will end up queued in the command buffer of PhysicsServer3DWrapMT and later executed (in serial) on the server thread anyway, when synchronized with the main thread.
You could make shape_set_data a non-deferred method, similar to methods like concave_polygon_shape_create, but since the shape could be attached to a body you'll have knock-on effects that now need to be thread-safe as well, which will likely be error-prone to maintain.

The Bounce Velocity Threshold and Sleep Velocity Threshold project settings are missing range hints, as they shouldn't be allowed to be negative (or even zero, perhaps):

@Calinou I've allowed zero for now, but I struggle to think of sensible ranges and step sizes for these, so I've put in 0,1,0.001,or_greater, meaning a minimum of 0, a "maximum" of 1, a step size of 0.001 and no upper bound (when inputting the value manually).
Do you have any suggestions for better ranges for these, @jrouwe, or just a better lower bound?

The 3D Physics Tests demo crashes on startup, likely because of debug collision shape drawing. This doesn't occur on 4.4.dev5.

@Calinou Is there anything in particular I have to do to trigger this, besides just starting the demo? I don't seem to be able to reproduce this (on Windows).

I'm all for finding some solution to this, but I'm not entirely sure what that would be.

Considering current design decisions, I guess it's going to be a different API from the default. Originally I thought it only had to be some kind of setting specified in the set_shape_data argument, but...

You could make shape_set_data a non-deferred method, similar to methods like concave_polygon_shape_create, but since the shape could be attached to a body you'll have knock-on effects that now need to be thread-safe as well, which will likely be error-prone to maintain.

That's what I feared when I wrote the proposal. It's frustrating because these cases don't apply to my situation, since I already expect to assign shapes to bodies in the main threads due to how things are designed. Shapes are usually isolated and easy to thread creation of, but it seems Godot makes things quite difficult.

Do you have any suggestions for better ranges for these, @jrouwe, or just a better lower bound?

The current default is 1, so a higher max would be possible. But the range 0, 1 with the ability to type a higher number seems like a good hint to me.

@Calinou Is there anything in particular I have to do to trigger this, besides just starting the demo? I don't seem to be able to reproduce this (on Windows).

On my end, I just need to start the demo (even through the command line using --path path/to/project/folder). I'm on Linux.

Can confirm this does unfortunately not fix https://github.com/godotengine/godot/issues/100040.

Does switching to Jolt really "fix" the linked issue, as well as others being brought up? The bug will still be there in Godot Physics. If closing those, it's going to be more along the lines of "We won't fix these in favour of Jolt".

Good point, some care is important in how we frame it! It is a fix only in the sense that there is a built-in solution to the issue that does not require addons.
The bug will still occur with default settings. Depending on the stability of this module, we might want to consider deprecating the default one in the future.

On my end, I just need to start the demo (even through the command line using --path path/to/project/folder). I'm on Linux.

@Calinou I just tried on latest Linux Mint, and it seems to work fine for me there, weirdly enough.
Is anyone else here able to run the 3D physics tests project on Linux to see if it crashes?

Just so it doesn't get missed, I've dropped the 3D suffix from the registered name of the physics engine/server, so you'll need to change your physics/3d/physics_engine project setting to be JoltPhysics instead of JoltPhysics3D. If you don't, you'll end up using the default engine (i.e. Godot Physics).

First of all, I'm really happy that Jolt is being considered as part of the engine and not just a third party plugin. Massive congratulations to Mihe, jrouwe, and the people that made the plugin perfect.
@mihe, when developing the plugin, some bug reports were dismissed because they were impossible to fix due to plugin interface limitations. For example, this, where you were limited by how Godot does shape-casting. Does Godot Jolt becoming an engine module mean that you will be able to fix things that you were previously limited by the GDNative interface? As another example, would doing this be easier due to it not requiring modifications to GDNative?

Does Godot Jolt becoming an engine module mean that you will be able to fix things that you were previously limited by the GDNative interface?

@Gamepro5 It's still a somewhat unanswered question what exactly the future of the physics interface is going to look like, and I'm not any authority on the matter either. I'm sure there's going to be some interest from the community in seeing certain Jolt-specific things exposed pretty quickly, but so long as Godot Physics 3D remains the default engine I imagine there will/should be some requirement to implement any new feature in both engines still.
As mentioned in the PR description there have been discussions surrounding exposing engine-specific node properties in a way that doesn't add to the shared interface, which might perhaps be extendable to node methods eventually as well, but things like adding to the query results (to expose things like surface normals) on a per-engine basis hasn't really been talked about (as far as I'm aware) and is less obvious to me how you'd achieve.
Despite some quirks in the current interface (e.g. joints, cast_motion, body_test_motion) I've personally been happy with how applicable it seems to be to a number of physics engines out there. It would be great to preserve that, and perhaps even remove things from that shared interface that are deemed not generic enough, while still allowing for engine-specific features somehow.

Is anyone else here able to run the 3D physics tests project on Linux to see if it crashes?

Ubuntu 24.04.1 on WSL is running fine.
However, on Windows the physics_tests scene crashes on load in the editor even before I can select JoltPhysics as engine. Something in the controls framework (didn't appear to be related to physics), unfortunately I didn't capture the callstack and it was gone after a full rebuild, so it looks like a build dependency issue.

I think these are most or all the major Jolt features that aren't exposed:

Tapered Capsules and Cylinders.
There is like double the joint/constraint types.
Tracked vehicles and motorcycles.
The ragdoll system?
Character Simulation.
Water buoyancy.

Some of my thoughts:
VehicleBody3D could probably be reworked to being a more generic node that other ones would inherit from.
Jolt's Virtual Character seems to mostly align with Godot's Character Bodies, albeit with some extra features (like stairs). Though I believe Character Bodies should be split into general kinematic bodies and more specialized character bodies.
Maybe buoyancy could be added as a property of Area3D? It already has things like wind, reverb and overriding physics parameters.

I believe Character Bodies should be split into general kinematic bodies and more specialized character bodies

AnimatableBody3D is the node for a general kinematic body (although the sync_to_physics flag is a bit confusing for users IMO)

Squashed and rebased, and I also threw in some minor documentation changes for the project settings. I'd appreciate another pass on the documentation, @Mickeon.
@jrouwe I'd appreciate if you could look over the documentation for the project settings as well, if you haven't already. I'd hate to be misrepresenting Jolt in some way. In particular I'm curious if my layman's understanding of speculative contacts in the documentation for speculative_contact_distance setting was correct. I couldn't seem to find any documentation for how speculative contacts are used within Jolt specifically, so I threw in my rough understanding of them.

(This has a linked proposal, is that not solved by this? Otherwise this should be an enhancement and not a feature proposal)

@AThousandShips I thought a large enchancement is considered as feature proposal. At least it was in the past.

The current use is for when the PR itself serves as a proposal, when no dedicated proposal exists

I would suggest making the project setting for the physics engine a "basic" setting so it's easy to find for users who want to test Jolt.

Would I do that in this PR?

Also, as mentioned in the pull request description, and mentioned in passing in other conversations, this module should ideally be considered experimental for the near future. With that in mind, do we perhaps want to change the registered server name to be something like JoltPhysics (Experimental) rather than JoltPhysics, so it's very obvious, or is it fine to just have it be mentioned somewhere in the release blog post?
(I guess that also begs the question why there isn't a space inbetween Jolt and Physics, if we want to bikeshed even more.)

I would suggest making the project setting for the physics engine a "basic" setting so it's easy to find for users who want to test Jolt.

Would I do that in this PR?

Yeah I would suggest so, so it's easy to test right away. And it's a pretty minor change well justified by adding a secondary builtin physics engine for 3D.

Also, as mentioned in the pull request description, and mentioned in passing in other conversations, this module should ideally be considered experimental for the near future. With that in mind, do we perhaps want to change the registered server name to be something like JoltPhysics (Experimental) rather than JoltPhysics, so it's very obvious, or is it fine to just have it be mentioned somewhere in the release blog post?

We'll mention it in the blog post for sure, but if you want to make the visible name include  (Experimental), I think that's fine. I suppose the actual integer value won't change so when we decide to drop the  (Experimental) bit it won't break compat.

(I guess that also begs the question why there isn't a space inbetween Jolt and Physics, if we want to bikeshed even more.)

It can definitely be Jolt Physics (Experimental) :D
The name there should be the canonical name of the library. I think for Bullet Physics we just had Bullet, but in retrospect it should likely have been Bullet Physics if it's how the project calls itself. Likewise for Jolt Physics.
GodotPhysics3D just happens to be the canonical name we chose for Godot's internal unnamed physics backend, and likewise GodotPhysics2D for 2D. It's not a requirement that physics backends should be PascalCase or with a dimensional suffix :)

I suppose the actual integer value won't change so when we decide to drop the  (Experimental) bit it won't break compat.

There is no integer value backing this, unfortunately. The 3d/physics_engine project setting is a string, which is the registered server name. So this would presumably need some sort of migration code when we decide to drop the  (Experimental) part.
Should I still go ahead with adding it?

Then I wouldn't add the  (Experimental) part, we'll just make it clear elsewhere.

If Jolt is going to be the default after going out of "experimental" then I believe changing the name wouldn't matter since it'd just fall back on itself.

If Jolt is going to be the default after going out of "experimental" then I believe changing the name wouldn't matter since it'd just fall back on itself.

It would still keep the Jolt Physics (Experimental) value for the setting itself though, which will manifest as a blank value in the project settings, even when re-saving the project.
Frankly, the silent fallback that's currently happening should be an error instead.

Anyway, so...

⚠ The registered server name is now Jolt Physics instead of JoltPhysics, so anyone messing around with this PR still will need to change physics/3d/physics_engine once again.
Both physics/3d/physics_engine and physics/2d/physics_engine are now considered basic settings, and thus won't require toggling "Advanced Settings" in the project settings dialog anymore.

I don't believe there are any more pending issues to resolve.

Thank you @mihe and @jrouwe for this amazing contribution!
Jolt has proven to be an excellent fit for Godot, especially after all the work done upstream to accommodate our high level API and ensure we can preserve as much compatibility as possible.
The result as of this PR is a drop-in replacement that covers most of the API and should work well for most games. The remaining parts which don't have parity yet will be evaluated in coming months while our Godot Jolt integration goes from experimental to production ready, and eventually if all goes well the new default physics engine.
Thanks also for all the work put into godot-jolt, which helped ensure and proved that GDExtension is suitable for adding major functionality like a whole new physics API, and to iterate quickly in a community project without being held back with the upstream core bureaucracy. Being able to then convert the GDExtension using godot-cpp to a core module was also part of the intended design of godot-cpp, aiming to keep as much of the API matching what Godot C++ modules can do.
Let's get this well tested and ironed out for the 4.4 release!

Awesome! I'm excited to see where things go from here. Hopefully we can smooth out whatever rough edges there are currently and eventually make Jolt the default 3D physics engine.
Also, a big thank you to everyone who took the time to try out the extension and report issues during these past two years. This module would likely have been in a much rougher state (if at all) without the battle-testing from the community.

This is very cool! My thanks goes out to @mihe for spending so much time in making this plugin. Jolt really improved due to all the issues he found and requests he made! It has been a joy working together!
Looking forward to the last push to make it production ready! Feel free to tag me on any issues that are reported. Also it would be nice if there was a label that I can filter on to quickly find issues reported against this module, e.g. label:topic:joltphysics.

Also it would be nice if there was a label that I can filter on to quickly find issues reported against this module, e.g. label:topic:joltphysics.

We could add this easily, but it would be quite specific compared to our other labels which typically encompass whole systems (like topic:physics).
We do have a need for more granularity but labels won't cut it (we'd need to multiply the amount of labels by 3-5 to cover everything), instead we're working on preparing some public GitHub projects for each team/system (basically each topic: label), which will have further categorization. So once this is done you should be able to find and filter issues with the Jolt Physics category in the (upcoming) Physics team issue triage project.

Спасибо @mihe и @jrouwe за этот замечательный вклад!
Jolt отлично подходит для Godot, особенно после того, как мы проделали всю необходимую работу, чтобы адаптировать наш высокоуровневый API и сохранить максимальную совместимость.
В результате этого PR-запроса мы получили замену, которая охватывает большую часть API и должна хорошо работать в большинстве игр. Остальные части, которые ещё не имеют аналогов, будут протестированы в ближайшие месяцы, пока наша интеграция Godot Jolt переходит от экспериментальной к готовой к использованию, и в конечном итоге, если всё пойдёт хорошо, станет новым физическим движком по умолчанию.
Также спасибо за всю работу, проделанную над godot-jolt, которая помогла убедиться в том, что GDExtension подходит для добавления основных функций, таких как совершенно новый физический API, и для быстрой работы над проектом сообщества без бюрократии, присущей ядру. Возможность преобразовать GDExtension с помощью godot-cpp в основной модуль также была частью задуманного дизайна godot-cpp, целью которого было сохранить как можно больше API, соответствующего модулям Godot C++.
Давайте тщательно протестируем и исправим это для версии 4.4!

Maybe there is a chance that it will come out with Godot 4.3? Even in test mode. Godot 4.4 will not be released anytime soon.

First of all. Nice work.
One thing that would be a game changer for my game project, which heavily relies on modifying compound, rigid bodies with sometimes hundreds of shapes would be to be able to offload the updating process of these bodies to a worker thread. This would cause the body, and then replacing the body a few frames later. This would greatly reduce the risk of frame rate drops upon adding or removing shapes to a body. The trade-off to wait for a frame or two to get the new shape in place would in this case be more than reasonable in my opinion. This could practically be achieved through adding an opt-in bool parameter in the PhysicsServer3D.body_[add/remove]_shape or by a project setting. Would you @mihe think this would be an impossibility?

On another note. Will Godot's 64-bit precision option work within this framework?

It should: https://github.com/godotengine/godot/blob/b9437c393871c377b5ece131afaf831e78dfb6f8/modules/jolt_physics/SCsub#L155
See also about how it was added: https://github.com/jrouwe/JoltPhysics/issues/94#issuecomment-1242900556

Is the common/physics_interpolation function of Godot adapted to JOLT?@mihe

Is the common/physics_interpolation function of Godot adapted to JOLT?@mihe （godotengine/godot/pull/92391）

Yes, physics interpolation works out of the box with Jolt.

I suppose jolt being now part of the Godot engine, I should file bug reports for it in Godot Engine's issues, right?

I suppose jolt being now part of the Godot engine, I should file bug reports for it in Godot Engine's issues, right?

To be clear, the Jolt project is still a standalone library that has its own development priorities and issue tracker.
If you have issues with Jolt in Godot, then yes those issues should be filed in the Godot repository.

If you have issues with Jolt in Godot, then yes those issues should be filed in the Godot repository

To add to this, if the bug is manifesting with the Godot Jolt extension then you're welcome to continue reporting them to the godot-jolt/godot-jolt repository, just to avoid burdening the Godot repository with stuff that might perhaps be extension-specific. I'll fix whatever needs fixing in both repositories for the foreseeable future, and cross-report the issue if it's something more long-term.
If the bug is manifesting in this new engine module, then definitely report it to the Godot repository.

One thing that would be a game changer for my game project, which heavily relies on modifying compound, rigid bodies with sometimes hundreds of shapes would be to be able to offload the updating process of these bodies to a worker thread. This would cause the body, and then replacing the body a few frames later. This would greatly reduce the risk of frame rate drops upon adding or removing shapes to a body. The trade-off to wait for a frame or two to get the new shape in place would in this case be more than reasonable in my opinion. This could practically be achieved through adding an opt-in bool parameter in the PhysicsServer3D.body_[add/remove]_shape or by a project setting. Would you @mihe think this would be an impossibility?

@albinaask This discussions is probably better suited for a proposal, but it's certainly not impossible. The question is more of whether there are other approaches that can help alleviate this without burdening the shared PhysicsServer3D interface or throwing threads (and potential concurrency issues) at the problem, like introducing the hybrid/deferred compound shape mentioned in the PR description, and/or allowing for the use of Jolt's MutableCompoundShape instead.

How will Godot integrate Jolt's ability to work with vector instructions (SSE, AVX etc)?

@albinaask As far as I know, Jolt should automatically make use of whatever instruction sets are enabled/defined during compilation, which for Godot is SSE2 by default. If you want more than this (SSE4.2, AVX, etc.) you'll need to pass the appropriate compiler options (e.g. -mavx for GCC/Clang) through something like Godot's ccflags SCons option.

Thats a great news♥ Thank a lot for your hard work. Looking foward to benchmark this a lot. :)


Invoke-WebRequest / Invoke-RestMethod ContentType problem

Steps to reproduce
Try to use dropbox API https://www.dropbox.com/developers/documentation/http/teams#team-get_info
I'm passing explicit -ContentType 'application/json' and getting error Bad HTTP "Content-Type" header: "application/x-www-form-urlencoded"
Invoke-RestMethod -Uri https://api.dropboxapi.com/2/team/get_info -ContentType 'application/json' -Headers @{"Authorization" = "Bearer $AUTH_TOKEN" } -Method POST

Expected behavior
Success, like when I call
curl -X POST https://api.dropboxapi.com/2/team/get_info --header "Authorization: Bearer $AUTH_TOKEN"

Actual behavior
Current behavior just returns generic error, see #2193
Here is the output deobfuscated with my hotfix
Error in call to API function "team/get_info": Bad HTTP "Content-Type" header: "application/x-www-form-urlencoded".  Expecting one of "application/json", "application/json; charset=utf-8", "text/plain; charset=dropbox-cors-hack".

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   <IP_ADDRESS>
GitCommitId                    v6.0.0-alpha.14-78-gaa764dd54edd5b214eb1fcb67aba5370014e7663-dirty
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

I read the code a little bit and it could be dotnet problem O_o
So, if endpoint require some payload, I can run Invoke-RestMethod -Uri https://api.dropboxapi.com/2/team/groups/list -ContentType 'application/json' -Headers @{"Authorization" = "Bearer $AUTH_TOKEN" } -Method POST -Verbose -Body (@{'limit' = 100} | ConvertTo-Json)
And I get a good response
But if it doesn't require, the Content-Type header is not getting set.
If I add dummy -Body '', I getting Error in call to API function "team/get_info": request body: could not decode input as JSON

@vors I looked at this and it does appear to be a limitation with dotnet.  They don't allow Body to be null and having Content-Type header.  Best we can do here might be to output a warning that ContentType isn't being used if the Body is not specified.  Based on my reading of RFC2626 you should be allowed to specify Content-Type without a Body.

@SteveL-MSFT thanks for confirming. That was my understanding as well.
It seems dotnet-core specific, because in the Full framework, there is a separate field for the ContentType.
That pretty much prohibits using most of the Dropbox API v2 endpoints from PowerShell core and from dotnet core as well. For example https://github.com/dropbox/dropbox-sdk-dotnet could not be ported to dotnet core.

@vors did you open an issue against corefx?  We should ref it here

BTW, on the full version of PS v5.1 I'm getting another error
Invoke-WebRequest : Error in call to API function "team/get_info": request body: could not decode
input as JSON
At line:1 char:1
+ Invoke-WebRequest -Uri https://api.dropboxapi.com/2/team/get_info -Co ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke
   -WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWe
   bRequestCommand

After conversation in corefx issue, it seems that -Body "null" workaround is the right way to do it in the dropbox case.
Meanwhile, I think that powershell side of things could be improved.
Particualrly, I don't like the fact that powershell silently ignores -ContentType 'application/json'.

@vors so the workaround is to have the word null in the body?

@SteveL-MSFT in the dropbox v2 API case yes.
There could be different API endpoints that may be unavailable because of a similar issue, I don't have data about it.

@markekraus Could you please look the Issue?
@vors Currently we was moved to .Net Core 2.1 with new WebClient - could you update status of the Issue?

Hey it works on 6.1.0 :) 👍

Can this be re-opened ? This is still an issue in 6.2.1
Invoke-WebRequest -Method Post -ContentType 'application/json' $url

This does not send content type header at all !
When I run it in 5.1.18922.1000 it works. I''ve also tested this on windows 8. Same behaviour
Name                           Value
----                           -----
PSVersion                      6.2.1
PSEdition                      Core
GitCommitId                    6.2.1
OS                             Microsoft Windows 10.0.18922
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

@yar05 Please open new issue with repo steps and reference the issue.

@yar05 this appears to be an optimization by .NET.  Content-Type is only necessary if there is a body to indicate the media type of the body content.  Since you are not providing a body, that header doesn't get included.  If you try:
Invoke-WebRequest -Uri "http://httpbin.org/headers" -ContentType "application/json" -Body "test"

You'll see
StatusCode        : 200                                                                                StatusDescription : OK                                                                                Content           : {
                      "headers": {
                        "Content-Length": "4",
                        "Content-Type": "application/json",
                        "Host": "httpbin.org",
                        "User-Agent": "Mozilla/5.0 (Macintosh; Darwin 18.6.0 Darwin Kernel Version 18.6.0:…
RawContent        : HTTP/1.1 200 OK
                    Access-Control-Allow-Credentials: true
                    Access-Control-Allow-Origin: *
                    Date: Fri, 05 Jul 2019 20:45:47 GMT
                    Referrer-Policy: no-referrer-when-downgrade
                    Server: nginx
                    X-Content-Type-Optio…
Headers           : {[Access-Control-Allow-Credentials, System.String[]], [Access-Control-Allow-Origin, System.String[]], [Date, System.String[]], [Referrer-Policy, System.String[]]…}
Images            : {}
InputFields       : {}
Links             : {}
RawContentLength  : 300
RelationLink      : {}


Brian/key wallet collateral

Closes # .
Pre-review checklist

[ ] All code has been formatted using our config (make format for Purescript, nixpkgs-fmt for Nix)
[ ] All Purescript imports are explicit, including constructors
[ ] All existing examples have been run locally against a fully-synced testnet node
[ ] The integration and unit tests have been run (npm run test) locally
[ ] The changelog has been updated under the ## Unreleased header, using the appropriate sub-headings (### Added, ### Removed, ### Fixed)

I was able to confirm that this works downstream.


Add google analytics functions

Add google analytics functions on Views and Events.

@hectoruch can you check the conflicts please?

Conflicts resolved 😁


[BUG] fzf-tmux doesn't work when invoked from a noninteractive shell

[x] I have read through the manual page (man fzf)
[x] I have the latest version of fzf
[x] I have searched through the existing issues

Info

OS

[x] Linux
[x] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[ ] bash
[x] zsh
[ ] fish

Problem / Steps to reproduce

Run tmux new  bash -c 'echo 1 2 3 | fzf-tmux -p90'. It exits without showing the popup. Running eval 'echo 1 2 3 | fzf-tmux -p90' on an interactive shell works as expected.

Does tmux new bash -c 'echo 1 2 3 | fzf-tmux -p90%' work? (90% instead of 90)

@junegunn commented on Oct 5, 2020, 5:10 PM GMT+3:30:

Does tmux new bash -c 'echo 1 2 3 | fzf-tmux -p90%' work? (90% instead of 90)
fzf-tmux may fail if the specified width and height exceed the actual screen size.

Seems to work. Thanks!


Create event section

Library name(s)
MarkDoc.Generator.Basic
Description
Add the ability to print detailed event documentation
Subtasks

[x] Name
[x] Summary
[x] Remarks
[x] Example
[x] See also
[x] Inherited from (#58)

Total: 15m


i can't compile

hi i get this error, what i've to do?
:
C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\HuyangAudio.cpp: In constructor 'HuyangAudio::HuyangAudio()':
C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\HuyangAudio.cpp:8:26: error: no matching function for call to 'SoftwareSerial::SoftwareSerial()'
8 | HuyangAudio::HuyangAudio()
|                          ^
In file included from C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\HuyangAudio.h:4,
from C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\HuyangAudio.cpp:1:
C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\SoftwareSerial.h:92:3: note: candidate: 'SoftwareSerial::SoftwareSerial(uint8_t, uint8_t, bool)'
92 |   SoftwareSerial(uint8_t receivePin, uint8_t transmitPin, bool inverse_logic = false);
|   ^~~~~~~~~~~~~~
C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\SoftwareSerial.h:92:3: note:   candidate expects 3 arguments, 0 provided
C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\SoftwareSerial.h:50:7: note: candidate: 'constexpr SoftwareSerial::SoftwareSerial(const SoftwareSerial&)'
50 | class SoftwareSerial : public Stream
|       ^~~~~~~~~~~~~~
C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\SoftwareSerial.h:50:7: note:   candidate expects 1 argument, 0 provided
C:\Users\stany\Documents\Arduino\Huyang_Remote_Control\src\classes\HuyangAudio\HuyangAudio.cpp:10:27: error: 'SWSERIAL_8N1' was not declared in this scope; did you mean 'SERIAL_8N1'?
10 |  _audioSerial.begin(9600, SWSERIAL_8N1, AudioSerialPort_RX, AudioSerialPort_TX);
|                           ^~~~~~~~~~~~
|                           SERIAL_8N1
exit status 1
Compilation error: no matching function for call to 'SoftwareSerial::SoftwareSerial()'

please replace the whole project except the config.h
the Missing Software shoud be part of the expressif compiler files.
What board did you select?

please replace the whole project except the config.h the Missing Software shoud be part of the expressif compiler files. What board did you select?

node mcu 1.0

solved just........rebooting the pc!
I don't know what's happened, but suddenly everything worked.
Thanks


Allow accessing send queue count from WebSocketConnection

Allows derived classes to check the send queue count and override SendMessageAsync in case the number of messages in the outbound queue is growing out of control.  Perhaps in the future backpressure options will be available as a built-in feature.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

5 of 5 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.009%) to 94.537%

Totals

Change from base Build<PHONE_NUMBER>7:
0.009%

Covered Lines:
1882

Relevant Lines:
1941

💛  - Coveralls


Coconino County AZ

http://data.coconinocounty.opendata.arcgis.com/datasets/76ca136c49db437aa624ab8f05d493bd_0
rest: https://utility.arcgis.com/usrsvcs/servers/76ca136c49db437aa624ab8f05d493bd/rest/services/OpenData/CoconinoCountyOpenData/FeatureServer/0

(Does duplicate addresses in Flagstaff, but that's okay.)

fix broken link. new page:
https://datahub-coconinocounty.opendata.arcgis.com/datasets/b1765e3b217d4a43a0034ffe70230a39_0
https://services1.arcgis.com/Rlvx5g8pKeK13apH/arcgis/rest/services/County_Addresses/FeatureServer/0


Fix build issues

Fixes https://github.com/coala/corobo/issues/667
Reviewers Checklist

[ ] Appropriate logging is done.
[ ] Appropriate error responses.
[ ] Handle every possible exception.
[ ] Make sure there is a docstring in the command functions. Hint: Lookout for
botcmd and re_botcmd decorators.
[ ] See that 100% coverage is there.
[ ] See to it that mocking is not done where it is not necessary.

Sure. Following is the travis CI build:
https://travis-ci.com/github/codehobbyist06/corobo/builds/223374656


[BEAM-7274] In preparation for protocol-buffer schemas, add OneOf and Enumeration logical types

Add new LogicalTypes to represent enumerations and OneOf types. In order to implement this, we extended the LogicalType argument to be able to have a Schema so that we don't have to encode complicated arguments inside of strings.
R:@alexvanboxel

run sql postcommit

run java precommit

run java precommit

Also added support for enums in the java type mapping. This means that POJOs or JavaBeans (or AutoValues, or any similar type) with Java enums will map to the new EnumerationType.

Run Python2_PVR_Flink PreCommit

Note: fixing the Avro issue requires refactoring a bit. This refactor I already have in another PR as protos require it, so I'll go send that out now.

Note: fixing the Avro issue requires refactoring a bit. This refactor I already have in another PR as protos require it, so I'll go send that out now.

I was indeed wondering how this would Avro would be handled. For me it looks all good.

Added Enum support to Avro. Adding support for generic Avro unions proved complicated (mostly because Avro compiler represents them using an Object type), so best left for another PR; also, it appears that most usages of Avro unions are to represent nullable types, which we already handle.

@alexvanboxel I added Avro support for enums, and have now fixed CheckStyle errors. Let me know how this looks to you.

OK, it took a while... but I've wanted to verify something. I've been experimenting with how Avro compiles to Java code and how the ordinal value is created. I just wanted to check out the following scenario:
 { "name": "foo", "type": { "name": "FooEnum", "type": "enum", "symbols": ["x","y"] }},
we have a schema evolution to:
 { "name": "foo", "type": { "name": "FooEnum", "type": "enum", "symbols": ["a", "x", "y"] }},
we upgrade the pipeline, so the current state is stored. As the ordinal value is stored in the intermediate state and the schema is evolved by pre-pending a enum value, that means the ordinal values changed (as it's sequential as defined in the source file: from x=0 , y=1 > a=0, x=1, y=2 ).
I do notice the same holds through to the Java Enum type. Not to Proto as it has an explicit number value assigned to an Enum string.
I don't know if it's an issue... but I wanted to raise it so you're aware of the side effect. Is a pipeline even upgradable when the schema changes?

Right now we don't support evolving schemas. There is a plan (that needs to be discussed on the dev list for this): but essentially it would require the new pipeline to preserve the old job's ordinal values as much as possible, instead of simply taking them in order.

Right now we don't support evolving schemas. There is a plan (that needs to be discussed on the dev list for this): but essentially it would require the new pipeline to preserve the old job's ordinal values as much as possible, instead of simply taking them in order.

OK, then it's not an issue for now.

Run Java PreCommit

Run Java PreCommit

Run Java PreCommit

Run Java PreCommit

Run Java PreCommit


TestSyncTrigger fails on CI

--- FAIL: TestSyncTrigger-2 (0.01s)
server_test.go:741: len(action) = 0, want 1

More testutil.WaitSchedule() flapping?

@heyitsanthony Probably. We need to spend some time to fix all infra(testing/building/scripting) related issues. :)

I see how to do the server_test.go ones in a sane way, so I'll give nuking WaitSchedule there a shot.

For WaitSchedule, I have an idea: #4121


All Pokemon Go Servers are available in a JSON

https://ispgo.net/api/ is giving all the servers, pings and locations of the servers in a single JSON. It may help your program!

Thanks a bunch, I'm not sure if i'll be able to implement it before the servers become more stable, but I'll try


No License

Seems like a good project, but I don't see a license anywhere, so not clear under what conditions I can use it. Any chance of attaching a license to this (e.g. MIT, BSD, etc..)?

Thanks for opening the issue. Just added MIT license. Sorry for the delay.


[WIP] Add sensors, confidence, and learning_methods in EventFilter

The eventList API requires the functionality to allow users to search for events based on sensors, confidence level, and learning methods (either unsupervised or semi-supervised). Therefore, the ability to filter events using these parameters is included as a feature.

Since cargo clippy generates so many errors, I had to put the below in lib.rs.
#![allow(clippy::missing_errors_doc)]

Since cargo clippy generates so many errors, I had to put the below in lib.rs.
#![allow(clippy::missing_errors_doc)]

We should avoid disabling clippy lints in the source codes. Please set this in your local clippy.toml instead.

Since cargo clippy generates so many errors, I had to put the below in lib.rs.
#![allow(clippy::missing_errors_doc)]

We should avoid disabling clippy lints in the source codes. Please set this in your local clippy.toml instead.

@minshao assisted me in modifying the migration section, but I'm uncertain whether it meets @msk's requirements for DATABASE_VERSION_REQ. Would both of you review the changes and confirm that they are appropriate?


Also test Salt config changes as an upgrade

The current testing always starts from scratch.
However, in practice we do not rebuild all our machines from scratch
on every change, but instead usually incrementally upgrade them.
Run the tests both from scratch, which is used whenever we stand up
a new builder, and as an upgrade from the previous configuration, which
is the more common case.
Additionally, the Salt installation and Salt grains.items and
state.show_highstate commands produce output that is useful for
debugging, but is normally not necessary to view.
Add special markers to the build log that fold these sections on Travis.
This is especially useful with the longer build logs.
Note that this doubles the number of builds run on Travis.
r? @larsbergstrom @edunham

This change is

@bors-servo r+
Thank you!

:pushpin: Commit c66f555 has been approved by edunham

:hourglass: Testing commit c66f555 with merge c54b8be...

:broken_heart: Test failed - travis

@bors-servo r+

:hourglass: Testing commit 075c34d with merge cc05e17...

:sunny: Test successful - travis


RSS/Atom support

feedburner
but can be configured by the bot owner

I like the idea of "reading" an rss feed. Can be usefull in most situation, but should be owner only due to the large ammount of data that can need to be reached (rss feed on a twitter account, etc)

#102


jQuery and mezzanine 4.1.0 and autocomplete-light 2.3.3 in the same ship

Hi,
I'm facing a jQuery dependencies problem with autocomplete 2.3.3. In the admin interface, I uses the mezzanine provided jQuery (1.8.3). It seams to be bound to
window.jQuery
attribute. I'm trying to re-use this jQuery to load the autocomplete stuff with :
{% include "autocomplete_light/static.html" %}
I've done many tries with noConflict, but none seams to work, loading another version of jQuery (2.1.4) at mezzanine level, reloading jQuery before the include... and I'm still stuck.
Have you an idea on how to make it work ?
I've the message :
TypeError: $(...).yourlabsWidget is not a function
Thanks for your great job !

I just had to solve a similar error, it may be worthwhile for you to try the following hack.
Add these lines after your JavaScript imports:
    <script type="text/javascript">
        django.jQuery.fn.yourlabsWidget = jQuery.fn.yourlabsWidget;
    </script>

Not sure if related, just a suspicion.

Now I've lost the left menu in my admin ... I'm in hell, really ...

I've gone a bit. In fact ; the left menu is hidden : it's created (can see it in sources), but hidden : when I click on left border, the main form space in enlarged, the menu does not appears.
This menu is only hidden when I load page with autocomplete-activated forms, is changelist  views it appears correctly.
I've tryed the sef lines :
    <script type="text/javascript">         django.jQuery.fn.yourlabsWidget = jQuery.fn.yourlabsWidget;     </script>
and event tried at many places in the loading flow, but I've always the
TypeError: $(...).yourlabsWidget is not a function error.
The code chunk : admin/base_site.html
`
{% block extrahead %}
{# ... copy of mezzanine page  #}

{% if debug %}
    <script src="{% static "jquery/dist/jquery.js" %}"></script>
{% else %}
    <script src="{% static "jquery/dist/jquery.min.js" %}"></script>
{% endif %}
<script type="application/javascript">
    if (typeof (jQuery) != 'undefined') {
        window.$ = jQuery;
        console.debug('jQuery.fn.jquery = ' + jQuery.fn.jquery);
    }
</script>
{% include 'autocomplete_light/static.html' %}
<script type="text/javascript">
    django.jQuery.fn.yourlabsWidget = jQuery.fn.yourlabsWidget;
</script>
<!-- /autocomplete -->

{% block extrahead %}
`

Instead, may i suggest that you override admin/jquery.init.js to remove
noConflict(true) perhaps ?
Or set up an example project so that we can try to debug it ?
Otherwise maybe try v3 ?

autocomplete works !!
I've put :
    {% include 'autocomplete_light/static.html' %}     <script type="text/javascript">         django.jQuery.fn.yourlabsWidget = jQuery.fn.yourlabsWidget;     </script>
at the bottom of the footer block without any jQ reloading. But my left menu not yet...

:guitar:
Please reopen if needed. The best would be to PR to add test_project/settings/mezzanine.py so we could even add it in CI.


Implement slot sharing support

This PR implements slot sharing, which at the very least should work.
The core logic is remarkable similar to how vertices were handled so far.
To compute the requirements we no longer use the summed parallelism over all vertices, but instead the summed max parallelism of all slot sharing groups,
Free slots are not distributed over vertices, but slot sharing groups.
The vertex parallelism is then determined within the SlotSharingGroup; it is either the number of slots the group has been provided with or the vertex parallelism, whichever is slower.
Once we have the parallelism we can generate the ExecutionVertexIds, reserve all the slots we received, wrap them in a SharedSlot, and then allocated the logical slots from it.
The contained test run a job with 2 vertices with a pipelined data exchange within a single SlotSharingGroup, on a cluster with only 1 slot total. The job is run twice to make sure the slot release works properly.
The following things are not explicitly handled:

CoLocation constraints: As it is, given N vertices in one slot sharing group the i-th subtask of each are deployed into the same slot, which seems to fulfill the core requirement? What I'm not sure about is whether the scheduler is responsible for matching the parallelism, or whether the JobGraphGenerator handles this earlier.
Input Locality: Not relevant for streaming?
Prior Locations: If we want to account for this when re-scaling then we'll need some data-structure outside the EG that tells us where we deployed things on a previous run, or keep the old EG around.

Re existing classes: The SlotSharingExecutionSlotAllocator was a somewhat good guide on what is needed, but it is really setup for asynchronous operations which we don't really need currently.

Merged into declarative-scheduler branch.

Merged into declarative-scheduler branch.


Train data and Openset issues

Hello,
The practical test set seems to have only paintings and not real/fake photos, so I was wondering if it is a better idea to benchmark the model on a combination of the two. Then, I referred to the provided Openset and was confused why all the names are prepended by real_ - aren't all the images there generated by GANs/DMs? What real_ stands for in the image names?
Finally, to make it possible for other studies to compare to yours, can you provide the full training set (or scripts to generate it from the datasets mentioned in the paper so it doesn't have overlaps with the provided test sets)? I wanted to reproduce your results by training LASTED on my end and then updating the way it works to see if improvements can be made. In that regard, providing any random seeds, etc. used during benchmarking would be appreciated as well, so the same metric values could be optained.

Thanks for your attention.

Since the Openset testset has included the combination of  real/fake photo/paintings, we only collect some real/fake paintings in the Practical testset.

The name of the folders in the Openset test means the data sources (e.g., ImageNet_VISION_BigGAN means the real data are from ImageNet and VISION, while the fake data are from (generated by) the BigGAN). The “real_” just for a more convenient metric calculation, as we only need to classify/cluster the data into “real” and “fake” classes.

Sure. We will release all the training data soon.

The training dataset can be downloaded from the following link. Due to Google Drive's capacity limitations, we are currently only able to share it via Baidu Pan: https://pan.baidu.com/s/1ZgSiNX_Dd7cZcwiHv1ujVg?pwd=h4p7

Thank you.


availability_zone aware deploy

This commit extends the deploy constraint functionality from tag-aware to availability_zone-aware deploy, though different in:
tag-aware choose X number of hosts from each tag groups, and deploy in parallel.
az-aware choose X number of hosts from one group only, and deploy group by group.

in this example deploy in order of:  us-east-1c -> us-east-1a -> us-east-1d

likestamp


Add api-module and admin for User-Permissions

Succeeds https://github.com/vivid-planet/comet/pull/1223
Just adds api and admin-parts for administrating permissions and content scopes.
No incompatible change, doesn't do anything with the current user rights.
Known issues:

DatePicker delivers wrong date (has to be solved in DatePicker-package)

@fraxachun please resolve the problem with the lint check, then we're good to go

@fraxachun please resolve the problem with the lint check, then we're good to go

@johnnyomair Here we go


New Release

Since release 1.1.0  one more changed applied to the repo, which is mandatory.
Thank you !!

I just have to rebuild the binary based on the latest commit?

I just have to rebuild the binary based on the latest commit?

Looks good to me, you can close the issue :)


Improve the route group concept

I propose you an improvement of the RouteGroup concept. The change is small but the impact is great.
The idea is that I can create complete decoupled routes group and create nice modular application.
A new method addRouteGroup was added in RouteGroup class to allow as to add anytime a route group to another group.
Before:
class DemoApplication extends Application {

    @Override
    protected void onInit() {
        addRouteGroup(new AdminRoutes(this));
    }

}

class AdminRoutes extends RouteGroup {

    public AdminRoutes(Application appplication) {
        super("/admin");

        // BEFORE FILTERS
        addBeforeFilters();

        // ROUTES
        addRoutes();

        // GROUPS
        application.addRouteGroup(new UserRoutes(this));
        application.addRouteGroup(new CustomerRoutes(this));
    }

}

After:
class DemoApplication extends Application {

    @Override
    protected void onInit() {
        addRouteGroup(new AdminRoutes());
    }

}

class AdminRoutes extends RouteGroup {

    public AdminRoutes() {
        super("/admin");

        // BEFORE FILTERS
        addBeforeFilters();

        // ROUTES
        addRoutes();

        // GROUPS
        addRouteGroup(new UserRoutes());
        addRouteGroup(new CustomerRoutes());
    }

}

So, now each RouteGroup is total separated, without a dependencies to parent (I don't need to know when I create a RouteGroup where the group will be mount). For example I can have a modular web application (built with PF4J or other plugin framework) where each plugin comes with own independent routes (user management -> UserRoutes, customer management -> CustomerRoutes, ...). At runtime I can add these groups (discovered automatically by PluginManager via getExtensions(AppRoutes.class) method for example).
The RouteGroup is a concept very import when you are forced to deal with a considerable number of routes in your application.
The PR comes with some unit tests and I don't think that break the backward compatibility with the actual released version.

Coverage increased (+0.2%) to 20.447% when pulling 2c7db989d9ba1f3bd3206170a515747852d9130e on improve_route_group into f143f3172933d35c50265e039323ff8dc3a03dce on master.


Replace async_connect() with am::async_underlying_handshake().

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.42%. Comparing base (22b5dad) to head (f4c8bf1).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #249   +/-   ##
=======================================
  Coverage   89.42%   89.42%
=======================================
  Files         121      121
  Lines        7915     7925   +10
=======================================
+ Hits         7078     7087    +9
- Misses        837      838    +1

see 1 file with indirect coverage changes


fix(text): added spacing

Added top & bottom margin to headlines & body

Should we recommend nesting tags within our component? because right now in docs it shows both as optional?

I think we can still keep them both


Compilation fails for gRPC applications in dev mode

Bug description
I finally realize why Quarkus does not exclude Findbugs in grpc-common.  Seems gRPC has a number of occurrences of javax.annotation.CheckReturnValue:
https://github.com/search?q=repo%3Agrpc%2Fgrpc-java+CheckReturnValue&type=code&p=1
Which results in the following compilation error because we are excluding findbugs here:
https://github.com/apache/camel-quarkus/blob/main/extensions/grpc/runtime/pom.xml#L41-L45
Seems to not occur outside of dev mode though.
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] cannot access javax.annotation.CheckReturnValue
  class file for javax.annotation.CheckReturnValue not found
[INFO] 1 error
[INFO] -------------------------------------------------------------

The simplest fix would be to remove the Findbugs exclusion.

@ppalaga Is there any way of ignoring the dependency ban for Findbugs exclusively in the grpc/runtime module? Or would the ban have to be removed globally (maybe undesirable)?

Yeah, I also recollect gRPC was a special about findbugs.
We could try to redefine the rules in this module, something like
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-enforcer-plugin</artifactId>
                        <dependencies>
                            <dependency>
                                <groupId>io.quarkus</groupId>
                                <artifactId>quarkus-enforcer-rules</artifactId>
                                <version>${quarkus.version}</version>
                            </dependency>
                            <dependency>
                                <groupId>org.l2x6.cq</groupId>
                                <artifactId>cq-filtered-external-enforcer-rules</artifactId>
                                <version>${cq-plugin.version}</version>
                            </dependency>
                        </dependencies>
                        <executions>
                            <execution>
                                <id>camel-quarkus-enforcer-rules</id>
                                <goals>
                                    <goal>enforce</goal>
                                </goals>
                                <configuration>
                                    <rules>
                                        <requireJavaVersion>
                                            <version>11</version>
                                        </requireJavaVersion>
                                        <dependencyConvergence />
                                        <filteredExternalRules>
                                            <location>classpath:enforcer-rules/quarkus-require-maven-version.xml</location>
                                        </filteredExternalRules>
                                        <filteredExternalRules>
                                            <location>classpath:enforcer-rules/quarkus-banned-dependencies.xml</location>
                                            <xsltLocation>${maven.multiModuleProjectDirectory}/tooling/enforcer-rules/quarkus-banned-dependencies.xsl</xsltLocation>
                                        </filteredExternalRules>
                                        <filteredExternalRules>
                                            <location>${maven.multiModuleProjectDirectory}/tooling/enforcer-rules/camel-quarkus-banned-dependencies.xml</location>
<!-- Exclude findbugs in this module -->
                                            <xsltLocation>${maven.multiModuleProjectDirectory}/tooling/enforcer-rules/exclude-findbugs.xsl</xsltLocation>
                                        </filteredExternalRules>
                                        <filteredExternalRules>
                                            <location>${maven.multiModuleProjectDirectory}/tooling/enforcer-rules/camel-quarkus-banned-dependencies-spring.xml</location>
                                        </filteredExternalRules>
                                    </rules>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>

where tooling/enforcer-rules/exclude-findbugs.xsl could be adapted from the existing tooling/enforcer-rules/quarkus-banned-dependencies.xsl

It's actually "allow findbugs" rather than "exclude findbugs"


WIP: extend AttributeType to XdmfTimeSeries

This is intended to fix #522.

I noticed that the instance method XdmfWriter._attribute_type doesn't refer to its first argument and so could be redefined as static; however, since that class is unrelated to XdmfTimeSeriesWriter, I think they can only share the code by both importing it as a module function from common.


ApiManagement - certificates in backends

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[*] Other, please clarify :  updating spec to reflect changes made in preview version which is already deployed. no changed in stable versions.

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet

Already deployed

When you expect to publish swagger? Please provide date, or month to public if date is not available yet.

If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[] SDK of .NET (need service team to ensure code readiness)
[] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[* ] No, no need to refresh for updates in this PR

Contribution checklist:

[*] I commit to follow the Breaking Change Policy of “no breaking changes
[*] I have reviewed the documentation for the workflow.
[*] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@leni-msft , do we need to create work item to approve breaking changes?
It's a preview version, as I understand, we don't need to approve breaking changes for preview, right?

Hi @vfedonkin, PublicPreview version is also in scope, according to the breaking change policy.

@leni-msft , I will create approve request, thank you

@leni-msft , I will create approve request, thank you

approval request: https://msazure.visualstudio.com/One/_workitems/edit/9060196

approval request: https://msazure.visualstudio.com/One/_workitems/edit/9060196


Revert "Default measureCpuGpu to true"

Reverts flutter/flutter#66386
This broke our device lab tests.
TBR: @zanderso

Merge on red to fix the tree.


Document About page

Overview
Document file and code structure for About page
Action Items

[ ] Document file and code structure for About page

Resources/Instructions
Civic Tech Index Site Architecture documentation can be updated here

@maxskewes good start to the About page documentation.  I would that the About component is the main component that displays the overall page content.  Also mention any other important components/variables used and use the "backtick" markup so that they stand out in the documentation.  The Home page documentation has multiple markup locations if you need a reference.  Thanks!

Updates look good.  Thanks @maxskewes !


Use NPMCDN bower.zip package, fixes #250

Fixes #250

So what's the magic incantation to make this work upon publish?

As soon as it is merged and you published new version to npm (patch would be ok I guess), you can check it with
bower install --save https://npmcdn.com/react-motion/bower.zip

Then obviously check the bower_components dir to make sure react-motion has right files in there (as well as dependencies: react)

Sounds great to me! Thanks

Publish new version on npm?

Repo's currently undergoing some refactoring so I can't push yet. But we could theoretically revert to latest stable, put a new tag, then publish again... Does that even work?

Yeah, why not. Works pretty well =)


Set default values according to Spec by @purkhusid + changes from review

@purkhusid I know it's been a long time, and I'm sorry I wasn't able to do it sooner, but I read through all of your changes.
I had to rebase the changes over the new main, and made a bunch of changes of my own. Most notably, there is no need to commit the files generated by running the test scripts to the repository, and the test script wasn't working on Windows, so I had to update it to run in git bash.
I'm leaving this branch intact in case you want to review my changes. You can tell me to delete it once you're done.