Build system fixes

Summary
It compiles on Arch, though there is one bigger change required to get msgpack 5 properly supported in CMake.
Test plan

Check that OI is working correctly, you can add some unit or integration test,
paste the output of some manual test, and / or paste the output of running
the test locally with make test-static

There is no such target test-static? ctest also doesn't seem to find anything? Am I missing something? I have these in my CMakeCache.txt:
BUILD_TESTING=ON
WITH_FLAKY_TESTS:BOOL=ON
WITH_TESTS:BOOL=ON

I added an include(CTest) to test/CMakeLists.txt and when I then run ctest I get tons of errors:
49% tests passed, 358 tests failed out of 702

Total Test time (real) =  93.14 sec

The following tests did not run:
         61 - DrgnParserTest.StructAlignment (Skipped)
         62 - DrgnParserTest.MemberAlignment (Skipped)
         68 - DrgnParserTest.BitfieldsMoreBitsThanType (Skipped)
        198 - OidIntegration.std_vector_bool_empty (Skipped)
        199 - OidIntegration.std_vector_bool_some (Skipped)
        215 - OidIntegration.std_unordered_map_int_int (Skipped)
        284 - OidIntegration.references_int_ref (Skipped)
        285 - OidIntegration.references_vector_ref (Skipped)
        305 - OidIntegration.pointers_incomplete_raw (Skipped)
        306 - OidIntegration.pointers_incomplete_raw_no_follow (Skipped)
        307 - OidIntegration.pointers_incomplete_raw_null (Skipped)
        313 - OidIntegration.pointers_function_raw (Skipped)
        314 - OidIntegration.pointers_function_raw_chase (Skipped)
        315 - OidIntegration.pointers_function_raw_null (Skipped)
        316 - OidIntegration.pointers_function_std_function (Skipped)
        317 - OidIntegration.pointers_function_std_function_chase (Skipped)
        318 - OidIntegration.pointers_function_std_function_null (Skipped)
        319 - OidIntegration.pointers_int (Skipped)
        320 - OidIntegration.pointers_int_no_follow (Skipped)
        321 - OidIntegration.pointers_int_null (Skipped)
        322 - OidIntegration.pointers_void (Skipped)
        323 - OidIntegration.pointers_void_no_follow (Skipped)
        324 - OidIntegration.pointers_void_null (Skipped)
        325 - OidIntegration.pointers_vector (Skipped)
        326 - OidIntegration.pointers_vector_no_follow (Skipped)
        327 - OidIntegration.pointers_vector_null (Skipped)
        335 - OidIntegration.pointers_vector_of_pointers_no_follow (Skipped)
        340 - OidIntegration.padding_parent_padding (Skipped)
        381 - OidIntegration.folly_sorted_vector_map_int_vector_empty (Skipped)
        382 - OidIntegration.folly_sorted_vector_map_int_vector_some (Skipped)
        412 - OidIntegration.enums_anonymous (Skipped)
        422 - OidIntegration.bitfields_more_bits_than_type (Skipped)
        429 - OidIntegration.arrays_direct_int10 (Skipped)
        430 - OidIntegration.arrays_direct_int0 (Skipped)
        431 - OidIntegration.arrays_ref_int10 (Skipped)
        432 - OidIntegration.arrays_ref_int0 (Skipped)
        435 - OidIntegration.anonymous_anon_struct_ptr (Skipped)
        440 - OidIntegration.alignment_container_struct (Skipped)
        442 - OidIntegration.alignment_container_two_members (Skipped)
        444 - OidIntegration.alignment_container_member_alignment (Skipped)
        446 - OidIntegration.alignment_container_union_member (Skipped)
        448 - OidIntegration.alignment_container_member_override (Skipped)
        450 - OidIntegration.alignment_container_member_lower (Skipped)
        460 - OilIntegration.templates_int (Skipped)
        462 - OilIntegration.templates_two (Skipped)
        464 - OilIntegration.std_vector_del_allocator_a (Skipped)
        467 - OilIntegration.std_vector_bool_empty (Skipped)
        468 - OilIntegration.std_vector_bool_some (Skipped)
        472 - OilIntegration.std_variant_char_int64_1 (Skipped)
        473 - OilIntegration.std_variant_char_int64_2 (Skipped)
        474 - OilIntegration.std_variant_vector_int_1 (Skipped)
        475 - OilIntegration.std_variant_vector_int_2 (Skipped)
        476 - OilIntegration.std_variant_optional (Skipped)
        477 - OilIntegration.std_variant_empty (Skipped)
        478 - OilIntegration.std_variant_256_params_256 (Skipped)
        479 - OilIntegration.std_variant_256_params_empty (Skipped)
        484 - OilIntegration.std_unordered_map_int_int (Skipped)
        485 - OilIntegration.std_tuple_uint64_uint64 (Skipped)
        486 - OilIntegration.std_string_empty (Skipped)
        487 - OilIntegration.std_string_sso (Skipped)
        488 - OilIntegration.std_string_heap_allocated (Skipped)
        489 - OilIntegration.std_stack_int_empty (Skipped)
        490 - OilIntegration.std_stack_int_some (Skipped)
        491 - OilIntegration.std_stack_stack_int_empty (Skipped)
        492 - OilIntegration.std_stack_stack_int_some (Skipped)
        493 - OilIntegration.std_stack_adapter_vector_empty (Skipped)
        494 - OilIntegration.std_stack_adapter_vector_some (Skipped)
        514 - OilIntegration.std_reference_wrapper_int (Skipped)
        515 - OilIntegration.std_reference_wrapper_vector (Skipped)
        516 - OilIntegration.std_queue_int_empty (Skipped)
        517 - OilIntegration.std_queue_int_some (Skipped)
        518 - OilIntegration.std_queue_queue_int_empty (Skipped)
        519 - OilIntegration.std_queue_queue_int_some (Skipped)
        520 - OilIntegration.std_queue_adapter_vector_empty (Skipped)
        521 - OilIntegration.std_queue_adapter_vector_some (Skipped)
        522 - OilIntegration.std_priority_queue_int_empty (Skipped)
        523 - OilIntegration.std_priority_queue_int_some (Skipped)
        524 - OilIntegration.std_priority_queue_adapter_deque_empty (Skipped)
        525 - OilIntegration.std_priority_queue_adapter_deque_some (Skipped)
        526 - OilIntegration.std_pair_uint64_uint64 (Skipped)
        527 - OilIntegration.std_pair_uint64_uint32 (Skipped)
        528 - OilIntegration.std_pair_vector_vector (Skipped)
        536 - OilIntegration.std_list_del_allocator_a (Skipped)
        537 - OilIntegration.std_deque_del_allocator_a (Skipped)
        538 - OilIntegration.std_deque_int_empty (Skipped)
        539 - OilIntegration.std_deque_int_some (Skipped)
        540 - OilIntegration.std_deque_deque_int_empty (Skipped)
        541 - OilIntegration.std_deque_deque_int_some (Skipped)
        542 - OilIntegration.std_conditional_a (Skipped)
        543 - OilIntegration.std_array_uint64_length_0 (Skipped)
        544 - OilIntegration.std_array_uint64_length_1 (Skipped)
        545 - OilIntegration.std_array_uint64_length_8 (Skipped)
        546 - OilIntegration.std_array_vector_length_1 (Skipped)
        547 - OilIntegration.std_array_vector_length_2 (Skipped)
        548 - OilIntegration.sorted_vector_set_no_ints (Skipped)
        549 - OilIntegration.sorted_vector_set_some_ints (Skipped)
        553 - OilIntegration.references_int_ref (Skipped)
        554 - OilIntegration.references_vector_ref (Skipped)
        574 - OilIntegration.pointers_incomplete_raw_no_follow (Skipped)
        575 - OilIntegration.pointers_incomplete_raw_null (Skipped)
        576 - OilIntegration.pointers_incomplete_unique_ptr (Skipped)
        577 - OilIntegration.pointers_incomplete_unique_ptr_null (Skipped)
        578 - OilIntegration.pointers_incomplete_shared_ptr (Skipped)
        579 - OilIntegration.pointers_incomplete_shared_ptr_null (Skipped)
        580 - OilIntegration.pointers_function_raw (Skipped)
        581 - OilIntegration.pointers_function_raw_null (Skipped)
        582 - OilIntegration.pointers_function_std_function (Skipped)
        583 - OilIntegration.pointers_function_std_function_null (Skipped)
        584 - OilIntegration.pointers_int (Skipped)
        585 - OilIntegration.pointers_int_no_follow (Skipped)
        586 - OilIntegration.pointers_int_null (Skipped)
        587 - OilIntegration.pointers_void (Skipped)
        588 - OilIntegration.pointers_void_no_follow (Skipped)
        589 - OilIntegration.pointers_void_null (Skipped)
        590 - OilIntegration.pointers_vector (Skipped)
        591 - OilIntegration.pointers_vector_no_follow (Skipped)
        592 - OilIntegration.pointers_vector_null (Skipped)
        597 - OilIntegration.pointers_vector_of_pointers_no_follow (Skipped)
        603 - OilIntegration.namespaces_queue (Skipped)
        604 - OilIntegration.namespaces_stack (Skipped)
        605 - OilIntegration.inheritance_polymorphic_non_dynamic_base_a_as_a (Skipped)
        607 - OilIntegration.inheritance_polymorphic_non_dynamic_base_b_as_a (Skipped)
        608 - OilIntegration.inheritance_polymorphic_non_dynamic_base_b_as_b (Skipped)
        609 - OilIntegration.inheritance_polymorphic_non_dynamic_base_b_no_polymorphic (Skipped)
        610 - OilIntegration.inheritance_polymorphic_non_dynamic_base_c_as_a (Skipped)
        611 - OilIntegration.inheritance_polymorphic_non_dynamic_base_c_as_b (Skipped)
        612 - OilIntegration.inheritance_polymorphic_non_dynamic_base_c_as_c (Skipped)
        613 - OilIntegration.inheritance_polymorphic_non_dynamic_base_c_no_polymorphic (Skipped)
        614 - OilIntegration.inheritance_polymorphic_diamond_root_as_root (Skipped)
        615 - OilIntegration.inheritance_polymorphic_diamond_middle1_as_root (Skipped)
        616 - OilIntegration.inheritance_polymorphic_diamond_middle1_as_middle1 (Skipped)
        617 - OilIntegration.inheritance_polymorphic_diamond_middle2_as_root (Skipped)
        618 - OilIntegration.inheritance_polymorphic_diamond_middle2_as_middle2 (Skipped)
        619 - OilIntegration.inheritance_polymorphic_diamond_child_as_middle1_root (Skipped)
        620 - OilIntegration.inheritance_polymorphic_diamond_child_as_middle2_root (Skipped)
        621 - OilIntegration.inheritance_polymorphic_diamond_child_as_middle1 (Skipped)
        622 - OilIntegration.inheritance_polymorphic_diamond_child_as_middle2 (Skipped)
        623 - OilIntegration.inheritance_polymorphic_diamond_child_as_child (Skipped)
        624 - OilIntegration.inheritance_polymorphic_a_as_a (Skipped)
        625 - OilIntegration.inheritance_polymorphic_b_as_a (Skipped)
        626 - OilIntegration.inheritance_polymorphic_b_as_b (Skipped)
        627 - OilIntegration.inheritance_polymorphic_c_as_a (Skipped)
        628 - OilIntegration.inheritance_polymorphic_c_as_b (Skipped)
        629 - OilIntegration.inheritance_polymorphic_c_as_c (Skipped)
        635 - OilIntegration.ignored_a (Skipped)
        639 - OilIntegration.folly_sorted_vector_map_int_vector_empty (Skipped)
        640 - OilIntegration.folly_sorted_vector_map_int_vector_some (Skipped)
        656 - OilIntegration.fbstring_empty (Skipped)
        657 - OilIntegration.fbstring_inline (Skipped)
        658 - OilIntegration.fbstring_heap_allocated (Skipped)
        659 - OilIntegration.fbstring_string_pooled (Skipped)
        670 - OilIntegration.enums_anonymous (Skipped)
        672 - OilIntegration.cycles_unique_ptr (Skipped)
        673 - OilIntegration.cycles_shared_ptr (Skipped)
        674 - OilIntegration.bitfields_single (Skipped)
        675 - OilIntegration.bitfields_within_bytes (Skipped)
        676 - OilIntegration.bitfields_straddle_bytes (Skipped)
        677 - OilIntegration.bitfields_mixed (Skipped)
        678 - OilIntegration.bitfields_more_bits_than_type (Skipped)
        679 - OilIntegration.bitfields_zero_bits (Skipped)
        680 - OilIntegration.bitfields_enum (Skipped)
        682 - OilIntegration.arrays_member_int0 (Skipped)
        684 - OilIntegration.arrays_direct_int10 (Skipped)
        685 - OilIntegration.arrays_direct_int0 (Skipped)
        686 - OilIntegration.arrays_ref_int10 (Skipped)
        687 - OilIntegration.arrays_ref_int0 (Skipped)
        689 - OilIntegration.anonymous_anon_struct_ptr (Skipped)
        690 - OilIntegration.anonymous_anon_union (Skipped)
        692 - OilIntegration.alignment_container_struct (Skipped)
        694 - OilIntegration.alignment_container_two_members (Skipped)
        696 - OilIntegration.alignment_container_member_alignment (Skipped)
        698 - OilIntegration.alignment_container_union_member (Skipped)
        700 - OilIntegration.alignment_container_member_override (Skipped)
        702 - OilIntegration.alignment_container_member_lower (Skipped)

