Usage of SCREEN_UV appears to break lighting (with Light2D)

Godot version: 3.1.1.stable.official

OS/device including version:  Ubuntu 16.04.6 LTS

Issue description:

It appears that usage of SCREEN_UV inside a canvas_item shader changes how those sprites are rendered in a way that breaks lighting (for my purposes).
I'm not precisely sure how to describe the behavior, but here's my use case:
I'm putting together a 2D platformer using the tilemap system. However, in order to add detail to the tilemaps, I've decided to use a masking system, where a mask for the tilemap is first rendered onto a Viewport, and then the tile shader reads from that mask to see whether to discard the fragment.
However, it appears that Light2Ds will still illuminate the discarded fragments, and I haven't found a way to stop that from happening.
Here's an image demonstrating the behavior:

Upon further investigation, I was able to create a situation where a shader that reads from SCREEN_UV has a similar problem, while a shader that reads from UV does not. I have attached a demo project. In this demo, strangely enough, reading from SCREEN_UV completely disables lighting, which is seemingly not related to the behavior in my real project.
I believe this is, incidentally, related to an issue I opened before, so I might have a bit more understanding of why it is happening. I believe that screen-reading shaders are likely rendered differently from non-screen-reading shaders, and this is for some justifiable reasons, from my understanding.
However, it is important to note that just because a shader reads from SCREEN_UV does not mean it is a screen-reading shader. The example project I have attached should exemplify this.
So my suggestion is that reading from SCREEN_UV should not impact how a shader is rendered.
Of course, for my real use case, there may be additional factors causing the problem. But I think the demo project indicates that the SCREEN_UV issue does exist independently in any case.
Steps to reproduce:
Create a shader that does something. Change it to use SCREEN_UV somewhere. Observe if this changes how it interacts with lights.
Minimal reproduction project:

screen-uv-example.zip

Note that this is only reproducible in GLES3.

After playing around with it a bit more I found two more distinct behaviors, created by these shaders:
bool threshold(float x, float y) {
	return abs(x - y) < 0.1;
}

void fragment() {
	if(threshold(rand(SCREEN_UV), 0.5)) {
		discard;
	}
}

bool threshold(float x, float y) {
	return abs(x - y) < 0.1;
}

void fragment() {
	float x = SCREEN_UV.x;
	if(threshold(rand(UV), x)) {
		discard;
	}
}

I can't imagine this information is particularly illuminating, but I guess I might as well post it.
Here's an additional project with everything I've looked at:
screen-uv-example-2.zip
If I have more time I might try to reproduce the structures in my real project to see if they have the same behaviors. They were incredibly strange: if I changed the color I used for masking in the shaders to the background color of the mask viewport, they would no longer have the same "illuminating discarded pixels" bug, but would rather display the "no illumination whatsoever" bug.

After playing around with it a bit more I found two more distinct behaviors, created by these shaders:
bool threshold(float x, float y) {
	return abs(x - y) < 0.1;
}

void fragment() {
	if(threshold(rand(SCREEN_UV), 0.5)) {
		discard;
	}
}

bool threshold(float x, float y) {
	return abs(x - y) < 0.1;
}

void fragment() {
	float x = SCREEN_UV.x;
	if(threshold(rand(UV), x)) {
		discard;
	}
}

I can't imagine this information is particularly illuminating, but I guess I might as well post it.
Here's an additional project with everything I've looked at:
screen-uv-example-2.zip
If I have more time I might try to reproduce the structures in my real project to see if they have the same behaviors. They were incredibly strange: if I changed the color I used for masking in the shaders to the background color of the mask viewport, they would no longer have the same "illuminating discarded pixels" bug, but would rather display the "no illumination whatsoever" bug.

Is this not supposed to work with GLES2? I got many errors along with some long shader code(probably endless because it overflowed after some time). Here's the part of it which repeats again and again(note this is not the start of the log but still shows where it repeats):

ERROR: _display_error_with_code: CanvasShaderGLES2: Fragment shader compilation failed:
ERROR: 4:10: 'round' : no matching overloaded function found (using implicit conversion)
ERROR: 4:10: 'round' : function is not known

   At: drivers\gles2\shader_gles2.cpp:129
ERROR: ShaderGLES2::get_current_version: Method/Function Failed, returning: 0
   At: drivers\gles2\shader_gles2.cpp:360
ERROR: ShaderGLES2::bind: Condition ' !version ' is true. returned: false
   At: drivers\gles2\shader_gles2.cpp:88
