AddressSanitizer: stack-overflow jerry-core/vm/vm.c:975 in vm_loop

JerryScript commit hash
55acdf2048b390d0f56f12e64dbfb2559f0e70ad
Build platform
Ubuntu 20.04 LTS
Build steps
python3 tools/build.py --debug --compile-flag=-fsanitize=address

poc
unction assertThrows(code, type_opt, cause_opt) {
    if (typeof code === 'function')
        return code();
    if (typeof code === 'string')
        return eval(code);
}
var global = this;
global.__defineSetter__('x', function (v) {
    x = v;
});
assertThrows('global.x = 0', RangeError);

asan log
AddressSanitizer:DEADLYSIGNAL
=================================================================
==503383==ERROR: AddressSanitizer: stack-overflow on address 0x7fff9e2c6e28 (pc 0x558b17c76d5a bp 0x7fff9e2c75c0 sp 0x7fff9e2c6e10 T0)
    #0 0x558b17c76d59 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:975
    #1 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #2 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #3 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #4 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #5 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #6 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #7 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #8 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #9 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #10 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #11 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #12 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #13 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #14 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #15 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #16 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #17 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #18 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #19 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #20 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #21 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #22 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #23 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #24 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #25 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #26 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #27 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #28 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #29 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #30 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #31 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #32 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #33 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #34 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #35 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #36 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #37 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #38 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #39 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #40 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #41 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #42 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #43 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #44 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #45 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #46 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #47 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #48 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #49 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #50 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #51 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #52 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #53 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #54 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #55 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #56 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #57 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #58 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #59 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #60 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #61 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #62 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #63 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #64 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #65 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #66 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #67 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #68 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #69 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #70 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #71 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #72 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #73 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #74 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #75 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #76 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #77 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #78 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #79 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #80 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #81 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #82 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #83 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #84 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #85 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #86 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #87 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #88 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #89 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #90 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #91 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #92 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #93 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #94 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #95 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #96 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #97 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #98 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #99 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #100 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #101 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #102 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #103 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #104 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #105 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #106 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #107 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #108 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #109 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #110 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #111 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #112 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #113 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #114 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #115 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #116 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #117 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #118 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #119 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #120 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #121 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #122 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #123 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #124 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #125 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #126 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #127 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #128 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #129 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #130 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #131 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #132 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #133 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #134 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #135 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #136 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #137 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #138 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #139 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #140 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #141 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #142 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #143 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #144 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #145 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #146 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #147 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #148 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #149 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #150 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #151 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #152 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #153 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #154 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #155 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #156 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #157 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #158 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #159 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #160 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #161 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #162 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #163 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #164 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #165 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #166 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #167 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #168 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #169 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #170 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #171 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #172 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #173 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #174 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #175 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #176 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #177 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #178 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #179 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #180 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #181 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #182 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #183 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #184 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #185 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #186 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #187 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #188 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #189 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #190 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #191 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #192 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #193 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #194 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #195 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #196 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #197 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #198 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #199 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #200 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #201 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #202 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #203 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #204 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #205 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #206 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #207 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #208 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #209 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #210 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #211 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #212 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #213 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #214 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #215 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #216 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #217 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #218 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #219 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #220 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #221 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #222 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #223 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #224 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #225 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #226 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #227 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #228 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #229 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #230 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #231 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #232 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #233 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #234 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #235 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #236 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #237 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #238 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #239 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #240 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751
    #241 0x558b17c93b85 in vm_execute /home/sakura/jerryscript/jerry-core/vm/vm.c:5260
    #242 0x558b17c9420b in vm_run /home/sakura/jerryscript/jerry-core/vm/vm.c:5363
    #243 0x558b17bf620f in ecma_op_function_call_simple /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1203
    #244 0x558b17bf6d93 in ecma_op_function_call /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-function-object.c:1439
    #245 0x558b17c06014 in ecma_op_object_put_with_receiver /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1677
    #246 0x558b17c04680 in ecma_op_object_put /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-objects.c:1197
    #247 0x558b17cd378e in ecma_op_put_value_lex_env_base /home/sakura/jerryscript/jerry-core/ecma/operations/ecma-get-put-value.c:293
    #248 0x558b17c913e8 in vm_loop /home/sakura/jerryscript/jerry-core/vm/vm.c:4751

SUMMARY: AddressSanitizer: stack-overflow /home/sakura/jerryscript/jerry-core/vm/vm.c:975 in vm_loop

poc2

(function () {
    try {
        Function("this.__defineGetter__(\"x\",(Function(\"for(z=0;z<6;z++)(x)\")))")();
    } catch (e) {
    }
}()(function f(d, aaaaaa) {
    if (bbbbbb = aaaaaa) {
        x;
    }
    f(bbbbbb, aaaaaa + 1);
}([], 0)));

Closing the issue, see #4866 comment.


Orchestrate CockroachDB with Docker Swarm Doc Update

Re: Orchestrate CockroachDB with Docker Swarm
Issue Description
The instructions to create a client certificate are very subtly, just a short phrase with link under section 5, bullet 5.
Suggested Resolution
Since we have a sample cockroach sql invocation, we should have a specific step to create a client certificate as well.

Make sure to also add an explanation on how to use the required parameter --ca-key= inside of the container since the ca key is to be kept secret and I guess outside of the container because of that. Maybe move it inside temporarily and delete it afterwards? I'm new to this so just giving random suggestions here.

Also take into consideration that /run/secrets are read-only
root@fe71ca7e5a87:/cockroach# ./cockroach cert create-client --certs-dir=/run/secrets --ca-key=/root/ca.key root
Error: failed to generate client certificate and key: error writing node server certificate to /run/secrets/client.root.crt: open /run/secrets/client.root.crt: read-only file system
Failed running "cert"

So if the root certificate is created inside one of the cockroachdb docker containers it should afterwards be exported and added as a secret.

The certificates are passed to the containers through the secrets mechanism. You should do the same for the client certificate: generate it outside the container, and specify it through secrets.
Copying the ca key onto the containers is a big no-no.
You probably don't need client certificates on the cockroach container either. Whatever client you're using should be running either outside docker swarm entirely, or in its own containers with their own secrets.

Thanks for the input, I deleted the comments since I realized this when reading the guide once again.


ASU-130 | Customer create and update API

Implemented APIs for creating and updating customers. New Profiles are created for every new Customer, ie. it is not possible to select an already existing Profile when creating a new Customer. Also, when updating a Customer, the related Profiles are updated, and it is not possible to change the Profiles to other Profiles.
Partial update (HTTP PATCH) is disabled for now, because it would make the update logic more complicated, and it is still unclear whether it is actually needed or not.
Example requests and responses
Create request
POST /v1/sales/customers/
{
	"additional_information": "",
	"created_at": "2022-02-11T11:40:24.913175+02:00",
	"has_children": true,
	"has_hitas_ownership": null,
	"is_age_over_55": null,
	"is_right_of_occupancy_housing_changer": null,
	"last_contact_date": null,
	"primary_profile": {
		"first_name": "Jurtti",
		"last_name": "Juonio",
		"email"<EMAIL_ADDRESS>		"phone_number": "243335234",
		"national_identification_number": "111271-111A",
		"street_address": "Jokutie 5 D",
		"postal_code": "24523",
		"city": "Helsinki",
		"contact_language": "fi",
		"date_of_birth": "2021-01-01"
	},
	"secondary_profile": null,
	"right_of_residence": 123
}

Create response
HTTP 201
{
	"id": 20,
	"additional_information": "",
	"created_at": "2022-03-04T08:46:18.150364+02:00",
	"has_children": null,
	"has_hitas_ownership": null,
	"is_age_over_55": null,
	"is_right_of_occupancy_housing_changer": null,
	"last_contact_date": null,
	"primary_profile": {
		"id": "5a7177c5-87c4-41f4-8630-ca86e0de7b75",
		"first_name": "Jurtti",
		"last_name": "Juonio",
		"email"<EMAIL_ADDRESS>		"phone_number": "2435234",
		"national_identification_number": "111271-111A",
		"street_address": "Jokutie 5 D",
		"postal_code": "24523",
		"city": "Helsinki",
		"contact_language": "fi",
		"date_of_birth": "2021-01-01"
	},
	"right_of_residence": 127,
	"secondary_profile": null,
	"apartment_reservations": []
}