The following tests FAILED:
          9 - AddChildrenTest.InheritancePolymorphic (Failed)
         40 - DrgnParserTest.Container (Failed)
         55 - DrgnParserTest.ClassTemplateVector (Failed)
        177 - integration_py (Timeout)
        178 - OidIntegration.unions_int (Failed)
        179 - OidIntegration.unions_vector (Failed)
        180 - OidIntegration.unions_unordered_map (Failed)
        181 - OidIntegration.unions_alignment (Failed)
        182 - OidIntegration.unions_tagged_int (Failed)
        183 - OidIntegration.unions_tagged_vector (Failed)
        184 - OidIntegration.unions_tagged_unordered_map (Failed)
        185 - OidIntegration.typedefs_c_style (Failed)
        186 - OidIntegration.typedefs_using (Failed)
        187 - OidIntegration.typedefs_container (Failed)
        188 - OidIntegration.typedefs_anonymous (Failed)
        189 - OidIntegration.typedefed_parent_simple_typedef_parent (Failed)
        190 - OidIntegration.typedefed_parent_multilevel_typedef_parent (Failed)
        191 - OidIntegration.templates_int (Failed)
        192 - OidIntegration.templates_vector (Failed)
        193 - OidIntegration.templates_two (Failed)
        194 - OidIntegration.templates_value (Failed)
        195 - OidIntegration.std_vector_del_allocator_a (Failed)
        196 - OidIntegration.std_vector_int_empty (Failed)
        197 - OidIntegration.std_vector_int_some (Failed)
        200 - OidIntegration.std_vector_vector_int_empty (Failed)
        201 - OidIntegration.std_vector_vector_int_some (Failed)
        202 - OidIntegration.std_vector_reserve (Failed)
        203 - OidIntegration.std_variant_char_int64_1 (Failed)
        204 - OidIntegration.std_variant_char_int64_2 (Failed)
        205 - OidIntegration.std_variant_vector_int_1 (Failed)
        206 - OidIntegration.std_variant_vector_int_2 (Failed)
        207 - OidIntegration.std_variant_optional (Failed)
        208 - OidIntegration.std_variant_empty (Failed)
        209 - OidIntegration.std_variant_256_params_256 (Failed)
        210 - OidIntegration.std_variant_256_params_empty (Failed)
        211 - OidIntegration.std_unordered_set_custom_operator_a (Failed)
        212 - OidIntegration.std_unordered_multiset_custom_operator_a (Failed)
        213 - OidIntegration.std_unordered_multimap_custom_operator_a (Failed)
        214 - OidIntegration.std_unordered_map_custom_operator_a (Failed)
        216 - OidIntegration.std_tuple_uint64_uint64 (Failed)
        217 - OidIntegration.std_string_empty (Failed)
        218 - OidIntegration.std_string_sso (Failed)
        219 - OidIntegration.std_string_heap_allocated (Failed)
        220 - OidIntegration.std_stack_int_empty (Failed)
        221 - OidIntegration.std_stack_int_some (Failed)
        222 - OidIntegration.std_stack_stack_int_empty (Failed)
        223 - OidIntegration.std_stack_stack_int_some (Failed)
        224 - OidIntegration.std_stack_adapter_vector_empty (Failed)
        225 - OidIntegration.std_stack_adapter_vector_some (Failed)
        226 - OidIntegration.std_smart_ptr_unique_ptr_uint64_empty (Failed)
        227 - OidIntegration.std_smart_ptr_unique_ptr_uint64_present (Failed)
        228 - OidIntegration.std_smart_ptr_unique_ptr_vector_empty (Failed)
        229 - OidIntegration.std_smart_ptr_unique_ptr_vector_present (Failed)
        230 - OidIntegration.std_smart_ptr_unique_ptr_void_empty (Failed)
        231 - OidIntegration.std_smart_ptr_unique_ptr_void_present (Failed)
        232 - OidIntegration.std_smart_ptr_shared_ptr_uint64_empty (Failed)
        233 - OidIntegration.std_smart_ptr_shared_ptr_uint64_present (Failed)
        234 - OidIntegration.std_smart_ptr_shared_ptr_vector_empty (Failed)
        235 - OidIntegration.std_smart_ptr_shared_ptr_vector_present (Failed)
        236 - OidIntegration.std_smart_ptr_shared_ptr_void_empty (Failed)
        237 - OidIntegration.std_smart_ptr_shared_ptr_void_present (Failed)
        238 - OidIntegration.std_smart_ptr_weak_ptr_int64_empty (Failed)
        239 - OidIntegration.std_smart_ptr_weak_ptr_int64_void_empty (Failed)
        240 - OidIntegration.std_smart_ptr_weak_ptr_int64_present (Failed)
        241 - OidIntegration.std_smart_ptr_weak_ptr_int64_expired (Failed)
        242 - OidIntegration.std_smart_ptr_weak_ptr_int64_present_chase (Failed)
        243 - OidIntegration.std_smart_ptr_weak_ptr_int64_expired_chase (Failed)
        244 - OidIntegration.std_set_custom_comparator_a (Failed)
        245 - OidIntegration.std_reference_wrapper_int (Failed)
        246 - OidIntegration.std_reference_wrapper_vector (Failed)
        247 - OidIntegration.std_queue_int_empty (Failed)
        248 - OidIntegration.std_queue_int_some (Failed)
        249 - OidIntegration.std_queue_queue_int_empty (Failed)
        250 - OidIntegration.std_queue_queue_int_some (Failed)
        251 - OidIntegration.std_queue_adapter_vector_empty (Failed)
        252 - OidIntegration.std_queue_adapter_vector_some (Failed)
        253 - OidIntegration.std_priority_queue_int_empty (Failed)
        254 - OidIntegration.std_priority_queue_int_some (Failed)
        255 - OidIntegration.std_priority_queue_adapter_deque_empty (Failed)
        256 - OidIntegration.std_priority_queue_adapter_deque_some (Failed)
        257 - OidIntegration.std_pair_uint64_uint64 (Failed)
        258 - OidIntegration.std_pair_uint64_uint32 (Failed)
        259 - OidIntegration.std_pair_vector_vector (Failed)
        260 - OidIntegration.std_optional_uint64_empty (Failed)
        261 - OidIntegration.std_optional_uint64_present (Failed)
        262 - OidIntegration.std_optional_vector_empty (Failed)
        263 - OidIntegration.std_optional_vector_present (Failed)
        264 - OidIntegration.std_multiset_custom_comparator_a (Failed)
        265 - OidIntegration.std_multimap_custom_comparator_a (Failed)
        266 - OidIntegration.std_map_custom_comparator_a (Failed)
        267 - OidIntegration.std_list_del_allocator_a (Failed)
        268 - OidIntegration.std_deque_del_allocator_a (Failed)
        269 - OidIntegration.std_deque_int_empty (Failed)
        270 - OidIntegration.std_deque_int_some (Failed)
        271 - OidIntegration.std_deque_deque_int_empty (Failed)
        272 - OidIntegration.std_deque_deque_int_some (Failed)
        273 - OidIntegration.std_conditional_a (Failed)
        274 - OidIntegration.std_array_uint64_length_0 (Failed)
        275 - OidIntegration.std_array_uint64_length_1 (Failed)
        276 - OidIntegration.std_array_uint64_length_8 (Failed)
        277 - OidIntegration.std_array_vector_length_1 (Failed)
        278 - OidIntegration.std_array_vector_length_2 (Failed)
        279 - OidIntegration.sorted_vector_set_no_ints (Failed)
        280 - OidIntegration.sorted_vector_set_some_ints (Failed)
        281 - OidIntegration.simple_struct (Failed)
        282 - OidIntegration.simple_class (Failed)
        283 - OidIntegration.simple_union (Failed)
        286 - OidIntegration.primitives_short (Failed)
        287 - OidIntegration.primitives_ushort (Failed)
        288 - OidIntegration.primitives_int (Failed)
        289 - OidIntegration.primitives_uint (Failed)
        290 - OidIntegration.primitives_long (Failed)
        291 - OidIntegration.primitives_ulong (Failed)
        292 - OidIntegration.primitives_longlong (Failed)
        293 - OidIntegration.primitives_ulonglong (Failed)
        294 - OidIntegration.primitives_bool (Failed)
        295 - OidIntegration.primitives_char (Failed)
        296 - OidIntegration.primitives_uchar (Failed)
        297 - OidIntegration.primitives_schar (Failed)
        298 - OidIntegration.primitives_wchar_t (Failed)
        299 - OidIntegration.primitives_char8_t (Failed)
        300 - OidIntegration.primitives_char16_t (Failed)
        301 - OidIntegration.primitives_char32_t (Failed)
        302 - OidIntegration.primitives_float (Failed)
        303 - OidIntegration.primitives_double (Failed)
        304 - OidIntegration.primitives_long_double (Failed)
        308 - OidIntegration.pointers_incomplete_unique_ptr (Failed)
        309 - OidIntegration.pointers_incomplete_unique_ptr_null (Failed)
        310 - OidIntegration.pointers_incomplete_shared_ptr (Failed)
        311 - OidIntegration.pointers_incomplete_shared_ptr_null (Failed)
        312 - OidIntegration.pointers_incomplete_containing_struct (Failed)
        328 - OidIntegration.pointers_struct_primitive_ptrs (Failed)
        329 - OidIntegration.pointers_struct_primitive_ptrs_no_follow (Failed)
        330 - OidIntegration.pointers_struct_primitive_ptrs_null (Failed)
        331 - OidIntegration.pointers_struct_vector_ptr (Failed)
        332 - OidIntegration.pointers_struct_vector_ptr_no_follow (Failed)
        333 - OidIntegration.pointers_struct_vector_ptr_null (Failed)
        334 - OidIntegration.pointers_vector_of_pointers (Failed)
        336 - OidIntegration.pointers_feature_flag_disabled (Failed)
        337 - OidIntegration.pointers_feature_config (Failed)
        338 - OidIntegration.padding_bool_padding (Failed)
        339 - OidIntegration.padding_nested_padding (Failed)
        341 - OidIntegration.packed_a (Failed)
        342 - OidIntegration.namespaces_queue (Failed)
        343 - OidIntegration.namespaces_stack (Failed)
        344 - OidIntegration.multi_arg_a (Failed)
        345 - OidIntegration.multi_arg_tb_fail_first_arg (Failed)
        346 - OidIntegration.multi_arg_tb_all_fail_crashes (Failed)
        347 - OidIntegration.inheritance_polymorphic_non_dynamic_base_a_as_a (Failed)
        348 - OidIntegration.inheritance_polymorphic_non_dynamic_base_a_no_polymorphic (Failed)
        349 - OidIntegration.inheritance_polymorphic_non_dynamic_base_b_as_a (Failed)
        350 - OidIntegration.inheritance_polymorphic_non_dynamic_base_b_as_b (Failed)
        351 - OidIntegration.inheritance_polymorphic_non_dynamic_base_b_no_polymorphic (Failed)
        352 - OidIntegration.inheritance_polymorphic_non_dynamic_base_c_as_a (Failed)
        353 - OidIntegration.inheritance_polymorphic_non_dynamic_base_c_as_b (Failed)
        354 - OidIntegration.inheritance_polymorphic_non_dynamic_base_c_as_c (Failed)
        355 - OidIntegration.inheritance_polymorphic_non_dynamic_base_c_no_polymorphic (Failed)
        356 - OidIntegration.inheritance_polymorphic_diamond_root_as_root (Failed)
        357 - OidIntegration.inheritance_polymorphic_diamond_middle1_as_root (Failed)
        358 - OidIntegration.inheritance_polymorphic_diamond_middle1_as_middle1 (Failed)
        359 - OidIntegration.inheritance_polymorphic_diamond_middle2_as_root (Failed)
        360 - OidIntegration.inheritance_polymorphic_diamond_middle2_as_middle2 (Failed)
        361 - OidIntegration.inheritance_polymorphic_diamond_child_as_middle1_root (Failed)
        362 - OidIntegration.inheritance_polymorphic_diamond_child_as_middle2_root (Failed)
        363 - OidIntegration.inheritance_polymorphic_diamond_child_as_middle1 (Failed)
        364 - OidIntegration.inheritance_polymorphic_diamond_child_as_middle2 (Failed)
        365 - OidIntegration.inheritance_polymorphic_diamond_child_as_child (Failed)
        366 - OidIntegration.inheritance_polymorphic_a_as_a (Failed)
        367 - OidIntegration.inheritance_polymorphic_b_as_a (Failed)
        368 - OidIntegration.inheritance_polymorphic_b_as_b (Failed)
        369 - OidIntegration.inheritance_polymorphic_c_as_a (Failed)
        370 - OidIntegration.inheritance_polymorphic_c_as_b (Failed)
        371 - OidIntegration.inheritance_polymorphic_c_as_c (Failed)
        372 - OidIntegration.inheritance_multiple_a (Failed)
        373 - OidIntegration.inheritance_access_public (Failed)
        374 - OidIntegration.inheritance_access_protected (Failed)
        375 - OidIntegration.inheritance_access_private (Failed)
        376 - OidIntegration.inheritance_access_public_as_base (Failed)
        377 - OidIntegration.ignored_a (Failed)
        378 - OidIntegration.folly_sorted_vector_map_int_int_empty (Failed)
        379 - OidIntegration.folly_sorted_vector_map_int_int_some (Failed)
        380 - OidIntegration.folly_sorted_vector_map_int_int_reserve (Failed)
        383 - OidIntegration.folly_small_vector_int_default_empty (Failed)
        384 - OidIntegration.folly_small_vector_int_default_inlined (Failed)
        385 - OidIntegration.folly_small_vector_int_default_overflow (Failed)
        386 - OidIntegration.folly_small_vector_vector_3_empty (Failed)
        387 - OidIntegration.folly_small_vector_vector_3_inlined (Failed)
        388 - OidIntegration.folly_small_vector_vector_3_overflow (Failed)
        389 - OidIntegration.folly_small_vector_int_always_heap (Failed)
        390 - OidIntegration.folly_f14_vector_set_a (Failed)
        391 - OidIntegration.folly_f14_vector_map_a (Failed)
        392 - OidIntegration.folly_f14_value_set_a (Failed)
        393 - OidIntegration.folly_f14_value_map_a (Failed)
        394 - OidIntegration.folly_f14_node_set_a (Failed)
        395 - OidIntegration.folly_f14_node_map_a (Failed)
        396 - OidIntegration.folly_f14_fast_set_a (Failed)
        397 - OidIntegration.folly_f14_fast_map_a (Failed)
        398 - OidIntegration.fbstring_empty (Failed)
        399 - OidIntegration.fbstring_inline (Failed)
        400 - OidIntegration.fbstring_heap_allocated (Failed)
        401 - OidIntegration.fbstring_string_pooled (Failed)
        402 - OidIntegration.enums_params_scoped_enum_type (Failed)
        403 - OidIntegration.enums_params_scoped_enum_val_cast (Failed)
        404 - OidIntegration.enums_params_scoped_enum_val (Failed)
        405 - OidIntegration.enums_params_scoped_enum_val_gaps (Failed)
        406 - OidIntegration.enums_params_scoped_enum_val_negative (Failed)
        407 - OidIntegration.enums_params_unscoped_enum_type (Failed)
        408 - OidIntegration.enums_params_unscoped_enum_val_cast (Failed)
        409 - OidIntegration.enums_scoped (Failed)
        410 - OidIntegration.enums_scoped_uint8 (Failed)
        411 - OidIntegration.enums_unscoped (Failed)
        413 - OidIntegration.enums_paired_with_element (Failed)
        414 - OidIntegration.cycles_raw_ptr (Failed)
        415 - OidIntegration.cycles_raw_ptr_wrapped (Failed)
        416 - OidIntegration.cycles_unique_ptr (Failed)
        417 - OidIntegration.cycles_shared_ptr (Failed)
        418 - OidIntegration.bitfields_single (Failed)
        419 - OidIntegration.bitfields_within_bytes (Failed)
        420 - OidIntegration.bitfields_straddle_bytes (Failed)
        421 - OidIntegration.bitfields_mixed (Failed)
        423 - OidIntegration.bitfields_zero_bits (Failed)
        424 - OidIntegration.bitfields_enum (Failed)
        425 - OidIntegration.arrays_member_int10 (Failed)
        426 - OidIntegration.arrays_member_int0 (Failed)
        427 - OidIntegration.arrays_multidim_legacy (Failed)
        428 - OidIntegration.arrays_multidim (Failed)
        433 - OidIntegration.anonymous_regular_struct (Failed)
        434 - OidIntegration.anonymous_anon_struct (Failed)
        436 - OidIntegration.anonymous_anon_typedef (Failed)
        437 - OidIntegration.anonymous_anon_union (Failed)
        438 - OidIntegration.anonymous_nested_anon_struct (Failed)
        439 - OidIntegration.alignment_wrapper_struct (Failed)
        441 - OidIntegration.alignment_wrapper_two_members (Failed)
        443 - OidIntegration.alignment_wrapper_member_alignment (Failed)
        445 - OidIntegration.alignment_wrapper_union_member (Failed)
        447 - OidIntegration.alignment_wrapper_member_override (Failed)
        449 - OidIntegration.alignment_wrapper_member_lower (Failed)
        451 - OilIntegration.unions_int (Failed)
        452 - OilIntegration.unions_vector (Failed)
        453 - OilIntegration.unions_unordered_map (Failed)
        454 - OilIntegration.unions_alignment (Failed)
        455 - OilIntegration.unions_tagged_int (Failed)
        456 - OilIntegration.unions_tagged_vector (Failed)
        457 - OilIntegration.unions_tagged_unordered_map (Failed)
        458 - OilIntegration.typedefed_parent_simple_typedef_parent (Failed)
        459 - OilIntegration.typedefed_parent_multilevel_typedef_parent (Failed)
        461 - OilIntegration.templates_vector (Failed)
        463 - OilIntegration.templates_value (Failed)
        465 - OilIntegration.std_vector_int_empty (Failed)
        466 - OilIntegration.std_vector_int_some (Failed)
        469 - OilIntegration.std_vector_vector_int_empty (Failed)
        470 - OilIntegration.std_vector_vector_int_some (Failed)
        471 - OilIntegration.std_vector_reserve (Failed)
        480 - OilIntegration.std_unordered_set_custom_operator_a (Failed)
        481 - OilIntegration.std_unordered_multiset_custom_operator_a (Failed)
        482 - OilIntegration.std_unordered_multimap_custom_operator_a (Failed)
        483 - OilIntegration.std_unordered_map_custom_operator_a (Failed)
        495 - OilIntegration.std_smart_ptr_unique_ptr_uint64_empty (Failed)
        496 - OilIntegration.std_smart_ptr_unique_ptr_uint64_present (Failed)
        497 - OilIntegration.std_smart_ptr_unique_ptr_vector_empty (Failed)
        498 - OilIntegration.std_smart_ptr_unique_ptr_vector_present (Failed)
        499 - OilIntegration.std_smart_ptr_unique_ptr_void_empty (Failed)
        500 - OilIntegration.std_smart_ptr_unique_ptr_void_present (Failed)
        501 - OilIntegration.std_smart_ptr_shared_ptr_uint64_empty (Failed)
        502 - OilIntegration.std_smart_ptr_shared_ptr_uint64_present (Failed)
        503 - OilIntegration.std_smart_ptr_shared_ptr_vector_empty (Failed)
        504 - OilIntegration.std_smart_ptr_shared_ptr_vector_present (Failed)
        505 - OilIntegration.std_smart_ptr_shared_ptr_void_empty (Failed)
        506 - OilIntegration.std_smart_ptr_shared_ptr_void_present (Failed)
        507 - OilIntegration.std_smart_ptr_weak_ptr_int64_empty (Failed)
        508 - OilIntegration.std_smart_ptr_weak_ptr_int64_void_empty (Failed)
        509 - OilIntegration.std_smart_ptr_weak_ptr_int64_present (Failed)
        510 - OilIntegration.std_smart_ptr_weak_ptr_int64_expired (Failed)
        511 - OilIntegration.std_smart_ptr_weak_ptr_int64_present_chase (Failed)
        512 - OilIntegration.std_smart_ptr_weak_ptr_int64_expired_chase (Failed)
        513 - OilIntegration.std_set_custom_comparator_a (Failed)
        529 - OilIntegration.std_optional_uint64_empty (Failed)
        530 - OilIntegration.std_optional_uint64_present (Failed)
        531 - OilIntegration.std_optional_vector_empty (Failed)
        532 - OilIntegration.std_optional_vector_present (Failed)
        533 - OilIntegration.std_multiset_custom_comparator_a (Failed)
        534 - OilIntegration.std_multimap_custom_comparator_a (Failed)
        535 - OilIntegration.std_map_custom_comparator_a (Failed)
        550 - OilIntegration.simple_struct (Failed)
        551 - OilIntegration.simple_class (Failed)
        552 - OilIntegration.simple_union (Failed)
        555 - OilIntegration.primitives_short (Failed)
        556 - OilIntegration.primitives_ushort (Failed)
        557 - OilIntegration.primitives_int (Failed)
        558 - OilIntegration.primitives_uint (Failed)
        559 - OilIntegration.primitives_long (Failed)
        560 - OilIntegration.primitives_ulong (Failed)
        561 - OilIntegration.primitives_longlong (Failed)
        562 - OilIntegration.primitives_ulonglong (Failed)
        563 - OilIntegration.primitives_bool (Failed)
        564 - OilIntegration.primitives_char (Failed)
        565 - OilIntegration.primitives_uchar (Failed)
        566 - OilIntegration.primitives_schar (Failed)
        567 - OilIntegration.primitives_wchar_t (Failed)
        568 - OilIntegration.primitives_char8_t (Failed)
        569 - OilIntegration.primitives_char16_t (Failed)
        570 - OilIntegration.primitives_char32_t (Failed)
        571 - OilIntegration.primitives_float (Failed)
        572 - OilIntegration.primitives_double (Failed)
        573 - OilIntegration.primitives_long_double (Failed)
        593 - OilIntegration.pointers_struct_primitive_ptrs_no_follow (Failed)
        594 - OilIntegration.pointers_struct_primitive_ptrs_null (Failed)
        595 - OilIntegration.pointers_struct_vector_ptr_no_follow (Failed)
        596 - OilIntegration.pointers_struct_vector_ptr_null (Failed)
        598 - OilIntegration.pointers_feature_flag_disabled (Failed)
        599 - OilIntegration.padding_bool_padding (Failed)
        600 - OilIntegration.padding_nested_padding (Failed)
        601 - OilIntegration.padding_parent_padding (Failed)
        602 - OilIntegration.packed_a (Failed)
        606 - OilIntegration.inheritance_polymorphic_non_dynamic_base_a_no_polymorphic (Failed)
        630 - OilIntegration.inheritance_multiple_a (Failed)
        631 - OilIntegration.inheritance_access_public (Failed)
        632 - OilIntegration.inheritance_access_protected (Failed)
        633 - OilIntegration.inheritance_access_private (Failed)
        634 - OilIntegration.inheritance_access_public_as_base (Failed)
        636 - OilIntegration.folly_sorted_vector_map_int_int_empty (Failed)
        637 - OilIntegration.folly_sorted_vector_map_int_int_some (Failed)
        638 - OilIntegration.folly_sorted_vector_map_int_int_reserve (Failed)
        641 - OilIntegration.folly_small_vector_int_default_empty (Failed)
        642 - OilIntegration.folly_small_vector_int_default_inlined (Failed)
        643 - OilIntegration.folly_small_vector_int_default_overflow (Failed)
        644 - OilIntegration.folly_small_vector_vector_3_empty (Failed)
        645 - OilIntegration.folly_small_vector_vector_3_inlined (Failed)
        646 - OilIntegration.folly_small_vector_vector_3_overflow (Failed)
        647 - OilIntegration.folly_small_vector_int_always_heap (Failed)
        648 - OilIntegration.folly_f14_vector_set_a (Failed)
        649 - OilIntegration.folly_f14_vector_map_a (Failed)
        650 - OilIntegration.folly_f14_value_set_a (Failed)
        651 - OilIntegration.folly_f14_value_map_a (Failed)
        652 - OilIntegration.folly_f14_node_set_a (Failed)
        653 - OilIntegration.folly_f14_node_map_a (Failed)
        654 - OilIntegration.folly_f14_fast_set_a (Failed)
        655 - OilIntegration.folly_f14_fast_map_a (Failed)
        660 - OilIntegration.enums_params_scoped_enum_type (Failed)
        661 - OilIntegration.enums_params_scoped_enum_val_cast (Failed)
        662 - OilIntegration.enums_params_scoped_enum_val (Failed)
        663 - OilIntegration.enums_params_scoped_enum_val_gaps (Failed)
        664 - OilIntegration.enums_params_scoped_enum_val_negative (Failed)
        665 - OilIntegration.enums_params_unscoped_enum_type (Failed)
        666 - OilIntegration.enums_params_unscoped_enum_val_cast (Failed)
        667 - OilIntegration.enums_scoped (Failed)
        668 - OilIntegration.enums_scoped_uint8 (Failed)
        669 - OilIntegration.enums_unscoped (Failed)
        671 - OilIntegration.enums_paired_with_element (Failed)
        681 - OilIntegration.arrays_member_int10 (Failed)
        683 - OilIntegration.arrays_multidim (Failed)
        688 - OilIntegration.anonymous_regular_struct (Failed)
        691 - OilIntegration.alignment_wrapper_struct (Failed)
        693 - OilIntegration.alignment_wrapper_two_members (Failed)
        695 - OilIntegration.alignment_wrapper_member_alignment (Failed)
        697 - OilIntegration.alignment_wrapper_union_member (Failed)
        699 - OilIntegration.alignment_wrapper_member_override (Failed)
        701 - OilIntegration.alignment_wrapper_member_lower (Failed)