1: #version 120
2: #define USE_GLES_OVER_GL
3: #define USE_TEXTURE_RECT
4: #define USE_LIGHTING
5:
6: // texture2DLodEXT and textureCubeLodEXT are fragment shader specific.
7: // Do not copy these defines in the vertex section.
8: #ifndef USE_GLES_OVER_GL
9: #ifdef GL_EXT_shader_texture_lod
10: #extension GL_EXT_shader_texture_lod : enable
11: #define texture2DLod(img, coord, lod) texture2DLodEXT(img, coord, lod)
12: #define textureCubeLod(img, coord, lod) textureCubeLodEXT(img, coord, lod)
13: #endif
14: #endif // !USE_GLES_OVER_GL
15:
16: #ifdef GL_ARB_shader_texture_lod
17: #extension GL_ARB_shader_texture_lod : enable
18: #endif
19:
20: #if !defined(GL_EXT_shader_texture_lod) && !defined(GL_ARB_shader_texture_lod)
21: #define texture2DLod(img, coord, lod) texture2D(img, coord, lod)
22: #define textureCubeLod(img, coord, lod) textureCube(img, coord, lod)
23: #endif
24:
25: #ifdef USE_GLES_OVER_GL
26: #define lowp
27: #define mediump
28: #define highp
29: #else
30: #if defined(USE_HIGHP_PRECISION)
31: precision highp float;
32: precision highp int;
33: #else
34: precision mediump float;
35: precision mediump int;
36: #endif
37: #endif
38:
39: uniform sampler2D color_texture; // texunit:-1
40: /* clang-format on */
41: uniform highp vec2 color_texpixel_size;
42: uniform mediump sampler2D normal_texture; // texunit:-2
43:
44: varying mediump vec2 uv_interp;
45: varying mediump vec4 color_interp;
46:
47: uniform highp float time;
48:
49: uniform vec4 final_modulate;
50:
51: #ifdef SCREEN_TEXTURE_USED
52:
53: uniform sampler2D screen_texture; // texunit:-4
54:
55: #endif
56:
57: #ifdef SCREEN_UV_USED
58:
59: uniform vec2 screen_pixel_size;
60:
61: #endif
62:
63: #ifdef USE_LIGHTING
64:
65: uniform highp mat4 light_matrix;
66: uniform highp mat4 light_local_matrix;
67: uniform highp mat4 shadow_matrix;
68: uniform highp vec4 light_color;
69: uniform highp vec4 light_shadow_color;
70: uniform highp vec2 light_pos;
71: uniform highp float shadowpixel_size;
72: uniform highp float shadow_gradient;
73: uniform highp float light_height;
74: uniform highp float light_outside_alpha;
75: uniform highp float shadow_distance_mult;
76:
77: uniform lowp sampler2D light_texture; // texunit:-4
78: varying vec4 light_uv_interp;
79: varying vec2 transformed_light_uv;
80:
81: varying vec4 local_rot;
82:
83: #ifdef USE_SHADOWS
84:
85: uniform highp sampler2D shadow_texture; // texunit:-5
86: varying highp vec2 pos;
87:
88: #endif
89:
90: const bool at_light_pass = true;
91: #else
92: const bool at_light_pass = false;
93: #endif
94:
95: uniform bool use_default_normal;
96:
97: /* clang-format off */
98:
99: float m_rand(in vec2 m_co)
100: {
101:    return fract((sin(dot(m_co.xy, vec2(12.9898,78.233))) * 43758.5));
102: }
103:
104: float m_rand_int(in vec2 m_uv)
105: {
106:    return round(m_rand(m_uv));
107: }
108:
109:
110: /* clang-format on */
111:
112: void light_compute(
113:            inout vec4 light,
114:            inout vec2 light_vec,
115:            inout float light_height,
116:            inout vec4 light_color,
117:            vec2 light_uv,
118:            inout vec4 shadow_color,
119:            vec3 normal,
120:            vec2 uv,
121: #if defined(SCREEN_UV_USED)
122:            vec2 screen_uv,
123: #endif
124:            vec4 color) {
125:
126: #if defined(USE_LIGHT_SHADER_CODE)
127:
128:    /* clang-format off */
129:
130:
131:    /* clang-format on */
132:
133: #endif
134: }
135:
136: void main() {
137:
138:    vec4 color = color_interp;
139:    vec2 uv = uv_interp;
140: #ifdef USE_FORCE_REPEAT
141:    //needs to use this to workaround GLES2/WebGL1 forcing tiling that textures that don't support it
142:    uv = mod(uv, vec2(1.0, 1.0));
143: #endif
144:
145: #if !defined(COLOR_USED)
146:    //default behavior, texture by color
147:    color *= texture2D(color_texture, uv);
148: #endif
149:
150: #ifdef SCREEN_UV_USED
151:    vec2 screen_uv = gl_FragCoord.xy * screen_pixel_size;
152: #endif
153:
154:    vec3 normal;
155:
156: #if defined(NORMAL_USED)
157:
158:    bool normal_used = true;
159: #else
160:    bool normal_used = false;
161: #endif
162:
163:    if (use_default_normal) {
164:            normal.xy = texture2D(normal_texture, uv).xy * 2.0 - 1.0;
165:            normal.z = sqrt(1.0 - dot(normal.xy, normal.xy));
166:            normal_used = true;
167:    } else {
168:            normal = vec3(0.0, 0.0, 1.0);
169:    }
170:
171:    {
172:            float normal_depth = 1.0;
173:
174: #if defined(NORMALMAP_USED)
175:            vec3 normal_map = vec3(0.0, 0.0, 1.0);
176:            normal_used = true;
177: #endif
178:
179:            /* clang-format off */
180: {
181:    if ((m_rand_int(uv) == 0.0))
182:    {
183:                    {
184: discard;   }
185: ;
186:    }
187: }
188:
189:
190:            /* clang-format on */
191:
192: #if defined(NORMALMAP_USED)
193:            normal = mix(vec3(0.0, 0.0, 1.0), normal_map * vec3(2.0, -2.0, 1.0) - vec3(1.0, -1.0, 0.0), normal_depth);
194: #endif
195:    }
196:    color *= final_modulate;
197:
198: #ifdef USE_LIGHTING
199:
200:    vec2 light_vec = transformed_light_uv;
201:
202:    if (normal_used) {
203:            normal.xy = mat2(local_rot.xy, local_rot.zw) * normal.xy;
204:    }
205:
206:    float att = 1.0;
207:
208:    vec2 light_uv = light_uv_interp.xy;
209:    vec4 light = texture2D(light_texture, light_uv);
210:
211:    if (any(lessThan(light_uv_interp.xy, vec2(0.0, 0.0))) || any(greaterThanEqual(light_uv_interp.xy, vec2(1.0, 1.0)))) {
212:            color.a *= light_outside_alpha; //invisible
213:
214:    } else {
215:            float real_light_height = light_height;
216:            vec4 real_light_color = light_color;
217:            vec4 real_light_shadow_color = light_shadow_color;
218:
219: #if defined(USE_LIGHT_SHADER_CODE)
220:            //light is written by the light shader
221:            light_compute(
222:                            light,
223:                            light_vec,
224:                            real_light_height,
225:                            real_light_color,
226:                            light_uv,
227:                            real_light_shadow_color,
228:                            normal,
229:                            uv,
230: #if defined(SCREEN_UV_USED)
231:                            screen_uv,
232: #endif
233:                            color);
234: #endif
235:
236:            light *= real_light_color;
237:
238:            if (normal_used) {
239:                    vec3 light_normal = normalize(vec3(light_vec, -real_light_height));
240:                    light *= max(dot(-light_normal, normal), 0.0);
241:            }
242:
243:            color *= light;
244:
245: #ifdef USE_SHADOWS
246:            // Reset light_vec to compute shadows, the shadow map is created from the light origin, so it only
247:            // makes sense to compute shadows from there.
248:            light_vec = light_uv_interp.zw;
249:
250:            float angle_to_light = -atan(light_vec.x, light_vec.y);
251:            float PI = 3.14159265358979323846264;
252:            /*int i = int(mod(floor((angle_to_light+7.0*PI/6.0)/(4.0*PI/6.0))+1.0, 3.0)); // +1 pq os indices estao em ordem 2,0,1 nos arrays
253:            float ang*/
254:
255:            float su, sz;
256:
257:            float abs_angle = abs(angle_to_light);
258:            vec2 point;
259:            float sh;
260:            if (abs_angle < 45.0 * PI / 180.0) {
261:                    point = light_vec;
262:                    sh = 0.0 + (1.0 / 8.0);
263:            } else if (abs_angle > 135.0 * PI / 180.0) {
264:                    point = -light_vec;
265:                    sh = 0.5 + (1.0 / 8.0);
266:            } else if (angle_to_light > 0.0) {
267:
268:                    point = vec2(light_vec.y, -light_vec.x);
269:                    sh = 0.25 + (1.0 / 8.0);
270:            } else {
271:
272:                    point = vec2(-light_vec.y, light_vec.x);
273:                    sh = 0.75 + (1.0 / 8.0);
274:            }
275:
276:            highp vec4 s = shadow_matrix * vec4(point, 0.0, 1.0);
277:            s.xyz /= s.w;
278:            su = s.x * 0.5 + 0.5;
279:            sz = s.z * 0.5 + 0.5;
280:            //sz=lightlength(light_vec);
281:
282:            highp float shadow_attenuation = 0.0;
283:
284: #ifdef USE_RGBA_SHADOWS
285:
286: #define SHADOW_DEPTH(m_tex, m_uv) dot(texture2D((m_tex), (m_uv)), vec4(1.0 / (256.0 * 256.0 * 256.0), 1.0 / (256.0 * 256.0), 1.0 / 256.0, 1.0))
287:
288: #else
289:
290: #define SHADOW_DEPTH(m_tex, m_uv) (texture2D((m_tex), (m_uv)).r)
291:
292: #endif
293:
294: #ifdef SHADOW_USE_GRADIENT
295:
296:            /* clang-format off */
297:            /* GLSL es 100 doesn't support line continuation characters(backslashes) */
298: #define SHADOW_TEST(m_ofs) { highp float sd = SHADOW_DEPTH(shadow_texture, vec2(m_ofs, sh)); shadow_attenuation += 1.0 - smoothstep(sd, sd + shadow_gradient, sz); }
299:
300: #else
301:
302: #define SHADOW_TEST(m_ofs) { highp float sd = SHADOW_DEPTH(shadow_texture, vec2(m_ofs, sh)); shadow_attenuation += step(sz, sd); }
303:            /* clang-format on */
304:
305: #endif
306:
307: #ifdef SHADOW_FILTER_NEAREST
308:
309:            SHADOW_TEST(su);
310:
311: #endif
312:
313: #ifdef SHADOW_FILTER_PCF3
314:
315:            SHADOW_TEST(su + shadowpixel_size);
316:            SHADOW_TEST(su);
317:            SHADOW_TEST(su - shadowpixel_size);
318:            shadow_attenuation /= 3.0;
319:
320: #endif
321:
322: #ifdef SHADOW_FILTER_PCF5
323:
324:            SHADOW_TEST(su + shadowpixel_size * 2.0);
325:            SHADOW_TEST(su + shadowpixel_size);
326:            SHADOW_TEST(su);
327:            SHADOW_TEST(su - shadowpixel_size);
328:            SHADOW_TEST(su - shadowpixel_size * 2.0);
329:            shadow_attenuation /= 5.0;
330:
331: #endif
332:
333: #ifdef SHADOW_FILTER_PCF7
334:
335:            SHADOW_TEST(su + shadowpixel_size * 3.0);
336:            SHADOW_TEST(su + shadowpixel_size * 2.0);
337:            SHADOW_TEST(su + shadowpixel_size);
338:            SHADOW_TEST(su);
339:            SHADOW_TEST(su - shadowpixel_size);
340:            SHADOW_TEST(su - shadowpixel_size * 2.0);
341:            SHADOW_TEST(su - shadowpixel_size * 3.0);
342:            shadow_attenuation /= 7.0;
343:
344: #endif
345:
346: #ifdef SHADOW_FILTER_PCF9
347:
348:            SHADOW_TEST(su + shadowpixel_size * 4.0);
349:            SHADOW_TEST(su + shadowpixel_size * 3.0);
350:            SHADOW_TEST(su + shadowpixel_size * 2.0);
351:            SHADOW_TEST(su + shadowpixel_size);
352:            SHADOW_TEST(su);
353:            SHADOW_TEST(su - shadowpixel_size);
354:            SHADOW_TEST(su - shadowpixel_size * 2.0);
355:            SHADOW_TEST(su - shadowpixel_size * 3.0);
356:            SHADOW_TEST(su - shadowpixel_size * 4.0);
357:            shadow_attenuation /= 9.0;
358:
359: #endif
360:
361: #ifdef SHADOW_FILTER_PCF13
362:
363:            SHADOW_TEST(su + shadowpixel_size * 6.0);
364:            SHADOW_TEST(su + shadowpixel_size * 5.0);
365:            SHADOW_TEST(su + shadowpixel_size * 4.0);
366:            SHADOW_TEST(su + shadowpixel_size * 3.0);
367:            SHADOW_TEST(su + shadowpixel_size * 2.0);
368:            SHADOW_TEST(su + shadowpixel_size);
369:            SHADOW_TEST(su);
370:            SHADOW_TEST(su - shadowpixel_size);
371:            SHADOW_TEST(su - shadowpixel_size * 2.0);
372:            SHADOW_TEST(su - shadowpixel_size * 3.0);
373:            SHADOW_TEST(su - shadowpixel_size * 4.0);
374:            SHADOW_TEST(su - shadowpixel_size * 5.0);
375:            SHADOW_TEST(su - shadowpixel_size * 6.0);
376:            shadow_attenuation /= 13.0;
377:
378: #endif
379:
380:            //color *= shadow_attenuation;
381:            color = mix(real_light_shadow_color, color, shadow_attenuation);
382: //use shadows
383: #endif
384:    }
385:
386: //use lighting
387: #endif
388:
389:    gl_FragColor = color;
390: }
391:
ERROR: _display_error_with_code: CanvasShaderGLES2: Fragment shader compilation failed:
ERROR: 5:10: 'round' : no matching overloaded function found (using implicit conversion)
ERROR: 5:10: 'round' : function is not known

   At: drivers\gles2\shader_gles2.cpp:129
ERROR: ShaderGLES2::get_current_version: Method/Function Failed, returning: 0
   At: drivers\gles2\shader_gles2.cpp:360
ERROR: ShaderGLES2::bind: Condition ' !version ' is true. returned: false
   At: drivers\gles2\shader_gles2.cpp:88
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: d:\godot\compile_space\godot\drivers\gles2\shader_gles2.h:254
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: d:\godot\compile_space\godot\drivers\gles2\shader_gles2.h:254
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: d:\godot\compile_space\godot\drivers\gles2\shader_gles2.h:254

Might be unrelated.

GLES3:

GLES2:

That big white rect that only appears in GLES2 is puzzling me.

@Anutrix The GLES2 issue is unrelated. GLES2 doesn't have the built-in round() function, so when you try to use it in a shader it results in a compile error. https://github.com/godotengine/godot/issues/24850

I've been messing around with canvas.glsl and found something, maybe..?
If I comment out uniform vec2 screen_pixel_size; and then, to the top of main(), add vec2 screen_pixel_size = vec2(0.5 / 640.0, 0.5 / 480.0);, the bug goes away for my demo project (as these should be the proper pixel size factors).
However, this doesn't really make sense, as screen_pixel_size appears to be entirely unrelated to the lighting calculations. The only thought I had is that maybe uniforms were being written to the wrong place, but I couldn't find anything else that would indicate that was happening.

Here's my theory as to what's happening:
During the light pass, screen_pixel_size is being set to zero.
Take a look at this shader:
shader_type canvas_item;

uniform vec2 offset;

float rand(vec2 co){
    return fract(sin(dot((co + offset).xy ,vec2(12.9898,78.233))) * 43758.5453);
}

vec3 rand3(vec2 co) {
	float a = rand(co);
	float b = rand(co + vec2(a));
	float c = rand(co + vec2(b));
	return vec3(a, b, c);
}

void fragment() {
	COLOR.rgb = rand3(SCREEN_UV);
}

And then use the same setup as in my demo scene.
Changing the uniform vec2 offset will change which color the entire lighted section takes on. This would happen if screen_uv is zero (due to being multiplied by a zero screen_pixel_size), and it also just so happens that an offset of zero results in rand3 return (0, 0, 0), for zero screen_uv, or unlit.
I just can't figure out where in the source code this bug would be coming from.

You can prove your theory by changing the value based on whether AT_LIGHT_PASS is true or false.
vec2 uv = UV;
if (AT_LIGHT_PASS) {
    uv = vec2(0.0);
}

