Add reverse-z depth buffer support

Add support for reverse-z depth buffer resolve godotengine/godot-proposals#3539
@BastiaanOlij    @clayjohn
These changes break compatibility.
I finished part of it.
Have finished:

a part of operations related to Projection class, such as creating projection matrix and get_projection_plane function.
all depth clear values in cpp files are inverted (e.g. 1.0 changed to 0.0).
all depth test function inverted (e.g. LESS changed to GREATER).
glsl for skybox.
light shadow.

Unfinished and known issues:

the xr part of the Projection class is not tested.
ssao is incorrect. (should be problems with most post-processing effects)

Some problems encountered:

some depth comparison methods are specified in the sampler, not in the glsl file.
sometimes the depth buffer is directly manipulated in glsl.

This needs more testing by myself and clay and there are a few change we likely want. But it is important to know that there is consensus within the rendering team that the compatibility breakage is acceptable as this will effect really limited edge cases.
Anyone who does unprojection in shaders is not effected as the unprojection deals with this. Only when working with the z values as is could result in breakage. The benefits far outweigh the cons here.
We do have a few suggestions for limiting breakage, those will be forthcoming soon.

@Khasehemwy one important change you might be able to do, we don't want the Z-flip to be part of the code for populating the the projection matrix. So we leave all the setters etc. alone.
Instead the Projection class needs a single reverse_z function that applies the flip. This way we can keep using the projection matrix as is, we can keep the culling logic as is, we simply call the reverse_z early on in the render_scene logic, maybe as part of render_scene_data so only the rendering happens with the matrix with Z reversed.
That has far less impact than doing this early on.

@Khasehemwy one important change you might be able to do, we don't want the Z-flip to be part of the code for populating the the projection matrix, but only apply this when populating the GPU buffers. So we leave all the setters etc. alone.
The Projection class needs a single reverse_z function that applies the flip. This way we can keep using the projection matrix as is, we can keep the culling logic as is, we simply call the reverse_z early on in the render_scene logic, maybe as part of render_scene_data so only the rendering happens with the matrix with Z reversed.
That has far less impact than doing this early on.

I changed the projection matrix back to normal z, then added reverse z-related operations, and added reverse-related operations where I thought they needed to be added.
In addition, I found that there is a problem with the Dual Paraboloid shadow mode of Omni Light. It seems that the official version also has problems. It may not be caused by my changes.

Will this not be an issue (asking just in case): https://github.com/roalyr/godot-for-3d-open-worlds/issues/15 ?

Ok, we talked about this in the rendering meeting today.
We would prefer it if all the if(is_reversed_depth) code was removed; once the corrections have been applied those functions shouldn't be called anymore anyways.
In addition, it would be nice if there was the option (controlled by a boolean) to perform rev z in set_depth_correction and create_depth_correction, defaulting to true.
Once those changes have been made, there shouldn't be anything blocking this PR from being merged.
Great Work!

FSR2 will likely need some changes.
https://github.com/godotengine/godot/blob/b8f106acb24387d2f2c746a586edc0728fd10aaf/servers/rendering/renderer_rd/effects/fsr2.cpp#L523-L533
"\n#define FFX_FSR2_OPTION_INVERTED_DEPTH 1\n" must be added to the define (after "\n#define FFX_FSR2_OPTION_HDR_COLOR_INPUT 1\n" seems like a good spot).
https://github.com/godotengine/godot/blob/b8f106acb24387d2f2c746a586edc0728fd10aaf/servers/rendering/renderer_rd/effects/fsr2.cpp#L811
Should be changed to:
context->fsr_desc.flags = FFX_FSR2_ENABLE_HIGH_DYNAMIC_RANGE | FFX_FSR2_ENABLE_DEPTH_INVERTED;
I haven't tested these changes yet or if they're necessary but at least according to the FSR2 documentation they'd be required.

We would prefer it if all the if(is_reversed_depth) code was removed; once the corrections have been applied those functions shouldn't be called anymore anyways.

But, the implementation of functions such as get_z_far is different in reversed-z and normal-z. If the projection matrix is not directly modified like the beginning, I think we can only add a judgment on whether it is reversed-z or not in get_z_far.

Why must far and near planes be reconstructed from matrix and normalized if they can simply be declared as Plane(0.0, 0.0, -1.0, z_far_val), for instance? Besides, I've mentioned before that large z-far values mess up plane normalization and you get an empty plane.

It seems to be the same problem as @Calinou mentioned before. I tried the initial version of PR and had problems too.
I haven't figured out what causes it yet. There are definitely a lot of things that need to be changed. I will change the basic rendering process, and other things will probably need to be changed by the official later.😢

Oh, I agree to change the relevant operations to set_depth_correction(). My focus is actually here:

We would prefer it if all the if(is_reversed_depth) code was removed; once the corrections have been applied those functions shouldn't be called anymore anyways.

the implementation of functions such as get_z_far is different in reversed-z and normal-z.
I think we can only add a judgment on whether it is reversed-z or not, in get_z_far