Errors while running CTest

Codecov Report

Merging #360 (48a92a0) into main (c766d7b) will decrease coverage by 21.43%.
Report is 2 commits behind head on main.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main     #360       +/-   ##
===========================================
- Coverage   68.00%   46.58%   -21.43%
===========================================
  Files         114      101       -13
  Lines       11144    10811      -333
  Branches     1864     1811       -53
===========================================
- Hits         7579     5036     -2543
- Misses       2596     4924     +2328
+ Partials      969      851      -118

Files Changed
Coverage Δ

oi/PaddingHunter.cpp
86.11% <ø> (ø)

... and 72 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

On the testing, you got it pretty much right. The tests that failed when you manually tested it all ran in the CI and on my machine fine. make test-static is an internal only artifact that shouldn't be in this repo. As an early external contributor you're getting the worst of it. Opened an issue for us to update this text #363.


Payment::search does not add the filters to the HTTP request

When searching a Payment with an external_reference the filters do not work (brings all payments) and it doesn't appear on the api request object (Http request). After looking at the source in the class MPBase the method processMethodBulk does not use the filters at all unless there is a ":" character on the path.
I think this issue might be related to:
https://github.com/mercadopago/dx-java/issues/72
https://github.com/mercadopago/dx-java/issues/75

Hay alguna novedad?
Gracias.