Is the same as using SCREEN_UV
There are a couple places to look for this. Most likely is rasterizer_canvas_gles3.cpp This is the file responsible for setting shader uniforms, so look for where they set USE_LIGHTING, and SCREEN_PIXEL_SIZE.
SCREEN_UV_USED is set automatically by the shader compiler when it detects that you have used SCREEN_UV. Something may be wonky with that too. So look in shader_compiler_gles3.cpp
Since this issue isn't in GLES2, it would be very useful to compare the two and see what is done differently in each file in GLES2.

Just submitted a commit to fix this! :)

Oh no me too

@TheMonsterFromTheDeep Haha! Oh no!


Fix retry algorithm

This test is flaky:

TestRetryingUnaryOperation.testCompleteFailure_Deadline:147->testTimeout:175 Slept more than expected (1549000 ms)

The retry process has some issues in it.

I don't seem to recreate test failure in my local. I tried timeout range from 1 to 600, it was passing in all of them.
Was there any specific duration for which it was failing?

TestRetryingUnaryOperation.testCompleteFailure_Deadline would sporadically fail.
Please change this line from 1.5 to something like 1.1: https://github.com/googleapis/cloud-bigtable-client/blob/397f709991c60b2e6061418f0b6dce54a431d321/bigtable-client-core-parent/bigtable-client-core/src/test/java/com/google/cloud/bigtable/grpc/async/OperationClock.java#L91


menu

Just comment it, GUI will prolly be finished in 7 days or so

https://cdn.discordapp.com/attachments/929069498164711505/929740862844461116/unknown.png

With that nobody ever will help you, check printed stack, check what failed and where and why.
By now I can only see that filesystem returned somewhere runtime error.

oh my bad fixed

Can I know what exactly was the fix? It will help for other people too

i formatted pc and i installed c++ redistributables and fixed

its crashing when inject but with -insecure its not crashing why ?

I doubt the flag to launch the game will cause the crash, it might be due to injector. I personally have never injected it on normal launch. Will inform you tomorrow or in few days.

okay

I can't really find any reason, this flag is not a reason ever. Only what I can imagine is injector somehow blocking access to resource which can crash.
Solution: use any other injector, or compile it correctly.


Pilets built with Webpack seem to be using first chunk emitted as the Pilet

We're running into an issue with Piral and Webpack. When running in debug mode (i.e., pilet debug), if the Webpack build emits more than one chunk, it tries to load the wrong chunk as the pilet. More specificially, it tries to load the first chunk emitted by the Pilet's webpack build.
For example, if we use Font Awesome 4, the chunks emitted include font files. So, when running pilet debug, it ends up trying to load an .eot file as the pilet.
Another example, if we do code splitting with React.lazy() and import(), the chunks emitted are 0.index.js and index.js. In that case, it tires to load 0.index.js as the pilet, which is incorrect.

Closing in favor of https://github.com/smapiot/piral/issues/258.
Thanks for reporting the issue :+1:!


Add list of removed panels to the 67 release notes

Originally, the three panels: canvas, shader, and WebAudio were to be deprecated in Firefox 67 and removed from Firefox 68. However, the panels have been removed from 67 (as shown in Firefox Developer) so the notice of their removal needs to be added to the 67 release notes. Information about the associated bugs can be found on the Deprecated tools page.
Acceptance criteria

[x] Notice has been added to the release notes.
[x] Deprecated tools page has been updated to reflect the fact that the panels will be gone as of Firefox 67 instead of 68.

Added the following to the 67 release notes:
The following Developer Tools panels have been removed:
Canvas debugger (bug 1403938).
Shader editor (bug 1342237).
WebAudio editor (bug 1403944).

Updated the Deprecated tools page to note that the panels have been removed as of Firefox 67 instead of deprecated in Firefox 68.
I have not deleted the documentation for the panels but will archive it and add that note to the Deprecated Tools page when Firefox 67 has been released.
Finally, on the main developer tools page, I have edited the existing note to say:
Note: The Canvas Debugger, Shader Editor, and Web Audio Editor tools have been deprecated and will be removed from Firefox 67. For details, see Deprecated tools.


[BEAM-6694] Added Approximate Quantile Transfrom on Python SDK

Added PTransforms for getting an idea of a PCollection's data distribution using approximate N-tiles (e.g. quartiles, percentiles, etc.), globally & per-key.
It offers the same API as its Java counterpart

https://github.com/apache/beam/blob/master/sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/ApproximateQuantiles.java

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---

---
---

Java

Python

---

---
---

Pre-Commit Tests Status (on master branch)

---
Java
Python
Go
Website

Non-portable

Portable
---

---
---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

retest this please

R: @Hannah-Jiang could you make this first pass review here since you worked on the similar  ApproximateUnique transform.

Run Python_PVR_Flink PreCommit

Hi @Hannah-Jiang. Thanks for reviewing my PR and the feedbacks. I've made some changes you mentioned. Can you please take a look? Thank you.

retest this please

Run Python_PVR_Flink PreCommit

This looks good.
A minor point is can we add more test cases with different compare functions?
For example, compare with absolute values, compare with string, pass a customized function to compare (instead of a simple a,b comparison). Now we compare strings by length, but I think in real practice, there are many cases users want to compare by string values or pass a customized compare functions.

Hi @Hannah-Jiang. Thanks for the feedback. There is a test case test_alternate_comparator() in which user get the results as per the length of the string. But I can see your point, let me add some more.


SK3dView y axis inverted?

Hi!
My code looks like:
SK3dView v = new SK3dView();
v.Translate(10, 10, 0); //x10, y10, z0
using (SKCanvas canvas = surface.Canvas) {
  canvas.SetMatrix(v.Matrix);
  canvas.DrawRect(new SKRect(0, 0, 100, 100), new SKPaint() {
    Color = new SKColor(255, 0, 0),
    IsAntialias = true, });
}

Now the painted rectangle is not on the position x[10], y[10] (as I would expect it), its is on the position x[10], y[-10].
Is this a correct behavior?
EDIT:
The Z-Axis has the same behavior. A negative value makes the rectangle appear greater and a positive value makes the rectangle appear smaller.
Best regards,
Sora

I think this is the desired/correct functionality.
Here is a fiddle: https://fiddle.skia.org/c/1554299ac982bee3eb824a4b1985a87b

There are 4 rectangles:

GRAY - initial/base
GREEN - moved +50 pixels along the X axis
BLUE - moved +50 along the Y axis
RED - moved +200 pixels along the Z axis

As you can see, the origin is the bottom, left (typical in 3D spaces) and the Z direction is away from the screen.
It is important to remember that this transformation doesn't change the actual canvas matrix origin. It is still the top left.


[BUG] Deepspeed help parameter typo

@oushu1zhangxiangxuan1 - this is the correct comment, as mentioned in my comment on your PR, the description of the behavior of --exclude references --include since it is mutually exclusive with it, meaning they cannot be used together.


Vocabulary test should check the date if the thesaurus is GEMET - INSPIRE themes, version 1.0

The vocabulary test should check all of the following when the title of the thesaurus is "GEMET - INSPIRE themes, version 1.0":

date type is publication
date is 2008-06-01

Argument: it is not an explicit requirement in the TG and is given as example in section 2.4.2. However, the INSPIRE spatial data theme is a crucial keyword, thus it is important that all the information is present, correct and preferably containing the same date type - and thus date - in all member states.
See also https://ies-svn.jrc.ec.europa.eu/issues/3101

While I understand this request, I do not see it covered by the Technical Guidance. I think the relevant requirement is 18:

The thesaurusName identification shall include at least the title and a reference date (date of publication, date of last revision or of creation) of the originating controlled vocabulary.

I.e., there is no requirement to provide a publication date. Any of the three types of dates is ok.
In order to test valid dates for selected vocabularies, a list of vocabulary titles and publication dates would need to be published and maintained somewhere. I guess the registry would be the place for this.
I tag this issue for discussion by the MIG-T subgroup.

I agree that the use of the date of publication for the INSPIRE themes is not explicitly required in the MD TG v1.3, but only included in the example. If we agree that it should be a requirement (as it is in the v2.0 - see TG Requirement C.15: metadata/2.0/req/common/keyword-originating-cv), we would either need to update the TG v1.3, or agree that the ATS should be more strict than the requirements in the text.
We may need to have a general discussion on this topic, since it seems to be a recurring case for the (often un-precise v1.3 of the MD TG).

OK, but I do not think it is just  MD TG v1.3 to blame. TG MD 2.0.1 makes
it actually even worse with an explicit note:
*(24) Attribute codeList shall have value
"http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode
http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#CI_DateTypeCode"
and the attribute codeListValue value "publication". *
On Thu, Feb 15, 2018 at 12:00 PM, Michael Lutz<EMAIL_ADDRESS>wrote:

I agree that the use of the date of publication for the INSPIRE themes is
not explicitly required in the MD TG v1.3, but only included in the
example. If we agree that it should be a requirement (as it is in the v2.0

see TG Requirement C.15: metadata/2.0/req/common/keyword-originating-cv),
we would either need to update the TG v1.3, or agree that the ATS should be
more strict than the requirements in the text.

We may need to have a general discussion on this topic, since it seems to
be a recurring case for the (often un-precise v1.3 of the MD TG).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/inspire-eu-validation/metadata/issues/130#issuecomment-365893967,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhmKr2331mJpF8xWOSapc0yVT7f2ISNks5tVA5ogaJpZM4R8UWE
.

In addition, in the MD TG v1.3 the specific title of the thesaurus is not even explicitly required, as in the v2.0  - see TG Requirement 1.4: metadata/2.0/req/datasets-and-series/inspire-theme-keyword.
Furthermore, the TG requirement C.15 in MD TG v2.0 refers explicitly to the publication date of publication; indeed it reads as follows "The publication date of the vocabulary shall be given using the gmd:date/gmd:CI_Date/gmd:date/gco:Date and gmd:dateType/gmd:CI_DateTypeCode elements". The footnote only gives the implementation.  In case of a possible revision of the TG 2.0 the footnote could be added in the text  of the requirement.
So, since the TG v2.0 gives more specific requirements, I agree on the second option (more strict ATS) without updating the TG v.1.3.