Update request
PUT /v1/sales/customers/20/
{
	"additional_information": "updated information",
	"has_children": true,
	"has_hitas_ownership": null,
	"is_age_over_55": false,
	"is_right_of_occupancy_housing_changer": null,
	"last_contact_date": null,
	"primary_profile": {
		"first_name": "Matti",
		"last_name": "Mainio",
		"email"<EMAIL_ADDRESS>		"phone_number": "243335234",
		"national_identification_number": "111271-111A",
		"street_address": "Jokutie 5 D",
		"postal_code": "24523",
		"city": "Helsinki",
		"contact_language": "sv",
		"date_of_birth": "2021-01-01"
	},
	"secondary_profile": null,
	"right_of_residence": 123
}

Update response
HTTP 200
{
	"id": 20,
	"additional_information": "updated information",
	"created_at": "2022-03-04T08:46:18.150364+02:00",
	"has_children": true,
	"has_hitas_ownership": null,
	"is_age_over_55": false,
	"is_right_of_occupancy_housing_changer": null,
	"last_contact_date": null,
	"primary_profile": {
		"id": "5a7177c5-87c4-41f4-8630-ca86e0de7b75",
		"first_name": "Jurtti",
		"last_name": "Mainio",
		"email"<EMAIL_ADDRESS>		"phone_number": "243335234",
		"national_identification_number": "111271-111A",
		"street_address": "Jokutie 5 D",
		"postal_code": "24523",
		"city": "Helsinki",
		"contact_language": "sv",
		"date_of_birth": "2021-01-01"
	},
	"right_of_residence": 123,
	"secondary_profile": null,
	"apartment_reservations": []
}

Codecov Report

Merging #168 (0013526) into develop (2d0f0d0) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #168      +/-   ##
===========================================
+ Coverage    94.83%   94.88%   +0.05%
===========================================
  Files           97       97
  Lines         2767     2798      +31
  Branches       220      224       +4
===========================================
+ Hits          2624     2655      +31
  Misses         106      106
  Partials        37       37

Impacted Files
Coverage Δ

apartment_application_service/utils.py
100.00% <100.00%> (ø)

customer/api/sales/serializers.py
100.00% <100.00%> (ø)

customer/api/sales/views.py
100.00% <100.00%> (ø)

users/api/sales/serializers.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


MemoryLayout(::AbstractArray)

This lets MemoryLayout act on an instance instead of its type, which is (I think) what its docstring says should work.

Thanks!

It's possible this should in fact be ::Any, but I'm not sure? Since MemoryLayout(Float64) is defined.

Yes there are other types than AbstractArray that use this, eg AbstractQuasiArray in QuasiArrays.jl. We can either make the overload Any, or require every type to do this.
Probably the Any approach is fine

Can you add tests too?

Sure, I added very simple ones, should I do something more elaborate?

Oh it’s fine, codecov was being funny but has fixed itsrlf


Azure.Identity returned 401 status code when I used the wrong account to access Azure Blob Storage.

I was trying to use AzCli credential with "Storage Blob data Contributor" role to access Azure Blob Storage with the following code in dev environment:
string blobEndpoint = $"https://{accountName}.blob.core.windows.net";
BlobServiceClient blobServiceClient = new BlobServiceClient(new Uri(blobEndpoint), new AzureCliCredential());
var scriptContainer = blobServiceClient.GetBlobContainerClient(containerName);
await scriptContainer.CreateIfNotExistsAsync();

Then I got the error “Server failed to authenticate the request. Please refer to the information in the www-authenticate header.” with a 401 status code.
Actual behavior
I realized that I had logged in with the wrong account. After I switched the account, everything was good.
Environment:

Azure.Identity 1.3.0
Windows 10 .NET Framework 4.8
Visual Studio 16.8.5

Hi @momoliu-msft.   Could you provide the stack trace that you're seeing as well, please?   From the context, I'm not sure whether this is the return from the storage service due to the invalid credential or this was returned from Azure.Identity when trying to authenticate.    For now, I'll ask @schaabs to offer his thoughts and reroute if necessary.

@momoliu-msft  Thanks for filing this issue. In this case the 401 (Unauthorized) is returned from the storage service, because the account of the token supplied isn't authorized to perform the requested operation. This is the designed behavior of the storage service. Were you expecting a different error? I'm not sure we can do much to provide a better error experience from the client side.

Yeah, the error is returned as expected. Filling the issue here for giving those who may encounter the same problem as me an idea to solve the problem. I will paste the stack trace after I could use the other account to log in and reproduce the error.