Tengo el mismo error, luego de actualizar la librería a v1.0.36. Pareciera haber un pull request que lo soluciona, pero no está realizado.

The issue was solved in version 1.1.0.


[BEAM-1941] Add Source Watermark Metrics

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[ ] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[ ] Make sure tests pass via mvn clean verify.
[ ] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

R: @aviemzur  Not fully finish yes, the min amongst all splits watermark need some discussion.

Coverage increased (+0.01%) to 69.988% when pulling 4e6b980092185fb314ab177c98a76f18111add4d on JingsongLi:BEAM-1941-watermark into 7d6f8bde707191e7354e08630f332a3a68c659f7 on apache:master.

@aviemzur It is ready to review now.

Changes Unknown when pulling 488acbb7c1e25ee2992d5bfc77a7b5b98d5479f7 on JingsongLi:BEAM-1941-watermark into ** on apache:master**.

retest this please

Changes Unknown when pulling 488acbb7c1e25ee2992d5bfc77a7b5b98d5479f7 on JingsongLi:BEAM-1941-watermark into ** on apache:master**.

As per chat with @JingsongLi a proposal will be coming for this written by him and sent to the dev list.

@JingsongLi, is this PR maybe obsolete in light of the discussion on the dev@ list?

I will take a reminder to dev@ list.


Add Amazon Linux 2 and aarch64 tarball support

I noticed this module would support the older rhel/centos 6 based Amazon 1, but not the newer Amazon 2. In an x86_64 install, it should be able to find the correct package now and it should also be able to start the daemon now.
I also needed to translate between the aarch64 architecture provided by in the OS fact to arm64 as used here - https://download.newrelic.com/infrastructure_agent/binaries/linux/arm64/

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

LGTM, but we need to look into why CI failed

FYI, Amazon Linux 2018 is also EL6 compatible

A new PR has been prepared containing fixes as well as support for older Amazon Linux distributions here: https://github.com/newrelic/infrastructure-agent-puppet/pull/84


Use conan version from host in docker guest

While testing conan==1.0.0-beta.2, it happens that the guest is still running 0.30.3, and some errors are being raised, due to unexpected migrations running, like: https://travis-ci.org/memsharded/conan-tbb/jobs/321763072

It was already fixed some versions ago.


edit-csv broken UI on vscode insider

Bug description
Hello, I heavily rely on your extensions in daily work and very appreciate it.
Recently i turn to vscode insider version to use "Remote SSH" function
But on this version, edit-csv display an broken UI (as below) seems like failure of loading of CSS or js or whatelse

I search the github, someone encounters the same issue: Extension doesn't work with vscode-insider: Git Graph、Edit csv.. In that link the repo owner thinks it is caused by "fundamental change in how the JS & CSS are loaded (as they are stored on the remote system instead of the local machine)."
How to reproduce
Software version

local os: Windows_NT x64 10.0.17763
remote os: Ubuntu 16.04.1
vscode: 1.35.0-insider (system setup)
vscode extensions

Remote - SSH: 0.37.0
Edit csv: 0.0.11

Steps

Install vscode insider and install Remote - SSH
Open an ubuntu remote machine using Remote - SSH
Install edit-csv, it will automatically installed on to the remote side
Create a new csv file on the remote, and use edit csv to display it

Then u can see the what i encountered.
I believe the os version is not correlated, under other os version the bug may also be reproduced.
Notice
Sometimes on the first run after installation of insider, the edit-csv works well. But when u close and reopen the insider, the bug will emerge

Thanks that you already searched for possible reasons :)
I'll look into that in the next few days (probably this weekend).

I've tested a bit and I had no issues. I tested with macOS, windows 10 and remote was Ubuntu 18.04.2.
insider version was: 1.35.0 (2019-05-24)
Could you run a >Developer: Show Running Extensions and check if edit-csv is running remotely (has the >< sign) or not?
I also tested with different setups where the plugin was

installed locally and installed remotely,
installed locally but not remotely (could not be used because not installed)
not installed locally but remotely

they worked all.

The vs code insider download site states that they build daily, so it might be already fixed?