[2017.4 meeting 2018-02-15] Even if the requirement in v1.3 of the TG is not requiring the date to be the date of publication, the given date and title should be correct with respect to the given controlled vocabulary. For the "GEMET - INSPIRE themes, version 1.0" (https://www.eionet.europa.eu/gemet/en/inspire-themes/), it should therefore be "2008-06-01" (date of publication). This should be clarified in a corrigendum for v1.3, and the ATS and ETS should be updated accordingly.

[2017.4 meeting 2018-03-16] The conclusions from the previous meeting are confirmed. The issue should be closed and 3 new issues for ATS, ETS and TG changes should be created.


Patch 4.4 update?

I've waited for almost a week and the website still don't have the 4.4 synthesis items.
https://ermad.github.io/ffxiv-craft-opt-web/app/#/simulator

That is not the official website, it is the testing website of a frequent contributor. The official website is http://ffxiv.lokyst.net or http://ffxiv-beta.lokyst.net for the latest updates.
I don't follow FFXIV news very closely so I was unaware of the new patch. Thanks for letting me know.
However, it appears that there are now 4-star recipes, for which my importer script does not know how to calculate their effective level (level 70 3-star recipes are effectively level 350, for example). The effective level progression of level 70 star recipes so far has been: 290, 300, 320, 350. I could infer that 4-star recipes are 390 but it would just be a guess. I need confirmation from somebody who can test it.
@ermad Have you been able to determine this yet?

Given that level 60 4-star recipes were effectively 40 levels higher than level 60 3-star recipes, that seems to be a safe bet. So I can provisionally import the database using that progression and if it's later determined to be wrong, I can reimport the database.

I am not playing atm either (taking a break for a bit), so why I haven't done any updates yet. Most of the stuff follow the same formula so should be easy to update regardless.
If anyone has some data from the 4* crafts I can use to confirm the results that will help a lot.

Deployed to beta site.

Ing2RecipeLevelTable
380: 293   // 70_4star
Ing1RecipeLevelTable
380: 294   // 70_4star
ProgressPenaltyTable
380: -0.048
QualityPenaltyTable
380: -0.1305
I have measured these data and there will be some errors in the advancement of the high progress, but these errors are within acceptable limits.
I do not guarantee its correctness and it can be only used as a reference.
Interestingly, when testing this data, I found that the parameters of the control calculation were very close to a multiple of the number 0.345, but I was not sure exactly where it took the integer.
`baseQuality = 3.4500e-5 * control * control + 0.34500 * control + 34.50
var QualityPenaltyTable = {
380: -0.12
}`


fix(gotool_extractor): when no global corpus is given, use package's corpus for each file

Meta note, we gonna be generally ok with using the repo URL as the corpus for most external things?

It's not clear there's something obviously better, at least to start with. Longer term the main confounding issue is that repositories sometimes have alternate vanity URLs (e.g., gopkg.in) that redirect to the real one. Canonicalizing those—if we care to—will either require a database or some other identification like a root-tip hash pair.
But starting with the base URL makes as much sense as anything else. After all, that's how anyone who wants to use the code will find it.


Added tests for hashing parameters except ListParameter

ListParameter cannot be hashed. This may or may not be a problem.
Meant to add this for the other PR. Lists can't be hashed of course. Not sure what should be done wrt that.
I realize the tests are a bit repetitive, but it seems that many of the parameter tests are similar in this respect.
The reason I went through the trouble of actually instantiating a task is due to the distinction between how the parsing of the string handles the creation of the value for the parameter and that the actual instantiation logic only invokes the normalization code. This is what caused the two separate ways that errors showed up for DictParameters in the execution summary.
@Tarrasch

[Current coverage][cc-pull] is 76.11%

Merging [#1719][cc-pull] into [master][cc-base-branch] will decrease coverage by 2.66%

@@             master      #1719   diff @@
==========================================
  Files            94         94
  Lines         10324      10324
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           8133       7858   -275
- Misses         2191       2466   +275
  Partials          0          0

Powered by Codecov. Last updated by [859095a...97e1260][cc-compare]
[cc-base-branch]: https://codecov.io/gh/spotify/luigi/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/spotify/luigi/compare/859095a106864ef11176fbe03c3bb8f8a4c3ad42...97e126026ff94ebd060ccd2824d14bd4272125e1
[cc-pull]: https://codecov.io/gh/spotify/luigi/pull/1719?src=pr

Really?! Is all hashing in python done by first turning the data into a string representation and then hashing it??

Lists can't be hashed of course. Not sure what should be done wrt that.

Why of course? I think it was just an oversight from us when merging ListParameter. If we make it a frozen structure, it should be hashable, no?

I just meant standard Python lists. If a new frozen class is introduced, I'm sure it can be made to work. But given the current state of the code, adding a list test case would fail. My presumption was that you wouldn't want to merge a failing test case. I can add one if you like though.

Really?! Is all hashing in python done by first turning the data into a string representation and then hashing it??

I have no clue. I figured using the standard hash function was right though since my understanding is that that is how dictionaries hash their keys.

@nugend @Tarrasch What is the status of this? Do I need to update ListParameter to be a frozen structure before this PR can be merged?

If ListParameters are made frozen, a list test case would need to be added.

@dlstadther, oh, if you can change the ListParameter to be a frozen structure that would be great!

@Tarrasch, Am I correct that when we refer to a frozen structure, we mean that the data structure is immutable? If so, isn't a frozen list just a tuple?

@dlstadther that's correct. I just didn't realize that it would be that simple as you just said to normalize everything into the tuple type.

@Tarrasch Does it make more sense to add tuple casting to ListParameter's normalize method? Or just  have ListParameter call TupleParameter (essentially removing any differences between ListParameter and TupleParameter)?

Oh holy macaroni we already have TupleParameter I just realized.
We might still call it a ListParameter although it fact the internal structure is a Tuple. Immutability should be seen as an implicit property. Super confusingly enough it seems like tuple-parameter allows 2D structures (tuples of tuples)
Also the name List is intuitive. Luigi is a tool also used by non-programmers, and "List" is more familiar than "Tuple".

My summary: Yes, just add the casting in the normalize() method. Though be careful with implementation as when parsing and serializing we still should print the [1,2,3] syntax. Does this make sense? :)

Yeah, TupleParameter allows for 2D structures since redshift/postgres read columns as a tuple of tuples.
I believe I understand. I'll work on this as time allows this week.

After messing with this a bit, I have something. However, i'm not overly confident with it. I'll submit a PR and we can move the discussion there.


bug: Return to flicker

"@ionic/angular": "^4.10.0",
"@ionic/core": "^4.10.0",
The return of a child page causes a flicker
The animation doesn't seem to stop at the end frame

Thanks for the issue. I am going to close this as a duplicate of https://github.com/ionic-team/ionic/issues/19491.


Error: "Must use import to load ES Module", but I'm already using import!

Versions

nuxt: v2.15.4
node: v14

Reproduction

https://codesandbox.io/s/wizardly-rgb-8jpy8?file=/plugins/test.js
Steps to reproduce

Create a new Nuxt project.
npm i hast-util-select to install the particular library I'm having trouble with (which by the way is part of a widely used ecosystem and work fine outside of Nuxt, so I'm pretty confident it's not the problem here).
Create a file ~/plugins/test.js with the following code:

import { select } from "hast-util-select";

console.log("test", select("p", {
  type: "element",
  tagName: "p",
  properties: {},
  children: [],
}));

Add the plugin to nuxt.config.js.

What is Expected?
The project runs without errors.
What is actually happening?
The error...
Must use import to load ES Module: /sandbox/node_modules/hast-util-select/index.js require() of ES modules is not supported. require() of /sandbox/node_modules/hast-util-select/index.js from /sandbox/node_modules/vue-server-renderer/build.dev.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules. Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /sandbox/node_modules/hast-util-select/package.json.

...is shown on the front-end.

Does anyone have time to look into why this is happening?

@AaronBeaudoin I took a look and was able to get it working by adding all of the various esm packages to the transpile block of the nuxt config: take a look at my fork of your code sandbox

Initially I was adding them as dependencies but that might not be necessary.

I originally only transpiled the hast-util-select package itself and not its dependencies. Thanks for clarifying!
I wonder however, if this workaround should be necessary at all, but that might be another issue.

Adding esmodule dependencies (and their dependnecies) to build.transpile is a good idea.
Alternatively, you can use build.standalone: true in nuxt.config file. (see sandbox fork)
With either workaround, way avoid externalizing server bundle dependencies (nuxt2 uses CommonJS for building server and by default externalizes all node_modules. Which is broken with new type of packages that are (sadly) esm only.)
Since this kind of packages are getting more common in npm ecosystem, I think we might make a fork of webpack-node-externals that has continuous of package exports type, automatically inlining esmodules.

:+1: for the build.standalone: true solution.
I experienced this issue with d3 dependencies. Because d3 packages are using other d3 package as dependencies I would have to transpile every dependency.

Would be great that build.transpile function receives the module path or even better, the resolved path in order to return true for any file ending with .esm.js or .mjs. Something like:
build: {
  transpile: [
    ({ filePath }) => /(\.esm\.js|\.mjs)$/.test(filePath),
  ],
},

I had this same issue but with lodash-es. To fix it, I added this to the nuxt.config.js build object:
   build: {
      transpile: [
          'lodash-es'
       ],
   }

So if you add the packages to the transpile array hopefully it should work.

Hey @AaronBeaudoin I ran into this today and was able to solve it by updating my nuxt.config.js build config to have it transpile the ESM packages like so:
// nuxt.config.js
  build: {
    transpile: [
      '@sindresorhus/slugify',
      '@sindresorhus/transliterate',
      'hast-util-select',
    ],
  }

waw thanks, this solving my same problem on import axios for ssr nuxtjs

@pi0  thank u so much !!! it was solved it ~~~~i spent 3 hours !!!


Manager of an admin set does not see works deposited to the admin set on the Works page

 Issue by hannahfrost
Friday May 12, 2017 at 16:24 GMT
Originally opened as https://github.com/projecthydra-labs/hyku/issues/1111

Expected behavior
I am a Manager of the default admin set. When I am on the dashboard, I expect to see any works deposited to that admin set listed on the Works page, under the Repository Contents.
I expect to see works that have been submitted after the time I was granted the role of Manager
I expect to see works that have been submitted, regardless of whether they are in active or not in active workflow.
Actual behavior
My works page is blank.

Related to https://github.com/projecthydra-labs/hyrax/issues/853

 Comment by jcoyne
Friday May 12, 2017 at 16:28 GMT

@hannahfrost this seems just like projecthydra-labs/hyrax#855, but "as an admin set manager" instead of "as a repository administrator". Is that correct?

 Comment by jcoyne
Friday May 12, 2017 at 16:32 GMT

@hannahfrost is there some reason this is in hyku and not hyrax?
Additionally, should an "admin set manager" get the "All works" tab on this page? https://github.com/projecthydra-labs/hyku/issues/447#issuecomment-276233397 just like the repository manager has?   Is "All works" going to be confusing?

 Comment by hannahfrost
Friday May 12, 2017 at 17:03 GMT

@ggeisler See @jcoyne 's comment above. The question is what should appear on an admin set Manager's Works page? This Manager may not be able to see All Works in the repository, and may not have any works of their own to see. Do they get a different tab?

 Comment by ggeisler
Friday May 12, 2017 at 17:14 GMT

@hannahfrost @jcoyne Yeah, I see the issue. Maybe a third tab is the right approach?

All Works - for repository manager - everything in the repository
Managed Works - all works the user can manage by virtue of being an admin set manager for one or more admin sets
Your Works - works deposited by or shared with the user

@jcoyne @hannahfrost @ggeisler How much design do you think is needed for this ticket? Is @ggeisler's comment above sufficient to make this actionable?

@mjgiarlo @jcoyne @ggeisler I believe this to be actionable without further discussion.

One addendum to my previous comment where I listed three tabs:

All Works - for repository manager - everything in the repository
Managed Works - all works the user can manage by virtue of being an admin set manager for one or more admin sets
Your Works - works deposited by or shared with the user

In case it wasn't clear from that comment, I believe a given user should never see more than two of the three tabs:

If user is a Repository manager (or other user with ability to manage all works in the repo): All Works and Your Works tabs
If user is Admin set manager (a user that is manager or one or more admin sets): Managed Works and Your Works tabs
If normal user: just Your Works tab

@ggeisler That makes sense. I am going to move this to the Ready column

I may have mistakenly added extra baggage to this ticket. I think we have two related needs:

As an Admin Set Manager, I should be able to view works in the Admin Sets I manage independent of the works that I have deposited. I believe what @ggeisler wrote above works :100: for this.
As a Repository Manager and an Admin Set Manager, I should be able to view works in the Admin Sets I manage independent of the works that I have deposited and I should be able to pick out those works from the list of All Works relatively easily. I believe this is already accommodated via the "Collection" filter here:

@hannahfrost @jcoyne @ggeisler Thus:

I'm back to thinking this issue is now ready, and should focus on (1) above. Sorry that I confused things.
Should we re-label the "Collection" filter above to "Administrative Set" since this list includes AdminSets and we're in the dashboard side of the UI?

Original Description
 Issue by hannahfrost
Friday May 12, 2017 at 16:24 GMT
Originally opened as https://github.com/projecthydra-labs/hyku/issues/1111

Expected behavior
I am a Manager of the default admin set. When I am on the dashboard, I expect to see any works deposited to that admin set listed on the Works page, under the Repository Contents.
I expect to see works that have been submitted after the time I was granted the role of Manager
I expect to see works that have been submitted, regardless of whether they are in active or not in active workflow.
Actual behavior
My works page is blank.

Related to https://github.com/projecthydra-labs/hyrax/issues/853

I updated the acceptance criteria of this issue. (See issue description.) It's now ready to be picket up. Thanks, @jcoyne.

@vantuyls Can you confirm that this ticket is still independently needed and useful, and that the need hasn't been subsumed into some other ticket somewhere?

I don't see a related issue elsewhere. this is functionality we currently see in Collection Extensions work - @elrayle does the implementation of Managed Works come out of CE work or are you leveraging previous work for that?

This work may be done as part of https://github.com/samvera/hyrax/issues/1705
If someone has cycles, this could be tested in nurax. Cc: @hannahfrost @aaron-collier @jcoyne

I tested this in nurax just now and confirmed that this change has been implemented. Closing the ticket. Thanks, all!


Add Germany West Central as a new AKS region into rancher 2.5 UI

When trying to add new AKS managed cluster there is no selection for Germany West Central location.
Please add support for this locations.

Same here


Creating a .prettierrc file doesn't modify prettier config

How to modify the integrated prettier config?
What I did :

Installed the Solidity plugin.
Created a .prettierrc like stated in the plugin overview and placed it at the root of my folder with this content :

{
  "overrides": [
    {
      "files": "*.sol",
      "options": {
        "printWidth": 2000,
        "tabWidth": 2,
        "useTabs": true,
        "singleQuote": false,
        "bracketSpacing": true,
        "explicitTypes": "always"
      }
    }
  ]
}

It worked after I restarted my VSCode, did you too?

@pofulu  yes it should work after restarting and new release should be out soon that fixes this.


Accessories can be found only once during Add-procedure (Core.js)

Hey there,
I experienced some unreliability issues while using 2 GarageDoorOpener accessories with Core.js
Unfortunately once the accessories were added (e.g. to one device via HMCatalog), it can't be found by any other device anymore. Controls work fine and reliable on this one device.
Only help --> remove the "persist" directory and clear the HomeKit data from the device.
Interesting thing is e.g. if you configure the accessories on two iPhones simultaneously it works. But if you try to add another "consumer" to this a minute later -> no accessories appear in the menu.
(I tested this behavior several times)
Any thoughts on this?

@futuretec this is designed by HomeKit due to security reason. To give access accessory to another user, please share the home to the other account if you want to use those accessories with multiple users.

@KhaosT
thanks for the reply.
In that case I don't understand how it is even possible to add the accessories on multiple devices without using the "share home" functionality.
But thanks anyway - I will try to add the devices on one iPhone and share it with other users.


Allow for customization of env vars on prometheus-pushgateway

Signed-off-by: Jessie A. Morris<EMAIL_ADDRESS>
What this PR does / why we need it:
This allows extra environment variables to be specified for the pushgateway container. Specifically I want to set the GOMAXPROCS environment variable to reduce CPU throttling and improve performance on my k8s cluster.
Which issue this PR fixes
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

@gianrubio

/assign @gianrubio

cc @gianrubio
/ok-to-test

/lgtm


WebView2 control

I would like to keep using Rust instead of switching to C#, but I never did any win32 programming so winsafe is very helpful. I've looked into webview2-rs, but the public API is full of unsafe and I found the sample code too complicated compared to winsafe...
Could WebView2 be added to winsafe somehow? I understand WebView2 is very new relative to the classic controls, but I think it would be pretty amazing, if it's doable.

Yes, it can be added.
I never used it, but as far as I could see, it's not a simple thing to do, so it will take some time to be implemented.

Hi, please winsafe add an example with the font and its settings. Thank you.


Implement handles functionality in BlocksBuilder

The BlocksBuilder example scene in feature-gui-interaction has some handy-dandy transform handles that rely on grasp and hover callbacks for visual feedback. But they still can't actually manipulate the object yet!
This is a motivating example for the IE revision, as it's an abstract interaction paradigm that was tricky to figure out how to make work with the original IE.

Scaling was left unimplemented but Translation and Rotation were implemented and the example is wrapped for now.


fatal error: concurrent map read and map write when migrating data to seaweedfs

Chris
This issue is not easy to reproduce without migrating data(heavy R/W loading with frequent adding new volume actions).  I have 3 weed master servers at prod environment, the master leader crash after running for sometime(maybe 2 hours ,or maybe 2 days)
At the initial time, I thought that the RWLock should be the key problem. After digging into it,  I did not find any bug at application code.
The data_node.go file does not export any pub API which could  directly R/W struct DataNode's  volumes field. And when analyzing the backtrace file, there are about 3-4 goroutines R/W  volumes field with APIs at data_node.go, one in line 85(inside the RWLock.RLock() scope, in running status ) ,others are in semacquire status. What I'm confused for the goroutines in semacquire status is that one goroutine is in RWLock.Lock() while another is in RWLock.RLock(), RLock() and semacquire status means there is being an writing operation when the crash happen, but I could not find it.
Could you give some suggestions? Thanks!
weed-master-err.zip

I suspect your code is not in sync with the repo. data_node.go:56 is a Lock(), not RLock()
goroutine 14343569 [semacquire]:
sync.runtime_Semacquire(0xc820444104)
/usr/local/go/src/runtime/sema.go:47 +0x26
sync.(*RWMutex).RLock(0xc8204440f8)
/usr/local/go/src/sync/rwmutex.go:37 +0x58
github.com/chrislusf/seaweedfs/weed/topology.(*DataNode).UpdateVolumes(0xc8204440c0, 0xc8214b2000, 0x209, 0x22e, 0x0, 0x0, 0x0)
/data/go-project/objectStore/src/github.com/chrislusf/seaweedfs/weed/topology/data_node.go:56 +0x20e

Sharp analysis!!
I was reviewing the latest code while the online service is build by old version. Thanks!


Add support for width attribute on nodes

Not sure if there's a reason why the width attribute didn't exist, but I thought, I'll just add it. 🙂

There was no particular reason. I've developed this library for one of my personal project, so I did add only parts I needed.
Thanks a lot for your contribution.


Fixed support check for properties

The specifications for CSS.supports state that both the key and the value are to be provided (https://developer.mozilla.org/es/docs/Web/API/CSS/supports). In firefox and chrome the api call is failing due to missing value specification

+1, Having the same issue

Released as 2.0.1.
As a side note, I highly recommend searching for an alternative solution. styled-components, css-in-js, Radium ... the list goes on and on of much more robust, maintained solutions.


Adding pgbench dashboard to grafonnet.

Type of change

[ ] Refactor
[X] New feature
[ ] Bug fix
[X] Optimization
[ ] Documentation Update

Description

Adding pgbench dashboard to grafonnet.
Related Tickets & Documents

Related Issue #
Closes #

Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.

Testing

Please describe the System Under Test.
Please provide detailed steps to perform tests related to this code change.
How were the fix/results from this change verified? Please provide relevant screenshots or results.

Old dashboard:  https://grafana.rdu2.scalelab.redhat.com:3000/d/d8d9edd1-448e-45b5-bd1c-e8d43600a6c0/pgbench-dashboard?orgId=1
new dashboard: https://grafana.rdu2.scalelab.redhat.com:3000/d/ee79dc45-5403-49d2-b3e4-1feac48d0a7f/pgbench-dashboard-test?orgId=1&showCategory=Data links&tab=query&from=now%2Fy&to=now

lgtm. Thanks :)


[BugFix] fix show create materialized errors

Fixes #issue

Persist and display the ORDER BY clause of materialized view
Simplify the show create materialized view implementation
Fix the REFRESH DEFERRED semantic

What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[x] Yes, this PR will result in a change in behavior.
[ ] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.2
[x] 3.1
[x] 3.0
[x] 2.5
[ ] 2.4

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

@Mergifyio rebase

[FE Incremental Coverage Report]
:heart_eyes: pass : 44 / 51 (86.27%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/TableProperty.java
6
13
46.15%
[299, 402, 403, 404, 408, 409, 411]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
33
33
100.00%
[]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
5
5
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[FE Incremental Coverage Report]
:heart_eyes: pass : 44 / 51 (86.27%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/TableProperty.java
6
13
46.15%
[299, 402, 403, 404, 408, 409, 411]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
33
33
100.00%
[]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
5
5
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[FE Incremental Coverage Report]
:heart_eyes: pass : 44 / 51 (86.27%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/TableProperty.java
6
13
46.15%
[299, 402, 403, 404, 408, 409, 411]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
33
33
100.00%
[]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
5
5
100.00%
[]

@Mergifyio

@Mergifyio rebase

[FE Incremental Coverage Report]
:heart_eyes: pass : 44 / 51 (86.27%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/TableProperty.java
6
13
46.15%
[299, 402, 403, 404, 408, 409, 411]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
33
33
100.00%
[]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
5
5
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

@Mergifyio backport branch-3.2

@Mergifyio backport branch-3.1

@Mergifyio backport branch-3.0

@Mergifyio backport branch-2.5


Feature/jpaley ssd digitization

I think I've managed to resolve the differences between how you and I were using sensor vs. plane in the channel map and have main fully merged in now. I tested makessdclust_job.fcl, but haven't tested any of the digitization code. That part should be blind to the changes though.
I do still want to take a closer look through some of this before merging with main -  strip and set aren't being set correctly. The strip number in SSDRawDigit doesn't actually correspond to what you think it does.


Cherry-pick https://github.com/mattermost/mattermost-server/pull/22711 [MM-51489]: Fix issue with compact message mode

Summary
Fix issue with compact message mode
cherry-pick https://github.com/mattermost/mattermost-server/pull/22711
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-51489
Fixes https://github.com/mattermost/mattermost-server/issues/22551
Screenshots

Before
After

Release Note

- Fix issue with compact message mode

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.


Error with fused function dispatch on Linux with Python 2.7 and NumPy 1.16.3

Minimal Reproducible Example: https://gist.github.com/mobiusklein/808d101ea228a71af02e9b5f4a8a0caa
It was observed that using Python 2.7 on Linux with NumPy 1.16, invoking an unspecialized fused function where np.ndarray is in the fused type produces RuntimeError: implement_array_function method already has a docstring.
The gist includes the source code for building numfoo, and a short test script to demonstrate the behavior:
import numfoo
import numpy as np

data = [1.2, 2.4]

# The data are a plain list
print(data)

# Invoking the fused function explicitly with a list works
print(numfoo.make_array[list](data))

# convert it into a NumPy array
data = np.array(data)

# Invoking the fused function explicitly with an np.ndarray works
print(numfoo.make_array[np.ndarray](data))

# This fails
print(numfoo.make_array(data))

This does not happen with an earlier NumPy version, it does not happen with a newer version of Python, and it does not appear to happen on Windows. That it blows up inside the fused function dispatch machinery but with seemingly an initialization-like problem in NumPy makes it hard to tell where I should be reporting this bug.
Note: Compilation was does using Cython 0.29.7

From reviewing the C code template for fused functions, I can't tell where the actual type testing takes place. Is there a place other than /Cython/Utility/CythonFunction.c I should be looking?
Thank you.

I could reproduce the error before, but cannot right now with cython3.0a0 and numpy 1.16.2 (not 100% sure what my previous numpy version was, but I expect it was identical). I closed the numpy issue for now, and think it is likely this can be closed as well, but maybe @mobiusklein can/wants to check?


require bulma in example only

Codecov Report

Merging #1531 into dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev    #1531   +/-   ##
=======================================
  Coverage   87.13%   87.13%
=======================================
  Files          14       14
  Lines         917      917
=======================================
  Hits          799      799
  Misses        118      118

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 8dd1bfe...5f60b23. Read the comment docs.

Thanks @motia


Descriptor checksum

This implements sum check when parsing descriptors with a checksum, and Display them along with their checksum.
The big diff is due to the first refactoring commit which moves the descriptor key logic which accumulated in mod to a new key submodule.
Fixes https://github.com/rust-bitcoin/rust-miniscript/issues/195

Fixed 1.29, fuzzing roundtrip and rebased on master.

Following up on https://github.com/rust-bitcoin/rust-miniscript/issues/195#issuecomment-734029683, is it expected that non-canonically-encoded descriptors won't retain their original checksum?
For example, Descriptor::<DescriptorPublicKey>::from_str("wpkh([aabbccdd/1h]tpubD6N..H2eA)#2p83t04l").unwrap().to_string() == "wpkh([aabbccdd/1']tpubD6N..H2eA)#e7asl9q4".
This could be problematic if the checksum if used as an identifier for the descriptor that is expected to remain stable. In bwt I ended up rejecting checksummed descriptors that aren't canonically encoded, because it seemed too strange for the user to explicitly provide a checksum and then get a different one back out.
I don't really have good suggestions for how to handle this, just thought its worth bringing up. I guess that one solution is to avoid using the checksum as a stable identifier, and require users to provide an explicit identifier label instead.
Looking at Bitcoin Core's getdescriptorinfo, it appears that its also similarly normalizing the descriptor to its canonical representation, but also provides the checksum for the original descriptor as a separate field:
$ bitcoin-cli -regtest getdescriptorinfo 'wpkh([aabbccdd/1h]tpubD6NzVbkrYhZ4XJDrzRvuxHEyQaPd1mwwdDofEJwekX18tAdsqeKfxss79AJzg1431FybXg5rfpTrJF4iAhyR7RubberdzEQXiRmXGADH2eA)#2p83t04l'
{
  "descriptor": "wpkh([aabbccdd/1']tpubD6NzVbkrYhZ4XJDrzRvuxHEyQaPd1mwwdDofEJwekX18tAdsqeKfxss79AJzg1431FybXg5rfpTrJF4iAhyR7RubberdzEQXiRmXGADH2eA)#e7asl9q4",
  "checksum": "2p83t04l",
  ...
}

There's some related discussion at https://github.com/bitcoin/bitcoin/issues/15740.
I also noticed that desc_checksum was not made public for consumers of the library. Was this intentional? Without direct access to it, it is currently impossible to compute the checksum of non-canonical descriptors.

Just read the IRC backlog, so to summarize what was already hashed there (and i agree with).

It's expected that non-canonically-encoded descriptors won't retain their original checksum. I think it makes more sense to keep original checksums, but being bitcoin-core-compatible is imo the Right Thing to do for now.
I don't think we should use checksums as stable identifiers, and that what was proposed on #miniscript yesterday is more desirable.
It was intentional to not expose desc_checksum, but this i can fix :)


Feature Request Load unload Filament and status

Hello, would be cool if we can have an action to load and unload filament not only ams also the extra filament which is connected for example with splitter.
My idea is to have a "mico" ams for tpu with the splitter:

This sould be filament pullback


Df maturitymodel

Please use this template to ensure easier processing of your pull request
Category

[x ] Content fix
[ ] New article

Docs Build status updates of commit 590b37e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Community/index.yml
:white_check_mark:Succeeded
View

Community/TOC.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Immediately rejected Promise kills the kernel

Hi there, loving the kernel so far! It works great with Node6 and has made presentations a breeze.
One small snag, despite best efforts catching Promise rejections, the kernel seems to die unless a setTimeout is involved. Examples!
this works:
var getHamburgerMaybe = new Promise((resolve, reject) => {
    setTimeout(() => reject("[OutOfMeatException] Where's the beef?"), 3000);
});

getHamburgerMaybe.catch(error => console.log(error));

this kills the kernel:
const p = new Promise((resolve, reject) => {
    reject();
})
.then(
    () => {
        console.log('Promise fulfilled.');
    },
    () => {
        console.log('Promise rejected');
    }
)

Any thoughts?

I just upgraded to use vm instead of contextify, and it looks like this is working now?

Ahh great, it works now! Thanks for looking into it 👍

Ahh great, it works now! Thanks for looking into this 👍


Handle missing attributes

Fixing #126. I used https://github.com/ggtracker/sc2reader/blob/e22cb674ad148de53e32775681a9c097c79766e6/sc2reader/scripts/sc2attributes.py to generate a new attributes.json, but it actually still didn't get the values we needed, so I just caught the KeyError if it is missing.

I figured out my mistake: I played the co-op game but didn't open the Game Summary from my Match History. I was able to get a bunch more data in there. However, it does appear that I'll need to play with all of the commanders to make sure I cover my bases, so I'll get on that soon.

I played a game with all commanders and opened up the score screens and didn't add any more entries, so hopefully this is sufficient


DOC: Clean up README

I added some badges, simplified some text, and made it more compact so that it is easier to view and find information.

Regarding the badges while they are useful for other projects, I think they don't serve any purpose for SciPy, because code is thoroughly tested before merges and the badges have some refresh delay, probably any failure would be fixed before they get updated.

I am not sure what you mean by "code is thoroughly tested before merges".  Isn't that standard practice for projects using automated testing of PRs?  Does SciPy do some extra level of testing that other projects (like NumPy, matplotlib, scikit-learn, scikit-image, networkx, etc.) don't?
I like badges in the READMEs of projects because it is an easy and compact way of letting visitors see what integration services you are using for the passing bits also the coverage report is nice.  They don't take up much space and provide a quick sense of new visitors of the extent to which the project is tested without having to dig into the documentation or look at configuration files.  For developers, it provides a convenient location for finding links to the various integration systems used for projects.
I am not sure what you like about the Pandas README.  Are you pointing to it as a example of inserting a logo in a README?  Or is there something else about their README you like?  Personally, I find their README a bit too long and uses too much vertical space making it difficult to get a quick visual overview.
If you want me to insert the logo, I can do the same thing I did for NumPy:
https://github.com/numpy/numpy/blob/master/README.md
I found this logo:
https://github.com/scipy/scipy/blob/master/doc/source/_static/scipyshiny_small.png
However, it would be better if there was a banner style logo like the one I used for NumPy.  (Personally, I prefer just having a plain text "logo", but I don't have a strong opinion.)

I mean, seeing a build:passing badge wouldn't say much, I am not sure about its purpose. I don't think anybody would leave it in a build:failing state especially SciPy scaled projects so having another badge seems redundant to me but I also don't have any strong opinion about them.
For the integration services yes indeed that might be a message. We can still have those as you said they don't take up any space. There are more examples here : http://shields.io/
Pandas example was for the logo example and the badge table layout. Instead of leaving them inline without any frames, maybe we can also confine them into proper layout

I used the badges from http://shields.io/ already so that the badge don't just say build:passing, but Travis CI: passing, AppVeyor: passing, and CircleCI: passing.
I don't see any advantage to using a table layout like pandas did.

I have no opinion on the badges, but it does look simpler and less verbose to me.

I'm also +1 for this change. Less text, same content, gets the job done.

If nobody else shares my opinion about the badges, then let's get it in 😃

https://github.com/jarrodmillman/scipy/tree/readme-cleanup looks like a significant improvement over the current README, and I'm fine with the badges.

Oh and welcome back @jarrodmillman !

In it goes then.


Add authentication layer for transferd

transferd currently connects directly to the socket created by the other transferd process. For secure communication, authentication of the connection should be performed, e.g. using PKI with mutual TLS, just like what is done in Guardian.
Encryption of the channel is technically not necessary.
This can be achieved by adding an encrypted classical channel negotiated by an SSL package, e.g. authd. This authd has two sockets, one internal that acts as a proxy for transferd, and one external to communication with the other authd.

Flow can be as such:

One side starts QKDServer, whose transferd will connect directly to the internal socket opened by authd.
authd will attempt to connect to the specified external socket as an SSL client (fails since the other side does not have authd running yet)
authd creates and listens on its specified socket (as a server).
The other side starts QKDServer - authd makes a connection to the first authd using mutual TLS authentication.
transferd writes to the internal socket, which authd will act as a tunnel to the other socket that the other transferd listens to.

Alternative to this flow is to have a server + client running for each QKDServer instance, which is kind of pointless since both the server and client can transmit messages within the same connection.

The nice thing about this is it indirectly solves #3, since transferd will have an internal socket (provided by authd) to latch onto immediately without timing out.

Fixed with addition of authd, see #1.


first_professor should actually try to find a professor, rather than just looking at the first one.

Where does this get affected in the app on the user-end? Change seems fine, but I don't understand what we're changing.

Some courses have their first professor as "Staff" or "TBA" even though they have other professors that are "real". So on the course show page, it will show "Staff" for the main professor even though we totally have a better professor to show.
Change is here

As a side note, I'm using that real_professors method in the tips and reviews stuff (PR coming soon), so I want that to stay regardless.


codewide: Allow setting Serial,LocalSerial for Consistency

Motivation
See #736.
What's done

Consistency is extended with Serial and LocalSerial to support reading using Paxos (SELECT statements),
LegacyConsistency is removed altogether,
a test is added that performs such a Paxos read.

Fixes: #736
Pre-review checklist

[x] I have split my patch into logically separate commits.
[x] All commit messages clearly explain what they change and why.
[x] I added relevant tests for new features and bug fixes.
[x] All commits compile, pass static checks and pass test.
[x] PR description sums up the changes and reasons why they should be introduced.
[ ] I have provided docstrings for the public items that I want to introduce.
[ ] I have adjusted the documentation in ./docs/source/.
[x] I added appropriate Fixes: annotations to PR description.

implemented thiserror::Error as requested,
rebased.


Allow doc comments to be written inside explicit types

Currently the parser only produces an ArcType (the same type used in typechecking) when parsing types. This makes it impossible to write documentation comments inside type defintions and type declarations of bindings which are both useful cases.
type Monoid m = {
    /// * Known as `mappend` in Haskell
    append : m -> m -> m,
}

cc #319

Closed by #324


Github logo changed into a ribbon

Related Issue or bug
Fixes: #42
Changes I've made
I have added a ribbon in the top right corner of the header. It clearly describes the "GITHUB" repository link. The earlier button was somewhat camouflaging with the background. Hence I have used a classic red gradient which is going with the website's theme to make it a little bit attractive.
Putting it on the left side would have been a bit uncomfortable in terms of UI as the scroll bar would be just adjacent to the ribbon end and it would have had an incomplete or a discontinuos feel.
Type of change

[ ] New feature (non-breaking change which adds functionality)
[x] Code style update (formatting, local variables)

Checklist:

[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] My changes generate no new warnings.
[x] New and existing unit tests pass locally with my changes.
[x] Any dependent changes have been merged and published in downstream modules.

Screenshots

Original
Updated

Align the Github Ribbon on the right side of the website.
Use the Github logo instead of Text GITHUB, if possible use SVG.
Make sure that the website is responsive after your changes.

@abby3010 You can view this website for the Github Iogo I'm trying to say: https://30daysofjs.netlify.app/


Unable to federate matrix synapse using NPM

Checklist

Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?

Yes

Are you sure you're not using someone else's docker image?

Yes

Have you searched for similar issues (both open and closed)?

Yes

Describe the bug
Would I consider this a bug? I'm not sure but I have searched everywhere else, including posting on reddit, and am unable to find an answer so this is my last resort. If this is the wrong place I apologize.
A few details, I am using a subdomain, matrix.minnix.dev, for the actual matrix server and my homeserver.yaml lists my parent domain as minnix.dev so that my user name looks like<EMAIL_ADDRESS>within matrix instead of<EMAIL_ADDRESS>I had a configuration working quite well just using plain nginx as a reverse proxy in front of my matrix server. I actually wrote a guide about the process here. I can't get NPM to do the same thing though as I am failing the federation test here. My self-hosted matrix rooms are still available to other users and they can communicate with each other but they cannot see my communications and when I search for other rooms I get the message "Failed to fetch room list"
My old proxy configs looked like this before installing NPM:
For the matrix server-
    server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        # For the federation port
        listen 8448 ssl http2 default_server;
        listen [::]:8448 ssl http2 default_server;

        server_name matrix.minnix.dev;

        location ~* ^(\/_matrix|\/_synapse\/client) {
            proxy_pass http://<IP_ADDRESS>:8008;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header Host $host;

            # Nginx by default only allows file uploads up to 1M in size
            # Increase client_max_body_size to match max_upload_size defined in homeserver.yaml
            client_max_body_size 50M;
        }

    }

And for my parent domain-
    server {

            server_name minnix.dev;

         location /.well-known/matrix/server {
         return 200 '{"m.server": "matrix.minnix.dev:443"}';
         default_type application/json;
         add_header Access-Control-Allow-Origin *;

    }

         location /.well-known/matrix/client {
         return 200 '{"m.homeserver": {"base_url": "https://matrix.minnix.dev"}}';
         default_type application/json;
         add_header Access-Control-Allow-Origin *;

      }

    }

I have a feeling this can all be done with a single config as that's all that's listed within the official synapse documentation here
For the record I added these lines to the advanced tab to try and enable federation with no change:
listen 8448 ssl http2 default_server;
listen [::]:8448 ssl http2 default_server;

I have transferred 12 other servers over to NPM without issue including Mastodon and Peertube which are federated, but matrix is not working for me.
Nginx Proxy Manager Version
v2.9.15
Expected behavior
Passing the federation test
Operating System
Armbian Focal Ubuntu server running on Rock64

I just had this same issue.  I ended up hosting the /.well-known/matrix/server file.  Here is my example one  https://gitlab.autiboystech.com/-/snippets/1 .  Under nginx proxy I went to my domain name and did a custom location.  I set the location to /.well-known/matrix/server  and the scheme to http.  The url I set to gitlab-ce/-/snippets/1/raw/main/matrix_server (my gitlab docker container).  The port I set to 80 as that is the port gitlab runs on.

Where should I put the /.well-known/matrix/server file since I am running matrix natively on its own machine and not through docker and I am not running nginx or NPM on the matrix server itself? I'm assuming my file should look like this:
{
    "m.server": "matrix.minnix.dev:443"
}

You could use a github gist.  At least thats what I would do and yes the above is what your file should look like.

All you need is some type of url to a raw file.

Ok I wasn't thinking straight. For some reason I thought it had to be on the matrix server itself. I'll host it on my blog and see what happens.

When you get it to work be sure to close this and mark a solution.

I tried it using a github gist and it doesn't work. Proxy host shows as offline whenever I hit save. I chose /.well-known/matrix/server as my location and for the second part scheme is https, forward hostname is https://gist.githubusercontent.com/minnixtx/18b65147c9293764add5350eb21e264a/raw/3c790731393885dd0667fd6ad4afd397f1cf75e4/matrix_server and port is 443.

Ok here's what worked for me:
1.Create a proxy host for matrix.minnix.dev
Domain: matrix.minnix.dev
Scheme: http
Hostname: <IP_ADDRESS>
Port: 8008
Under the advanced tab:
listen 8448 ssl http2 default_server;
listen [::]:8448 ssl http2 default_server;

Get SSL cert

Create a proxy host for my parent domain minnix.dev

Domain: minnix.dev
Scheme: http
Hostname: <IP_ADDRESS>
Port: 8008
Under the Advanced tab:
location /.well-known/matrix/server {
     return 200 '{"m.server": "matrix.minnix.dev:443"}';
     default_type application/json;
     add_header Access-Control-Allow-Origin *;

}

     location /.well-known/matrix/client {
     return 200 '{"m.homeserver": {"base_url": "https://matrix.minnix.dev"}}';
     default_type application/json;
     add_header Access-Control-Allow-Origin *;

  }

Get SSL cert

The gist didn't work as your file was in the incorrect format

thanks for this solution, but i dont seem to get it working that i can proxy host my matrix server on my matrix subdomain. how did you solve it with the custom paths? I just dont get it working.

Are you using nginx?

Are you using nginx?

I host the matrix on my home server, which is connected to my VPS via a VPN. I would like to use NPM without a extra Nginx server, but if that isnt possible it's going to make things harder for me.

Ok so I had all my stuff in docker.  NPM comes with nginx by default so your good there.  Do you have anything setup in NPM yet?  Also what exactly isn't working and did you look at this https://github.com/spantaleev/matrix-docker-ansible-deploy ?/issues/1687

The problem is that i don't know how to make the correct settings for it to work in NPM. Do you know how? Would be nice if you could contact me ^^ (discord: AroPix#2632)

I do now how to help you I just need to find my document I had.

(he helped me and it wasnt a fault of npm, rather a misconfigured matrix server)

@czadikem @AroPix are you able to share the document and misconfigurations?


Error in install and can build my Os distributions only and can't build another distributions

Error in install and can't build another distributions
First Error when Package installation

npm WARN prefer global<EMAIL_ADDRESS>should be installed with -g

npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN<EMAIL_ADDRESS>No license field.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/7zip-bin/node_modules/7zip-bin-mac):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/7zip-bin/node_modules/7zip-bin-win):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"win32","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN<EMAIL_ADDRESS>No repository field.

Second Error when Build Package
Building AppImage for arch x64
Error: Exit code: ENOENT. spawn icns2png ENOENT
    at /media/emad/DevExe/electron/my-project/node_modules/electron-builder-util/src/util.ts:75:16
    at exithandler (child_process.js:218:5)
    at ChildProcess.errorhandler (child_process.js:230:5)
    at emitOne (events.js:96:13)
    at ChildProcess.emit (events.js:188:7)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:213:12)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
From previous event:
    at exec (/media/emad/DevExe/electron/my-project/node_modules/electron-builder-util/src/util.ts:53:3)
    at /media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/targets/LinuxTargetHelper.ts:136:28
    at Generator.next (<anonymous>)
    at runCallback (timers.js:649:20)
    at tryOnImmediate (timers.js:622:5)
    at processImmediate [as _immediateCallback] (timers.js:594:5)
From previous event:
    at LinuxTargetHelper.createFromIcns (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/out/targets/LinuxTargetHelper.js:186:11)
    at /media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/targets/LinuxTargetHelper.ts:28:25
From previous event:
    at LinuxTargetHelper.computeDesktopIcons (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/out/targets/LinuxTargetHelper.js:58:11)
    at new LinuxTargetHelper (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/targets/LinuxTargetHelper.ts:16:23)
    at getHelper (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/linuxPackager.ts:32:18)
    at outDir (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/linuxPackager.ts:61:122)
    at mapper (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/targets/targetFactory.ts:15:16)
    at LinuxPackager.createTargets (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/linuxPackager.ts:61:7)
    at createTargets (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/targets/targetFactory.ts:22:12)
    at /media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/packager.ts:175:41
From previous event:
    at Packager.doBuild (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/out/packager.js:299:11)
    at /media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/packager.ts:143:38
    at Generator.next (<anonymous>)
    at runCallback (timers.js:649:20)
    at tryOnImmediate (timers.js:622:5)
    at processImmediate [as _immediateCallback] (timers.js:594:5)
From previous event:
    at Packager.build (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/out/packager.js:251:11)
    at /media/emad/DevExe/electron/my-project/node_modules/electron-builder/src/builder.ts:214:40
    at Generator.next (<anonymous>)
From previous event:
    at build (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/out/builder.js:63:21)
    at Object.<anonymous> (/media/emad/DevExe/electron/my-project/node_modules/electron-builder/out/cli/build-cli.js:68:41)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)
    at run (bootstrap_node.js:420:7)
    at startup (bootstrap_node.js:139:9)
    at bootstrap_node.js:535:3