The relevant code is:
real_t Projection::get_z_far() const {
	const real_t *matrix = (const real_t *)columns;
	Plane new_plane;
	if (is_reversed_z()) {
		new_plane = Plane(matrix[3] + matrix[2],
				matrix[7] + matrix[6],
				matrix[11] + matrix[10],
				matrix[15] + matrix[14]);
	} else {
		new_plane = Plane(matrix[3] - matrix[2],
				matrix[7] - matrix[6],
				matrix[11] - matrix[10],
				matrix[15] - matrix[14]);
	}
...

The relevant code is:

Am I wrong in assuming there would be no need for this if you just didn't modify the matrix at all from its current representation already and made the reverse Z a separate correction instead? It sounds to me like the near and far planes should be identical regardless of whether reverse Z is used or not, it just looks to me like you need the branching because you're modifying the matrix itself instead of just applying a correction before rendering.
Is that correct? Or does using reverse Z actually imply major differences as to what the near and far values mean?

I understand, apply reverse when finally passing it to the GPU, so that I don't have to consider the reversed-z situation before.
But I see that both create_depth_correction() and get_z_far() seem to be exposed to the user. If the user uses create_depth_correction(), gives the result to the projection matrix, and then uses get_z_far(), it seems that the wrong value will be obtained.

I understand, apply reverse when finally passing it to the GPU, so that I don't have to consider the reversed-z situation before.
But I see that both create_depth_correction() and get_z_far() seem to be exposed to the user. If the user uses create_depth_correction(), gives the result to the projection matrix, and then uses get_z_far(), it seems that the wrong value will be obtained.

create_depth_correction doesn't actually correct the current matrix AFAIK, it just sets the matrix to a fixed set of values to make a correction matrix.
https://github.com/godotengine/godot/blob/c05506f042fbaae40971b3319e262df983af80ce/core/math/projection.cpp#L796-L815
Therefore you'll never get a valid Z Far value out of this, as it's a matrix intended purely for being used as (correction * projection) in operations later. I don't think you need to worry about all methods working correctly once operations like these have been performed: hence why it's probably better to just not worry about reversing the matrix itself and leaving it as is and give that responsibility to a correction matrix instead.

After OpenGL uses reversed-z here, it is still [-1, 1], but the far distance is closer to -1, which should have no effect on the accuracy.
What we discussed in the issue before is that all APIs use reversed-z method. so that there is no need to deal with two situations, which facilitates subsequent development.

I have another question:
I see the PR adds reverse Z to the GLES3 renderer without the ability turn it off.
However, in most cases we must not use reverse Z with GLES3 because you need GL_ARB_clip_control which is often not available with GLES3. In fact I don't see glClipControl being called at all.
Reverse Z gives LESS precision (not more) when not using GL_ARB_clip_control / glClipControl.

I'll start by saying that low-level graphics programming is definitely not my wheelhouse, so this might not be of any use, but I did learn about an alternate method to potentially do reverse-Z in OpenGL, involving using glDepthRange. This old Outerra post talks about it: https://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html (DirectX vs OpenGL section). And apparently this function is still available with GLES (if floating point depth buffers are available)

I moved all reverse-related operations to set_depth_correction(). I also added bool p_remap_z and bool p_restore parameters. Because set_depth_correction() is used in OpenGL, p_remap_z is necessary, and during the process of adapting shadows, I found that it would be more convenient if I could control the projection matrix restoration, so p_restore was added.

Cool, thanks!

I also looked at https://outera.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html. I feel that OpenGL does not need this kind of processing, because for compatibility, it usually uses a 24-bit depth buffer. I tried a 24-bit depth buffer before, the effect of reversed-z was not good enough too.

It indeed doesn't do much, but Clay pointed out to me we'd be switching to reverse Z in OpenGL anyway for the sake of consistency of the shader behavior between renderers even if it doesn't provide much of a benefit. Otherwise you'd have to keep in mind that the range of values you get in one backend would be reversed in the other one.

Ok, we looked at this PR again during this week's rendering meeting. Thanks for incorporating the changes we suggested last time, this is already looking way better.
There are a couple minor nitpicks we discovered and would like to see fixed:

set_depth_correction Thanks for moving all the rev_z stuff on the cpu side into this function, this is far better to reverse z early on and then having to be careful with anything on the cpu side that interacts with projection. However, it has become a bit complicated to understand what exactly it is set_depth_correction is actually doing, especially with the rather convoluted if statements. Some documentation would be really appreciated, especially as to what the purpose of restore is.
A couple of times you are doing something along the lines of 1.0 - depth in the shader code, which is less than ideal since it results in an immediate loss of the additional precision. This should be avoided at all cost, the shader should always operate with rev z.
The light calculation in the shader apparently reverses the light depth only moments before sampling, which means that we have already lost any additional precision. Instead, the light matrix should be reversed before it is used to calculate the depth in the first place (which it might already be? reversing shadow depth one time too often could have caused the shadow artifacts @mrjustaguy has reported). Note that this change would mean that any and all modifications that happen to the shadow depth (such as e.g. shadow bias) now also need to be reversed.
It would be neat if you could get FSR2 working with this PR, if Dario is correct it might be as simple as adding two lines. If that doesn't work and you don't want to investigate it yourself, that's fine too, we could fix this in a follow-up pr.

If you have any questions, feel free to reach out to us on the rendering channel on RC.

@BastiaanOlij Could you maybe look at how this PR performs in XR? Sorry for pinging you directly, but I lack the permissions to request reviews from teams.

A couple of times you are doing something along the lines of 1.0 - depth in the shader code, which is less than ideal since it results in an immediate loss of the additional precision. This should be avoided at all cost, the shader should always operate with rev z.
The light calculation in the shader apparently reverses the light depth only moments before sampling, which means that we have already lost any additional precision. Instead, the light matrix should be reversed before it is used to calculate the depth in the first place (which it might already be? reversing shadow depth one time too often could have caused the shadow artifacts @mrjustaguy has reported). Note that this change would mean that any and all modifications that happen to the shadow depth (such as e.g. shadow bias) now also need to be reversed

I started looking into resolving this issue. Unfortunately, it is quite complex. Cubemap shadows are rendered using non-reverse-z, then they are linearized and scaled to match the dual paraboloid shadows and flipped to reverse-z. Dual paraboloid shadows are rendered with reverse-z.
Omnilight shadows are not calculated in NDC space though, they are in a special space that is essentially the local light space scaled by the light range. Ultimately, what we calculate is the distance to the light in this modified light space.
So right now, to make this work with reverse-z we are forced to flip the scaled light distance right before the shadow map comparison.
This can't easily be fixed for a couple of reasons:

The dual paraboloid mapping relies on its on mapping instead of using perspective projection (so we can't get the benefits of reverse-z anyway)
All shadows share a sampler that is tuned for reverse-z. So at sample time, we need to be in reverse-z
Ultimately, the sample position is less important than the sample that is actually stored in the texture
Typically shadows are 16 bit only and don't benefit from reverse-z anyway.

I'm going to continue looking at this tomorrow as I suspect there is a way to implement this a bit cleaner now that I understand the problem. We might even be able to create a sudo-projection matrix that works.

I am also looking at Cubemap shadows. It is no problem to directly use the reversed-z projection to generate the Shadow Map. But when rendering objects, it is a bit tricky to sample the Shadow Map. I can only use 1.0 - depth.

I have a fix locally for the directional light issue. I will make a PR to your branch soon!

@Khasehemwy I made a PR to your branch. If you merge the PR to your branch it will show up here as well https://github.com/Khasehemwy/godot/pull/1

So far I have tested (on all backends):

regular depth precision
shadows

With my PR both depth and shadows are working correctly. Including fixing the issue mrjustaguy reported.
I have not tested post processing or GI which are other areas where things might break. Before this is merged we need to:

Merge my PR into Khasehemwy's branch
Test post processing and GI and confirm they continue to work

I think we should try to fix the WebXR regression after merging as it might take a bit for us to narrow down the issue.

How does Reverse-Z impact user shaders? (gdshader) I'm noticing some rather 'unexpected' behavior with PROJECTION_MATRIX and depth_texture. I'm aware that this is part of the reverse z buffer breaking changes, but is there any way around this? Sorry to clutter this thread with a rather novice question, but I'd be very appreciative if someone could explain what exactly changes about these values and how to bodge something together to adapt existing shaders.

edit: managed to figure this out, leaving this for anyone else who's struggling
If you'd like to use Reverse-Z on existing user shaders, anywhere INV_VIEW_MATRIX is used needs to be inverted within the shader. Here's an example of how I managed this - might not be the best as I'm not a shader wizard, but it works.
mat4 modifiedMatrix = INV_VIEW_MATRIX;
modifiedMatrix[3][0] = -modifiedMatrix[3][0];
modifiedMatrix[3][1] = -modifiedMatrix[3][1];
modifiedMatrix[3][2] = -modifiedMatrix[3][2];

You can then use modifiedMatrix as you would normally use INV_VIEW_MATRIX.

reversed-z only affects the projection matrix, should have nothing to do with the view matrix(?). The INV_PROJECTION_MATRIX will also auto change, shader developers not need to change it.
This PR will indeed break shader compatibility. Most shaders should only need to change the depth comparison method.

Then it would appear that I've found an issue, unless I'm mistaken which I very well could be considering my novice state. I wrote a very crude test minimum-reproduction shader:
shader_type spatial;

varying mat4 modifiedMatrix;
const bool DoFix = true;
void vertex() {
	modifiedMatrix = INV_VIEW_MATRIX;
    modifiedMatrix[3][0] = -modifiedMatrix[3][0];
    modifiedMatrix[3][1] = -modifiedMatrix[3][1];
    modifiedMatrix[3][2] = -modifiedMatrix[3][2];
}

void fragment()
{
	if(DoFix)
	{
		ALBEDO = modifiedMatrix[3].xyz;
	} else {
		ALBEDO = INV_VIEW_MATRIX[3].xyz;
	}
}

with DoFix set to true, this produces the same result as in a normal current build of Godot. With it set to false, it produces the inverse. If I use this shader in a normal build of Godot, it does the opposite: DoFix reproduces the wonky matrix seen in the PR version. I don't think there's anything wrong on my end in my larger shader, but it's 1AM and I am rather sleep deprived so do with that what you will.

@violetfrost Without seeing your shader, it is impossible to pinpoint what the issue is. This PR doesn't alter the INV_VIEW_MATRIX, so your messages are a little confusing. You shader code also doesn't read from the depth buffer, so it really doesn't seem to have anything to do with this PR.
I have tested this PR with the following shader code (copied from the docs) and it works correctly:
uniform sampler2D depth_tex : hint_depth_texture;

void fragment() {
	float depth = texture(depth_tex, SCREEN_UV).x;
	vec3 ndc = vec3(SCREEN_UV * 2.0 - 1.0, depth);
	vec4 view = INV_PROJECTION_MATRIX * vec4(ndc, 1.0);
	view.xyz /= view.w;
	float linear_depth = -view.z;
	ALBEDO = vec3(linear_depth)/40.0;
}

Is there any chance you are applying INV_VIEW_MATRIX directly to the raw value from the depth (i.e. not converting to view space first)?
As a reminder, you need to convert to view space using INV_PROJECTION_MATRIX before you convert from view space into world space with INV_VIEW_MATRIX

@Khasehemwy Thank you for merging my PR. After my last update I thought about this a little more and I have a feeling that post processing is broken. At least for SSAO, SSIL, and SSR. They all linearize at some point and I'm not sure that our current depth linearization function handles reversed z values properly. I'm going to investigate a bit more tomorrow or Monday to confirm. Ideally I would like to merge this PR early next week.

Is there any chance you are applying INV_VIEW_MATRIX directly to the raw value from the depth (i.e. not converting to view space first)?

No - and in the minimum reproduction shader I wrote INV_VIEW_MATRIX returns a completely different output (looks to be directly inverted) on both the latest PR from @clayjohn [a83eb16fb] and the latest official build 4.2 [b09f793f5]. Note the value of DoFix in each respective editor window.

I can't reproduce your issue with your provided code. Testing this PR and testing 4.2.1. I get the same results.

At this point, you should probably check a couple of things:

Ensure you are building from this PR and not another one by accident (i.e. is it possible you have pulled this PR on top of unrelated local changes?)
Ensure you have the same build settings in this branch and when building 4.2.1
Ensure that nothing else is affecting your camera matrix (i.e. changes to the editor camera, switching from editor camera to a Camera3D node, etc.)

I really want to highlight that this PR does not touch that matrix at all. So it is extremely unlikely that the issue you are seeing is related to this PR.

A-ha! You were right - my sleep deprivation got the better of me. I was testing on the wrong branch - my apologies! Great work you all are doing :)

I think we should try to fix the WebXR regression after merging as it might take a bit for us to narrow down the issue.

Just to be clear, the issue isn't specific to WebXR - I had been testing with OpenXR on the Meta Quest. I think it probably affects stereo rendering with OpenGL on any XR platform.

Thanks for testing this in VR David!

Ideally I would like to merge this PR early next week.

What about the cubemap and omnilight shadows? I looked at the changes you made to the glsl files and didn't see you address that anywhere. According to GitHub, the only change to shadercode is a fix for shadow pancaking (to fix the bug mrjustaguy found).

Thanks for testing this in VR David!

Ideally I would like to merge this PR early next week.

What about the cubemap and omnilight shadows? I looked at the changes you made to the glsl files and didn't see you address that anywhere. According to GitHub, the only change to shadercode is a fix for shadow pancaking (to fix the bug mrjustaguy found).

They are stored in linear space. They don't benefit from reversed z to the same extent. And I don't think it's possible to avoid reversing them manually. With omnilight shadows we aren't comparing the depth of the shadow map to the depth in some coordinate space. We are calculating the distance from the surface to the light in world space and then comparing that to the shadow map. This means there is no way to bake the calculation into a projection matrix.
Additionally, shadows are stored in 16 bit textures. They don't benefit from reversed z anyway

Thanks @Calinou I'm working on fixes these cases now:

[x] SSR
[x] SSAO
[x] SSIL
[ ] DoF
[ ] SDFGI
[ ] VoxelGI
[ ] VolumetricFog

This should be ready to merge once https://github.com/Khasehemwy/godot/pull/2 is merged. I have now tested everything except XR. There are a few edge cases that might arise in XR so more testing is welcome, especially with GI and effects

Using the latest code on this PR, I've made a quick video showing the sky issue with XR and the compatibility renderer on a Meta Quest 3:
https://github.com/godotengine/godot/assets/191561/090084e6-a509-491f-8e5d-0f695cefeaf9
Rather than staying fixed in the right place, the horizon moves depending on how I turn my head (aka the camera). It sort of feels like it's moving in the inverse direction than it should in order for it to appear fixed in place.
And, it's actually worse than it appears in the video, because the left and right eye are showing something different (the video is only of the left eye): if I tilt my head to the left or right, the horizon will move one direction in the left eye, and the opposite direction in the right eye - breaking proper stereo perspective.
As I mentioned previously, this probably doesn't happen with the Vulkan Mobile renderer, only the OpenGL renderer.

It may be Vulkan is incorrect after modification.
I saw that sky.cpp has been modified:

You can try changing it to the following, and test Vulkan again:

I don’t know if it can be fixed. Sorry, I don't have an xr device to test it.

@Khasehemwy Thanks, that fixed the issue on the Vulkan Mobile renderer!
How can we translate that fix to OpenGL as well?
I've attached the changes I made per your screenshot as a patch, just so it's clear to everyone exactly what the changes were.
xr-vulkan-mobile-sky-fix.patch.txt

@Khasehemwy Thanks, that fixed the issue on the Vulkan Mobile renderer!

@dsnopek Thank you, Nice! I commit a change, maybe can fix OpenGL issue.

Thanks! The lastest changes do fix the sky issue on OpenGL, but create a new issue - it seems like it's un-reversing the depth buffer?
Here's a screenshot with Vulkan Mobile:

And here's with OpenGL:

@dsnopek I'm a little bit skeptical of p_render_data->view_projection[v]. It seems like it is combining a view-space operation into the projection:
https://github.com/godotengine/godot/blob/da945ce6266ce27ba63b6b08dc0eb2414594f7cb/servers/rendering/renderer_scene_render.cpp#L184-L185

@dsnopek I'm a little bit skeptical of p_render_data->view_projection[v]. It seems like it is combining a view-space operation into the projection:
https://github.com/godotengine/godot/blob/da945ce6266ce27ba63b6b08dc0eb2414594f7cb/servers/rendering/renderer_scene_render.cpp#L184-L185
Okay, ya it is. It a little per-eye correction in view space. It looks like we encode a transform that goes from view space to world space, back to view space then into clip space. The reverse-z portion should only apply to the clip space portion. But we don't have that at the rendering driver level! I think we need to keep the view-space operations out of the projection and then just combine them at the last minute. If view_projection is accessed anywhere else it is probably messing up a lot of things as a result

Ah this makes lots of sense Clay. This is the thing Juan came up with so we don't need to add a lot of extra shader code to handle the eyes separately in all sorts of processes.
The problem is that it's not just the eye offset left/right, but we can also end up moving the center point backwards so the combined frustum is usable. That shift now suddenly gets reversed as well with the reverse-z causing the weird wobble. It'll just be far more pronounced on headsets like the Quest.
This would impact Vulkan as well and is not limited to OpenGL

Actually let me do some more testing because the more I think of this, the more this should still work, there must be a shortcut we're taking in the unproject on sky.

Ok, I fixed it all up, we were applying patches over patches to try and work around the real issue. There were two:

We have to unproject at the far plane, not the near plane due to stereo having asymmetrical view frustums. If you unproject at the near plane (which we now do because we flipped near and far around) you're basically getting your sky as if the sky is inside of your eyeballs, hence the really weird shifts.
Once I fixed 1, GLES worked perfectly, Vulkan suddenly broke. Turns out we were creating a GLES projection matrix in the Vulkan renderer.

https://github.com/Khasehemwy/godot/pull/3 fixes these issues and undoes some of the workaround patches that were wrong.
I also found out that we're being really messing with our y-flip. Sky is actually doing the y-flip in the shader, and we're countering it in places by y-flipping when we don't need y-flipping and visa versa. It's a miracle this is working correctly in reflection probes, but it is:).
One day we should really clean this up and make everything render the same way up.
The volumetric code is a bit of a hack. What we're doing here is un-projecting the stereo view and reprojecting to mono. That's fundamentally flawed. We really need to do a stereo version of our volumetric buffer. That's a whole different thing for another day.