Here is the stack trace of the failure:
"ClassName":"System.AggregateException","Message":"One or more errors occurred.","Data":{"IsLogged":true},"InnerException":{"Status":401,"ErrorCode":"InvalidAuthenticationInfo","ClassName":"Azure.RequestFailedException","Message":"Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:15e51a47-b01e-0130-5e95-0fa67e000000
Time:2021-03-02T18:57:56.2861795Z
Status: 401 (Server failed to authenticate the request. Please refer to the information in the www-authenticate header.)
ErrorCode: InvalidAuthenticationInfo
Additional Information:
AuthenticationErrorDetail: Issuer validation failed. Issuer did not match.
Headers:
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: 15e51a47-b01e-0130-5e95-0fa67e000000
x-ms-error-code: InvalidAuthenticationInf
WWW-Authenticate: REDACTED
Date: Tue, 02 Mar 2021 18:57:55 GMT
Content-Length: 402
Content-Type: application/xml
","Data":{"AuthenticationErrorDetail":"Issuer validation failed. Issuer did not match."},"InnerException":null,"HelpURL":null,"StackTraceString":"   at Azure.Storage.Blobs.BlobRestClient.Service.GetUserDelegationKeyAsync_CreateResponse(ClientDiagnostics clientDiagnostics, Response response)\
at Azure.Storage.Blobs.BlobRestClient.Service.GetUserDelegationKeyAsync(ClientDiagnostics clientDiagnostics, HttpPipeline pipeline, Uri resourceUri, KeyInfo keyInfo, String version, Nullable1 timeout, String requestId, Boolean async, String operationName, CancellationToken cancellationToken)\\    at Azure.Storage.Blobs.BlobServiceClient.GetUserDelegationKeyInternal(Nullable1 startsOn, DateTimeOffset expiresOn, Boolean async, CancellationToken cancellationToken)\
at Azure.Storage.Blobs.BlobServiceClient.GetUserDelegationKeyAsync(Nullable1 startsOn, DateTimeOffset expiresOn, CancellationToken cancellationToken)\",\"RemoteStackTraceString\":null,\"RemoteStackIndex\":0,\"ExceptionMethod\":null,\"HResult\":-2146233088,\"Source\":\"Azure.Storage.Blobs\",\"WatsonBuckets\":null},\"HelpURL\":null,\"StackTraceString\":\"   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)\\    at System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification)\
at System.Threading.Tasks.Task`1.get_Result() at...


The Git files function is not work in beta4 sometimes.

My English is not well，But I love Atom.

Thanks for reaching out!
We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us half way :grinning:


Integration with DDL

Use DDL to define space schema in README in tests.

I like the idea about loose coupling, proposed by @knazarov in https://github.com/tarantool/crud/issues/46#issuecomment-705634866. Not sure, whether it should use a space, but the idea in general looks nice.

How #123 and #166 are related to this task (X is part of Y, Z is duplicate of A and so on)?

Proposal
I consider this issue as the task about support of an external schema provider. This proposal describes my vision of API of this external schema provider.
tarantool/ddl is the reference schema provider and in the most cases, where I say 'schema provider', one may assume 'tarantool/ddl'.
Schema provider API
-- Get the full space schema.
--
-- The format of the return value is described in the
-- tarantool/ddl README.
--
-- The plan is to introduce optional `sharding_func` field for a
-- space. If the field exists, the space is considered as sharded.
-- The format of the `sharding_func` field is the same as in the
-- `get_sharding_func()` function.
<schema_provider>.get_schema() -> {
    spaces = <...>
}

-- Get sharding functions for all spaces.
--
-- This information must be in-sync with one returned by
-- the `get_schema()` function.
<schema_provider>.get_sharding_func() -> {
    [space_name] = 'mpcrc32' | 'strcrc32' | 'dot.notation.func' | {body = 'function(key) return <...> end'},
    <...>
}

A schema provider may expose additional functions, which allow to set particular fields:
-- Set sharding function for a space.
--
-- func: 'mpcrc32' | 'strcrc32' | 'dot.notation.func' | {body = 'function(key) return <...> end'}
<schema_provider>.set_sharding_func(space_name, func)

However it is generally out of scope of this proposal.
Schema consumers
A schema consumer code will look like so:
-- Use a provided schema or fail.
if rawget(_G, 'ddl') == nil or _G.ddl.get_schema == nil then
    error('No default schema provider: _G.ddl.get_schema is not available')
end
local schema = _G.ddl.get_schema()

-- If we only need information about sharding functions.
if rawget(_G, 'ddl') == nil or _G.ddl.get_sharding_func == nil then
    error('No default schema provider: _G.ddl.get_sharding_func is not available')
end
local sharding_func_map = _G.ddl.get_sharding_func()

Details about tarantool/crud
In fact, tarantool/crud becomes a schema provider and a schema cunsumer at the same time.
The module provides crud.get_schema(), which just passes execution to _G.ddl.get_schema() if it exists or uses net.box information about space schema otherwise.
It saturates the net.box space schema information with data from _G.ddl.get_sharding_func() if it exists, otherwise say 'strcrc32' about all known spaces.
In other words:
-- Get full space schema.
--
-- The format of the return value is described in the
-- tarantool/ddl README.
--
-- This function returns the schema collected from net.box
-- connections to storages. If there is `_G.ddl.get_sharding_func()`,
-- use its information to fill `sharding_func` fields.
--
-- The function should detect recursion for the case, when
--
--  | _G.ddl = require('crud')
--
-- If the recursion is detected, fall back to the default behaviour:
-- return the net.box based space schema.
crud.get_schema() -> {
    spaces = <...>
}

Follow ups
If this proposal looks good, I think we should introduce <schema_provider>.get_sharding_key() and <schema_provider>.set_sharding_key(space_name, key_part_names) similarly how it is proposed for the sharding functions and use this API in #166.

Several follow ups:

@sharonovd proposes crud.set_schema_provider(<schema provider>) instead of _G.ddl = <schema provider>. Those are not equivalent: my idea was to set a default schema provider for all who needs it (the setting to _G is weird thought, don't know an alternative). Dmitry's idea is to set a schema provider just for crud (which will cover 90% of cases anyway, I guess).
My thought: in fact, we're not obligated to make crud a schema provider and provide crud.get_schema(). Let's do it only if it actually will make the code structured better. We can just make crud the user of <schema provider>.get_schema() and/or <schema provider>.get_sharding_func().

One more thought:
If we'll consider the case, when a user wants schema be collected from storages using net.box, but sharding functions from a schema provider (tarantool/ddl), as a strange wish, which should be implementable, but not necessary in a easy way, we can exclude <schema provider>.get_sharding_func() from the schema provider API.
So, crud will always use <schema provider>.get_schema() if a schema provider is set (as default / for crud). So crud without a schema provider will always use 'strcrc32' as a sharding function.
If a user want to use a custom sharding function, but keep net.box based space schema fetching, it can update its ddl schema according to what net.box reported in its own code.
And, if we'll later found that this case is actually required, we can just add crud.set_sharding_func(space_name, key_part_names) without any relation to the schema provider API.

So now my proposal is the following:

Add crud.set_schema_provider(<schema provider>). Calling it will replace usage of net.box's schema with usage of the schema from the schema provider (so crud will call <schema provider>.get_schema()).
Learn crud to follow sharding_key fields (in space definitions) from the schema provider if it is set (#166).
Learn tarantool/ddl to store and return sharding_func fields (in space definitions) from get_schema().
Learn crud to follow sharding_func fields from the schema provider (if set).

I changed my mind, at least in context of near tasks.
tarantool/ddl is just accessor for an instance local schema, not something like a cluster wide schema provider. So it'll collect router's local database schema when called on a router.
If we'll reconsider tarantool/ddl design together with this task, we'll pass the long way to achieve the not-to-large goal.
So I propose to stick on the simpler plan:

Bless _ddl_sharding_key space as part of the tarantool/ddl API (already done in https://github.com/tarantool/ddl/pull/65).
Introduce the new _ddl_sharding_func space as part of the API (within https://github.com/tarantool/ddl/issues/71).
Support collecting information from those spaces in tarantool/crud (within #166 and https://github.com/tarantool/ddl/issues/71).

And stop on it. At least, for now.

All planned tasks are solved.


Automigrate conversations from local store (prev version) into stateful api (new version)

For mobile we should use smaller font sizes

Animated prototype
https://www.figma.com/proto/lwL5jneveZczAj5RLcLFH2/DIAL-Chat?page-id=0%3A1&type=design&node-id=5846-11399&viewport=-1932%2C-3269%2C0.12&t=fIeGuZuasO1uIakc-1&scaling=min-zoom&starting-point-node-id=2%3A14&mode=design


MOBILE-1870 Added npm commands

Solves issue MOBILE-1870.

This also simplifies setting up the development environment where developers only have to run npm install after cloning the project, given that they have the correct NodeJS version installed. It will then start in the default browser by running npm start.

Closing this since we did some additional changes, more information here: https://tracker.moodle.org/browse/MOBILE-1870
Thanks for your work!


Iban_Stealer is not defined

its not defined this my way how I fixed it
https://github.com/dankor33/TrapStealerPacked/blob/main/builder.py#LL137

Fixed in the newest update

Fixed in the newest update

still broken 😢

Fixed now


crash when used as face-view labeling

I tried to use it as demonstrated in mvs_texturing, but for some meshes it crashes:

I can send the mesh, but I do not see an easy way to dump the mapmap problem to a file to send you the problem.

Hey, I ran into the exact same problem as yours. Did you work it out eventually?

but for some meshes it crashes:

For me, I didn't find out a single working mesh...

Hi there,
I'd be happy tro investigate that. If you send me the mesh and instructions to replicate, I'll take a shot at it (at least under Linux).

Hi there,
I'd be happy tro investigate that. If you send me the mesh and instructions to replicate, I'll take a shot at it (at least under Linux).
Hi, this is one of my meshes that is keep getting the segmentation fault. I have tried it on Linux(Ubuntu) and it works fine on it.
https://drive.google.com/file/d/1nJ9ZDvfvBihSqb-oXHONyZC1fqiuvODk/view?usp=sharing
I tried to debug it for serveral days now. I suspect it's related to some array alignment problems like the link below.
https://stackoverflow.com/questions/62324009/mm256-load-ps-cause-segmentation-fault-with-google-benchmark-in-debug-mode
BTW, I am using MinGW-w64 GCC (10.2.0) as compiler on windows10.

actually, you may not need the mesh. I ran into the same issue in mapmap_demo or mapmap_test.
It always crashed here.

I can't figure out why this can trigger a segmentation fault. After some tries, I changed the line a little bit.
diff --git a/mapmap/source/optimizer_instances/dp_node_solver.impl.h b/mapmap/source/optimizer_instances/dp_node_solver.impl.h
index 63498f8..5f82c87 100644
--- a/mapmap/source/optimizer_instances/dp_node_solver.impl.h
+++ b/mapmap/source/optimizer_instances/dp_node_solver.impl.h
@@ -246,7 +246,8 @@ get_independent_of_parent_costs(
         label_from_offset(node_id, 0);

     /* vector holding costs */
-    _v_t<COSTTYPE, SIMDWIDTH> cost = v_init<COSTTYPE, SIMDWIDTH>();
+    _s_t<COSTTYPE, SIMDWIDTH> test = 0;
+    _v_t<COSTTYPE, SIMDWIDTH> cost = v_init<COSTTYPE, SIMDWIDTH>(test);

     /* retrieve label vector for this offset */
     _iv_t<COSTTYPE, SIMDWIDTH> l = m_node->c_labels->

Then I not longer received the segmentation fault in that line. Instead, I crashed in the few lines below.
    cost = c_unary->supports_enumerable_costs() ?
        v_add<COSTTYPE, SIMDWIDTH>(cost,
        c_unary->get_unary_costs_enum_offset(l_i)) :
        v_add<COSTTYPE, SIMDWIDTH>(cost, c_unary->get_unary_costs(l));

Interesting - so far, I seem to be unable to reproduce it. Can you give me the rough outline of your system (especially CPU and OS) so I can narrow this down to the right instruction set (AVX/2, SSE, ...)?

One further thing to try would be edit all v_load variants in source/vector_math.impl.h so they always use the unaligned intrinsics (loadu). I'll see if I can get my hands on a windows machine to test that.

Interesting - so far, I seem to be unable to reproduce it. Can you name me the CPU you're using so I can narrow this down to the right instruction set (AVX/2, SSE, ...)?

My CPU is Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz (4 CPUs), ~3.6GHz

One further thing to try would be edit all v_load variants in source/vector_math.impl.h so they always use the unaligned intrinsics (loadu). I'll see if I can get my hands on a windows machine to test that.

Just tested it, no luck though.

Surprisingly, I tested mapmap_demo compiled by MVSC and NO SegFault! Though as https://github.com/dthuerck/mapmap_cpu/issues/21 mention, I have to change the line in prev_level().
I was using MinGW-GCC 10.2.0 as compiler, maybe the tbb provieded by msys2's package manager has some issues. I will try to rebuild it to see if the problem still exsits.

I can confirm that my bug is related to the compiler, there've been serval discussion about this bug.
https://stackoverflow.com/questions/30928265/mingw64-is-incapable-of-32-byte-stack-alignment-required-for-avx-on-windows-x64
https://sourceforge.net/p/mingw-w64/mailman/message/34485783/

Ah, too bad, it's a compiler bug. Are you able to switch to VS? I'll push the change in #21 upstream.
Regarding this problem, I only see two possibilities going forward:

Avoid MinGW ;)
Move variables from stack to heap.

Ah, too bad, it's a compiler bug. Are you able to switch to VS? I'll push the change in #21 upstream.
Regarding this problem, I only see two possibilities going forward:
1. Avoid MinGW ;)

2. Move variables from stack to heap.

Yeah, but I was able to avoid the problem by setting simd width to 4 using mingw. I don't know what it will do to the final outcome though.

@xubury @dthuerck
I am facing the same issue reported here by @cdcseacave. I packed the problem to a bin file in this issue https://github.com/dthuerck/mapmap_cpu/issues/37#issuecomment-1218231886

I think I might have found the reason, looks like the "labels" within the "label_set" are assumed to be sorted. If not, bad things happen. Correct?

Solved by making sure labels are sorted.
cc: @cdcseacave in case you are still interested in trying it again.

Thanks for investigating!


2.9.0 untrack-css.sh fails on mac, cut utility downlevel

When submitting a new issue, please supply the following information:
Platform: Place your platform here... give us your web browser/Electron version and your hardware (Raspberry Pi 2/3, Windows, Mac, Linux, System V UNIX).
MacOS Catalina
Node Version: Make sure it's version 0.12.13 or later.
12.8.1
**NPM version
6.9.0
MagicMirror Version: Now that the versions have split, tell us if you are using the PHP version (v1) or the newer JavaScript version (v2).
2.9.0
Description: Provide a detailed description about the issue and include specific details to help us understand the problem. Adding screenshots will help describing the problem.
untrack-css runs on every start, fails on macos, as cut is downlevel
Steps to Reproduce: List the step by step process to reproduce the issue.
install 2.9.0 on macos
npm start

Merged.


Jesse: Watch inc-community.rf.gd

Jesse requests the watch of the watch_keyword inc-community\.rf\.gd. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

inc-community\.rf\.gd has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Add option to lock wallet on timeout

What do you mean by "lock"?
Isn't spending password enough?


Fix native STARTTLS for Chrome Apps

Discussion: https://github.com/emailjs/emailjs-imap-client/issues/81

awesome, will have a look at it later today :) :+1:

so let me get this straight ... we schedule any subsequent read until the previous has had a chance to go through all of the microtask handlers. we're using the faster timeout, since this is scheduled on every run. good thing is that this should dilute perfomance only marginally, since it only affects the cleartext part of a connection, which is not a whole lot. and if you use email with cleartext connection only, poorer performance you shall deserve ;)
i am going out on a limb here and say this was introduced when i made the internal refactoring to use promises in the imap client, because before that it was all synchronous callbacks, which screwed up the task order. oopsie. -.-
please confirm if i got this right, then this should be good to merge.

That sounds absolutely plausible. If everything used to use synchronous callbacks, then I'm pretty sure it would have worked, and this fix is only needed because promises are now used instead. And yes, only the plaintext part of connections is affected by the fix.
Next challenge: unit test this >:O

tagged and published as v1.0.2


Subgraph not working after successful deployment

Hello,
A subgraph I have deployed is not working and I cannot determine what the problem is.
The target network is bsc and the subgraph is here. There are no error messages displayed whatsoever.

We are having instability with logs on the hosted service, to check the health of your subgraph please use the indexing status api:
curl --location --request POST 'https://api.thegraph.com/index-node/graphql'  --data-raw '{"query":"{ indexingStatusForCurrentVersion(subgraphName: \"<SUBGRAPH-NAME>\") { subgraph fatalError { message } nonFatalErrors {message } } }"}'

Replace <SUBGRAPH-NAME> with the name of your subgraph. If it's a pending version replace indexingStatusForCurrentVersion with indexingStatusForPendingVersion

Thank you so much. I was able to pinpoint the issue and solve it. Closing this.

Hello,
I am trying the following command to no avail:
curl --location --request POST 'https://api.thegraph.com/index-node/graphql'  --data-raw '{"query":"{ indexingStatusForPendingVersion(subgraphName: \"test") { subgraph fatalError { message } nonFatalErrors {message } } }"}'
Is the API still working? thank you in advance
Cheers

@oikos1 yes it is working. You were missing a backlash in subgraphName: \"test", should be subgraphName: \"test\".

Thank you so much!


Add margin to the footer

Description
Add some margin-top to the footer
Changes

Related Issues
#2261
Checklist

[ ] Tests included
[ ] Build pass
[x] Documentation
[x] Code format and docstrings
[x] Screenshots/Video attached (needed for UI changes)

Does this need to be in the center?

@ehab-hassan can you confirm, please?

@ehab-hassan can you confirm, please?

yes please


(PA-139) unify pa acceptance workflows

(PA-139) acceptance: allow multiple options to beaker using OPTIONS
(PA-139) acceptance: move beaker host generation to own task
This change moves host file generation to its own task. This separates
its concerns from the testing tasks, and allows the testing tasks to be
dependent upon it.

(PA-139) add tmp hostgenerator dir to rake clean list
(PA-139) move common options out of Rakefile
Many people run with beaker standalone. Common and required options have
been moved to the options files to support this workflow in this change.
We also move common options to their own file and load them into the
other options files that are loaded by beaker.

(PA-139) acceptance: fix running against preserved_hosts
(PA-139) fix releasing of preserved hosts
Fix the releasing of hosts helper task by using the user's vmpooler
token from their .fog file. We also remove some lingering
preserved_config logic, which is no longer used due to improvements in
beaker.

(PA-139) fix listing of preserved hosts
This change fixes developer helper tasks made for managing acceptance
VMs easier. We also remove methods that are superseded by beaker
functionality.

(PA-139) acceptance: Rakefile: deprecate CONFIG in favor of HOSTS
(PA-139) acceptance: remove passenger and packages installs
[skip ci]

i only tested the test_against_preserved_hosts task with an empty simple test.  further testing reveals that beaker wipes out the HOSTS hash when using any options file that points at a preserved_hosts file.  i believe a work around is available that i'm working out for deployer.  digging into the morass of coupling that is the beaker options parser is probably not the best route for now...

suggestion to use BEAKER_HOSTCONFIG rather than HOSTS  thoughts?

yeah, i'm sold on BEAKER_HOSTCONFIG use.  i have a couple other updates for this PR.  but maybe we should just get those minimal changes in, similar to your hiera PR and then i'll rebase this one as it has extensive unrelated changes.

floating an update to hiera component to use BEAKER_HOSTCONFIG. This can be propagated to other puppet-agent components when approved.
https://github.com/puppetlabs/hiera/pull/338

Is this starting from a baseline that's compatible with the changes in FACT-1281?

@MikaelSmith not yet.  but it can be.  we should probably wait until after the release for stuff like this PR

wrong branch name.  re-opening


Custom routes with nuxt extends not working

Environment

Operating System: Darwin
Node Version:     v16.14.2
Nuxt Version:     3.1.1
Nitro Version:    2.1.1
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      -
Runtime Modules:  -
Build Modules:    -

Reproduction
https://stackblitz.com/edit/nuxt-starter-5ar22s?file=nuxt.config.ts,base%2Fnuxt.config.ts,base%2Froutes%2FRoutes.js,pages%2Findex.vue
Describe the bug
When the extends functionality from Nuxt 3 is used, and we have a pages directory when is extended into the source. The pages inside the extend are not found by the i18n module.
The pages inside the root work fine. I am on the latest version (8.0.0-beta.9)
You'll see in the reproduction that there is a login and register to showcase this.
The login.vue is located inside the extend base directory, and is not found, also the terminal gives a warning: [@nuxtjs/i18n]: Couldn't find AnalizedNuxtPageMeta by NuxtPage (/login), so no custom route for it
The register.vue is located inside the root, and works fine.
Additional context
If this is something that needs to be fixed in Nuxt 3, is there a workaround for this?
Also you can see what's wrong on the homepage, where the link for login is referring to /login and not /aanmelden, as it is set in routes/Routes.js
It might be a bit related to: https://github.com/nuxt-modules/i18n/issues/1743, however this is not really a RFC.
Logs
No response

Any news on this? Or can you point me in a direction to fix this?

Any news about this issue?! Our project is stucked into it!

Any news about this issue?! Our project is stucked into it!

Until this is resolved, you could just not use the pages as extend or create duplicate files.
But yeah we are too stuck with this. I'll try to open a PR if i find a solution.

Resolved with: https://github.com/nuxt-modules/i18n/pull/1925


1.8.0

When I upgraded from 1.7.0 to 1.8.0, I found that the render mode of Vue was changed from replace el to append under El

That is the intentional behavior we changed in 1.8.0. See https://github.com/single-spa/single-spa-vue/releases/tag/v1.8.0 and #33.
In<EMAIL_ADDRESS>this behavior only applied when you omitted appOptions.el, but now it applies also when you do not omit appOptions.el

Thinking more about this - maybe would have been better to publish as 2.0.0 to avoid confusion / breaking things. Next time I'll be more conscious of this.


viser også barnløse lag

A picture tells a thousand words
Before this PR

After this PR

Coverage decreased (-0.1%) to 43.664% when pulling f8c8859f3238514825122f508ecac821c437c4fe on fix#418 into e7e5b2d535c3f34d605144d67d34297e5e9fe6b2 on master.


Build for Docker

Sorry i am new in rust world.
Do you have example for the deployment, because it is not found in the documentation?

Hello, i can confirm i successfully deploy rust with prisma-client-rust.
i also deployed the app in fly.io https://rust-with-prisma.fly.dev/user
here are my Dockerfile
# Build stage
FROM rust:1.70.0-slim-bullseye AS build

ARG APP_NAME="with-prisma"

RUN apt-get update -y && \
  apt-get install -y pkg-config make g++ libssl-dev && \
  rustup target add x86_64-unknown-linux-gnu

WORKDIR /build

COPY . .

RUN cargo prisma generate
# /root/.cache/prisma/binaries/cli/4.8.0/prisma-cli-linux-x64

RUN cargo build --release --target x86_64-unknown-linux-gnu

CMD ["/build/target/x86_64-unknown-linux-gnu/release/with-prisma"]

however the image build is really big, here is the detail:

i am looking the way, for decreasing the image size. Do you have any suggestion?

Use a multi-stage build and only copy over the executable in the second stage, everything else in target is unnecessary.


OSX - w2e 0.6.4b icon paths hardcoded in manifest - built app won't launch

OSX 10.11.6  El Capitan
NWjs 0.20.3-osx
Using 0.6.4b the generated builds are not launching - the problem appears to be hard-coded icon paths in the package.json (should be stripped to relative paths) - tried 0.5.1b and all was OK.
Have attached screenshots and the test project to assist.
iconbuildbug.zip

Ah, something is going wrong with file copying. So here's the issue: if icons are outside the project directory (where the package.json exists) Web2Exe should copy them to that folder and replace the absolute path with the new path. The reason is that NW.js can't see anything outside that folder. For some reason, it looks like this behavior is not happening anymore.
As a workaround, you could copy those files inside your "Blank" folder and reference them in Web2Exe.

Right then - going bananas here but have found that putting the files in the Blank folder didn't work so well but if I just build it as normal and then edit the icon references in the generated app package the app will work fine (a hassle tho!).  When I was trying the earlier builds of W2E to test I was being tripped up by the modified package.json file - came right when I restored the original package.json file.  Also wondering why the webexe_settings are still in the package.json when there is now a separate web2exe.json file produced. Note: retried the 0.6.3b build and it was OK so the issue appears to be with the 0.6.4b build.

The webexe_settings should only be in the package.json if they were in there already before (when you were exporting with older versions it would have been added).
I'll try to have this fixed as soon as I can. It's probably creating a lot of grief for others as well.

Thanks Joey - can't check though - no W2E for Mac build in the 0.6.5 downloads.
I will wait in case the downloads are taking a while to update.
Cheers.

Hey man, sorry about that. I had issues building on my Mac last night. I'll put it up when I get home!

Should be up :)


Nvim .9 crashes with image.nvim

I noticed this with a lot of other plugins that involve image rendering, neovim ,9 just crashes with hologram and this plugin

It seems to be a seperate plugin issue that causes this crashing


Admin Menu - Superuser and up

only superusers and higher should be able to see the Admin menu item

As a (type of user)
I want (goal)
so that (reason/ why/ value)
Acceptance Criteria
Scenario 1:
GIVEN ... (you or your condition)
WHEN ... (what you do)
THEN ... (what you see)
Scenario 2:
xxxxxx
Validation Rules?
(If yes, list here)
Screenshot
(Link above will always be the most up-to-date version.)

@TomChapmanGov I am a viewer, and I can still access the Admin User menu.

I'm showing up as nothing on Test, but can still see admin menu

in Dev, I can still see the menu item, but the screen doesn't load data.


OCPBUGS-37055: Use proxy for HTTP request release signatures

Description
This fixes the error encountered when running oc-mirror behind proxy for mirroring releases: signature API was called without respecting proxy setup
Fixes #OCPBUGS-37055
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

Install tinyproxy (sudo dnf install tinyproxy -y)
Create tinyproxy.conf

Port 8888
Listen <IP_ADDRESS>
Timeout 600
Allow <IP_ADDRESS>

run tinyproxy (tinyproxy -d -c tinyproxy.conf)
in separate window, run oc-mirror with proxy env vars set:

 export http_proxy=localhost:8888
 export HTTP_PROXY=localhost:8888
export HTTPS_PROXY=localhost:8888
export https_proxy=localhost:8888
./bin/oc-mirror --v2 -c ec2-demo/isc_resources.yaml file:///home/skhoury/demo1

look at logs of tinyproxy, call to mirror.openshift.com (as well as quay.io for images, and api.openshift.io for cincinnati) should be visible in the logs.

Expected Outcome
see above

/label qe-approved

/lgtm

/label acknowledge-critical-fixes-only

/cherry-pick release-4.16


Slow speeds and connection errors

Whenever I try to set the custom server https://dns11.quad9.net the connection simply stops working.
Also no matter which dns provider I choose, I get extremely slow speeds. My connection is 300mbps and I'm barely getting 50mbps download, as soon as I disable Intra the speeds go back to normal, this happens both on wifi and data.

I'm also observing same issue. My broadband is 100 mbps. However the moment I turn on Intra (any dns server), the speed falls to about 45-50 mbps.
The speed again restores if I disable Intra.

These may fix the issues you've reported (it fixes them on a hard fork of Intra I maintain). Perhaps, these fixes land in the next Intra release.

#519
#517

Any news when the next version is going to be released? It's been 4 months already


The method 'sendSubegment' of AWSXRay should have been 'sendSubsegment'

Issue #, if available:
No issue created.
Description of changes:
This is fixing a typo in a method name.  sendSubegment vs sendSubsegment (missing the 's').
I marked 'sendSubegment' as deprecated and added a new 'sendSubsegment' method.
I made the old 'sendSubegment' call the new 'sendSubsegment' for backwards compatibility.
Since this is an interface change that is breaking (if the typo was just fixed) I figured the best way to handle this would be to mark the old method as deprecated, but keep it around.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thank you very much for your contribution!


How do I build this?

I've tried to make a distribution using pyinstaller, but I can't get it working. I wanted to set the port number for the server. Could you please explain how making a binary release works? Alternatively, it would be nice if the port number was configurable instead of random.

I used Auto PY to EXE to generate the release you'll need to add the static, templates and vgamepad folders as additional folders.

The command it generated is pyinstaller --noconfirm --onedir --windowed --icon "D:/Projects/pythonProjects/StadiaWireless/logo.ico" --add-data "D:/Projects/pythonProjects/StadiaWireless/static;static/" --add-data "D:/Projects/pythonProjects/StadiaWireless/templates;templates/" --add-data "D:/Projects/pythonProjects/StadiaWireless/vgamepad;vgamepad/"  "D:/Projects/pythonProjects/StadiaWireless/server.py"

Thank you. This is very good information. Might I suggest you make this part of the documentation?

Updated the readme to include the pyinstaller commands


ERROR TypeError: Cannot read property 'apply' of undefined

Hi,
I am trying to open a modal with a component but I have the following error:
LoginModalComponent.html:2 ERROR TypeError: Cannot read property 'apply' of undefined
    at RendererAdapter.invokeElementMethod (core.es5.js:10726)
    at MzModalComponent.initModal (modal.component.js:45)
    at MzModalComponent.ngAfterViewInit (modal.component.js:33)
    at callProviderLifecycles (core.es5.js:11398)
    at callElementProvidersLifecycles (core.es5.js:11373)
    at callLifecycleHooksChildrenFirst (core.es5.js:11357)
    at checkAndUpdateView (core.es5.js:12467)
    at callViewAction (core.es5.js:12824)
    at execComponentViewsAction (core.es5.js:12756)
    at checkAndUpdateView (core.es5.js:12465)
    at callWithDebugContext (core.es5.js:13679)
    at Object.debugCheckAndUpdateView [as checkAndUpdateView] (core.es5.js:13219)
    at ViewRef_.detectChanges (core.es5.js:10385)
    at eval (core.es5.js:5016)
    at Array.forEach (<anonymous>)
    at ApplicationRef_.tick (core.es5.js:5016)
    at eval (core.es5.js:4888)
    at ZoneDelegate.invoke (zone.js:392)
    at Object.onInvoke (core.es5.js:4094)
    at ZoneDelegate.invoke (zone.js:391)
    at Zone.run (zone.js:142)
    at NgZone.run (core.es5.js:4025)
    at Object.next (core.es5.js:4888)
    at SafeSubscriber.schedulerFn [as _next] (core.es5.js:3839)
    at SafeSubscriber.__tryOrUnsub (Subscriber.js:238)
    at SafeSubscriber.next (Subscriber.js:185)
    at Subscriber._next (Subscriber.js:125)
    at Subscriber.next (Subscriber.js:89)
    at EventEmitter.Subject.next (Subject.js:55)
    at EventEmitter.emit (core.es5.js:3825)
    at checkStable (core.es5.js:4059)
    at onLeave (core.es5.js:4138)
    at Object.onInvokeTask (core.es5.js:4088)
    at ZoneDelegate.invokeTask (zone.js:424)
    at Zone.runTask (zone.js:192)
    at ZoneTask.invokeTask [as invoke] (zone.js:499)
    at invokeTask (zone.js:1427)
    at XMLHttpRequest.globalZoneAwareCallback (zone.js:1445)

Here is the component:
@Component({
  selector: 'login-modal',
  template: `
<mz-modal>
  <mz-modal-header>

Authentification requise

  </mz-modal-header>

  <mz-modal-content>
  </mz-modal-content>

  <mz-modal-footer>
    <button mz-button class="green" (click)="submit()">
      Login
    </button>

    <button mz-button mz-modal-close>
      Cancel
    </button>
  </mz-modal-footer>
</mz-modal>
  `
})
export class LoginModalComponent extends MzBaseModal {
  @ViewChild('loginForm') loginForm: LoginFormComponent;

  submit(): void {
    // TODO Alexis Lahouze 2017-08-31 Send result, close modal.
  }
}

And here is the way I open the modal:
let modal = this.mzModalService.open(LoginModalComponent);

Here are the versions of my dependencies:
$ yarn list @angular/core ng2-materialize materialize-css zone.js rxjs
yarn list v0.27.5
├─<EMAIL_ADDRESS>
├─<EMAIL_ADDRESS>
├─<EMAIL_ADDRESS>
├─<EMAIL_ADDRESS>
└─<EMAIL_ADDRESS>
Done in 0.89s.

I tried to downgrade zone.js to version 0.8.4 after reading this issue https://github.com/angular/angular-cli/issues/6036 but got the same error.
Best regards,
Alexis.

Forgot to mention the browser used is Google Chrome 60.0.3112.101.
I tried using Firefox, but the error was the same:
ERROR TypeError: renderElement[methodName] is undefined
(on line 10726 of core.es5.js, the undefined object which we try to call 'apply' on is renderElement[methodName])

Hi @xals,
Sorry for the huge delay. According to your stack trace ... it seems like the JQuery method modal is undefined as it is the only method called through the renderer.invokeElementMethod in the initModal method of the ModalComponent.
Just to be sure ... did you included materialize.js and jquery.js (or the minify equivalent) in your application like specified in the README.md file under "Installation" ?

Same here for the delay.
Actually I am trying to use ng2-materialize with webpack, not angular-cli, and my configuration may not be accurate.
I tried to import jQuery and Materialize-css in my index file, and got the same error.
I will try to build a simple prototype to give you a base to work on.

@jfcere Here I created a basic repository: https://github.com/xals/angular-materialize
If you need more information, feel free to reply to this issue.

I have the same issue, no informations on how to configure ng2-materialize with webpack.

Really sorry, its been a long time this has been opened. I don't have much experience with webpack without angular-cli but i'll try to take some times to look at it again.
If anybody have any insight or thoughts about what could be the problem I am all ears!


fix(vue-renderer): clone options.head before generating meta tags in spa mode

Types of changes

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

Description

Resolves: #6428
vue-meta mutates the metaInfo object it receives, which could cause issues as in the linked issue.
Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly. (PR: #)
[ ] I have added tests to cover my changes (if not applicable, please state why)
[ ] All new and existing tests are passing.

Codecov Report

Merging #6429 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev    #6429   +/-   ##
=======================================
  Coverage   95.61%   95.61%
=======================================
  Files          79       79
  Lines        2689     2689
  Branches      694      694
=======================================
  Hits         2571     2571
  Misses        101      101
  Partials       17       17

Flag
Coverage Δ

#e2e
100% <ø> (ø)
:arrow_up:

#fixtures
50.79% <0%> (ø)
:arrow_up:

#unit
92.26% <100%> (ø)
:arrow_up:

Impacted Files
Coverage Δ

packages/vue-renderer/src/renderers/spa.js
87.87% <100%> (ø)
:arrow_up:

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 0e0149d...6ce21ea. Read the comment docs.

Thanks!


Add pentatonic scales

This is difficult in the case of Guitar Dashboard because of the way the music algorithm works and chords are generated.


Raise an alloc error on any alloc failure

Description of change
Current code was using OPENSSL_zalloc/OPENSSL_malloc and OPENSSL_strdup,
but only the failure of last one was raising an error.
Targets:

[X] master
[X] branch 1.1.0

+1

+1

pushed to master and 1.1.0, thanks.


Generic Record fails to infer dynamic property

TypeScript 3.7.2
Playground link

Compiler Options
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}

Input:
class Foo<Document, K extends string> {
  constructor(private field: K) {}

  fn(a:Record<K,number>) {}

  fail(opt: K) {
    this.fn({ [opt]: 2 });
  }

  works(opt: K) {
    this.fn({ [opt]: 2 } as Record<K, number>);
  }
}

Output:
"use strict";
class Foo {
    constructor(field) {
        this.field = field;
    }
    fn(a) { }
    fail(opt) {
        this.fn({ [opt]: 2 });
    }
    works(opt) {
        this.fn({ [opt]: 2 });
    }
}

Expected behavior:
I would expect the fail function to compile, but it appears I have to force the parameter's type (like in works function). I can't determine if it's a compiler's bug or my mistake, all types seem correct and pretty straightforward to me, so if anyone has a clue about what's happening here, I'd be glad to have an explanation.

It seems that TS infers a string index signature rather than { [x in K]: number } like one would expect.  It knows that opt :: K yet goes ahead and uses its string constraint for the key type... hmm.

This is a correct error. You only have one key here, but K could be a union and you would be failing to produce a complete object. Here's an example that shows how to produce an unsoundness if this code were allowed:
class Foo<Document, K extends string> {
  constructor(private field: K) {}

  key!: K;
  fn(a: Record<K, number>) {
    return a[this.key];
  }

  setKey(value: K) {
    this.field = value;
  }

  fail(opt: K) {
    return this.fn({ [opt]: 2 });
  }

  works(opt: K) {
    this.fn({ [opt]: 2 } as Record<K, number>);
  }
}

const c = new Foo<any, "foo" | "bar">("foo");
c.setKey("bar");
const m = c.fail("foo");
// m: number, but is undefined

Oh, thanks for the clarification, I understand now. This seems to be the case only if you enforce generic arguments to be different from what would naturally be inferred from the constructor without generic arguments then. I'll be fine with the forced cast, but out of curiosity, do you see a way to write such a pattern with soundness?


[BEAM-7034] Add example snippet to read fromQuery using BQ Storage API.

Jira ticket was resolved but the docs haven't been updated accordingly with a snippet.

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

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] 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.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Should we add a note about the pricing?
Does using BigQuery Storage API + fromQuery combines the cost = BigQuery query pricing + BigQuery Storage API pricing on top)?

R: @kennknowles

R: @kmjung @chamikaramj

cc: @vachan-shetty

Also, re: the question above about pricing: the storage API is free when used to read anonymous tables (e.g. query results). Users pay only when scanning from a named table.

@fpopic - Could you address the open comments?

Also, re: the question above about pricing: the storage API is free when used to read anonymous tables (e.g. query results). Users pay only when scanning from a named table.

Does it mean that for my existing named table myproject:mydataset.mytable with the following schema:
[
  {
    "mode": "NULLABLE",
    "name": "my_string_field_1",
    "type": "STRING"
    },
  {
    "mode": "NULLABLE",
    "name": "my_string_field_2",
    "type": "STRING"
  }
]

Option A
BigQueryIO
.read<T>(...)
.from("myproject.mydataset.mytable")
.withSelectedFields("my_string_field_1")
.withMethod(Method.DIRECT_READ))