npm ERR! Linux 4.8.0-41-generic
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "build"
npm ERR! node v7.2.0
npm ERR! npm  v4.0.2
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>build: `npm run pack && build`
npm ERR! Exit status 255
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build script 'npm run pack && build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the my-project package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm run pack && build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs my-project
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls my-project
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /media/emad/DevExe/electron/my-project/npm-debug.log

and stop building, when open dist folder i found only linux-unpacked
Tell me about your development environment.

Node version: 7.2.0
NPM version: 4.0.2
vue-cli version: (if necessary)
Operating System: Ubuntu 16.10 for 46-bit
In package (You are using electron v1.6.2 with node v7.4.0 on the linux platform.)

Thanks in advance

https://github.com/electron-userland/electron-builder/wiki/Multi-Platform-Build#linux
sudo apt-get install --no-install-recommends -y icnsutils graphicsmagick xz-utils

Thanks so much my dear
Still Installation errors
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/7zip-bin/node_modules/7zip-bin-mac):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/7zip-bin/node_modules/7zip-bin-win):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"win32","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN<EMAIL_ADDRESS>No repository field.

windows build
When build by npm run build --win not have build dist for win but build dist for Linux, that is done without any errors.
how can build to windows ? and what about installation errors ?

Thanks @SimulatedGREG
Solved problem and now i can build to windows and  mac  from  linux by using electron-builder through install prebuild as globally
$ npm install -g prebuild

