Source of truth for Transform data

Currently the Transform is not considered the ssot for position, rotation, and scale (based on the comments in transform.rs). However in the examples (3d_scene, load_model) translation and rotation for the Camera3dComponents is usually never set. This could cause confusion in regards of the ssot of the position, rotation and scale data.
The position data will be needed in the future to calculate more advanced pbr shaders.

I would propose another solution to this problem (copied from another issue that has been closed as duplicate)
Wherever Transform is required, if there is none attached, build it (maybe with #266) from Translation, Rotation or Scale, or Trasform::identity(), if nothing else is present. DynamicBundles would have to restrict creation to just Transform, which could however incorporate Translation, Rotation and/or Scale by using the above mentioned TransformBuilder.

Yeah currently transform is the "output" used in shaders, but position, rotation, and scale will be used to set the Transform, if they exist. The benefits are that systems can pull in exactly what they want, which is faster (less memory being accessed) and easier to parallelize.
The downside is that Transform needs to be updated after app logic finishes, which means Transform will be a frame behind in the UPDATE stage. It also creates issues like "setting the transform does not automatically update source components.
The alternative is to use a combined transform for everything. We are heavily considering this option.
The Amethyst folks have already discussed the issue at length, so please read that thread first before weighing in here: https://community.amethyst.rs/t/legion-transform-design-discussion

Couldn't we update the Transform every time Scale, NonUniformScale, Rotation, or Translation are mutated, and visa versa? That way, the Transform and the individual components are always kept in sync. What am I missing?

+1 for using a single transform component. My rationale was on the thread linked by @cart here: https://community.amethyst.rs/t/legion-transform-design-discussion/1582/16?u=aclysma

@cart great thread! I think this post summarizes it fairly well.
@GrantMoyer That's kind of the idea, but instead we would have one Transform-component that implements e.g. translate(). The problem lies more in the hierarchy: When a Transform is translated, for example, all children would have to be moved as well, which is not possible without access to them. You can look at the linked post for how the amethyst folks want to solve this.
As I see it, the biggest drawback of their solution, in terms of performance, is that there are more matrix calculations needed to be done by the CPU. In terms of usability it would be nice to be able to mutate the global-part of the Transform.
I think, however, those drawbacks are negligible, at least for the moment. A possible solution for the performance-part could be to load it off to a compute shader, if it all happens at the same time and I'm not terribly mistaken.
Another extension to this solution could still be to allow just e.g. a Translation-component on the entity and create a Transform based on that. Also, could it be possible to perform those global transform calculations in visible_entities_system(..)?.
What do you guys think about the linked solution?

I think this issue can be closed now.

@cart @MarekLg @aclysma I'm sorry I didn't know about Bevy until a few days ago, so didn't know about this conversation. I wrote the original legion_transform library. I'm all for a 'simpler' API if you guys feel that's a better fit for Bevy (I personally much prefer separate Translation/Rotation/Scale components as keeping entity sizes down is crucial for ECS performance and being able to 'throw entities at the problem'). I'm sorry so much work has already gone into this, but...
You cannot store the source of truth for an Affine transform as a mat4, it accumulates significant errors over time as you manipulate rotation. This is because rotation and scale are encoded together in the upper left 3x3, rotation will end up effecting scale and it will drift, see this article for example. This must be reverted back to separate Translation (Vec2/3), Rotation (Quat3/4), Scale(Float) and/or NonUniformScale (float2/3) even if you chose to have all of those live in one component (which again, I disagree with, but that's your call 🤷♂).
Also NonUniformScale was chosen as an exception not the default because Affine transforms (ones with non-uniforms scale) are evil in games. They incur significant precision errors when converted to a mat4 (especially in a hierarchy), plus they cannot be used by a physics engine in any meaningful way without a nightmarish amount of corner-cases and performance degradation.

@AThilenius thanks for the heads up! You have a lot of context here, so your perspective is much appreciated. We currently make no stability guarantees, so I'm more than happy to make breaking changes in the interest of improving the engine. I'm re-opening this issue and I encourage everyone to weigh in on @AThilenius's comments.

You cannot store the source of truth for an Affine transform as a mat4, it accumulates significant errors over time as you manipulate rotation

This is certainly useful information :smile:
Sounds like a problem we should solve, but how we do that is up for debate:

Completely replace Mat4 with pos/rot/scale inside the Transform component and re-compute matrix on demand when it is asked for. Direct matrix read/writes are now "more expensive" and accessing rotation and scale are now "less expensive".
Revert to the old model. "Transform" is now back to being out of sync during the UPDATE stage. "directly setting" matrix values is now cumbersome because the individual components are the source of truth. I would probably want to work out a nice way to "sync back" direct Transform changes to the "source of truth" components.
Store pos/rot/scale/mat4 together and make sure they stay in-sync internally. This makes the component "very big" and is almost certainly not what we should shoot for. It might be worth benchmarking this just to see how much performance we lose.

NonUniformScale was chosen as an exception not the default

Yeah I totally agree on this. I tried to mirror that in the new transform api by using the "scale" term to refer to a uniform scale: https://github.com/bevyengine/bevy/blob/3abfcad7ab5e194e1b79daedc0234e2d3afbfb24/crates/bevy_transform/src/components/transform.rs#L31

In any case, I don't think we should have a non-source of truth component for the local transform. I think helper methods to set the source of truth are better.

Pulling in @termhn because of her linear algebra / ultraviolet experience

Here's a few more considerations to throw into the mix (why legion_transform was laid out the way that it was 😁)

If LocalToWorld is computed from N transformation types, and LocalToWorld is only requirement for most systems, then pre-baked static objects need only that one component, regardless of their original transforms / hierarchies. This is both a saving on memory, and more importantly runtime did-move checks as these static objects are simply never processed by any transform system. They don't even need to be checked for 'did you move' because they are incapable of moving without an archetype change or someone directly modifying the LocalToWorld which is generally not a good idea because of physics needing access to non-drifting translation/rotation components.
Computing a LocalToWorld isn't "expensive" per se, but it's a very common operation. If you split transformation types into Translation/Rotation/Scale/NonUniformScale then you only pay the cost of incorporating that single transformation into the matrix. For Translation (which is the most common) that's just a vec3 copy.
If all 'movable' objects all have some combination of Translation/Rotation/Scale/NonUniformScale then networking becomes simpler, you don't need any sleep or 'did-move' logic as entities that lack these components will not move. Nor does the entire 4x4 matrix need to be sent over the network, only the Vec3 for Translation in most cases.
Storing transforms for hierarchies (LocalToParent, Parent and Children) separate is also a good idea, because it's surprisingly uncommon once you bake out static objects in a scene. Very few entities actually use transforms at runtime, mostly it's used as an organizational tool in editor. Meaning you want to pay as little cost per-entity that doesn't use hierarchies here as possible (in the case of legion_transform that cost is exactly zero).
Without splitting the components apart into Translation/Rotation/Scale/NonUniformScale you will need to provide a fast way to check for identity, and uniform vs. non-uniform scale. Either wrapping them all in enums / optional, or paying the cost of running expensive checks each time you want to check "does this entity have a non-uniform scale". This will be required for things like Physics, where Affine transforms cannot be applied to colliders because they are not tessellated.

All of these requirements is why I felt separate components for everything was the right call. Your mileage may vary of course. If you really want local transforms to be one component, I would recommend something along the lines of:
pub enum Scale {
    Identity,
    Uniform(f32),
    NonUniform(Vec3)
}

pub struct Transform3D {
    translation: Vec3,
    rotation: Quat,
    scale: Scale,
}

// Plus nice `impl` methods for `Transform3D`

with a separate component to store LocalToWorld matrix. This still doesn't help with the problem of hierarchies being out of date though. There isn't a perfect solution to that one sadly. For that I would say... make recomputing the hierarchy (updating Children and LocalToWorld on hierarchy entities) very easy API wise, and let users recompute (or partially recompute) the graph when they need to. The engine has no way of knowing ahead of time when that is, without doing nasty dirty checks and conservative re-computation all over the place.

I am personally a fan of "option 1". I think it's the best compromise in terms of the things that @AThilenius has said with usability from the user's perspective. A Similarity3 or similar (which allows for translation, rotation, and uniform scale) takes up only 8 floats (nonuniform scale would be 10 floats instead) and I don't think splitting these things into separate Components is going to make a big enough perf difference to account for the usability hindrance. Separating them makes composition harder or impossible, which while it's not a super-common use case as much as simply changing the transform, it's still common.
Another thing to consider is that the composition (i.e. combining two together to get the result of applying their transformations in sequence) of Similarities (or transforms stored in the same manner) is faster than the composition of a full Mat4, but transforming a Point3/Vec3 with a Similarity is slower than transforming it with a Mat4 because rotating a Vec/Point with a Quaternion is slower than with a rotation matrix... however, this perf difference can be made negligible by transforming multiple points at once because you can compute some 'state' upfront and then only do a small amount of computation per point.
Finally, one more thing to toss into the hat is that I would consider restricting any scaling at all to be only possible on entities that are "leaves" of the hierarchy graph. This could be done by using an Isometry3 (allows translation and rotation, also called a rigid body transformation or a "motor") or similar as the universal Transform type and then allowing leaf nodes to also have a Scale component like the one @AThilenius proposed above. The benefits would be:

Cheaper to store, less memory usage (by a small amount)
Simplifies transformations due to hierarchy by a great amount, particularly since you no longer have to account for different scaling types during hierachy, you just apply it at the leaf and then leave it, which is good for physics, simpler code, and it's cheaper to compute.
Though this isn't particularly relevant currently, I'll probably start evangelizing adopting (Projective) Geometric Algebra eventually, due to its awesome elegance and simplicity plus several other benefits mentioned in that video. PGA has elements called "motors" (which I alluded to above) that are the combination of a "translator" and "rotor", and which do rigid body transformations (translation and rotation). They can be stored as 8 floats. These motors are really awesome because you can apply them to any other element of the algebra (points, lines, planes, other motors, other translators, other rotors...) in a straight forward way and it just works. In addition, they are isomorphic (meaning they are the same thing, just a different formulation) to Dual Quaternions, and much like how Quaternions are useful for clean interpolation of rotations, we can use motors to do much better interpolation of full rigid body transforms, which is particularly useful for animations but can be useful for a number of other things as well. You can even use them to do the job of a perspective projection matrix. However, they don't do any type of direct scaling at all, so when using them if you need/want to scale, the best way to do it is to simply add a scaling step which just multiplies things at the beginning and then uses motors from then on in the transform "pipeline".

If you are interested in trying Scale, Rotation and Translation in a single 3D transform these currently exist in glam at the moment using the transform-types feature (see https://github.com/bitshifter/glam-rs/blob/master/src/f32/transform.rs). They're on a feature because it's just something I was playing around with as a 3D transform type and haven't committed to supporting in the library. There are benchmarks for them in glam if you want to see the performance trade offs. Generally they performed worse than a Mat4 for transforming points/vectors and other transforms but are faster for inverses. I think in particular in glam they are slower than the Mat4 because they're using Vec3 instead of Vec3A.

Regarding position/rotation/scale being in a single component or spread across components:

Unreal and other engines I've used combine these into a single struct/component and it seems to work well for them. Unity DOTS plans to separate them, but it sounds like they are considering other options (https://gist.github.com/joeante/79d25ec3a0e86436e53eb74f3ac82c0c).
Separating these components potentially introduces new costs (fetching additional components and running extra systems) and I don't feel confident to assume either approach would be faster than the other. I'd like to see data from a real game that's meant to be played. (i.e. not a microbenchmark or tech demo that has a sole purpose of making transform fetches a bottleneck.)

The internals of how position/rotation/scale are stored in a component that contains all three is a changeable implementation detail, so I think that takes a lot of pressure off of picking "the right way" today (as if there is such a thing.) I prefer approach (1). I think there are options for a Mat4 approach (like stashing scale in unused w components) but this seems like something that could be investigated later, hopefully with the benefit of profiling something a little more "real" than we have today.

Regarding position/rotation/scale being in a single component or spread across components:

Unreal and other engines I've used combine these into a single struct/component and it seems to work well for them. Unity DOTS plans to separate them, but it sounds like they are considering other options (https://gist.github.com/joeante/79d25ec3a0e86436e53eb74f3ac82c0c).
Separating these components potentially introduces new costs (fetching additional components and running extra systems) and I don't feel confident to assume either approach would be faster than the other. I'd like to see data from a real game that's meant to be played. (i.e. not a microbenchmark or tech demo that has a sole purpose of making transform fetches a bottleneck.)

The internals of how position/rotation/scale are stored in a component that contains all three is a changeable implementation detail, so I think that takes a lot of pressure off of picking "the right way" today (as if there is such a thing.) I prefer approach (1). I think there are options for a Mat4 approach (like stashing scale in unused w components) but this seems like something that could be investigated later, hopefully with the benefit of profiling something a little more "real" than we have today.

Unreal (and other engines) don't use an ECS so you're comparing apples to race cars. Unity DOTs has been separate components from the start and they don't plan on changing that because the performance is exceptional. That gist is only talking about aspects, which are just 'views' on top of set of components.
Breaking things apart rather than combining them is almost always faster. Instead of the hierarchy system needing to loop over every chunk with a Transform, it can simply loop over chunks that include a Parent. Ie. the former requires more looping AND a conditional branch for each entity, the latter is a non-op which is the beauty of an archetypical ECS.
These are all separate concepts and must be considered independently (I'm seeing these getting blurred):

What format is the source-of-truth for local space transforms in

This means separate or single component (and @termhn can talk more to Protective GA because I'm out of my depth there but it looks awesome).
This should never be stored as a mat4, including 'stashing scale in unused w components' which defeats the entire purpose of using a mat4 (ie they can be used by linear algebra equations directly). You're basically just packing a normal vec3 into a mat4 struct at that point, which isn't useful.

Where the computed space transforms are stored

There are very few reasons for this to be stored in the above component, and lots of very good reasons for it to be separate.
Both a local-space and a global-space transform are needed, with the local-space being conditional on presence of a hierarchy (ie we really want to keep LocalToWorld and LocalToParent separate, because the former is orders of magnitude more common).
I am almost certain these must be mat4, because all our existing hardware (GPUs for example) work on mat4. @termhn can chime in here again if Projective GA can offer an alternative. But multiplying matrices is also really fast, even on the CPU.

Where are hierarchies stored

While not ideal, after 3 totally disparate implementations, I finally agreed with Unity DOTs and went the way of separate Parent and Children components. Hierarchies in ECS are hard, because we lack reference types. There is no easy solution to this one, they all have some super nasty trade-offs.

I'd like to propose a solution to this problem, which IMO is in line with the general consensus here, as well as the current solution in regards changes that would be needed to make.
Geometric data is currently stored as Transform and GlobalTransform:

Transform represents local data
GlobalTransform is used as the global data and gets computed after every update.

Seeing as only GlobalTransform gets used for any rendering, it can keep being represented as a Mat4 - minus the mutating methods except matrix_mut(..) ..
Transform could look like this
struct Transform {
  pub translation: Vec3,
  pub rotation: Quat,
  pub scale: Vec3,
}

With something like pub fn compute_matrix(mut self) -> Mat4 to compute the respective Mat4 used to compute the GlobalTransform.
This doesn't have to be the definitive answer, but can be seen as 'good for now' and can be altered if need be. One extension could be to compute GlobalTransform only from a Tuple of e.g. (&Translation, &Rotation), if no Transform is present.
The main reasons I see to not convert to a system like that right now:

It either relies on newtypes, which IMO are more wonky to use as a single Transform, or we would need to rewrite a lot of the glam stuff.
We could not provide methods like Transform::orbit_around(&mut self, center: Vec3, axis: Vec3, t: f32) without a system, because they operate on more than one component.

These points could be irrelevant for other engines, and rightfully so, because they don't prioritize simplicity.
Regarding scale: keeping ease of use in mind, we can just leave it a Vec3, which will likely stay Vec3::one() all the time. If a more performat solution is needed here, I like the enum approach shown by @AThilenius.
Regarding hierarchy: We can just leave it as it is, because it works. As above, if we need to rewrite it that would likely be decoupled from Transforms anyway.
I'll try to get a PR ready in the next week to see what you guys think!

Hi Merek,
Have you seen how unity does their ecs hierarchy? It’s quite elegant imo.
<EMAIL_ADDRESS>It doesn’t include the parameterized data because there are many ways to create the matrix. Prescribing a TRS approach is limiting.
Cheers,
Ryan Cleven

On Sep 27, 2020, at 2:24 AM, Marek Legris<EMAIL_ADDRESS>wrote:

I'd like to propose a solution to this problem, which IMO is in line with the general consensus here, as well as the current solution in regards changes that would be needed to make.
Geometric data is currently stored as Transform and GlobalTransform:
Transform represents local data
GlobalTransform is used as the global data and gets computed after every update.
Seeing as only GlobalTransform gets used for any rendering, it can keep being represented as a Mat4 - minus the mutating methods except matrix_mut(..) ..
Transform could look like this
struct Transform {
pub translation: Vec3,
pub rotation: Quat,
pub scale: Vec3,
}
With something like pub fn compute_matrix(mut self) -> Mat4 to compute the respective Mat4 used to compute the GlobalTransform.
This doesn't have to be the definitive answer, but can be seen as 'good for now' and can be altered if need be. One extension could be to compute GlobalTransform only from a Tuple of e.g. (&Translation, &Rotation), if no Transform is present.
The main reasons I see to not convert to a system like that right now:
It either relies on newtypes, which IMO are more wonky to use as a single Transform, or we would need to rewrite a lot of the glam stuff.
We could not provide methods like Transform::orbit_around(&mut self, center: Vec3, axis: Vec3, t: f32) without a system, because they operate on more than one component.
These points could be irrelevant for other engines, and rightfully so, because they don't prioritize simplicity.
Regarding scale: keeping ease of use in mind, we can just leave it a Vec3, which will likely stay Vec3::one() all the time. If a more performat solution is needed here, I like the enum approach shown by @AThilenius.
Regarding hierarchy: We can just leave it as it is, because it works. As above, if we need to rewrite it that would likely be decoupled from Transforms anyway.
I'll try to get a PR ready in the next week to see what you guys think!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

@onehundredfeet thanks for the article! It's always nice to see different approaches.
That seems to already be the approach bevy is taking, however. At least concerning hierarchy. I might look into it a bit more after I've got my first solution ready, but I think potential improvements to the hierarchy system should be a different issue/PR as it works quite independent from the Transform composition.

With something like pub fn compute_matrix(mut self) -> Mat4 to compute the respective Mat4 used to compute the GlobalTransform.

What happens when a parent has N children? Do you recompute the mat4 for each child? What happens when N systems need access to the global transform for M entities? Do you just accept the O(MN) complexity, or do you cache it somewhere? If you cache it somewhere... then how is that different from the way I originally setup legion_transform?

@AThilenius bevy has a transform propagation system which queries all Transforms and GlobalTransforms starting by the ones without Parent and, after computing their own, recursively compute the GlobalTransform of the Children. So the GlobalTransform gets computed just once and represents the cache of the Mat4 for each entity for the next frame.
I don't know how this is different from legions implementation, because I didn't look at it.

bevy has a transform propagation system which...

I'm aware, I wrote the original impl 😋 I'm confused though, can you clarify exactly which components you intend to have, and what they contain?

I'm aware, I wrote the original impl

That's good to know 😅
I just adopted the system as it was when we had both Transforms and Translation, etc. components, so I don't know the ins and outs, but this is how I understand it.
Relevant components are:

Parent stores the parent Entity
Children stores the children Entitys
Transform
GlobalTransform absolute global transform used for rendering etc.

That's about it, really. A quick look into bevy-transform::transform_propagate_system should get you a clearer picture (at least clearer than I could paint it).

@MarekLg

It either relies on newtypes, which IMO are more wonky to use as a single Transform, or we would need to rewrite a lot of the glam stuff.

I was wondering why it would be necessary to rewrite a lot of glam stuff?

@bitshifter
Maybe I expressed that poorly 😅. I don't think we should stop using glam at all! Let me try to explain what I mean.
For example: Vec3 is currently used as translation and scale, so in order to use it as a component it needs to be wrapped in either a newtype, or in a wrapper. My problem is that newtype feels, again IMO, wonky to use and a wrapper would need a lot of boilerplate code (e.g. implementing all the traits of Vec3 on a supposed Translation etc.).
I may be wrong, however, and there is a neat solution after all.. If that's the case I'd love to be corrected!

@MarekLg ah thanks. I was just wondering if you were hitting some limitation in glam but it's more a general Rust new type thing.

@bitshifter absolutely correct

Resolved by #596


Add High Quality Once update mode to Sky

Related to https://github.com/godotengine/godot/pull/55929.
This allows for generating high-quality reflections once when the sky resource is first assigned (or when the project starts).
The use case is to use sky shaders that feature real-time clouds and the like without impacting performance nearly as much, since the radiance map is no longer constantly regenereated during gameplay. When using this mode, clouds won't move in reflections anymore, but this is hardly a problem in most scenes since clouds are hard to see moving in reflections.
Additionally, with some shader trickery (e.g. toggling a boolean uniform after loading the scene), this allows you to have a radiance map that looks nothing like the sky if you wish :wink:
While not physically accurate, this has been requested many times over the years: https://github.com/godotengine/godot-proposals/issues/3593
Testing project: test_sky_update_once.zip
Press C to cycle between sky update modes (including Automatic).
This PR can likely be remade for 3.x if desired.
This closes https://github.com/godotengine/godot/issues/53969 (at the cost of incorrect reflections, but not much can be done about this, other than adjusting ambient light intensity at run-time).
Performance
OS: Fedora 34
CPU: Intel Core i7-6700K
GPU: GeForce GTX 1080

Update mode
FPS

High Quality Once
657 FPS (1.52 mspf)

High Quality
23 FPS (43.48 mspf)

High Quality Incremental
151 FPS (6.62 mspf)

Real Time
321 FPS (3.12 mspf)

Yay!
(Personally I'm halfway through moving my racer project to Vulkan, but a 3.x backport would be awesome if possible)

I don't think that this resolves godotengine/godot-proposals#3593
Wouldn't it be preferable to implement godotengine/godot-proposals#3593 e.g. provide a different sky source for reflections and background?
To me, the current workflow in this PR seems a little hacky. Users would have to write a script to change the sky_material after one frame if they want to separate reflections from the sky background. Otherwise, they would just end up with whatever their lighting/material setup was on frame 0.

It sort of resolves #3593, as setting the Sky for radiance map to update only once does allow for a Static Sky to Provide Ambient and Reflected Lighting, while also allowing the Sky itself to be changed, without affecting the radiance maps..
I mean this doesn't resolve it the way it's proposed, but it does add a workaround that gives a desired result and it is still unclear how much demand there is for something like that for it to be made more user-friendly way of doing it.

notable performance issues that occur when performing sky updates that do not change the radiance map in a significant way

Is this an issue that users have been reporting? I'm concerned that we may be chasing an invented use-case and not an actual problem that users are running into. I'm happy to be shown I am wrong here, but I haven't seen any users who are slightly tweaking their sky every frame and running into resulting performance issues. Although, personally, I really like the idea of being able to set the reflections to not update, and then being able to update them when you choose. But I feel that I am being too speculative.
I have a feeling that if users want to have a static sky for reflections along with a dynamic sky for the background, the best option is the one presented in godotengine/godot-proposals#3593,

We discussed this PR during today's PR review meeting. The consensus is that we should add a project setting to control how often the radiance map is updated (either once, spread over N frames, or updated every frame). In order to do that we will need to re-evaluate the rendering probe update options and the Update Mode settings in Sky (high quality incremental may no longer be needed).

Is this still useful after https://github.com/godotengine/godot/pull/58177?

Is this still useful after #58177?

Yes, but this PR needs to be redesigned to follow clayjohn's comment above.

To add to Calinou's comment, something like this is still needed because for complex sky shaders, the slowest part is the sky shader rather than the generation of the radiance map. https://github.com/godotengine/godot/pull/58177 made generating a high quality radiance map much cheaper, but it does nothing for expensive shaders.
@Calinou I am thinking that we do the following:

Change the name of "Update Mode" to "Filter Mode" and keep the current options
Add an "update mode" that controls how often the sky shader is run (but does not impact the radiance map filtering) with the following options

UPDATE_MODE_ALWAYS; // all 6 faces every frame
UPDATE_MODE_ONCE; // All six faces for one frame then freeze update
UPDATE_MODE_INCREMENTAL; // Update over 6 frames

The radiance update would only start after the cubemap is updated after running the sky shader.


Fixes asynch launchTwa freezing splash screens

Moved code that builds the splash screen strategy to run on
onCreate(), so they will already be available when
onEnterAnimationComplete() is invoked.
When finish() is called early, on onCreate(), to bring an
existing Activity to front, launchTwa() shouldn't be invoked.
We update the Firebase demo to reflect that and add a guard in
launchTwa().

Closes #281

You guys work fast, thanks for fixing!

Can we bump the version up to include this fix? Thanks!

This has been published on 2.2.2.


Mark abort as having type NoReturn

In https://github.com/pallets/werkzeug/pull/1995, typing was added to large parts of this project. This will be really useful to me.
One of the problems I have with the latest release is abort. PyCharm doesn't know that abort aborts. So it will complain about possibly uninitialised variables if I write code like this:
if foo:
    bar = 1
else:
    abort(404)

print(bar)

This is because abort is declared to return type None: def abort(status: t.Union[int, "Response"], *args, **kwargs) -> None:.  This is not the case - I think abort always raises an exception.
Instead, what we want to do is change the return type to t.NoReturn. This expresses the correct meaning, which is that the abort function never returns. In turn, this will help PyCharm and other analysers understand code that uses abort better.
Checklist:
(a docs change, so I've skipped some steps)
~- [ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.~

[x] Add or update relevant docs, in the docs folder and in code.
[ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue. - this PR builds on https://github.com/pallets/werkzeug/pull/1995, which doesn't have an entry. Should I add an entry to cover both, or leave it alone?
~- [ ] Add .. versionchanged:: entries in any relevant code docs.~
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

See the test failure for why I didn't do this.

See the test failure for why I didn't do this.

Good point - I missed this in the tox output. I think I've found the problem - mypy's type inference doesn't seem to understand _aborter. It looks as if being explicit about the type of _aborter fixes the problem, though.
I'm not entirely sure why this is, which is a bit unsatisfactory.

Good point - I missed this in the tox output. I think I've found the problem - mypy's type inference doesn't seem to understand _aborter. It looks as if being explicit about the type of _aborter fixes the problem, though.
I'm not entirely sure why this is, which is a bit unsatisfactory.

Thanks for figuring it out!

Thanks for figuring it out!


Package not working

I've got version 2.1.3 installed, and it's not behaving like the docs at all. It's always creating a single file called the target (the example creates a symlink "build/videos -> ../../assets/some-large-video.mp4", then fails on the next pipe). Passing an array to symlink fails with an error telling me it expects a string.

What does your code look like? Last time I published this test still passed: https://github.com/ben-eb/gulp-symlink/blob/master/test/index.js#L211-L229

This module has now been deprecated. https://github.com/ben-eb/gulp-symlink#deprecation-notice


[lc_ctrl/alerts] Fix a typo

Fixes https://github.com/lowRISC/opentitan/pull/7075#pullrequestreview-692183922 and https://github.com/lowRISC/opentitan/pull/7063#discussion_r658246304
Signed-off-by: Michael Schaffner<EMAIL_ADDRESS>

Haha yeah ;)


Update Readme of perceiver for pip install flag

Updated Readme in Perceiver
from pip install -f requirements.txt
to pip install -r requirements.txt

@googlebot I signed it!


Integration Test - Release - 2019/03/09 00:48:35

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

@PRMergerTest3 : Thanks for your contribution! The author, @v-caxian, has been notified to review your proposed change.


Add support for the name option

Closes #227

@dvic don't worry about the capture_log CI failure, it's been flaky ever since we moved to Github actions and we didn't take the time to investigate yet :shrug:

Alright, I just pushed my last change, forgot to remove the is_pid guard. It should be good to go now.

Also said in the one comment, I wonder if we should move the whole thing to ChromicPDF.Supervisor to reduce the noise in the "main" docs. IMO it kind of fits better there, wdyt?

To be precise:

move both get_dynamic_name/1 and put_dynamic_name1 outside of the __using__ block in Supervisor
move the documentation to the moduledoc in Supervisor

Also said in the one comment, I wonder if we should move the whole thing to ChromicPDF.Supervisor to reduce the noise in the "main" docs. IMO it kind of fits better there, wdyt?

To be precise:

move both get_dynamic_name/1 and put_dynamic_name1 outside of the __using__ block in Supervisor
move the documentation to the moduledoc in Supervisor

I moved the docs to put_dynamic_name/1. However, I kept it inside the __using__ macro because I think it makes more sense to keep it there as the default name is the module that called use. Wdyt?


OS.execute on exported project will go nuts.

Godot version:
3.0-stable.
OS/device including version:
Debian 9
Issue description:
OS.execute should execute said command just once, but seems that when executing an exported project, for some reason the command keeps getting executed.
Steps to reproduce:
Create a blank project with a script that says "Hello, World!" on ready. Export it.

You need to set the path to the location of your first project, or use the --path argument. By default the Godot binary is not bound to any data pck, it will execute what it finds it the current working directory. In your case, it's the directory of the second project, so the second project actually runs itself endlessly.

@akien-mga Sorry to reopen this, but I don't understand what you mean by "set the path to the location of your first project" .... I do OS.execute("/home/user/hello_project.x86_64", [], true) that should execute directly the binary, no?

I think @akien-mga said you should execute the exported binary with an argument such as --path /path/to/project/directory (I think you can specify the path to the PCK file directly, I'm not sure).

I'm not a fan of reliving closed issues but the literal answer to this is nowhere to be found on the internet so I'm doing a favour to whoever is having the same issue as me and @vicguedez .
OS.execute('C:/program.exe' ,['--path', 'C:/'], false)

Oh yes, I totally forgot comment here that you should pass any arguments in the array. Thanks @isHaacK.

Can the current OS.execute() documentation be improved based on your comments?

It can probably be more clarified. "platform path resolution will take place" wasn't clear for me, I didn't understand that the exported project was being executed in the current path, loading the wrong pck resulting in me struggling to understand how in the hell it was opening another instance of the current project.


engine: unify request objects

One issue with breaking out the requests by type into individual fields over the engine API is it forces ELs to refer to the fork schedule to convert blocks to ExecutionPayloadVX
This is due to the way null and empty fields are interpreted. Suppose in Osaka another request type is added. Now we have the Prague-activated requests and the Osaka request. To determine whether a block should write null for the Osaka request or empty value depends on if the fork has passed yet.
Typically with these things we can just look at block itself and propagate it's existence up through the engine API. However, with EIP-7685 this isn't possible. Requests are encoded depending on whether any requests occurred in the block. It's possible that if there are no requests, then number of requests for that type could be empty.
This means at the block level we cannot differentiate empty-but-active from null-but-inactive unless we have the fork schedule.
This PR combines all the requests into a single type RequestsV1. The field type is used to differentiate between different request types. Some fields are reused between request types. This is equivalent to how typed transactions are represented over the RPC.

EL is aware which method version has been called hence what payload version is expected in the response. Could the following approach work:
def get_payload_handler(id, version) -> GetPayloadResponse:
    response = GetPayloadResponse()

    …

    if version == “v5”:
        response.payload.osaka_requests = built_block.get_osaka_requests()

    return response

It's possible to do this, but I think it's much cleaner to just expose the data in the same way it exists in the consensus object.  It could also mask an issue with the client where maybe the deposit requests aren't accumulated and the API overrides a nil value with empty. Obviously this would be caught by other clients, but I find the pattern of the API forcing syntactic correctness over the underlying data to be an anti-pattern.

It's possible to do this, but I think it's much cleaner to just expose the data in the same way it exists in the consensus object.  It could also mask an issue with the client where maybe the deposit requests aren't accumulated and the API overrides a nil value with empty. Obviously this would be caught by other clients, but I find the pattern of the API forcing syntactic correctness over the underlying data to be an anti-pattern.

I appreciate this! Let’s discuss with client devs on the ACDC

@karalabe proposed couple weeks back to transition engine to binary encoding, so union support would not necessarily be available anymore.
The problem here seems to be introduced because of https://eips.ethereum.org/EIPS/eip-7685 - would a design simply using three separate list also solve this? Same as was done for withdrawals.

Also, wondering whether this reduces overall complexity or simply shuffles it from EL to CL.

It makes more sense to expose the block in the same way it is represented on the EL. That's what this PR does, it expresses the 7685 list as a single list in ExecutionPayload. The CL can decide how best to represent the data (and at what level) in it's data structure.

Wrt SSZ, as far as I'm aware, most libraries do not implement unions because it's an unused and a bit of a wonky construct. So relying on that might get some pushback from SSZ/consensus people. Need to grok this proposal a bit more, it's a bit hard to wrap my head around for some reason.

@lightclient Could you provide some examples for 7685 and how that would interplay/translate into this?
I'm having a hard time understanding the necessity for unionifying different things on one end; and also don't see how EIP-7685 gets into the picture which proposes opaque events that should not even be dissected in the first place.

Another approach could be, to get rid of the typed union and replace the requests MPT with a hash of 3x MPT, i.e.,

requests_root := keccak256[mpt_root(deposits) || mpt_root(withdrawals) || mpt_root(consolidations)]

That way, the motivation of 7685 of not extending the EL block header repeatedly could be fulfilled, while the problems that union types introduce are avoided - the EL can infer from what requests lists are defined, on what fields need to be [] vs null. That way, the provided data also matches more cleanly what is transmitted via JSON-RPC to API clients, and via engine API to the CL. Furthermore, such a structure could be more easily transformed into a strongly typed SSZ world in the future.

+1 to unify requests under a common container

Could you provide some examples for 7685 and how that would interplay/translate into this?

I'm having a hard time understanding the necessity for unionifying different things on one end; and also don't see how EIP-7685 gets into the picture which proposes opaque events that should not even be dissected in the first place.

@karalabe the idea in this PR is that we want the server to serve data similarly to how it's stored. That means we don't dissect requests into individual types and instead return a list of requests in the block.
That's the guiding light in the proposal, but there is also some practical improvements we get from this. Most execution clients do not have great support fork fork-typed data structures. Whether this is a historic artifact or not, having a block alone does not constitute certainty about its fork. This proposal acknowledges that and avoids implementations of the engine API needing to determine if a certain request type is not yet active or if there just were no occurrences in the blocks.
Ex. suppose fork F1 we have request types R1 and R2 and in fork F2 we have request type R3. It's not possible to determine if a block is from F1 or F2 on it's own via the presence / absence of R3. This is unlike how we are usually able to determine if some is active by check if the header field is non-nil.
Since the current engine API requires us to not only separate the requests by type, we also need ensure the empty vs. null values are respected. So we would need access to the chain spec to determine the fork the block originates from. This is certainly possible, but seems overly complex.
Re: SSZ --> we discussed on the CL call a bit and in general the point is that the way the json api serializes data doesn't necessarily need to be copied when migrating to SSZ. Unions in SSZ are the logical choice to represent requests, however there are certainly other options. I don't think making a decision here will impact our ability to migrate to SSZ in any meaningful way because we're only modifying inputs / outputs of existing API methods.

It's not possible to determine if a block is from F1 or F2 on it's own via the presence / absence of R3.

The fork can still be determined by looking at the block's timestamp.

Of course, this is why I specify it's not possible to determine the for on its own, e.g. without a fork schedule.

The EL needs a fork schedule anyway to correctly implement the engine API, e.g.,
https://github.com/ethereum/execution-apis/blob/main/src/engine/cancun.md#update-the-methods-of-previous-forks

This document defines how Cancun payload should be handled by the Shanghai API.
For the following methods:

engine_forkchoiceUpdatedV2
engine_newPayloadV2
engine_getPayloadV2

a validation MUST be added:

Client software MUST return -38005: Unsupported fork error if the timestamp of payload or payloadAttributes greater or equal to the Cancun activation timestamp.

and https://github.com/ethereum/execution-apis/blob/main/src/engine/prague.md#update-the-methods-of-previous-forks

This document defines how Prague payload should be handled by the Cancun API.
For the following methods:

engine_newPayloadV3
engine_getPayloadV3

a validation MUST be added:

Client software MUST return -38005: Unsupported fork error if the timestamp of payload or payloadAttributes greater or equal to the Prague activation timestamp.

Converting between block and executable data doesn't require the fork schedule and I think if we can avoid requiring it, that's best. That's what this PR does.

I think if we can avoid requiring it, that's best.

Why?
Execution payloads, at least, don't exist independently of forks. They're intrinsically of some specific fork, and to encode them properly for the engine API requires this knowledge.

This proposal acknowledges that and avoids implementations of the engine API needing to determine if a certain request type is not yet active or if there just were no occurrences in the blocks.
Ex. suppose fork F1 we have request types R1 and R2 and in fork F2 we have request type R3. It's not possible to determine if a block is from F1 or F2 on it's own via the presence / absence of R3. This is unlike how we are usually able to determine if some is active by check if the header field is non-nil.

This points to usage of potentially unreliable heuristics which must be determined to align with other specifications in a semi-arbitrary way, and such that there are intrinsically semi-defined ambiguous states as noted. This is not an ideal way to build a protocol, and extending that out from the EL and just asking some other entity to perform this extrapolation is not useful for the overall Ethereum system.
Rather, the requirement to, ever:

determine if a block is from F1 or F2 on it's own via the presence / absence of R3
should simply not exist.

Converting between block and executable data doesn't require the fork schedule

Would it be feasible, instead of converting between (block,) and executable data; to convert between a (block, fork) tuple and executable data for serialization purposes? As in, wrap the block in the tuple before serializing, and unwrap (and check constraints) after deserializing. If possible, that seems less invasive than introducing an entire type system, and also less invasive than routing additional context arguments throughout the entire serialization logic.
At some point, the EL needs the fork information, e.g., to check that there is no 0x03 tx before Deneb, or 0x04 tx before Electra. So maybe what we are seeing is just that that barrier on which the fork has to be known gets lowered somewhat further (into serialization) — It also has the upside, though, that invalid content can be rejected earlier than with an approach that first parses opaque data and then inspects it later.
BTW, the CL also has a few REST endpoints where the fork is not solely derivable from type information; the wrapper approach works quite well there. i.e., instead of serializing / deserializing T, serialize / deserialize RestVersioned[T] when T alone is not sufficient to determine the fork.
  RestVersioned*[T] = object
    data*: T
    jsonVersion*: ConsensusFork
    sszContext*: ForkDigest

Overall, I see three solutions:

Keep as is (and deal with it in the implementation)
Split the requests into separate lists (and then put a hash across all the root hashes into the block header) – this way, type information is once again sufficient to identify the fork
The approach being proposed here (where the problem sort of gets shifted to the CL)

Another aspect to consider are JSON-RPC clients (non engine). While I'm not too opinionated about the engine API myself, the external JSON-RPC is used by the masses, and I think that adding additional hurdles such as parsing various formats should be avoided. The current engine API (with the separate lists) seems quite in line with other endpoints, so has that going in its favor; but it's also fine to have more complexity on engine if it serves a purpose (e.g., engine could become binary, while JSON-RPC is still JSON based).

This points to usage of potentially unreliable heuristics which must be determined to align with other specifications in a semi-arbitrary way, and such that there are intrinsically semi-defined ambiguous states as noted. This is not an ideal way to build a protocol, and extending that out from the EL and just asking some other entity to perform this extrapolation is not useful for the overall Ethereum system.

Unfortunately this is the way the EL has evolved over the years. Drawing a line in the sand to change it now is not useful, imo. We should work around it in ways that do not significantly encumber us in the future.

Would it be feasible, instead of converting between (block,) and executable data; to convert between a (block, fork) tuple and executable data for serialization purposes?

Yes this is possible, but at that point we should just keep the spec as-is and use the timestamp to determine the schedule.

closing as we went with #591 instead


db_sample is valid?  Are you sure you use it for training ?

This is the the result of data augumentation by dbsample. A lot of invalid samples are introduced, which lead to training is not meaningful

Hi @wangguojun2018, how did you deal with this problem, do you think training without db_sampling would be better?


[SPARK-49447][K8S] Fix spark.kubernetes.allocation.batch.delay to prevent small values less than 100

What changes were proposed in this pull request?
This PR aims to fix spark.kubernetes.allocation.batch.delay to prevent small values less than 100 from Apache Spark 4.0.0.
Why are the changes needed?
The default value is 1s (=1000). Usually, a small value like 1 happens due to the missing unit, s, when users do mistakes. We had better prevent this. In addition, a misconfigured value like 1 can cause a high frequency traffic from Spark drivers to K8s control plan accidentally.
Does this PR introduce any user-facing change?
For the misconfigured values, Spark will complain and fail from Apache Spark 4.0.0.
How was this patch tested?
Pass the CIs with the newly added test case.
Was this patch authored or co-authored using generative AI tooling?
No.

Could you review this when you have some time, @viirya ?

Thank you, @yaooqinn !

Merged to master~


[Request] Add row and column count for stitching functionality.

Currently you can export layouts into a stitched image by specifying the width and height of the target image. It may be useful to let users specify the number of cards in a given row and/column.
See https://www.boardgamegeek.com/thread/1456296/feature-suggestion
There is a further request to dummy out a certain card for use with the Tabletop Simulator that requires the 70th card to be an unused one. On export use a dummy card index to space out the specified position. This will likely be saved at the CardMaker ini level as it is extremely specialized an unlikely to be needed on a per project basis.

This was added and can be used with this pre-release version: https://github.com/nhmkdev/cardmaker/releases/tag/v.<IP_ADDRESS>-unstable.v.a3


Database access in tests

It's currently quite hard to make sure that no new regressions are introduced while adding new functionality or fixing bugs.
I would propose adding support for a tests that have access to a running postgres instance and can use it to run commands against. If postgres is not running, such tests would be skipped.
Travis does have support for postgres and with some experimentation I'm sure turning it on in wouldn't be a problem.
@amjith, how do you feel about this? Would it be something that agrees with your plans for the project?

Yes. That is indeed in the grand plan. https://github.com/amjith/pgcli/blob/master/tests/test_plan.wiki
Just haven't gotten enough hours in a day. :)

Woot. We'll see, maybe I'll throw something together. :)
Cheers!


Can I create a report with apex-mdapi ?

Hi Andy,
Will apex-mdapi (and the underlying Metadata API) let me create a new report in Salesforce ?
Rupert

Yes it will, there is no example for create, but one for read. Take a look at the Q&A and Salesforce docs for this Metadata Type here, there is an example (in XML) at the bottom. Also check the Q&A for tips on writing code against the API based on a Report you've manually created and pulled down as XML as a guide. Hope this helps, sorry i don't have time at present to write a sample for you.

Andrew, thanks for your anwser which is great support : I will look into this method.
Keep your precious time for your customers.
Thanks,
Rupert

Le 4 mars 2016 à 08:46, Andrew Fawcett<EMAIL_ADDRESS>a écrit :
Yes it will, there is no example for create, but one for read. Take a look at the Q&A http://andyinthecloud.com/2014/11/22/apex-metadata-api-qa/ and Salesforce docs for this Metadata Type here https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_report.htm, there is an example (in XML) at the bottom. Also check the Q&A for tips on writing code against the API based on a Report you've manually created and pulled down as XML as a guide. Hope this helps, sorry i don't have time at present to write a sample for you.
—
Reply to this email directly or view it on GitHub https://github.com/financialforcedev/apex-mdapi/issues/123#issuecomment-192166794.

@AltiusRupert Did you manage to create reports using the metadata api ?
A sample would be appreciated :)

@KGFTW No I didn't, sorry to disappoint you :(

@KGFTW  was kind enough to share his example on another issue. I have since given him a shout out on Twitter and on the main page here. Thanks @KGFTW


Jest Snapshot: Warning: Native component for "RNSVGSvgView" does not exist

Hello guys,
So I'm testing my RN 0.33.1 with Jest, as follows:
import 'react-native';
import React from 'react';
import svgElementMockGenerator from '../__mocks__/svgElementMockGenerator';
import ReactTestRenderer from 'react-test-renderer';
const Headline = require('../Headline').default;
const Heart = require('../Heart').default;

// eslint-disable-next-line no-undef
jest.mock('react-native-svg', () => {
  // eslint-disable-next-line no-undef
  const ReactNativeSvg = jest.genMockFromModule('react-native-svg');
  return {
    Svg            : svgElementMockGenerator('Svg', ReactNativeSvg.Svg.propType),
    LinearGradient : svgElementMockGenerator('LinearGradient', ReactNativeSvg.LinearGradient.propType),
    Path           : svgElementMockGenerator('Path', ReactNativeSvg.Path.propType),
    Symbol         : svgElementMockGenerator('Symbol', ReactNativeSvg.Symbol.propType),
    Use            : svgElementMockGenerator('Use', ReactNativeSvg.Use.propType),
    Stop           : svgElementMockGenerator('Stop', ReactNativeSvg.Stop.propType),
    Defs           : svgElementMockGenerator('Defs', ReactNativeSvg.Defs.propType),
  };
});

// eslint-disable-next-line no-undef
test('Heart', () => {
  const tree = ReactTestRenderer.create(
    <Heart {...{
      width      : 50,
      gradient   : ['#EC6D57', '#FCC747'],
      rangeValue : 'sport',
    }} />
  ).toJSON();
  // eslint-disable-next-line no-undef
  expect(tree).toMatchSnapshot();
});

import React from 'react';
export default function svgElementMockGenerator (name, propTypes) {
  class SvgMock extends React.Component {
    static displayName = name;
    static propTypes = propTypes;
    render () {
      return React.createElement(name, this.props, this.props.children);
    }
  }
  return SvgMock;
}

This is passing, but I'm getting this warning:
 PASS  src/components/common/UI/__tests__/Components.test.js
  ✓ Heart (24ms)
  ✓ Headline (24ms)

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   2 passed, 2 total
Time:        1.601s
Ran all test suites.
  console.error node_modules/react-native/Libraries/JavaScriptAppEngine/Initialization/ExceptionsManager.js:78
    Warning: Native component for "RNSVGSvgView" does not exist

Any ideas on how to get rid of that one?
Thanks!

meh I just stopped sending propTypes so I got completely rid of the native component.

@hybrisCole thank you for your example. I'm using jest to test components automatically in tipsi-ui-kit. And I just fixed your example like this:
// eslint-disable-next-line no-undef
jest.mock('react-native-svg', () => {
  const React = require('react')
  // eslint-disable-next-line no-undef
  const ReactNativeSvg = jest.genMockFromModule('react-native-svg')

  const svgElementMockGenerator = (name, propTypes) => {
    function SvgMock() {
      return (
        React.createElement(name, null, null)
      )
    }

    SvgMock.displayName = name
    SvgMock.propTypes = propTypes

    return SvgMock
  }

  const Svg = svgElementMockGenerator('Svg', ReactNativeSvg.Svg.propTypes)

  Svg.Rect = svgElementMockGenerator('Rect', ReactNativeSvg.Rect.propTypes)
  Svg.LinearGradient = svgElementMockGenerator(
    'LinearGradient',
    ReactNativeSvg.LinearGradient.propTypes
  )
  Svg.Path = svgElementMockGenerator('Path', ReactNativeSvg.Path.propTypes)
  Svg.Symbol = svgElementMockGenerator('Symbol', ReactNativeSvg.Symbol.propTypes)
  Svg.Use = svgElementMockGenerator('Use', ReactNativeSvg.Use.propTypes)
  Svg.Stop = svgElementMockGenerator('Stop', ReactNativeSvg.Stop.propTypes)
  Svg.Defs = svgElementMockGenerator('Defs', ReactNativeSvg.Defs.propTypes)

  return Svg
})

Cause I need that mock should be identical to original module.

Carrying on from the code posted here (thanks for doing the bulk of the work!). I've made it a little more generic where it'll automatically mock out anything react-native-svg exports so it exports everything, and would support changes in the future.
I put this file into my project root /__mocks__/react-native-svg.js
import React, { Component } from 'react';
const ReactNativeSvg = jest.genMockFromModule('react-native-svg');

const excludedExports = ['Svg', 'default', '__esModule'];
const componentsToMock = Object.keys(ReactNativeSvg).filter(key => {
  return !excludedExports.includes(key);
});

const mocks = generateSvgMocks(componentsToMock);
// A hack to dynamically export all mocks as named exports.
// I don't think this is doable with the modern export syntax since it's dynamic.
module.exports = mocks;
export default mocks;

function generateSvgMocks(names) {
  return names.reduce((acc, name) => {
    acc[name] = generateSvgMock(name);
    return acc;
  }, generateSvgMock('Svg'));
};

function generateSvgMock(name) {
  return class SvgMock extends Component {
    static displayName = name;
    static propTypes = ReactNativeSvg[name].propType;

    render() {
      return React.createElement(name, this.props, this.props.children);
    }
  };
};

I added back the props and children since I wanted my snapshots to include the full Svg output where without it, you'd just get <Svg /> in the snapshot. If you want that, just change the mock to pass null for the children instead.

Thank you @jakecraige and @isnifer, you guys are heroes! Your solution solved the following error that I got when running Jest:
TypeError: inst.toJSON is not a function

hey @jakecraige, we had some problems at the project I'm working on with the presence of the Svg tag at the excludedExports constant. As u guys might know, it's the most important import when creating svgs (also being a named export) and, during the snapshot tests, we were facing the following error:
Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

So, we removed the Svg from the excludedExports constant and everything work as expected 😉

Seems line a jest configuration issue rather than svg rendering issue. Closing.


Set focus in first faulty field

Hi,
is there a way to always set the focus to the first faulty field?
I tried to implement a solution in my render field component:
componentDidUpdate() {
    const { meta: { submitting, touched, error } } = this.props;
    const field = this.refs['field' + this.props.name];

    ...

    if (!submitting && touched && error) {
      field.select();
    }
}

This works partially, but...
If I enter one char in the first faulty field, the validation is at this moment valid for the field and the next faulty field steals my focus.
How can I prevent this or is there already a built-in solution?
Thanks for your help!

Use onSubmitFail at reduxForm decorator.
Take a look at https://github.com/erikras/redux-form/issues/1336, instead of scroll you can use dispatch(focus(form:String, field:String))

Use onSubmitFail at reduxForm decorator.

✅  Yes.

Take a look at #1336, instead of scroll you can use dispatch(focus(form:String, field:String))

❌  No.
Dispatching FOCUS will not focus your field; it will merely mark it as "active" in redux-form. To put it another way, FOCUS is what is dispatched automatically from the onFocus event handler.
To actually put the cursor in a field, you have to have access to the DOM element itself and call .focus() on it. There is no way for redux-form to do this for you without making too many assumptions about your component structure.
Using onSubmitFail and the document.querySelectorAll([name="${fieldName}"]) method proposed in #1336 is probably the most elegant solution.
The next release will give each field access to the submitFailed to use in your calculations, which could make your in-field-component strategy more viable. #2346

Hi @Katu360 and @erikras,
seems to be working. But I will wait until the next release. When can we expect it?

Hi @erikras,
I see your release, many thanks.
But the meta submitFailed do not help me, because after the first try to submit the form I get always submitFailed: true, so I have no indicator if somebody press enter or submit the form again.
The onSubmitFail event would be perfect, but I can not access the event from the field component. Do you have another idea?
Yes I could handle this by each parent form of a field but I find that quite uncomfortable.
Maybe you have another idea :-)

You have both meta.submitting and meta.submitFailed, so you should be able to tell:
componentDidUpdate(prevProps) {
  const submitJustNowFailed = prevProps.submitting &&
                              !this.props.submitting &&
                              this.props.submitFailed
  if (submitJustNowFailed) {
    // do stuff
  }
}

Hey Erikras,
I tested this, but prevProps.meta.submitting is always false although this.props.meta.submitting is sometimes true.
Other idea?
Thanks for your help!

It must be getting updated twice, so the exact previous props were not with submitting true. You might have to remember it yourself.
if (this.props.meta.submitting && !this.state.submitting) {
  this.setState({ submitting: true })
}
if (this.state.submitting && !this.props.meta.submitting && this.props.meta.submitFailed) {
  this.setState({ submitting: false }) // reset state
  // submit just now failed
}

Some combination like that might work. I didn't give it too much thought, but I was just illustrating how you could keep a memory of if you have been submitting recently.

I've been working on this today and found a solution which I think is a bit more elegant than using document.querySelectorAll, and (with limited testing) seems to work well.  In the onSubmitFail method I dispatch the focus action so the active prop of the first failing field is set:
export default reduxForm({
    form: 'contact',
    onSubmitFail: (errors, dispatch) =>
        dispatch(focus('contact', Object.keys(errors)[0]))
})(ContactForm);

Then in the component I pass to Field, I set the focus on the <input> tag in componentDidUpdate via a ref:
export default class Input extends React.Component {
    componentDidUpdate(prevProps) {
        if (!prevProps.meta.active && this.props.meta.active) {
            this.input.focus();
        }
    }
    render() {
        let error;
        if (this.props.meta.touched && this.props.meta.error) {
            error =
{this.props.meta.error}
;
        }

        let warning;
        if (this.props.meta.touched && this.props.meta.warning) {
            warning = (

{this.props.meta.warning}

            );
        }

        return (

                    {this.props.label}
                    {error}
                    {warning}

                <input
                    {...this.props.input}
                    id={this.props.input.name}
                    type={this.props.type}
                    ref={input => (this.input = input)}
                />

        );
    }
}

If that looks useful and works for other folks then I can put in a PR with some documentation on how to do this.

Just a note @oampo object.keys(errors)[0] will not work for a form that contains an array of other values.

All suggestions (in all corresponding/found issues) for implementing focusing the first field error were failing for me.. then I worked out why.. when using redux-form/immutable the onSubmitFail errors object does not contain the fields in registration order (possibly requires an ordered list reviver when setting/getting fields?).
So I solved it with a pure DOM query:
In onSubmitFail Get all the error'ed fields and query them using querySelector. This is the most workable as querySelector "Returns the first Element within the document that matches the specified selector, or group of selectors." .. so even if the selector is not in registeredField order.. it still returns the first error'ed field in the document, then just focus() it.
Could possibly also scrollIntoView() though in my case this failed as the site has a fixed/floating header.
onSubmitFail: (errors) => {
  // # Focus on first error

  // When Immutable:
  // The errors are _not_ in `REGISTER_FIELD` order so we cant just "use" the first one..
  // (possibly requires an ordered list reviver when getting errors?)

  // so we try to get the first error element in another way, using a DOM query:

  // Note: You can't query a possible error class in `onSubmitFail` as the `render` may not have yet happened.

  // We do this using a DOM selector of all the fields that have error'ed and use `querySelector` which
  // Returns the first Element within the document that matches the specified selector, or group of selectors.
  const errorEl = document.querySelector(
    // flattenObject: https://github.com/hughsk/flat/issues/52
    Object.keys(flattenObject(errors)).map(fieldName => `[name="${fieldName}"]`).join(',')
  );
  if (errorEl && errorEl.focus) { // npe
    // if (errorEl.scrollIntoView) {
    //   errorEl.scrollIntoView(); // fails as the site has a fixed/floating header
    // }
    errorEl.focus(); // this scrolls without visible scroll
  }
}

Note: the form this is used for does not contain arrays, so I haven't checked the flattenObject actually creates correct field names
#1336

Thanks for the details, @AubreyHewes!
Since this issue is very UI specific, it's not a concern of Redux Form, therefore I'm closing it.
Feel free to continue the discussion, though.

@AubreyHewes Thanks !

@AubreyHewes I found using window.scrollTo can scroll the the errorEl
if (errorEl && window.scrollTo) {
  window.scrollTo(0, errorEl.offsetTop)
}


Installer?

Nothing fancy, and can be left after the alpha: just a script that exec on first run, ask for the first non-root username on the system and uninstall itself. This would need an adduser command, or maybe it can be a part of itself and just disable instead of uninstall...
Thoughs? What more should it do?

This reminds me oddly of the auto-installer... I wonder why. This is still a good idea! Instead of defaulting :P bump


Implement User Functionality

Users of the Thrive application should be able to create a user account for themselves to use within the application. The following fields should be considered for capture within the User bounded context:

Username unique
Password  hashed
Email
First Name
Last Name
Street Address 1
Street Address 2
City
State
Zip

Authentication / Authorization will be necessary, but should be managed from a separate story.

Hashing Alg: BCrypt


Increase icon size of shortcuts in shortcut card

you can find shortcut card component in source/Dashboard/components)/ShortcutCard/

I want to work on this

Hi there,
I have experience working with components and would like to work on this issue.
Please assign it to me.

@Aditya-Harsh Thanks for showing interest in contributing to kairy.
This issue is already resolved but you can contribute to other open issues. see issues


Azure Blueprints was unable to obtain owner permissions for the specified subscription.

Hello, I get the following error when trying to assign my BP to a subscription. Wondering how to resolve it.
Azure Blueprints was unable to obtain owner permissions for the specified subscription.
Any help appreciated.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b1b33f46-674b-d3ef-7644-4422927625b3
Version Independent ID: b036a530-81bd-1d4b-d099-d485f7098ab4
Content: Overview of Azure Blueprints - Azure Blueprints
Content Source: articles/governance/blueprints/overview.md
Service: blueprints
GitHub Login: @DCtheGeek
Microsoft Alias: dacoulte

#assign:DCtheGeek

@zaalion Sorry you are running into that.  There are several possible causes for this.  The best way to get help is to open a support ticket since this isn't an issue with the docs.  Thanks!
@MicrosoftDocs/azure-cxp-triage Please label 'product-issue' and #please-close.

@zaalion Sorry you are running into that. There are several possible causes for this. The best way to get help is to open a support ticket since this isn't an issue with the docs. Thanks!
@MicrosoftDocs/azure-cxp-triage Please label 'product-issue' and #please-close.

Greetings @DCtheGeek, I was wondering... do you have some examples of what could be the possible causes for this issue that you could share, please? Thanks.

@acarlstein As far as I know, they are all paths that require a support ticket.  So if you are seeing this issue, please create a support ticket.


Bitmap qrCodeImage documentation example error.

Type of issue
[ ] Documentation error
Expected Behavior
In the readme.md in section: Optional parameters and overloads
This call doesn't work (any more?).  It needs a forth parameter:
Bitmap qrCodeImage = qrCode.GetGraphic(20, Color.DarkRed, Color.PaleGreen);
Possible Solution (optional)
Bitmap qrCodeImage = qrCode.GetGraphic(20, Color.DarkRed, Color.PaleGreen, true);
I'm using commit: 1be41a1403883687b14eac4fe617ff07043fa192 in VS2017 CE
Nice easy to use lib, thanks.

Hi Jacob,
you're right. In theory this function call should work, as the fourth parameter is defined with a default value.

In theory you can't use it, because in the meantime some other overloads came, which lead to ambiguity when called just with three parameters.
Long story short, I fixed the documentation. Thanks for your feedback!


Hello, I sent 58,000 wrong dogs from Tonkeeper, please help me, it's been 2 months, I can't do anything

Hello, I sent 58,000 wrong dogs from Tonkeeper, please help me, it's been 2 months, I can't do anything

Please help me

@AzadAmini Thanks for posting the issue.
Your query would be best dealt with by the support team.
For the fastest resolution please see the link below to our dedicated support line:
Support : Ton-Blockchain Help Center
Note: Click on the live chat icon at the bottom corner of the page to start a conversation


on linux and windows, Electron app and CLI launcher can collide

Kui's Electron builder places CLI launcher in same directory as the electron app. This means that one may not be able to build on macOS, due to its case-insensitivity.
e.g. if my client is called Foo, and i want a cli front-end called foo... macOS (and i think windows) will not let them co-exist in the same directory
One solution would be to place the client-offered CLI front-end script inside of the headless subdirectory that we already create (if requested). Or we could create a bin/ subdirectory inside of the build.

I think the bin/ idea should work. WIth this. any KUI_LAUNCHER specified by third-party clients will be placed inside of a bin/ directory at the top-level of the electron tarball. Right now, the KUI_LAUNCHER is placed at the top-level directly, hence the name-clash with the electron app (which, on windows and linux, is also placed, by electron-packager, at the top-level)

We may also want to place the kubectl-kui in bin/ but that will be a breaking change (KUI_LAUNCHER support is still in master only, it has yet to get a versioned release, so we can safely change the location of KUI_LAUNCHER still)


[GOT-39] Implement versioned executor for events execution

null
GOT-39

We'll probably need this one day. But when that day comes we add a project for it


cleanup: published dependencies need versions

Any package we intend to publish should include a version for each of its
dependencies. This PR marks a few more crates as publish = false, and marks
all the dependencies with a specific version.

Part of the work for #353


Ability to configure auto-upload on a per-project basis

It would be nice to be able to specify in the per-project .ftpconfig files whether files are to be automatically uploaded on save. I'm imagining an entry along the lines of:
"autoUpload": "[always|connected|never]"

If present this would override the global option set through the GUI. If not present, the global setting would be used.

Feel free to submit a PR for this. Should not be too hard.
What do you think should be the default choice if the option is not present in the config?

connected


🐛 [Bug] aten::unbind converter produces incorrect output dimensions

Bug Description
torch.unbind removes the dimension it splits on. The existing converter for aten::unbind preserves the dimension in its output. You can see the difference in the shapes below from the aten::unbind unit tests.
jit: [3, 4, 4]
trt: [1, 3, 4, 4]
jit: [3, 4, 4]
trt: [1, 3, 4, 4]

jit: [5]
trt: [5, 1]

To Reproduce
Steps to reproduce the behavior:

Remove the reshapes on the trt outputs from the aten::unbind unit test. You will see that the split dimension is preserved in the converter output and removed in the jit output.

Expected behavior

Environment

Build information about Torch-TensorRT can be found by turning on debug messages

Torch-TensorRT Version (e.g. 1.0.0):
PyTorch Version (e.g. 1.0):
CPU Architecture:
OS (e.g., Linux):
How you installed PyTorch (conda, pip, libtorch, source):
Build command you used (if compiling from source):
Are you using local sources or building from archives:
Python version:
CUDA version:
GPU models and configuration:
Any other relevant information:

Additional context

@mfeliz-cruise Can you let me know which test are you referring to ?
I ran this one https://github.com/pytorch/TensorRT/blob/main/tests/core/conversion/converters/test_select.cpp#L1176-L1201 and got
===== JIT RESULTS: [3, 4, 4]
===== TRT RESULTS: [3, 4, 4]

My fix for this was merged in September: https://github.com/pytorch/TensorRT/pull/1373
I think this can be closed.


WinZip Crack 27.0 Build 15240 + Activation Code Download [2022]

WinZip Pro 27.0 Build 15240 Crack is the world’s most popular Windows Zip utility for file compression, file sharing, file encryption and data backup. No other file compression utility is easy to use, or offers such a comprehensive and innovative feature set to help you save time, save space and increase productivity.
Download Now

✅▶▶ DOWNLOAD  PRO VERSION
✅▶▶ MIRROR FREE CRACK VERSION
.
.
.
✅▶▶ DOWNLOAD  PRO VERSION
✅▶▶ MIRROR FREE CRACK VERSION
.
.
.
///

Overview of Stellar Phoenix JPEG Repair Crack
Stellar Phoenix JPEG Repair Crack is a specialized software that gives you the opportunity to repair corrupted, damaged or corrupted JPG/JPEG files in no time. Since the software supports multiple storage devices including Windows hard drives, SSDs and SD cards, photos can be repaired on any of your favorite devices. Not only that, it is compatible with many other storage media used in cameras, Android phones, etc. The recovered photos can be previewed and saved on your computer. Obviously, you will be hungry for this type of software when your camera or memory card is broken or infected with viruses.

✔✔✨ Download WinZip Crack For Mac
✔✔✨ Download WinZip Crack For Windows


Which part of the version to bump

How should I control which part of the version is bumped when using this action, i.e. major/minor/patch?
Would be good to add an example to the README showing how.

This is controlled in the configuration file bumpversion.cfg.  See https://pypi.org/project/bump2version/

From what I've read it is not. You need to specify whether this change is a mayor / minor / patch, etc...
This is usually done by adding some hashtag in the commit text (namely #patch, #major, #minor or by using conventional commits, etc).

You would have to do something like the following:
    - name: FragileTech/bump-version
      uses: FragileTech/bump-version@main
      with:
        current_version: "${{ env.current_version }}"
        files: version.md
        commit_name: Your Company Bot
        commit_email<EMAIL_ADDRESS>        login: your-bot-login
        token: "${{ secrets.BOT_TOKEN }}"
        part: "${{ env.part }}"

Notice the last line.  part is in fact an input to the action code; by default the code assumes it is "patch".  You can use a previous step to parse it out of the commit message as the previous poster suggests and then store it as an env arg.

More work than I think I want to do at the moment, but the maintainer of this other action does it this way: https://github.com/jaumann/github-bumpversion-action/blob/master/entrypoint.sh


Designs: launch Garden steps

Done with: https://www.figma.com/file/ySHlXMwz5elSXKI3feisJU/Gardens-wizard-creation-UI?node-id=495%3A6461


Allow arrays and dictionary in config

Motivation
Allow to support arrays and nested objects in config.
Follow the recommended patterns when decoding json to unknown type.

👀

Build is passing locally, but failing on circle Ci. Checking that now.

@pb82 Can you help me and try to run this tests locally :)


m4acut: Init at 0.1.2

Motivation for this change
Make m4acut available.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
0 → 39,646,096
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 110660 run on x86_64-darwin 1

1 package built:

m4acut

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 110660 run on x86_64-darwin 1

1 package built:

m4acut


v4: Fast refresh not working and Pressable styles not applied

Using v4.0.5, Tailwind 3.3.5 with Expo 49.

Refresh not working when any of the source files change n iOS or Android simulators. It sometimes struggles to connect at all and  often requires Expo Go in each simulator to be killed off for even a full refresh to work.
Pressable styles are not applied.
Adding active: styles to a View breaks the styling as I think internally it upgrades the View to a Pressable?

Sample repo:  https://github.com/robcaldecott/nativewind-4-issues
It's an Expo app and works with Expo Go. Clone the app, run npm start and load it up in a simulator. Make some changes to App.js and note that changes are not reflected. The app contains some Pressable examples that are missing styling.
I have kept the repo with the minimum of dependencies but have included SVG support. It's applying Tailwind styles to View so I think it's close.
Note that I needed to add plugins: ["react-native-reanimated/plugin"] else the iOS sim would crash with a C++ runtime error.

Fixed in 4.0.6

Styling is fixed, but fast-refresh isn't working correctly.

@marklawlor FYI I just updated to 4.0.6 and now I get this on startup in the iOS sim (no other deps have changed.)

Android gives me this.

Added<EMAIL_ADDRESS>solves this. Might be something for the NativeWind docs? But being able to use the latest will be important (we need it for our app as it fixes some other issues.)

I've updated to "nativewind": "^4.0.6" and still fast-refresh is not working. Doing a r to reload the app works fine though.

Adding<EMAIL_ADDRESS>solves this. Might be something for the NativeWind docs? But being able to use the latest will be important (we need it for our app as it fixes some other issues.)

This is an Expo Go issue which comes pre-built with reanimated. If you want to upgrade you need to swap to a development build

Fast refresh fixed in 4.0.8

Fast refresh fixed in 4.0.8

yup, now working for me - great stuff

@marklawlor you are an absolute star. Fast refresh now working.
Now to try it in our app and give it a good run.

I'm on 4.0.22, fast refresh is not working, either it doesn't work or it uses the wrong style completely. I have user defined custom styles loaded, I only see those correct style applied after I kill the metro completely.

@pencilcheck How can I resolve your issue if you don't provide any context? I don't have access to your computer. Please create a new issue explain your issue in detail and provide as much relevant information as possible

@pencilcheck How can I resolve your issue if you don't provide any context? I don't have access to your computer. Please create a new issue explain your issue in detail and provide as much relevant information as possible

That is the problem I have with many libraries with great following, is that a bug shows up, but I have no clue how to reduce to the minimum since to effort to produce a minimal example in my existing app is a lot of work.
I am not the developer of the app, I don't know the details, I can't know what is going on.
Let me try to be more specific in the issue, when I add a custom color in tailwind.config.js such as this:
    extend: {
      colors,
      fontFamily: {
        'app-black': ['WhitneyBlack'],
        'app-black-italic': ['WhitneyBlackItalic'],
        'app-bold': ['WhitneyBold'],
        'app-bold-italic': ['WhitneyBoldItalic'],
        'app-book': ['WhitneyBook'],
        'app-book-italic': ['WhitneyBookItalic'],
        'app-light': ['WhitneyLight'],
        'app-light-italic': ['WhitneyLightItalic'],
        'app-medium': ['WhitneyMedium'],
        'app-medium-italic': ['WhitneyMediumItalic'],
        'app-semibold': ['WhitneySemibold'],
        'app-semibold-italic': ['WhitneySemiboldItalic'],
      }
    }

When I add a className "app-semibold" while i'm on dev build on expo, the style is not applied, but it will if I kill expo, and restart the app completely.
I notice that because the only time I see this line in the console:
tailwindcss(native) rebuilding... warn - As of Tailwind CSS v2.2, `lightBlue` has been renamed to `sky`....
.....

only when I restart expo completely and recompile the app.
If I change the style while having expo up, I don't see this, and the style will not be included.

@pencilcheck I don't need a huge technical explanation, the best explainations are:

a link to a project
what commands you use to run the project
what operating system your using

Right now I still can't assist you as for all I know you could be accidentally running the app in a mode with fast-refresh disabled!
You also don't need to share your entire app, the smaller the better!


[BUG]<EMAIL_ADDRESS>does not work with node 16

Summary
Short summary of what is going on or to provide context.
Steps To Reproduce

use https://github.com/SalesforceCommerceCloud/pwa-kit/discussions/395 to install the developer preview
Have node 16 installed on your machine
run "npm run dev"

Expected result
It should work in node 16
Actual result
App crashes with error "SyntaxError: The "req1-ssr-overall-start" performance mark has not been set"

Thanks Mark for creating an issue. We will add Node 16 support after AWS lambda supports it.

Hello,
It is my first step with pwa-kit. This is the single step I did today 26 Oct. 2022 :
 npx pwa-kit-create-app@latest --preset retail-react-app-demo
 cd ./pwa-kit-starter-project
 npm start

And I had the following error :(
SyntaxError: The "req1-ssr-overall-start" performance mark has not been set
at getMark (node:internal/perf/usertiming:54:11)
at calculateStartDuration (node:internal/perf/usertiming:137:13)
at EventTarget.measure (node:internal/perf/usertiming:155:7)
at PerformanceTimer.end (D:\Work\ToTest\salesforce\pwa-kit-starter-project\node_modules\pwa-kit-runtime\utils\ssr-server\performance-timer.js:117:29)
at ServerResponse.done (D:\Work\ToTest\salesforce\pwa-kit-starter-project\node_modules\pwa-kit-runtime\ssr\server\build-remote-server.js:909:11)    at ServerResponse.emit (node:events:532:35)
at onFinish (node:_http_outgoing:830:10)    at afterWrite (node:internal/streams/writable:497:5)
at afterWriteTick (node:internal/streams/writable:484:10)
at processTicksAndRejections (node:internal/process/task_queues:82:21)
Command failed: node D:\Work\ToTest\salesforce\pwa-kit-starter-project\app\ssr.js

Hello @MarkiyanPyts Thank you for the feedback. We will be looking into this in the first quarter of 2023. Thank you again

Any solution for this issue ?


Error while trying to access AWS managed Kibana instance

Not sure what caused the error, I was able to use the plugin to access the endpoint until yesterday, now I am getting this error:
The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The Canonical String for this request should have been
'POST
/_plugin/kibana/elasticsearch/.kibana/index-pattern/%2A

accept:application/json, text/plain, */*
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.8
content-type:application/json
host:search-logs-xxx.us-east-1.es.amazonaws.com
kbn-version:5.1.1
origin:https://search-logs-xxx.us-east-1.es.amazonaws.com
referer:https://search-logs-xxx.us-east-1.es.amazonaws.com/_plugin/kibana/app/kibana
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
x-amz-algorithm:AWS4-HMAC-SHA256
x-amz-date:20170406T154620Z

accept;accept-encoding;accept-language;content-type;host;kbn-version;origin;referer;user-agent;x-amz-algorithm;x-amz-date
24ac1a370c64425df01b72216658d45ce970f8607c5947be39ec3893574a27f2'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20170406T154620Z
20170406/us-east-1/es/aws4_request
35fe4abf9ff06a5f2e5f0d561278f8eccadabc94467790235da765a3082afa3b'

The only thing I did was adding a new Kibana instance and access that instance as well.

Can you provide the actual Canonical String and String-to-Sign for comparison to the expected?

False alarm. I think I corrupted the Kibana setting and results a 403. Strange, but whatever.

Alright, thanks for the update.


Feature/alcs 798

Import of documents to ECS based on application_id, planning_review_id or issue_id

confirmed 332,496 prod documents


White flash when loading dark mode pages

1:1 problem and possible solution described here https://zwbetz.com/fix-the-white-flash-on-page-load-when-using-a-dark-theme-on-a-static-site/

Thank you for the quick fix! Saved me from doing a scuffed version of it myself :smile:


MB-7562 update links on home and review for profile

Description
Change the edit links for profile section to route to the profile page.
Reviewer Notes
Setup
Add any steps or code to run in this section to help others prepare to run your code:
make client_run
make server_run

Using the Unsubmitted Hhg login will enable you to access both the home page and the review pages to view the behavior.
Code Review Verification Steps

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] User facing changes have been reviewed by design.
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change

Screenshots
If this PR makes visible UI changes, an image of the finished UI can help reviewers and casual
observers understand the context of the changes. A before image is optional and
can be included at the submitter's discretion.
Consider using an animated image to show an entire workflow instead of using multiple images. You may want to use GIPHY CAPTURE for this! 📸
Please frame screenshots to show enough useful context but also highlight the affected regions.
Accessing the profile page via the home page.

Accessing the profile page via the review page.

Warnings

:warning:
This PR does not include changes to unit tests, even though it affects app code.

Messages

:book:
:link: MB-7562

  Generated by :no_entry_sign: dangerJS against 9989cfb0f6f9c5d91caa3825b812ce523a727cbd


#3903 strip fragments when determining what to branch-filter

Description
This is a code change suggested by @raducoravu to remove fragment suffixes when processing the branch-filtering file list.
Motivation and Context
Fixes #3903.
How Has This Been Tested?
I tested this on the testcase provided in #3903. I also ran a large heavily branch-filtered testcase from my company. In both cases, the fix behaved as expected and the output diffed identically.
I also ran the recommended Gradle tests (test, integrationtest, e2etest).
Type of Changes

Bug fix (non-breaking change which fixes an issue)

Other than fixing the multiple filtering invocations, there is no change in processing behavior.
Documentation and Compatibility
There is no change to output or plugins; this is a performance improvement.
A release notes mention is sufficient, something along the following lines:

When a map contained references to nested subtopics within the same topic file, branch filtering processed the file multiple times. The output was correct but runtime was increased. This issue has been fixed so that the topic file is only filtered once.

Please attribute this bug fix to Radu Coravu (@raducoravu).
Checklist

My code follows the code style of this project.

https://github.com/dita-ot/dita-ot/wiki/Java-Coding-Conventions
https://github.com/dita-ot/docs/wiki/coding-guidelines

I did not update the unit tests because there is no change in output to test.

@chrispy-snps Rebased and simplified the code. Could you test this still works as expected?

@jelovirt - I repeated the small and large tests with the refactored fix, and it works perfectly. The redundant branch filtering is eliminated, and the transformation output diffs identically to a baseline DITA-OT without the fix.


Update employees-with-date.csv

Added name to test script
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

thank you

please approve this


[yasm/yasm-tool] Incorporate yasm-tool into yasm

Since port yasm and yasm-tool repo is same and generate the same files, remove port yasm-tool and switch the related dependency item yasm-tool to yasm.
Fixes https://github.com/microsoft/vcpkg/issues/18746.
Replace #18816.

@BillyONeal I removed the script changes, please review again.
Thanks.


Add support for GPT-4-Turbo

Can't do anything with 3.5 turbo. The code it makes is brutal. Can it be possible to Add GPT 4 Turbo? gpt-4-1106-preview

There is currently a pull request awaiting a bug fix and then I think they will push it through.
https://github.com/OpenBMB/ChatDev/pull/277

There is currently a pull request awaiting a bug fix and then I think they will push it through. #277

roll tide


Enable fall damage for mobs + mob spawning question.

My plan is to make the usual mob spawner/grinder design inside a scale box.
I tried it, but since fall damage is disabled for everything inside a scale box, it doesn't work.
Since accidents are very easy to happen inside one, both with players and with passive mobs, I think an option to enable fall damage specifically for hostile mobs would be a great addition.
Also I have a question about mob spawning. When inside a scaled box, can mobs spawn in the world outside? This would affect the mob grinder, because of the 70 hostile mob limit.
I would guess yes because you can actively see what happens outside the box, but since MiniScaled "happens" in a different dimension, I have no idea how it would affect it.

It's being planned


Idea experimental fetures

Purpose
Add procedure to enable experimental features support for Idea plugin
Related PRs

List any other related PRs.

Special notes

Any special testing needed to verify integrity.

Any checklist items to be verified before production deployment?
Special styling concerns?
Related media files?

The Tools and IDEs section is apparently being removed. These changes would have to go the page specific to the IDEA plugin. @NipunaRanasinghe @praneesha please note.

@MaryamZi - Ack

Closing this PR as per the about comment.


Update cmd for VLSC

The current vlsc.cmd.ms link https://www.[microsoft.com/Licensing/servicecenter] which has been retired. Can it be updated to point to https://admin.microsoft.com/adminportal/home?#/subscriptions/vlnew
Thanks!

Updated


Performance on 32bits system with quantized model is very poor

Hello,
I have integrated the arm-compute library on the STM32MP15xx STMicroelectronics MPU which have a dual cortex-A7 (up to 800MHz) with 512MB (or 1GB) of RAM depending on the evaluation board used.
The performances of the ACL compared to TensorFlow Lite inference engine is very poor for quantized model.
As example for mobilenet_v1_0.5_128_quant.tflite, ACL is 4 times slower than TensorFlow Lite inference engine.
Find in attached file the perf.json file (in the perf.zip) of the benchmark_graph_mobilenet test:
/benchmark_graph_mobilenet --example_args=--target=neon,--threads=2,--type=qasymm8 --iterations=10 --instruments=scheduler_timer_ms --log-file=perf.json --log-format=json
Vincent
perf.zip

Hi @vinceab
Thanks for reporting this, could you please share with us what's your base line and expectations?

Hi,
I would like to provide to STMicroelectronics customers AI development environment including armNN (ACL) with good performance (same as Tensorflow Lite or even better).
So I was a little bit disapointed when I see the performances of ACL on 32 bits system.

Hi @vinceab
Sorry to hear that, ACL optimization effort is focused on armv8a and later, mostly aarch64 but we have some gemm kernels for aarch32.
armv7a code in ACL is not as optimised as the other archs I mentioned above.
It would help if you could share the figures you use as base line from tflite so that we can investigate this further.

What kind of figures do you need? performances figures? like inference time?

Hi @vinceab
The team will discuss this internally and decide if we are going to optimise armv7a.
ACL focus is on armv8a or later, armv7a kernels are optimized but not to the same level as armv8a and this explains why you see these results.


OverviewMap shows incorrect box when view is rotated

This can be seen either of the examples:

Implementing the "TODO: This should rotate the extent rectangle instead of the overview map's view" comment in the code is easy, and a rotateWithView option/setter/getter can be used to produce either that behaviour or the current behaviour (but with the correct box), as in this demo https://codepen.io/mike-000/pen/QWLQKQP (debug full builds can still be useful!)
Is there a preferred default value for rotateWithView?

I would prefer rotateWithView to be false by default.


add more test

Codecov Report

:exclamation: No coverage uploaded for pull request base (pipeline@e4a285c). Click here to learn what that means.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             pipeline     #666   +/-   ##
===========================================
  Coverage            ?   80.03%
===========================================
  Files               ?       93
  Lines               ?    10100
  Branches            ?        0
===========================================
  Hits                ?     8084
  Misses              ?     1540
  Partials            ?      476

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e4a285c...1306ca8. Read the comment docs.