@BastiaanOlij Thanks so much!
I've retested the latest version of this PR (which includes Bastiaan's changes) using both OpenGL and the Vulkan mobile renderer on a Meta Quest Pro, and everything (including sky rendering) seems to be working correctly now. :-)

Looks like this PR is in good shape now. Is there anything else I can do to assist with the merge?

Sorry if this is an obvious question but this is a pretty big breaking change (as noted in the OP) that will impact user shaders.
How can I as a user modify my shaders to be compatible with both the 4.2 and 4.3 rendering design?
I am surprised that a change like this is better in all cases and would have no downsides. If this is true, do all other major engines also use this approach on dx/vulkan? (Should this perhaps be a project setting?)
I saw XR mentioned. Are there any interoperability concerns related to submitting reversed depth buffer to OpenXR?

Sorry if this is an obvious question but this is a pretty big breaking change (as noted in the OP) that will impact user shaders.
How can I as a user modify my shaders to be compatible with both the 4.2 and 4.3 rendering design?

Most of your shaders should be completely fine, this only has an impact on you if you either manually write to depth or read it. That's why we really want to get this merged before the compositor PR makes writing custom post processing shaders much easier.
Should you run into any problems all you need to know is that the depth buffer now goes from 1.0-0.0 instead of 0.0-1.0. This means that you might have to invert any compare ops you do and maybe switch additions and subtraction operations.

I am surprised that a change like this is better in all cases and would have no downsides. If this is true, do all other major engines also use this approach on dx/vulkan? (Should this perhaps be a project setting?)

Yes, this is the approach that is used by any recent-ish engine. It has major advantages when it comes to precision and accuracy with 0 downsides, so there is no point in adding a project setting to turn it off (as a matter of fact that would actually be counterproductive, since custom post-processing assets could break depending on the state of that project setting).
The only reason why this wasn't a thing in godot already is because this optimization has no visible advantage in opengl, and people forgot to add it when the engine moved to vulkan.

I saw XR mentioned. Are there any interoperability concerns related to submitting reversed depth buffer to OpenXR?

Not that I am aware of. As said before, rev depth is the current state of the art and recommended by every hardware vendor out there. I have little experience with developing for VR, but I would be seriously surprised if rev depth was a problem.

I am surprised that a change like this is better in all cases and would have no downsides.

Reverse Z has the following conditions:
Much Better in all scenarios if:

Depth Buffer is set to D32_FLOAT. Only very old GPUs (more than 15+ years old) do not support it.

However on Linux + X11 + OpenGL (i.e. Compatibility), Mesa does not support D32_FLOAT for the render window. Fortunately Godot does not render directly to the render window so this not an issue but it can be for other engines.

In OpenGL (i.e. compatibility) glClipControl is supported and is set to range [0; 1]. This is not a given for OpenGL ES (i.e. mobile).

Slightly worse if:

Depth Buffer is set to D24_UNORM (it should not be an issue in Godot) or
glClipControl is not supported (i.e. Compatibility in Mobile).

If this is true, do all other major engines also use this approach on dx/vulkan? (Should this perhaps be a project setting?)

Other engines chose to either move to reverse Z as well, or allow for optionally support both.
Supporting both options requires a lot of testing and maintenance which is why the Godot team chose not to support the old regular Z at all. Often engines that support both options end up having bugs when using regular Z because very few people actually use that code path (due to the massive superiority of reverse Z).

How can I as a user modify my shaders to be compatible with both the 4.2 and 4.3 rendering design?

Godot devs will have to answer you this one. You do make a point that perhaps Godot 4.3 should define "something" to signal user shaders that reverse Z is being used; in case a user wants to support both versions (<= 4.2 + >= 4.3).

Ok your answers all make sense. I am pretty sold.
the main thing then is having some docs on porting shaders. For example one shader here is hardcoded in the godot engine source and probably needs to be pretty:
https://github.com/godotengine/godot/blob/master/editor/plugins/skeleton_3d_editor_plugin.cpp#L919..L920
In terms of user shaders, godot vrm does something with the projection space z coordinate for outlines:
https://github.com/V-Sekai/godot-vrm/blob/d88d2cc5a629d21a33196ef33a71f4bcb2736916/addons/Godot-MToon-Shader/mtoon_common.gdshaderinc#L103
People download this code and expect it to work in both 4.2 and 4.3 so I might need to come up with some heuristic to check for the inverted z buffer... I assume it should be possible to determine from the sign of some element of the projection matrix?

I have little experience with developing for VR, but I would be seriously surprised if rev depth was a problem.

I did a little research on this and sadly, non of the APIs in OpenXR that allow us to submit a depth buffer, provide the ability to tell the XR runtime we're storing reverse-Z, meaning they will be incorrectly interpreted.
Right now we only use the composition layer depth extension, and that is generally turned off. This discussion actually made me find a bug in that logic that might explain some issues we've had in the past.
Metas Application Spacewarp will also be effected by this.
That said, seeing many game engines are switching over to this, it's something that I have raised within the working group, hopefully that will lead to discussions to eventually add support for this.

@clayjohn Awesome! Thank you all! All the submissions have been squashed now.

I assume it should be possible to determine from the sign of some element of the projection matrix?

@lyuma Yes, you can determine whether it's reversed-z in the shader by checking the value of the PROJECTIONMATRIX. When reversed-z is applied, columns[2][2] > 0 ( columns[2][2] = (p_z_far + p_z_near) / (p_z_far - p_z_near) ). The same principle applies to orthogonal as well ( columns[2][2] > 0 ( columns[2][2] = 2.0 / (p_zfar - p_znear); ) ). Of course, we should assume that p_z_far > p_z_near by default.

Ok your answers all make sense. I am pretty sold.
the main thing then is having some docs on porting shaders. For example one shader here is hardcoded in the godot engine source and probably needs to be edited: https://github.com/godotengine/godot/blob/master/editor/plugins/skeleton_3d_editor_plugin.cpp#L919..L920
In terms of user shaders, godot vrm does something with the projection space z coordinate for outlines: https://github.com/V-Sekai/godot-vrm/blob/d88d2cc5a629d21a33196ef33a71f4bcb2736916/addons/Godot-MToon-Shader/mtoon_common.gdshaderinc#L103 People download this code and expect it to work in both 4.2 and 4.3 so I might need to come up with some heuristic to check for the inverted z buffer... I assume it should be possible to determine from the sign of some element of the projection matrix?

@lyuma Neither of the shaders you linked will need to be modified. The only user shaders that will need to be modified are those that adjust DEPTH or read from the depth_texture without using PROJECTION_MATRIX or INV_PROJECTION_MATRIX. In practice, it almost never makes sense to manipulate depth in clip space, so I don't think we will run into this issue often.
In other words:
// Compatibility is broken (need to flip the sign)
float depth = texture(depth_tex, SCREEN_UV).r;
vec4 clip = PROJECTION_MATRIX * vec4(VERTEX, 1.0);
clip.xyz /= clip.w;
if (depth < clip.z) {
    ...
}