and also add build-all to package.json
"scripts": {
    ...
    "build-all": "npm run pack &&build -mwl",
    ...
}

Never seen prebuild before; looks pretty interesting. Glad you got this sorted out.

Followed your instructions, @EmadAdly, got this:

Error: spawn hdiutil ENOENT
at exports._errnoException (util.js:1050:11)
at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
at onErrorNT (internal/child_process.js:367:16)
at _combinedTickCallback (internal/process/next_tick.js:80:11)
at process._tickCallback (internal/process/next_tick.js:104:9)
From previous event:
at spawn (/home/jclaus/Entwicklung/itl/node_modules/electron-builder-util/src/util.ts:118:3)
at /home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/targets/dmg.ts:49:11
at Generator.next ()
at /home/jclaus/Entwicklung/itl/node_modules/graceful-fs/graceful-fs.js:99:16
at /home/jclaus/Entwicklung/itl/node_modules/graceful-fs/graceful-fs.js:43:10
at FSReqWrap.oncomplete (fs.js:114:15)
From previous event:
at DmgTarget.build (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/targets/dmg.js:233:11)
at taskManager.addTask.default.map.it (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/platformPackager.ts:106:85)
From previous event:
at MacPackager.packageInDistributableFormat (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/platformPackager.ts:106:41)
at /home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/macPackager.ts:94:26
From previous event:
at /home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/macPackager.ts:94:10
at Generator.next ()
From previous event:
at MacPackager.pack (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/macPackager.js:190:11)
at /home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/packager.ts:253:24
From previous event:
at Packager.doBuild (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/packager.js:340:11)
at /home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/packager.ts:184:52
at Generator.next ()
From previous event:
at Packager.build (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/packager.js:259:11)
at /home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/builder.ts:266:40
at Generator.next ()
at build (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/builder.js:69:21)
at loadEnv.then (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/src/cli/cli.ts:49:4)
From previous event:
at build (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/builder.js:69:21)
at loadEnv.then (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/cli/cli.js:155:79)
at runCallback (timers.js:672:20)
at tryOnImmediate (timers.js:645:5)
at processImmediate [as _immediateCallback] (timers.js:617:5)
From previous event:
at Object.args [as handler] (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/cli/cli.js:155:68)
at Object.self.runCommand (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/node_modules/yargs/lib/command.js:233:22)
at Object.Yargs.self._parseArgs (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/node_modules/yargs/yargs.js:1018:24)
at Object.get [as argv] (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/node_modules/yargs/yargs.js:927:19)
at Object. (/home/jclaus/Entwicklung/itl/node_modules/electron-builder/out/cli/cli.js:151:465)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
at Module.runMain (module.js:605:10)
at run (bootstrap_node.js:427:7)
at startup (bootstrap_node.js:151:9)
at bootstrap_node.js:542:3