Thank's for the extensive test.
I update my insider version, then the issue disappear(^_^).
I should have told u the release date (Actually I didn't notice it)... The previous version caught issue is released at 2019-05-22T18:07:55.791Z. I run the command as u asked. It shows the edit-csv is running remotely but the UI is still broken. But after i update the insider, the issue all gone.
Maybe i should keep enough patience with a new-born software. Sorry about the time u cost


Add test for checking value after contract deployed after forking

This was brought up by @tcoulter mentioning that sending value to a contract during creation on a chain that resulted from a fork would not persist. This test now checks for the presence of this issue. A separate PR will be made for the resolution of this test.

The test added in this PR failed (as it should) here:

https://travis-ci.org/trufflesuite/ganache-core/jobs/394347307#L2599
https://travis-ci.org/trufflesuite/ganache-core/jobs/394347308#L2551

You can see here that the test shows that the current codebase will fail the test. #125 addresses this issue.

I started to put this in forking.js but the file is already getting a little out of hand. forking.js uses forkedWeb3 instead of mainWeb3 to deploy the contract. It's just a different set of steps and I felt it should be separated as such. I think forking.js should probably be split up as well.


node:os package missing.

Getting node:os package missing. Tried adding this package globally "node:os" don't work. I've added "os" and still getting same error:

Ideally, all dependencies should be installed with original npm install command (isn't that the point?).

hi @mfyz
I’ll check this tomorrow, thanks for the report

Hi again @mfyz
you need to use node version v16.x, i will mention it in the README.md
great regards


ZIP321 URI's not supported

Platform: iPhone 8
I'm trying to post to ZECpages, but Nighthawk wallet doesn't like the QR codes, which are ZIP321 URIs which contain valid zcash addresses. Nighthawk gives me the following error:
"This QR code does not contain a Zcash valid address!"
I've talked with Aditya about this, I know this is on your radar, but I thought it wise to document it here. These URI's have really helped streamline ZECpages' interface, and it'd be great to have them supported in your wallet!
Tiny, comparatively unimportant aside - I think the error message is incorrect and also too alarming. I think a more precise message (in the current implementation) would be "Zcash address not recognized"
EDIT:
Here's a js example. It's surely bulky and under engineered but it works
function parseZaddrOrUri(str) {
  str = str.replace(/ /g, "") // strip whitespace just to be thorough
  let amount = 0;
  let zaddr = "";
  let memo = "";
  const zaddrRegex = /(zs\w{76})/;
  const uriRegex2 = /(zcash:zs\w{76})/;
  const isValid = zaddrRegex.test(str) || uriRegex.test(str)
  if (!isValid) return {error: "Address/URI not recognized."}

  const memoMatch = str.match(/(memo=([^&]*))/);
  const amountMatch = str.match(/(amount=([^&]*))/);
  const zaddrMatch = str.match(zaddrRegex);

  if (memoMatch) memo = memoMatch[2]
  if (amountMatch) amount = amountMatch[2]
  if (zaddrMatch) zaddr = zaddrMatch[0]

  return {memo, amount, zaddr}
}

Some manual tests - I think these are all the permutations you have to handle.
var str = "zcash:zs19dedmnrkhq2pth3jp3cnn6c5jqshnu9ss2fljllm9l0tlgqw0mtpvs9207ecywwtmx7wkrvksvn?amount=0.001&memo=memobase64"
var str2 = "zcash:zs19dedmnrkhq2pth3jp3cnn6c5jqshnu9ss2fljllm9l0tlgqw0mtpvs9207ecywwtmx7wkrvksvn?memo=memobase64"
var str3 = "zcash:zs19dedmnrkhq2pth3jp3cnn6c5jqshnu9ss2fljllm9l0tlgqw0mtpvs9207ecywwtmx7wkrvksvn?amount=0.001"
var str4 = "zcash:zs19dedmnrkhq2pth3jp3cnn6c5jqshnu9ss2fljllm9l0tlgqw0mtpvs9207ecywwtmx7wkrvksvn"
var str5 = "zs19dedmnrkhq2pth3jp3cnn6c5jqshnu9ss2fljllm9l0tlgqw0mtpvs9207ecywwtmx7wkrvksvn"

console.log(parseZaddrOrUri(str))
console.log(parseZaddrOrUri(str2))
console.log(parseZaddrOrUri(str3))
console.log(parseZaddrOrUri(str4))
console.log(parseZaddrOrUri(str5))

https://zips.z.cash/zip-0321


Move getAttachmentFilename to Attachments.subs?

Is there any reason why getAttachmentFilename is in Subs.php?
Wouldn't make more sense to have it in Attachments.subs.php?

Agreed https://github.com/elkarte/Elkarte/pull/2331

Close


.Net: Add Support for "dall-e-3" Model in OpenAITextToImageService Class

Hi,
I propose we add support for the "dall-e-3" model within the OpenAITextToImageService class. The integration seems straightforward and the benefit to the users would be substantial.
Thank you for considering this request.

@Nurgo Please check these notebooks, they use "dall-e-3" model as example for image generation:

https://github.com/microsoft/semantic-kernel/blob/main/dotnet/notebooks/07-DALL-E-3.ipynb
https://github.com/microsoft/semantic-kernel/blob/main/dotnet/notebooks/08-chatGPT-with-DALL-E-3.ipynb

Hi @dmytrostruk , thank you for your reply. These notebooks only use "dall-e-3" if AddAzureOpenAIChatCompletion is used, and not AddOpenAITextToImage. From what I can see in the code, OpenAITextToImageService still uses "dall-e-2". Moreover, the image formats supported (256x256, 512x512, 1024x1024) are those of "dall-e-2".

@Nurgo Got it. Yes, looks like dall-e-3 is only implemented in AzureOpenAITextToImageService class, but not in OpenAITextToImageService.

Hello,
I am interested in adding support for dall-e-3 in OpenAITextToImageService.
The most straightforward way I can think of is by changing the GenerateImageAsync from (a) to (b) in OpenAITextToImageService.cs:
(a): Current version
public Task<string> GenerateImageAsync(string description, int width, int height, Kernel? kernel = null, CancellationToken cancellationToken = default)
{
    Verify.NotNull(description);
    if (width != height || (width != 256 && width != 512 && width != 1024))
    {
        throw new ArgumentOutOfRangeException(nameof(width), width, "OpenAI can generate only square images of size 256x256, 512x512, or 1024x1024.");
    }

    return this.GenerateImageAsync(this._modelId, description, width, height, "url", x => x.Url, cancellationToken);
}

(b): Added support for dall-e-3 image sizes based on documentation available at DALL·E 3 API
public Task<string> GenerateImageAsync(string description, int width, int height, Kernel? kernel = null, CancellationToken cancellationToken = default)
{
    Verify.NotNull(description);

    if (this._modelId == "dall-e-3")
    {
        if (!((width == 1024 && height == 1024) || (width == 1024 && height == 1792) || (width == 1792 && height == 1024)))
        {
            throw new ArgumentOutOfRangeException(nameof(width), width, "DALL·E 3 can generate only images of size 1024x1024, 1024x1792, or 1792x1024.");
        }
    }
    else
    {
        if (width != height || (width != 256 && width != 512 && width != 1024))
        {
            throw new ArgumentOutOfRangeException(nameof(width), width, "OpenAI can generate only square images of size 256x256, 512x512, or 1024x1024.");
        }
    }

    return this.GenerateImageAsync(this._modelId, description, width, height, "url", x => x.Url, cancellationToken);
}

Additionally, I was wondering if we should continue hardcoding the image sizes within the method, or if there might be a better approach, such as using configuration somewhere to manage these values. Any advice on this would be greatly appreciated.
Thank you for your consideration.

The changes we made for the new OpenAI and AzureOpenAI Connectors will bring full support for the dall-e-3 models using OpenAI's TextToImageService.
https://github.com/microsoft/semantic-kernel/blob/feature-connectors-openai/dotnet/src/Connectors/Connectors.OpenAI/Services/OpenAITextToImageService.cs
You can expect a release candidate to be soon release this or next week.
Follow that on our feature-connectors-openai branch.


[Bug][Sort] Missing MySQL CDC connector for Flink 1.15

What happened
Missing MySQL CDC connector for Flink 1.15

What you expected to happen
Add MySQL CDC connector for Flink 1.15
How to reproduce
Download apache-inlong-1.10.0-SNAPSHOT-sort-connectors-flink-v1.15.tar.gz.
Environment
No response
InLong version
master
InLong Component
InLong Sort
Are you willing to submit PR?

[ ] Yes, I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I'll fix the bug.


Update calls-deployment.rst  #7024ly

Solved issue #7024 by replacing with inconsistent table and modified it to read easily
Fixes https://github.com/mattermost/docs/issues/7024

Hello @Pranavram22,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.
Per the Mattermost Contribution Guide, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
Once you have signed the CLA, please comment with /check-cla and confirm that the CLA check is green.
This is a standard procedure for many open source projects.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

/check-cla

Thanks, @Pranavram22, for your documentation contribution. We won't be moving forward with this PR. The request wasn't to reformat the table content as text or sections of text, and the request wasn't limited to one table. The request is to holistically review table formatting across the product documentation site, identify a unified best practice approach, and ensure the proposed path forward adds good value for docs visitors.


Merge MAGIC data subrun-wise is not needed?

In the last weekly meeting Julian gave me a comment that M1 and M2 files may contain different sets of events even if the subrun ID is identical. Then I realized that it could affect the stereo reconstruction of MAGIC-only data, since I usually merge MAGIC DL1 files subrun-wise beforehand, but it may lose some events wrongly recognized as mono events. The best option would be to merge the files run-wise and use them for the stereo reconstruction (which takes more time per job though), and in that case the option --subrun-wise in merge_hdf_files.py is not needed anymore.

In order to avoid a confusion in the analysis, I would suggest to remove this option but I'm not sure who actually use it for the analysis. Please let me know what you think.

Hi Yoshiki, yes, better to remove it at this point. MARS indeed in superstar looks at the subrun before and after the current subrun to look for matching events. If merging run-wise gets all the subruns putting them in a single df and then does the matching, then it is the same behavior as MARS and should be the only one allowed.

OK thanks Alessio, then I will open an pull request to remove the option.


[Bug]: Cloudflare Captcha Don't Click (manualy)

Bug expectation
After open website with cloudflare I expect what click on captcha will trigger it, but instead nothing happen. Any else clicks (on other elements) are valid and work.
That happen only in new headless mode. In old headless captcha could be resolved as usual.

(nothing happen if I click on captcha:)

Bug behavior

[ ] Flaky
[ ] PDF

Minimal, reproducible example
import puppeteer from "puppeteer"

(async () => {
const browser = puppeteer.launch({
 headless: "new",
 args: [
              "--remote-debugging-port=9222",
            '--remote-debugging-address=<IP_ADDRESS>',
]
});
// after that you should go to chrome://inspect, connect to browser, then open page with cloudflare captcha and try resolve it by clicking on it.
})()

Error string
no error
Puppeteer configuration
No response
Puppeteer version
20.2.1
Node version
18.14.2
Package manager
npm
Package manager version
9.5.0
Operating system
Windows

There is not enough information to reproduce the issue. Please provide a runnable script including the test page. I suppose the captcha has some tricks to detect and prevent automation and that might be why it is not working. It is out of scope for Puppeteer though.

@OrKoN are you sure? In old headless mode, all works fine.

ah, you clicking via the screencast feature of DevTools? then yeah, please report it as crbug.com for the DevTools component. I think it should be reproducible without Puppeteer.

Just for note. Reported https://bugs.chromium.org/p/chromium/issues/detail?id=1446264


File icon thumbnail preview missing

Hi,
I've noticed that my Google Drive folder on Chrome OS displays thumbnail previews of many file types.
In the dropbox folder thumbnails are't displayed for PDF files, although image files show a thumbnail. Do you think it would be possible to add PDF thumbnail view in future releases ?

Unfortunately, the answer is no. Dropbox API doesn't support to provide the thumbnail image for PDF. See: https://www.dropbox.com/developers/documentation/http/documentation#files-get_thumbnail

This method currently supports files with the following file extensions: jpg, jpeg, png, tiff, tif, gif and bmp.


spec compatibility

Hi, Starlark spec author here. I'm very happy to see the Rust implementation improving, and that it now has a garbage collector.
In the Compatibility section of your main README, you list a number of places where the language differs from the spec. It would be unfortunate if the Rust implementation did not eventually converge on the spec, given that it was developed after the spec, and that two existing and largely conformant implementations are available for study.
Let's go through the list:
We have plenty of extensions, e.g. type annotations, lambda, recursion.

Lambda (along with nested def) is now a non-optional feature, so you need no longer mention it here.
The Go and Java implementations permit the dynamic check on recursive function calls to be disabled. Does the Rust implementation also allow it to be controlled? If so, you need not mention it here.
We don't have the common extensions of floats, bit operations, byte strings or sets.
Floats and bit operations are not extensions, they are core features. Fortunately they are easy to add. Consider this a request to do so.
Byte strings will be part of the spec fairly soon; they are somewhat tedious to add because they duplicate a lot of the logic of strings, but they don't pose any fundamental difficulty. The Rust implementation in particular sounds like it needs them because its string type is text, not binary. (In Go, text and binary are both represented using byte strings. The story in the Java implementation is more complicated because of entrenched bugs in Bazel.)
Sets are currently a Go-only optional extension.
Our strings are not compliant in several ways, often returning code points instead of singleton strings, and have poor performance.
I plan to change the spec for strings (which is currently true only for the Go impl, from which the spec was derived) so that that strings are defined as sequences of numeric UTF-K codes where K is implementation defined: 8 (byte) for Go, 16 (char) for Java, with no guarantee that the encoding is valid. Conversions to byte strings (encoding) and back (decoding) would be explicit operations.
What value of K would Rust use? I can imagine 8 might be the natural choice, because Rust strings are UTF-8, but they also require valid encodings, which would make the substring operation fail to cut a code point in half, contravening the spec. An alternative would be UTF-32 (in other words, a sequence of int32 code points), but that would require either an inefficient 4-byte representation, or indexing to take linear time. Another possibility is to represent strings as arbitrary byte arrays and to make the Starlark-Rust API do a validity check and conversion when accessing a Starlark string, either failing, or mending the encoding at that point.
Function arguments are sometimes evaluated in the wrong order, which is visible if their arguments have side effects.
This seems like a simple bug to fix. The Go and Java implementations can be studied as a model, and they contain additional comments that rationalize the spec on this point.
We follow proper lexical binding for list comprehensions, so each for clause introduces a fresh variable (deliberately).
I'm not sure what you mean here. How is this different from what the spec requires and the Go and Java implementations do, which is that the comprehension defines a new block, and a for clause is a binding use of its variables?  The hacks in the Java implementation were removed a while back.
We allow comparison between None values (deliberately).
Do you mean ordered comparison? Why deviate from the spec?
In some cases creating circular data structures may lead to stack overflows.
Yeah, this is a problem in all the implementations, and in every imperative language.
We use 32bit fixed size integers. Constructing larger values will result in Starlark failing with an overflow error.
int32 is not enough to represent all the data types that appear in a protocol buffer, for which one needs at least uint64 and int64. Without an int65 data type, you could use int128, but it's easier to use bigint. It really is a nicer language for it, and it needn't be expensive.
I recently changed the Java implementation to use bigint, without loss of efficiency: internally int is a union of three classes similar to java.lang.{Integer,Long,BigInteger}. It was an API change, but not a very disruptive one. Also, I changed the Go implementations to use an mmap trick so that int32 values can be represented as pointers to a special segment, allowing a single pointer to represent a small int or a big int without ambiguity, and without allocation in the int32 case. You might be able to follow the same approach in Rust.
There are a number of minor incompatibilities or places where the spec is unclear, many of which are included in our tests.
Please regard each of these as a bug, either in your implementation, or in our spec, in which case report them to us and we will endeavor to fix them. Starlark users would best served by not having to remember which of three similar dialects they are using in each application, and it's easier to achieve convergence before you have made promises of stability.
cheers
alan

Thanks for the notes! My inclination is to come to a consensus on these things, then take some to the starlark spec channel, some as issues in this repo, and some as fixes to the readme.

The Go and Java implementations permit the dynamic check on recursive function calls to be disabled. Does the Rust implementation also allow it to be controlled? If so, you need not mention it here.

There is no recursion check, so recursion is always enabled. I think that's fine as per the spec (we just hid a specific control option).

We don't have the common extensions of floats, bit operations, byte strings or sets.

Floats and byte strings are definitely on the todo list.

Regarding strings

In Rust, a String must be a UTF8 encoded string - if it's not, interoperability with Rust isn't easy. We want to be as compatible with Starlark as we can, but I think Rust Starlark needs to stick to valid-only UTF8 strings, or we're trading away a huge amount of convenience and performance. We're currently a long way away from the spec, and performance sucks, so we want to do more here - but that pretty much has to be the ultimate underlying representation in Rust, regardless of the Starlark standard.

Function arguments are sometimes evaluated in the wrong order

Yep, it's a bug, but one that has performance implications. I know how to fix it, and plan to do so, but need to benchmark some specific tasks to ensure we don't regress at the same time.

We follow proper lexical binding for list comprehensions

[x for x in x for x in x] defines two variables x - like a list comprehension in Haskell would, rather than one, like Starlark or Python would.

Ordered comparison between None

I don't get why the spec disallows comparison on None. It makes no sense to me. Could you explain?

We use 32bit fixed size integers

Yep, we plan to have a bigint union at some point. It's not pressing for us (Protobuf compatibility isn't that important to us), but it's definitely on the todo list. We also want encoded short strings, and that is a priority, so the plan was strings first, then reuse the techniques to do bigint.

There are a number of minor incompatibilities or places where the spec is unclear

Yep, I'll raise them. As a trivial example, {1:1, 1:2} is valid in Python, but invalid in Go, and I couldn't find the place in the spec that says. Another example, the *args can only appear once, but it doesn't say if **kwargs must be at most once or not.
As for promises of compatibility - don't worry - we're miles off that yet! This is a dynamically evolving project, and we're very happy to find a suitable middle ground on almost all of them.

Thanks for the notes! My inclination is to come to a consensus on these things, then take some to the starlark spec channel, some as issues in this repo, and some as fixes to the readme.

The Go and Java implementations permit the dynamic check on recursive function calls to be disabled. Does the Rust implementation also allow it to be controlled? If so, you need not mention it here.

There is no recursion check, so recursion is always enabled. I think that's fine as per the spec (we just hid a specific control option).

We don't have the common extensions of floats, bit operations, byte strings or sets.

Floats and byte strings are definitely on the todo list.

Regarding strings

In Rust, a String must be a UTF8 encoded string - if it's not, interoperability with Rust isn't easy. We want to be as compatible with Starlark as we can, but I think Rust Starlark needs to stick to valid-only UTF8 strings, or we're trading away a huge amount of convenience and performance. We're currently a long way away from the spec, and performance sucks, so we want to do more here - but that pretty much has to be the ultimate underlying representation in Rust, regardless of the Starlark standard.

Function arguments are sometimes evaluated in the wrong order

Yep, it's a bug, but one that has performance implications. I know how to fix it, and plan to do so, but need to benchmark some specific tasks to ensure we don't regress at the same time.

We follow proper lexical binding for list comprehensions

[x for x in x for x in x] defines two variables x - like a list comprehension in Haskell would, rather than one, like Starlark or Python would.

Ordered comparison between None

I don't get why the spec disallows comparison on None. It makes no sense to me. Could you explain?

We use 32bit fixed size integers

Yep, we plan to have a bigint union at some point. It's not pressing for us (Protobuf compatibility isn't that important to us), but it's definitely on the todo list. We also want encoded short strings, and that is a priority, so the plan was strings first, then reuse the techniques to do bigint.