// This is fine
float depth = texture(depth_tex, SCREEN_UV).r;
vec3 ndc = vec3(SCREEN_UV * 2.0 - 1.0, depth);
vec4 view = INV_PROJECTION_MATRIX * vec4(ndc, 1.0);
view.xyz /= view.w;
float linear_depth = -view.z;
if (view < VERTEX.z) {
    ...
}

Sorry @AThousandShips , I clicked on the wrong one and got a review😟

I amended the commit message to clean the description which still included past fixup commit titles, and retitled it to be clearer, especially regarding the fact that it's changing the convention, not adding a new option.

Thanks! And congrats for your first – but massive! – merged Godot contribution :tada:

Adding a note for the dev blog post:

This dev release switches our depth buffer to using a "reverse z" projection. This means that instead of the depth going from 0 (close to viewer) to 1 (far from view), it goes from 1 to 0. This is a enhancement found in most modern engines and it significantly improves depth precision by taking advantage of how floating point numbers are stored. This is a breaking change, however, we think the compatibility breakage is minimal and well worth the benefits.
In particular, any operation that uses clip space values directly from the depth buffer are now reversed. That includes uses of the depth buffer in custom render hook callbacks and uses of the depth_texture hint in shaders. That being said, we are confident that most users are reading depth to reconstruct view space, or world space depth which still works the same as before. For example the below is a very common pattern that will continue to work without modification:

float depth = texture(depth_tex, SCREEN_UV).r;
vec3 ndc = vec3(SCREEN_UV * 2.0 - 1.0, depth);
vec4 view = INV_PROJECTION_MATRIX * vec4(ndc, 1.0);
view.xyz /= view.w;
float linear_depth = -view.z;
if (view < VERTEX.z) {
    ...
}

As long as you are using the INV_PROJECTION_MATRIX to convert the depth into view space, no modifications are necessary. If you are working in clip space directly, you will need to reverse the sign of depth comparisons manually. For example take the following code:

float depth = texture(depth_tex, SCREEN_UV).r;
vec4 clip = PROJECTION_MATRIX * vec4(VERTEX, 1.0);
clip.xyz /= clip.w;
if (depth < clip.z) {
    ...
}

To maintain compatibility, you will have to change the comparison from depth < clip.z to depth > clip.z. The same is true for any code that is directly working with a depth value, or a clip space value returned by using PROJECTION_MATRIX.
Overall, we regret to break compatibility in this way, but we felt strongly that the tradeoff was worthwhile and the alternative was to wait until Godot 5 which will be many years away.


Add Rafay Systems as Package Distribution Maintainer and Kubeflow Support Provider

I have added Rafay Systems as a maintainer for Package Distribution and as a support provider for Kubeflow.

Hi @alfsuse and @knkski, we at Rafay Systems have made minor markdown edits to list ourselves as a provider of support and a packaged distribution of Kubeflow. There are no technical changes involved, just informational updates. Could you please review and, if all looks good, add /approve and /ok-to-test to help move this PR forward? Thank you!

/test

/test kubeflow-website-link-check


DBZ-5628 Add documentation for pre-image support

doc for: https://github.com/debezium/debezium/pull/3894
cc: @jpechane

@xinbinhuang Applied, thanks!


Incorrect variable bindings with subqueries

(Migrated from https://openrdf.atlassian.net/browse/SES-2099)
Hi,
For performance reasons I need to linearise the results of dependent queries. So I want to merge the queries into one using nested graph patterns. Since I don't want to display duplicated results for each subquery, I need to assign a unique identifier to each subset of result variables by using subqueries.
It seems however that those identifiers are improperly assigned during the join evaluation.
The main query is :
{code}
SELECT ?org ?orgName WHERE {
?org rdf:type foaf:Organization .
?org rdfs:label ?orgName .
}
ORDER BY ASC(STR(?orgName))
LIMIT 1
{code}
Subsequent queries are joined by matching variables and should be optional (we may not have corresponding data in the repository)
{code}
SELECT ?org ?interest WHERE {
?org foaf:interest/rdfs:label ?interest .
}
{code}
{code}
SELECT ?org ?address ?zip ?locality ?country WHERE {
?org test:address ?address .
?address test:postalCode ?zip .
?address test:locality ?locality .
?address test:country ?country .
}
{code}
{code}
SELECT ?address ?addressLine WHERE {
?address test:streetAddress/rdf:rest*/rdf:first ?addressLine .
}
{code}
See attachments for sample data and examples.

Looks like the same as #78


Fix lint error for missing copyright headers. [phab:D683]

Created by fromberger at 2016-02-01 17:30:58:
arc lint gets cranky if the error diagnostic generated by the lint
script does not include a line number, which has hitherto been the case
for our missing-copyright check.
Notwithstanding that a missing line does not have a line number, this
change addresses the issue by assigning blame to line 1.

zarko wrote at 2016-02-01 17:40:42:
Maybe do the same thing for the two case-insensitivity errors below?

zarko accepted this revision at 2016-02-01 17:40:42

fromberger wrote at 2016-02-01 17:48:02:

Do the same for case-sensitivity warnings.

fromberger closed via commit abcd0e6b3a15dd11a8b39967e618531387fe9c12 at 2016-02-01 17:48:39


Add ErrorStack to BsonDecoderError

This allows us to provide better help on errors, by providing a
"Stack" that directly points to the error. For example:
ErrorStack(List(Attr("bar"), Attr("baz"), Index(2), Case("Qux"), Attr("answer")))

says that we looked into the case class attribute bar.baz, at index 2, the sealed trait case Qux, the case class attribute answer and that's where the error occurred.
Thoughts?
Implementation Notes

I made the ErrorStack attribute default to ErrorStack.empty in order to not break any existing code (hopefully).
I sealed the BsonDecodeError in order to be able to push ErrorStackFrames on it, this would also be potentially breaking if somebody inherits from it

Added unit tests for the BsonDecoders that have a leftMap call, because I saw that I missed the Option case


Convert Service virtual_has_one :picture to a real has_one

From #9373

@kbrock makes a great point RE: removing the picture method and changing the virtual_has_one :picture, :uses=> :service_template to has_one :picture, :through => :service_template. It seems like a win-win. Let's use rails since it appears we don't really need a virtual has_one... We'll review this in a future PR, maybe it's obvious but there could something we're missing.

Let's figure out if we can just replace the virtual_has_one uses with a has_one through since it seems to be simpler with no change in behavior (I think).

/cc @NickLaMuro including you


Immutable assets

I see a problem that
            if (isDummyObjectForCacheAliasing)
                return;

is used an an "early out" on all convertToDummyObject
Now because the call is recursive (goes through children) and whether a child is converted depends on its mutability state... this means that just because it was called before on an asset, won't guarantee that a second call is not going to produce side-effects.
This logic was broken even before mutability concerns, when we first introduced the recursion depth parameter.

I see a problem that
            if (isDummyObjectForCacheAliasing)
                return;

is used an an "early out" on all convertToDummyObject
Now because the call is recursive (goes through children) and whether a child is converted depends on its mutability state... this means that just because it was called before on an asset, won't guarantee that a second call is not going to produce side-effects.
This logic was broken even before mutability concerns, when we first introduced the recursion depth parameter.

this if doesn't concern mutability at all. However I see your point.. for example at first I call converttodummy(0) and after that converttodummy (2). And levels 1 and 2 won't be converted then

TODO:

[ ] Comments
[ ] non-const getters on non-mutable assets to return nullptr etc.
[ ] const_cast in CPU2GPU converter (so that const getters can be used)

All done


It is too difficult to download the dataset

Hi, thank you for your novel research work.
Is it convenient to put the data set on Baidu Cloud Disk? too difficult to download the dataset for me as I failed to download the dataset several times.

Hi @liushu309 Thank you for your interest in our work! Currently, we only host our datasets on Google Drive, and we do not plan to host on Baidu Pan. Sorry for the inconvenience caused.


server can not get EOS

when i run this :python kaldigstserver/client.py -r 8192 test/data/bill_gates-TED.mp3
I have get:
Audio sent, now sending EOS
Received error from server (status 1)
who can tell me why and what should i do ?

I have the same error. Have you solve it?


Idle detection notification scaling issue on a Surface Book 2 Windows

Case 718426

Due to display peculiarities, when I unlock my Surface Book 2, a lot of things on the screen change size. With Toggle, this causes a problem because when the idle time detection dialog displays, sometimes it gets sized so small that only the title bar is visible, and I can't interact with it or resize it. Could you verify whether that dialog has a minimum size set? If not, could you set one? If it already has one, then it may take more investigation to figure out why it shrinks to title-bar size. It might also be helpful to make that dialog resizable, so that at least if it shrinks too small to work with, I can manually resize it.

#3009 same issue


Frappe Chart Not Rendering immediately

Expected Behaviour
Frappe chart renders immediately and automatically without further intervention upon loading the page.
Actual Behaviour
Container is loaded, but graph is not rendered. Some items like pop up elements of the graph are rendered, but the underlying graph is not visible. Once user resizes the window, the graph renders completely and functions normally.
Steps to Reproduce:
*Enter the URL of the page or doctype containing a frappe chart
*Press ENTER

Wait for the items to finish loading.  Result will be evident.

Code used in .js page:
NOTE: Add a GIF/Screenshot if required.

Frappé Charts version:
v1.0.0 or more?

I’ve found a workaround and that is to add a draw in a timeout under where you create the chart as follows:
// existing code
const chart = new frappeChart.Chart(dedicated_div, options)
// add
setTimeout(function () {chart.draw(!0)}, 1);

https://discuss.erpnext.com/t/frappe-chart-in-erpnext-on-new-page/32544/10


Just WOW!

This is such a cool program!
It reminds me a little of WinSpy++

I'm having fun watching it simply draw boxes on the windows.  It's fascinating to watch.
I've got a very large monitor and keep a large number of PySimpleGUI programming running so I made your sizes larger and made the window resizable:

Here's how your program analyzed one of my weather desktop widgets:

Thank you for posting a screenshot in your readme.  It grabbed my attention.

ShareX makes GIFs that are small enough to fit into a readme if you're interested in maybe embedding a GIF into your readme.  I saw your MP4, but I was unable to convert it into a GIF.  This one I made on my system and it's only 156K.

Thank you so much for comments @PySimpleGUI
You work are awesome, with PySimpleGUI I was able to delivery this little project to my team in less than one week.
You made my job very, very easy since draw UI using Python until today is a little bit complex.
More features in SpyTool will come soon.
Thanks for the GIF animation, I´ll include in readme now..


 Ich kann kein Parameter einstellen.
Gibt es dazu einen Lösungsansatz oder kann ich noch was zu diesem Fehler beitragen? Ist ein zusätzliches Log hilfreich?

zwave-js-ui: 9.10.3
zwave-js: 12.5.4

What can I do now or what needs to be changed?

@kilian-f-za Wait for @AlCalzone to update the device configuration to disable supervision on that device as it doens't support it correctly

You can look up how we disabled supervision on other problematic devices and use a custom config file with the same applied.
Otherwise you'll have to wait for me to fix it on Monday, and then new releases of node-zwave-js and zwave-js-ui.

@kilian-f-za it looks like for parameter 150 we have an incorrect value size (1 byte instead of 2) in our config file. Parameters 13, 20, 152 and 153 should be correct.
Can you try setting them please? And please make a driver log of that.

Yes, I can set the parameters 13, 20, 152 and 153. However, parameter 13 does not change the brightness on the device. When I press the current button, the switch lights up green.
It's Node 023
zwavejs_2024-04-22.log

Ok those look good, so it's not the Supervision CC, but our incorrect config file. We can't do anything about the config parameters not behaving as they should though.
Side note: You don't have to remove and include the device to make a log, unless I ask you to :)

What can I do now? So I can't set the parameters?

I'm fixing our config file, so you can set 150 and 151 as expected.
Setting the others appears to be working according to your log.
But if parameter 13 doesn't change the brightness even if the manual says so, that's nothing we can fix.

When is the new release expected to be published?
I currently still have the right to return the Switch. 😄

Likely today, then Z-Wave JS UI will have to follow up with a release. And if you're using the Home Assistant addon, that will also need one.
If you can't wait, you can also test the file in advance. See https://zwave-js.github.io/zwave-js-ui/#/device-support/custom-device-files for an explanation how. Save this as a .json file and put it into the folder mentioned in the documentation.
Don't forget to remove the custom file again after updating Z-Wave JS UI, otherwise you won't get any future fixes to that file.


Error when adding migration using Entity Framework Core

It has following error:
Method 'Create' in type 'Microsoft.EntityFrameworkCore.SqlServer.Query.Internal.SqlServerSqlTranslatingExpressionVisitorFactory' from assembly 'Microsoft.EntityFrameworkCore.SqlServer, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=adb9793829ddae60' does not have an implementation.
Turned out we need install following two as well
 PM> Install-Package Microsoft.EntityFrameworkCore.SqlServer
 PM> Install-Package Microsoft.EntityFrameworkCore.Tools

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

ID: 1d975a83-1550-b284-d0d8-7fe2ea206ff5
Version Independent ID: 48e81b42-7c2b-afbf-71e6-d4f442a4bd1f
Content: Part 4, add a model to an ASP.NET Core MVC app
Content Source: aspnetcore/tutorials/first-mvc-app/adding-model.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Those are listed.


Rancher CLI: No configuration found after successful login

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
Download Rancher CLI for Linux from the Rancher Web UI.
Unpack the archive, make the rancher binary executable and run the login:
chris akira ~/rancher-v2.2.0 13:19:00 8f929dbd master
❯ ./rancher l https://rancher1.URL.TLD -t XXXX
chris akira ~/rancher-v2.2.0 13:19:02 8f929dbd master
❯ echo $?
0
chris akira ~/rancher-v2.2.0 13:19:04 8f929dbd master
❯ ./rancher nodes
FATA[0000] no configuration found, run 'login'

Result:
No configuration is generated after successful login
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v2.2.2
Installation option (single install/HA): Multi-Node Cluster in VMWare

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Self Hosted
Machine type (cloud/VM/metal) and specifications (CPU/memory): VMs
Kubernetes version (use kubectl version): kubectl inside of rancher cli

I solved the problem by my self.. the reason were missing write permissions in my home directory.
It would be nice if rancher would be more verbose and output a "File permission" error and exit exit code 1

Available in v2.3.0-rc3

reproduced the issue in v2.2.0
Steps:

docker run --net=host -ti -w /tmp --user 1000:1000 centos bash
curl -L https://github.com/rancher/cli/releases/download/v2.2.0/rancher-linux-amd64-v2.2.0.tar.gz | tar xvzf - 2>/dev/null
./rancher-v2.2.0/rancher login -t token-xxxxx:xxxxxxxxxxxxxxxxxxxxxx https://
type yes to confirm cacerts if self signed
./rancher-v2.2.0/rancher projects
Error FATA[0000] no configuration found, run login  is seen

Validated the fix in v2.3.0-rc3

docker run --net=host -ti -w /tmp --user 1000:1000 centos bash
curl -L https://github.com/rancher/cli/releases/download/v2.2.0/rancher-linux-amd64-v2.2.0.tar.gz | tar xvzf - 2>/dev/null
./rancher-v2.2.0/rancher login -t token-xxxxx:xxxxxxxxxxxxxxxxxxxxxx https://
type yes to confirm cacerts if self signed
Error - FATA[0002] mkdir /.rancher: permission denied   is seen.


SLEEP: mutliple sequences with the same id

I think the SLEEP spec needs some clarification around what to do in the case of multiple sequences with the same id.
The spec makes reference to them being unique but in the case of CouchDB's _changes?feed=continuous that is actually not the case, as the database is updated later sequences will appear with the same id's as previous sequences as those documents are updated.
This is particularly important to me as mikeal/couchup keeps prior sequences around until compaction. The sparse sequence CouchDB maintains on write is really just an optimization.

WONTFIX (?) - closing due to inactivity.


Help for link indicates you can specify projectId

Just updates the help text for link

Thanks :D!

You are most welcome.
I forked the original project, used the "Deploy on Railway" button for code-server to get an IDE running against the fork (Tip: use the https clone link). I made the code change, installed a go tool chain to build and test in the terminal, then used the code-server GitHub integration to commit/push the fix back to the fork. Then one click in GitHub to create the PR. No localhosts harmed in the making of this PR ;)