TERRAN_COMMANDCENTER data is not filled on game start

I have the following code very similar to the tutorial. The code must limit the number of SCVs built for a particular command center:
virtual void OnUnitIdle(const sc2::Unit* unit) final {
    switch (unit->unit_type.ToType()) {
        case sc2::UNIT_TYPEID::TERRAN_COMMANDCENTER: {
            if (unit->assigned_harvesters < unit->ideal_harvesters)
                Actions()->UnitCommand(unit, sc2::ABILITY_ID::TRAIN_SCV);
            break;
        }
....
        default: {
            break;
        }
    }
}

However when the game starts only starts and OnUnitIdle is triggered the TERRAN_COMMANDCENTER unit structure is not filled properly, e.g.:
    frame #0: 0x000000010000bac3 Suvorov`Bot::OnUnitIdle(this=0x00007fff5fbff5a0, unit=0x0000000102e08c10) + 83 at Bot.h:38
   35   virtual void OnUnitIdle(const sc2::Unit* unit) final {
   36       switch (unit->unit_type.ToType()) {
   37           case sc2::UNIT_TYPEID::TERRAN_COMMANDCENTER: {
-> 38               if (unit->assigned_harvesters < unit->ideal_harvesters)
   39                   Actions()->UnitCommand(unit, sc2::ABILITY_ID::TRAIN_SCV);
   40               break;
   41           }
(lldb) p *unit
(const sc2::Unit) $0 = {
  display_type = Visible
  alliance = Self
  tag =<PHONE_NUMBER>
  unit_type = (type_id_ = 18)
  owner = 1
  pos = (x = 26.5, y = 137.5, z = 11.9960938)
  facing = 3.92529726
  radius = 2.75
  build_progress = 1
  cloak = NotCloaked
  detect_range = 0
  radar_range = 0
  is_selected = false
  is_on_screen = true
  is_blip = false
  health = 1500
  health_max = 1500
  shield = 0
  shield_max = 0
  energy = 0
  energy_max = 0
  mineral_contents = 0
  vespene_contents = 0
  is_flying = false
  is_burrowed = false
  weapon_cooldown = 0
  orders = size=0 {}
  add_on_tag = 0
  passengers = size=0 {}
  cargo_space_taken = 0
  cargo_space_max = 0
  assigned_harvesters = 0
  ideal_harvesters = 0
  engaged_target_tag = 0
  buffs = size=0 {}
  is_powered = false
  is_alive = true
  last_seen_game_loop = 0
}

All the data are in place on the next 'OnUnitIdle' so I can check the limits with the following workaround:
virtual void OnUnitIdle(const sc2::Unit* unit) final {
    switch (unit->unit_type.ToType()) {
        case sc2::UNIT_TYPEID::TERRAN_COMMANDCENTER: {
            if (unit->assigned_harvesters == 0 ||
                    unit->assigned_harvesters < unit->ideal_harvesters) {
                Actions()->UnitCommand(unit, sc2::ABILITY_ID::TRAIN_SCV);
            }

            break;
        }
....
        default: {
            break;
        }
    }
}

Is such behaviour intended? That looks like a race (the game info is not fully initialised at the moment of the event).

No units have been given commands yet on onStart(), I think you have to wait until an onStep() has been called

The main problem here is that ideal_harvesters is zero which us not related to the number of units if I not mistaken. Another problem: if you write the bot in that way the idle callback will be fired only once for the command center i.e. when there are only zeroes.

I believe ideal_harvesters is based on the number of minerals near the depot, so it cannot be determined before OnStart() has been called. You still probably have to wait until the first OnStep

No units have been given commands yet on onStart(), I think you have to wait until an onStep() has been called
Could be because onStep is triggered after OnUnitIdle when game starts. This is a minor issue anyway.

OnGameStart should be issued before any of the other events. This does seem wrong to me, it could be that the observation gathered at game loop 0 just doesn't have the necessary data for ideal_harvesters. I can look into this one today. I feel like assigned_harvesters might take a game loop to show up but I would have thought ideal_harvesters would be immediately filled out.

I’ve checked it in the debugger, the current event order is: 1 - onGameStart, 2 - onUnitIdle, 3 - onStep. That looks like a correct order.

This turned out to be a bug in an engine. Essentially these values were not properly set on game loop 0. I've added the necessary fix and this code should work as you expect it for both assigned_harvesters and ideal_harvesters for game loop 0 after our next patch goes live.

Thank you! Glad to hear.