Would only include the BigQuery Query scan cost of the field my_string_field_1 + Storage API scan cost for the field my_string_field_1?

Option B
BigQueryIO
.read<T>(...)
.fromQuery("SELECT my_string_field_1 || 'my_concat_business_logic_for_this_field' FROM `myproject.mydataset.mytable`")
.usingStandardSql()
.withMethod(Method.DIRECT_READ))

And here the cost would only include the Storage API scan cost for the field my_string_field_1?

Or you are just saying that anonymous table scan
BigQueryIO
.read<T>(...)
.fromQuery("SELECT 'dummy' AS my_string_field_1")
.usingStandardSql()
.withMethod(Method.DIRECT_READ))

is free of BigQuery query cost and you pay basically the Storage API cost for the bytes of dummy bytes?

In your examples above:
BigQueryIO
    .read<T>(...)
    .from("myproject.mydataset.mytable")
    .withSelectedFields("my_string_field_1")
    .withMethod(Method.DIRECT_READ))

This would incur only BigQuery storage API charges for the uncompressed size of the my_string_field_1 column (e.g. at $1.10/TiB). The BigQuery query engine isn't involved here, and so neither is the $5/TiB query cost.
BigQueryIO
    .read<T>(...)
    .fromQuery("SELECT my_string_field_1 || 'my_concat_business_logic_for_this_field' FROM `myproject.mydataset.mytable`")
    .usingStandardSql()
    .withMethod(Method.DIRECT_READ))