There are a number of minor incompatibilities or places where the spec is unclear

Yep, I'll raise them. As a trivial example, {1:1, 1:2} is valid in Python, but invalid in Go, and I couldn't find the place in the spec that says. Another example, the *args can only appear once, but it doesn't say if **kwargs must be at most once or not.
As for promises of compatibility - don't worry - we're miles off that yet! This is a dynamically evolving project, and we're very happy to find a suitable middle ground on almost all of them.

FWIW, we eliminated one incompatibility today (leading zeros meaning octal, 7be8744157869cb2c5001b7d9bb686518cd20f96), and I'm working on the call argument order today.

In Rust, a String must be a UTF8 encoded string - if it's not, interoperability with Rust isn't easy. We want to be as compatible with Starlark as we can, but I think Rust Starlark needs to stick to valid-only UTF8 strings, or we're trading away a huge amount of convenience and performance. We're currently a long way away from the spec, and performance sucks, so we want to do more here - but that pretty much has to be the ultimate underlying representation in Rust, regardless of the Starlark standard.

Fair enough. It's essentially an axiom of the design of Starlark that strings should interoperate with those of the host language---hence the UTF-k parameterization compromise between Go and Java. It's interesting that string data types vary so much between languages. I count five different approaches, those of {C,C++,Go}, Java, Python2, {Python3,Haskell}, and Rust. Both Pythons and Java made serious errors in the design of their strings. I have not written substantial Rust, but at least it takes advantage of all the good properties of UTF-8.

We follow proper lexical binding for list comprehensions ...
[x for x in x for x in x] defines two variables x - like a list comprehension in Haskell would, rather than one, like Starlark or Python would.

Are you implying that the proper semantics for list comprehensions in Starlark are not those prescribed by the spec of Starlark, but that of Haskell?

I don't get why the spec disallows comparison on None. It makes no sense to me. Could you explain?

Python2 allowed ordered comparison of arbitrary pairs of values, even of different data types, essentially be defining a total (and totally arbitrary) order over data types. Although it had its uses, too often this served to obscure unintended type errors. Python3 removed this feature, and made ordered comparison much more restricted: only types for which ordering makes sense support ordered comparisons. The disallowed operations included dict < dict, list < tuple, and None < None. Starlark follows Python3 here.

encoded short strings

What do you mean by that?

{1:1, 1:2} is valid in Python, but invalid in Go, and I couldn't find the place in the spec that says.

I never liked that invention of Starlark, but it is prescribed by the spec:
https://github.com/bazelbuild/starlark/blob/master/spec.md#dictionary-expressions
Evaluation fails if the same key is used multiple times.

Another example, the *args can only appear once, but it doesn't say if **kwargs must be at most once or not.

Good catch. Do file a bug for this any similar omissions.

As for promises of compatibility - don't worry - we're miles off that yet! This is a dynamically evolving project, and we're very happy to find a suitable middle ground on almost all of them.

Glad to hear it. Best of luck, and may the two existing implementations help the third.

The fix for call argument ordering landed in 71dec723b7eb40d0b3050c64f7de0e688965aef6, so that's one compatibility down.

Regarding strings

Great, sounds like we're on the same page.

List comprehensions

I suggest I file a ticket at the Starlark spec, outlining what I've done, why I think it's better, and where it differs from Python. It's a somewhat minor detail.

Value and None comparison

Being able to compare values of different types is indeed dodgy. Being able to compare dictionaries has its own problems. But there's absolutely no reason that None doesn't have a well formed comparison, in the same sense that the empty tuple has a well formed comparison. This seems like Python making a mistake.

Encoded short strings

For short int (32bit) we pack the int into the pointer, and use a tag bit, so ints don't end up on the heap, and are super fast. We want to do the same with <= 7bit strings, so those short strings also end up packed into the tag. We then want to have short strings packed in the pointer, and long strings on the heap. Once we have that in place, doing the same with short ints in the pointer and long ints on the heap is nice and easy.

{1:1, 1:2} is valid in Python, but invalid in Go

Should we follow Python here? Is this something reasonable to adjust in the spec? We do have a linter that checks for statically repeated keys in a dictionary, on the basis that's probably not intentional.
I'll go through and file bugs for everything at some point in the near future.

{1:1, 1:2} is valid in Python, but invalid in Go

Should we follow Python here? Is this something reasonable to adjust in the spec? We do have a linter that checks for statically repeated keys in a dictionary, on the basis that's probably not intentional.

What's the benefit of moving from an error to a linter warning here? When I added this restriction, I've found many errors in the existing code at Google. Many code examples I saw were super confusing for a reader. I've fixed dozens of instances, none of them were intentional.
Note that it's consistent with the check that rejects fct(x = 1, x = 2) as well as f(a=1, **{"a": 2}).

{1:1, 1:2}. What's the benefit of moving from an error to a linter warning here?

I think you've convinced me. Before I go as far as code, I guess there are other questions. Is {1: 1, 1: 2} a static error or not, and is {1+1: 1, 2: 1} a runtime error. Equally is {x: 1, x: 2} a static error? Is {f(): 1, f(): 2} a runtime error if the f() evaluates identically, but not an error if each f() returns a different value?

Yes, it's unfortunate we can't catch all the cases statically.
In Python and Starlark, we also have this:
f(a=1, **{"a": 2}) # dynamic error
f(a=1, a=2) # static error