check for status.services, im service status

Issue 58155 has found that ODLM may not instantiate status.services on first pass through for reconciling an operandrequest. This pr adds a check to see if status.service exists and to see if im is ready. If either of these checks fails, the operandrequest is requeued.
I have been testing the changes with a 4.0 deployment and so far so good. I'm going to try cleaning it up before merging as it's a little ugly compared to the other checks here.
Testing:

install bedrock 4.0, just cs operator and odlm
replace odlm image with this one (can build with makefile or ask me and I'll send you an image)
create operand request with just im
watch im operand request, make sure it is eventually (in a relatively short time frame) updated to include status.services
watch odlm logs to see if it's behaving as expected
im opreq will create ibm-iam-request that has common ui and mongo, watch to make sure this opreq eventually has its status.service as well. It should not have the "waiting on im" log message in odlm

To rerun, you can delete the operandrequests, wait for everything to uninstall, then re-create the im operandrequest
Note: DO NOT restart the odlm operator after applying the operand request. It is a workaround in making sure the operand requests are reconciled to include status.service and could muddy the results of the test.

The updates looks good to me. Let's go ahead merge it and unblock the issue.
On the other hand, I think we are trying to avoid hardcoded services in the code.
monitoredServices := []string{"ibm-iam-operator", "ibm-idp-config-ui-operator", "ibm-mongodb-operator", "ibm-im-operator"}

I have some new ideas, and I will open a new issue to have a team brainstorm on that.

introduce some annotations in OperandConfig to mark monitored services - with backward compatibility
introduce new spec parameter in OperandConfig to mark monitored services - without backward compatibility


Register evaluation data writer

Register the evaluation data writer with config utils factoryRos
so that it can be configured from a YAML file.

@Schmluk not sure if this is already fixed in another branch - if so, feel free to close the PR :)

LGTM, good that you saw these and good fixes!


renderAndGetWindow requires a full URL, whereas renderRoute only requires the path

Would it be possible to change renderAndGetWindow to also accept a path, instead of an absolute URL?
It kinda makes parallel testing with Ava a bit more difficult, because you spin up multiple Nuxt instances on different ports. You have to keep track of the Nuxt instance port in each renderAndGetWindow call.