This is a BigQuery query -- it will be executed as a query job, the query results will be written to an anonymous table, and then Beam will use the storage API to read the results from the anonymous table. You'll pay the standard $5/TiB on-demand query cost here (unless you're using a BigQuery reservation), but there won't be any costs associated with the storage API usage in this case because the target is an anonymous table.
I think your last example sums things up correctly.

Is this PR still active?

Is this PR still active?

Is this PR still active?

@kmjung we stopped here

Is this PR still active?

@kmjung we stopped here

I thought the plan was to merge this PR and then proceed with the update to remove readTableRows. Can we proceed with that plan? cc: @vachan-shetty

I thought the plan was to merge this PR and then proceed with the update to remove readTableRows. Can we proceed with that plan? cc: @vachan-shetty

I thought the plan was to merge this PR and then proceed with the update to remove readTableRows. Can we proceed with that plan? cc: @vachan-shetty

If the plan is to merge this, could you:

Review and LGTM the PR
Check that all tests are passing.

I thought the plan was to merge this PR and then proceed with the update to remove readTableRows. Can we proceed with that plan? cc: @vachan-shetty

If the plan is to merge this, could you:

Review and LGTM the PR
Check that all tests are passing.

The PR looks good to me. I'm not a Beam repository owner and can't provide formal approval.