The static check is insufficient, but I'd say it's still useful.
If we were to remove both static and dynamic checks, ignoring the first occurrence would be misleading and harmful, IMO.

Sorry, I have just checked our implementation: the error is dynamic only.
Your examples show the difficulty of catching the problem statically (it would work only for trivial expressions).

Cool - I've just submitted a patch to make repeated dictionary keys in dictionary literals a runtime error. I haven't made anything a compile-time error, but there is a lint-time error, so hopefully it's not too bad. The patch should show up in this repo in the next day or two.

But there's absolutely no reason that None doesn't have a well formed comparison, in the same sense that the empty tuple has a well formed comparison. This seems like Python making a mistake.

Well, comparison on tuples is useful. For consistency, you want to have it on all tuples, even if they're empty.
None is slightly different: there's no value of NoneType where comparison is useful.
Is there any code in your codebase that relies on None comparison? Could you review the code and check if it's legit?

I'm unaware of anyone who does comparison on None, and I doubt it's useful in practice. But looking at other languages, Haskell has comparison on () (which is it's None type), Rust has comparison on () (it's None type). When I've had languages that omit sensible common cases in the defaults it's usually led to less generic code or weird corner cases. Maybe though in Python None is really more like NaN but for values, so maybe that comparison isn't valid. If Python was typed I'd definitely want None to have comparisons, but maybe that's the difference...

8fc366330b644c06c50e6ff0141c2075a5355f19 now fixes the {1:1, 1:2} incompatibility.

FYI: https://github.com/bazelbuild/starlark/commit/7f53743af10f87f0915a2e941baf2e795ea8f3e3 adds support for byte strings to the spec, and begins to clarify the platform-dependent nature of text strings: UTF-8, valid by convention, in Go;  UTF-16, valid by convention, in Java; and UTF-8, valid always, in Rust (though more needs to be said here). It defines the literals and the data type, but another PR is required to specify all the operators and conversions.

We now disallow comparison between None and have changed the lexer to match the escaping rules. I think that leaves us with:

No support for big int.
No support for float.
No support for bytestring.
No support for bit operations.

List comprehensions have slightly different lexical scoping.

The first 4 are unimplemented features, so I'll mark them as separate bugs in this repo. The 5th is just a flat out bug, so it can have its own bug ticket, but it's more about figuring out quite what/why it does what it does, so there's a lot more work there. For the 6th I'll propose it as a Starlark implementation adjustment, and we can discuss it in detail there with full context. Anything else missing?

I created a tag at https://github.com/facebookexperimental/starlark-rust/labels/spec and fresh tickets as #3, #4, #5, #6 to track the first of those 4 spec violations separately. For crazy strings, I think I'll leave that silent for now - it's more a warning than a specific issue to be addressed. I'll go through and do it at some point. For 6, I've pushed in a patch which should flow out to this repo in the next day or so. I've also modified the README to list those things with links to their tickets, which again, should flow to the repo in the next day or so.

All these have now landed. The readme lists the spec compatibility issues. The list comps follow Starlark spec. I think we're all done here. Please reopen or comment if there's anything you think I've missed.


⚠ API - Lens has degraded performance

In 7b2c2bb, API - Lens ($LENS_API_URL) experienced degraded performance:

HTTP code: 503
Response time: 601 ms

Resolved: API - Lens performance has improved in 043f4b9 after 6 minutes.


Soulbound Mode Suggestion

Hello,
First, thanks for the addon, it's awesome!! One suggestion I do have is for the Auto Sell feature, mainly the Soulbound Mode. I would love to use this feature, but I have a Cloak of Coordination that is ilvl 29 in my inventory that I would like to keep, but the current Soulbound Mode sells it. I would suggest a feature to block certain items from being sold.
Thank you.

Hi @Elloran711,
You can blacklist the cloak to prevent it from being sold by Junker.
You can do this with a keybind if you set one or enter /hmp junker blacklist and paste the item. If done correctly, you'll see blacklisted text in the item's tooltip.


Error: ENOSPC: no space left on device while executing download_js_html

I have following problem while executing "Download source"
But it's cool because now I see that I can work offline :)
Even with METEOR_ALLOW_SUPERUSER or --allow-superuser, permissions in your app
directory will be incorrect if you ever attempt to perform any Meteor tasks as
a normal user. If you need to fix your permissions, run the following command
from the root of your project:
  sudo chown -Rh <username> .meteor/local
Even with METEOR_ALLOW_SUPERUSER or --allow-superuser, permissions in your app
directory will be incorrect if you ever attempt to perform any Meteor tasks as
a normal user. If you need to fix your permissions, run the following command
from the root of your project:
  sudo chown -Rh <username> .meteor/local
/root/.meteor/packages/meteor-tool/.1.5.1.mwqtpj++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:218
      throw error;
      ^
Error: ENOSPC: no space left on device, mkdir '/home/Tn9HpfrMNgqxysK2F/yFWCigfS7R39BxkF4-blaze'
    at Error (native)
    at Object.fs.mkdirSync (fs.js:794:18)
    at Object.wrapper [as mkdir] (/tools/fs/files.js:1586:35)
    at Object.files.mkdir_p (/tools/fs/files.js:445:11)
    at Object.files.cp_r (/tools/fs/files.js:487:11)
    at Command.func (/tools/cli/commands.js:697:9)
    at /tools/cli/main.js:1483:23
*** Meteor Kitchen v0.9.82 ***
Source code generator for Meteor.js - www.meteorkitchen.com
Copyright (c) Petar Korponaić
<EMAIL_ADDRESS>Downloading input file...
Reading input file...
Executing "meteor create /home/Tn9HpfrMNgqxysK2F/yFWCigfS7R39BxkF4-blaze/ --bare --unsafe-perm"...
Error executing "meteor create /home/Tn9HpfrMNgqxysK2F/yFWCigfS7R39BxkF4-blaze/ --bare --unsafe-perm". Error executing "meteor". No such file or directory
Error executing: download_js_html. Exit code: 255

@ignacy130 disk at server was full ( ENOSPC == "Error NO SPaCe").
It is fixed now.
Thanks for reporting issue! :+1:


looks like ref operator not converting correctly to refmt:3

Its converting
let newItem () => {
  lastId := !lastId + 1;
  {id: !lastId, title: "Click a button", completed: true};
};

to
let newItem = () => {
  :=(lastId, lastId^ + 1);
  {id: lastId^, title: "Click a button", completed: true}
};

when maybe it should be:
let newItem = () => {
  lastId := lastId^ + 1;
  {id: lastId^, title: "Click a button", completed: true}
};

See: reason-tools share link

IIRC, the old syntax update the value in a reference was:
lastId = !lastId + 1;

I'm not sure := should be converted into prefix form like that, so there is still possibly a bug here.


Integrate site_generator into lib and pastpy-script, use package_data to copy in mustache templates

https://docs.python.org/2/distutils/setupscript.html

Need to implement OnlinePastPerfectDatabase.objects().


Polish for v3

[x] delete playground
[x] get rid of horizontal scroll-bar in TOC on LinkedIn page

In the gatsby-config, the original social media sharing image was banner:
module.exports = {
  // ...
  siteMetadata: {
    // ...
    siteImage: `/banner.png`,
  }
};


Add supplier/license info support for rubygems.

Codecov Report
Attention: 90 lines in your changes are missing coverage. Please review.

Comparison is base (30cba55) 59.51% compared to head (1a90361) 59.37%.

Files
Patch %
Lines

...kageDetails/ComponentDetailsUtils/RubyGemsUtils.cs
52.50%
68 Missing and 8 partials :warning:

...t.Sbom.Api/PackageDetails/PackageDetailsFactory.cs
0.00%
10 Missing :warning:

.../ComponentDetection/RubyGemsComponentExtensions.cs
0.00%
4 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #453      +/-   ##
==========================================
- Coverage   59.51%   59.37%   -0.15%
==========================================
  Files         246      247       +1
  Lines        7361     7532     +171
  Branches      870      893      +23