This question is available on Nuxt.js community (#c2482)

#3151 would actually fix this.

@polyglotm @Atinux Am I correct in stating that #3151 is the correct "workaround" for my issue?


Problem with language of jquery.timeago

Hi, we have an app with Yii::$app->language set as "it-IT".
The problem is that the file "jquery.timeago.it.js" is not read because the extension search for "jquery.timeago.it-IT.js".
It is possible to fix the problem?

This have nothing to do with yii2-notifications.
(juste change Yii::$app->language to "it" or fix your code calling the javascript)

The code that call the javascript is in your extension, so I can fix it until next update...
in NotificatiosWidget, register Assets()
if ($filename = NotificationsAsset::getTimeAgoI18n($this->timeAgoLocale)) {
            $view->registerJsFile($asset->baseUrl . '/' . $filename, [
                'depends' => NotificationsAsset::className()
            ]);
        }

and $this->timeAgoLocale is set in the run()
 if (!isset($this->timeAgoLocale)) {
            $this->timeAgoLocale = Yii::$app->language;
        }

Ewww, so sorry for this falsy comment on my side. I'll be fixing that in a few minutes.

Should be fine now, update to last version and try again.
Thank you for reporting this issue.

The language is now loaded correctly.
Thanks


[BUG] Sidebar not scrolling upto bottom in mobile devices

Description
I'm not able see other category because it's not scrolling upto bottom in my phone
Screenshots

Any additional information?
No response
What browser are you seeing the problem on?
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[ ] I am willing to work on this issue (optional)
[ ] I am participating in Hacktoberfest 2023

/attempt #2069
I will try fixing this.

@Anmol-Baranwal Can You assign me this issue.

@Killer2OP
I have assigned you the issue. Please proceed with it, and don't hesitate to tag me @Anmol-Baranwal or @CBID2 if you require any assistance.

@KriteshTimsina
Why did you raise a PR without being assigned? Did you read contributing guidelines.

I'm sorry I didn't notice. You can reject if it goes against the guidelines

@Anmol-Baranwal Hey , Can I start the working on this issue now?

Sure. I never stopped you from working on this. If you're assigned, you can work.😄

@Anmol-Baranwal Hey , Can I start the working on this issue now?

Sure. I never stopped you from working on this. If you're assigned, you can work.😄

I thought there is no ready tag , that's why😅

I thought there is no ready tag , that's why😅

That is just a formality, the main thing is getting assigned. Forgot to add the label. LOL!🤣


question

Hi,
I am a node red newbie, this module seems interesting.
This may sound like a real odd question, could I ever use this as a "fault detection diagnostics checker?"
For example I work in the HVAC industry where I collect a lot sensor data and people create fault detection diagnostics if a sensor on the heating/cooling system for large buildings/hospitals is reading erroneous values. Sometimes the sensor value can be related to a mechanical issue (like broken valve in a piping system is leaking hot or cold water) or the electronics has an issue.
A classic one is buildings control a lot of HVAC based on locally installed outside air temperature sensor reading, and sometimes they install the sensor where it is hit by sunlight and that causes a whole mess of issues when HVAC starts going into a summer mode but it is actually winter time. Could this node red module ever be used to detect a sensor going out of range of acceptable values, and then documenting over time on a chart how often this error happens?
Thanks for anytime in response!
Ben

Hi,
Thank you for using "node-red-contrib-ui-timelines-chart".
Please excuse my poor English.

This may sound like a really odd question, could I ever use this as a "fault detection diagnostics checker?"
Yes. I think it is possible.

I'm using this Node-RED module as a "fault detection diagnostic checker" for factory machines. This may be the same as you think.
Please note that this Node-Red module can visualize the status of many devices, but you can not calculate or save data. Also, need a database to compare past data.
Sensor values are required to replace values from the range of the tolerance range (e.g. State-normal: 39 or less Degree, State-Warn: 40-69Degree, State-Err: 70 or more degree) Become.
I hope that answers your question.
sanlike0911

Thank you!


Create and publish npm package

When its ready.

note about original package json files config
"files": [
"dist/lib",
"dist/esm",
"dist/umd"
],

Workflow done and tested but library is not ready at this point. This still can be closed.


I cannot read a specific dwg file in c#

Hello ACadSharp Team,
I’m currently experiencing an issue while trying to read a file in C# using your library. The error message I receive is as follows:
System.ArgumentOutOfRangeException: TimeSpan overflowed because the duration is too long.
at ACadSharp.IO.DWG.DwgStreamReaderBase.ReadTimeSpan()
at ACadSharp.IO.DWG.DwgHeaderReader.Read(Int32 acadMaintenanceVersion, DwgHeaderHandlesCollection& objectPointers)
at ACadSharp.IO.DwgReader.ReadHeader()
at ACadSharp.IO.DwgReader.Read()
at ACadSharp.IO.DwgReader.Read(String filename, DwgReaderConfiguration configuration, NotificationEventHandler notification)

The file looks like this:

I kindly request your assistance in resolving this issue.
Thank you.

Hi @ebadmail,
can you provide the file or an equivalent of it to be able to reproduce the error?

Hi @DomCR,
Thank you for your response. I'm unable to share the file directly as I'm not the owner. However, I attempted to troubleshoot the problem by modifying the code in DwgStreamReaderBase.cs:
public TimeSpan ReadTimeSpan()
{
    long hours = this.ReadBitLong();
    long milliseconds = this.ReadBitLong();
...
}

The output I obtained was:
hours = 313330304;
milliseconds = 5246039;
To further investigate, I created a new file using the same entities, which worked successfully.
Please let me know if there's any additional information I can provide.
Thank you.

It seems that the error is in the TimeSpan conversion, but I don't feel comfortable adding a try catch or an implementation without a way to test it and make sure that does not have any other repercussion.

Here are the files:
Files.zip
My workaround:
public TimeSpan ReadTimeSpan()
{
	long hours = this.ReadBitLong();
	long milliseconds = this.ReadBitLong();

	// Handle potential overflow
	if (hours < 0 || hours > TimeSpan.MaxValue.TotalHours || milliseconds < 0 || milliseconds > TimeSpan.MaxValue.TotalMilliseconds)
	{
		return TimeSpan.FromHours(0) + TimeSpan.FromMilliseconds(0);

	}

	return TimeSpan.FromHours(hours) + TimeSpan.FromMilliseconds(milliseconds);
}

Some articles about this issue:
https://forums.autodesk.com/t5/autocad-forum/negative-editing-time-in-document-properties/td-p/4849303
https://help.autodesk.com/view/ACD/2018/ENU/?guid=GUID-990C8D36-CD20-48C0-A711-4F03B33C084C
https://www.cadtutor.net/forum/topic/50762-negative-total-editing-time/
https://office-watch.com/2023/dont-trust-total-editing-time-in-word/

I've tested your solution, works fine, thanks for the docs also.
Thanks, great job!


Fix the CRUD for Geolocation and connect the relationship between the…

… User and Geolocation. Also fix the Geolocation related functions for the frontend homepage,signup, and userprofile.

Palihog ko i delete inyong existing database kay ako gi usab ang CRUD sa Geolocation, I'm sure ma guba na ig run ninyo sa springboot


Since kill is gone ( except in MRI ) shutdowns raise NoMethodError

https://travis-ci.org/celluloid/celluloid/jobs/59063051#L690
NoMethodError: undefined method `kill' for Celluloid::Actor:Class
           shutdown at /home/travis/build/celluloid/celluloid/lib/celluloid/actor_system.rb:99
               each at org/jruby/RubyArray.java:1613
           shutdown at /home/travis/build/celluloid/celluloid/lib/celluloid/actor_system.rb:97
           shutdown at /home/travis/build/celluloid/celluloid/lib/celluloid.rb:168
  register_shutdown at /home/travis/build/celluloid/celluloid/lib/celluloid.rb:160

I didn't get to finish this (default Reaper).
Basically, on JRuby and Rubinius there shouldn't be anything where the kill() is - if terminate didn't work, shutting down the group is the only option (anything else requires complex logic to detect whether the actor is being finalized, if it's running, if it can be queued for joining later, etc).
The join code OTOH should be something like this (in JRuby/Rubinius):
Timeout.timeout(timeout) do
  begin
    Actor.join(actor) # optionally with a timeout parameter
  rescue => ex
    Celluloid::Logger.warn("Actor failed to terminate cleanly: #{ex}")
  end
end

(You want to give each actor time to finish - you don't want the first one stuck to prevent the others from terminating+finalizing without being given a chance to show failures, etc.). The timeout isn't honored (worst case for e.g. 15 actors it will be 15 x timeout), but generally other actors will finish terminating while one is waiting for the timeout.


Add RPI Camera Module 3 to the kirkstone branch

Is there a way to add support of RPI Camera Module 3 to the kirkstone branch?
It requires installing overlay imx708

duplicate

That would require a backporting investigation of that in kirkstone. Have you checked the kirkstone kernel version provided by the layer?

duplicate

I'm not sure what this means. Could you explain?

There is this MR: https://github.com/agherzan/meta-raspberrypi/pull/1197


Add RegNet Architecture in TorchVision

Resolves #2655

Publish to gather early feedback.
cc @fmassa @datumbox

High level comment for the group - do we want to support the following -
* [Fast and Accurate Model Scaling](https://arxiv.org/abs/2103.06877) proposes a way to scale models. Once a model is scaled, it cannot be defined by `w_a`, `w_m`, etc. anymore and instead needs to be specified by the stage widths, group widths, etc. which means the `RegNetParams` API does not suffice. We already have models like these being trained currently with multiple downstream applications (happy to share details internally). In Classy Vision we had an `AnyNetParams` API for this (https://github.com/facebookresearch/ClassyVision/blob/b9ea86b39cc469867aabb76ada33bf5a8530eb19/classy_vision/models/anynet.py#L364), which `RegNetParams` derived from.

* The [Designing Network Design Spaces](https://arxiv.org/abs/2003.13678) paper specified AnyNets as fairly general networks and `RegNetX`, `RegNetY`, `RegNetZ` are instantiations of these. Which is why we have multiple block types - a user can specify very general networks with these settings.

We could support both scaled and regular regnet model if we init the RegNetParams with lists of params and have a class method to compute list of params.
Regarding to various block type,  I'm leaning towards no including unused block types. From engineering point of view, if a component is not actively used within the code base, it is likely to be ignored in regular maintenance and eventually abandoned. Additionally, it's much easier to add a component than deleting it in a BC manner.

We could support both scaled and regular regnet model if we init the RegNetParams with lists of params and have a class method to compute list of params.

Regarding to various block type, I'm leaning towards no including unused block types. From engineering point of view, if a component is not actively used within the code base, it is likely to be ignored in regular maintenance and eventually abandoned. Additionally, it's much easier to add a component than deleting it in a BC manner.

Agree on both ascounts! Thanks Kai!

@kazhang I did a final check and the PR looks good to go for me. We can follow up for the nits and todos on another PR.
Two quick questions:

Your implementation contains classes such as SimpleStemIN, BottleneckTransform etc which I understand are not declared on the __all__ variable. This is a very common pattern in TorchVision BTW. I assume that you consider these classes not part of the public API but still made it not fully private (by prepending an _) because other developers might be interested in using them. Can you confirm this is the case?
Have you validated all deployed pre-trained weights by running the references script with the --test-only --pretrained arguments? This is a final step we usually do just prior merging to confirm the accuracies reported on docs are accurate and that we are good to go. See the bottom of the description of PR https://github.com/pytorch/vision/pull/3182 for an example.

@datumbox yes, SimpleStemIN, BottleneckTransform are common building blocks in RegNet, other developers might want to use them when exploring other variants of RegNet.

I've tested the pretrained model on ImageNet:

model
Acc@1
Paper Acc@1
Acc@5
command

regnet_y_400mf
74.024
74.1
91.68
srun -p $TRAIN_QUEUE --cpus-per-task=96 --gpus-per-node=8 python -m torch.distributed.launch --nproc_per_node=8 --use_env train.py --model regnet_y_400mf --batch-size 128 --test-only --pretrained

regnet_y_800mf
76.42
76.3
93.136
srun -p $TRAIN_QUEUE --cpus-per-task=96 --gpus-per-node=8 python -m torch.distributed.launch --nproc_per_node=8 --use_env train.py --model regnet_y_800mf --batch-size 128 --test-only --pretrained

regnet_y_8gf
79.966
79.9
95.1
srun -p $TRAIN_QUEUE --cpus-per-task=96 --gpus-per-node=8 python -m torch.distributed.launch --nproc_per_node=8 --use_env train.py --model regnet_y_8gf --batch-size 64 --test-only --pretrained

regnet_x_400mf
72.83
72.7
90.95
srun -p $TRAIN_QUEUE --cpus-per-task=96 --gpus-per-node=8 python -m torch.distributed.launch --nproc_per_node=8 --use_env train.py --model regnet_x_400mf --batch-size 128 --test-only --pretrained

regnet_x_800mf
75.19
75.2
92.418
srun -p $TRAIN_QUEUE --cpus-per-task=96 --gpus-per-node=8 python -m torch.distributed.launch --nproc_per_node=8 --use_env train.py --model regnet_x_800mf --batch-size 128 --test-only --pretrained

regnet_x_8gf
79.324
79.3
94.694
srun -p $TRAIN_QUEUE --cpus-per-task=96 --gpus-per-node=8 python -m torch.distributed.launch --nproc_per_node=8 --use_env train.py --model regnet_y_8gf --batch-size 64 --test-only --pretrained


Suggestion! Different Theme Options for Editor/Gallery

i.e. first sprig page background as background for editor

@leomcelroy Should we accept this as a feature request?

I think we'll stick to one theme for the editor.


AddPageRoute doesn't remove Index when it should

I use the following code to change the default page:
            services.AddMvc().AddRazorPagesOptions(options =>             {                 options.Conventions.AddPageRoute("/Transactions/Index", "");             });
But receive an error:
An unhandled exception occurred while processing the request.
AmbiguousActionException: Multiple actions matched. The following actions matched route data and had all constraints satisfied:
Page: /Index
Page: /Transactions/Index
Microsoft.AspNetCore.Mvc.Internal.ActionSelector.SelectBestCandidate(RouteContext context, IReadOnlyList candidates)
The workaround is to rename Index.cshtml, but could you fix this issue?

There are two pages in your application with the same route. AddPageRoute will not affect routes in the application (this could include other controller actions if you're mixing controllers and Razor Pages). The user's responsible for configuring the application the right way.

So what's the right method to change the default page?


Simple aInB for polygons

I don't know if I went about this in the right way, but I might've :)
Uses AABB for aInB for polygons. Polygon aInB used to always return true, so this is "better than nothing." It does have it's flaws (specifically for concave polygons) but gets the job done.
This just treats both elements as boxes:

Something I did just consider is that we should probably check !a.isConvex and !b.isConvex so we don't override convex Polygon on Circle aInB. However, I don't think Polygon on Polygon has an aInB.


New discussion forum? Convore being shutdown

I tried to post and search for a question on convore, but the site is crapping out at both requests. It looks like Convore is being shut down on April 1 too. Will there, or is there already a new home for django-social-auth discussions?
-Kim

Join the discussion group at https://groups.google.com/group/django-social-auth


Fix PyPi credentials

Signed-off-by: Sayali Gaikawad<EMAIL_ADDRESS>Description
Fix PyPi credentials and tests
Issues Resolved
List any issues this PR will resolve, e.g. Closes [...].
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #38 (b992815) into main (75b24ef) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head b992815 differs from pull request most recent head b848f42. Consider uploading reports for the commit b848f42 to get more accurate results

@@            Coverage Diff            @@
##               main      #38   +/-   ##
=========================================
  Coverage     83.95%   83.95%
  Complexity       24       24
=========================================
  Files            64       64
  Lines           187      187
  Branches         10       10
=========================================
  Hits            157      157
  Misses           24       24
  Partials          6        6

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Username as "azure" is not working for windows Vm.

Username as "azure" is not working for windows Vm. Is there any recent change which impact this as I am not able to see it under The following usernames are not allowed section https://docs.microsoft.com/en-us/azure/virtual-machines/windows/faq#what-are-the-username-requirements-when-creating-a-vm
Edited: doc info

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

ID: e14cfdc3-89e0-a2cf-39e6-b733e59b4784
Version Independent ID: 4c30cc9b-fa80-b174-8cdb-c615286cdcc5
Content: FAQ about Windows VMs in Azure
Content Source: articles/virtual-machines/windows/faq.md
Service: virtual-machines-windows
GitHub Login: @cynthn
Microsoft Alias: cynthn

@NAshwini, Thanks for the question! That's a good catch! We are taking a look into this and will get back to you soon.

@NAshwini  and @Karishma-Tiwari-MSFT - I remember there being issues with usernames that were only 5 characters, but I thought it was an SSH limitation (not RDP\Windows).
I just tried a quick test with the portal, and "azure" as a username didn't get flagged.
How were you creating the VM?
Thanks!

@cynthn I have tried it with windows 2012 R2 and 2019 from azure portal. While creation of user creds I created username as "azure" with password (met all criteria) and not with ssh_key. choose all the post SSH, RDP, HTTP, HTTPS) and the rest was default. The same pattern of vm creation was working earlier. The problem seems to be very recent.

@NAshwini Can you please share specifically which VM are you using. For example, I tried with Windows Server 2019 Datacenter with 'Azure' as username, it worked for me.

@NAshwini Can you please share if there is any update? Did you try again and still seeing issues? Let me know. I can try with the specific VMs you are trying with.

@Karishma-Tiwari-MSFT Sorry for late response was busy... I tried the same process now with azure as a username and was able to RDP it. Hence closing this issue.
Just for info is there any recent changes made to fix it ?


[Bug]: Getting blank map screen on IOS v10

Mapbox Implementation
Mapbox
Mapbox Version
mapbox
Platform
iOS
@rnmapbox/maps version
10.15.0
Standalone component to reproduce

Observed behavior and steps to reproduce
After installation @rnmapbox/maps getting white screen instead of maps with this error [Mapbox] [Error, maps-ios/MapView]: No suitable Metal simulator can be found.
Expected behavior
No response
Notes / preliminary analysis
No response
Additional links and references
No response

Same issue here, I've looked at the source code and the component doenst seem to do anything with the styleUrl prop

Do you find any solution ?

The props get passed directly to a native component so I've no idea

@danialseikh34 did you set up an access token with DOWNLOADS:READ scope?

yes

@danialseikh34 did you set it in the app.config plugins and use mapbox for RNMapboxMapsImpl?
      [
        '@rnmapbox/maps',
        {
          RNMapboxMapsImpl: 'mapbox',
          RNMapboxMapsDownloadToken: process.env.MAPBOX_SECRET_SCOPE_TOKEN
        }
      ]

yes


[Feature] Add panoptic segmentation loading.

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Add panoptic loading in LoadAnnotations3D for semanticKITTI and nuScenes.
Modification
Add _load_panoptic_seg_3d in LoadAnnotations3D. It simply loads panoptic labels from panoptic paths. The labels of segmentation datasets like semanticKITTI and nuScenes need further processing to get semantic labels and instance labels.
BC-breaking (Optional)
Does the modification introduce changes that break the back-compatibility of the downstream repos?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.
Checklist

Pre-commit or other linting tools are used to fix the potential lint issues.
The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
If the modification has potential influence on downstream projects, this PR should be tested with downstream projects.
The documentation has been modified accordingly, like docstring or example tutorials.

It seems that we need to load panoptic_annotation with seg_3d and mask_3d. We should follow the implementation in MMDetection,

It seems that we need to load panoptic_annotation with seg_3d and mask_3d. We should follow the implementation in MMDetection.

In datasets like semanticKITTI and nuScenes, both semantic labels and instance labels are in the same file, so I want to load them together in one function. For example, labels of semanticKITTI are constructed in the form of (instance ids<<16)+semantic labels.
And there are some questions. When only loading semantic labels, we need to filter out the instance part and do some mapping. When loading panoptic labels, we need to split the labels into semantic and instance parts. I plan to do it in the LoadAnnotations3D function with a new arg offset. What do you think of it?

It seems that we need to load panoptic_annotation with seg_3d and mask_3d. We should follow the implementation in MMDetection.

In datasets like semanticKITTI and nuScenes, both semantic labels and instance labels are in the same file, so I want to load them together in one function. For example, labels of semanticKITTI are constructed in the form of (instance ids<<16)+semantic labels. And there are some questions. When only loading semantic labels, we need to filter out the instance part and do some mapping. When loading panoptic labels, we need to split the labels into semantic and instance parts. I plan to do it in the LoadAnnotations3D function with a new arg offset. What do you think of it?

From my perspective, we need to split the original annotation label into semantic_mask and instance_mask as other datasets do for more common usage such as semantic segmentation task. Of course, more suitable method is also welcomed.

It seems that we need to load panoptic_annotation with seg_3d and mask_3d. We should follow the implementation in MMDetection.

In datasets like semanticKITTI and nuScenes, both semantic labels and instance labels are in the same file, so I want to load them together in one function. For example, labels of semanticKITTI are constructed in the form of (instance ids<<16)+semantic labels. And there are some questions. When only loading semantic labels, we need to filter out the instance part and do some mapping. When loading panoptic labels, we need to split the labels into semantic and instance parts. I plan to do it in the LoadAnnotations3D function with a new arg offset. What do you think of it?

From my perspective, we need to split the original annotation label into semantic_mask and instance_mask as other datasets do for more common usage such as semantic segmentation task. Of course, more suitable method is also welcomed.

Do you mean split labels with some preprocess? I think maybe it is not a good idea because it will occupy extra memory and therefore not friendly for user. Maybe I can implement one version and see if it suits.

Please merge the latest dev-1.x and resolve the conflicts.


Could Not Find Module

hackq_trivia> python3 -m hackq_trivia.hq_main
C:\Users\Yuzz\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\python.exe: Error while finding module specification for 'hackq_trivia.hq_main' (ModuleNotFoundError: No module named 'hackq_trivia')
C:\Users\Yuzz\Desktop\New folder\HackQ-Trivia\hackq_trivia>

Now I cannot import any of the modules I have installed.

I believe you should be in the HackQ-Trivia folder, not the hackq_trivia folder.

Assuming resolved.


commit test cases expected to change on go minor version release in g…

…o upgrade periodic
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Spell Checker for non-English languages

Despite my initial expectations I've been using Ghost Desktop a lot.

I'd suggest a setting in order to allow the user to choose whether enabling or disabling the spell checker, in case it is not possible to integrate the textatea with System's settings (I use OS X, but I'm aware there is only one codebase for all platforms).
Right now I enable Developer Tools (Current Blog), select the markdown textarea and modify its markup to spellcheck='false' before start writing. Not that hard, but non developers users might not think like me.
(As you can see I don't write in English, Portuguese is my main language.)

Hey, thanks for reporting! I'm sorry that you're having trouble - the system was really supposed to pick up your language and "just use that". Clearly this needs some work.

Oops! My bad!
The system is picking the correct language from OS: I use my devices in English (don't ask).
However, I write content in Portuguese, despite my OS language. :)
Thanks for your prompt response.

Okay, new issue title then: Let's make you and everyone else choose their language in the preferences. Would that work for you? You'd need to have the dictionary installed in your operating system, but we could easily add a little drop-down 👍

Closing in favor of #145


LIIKUNTA-274: Fix collection cards clamp

Description
Add clamp as well to the collection cards
Issues
Closes
DEV-XXX:
Related
Testing
Automated tests
Manual testing
Screenshots
Additional notes

Codecov Report

Merging #131 (3c96081) into main (260ea0d) will decrease coverage by 0.03%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
- Coverage   65.84%   65.81%   -0.04%
==========================================
  Files         130      130
  Lines        2073     2074       +1
  Branches      479      479
==========================================
  Hits         1365     1365
- Misses        701      702       +1
  Partials        7        7

Impacted Files
Coverage Δ

src/common/components/card/CollectionCard.tsx
0.00% <0.00%> (ø)

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 260ea0d...3c96081. Read the comment docs.


⚠ Bofrost.de has degraded performance

In 530fabd, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1432 ms

Resolved: Bofrost.de performance has improved in be7803d after 3 minutes.


Display fund account link on the transaction signing screen

Based on the work to be done for https://github.com/hirosystems/stacks-wallet-web/issues/2251.
We’d like to provide our users to the shortest path so a successful transaction. Currently, the transaction singing insufficient funds state doesn’t provide a direct way to add funds into an account.
Figma
Changelog

Removes “Copy address” button
Removes the “Close window” button
Adds a “Get STX” button that opens the Buy screen in a new tab
Updates button styles and layout

This is great @fbwoolf . Can we track how many users land in the Fund page from this Get STX button? Could we instrument that?


File size display

Display file size properly (in kb,mb, gb...whichever appropriate) instead of just mb.

done


Use tabs in package(-lock).json

This is more consistent with the most of the code base, and npm will preserve the indentation style.

Thank you for the PR @valtlai!
Both of these files are generated and managed by npm. We can't choose the indentation because every npm i <something> will change it back spaces. So it's impractical to maintain tabs.
For this reason, I will reject this PR.

That’s not true: npm does maintain the indentation style, i.e. running npm i <something, for example, won’t change tabs back to spaces. I tested it with both npm v6 and v7.

Oh, I found an old issue where people were angry that it didn't. They must have changed it since then.

Yeah, I’ve probably used npm too little time since I didn’t know this hasn’t always worked like today. 😄

Thank you for contributing @valtlai!


QUIC is not supressed on AG for Android

14:34:40.502 [tcpip-stack-pool-1-thread-89] DEBUG c.a.a.filtering.api.LocalVpnService - UDP id=6 onUdpConnectRequest: protocol=UDP, local=/<IP_ADDRESS>:59344, remote=/<IP_ADDRESS>:443
14:34:40.505 [tcpip-stack-pool-1-thread-89] DEBUG c.a.android.filtering.events.i - Creating new stats for com.android.chrome with id 6 and network type MOBILE

Not passed as "QUIC" in connect request

core/pull-requests/1071

For QA:
Google should be filtered.
Filtering log should not show not blocked entries like udp://x.x.x.x:443 from Chrome

I think this is now generally implemented in the latest ηightly.  Could there also be a corresponding method to generally allow QUIC (i.e., disable this setting, perhaps via an advanced setting)?

@TPS but for what reason? Tbh, I suppose we should add QUIC and HTTP/3 filtering in the future, thus we won't have to suppress it.

Until #487 is implemented (#746 is equivalent to this issue on Mac), a debug method to allow QUIC might help debug behavior, e.g., that I suspect has to do w/ this.


mp3 duration usually wrong on ios

When adding output mp3s to Mac OS "Books" application, the audio duration is correct, but rarely shows the full duration on ios devices (ex 8 hour mp3 will show 3:55 for instance on iPhone). The files continue to play past the duration, but if you skip ahead or back, it resets to whatever it thinks the end is.
Based on https://superuser.com/questions/607703/wrong-audio-duration-with-ffmpeg it looks like adding the option "write_xing 0" to the command pydub calls should fix this.

Resolved with merge of fix-mp3-duration branch


(WIP) docs: improve documentation and description of base_syscalls option

What type of PR is this?
/kind documentation
What this PR does / why we need it:

Improve documentation the base_syscalls option.
Shuffles and re-words a few blurbs to help provide the user with context and actionable items

Which issue(s) this PR fixes:
(no issue ticket filed)
Special notes for your reviewer:
cc @incertum @jasondellaluce for review, thanks for help!
Does this PR introduce a user-facing change?:
No, since this is a net-new feature going into Falco 0.35+

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

1bae490 docs: improve documentation and description of base_syscalls option

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Happy-Dude
Once this PR has been reviewed and has the lgtm label, please assign fededp for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Generally, I moved things around in a format where it flows from

state engine context
default behavior
configuring just custom_set
configuring repair
syntax usage
suggestions

Also, I would like to add a blurb about the -A command line flag, although I'm not fully informed of it's effects in relation to the varied ways base_syscalls can be configured.

Resolved some suggestions, typos, and wording, thanks @incertum !

Commit + rebased another suggestion.
Also added a new commit that cleans up some extraneous whitespace on some lines. Can drop if it doesn't belong in this PR 👍

/milestone 0.35.0

Apologies for the delay, thanks for the suggestions, Federico!
Made use of the super-neat GitHub batch + signoff + commit feature and rebased latest suggestions :)
Removing WIP tag from PR and looking for approvals for merge 🙏
Thanks for the suggestions, everyone!

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, Happy-Dude
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: ac830d8e3ccf5414d58ccbe9f822ccbfd8a22710

New changes are detected. LGTM label has been removed.

LGTM label has been added.  Git tree hash: d7c47eda10886aa16261e9e3074ecbd83887d612

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, Happy-Dude
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, Happy-Dude, leogr
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


refactor(core)!: move fee asset from UnsignedTransaction to SequenceAction and TransferAction

Summary
as title says. this is so fees can be set per-action instead of per-transaction.
Changes

move fee asset from UnsignedTransaction to SequenceAction and TransferAction
fee asset was only moved to SequenceAction and TransferAction as other actions don't have any fee payment, so it's unneeded.

Testing
unit tests
Breaking Changelist

UnsignedTransaction, SequenceAction, and TransferAction types are changed.

Related Issues
closes #714

note: approving breaking proto changes


Don't fetch nOpt another time

Issue Number
#1981
Overview

[x] Re-use the existing nOpt instead of fetching it again

Comments

bors r+

bors r+


Plugins revamp

Motivation and Context
Revamping plugin system to make at actually pluggable for different data types etc.
Description

Introducing new io module. This will help users to use the import/export functionality of plugins through the program if they don't wan't to interact with the low-level hangar APIs
We potentially can move other modules like dataset inside io module
Test cases are work in progress
Docs are work in progress

Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[x] Documentation update
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Is this PR ready for review, or a work in progress?

[ ] Ready for review
[x] Work in progress

How Has This Been Tested?
Put an x in the boxes that apply:

[x] Current tests cover modifications made
[x] New tests have been added to the test suite
[x] Modifications were made to existing tests to support these changes
[ ] Tests may be needed, but they are not included when the PR was proposed
[ ] I don't know. Help!

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have signed (or will sign when prompted) the tensorwork CLA.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

@rlizzo There will be few more minute changes but it's in a good shape now to review especially because of the introduction of io module

Ok. I'd like to merge the changes in #130 before this, since they did a big overhaul of the test suit to simplify it's fixture setup (improving speeds in most cases)

Make sense. I'll finish my review soon

Hey @hhsecond lets connect about these changes on a call. I don't think I agree with moving to io directory to top level of src/hangar. Will get into the details over a vid chat.

Sure thing. I was reluctant too about it initially but then realized few reasons why should we do it. Let's talk

What's the actual use case for plugins? I'm worried it's a lot of complexity and API surface area for benefit that isn't super clear from the outside.

@elistevens comment here https://github.com/tensorwerk/hangar-py/pull/134#discussion_r336724026 should give you more info. Lemme know what do you think

Sounds great!
On Fri, Oct 18, 2019, 23:07 Sherin Thomas<EMAIL_ADDRESS>wrote:

@elistevens https://github.com/elistevens comment here #134 (comment)
https://github.com/tensorwerk/hangar-py/pull/134#discussion_r336724026
should give you more info. Lemme know what do you think
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorwerk/hangar-py/pull/134?email_source=notifications&email_token=AABBWICFKAAAKUGWM3EQM6LQPKPZVA5CNFSM4I7YWL2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBXGL6Y#issuecomment-544105979,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABBWICCQQI3VPQJX5TA3PDQPKPZVANCNFSM4I7YWL2A
.


ChaCha20 tests

Test vectors from https://github.com/quicwg/base-drafts/pull/3712. While at it I also did some small refactorings.

While at it I also synce the Initial packet encryption/decryption test vectors as we haven't update them in a while.


Polishing to use fluent style coding as possible in MapperBuilderAssistant

I've polished to use fluent style coding on Builder object as possible.
Please review.
Thanks.

Seems a big change. Hope you did it carefully! :)

Thanks for merging.
I've polished carefully !!