The PR looks good to me. I'm not a Beam repository owner and can't provide formal approval.

Retest this please

Retest this please

Thanks. Will merge after tests pass.

Thanks. Will merge after tests pass.

Retest this please

Retest this please

Looks like there are style (spotless) issues.

Looks like there are style (spotless) issues.

Looks like there are style (spotless) issues.

Ah will check it out during weekend and fix. Thank you!

Looks like there are style (spotless) issues.

Ah will check it out during weekend and fix. Thank you!

Looks like there are style (spotless) issues.

Hi @aaltay, is there a way to locally run linter or whatever static check is failing, I am having a hard time figuring out what could be wrong without any log message in CI?

Looks like there are style (spotless) issues.

Hi @aaltay, is there a way to locally run linter or whatever static check is failing, I am having a hard time figuring out what could be wrong without any log message in CI?

You can run ./gradlew spotlessApply and it will automatically fix it.

You can run ./gradlew spotlessApply and it will automatically fix it.


Distribute functionality similar to HockeyApp

Describe the solution you'd like
Looking for AppCenter to support similar distribution functionality as HockeyApp. HockeyApp allowed us to configure Private download pages and Unrestricted Builds. With this implementation, our app is able to update itself provided it has a valid HockeyApp API Key. This works very well for our Internal Enterprise application that we distribute to end-users. Essentially we want Private Installation (only valid AppCenter users can install the application). If we send the application to a new user, they should be able to install the application and get In-App updates without an AppCenter account.
Ideally, if our application has an embedded AppCenter API key, it can get in-app updates like it did with HockeyApp.
Describe alternatives you've considered
We considered Public Distribution and adding end-users to AppCenter. Public Distribution does not work because it violates our client agreement so we cannot make  the installation page publically accessible. Adding end-users to AppCenter may work, but we do not want to add hundreds of users to AppCenter just to get In-App updates.
Additional context
This is the HockeyApp functionality we were expecting to retain with AppCenter. It is unfortunate that we thought this was going to be a smooth process, and that we would not lose functionality that we previously had with HockeyApp.