==========================================
+ Hits         4381     4472      +91
- Misses       2585     2657      +72
- Partials      395      403       +8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[#1091]java sdk add nacos selector

Fixes #1091
Motivation
Applications can access the EventMesh Workflow/AysncAPI capabilities through the EventMesh SDK to fill the event governance capabilities
Modifications

add nacos naming selector

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

@walterlife you better create an new issue also for this.

@walterlife you better create an new issue also for this.

ok


Add a linting rule for anonymous types (azure.resourcemanager and azure.core

Example violation

look at existing inline rule from providerhub


model KVStore initial migration not in package when installing via pip

I installed the package via pip and I was getting a programming error. I had to create the KVStore inital migration manually to make it work because apparently it was not there.
python manage.py makemigrations thumbnail
Migrations for 'thumbnail':
0001_initial.py:
- Create model KVStore
It should be included in the package to avoid problems. thank you

It already exists.
https://github.com/mariocesar/sorl-thumbnail/blob/c7d9e9d6d55d89f0a7aaa867d087d713cd76937c/sorl/thumbnail/migrations/0001_initial.py
It's just not in any releases on PyPI, which is the real issue.

Any updates to this issue?

@mariocesar This really needs addressed!  No one can use this library without googling around and figuring out that it's not working because migrations aren't included in the package they installed.

@dmwyatt You are right, need wrap a plan to maintain some compatibility and release a new version in the process.
If you want to help, solving tests and maintaining compatibility while doing the upgrade will fix all we need to release.

Installed with pip, followed the documentation, decided to use the default settings and bumped into this. Easy to solve of course but for a beginner user this still seems to be an issue.

Main issue is that the stable version is really outdated, and the work on the next released is stalled. If someone wants to give a hand on the next release is welcome. There is really not much work, update some tests, rename somethings, and other minor things

@mariocesar, thanks for the update. Is there a todo list for the new release somewhere so newcomers can try to help?

Can we at least have a release 12.3.1 branched off with 12.3, but with just the migration included? Currently, bootstrapping most projects has hacks in place to generate that migration (or curl it from github), and it's really hacky.
Also, like @pembeci said, a list of things that need work for the next release (maybe just tag the GH issues) would be great. I'm sure I can make the time to work on them at some point, but most importantly, I'm sure other are.


Add support for CRD conversion

Motivation
Should close #865

Solution
This PR contains multiple API additions (I can split them into separate PRs if needed):

kube::core::conversion::low_level - typings for the conversion-related k8s apis.
kube::core::conversion::Converter - simple utility which abstracts away annoying details (like the fact that kubernetes batches conversion requests)
kube::core::conversion::StarConverter - high-level utility which helps implement conversion in k8s-way (i.e. you define unversioned representation, converters to/from each version, and StarConverter implements the rest)
kube::client::api::migrate_resources - function which strips .status.storedVersions of the CRD, migrating all objects to storage version.

Additionally, crd_derive_multi is substantially modified: it now includes star-based conversion webhook and shows how this webhook achieves lossless conversion between versions.

TODO:

[x] tests?
[x] fix formatting
[ ] Maybe move Converter and StarConverter to kube_runtime?

Codecov Report

Merging #992 (945dd7a) into master (251728e) will decrease coverage by 1.36%.
The diff coverage is 0.00%.

:exclamation: Current head 945dd7a differs from pull request most recent head 27f44ef. Consider uploading reports for the commit 27f44ef to get more accurate results

@@            Coverage Diff             @@
##           master     #992      +/-   ##
==========================================
- Coverage   72.60%   71.24%   -1.37%
==========================================
  Files          64       67       +3
  Lines        4505     4590      +85
==========================================
- Hits         3271     3270       -1
- Misses       1234     1320      +86

Impacted Files
Coverage Δ

kube-client/src/api/mod.rs
68.08% <ø> (ø)

kube-client/src/api/util/mod.rs
78.65% <0.00%> (-14.69%)
:arrow_down:

kube-core/src/conversion.rs
0.00% <0.00%> (ø)

kube-core/src/conversion/low_level.rs
0.00% <0.00%> (ø)

kube-core/src/conversion/star.rs
0.00% <0.00%> (ø)

kube-core/src/resource.rs
45.45% <0.00%> (-1.06%)
:arrow_down:

kube-runtime/src/wait.rs
69.81% <0.00%> (-1.89%)
:arrow_down:

clippy job fails on code, not introduced in this PR, so it needs to be rebased on fresh master.
If you don't object, I will use that opportunity to split PR into several smaller ones.

Ok, yeah, that is sensible. :+1:


new error

Node.js v17.8.0
• [ Api ]       => Successfully connected to MongoDB.
• [ Player ]    => Loaded: 8
• [ Node ]      => Loaded: 4
• [ Button ]    => Loaded: 6
• [ Commands ]  => Command Loaded: 41
• [ Client ]    => Loaded: 10
C:\Users\Aditya\Documents\LyricLoom-main\LyricLoom-main\node_modules\discord.js\src\client\websocket\WebSocketManager.js:136
const invalidToken = new DiscordjsError(ErrorCodes.TokenInvalid);
^
Error [TokenInvalid]: An invalid token was provided.
at WebSocketManager.connect (C:\Users\Aditya\Documents\LyricLoom-main\LyricLoom-main\node_modules\discord.js\src\client\websocket\WebSocketManager.js:136:26)
at Savaan.login (C:\Users\Aditya\Documents\LyricLoom-main\LyricLoom-main\node_modules\discord.js\src\client\Client.js:228:21)
at Savaan.connect (C:\Users\Aditya\Documents\LyricLoom-main\LyricLoom-main\Src\Base\Client.js:141:15)
at new Savaan (C:\Users\Aditya\Documents\LyricLoom-main\LyricLoom-main\Src\Base\Client.js:52:14)
at Object. (C:\Users\Aditya\Documents\LyricLoom-main\LyricLoom-main\Src\Saavan.js:2:16)
at Module._compile (node:internal/modules/cjs/loader:1099:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
at Module.load (node:internal/modules/cjs/loader:975:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12) {
code: 'TokenInvalid'
}
even the token is correct still showing invaild

did you paste your bot token properley ?

Yes i pasted properly even tried multiple times
On Sat, 10 Feb 2024, 3:19 pm ₦ł₵₭ ₣ɄⱤɎ, @.***> wrote:

did you paste your bot token properley ?
—
Reply to this email directly, view it on GitHub
https://github.com/NICK-FURY-6023/LyricLoom/issues/1#issuecomment-1936956327,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYJDHODCRGASFNAK6USXOPDYS47DFAVCNFSM6AAAAABDB4XBK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWHE2TMMZSG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

ok join my server and share with me your error

You are no response so we close this issue


add ability to set operator logs levele

the way flags are read prevents setting log levels even if the operator was developed apparently with the operator SDK.
with log level set to info, one is not able to see from the logs why object creation is failing.
Alternatively print in the logs why object creation is failing at the warn level

Hi  @raffaelespazzoli, Could I ask you to provide a bit more context about what your suggestion is? If I'm understanding correctly, the issue you're talking about is to add a more varied/relevant log level to places where log.XXX is called? or is your suggestion to add a new type of log level which would be called warn?

@HubertStefanski sorry, I clearly did not explain myself. I have not found a way to increase the log levels of the grafana operator. I have a case where it fails at the step where it creates the ingress and no reason is given for the failure.
I assumed if there was a way to increase the log level I would be able to see what the error is. But I have found CLI option to increase the log level, not even using the operator-sdk standard approach (--zap-level option).
So I am essentially asking for two things:

provide a way to increase the log level
print out the error message when something fails during the provisioning of one of the CRs, regardless of the log level currently set.

@raffaelespazzoli thanks for the clarification!

as for the Ingress failed, this is a know issue https://github.com/integr8ly/grafana-operator/issues/208 https://github.com/integr8ly/grafana-operator/pull/213

On your points, I agree, I've looked through a few of these, and noticed a few calls that could (and should) be error instead of info.
As for the increase in log level, I also agree, this could be a useful feature for a lot of users for troubleshooting, are you familiar with this type of logging and it's implementation/s?

@HubertStefanski I have an eye on the code.
This kind of config will be easiy. But as I see, there are a lot of format log messages which is not aligned with the log rule here. https://github.com/go-logr/logr#why-not-allow-format-strings-too. If I have a PR for this, can I have some improvent on this kind of thing?

@HubertStefanski I have an eye on the code.
This kind of config will be easiy. But as I see, there are a lot of format log messages which is not aligned with the log rule here. https://github.com/go-logr/logr#why-not-allow-format-strings-too. If I have a PR for this, can I have some improvent on this kind of thing?

@dongwangdw Sure, I'm happy to help out, send in the PR whenever you want feedback/help

@HubertStefanski I'd like to elaborate on one more reason why it's important to have a configurable logging level ("warn" in my case).
As you know, many companies have centralized logging. The exact implementation depends on a type of cloud you're using or other consideration - it could be a flavor of ExK or some native service (e.g. Cloud Logging). In either case, you pay for the storage should it be mostly CAPEX or OPEX. To save on costs and improve usefulness of the stored logs, you'd normally try to remove the noise from the records.
And what I can tell now, the grafana-operator is the chattiest app in our cluster. 453103 messages within the last 24 hours just for one instance of the operator which handles only one instance of grafana. It's hard to calculate the exact space it consumes in our ElasticSearch, because data is stored compressed, but raw json entry (with all labels and other Kubernetes-related info) is about 2 KiB, which in turn makes 885 Mib x 2 replicas = 1770 Mib of log entries a day.
Other two instances of the operator deployed in other cluster are twice less chatty, but still generate a lot of data in a day:

To summarize, there could literally be a non-zero cost of using the operator. Of course, there are some ways to filter out entries through Fluentd or other collectors, but that increases operational complexity. So, to me, having a configurable logging level is one of the most important features the operator could have in the future.

Hi @weisdd , I'll look into this with priority, seeing the recent increase in communications around this issue. Thanks for sharing your case, it highlights the issue quite well, :+1:


:alien: Update downloads badge

Codecov Report
Patch coverage has no change and project coverage change: -20.33% :warning:

Comparison is base (e7e6f17) 100.00% compared to head (53ad651) 79.67%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
Additional details and impacted files
@@             Coverage Diff              @@
##            master      #45       +/-   ##
============================================
- Coverage   100.00%   79.67%   -20.33%
============================================
  Files            4        4
  Lines          123      123
  Branches        21       20        -1
============================================
- Hits           123       98       -25
- Misses           0       24       +24
- Partials         0        1        +1

see 1 file with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Create hello-word.md

I just discovered an impressive app called HelloWorld. Check it: https://illa.ai/app/ILAfx4p1C7J2/detail
📝 Description
Add a brief description.
💣 Is this a breaking change (Yes/No):

[ ] Yes
[x] No

🚧 How to migrate?
Don't need.
📝 Additional Information
lol

@AruSeito
new PR from https://github.com/illacloud/illa-builder/pull/2715

Please be patient and wait for my colleagues to review.
Have a good weekend


wasi: net implement sockets

Proposal Details
there is a sockets proposal for wasi in phase 3 (implementation). I'd like to start laying the ground work for that in golang as an experiment initially. the scope is mainly to wire up socket (tcp/udp, possibly unix if thats easier since filesystem already is supported) support within golang behind a flag for the wasi arch and help move the standardization process along.
What I'm not sure on is the golang teams willingness to support/enable such work. looking for clarity on where the boundaries would be and the process we'd want to follow for it.

In the meantime, if you want to use WASI and networking sockets, the official Go WASI blog post references https://github.com/stealthrocket/net, which can be used to get networking on GOOS=wasip1 on runtimes that support the unofficial wasip1 networking extension (wasmedge, wazero).

we're aware of the library its not sufficient for our use case. which requires transparent interopt with stdlib. stealthrockets implementation doesn't provide that. it mutates the default dialers, requires using their net package, and doesn't (last I checked a couple months ago so this may have changed) support remapping filesystem paths in the guest runtime.
unfortunately we need upstream support in golang stdlib to support it. we're happy to implement the missing calls within stdlib and put it behind compile experiment flags.

In case it wasn't clear in my first reply, you cannot just "implement the missing calls within stdlib". You need to add all the surrounding infrastructure to support wasip2, which will include a proposal for how to handle everything that comes along with that (WIT client generation, function import/export, ABI, WASI component compilation). It sounds to me like your best path forward for now is to either contribute to the efforts I outlined above, or contribute the necessary changes to the stealthrocket/net library for your use case.

I know what needs to be done for it to work. yes, you can 'just' implement the system calls long as host runtimes support them (which is exactly what stealthrocket has done). the issue is golang stdlib has implemented nothing because there are no implementations that exist for it to hook into. this issue is about getting that implementation going.

It sounds like you want to help implement runtime support for wasi-sockets? If so, I'd raise an issue against a Wasm/WASI runtime wazero or wasmtime. The Go project doesn't have a Wasm/WASI runtime so this wouldn't be the right place for it. That said, it seems wasmtime implements it if this issue is to be believed: https://github.com/bytecodealliance/wasmtime/issues/4276.
Regardless of runtime support, we still need to answer the questions I outlined before the Go standard library can consider supporting wasi-sockets. Unless you want to turn this issue into a general-purpose wasip2 proposal, I think we should close it.

I'm fairly indifferent to what the golang team decides here since wasip2 includes sockets I'm fine with that. my goal is to get the ball rolling on having some socket support moving forward in some manner as its been an annoying thorn in my side for a few months now (im just finally getting the bandwidth to address it). If golang team needs help getting the implementation done, im here for that in whatever form the golang team wants the process to take.

I believe this can be closed in favour of a future complete wasip2 proposal.


Add "Roundess" slider to label customization

Some people like rounded rectangles and circles.

这将使得按钮显得非常的酷。

我们也能得到完整的馅饼菜单切片吗？像GTA V换武器系统哈哈

这也是不错的方案。
薄或许这样也可以设置的话，建议增加勾选项，要按钮更加的丰富。

Can we also get complete pie menu slices? Like GTA V weapon changing system haha

Yeah that would be neat, but I'm not going to work on this one yet.  This would require a pretty big visuals rewrite and some addition of "Themes".  Although once that's added it would make it easier to add other types of visuals.  I'll keep this in mind but I'm going to stick to the roundness slider for now.

我们也能得到完整的馅饼菜单切片吗？像GTA V换武器系统哈哈

是的，那会很整洁，但我还不打算研究这个。这将需要相当大的视觉效果重写和一些“主题”的添加。虽然一旦添加了它会更容易添加其他类型的视觉效果。我会记住这一点，但我现在要坚持使用圆度滑块。

YES，支持薄的计划。
我们的按钮蒋变得非常完美。

Roundness slider has been added in v1.0.20, Feel free to open a new issue if anybody wants to talk about adding "Themes" to AHP.

这一次是成功的，对于只有图标按钮的时候，显得非常的酷。
------------------ 原始邮件 ------------------
发件人:                                                                                "dumbeau/AutoHotPie"                                                                                @.>;
发送时间: 2022年6月30日(星期四) 下午5:47
@.>;
<EMAIL_ADDRESS>主题: Re: [dumbeau/AutoHotPie] Add "Roundess" slider to label customization (Issue #51)
Roundness slider has been added in v1.0.20, Feel free to open a new issue if anybody wants to talk about adding "Themes" to AHP.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>