By default, builds are unrestricted and can be downloaded anonymously through HockeySDK or the HockeyApp API. The reason for this anonymous access is that sandboxing on iOS and Android prevents HockeySDK from identifying the user. For a higher level of security, we recommend the following steps
https://support.hockeyapp.net/kb/app-management-2/how-to-restrict-app-and-build-access

@dimazaid Do you all have an ETA on this implementation? It is a roadblock for us using App Center in our production environment.

With the announcement of retiring the HockeyApp SDK (https://github.com/microsoft/appcenter/issues/1840), any plans to introduce this functionality to AppCenter SDK before the November 13 date?
@ahdbilal, you recommended that we use the HockeyApp SDK because it allows anonymous users to get in-app updates without requiring a login. The HockeyApp SDK allows us to have a private download page with unrestricted builds.
Our use case is that we develop an internal iOS app. We have system support users who have AppCenter access to install the app on our corporate MDM managed devices. Our field users do not have access to AppCenter nor have a login to it. If we gave our field users access to AppCenter, they would be able to install our enterprise application on any device they want, which is not ideal and against our policy.
Are you planning to add a new update track that allows functionality similar to MSUpdateTrackPublic? However, we do not want to make the distribution group in AppCenter public as that means anyone could install the application. We just do not want to require an AppCenter login in order for in-app updates to work.
Thanks!

And why was this closed? This was a major gap between HockeyApp and AppCenter
Thanks

I don't work for them and still use AppCenter Distribute, but https://www.applivery.com/ is a good alternative and is very close to HockeyApp if needed. They have a lot of distribution methods.

I don't work for them and still use AppCenter Distribute, but https://www.applivery.com/ is a good alternative and is very close to HockeyApp if needed. They have a lot of distribution methods.

Thanks! Looks pricey...guess you get what you pay for...

Sorry, I wasn't sure anyone else was looking for this, and I found a workaround that seems to be working so far. Need to do a little more testing then I can share my solution. I reopened the issue in the mean time.

Think my method is working and seems to avoid prompting for a user login. However, we are only using this for iOS, and I am not sure what the Android equivalent is.
For iOS, I am using method swizzling to replace the functionality of MSKeychainUtil. If MSKeychainUtil returns a token for MSUpdateToken, it will not open Safari for the user to login.

Generate an AppCenter API read-only token
Create new Objective-C file

@interface NSObject (PrivateSwizzleCategory)

@end

@implementation NSObject (PrivateSwizzleCategory)

+ (void)load {
    Method original = class_getInstanceMethod(objc_getMetaClass("MSKeychainUtil"), @selector(stringForKey:statusCode:));
    Method swizzled = class_getInstanceMethod(self, @selector(swizzled_stringForKey:statusCode:));
    method_exchangeImplementations(original, swizzled);
}

- (NSString *)swizzled_stringForKey:(NSString *)key statusCode:(OSStatus *)statusCode {
    // hardcodes a token that way AppCenter SDK can prompt for updates
    // without this, AppCenter would pop open a Safari window so the user can log into AppCenter
    if ([key isEqualToString:@"MSUpdateToken"]) {
        return [AppSettingsObjc appCenterUpdateToken];
    }

    NSString* result = [(NSObject *)self swizzled_stringForKey:key statusCode: statusCode];
    return result;
}
@end


Add Seattle building permits EDA notebook

Cursory exploratory analysis of building permits using City of Seattle open data.  This is my first PR, hopefully everything is squared away.  Thanks so much for setting this up!

Nice @amcadie !


Missing Transport Client Dependencies

When attempting to use the Shaded Elasticsearch Transport client provided by the following dependency:
<dependency>
    <groupId>com.strapdata.elasticsearch.client</groupId>
    <artifactId>transport</artifactId>
    <version>5.5.0</version>
</dependency>

You encounter the following when trying to perform a mvn clean package:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building elassaandra-bug 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for com.strapdata.elasticsearch.plugin:transport-netty3-client:jar:5.5.0 is missing, no dependency information available
[WARNING] The POM for com.strapdata.elasticsearch.plugin:transport-netty4-client:jar:5.5.0 is missing, no dependency information available
[WARNING] The POM for com.strapdata.elasticsearch.plugin:reindex-client:jar:5.5.0 is missing, no dependency information available
[WARNING] The POM for com.strapdata.elasticsearch.plugin:lang-mustache-client:jar:5.5.0 is missing, no dependency information available
[WARNING] The POM for com.strapdata.elasticsearch.plugin:percolator-client:jar:5.5.0 is missing, no dependency information available
[WARNING] The POM for com.strapdata.elasticsearch.plugin:parent-join-client:jar:5.5.0 is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.599 s
[INFO] Finished at: 2018-05-10T10:35:11+01:00
[INFO] Final Memory: 14M/479M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project elassaandra-bug: Could not resolve dependencies for project com.example.elassandra:elassaandra-bug:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: com.strapdata.elasticsearch.plugin:transport-netty3-client:jar:5.5.0, com.strapdata.elasticsearch.plugin:transport-netty4-client:jar:5.5.0, com.strapdata.elasticsearch.plugin:reindex-client:jar:5.5.0, com.strapdata.elasticsearch.plugin:lang-mustache-client:jar:5.5.0, com.strapdata.elasticsearch.plugin:percolator-client:jar:5.5.0, com.strapdata.elasticsearch.plugin:parent-join-client:jar:5.5.0: Failure to find com.strapdata.elasticsearch.plugin:transport-netty3-client:jar:5.5.0 in http://nexus.technotomy.com/content/groups/allrepos was cached in the local repository, resolution will not be reattempted until the update interval of home has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Upon inspection it appears that the following compile dependencies are not included in the central maven repository:

Is this intentional?
If you want to perform operations using the Elasticsearch transport client on Elassandra which client library should you be using? The shaded one or the original from Elasticsearch? Or should we be excluding those dependencies and be using original Elasticaearch versions?
There isn't any mention of how to use a Transport client outside of the Enterprise section within the documentation, which mentions a secured Transport client being provided by Strapdata, with the class of com.strapdata.elasticsearch.plugins.ssl.PreBuiltSslTransportClient. The client provided by the shaded transport client dependency matches Elasticsearch's original org.elasticsearch.client.transport.TransportClient.
Previously when using the Transport client I have run into issues to do with binary incompatibilities between server and client when minor/patch versions differed (admittedly this was with the Elasticsearch 2.X.X versions), and assumed that the shaded client was provided because of potential issues with any changes you have made.

Yes, the issue is that we cannot append a digit to the elasticsearch version number in order to publish our releases because plugins' version must match elasticsearch version.
The workaround is to install locally strapdata artifacts in your maven repository to build your projects. Just clone the elassandra project (with --recurse-submodules), and run:
gradle publishToMavenLocal -Dbuild.snapshot=false -Dmaven.repo.local=/Users/xxxxx/.m2/repository


Add Subcollections

Add subcollections for existing things that can be subcollections
Remove unnecessary test helper methods by changing :type => :controller to :type => :request
Refactor almost identical code for Controller.list, .show, .destroy into mixins
Test the mixins themselves rather than the controllers to ensure that the same cases are covered for all controllers.

Looks great :+1:
http://localhost:3000/api/v0.0/service_offerings/367/service_parameters_sets
[{"id":"362","source_id":1,"source_ref":"43d3e23d214c26dbebc0879e44425db4","name":"default","description":"An APB that deploys MediaWiki","service_offering_id":367,"extra":null,"created_at":"2018-10-17T17:15:47.070Z","updated_at":"2018-10-17T20:59:29.441Z","source_deleted_at":null,"tenant_id":1,"source_created_at":"2018-08-31T00:35:53.000Z","create_json_schema":{"type":"object","$schema":"http://json-schema.org/draft-04/schema","required":["mediawiki_db_schema","mediawiki_site_name","mediawiki_site_lang","mediawiki_admin_user","mediawiki_admin_pass"],"properties":{"mediawiki_db_schema":{"type":"string","title":"Mediawiki DB Schema","default":"mediawiki","pattern":"^[a-zA-Z_][a-zA-Z0-9_]*$"},"mediawiki_site_lang":{"type":"string","title":"Mediawiki Site Language","default":"en","pattern":"^[a-z]{2,3}$"},"mediawiki_site_name":{"type":"string","title":"Mediawiki Site Name","default":"MediaWiki","pattern":"^[a-zA-Z]+$"},"mediawiki_admin_pass":{"type":"string","title":"Mediawiki Admin User Password"},"mediawiki_admin_user":{"type":"string","title":"Mediawiki Admin User (Cannot be the same value as Admin User Password)","default":"admin"}},"additionalProperties":false},"update_json_schema":null,"archived_on":null}]

One thing that concerns me here is the idea that we were going to generate the swagger yaml from the controllers.  I had assumed we'd have to leverage code comments to fill in the documentation aspects or use something like swagger-docs to do the heavy lifting.  If the code is moved into mixins like this though, I'm not sure how that would work.

I have a script that updates the swagger file based on the routes, not the controllers.


BDD us011 display state of a CE

Added the integration tests for user story 11 displaying the state of a collection exercise
https://trello.com/c/kJO9QkLd

 US011 Display State of a Collection Exercise [M]


Vite 4 Support

Attempting to upgrade Vite to version 4. Seems vite-plugin-svgr only supports up to version 3.
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>|| 3" from<EMAIL_ADDRESS>npm ERR! node_modules/vite-plugin-svgr
npm ERR!   dev<EMAIL_ADDRESS>from the root project

Temporary workaround in package.json:
"overrides": { "vite-plugin-svgr": { "vite": "4" } },

Thanks for the feedback!
Published v2.3.0