3.2.2 Dangling Variant Crash starting Jetpaca

Godot version:

3.2.2 beta2 - RC3
I have bisected this crash was introduced with commit 5d5848d.
OS/device including version:

Linux Mint 18.3
Intel core i5 7500T
HD Graphics 630
Issue description:

Crash on starting Jetpaca. (My jetpaca zip file date is 2 March 2020)
This occurs on release and debug builds.
Call stack:
memdelete<Thread>
_Thread::wait_to_finish
MethodBind0R<_Thread, Variant>::call
Object::call
MessageQueue::_call_function
MessageQueue::flush
SceneTree::iteration
Main::iteration
OS_X11::run
main

Steps to reproduce:
Use 3.2.2 beta2 to RC3 to run Jetpaca project.
https://github.com/KOBUGE-Games/jetpaca
Akien reports it did not occur for him, so it may be a race condition.

I can't reproduce it on Mageia 8 (also with HD Graphics 630), neither with 3.2.2 RC 2 nor a current debug build from 3.2 (7ec072f7e7).
I tried cleaning up my ~/.local/share/godot/app_userdata/Jetpaca to be sure but it still works fine.

I've bisected it to this PR:
#38119
Commit 5d5848d
new_dangling_variant_fix
cc @RandomShaper

Maybe this is the race condition mentioned in the PR. It does sound like a race condition if it is occurring for me but not for Akien.

For reference, here's how that race condition was described:

All that said, in the name of performance there's still one possible case of undefined behavior: in multithreaded scripts there would be a race condition between a thread freeing an Object and another one trying to operate on it. The latter may not realize the Object has been freed soon enough. But that's a case of bad scripting that was never supported anyway.

There's one use of threads in Jetpaca at https://github.com/KOBUGE-Games/jetpaca/blob/master/shared/music.gd#L24, that might be the issue. (You can check if disabling it fixes the crash.)

Yup, can confirm commenting out line 24 (and the one before creating the thread) fixes it.

Could you try inverting the order of these two lines (
	call_deferred("_change_music_to", loader.get_resource())
	options.thread.call_deferred("wait_to_finish")

) so they look like this (
	options.thread.call_deferred("wait_to_finish")
	call_deferred("_change_music_to", loader.get_resource())

) and see what happens?

To add a little piece of insight, in general it's not safe to access any object in Godot without proper synchronization. Some containers, etc. are thread-safe by themselves, but it's not the case for the universal Object base class.
That's true even before the dangling Variant fix. However, since it adds a little bit of additional bookkeeping, the chance of getting UB/crashes in the face of a lack of proper sync may be a bit bigger.

Still crashes after inverting order.

Thanks for testing. I'll give it a deeper look later today.

To add a little piece of insight, in general it's not safe to access any object in Godot without proper synchronization. Some containers, etc. are thread-safe by themselves, but it's not the case for the universal Object base class.
That's true even before the dangling Variant fix. However, since it adds a little bit of additional bookkeeping, the chance of getting UB/crashes in the face of a lack of proper sync may be a bit bigger.

Yup, as you say maybe the game is doing something unsafe anyway in the scripts and this is just making it more likely to occur.

I've not been able to reproduce the crash on Windows.
Tried both with and without debugger attached, debug and non-debug build.
I even tried being super unsafe in the usage of the loading thread.

Still crashing in 3.2 a6ef6b10b25d48a02a22de25a222f61aee035f25 on Linux on an Intel i7-8705G.
gdb backtrace:
instanced scene         [Control:48435] res://menu/stage_select.tscn
[New Thread 0x7fffe8058700 (LWP 259984)]
Adding levels...
Adding level    True    res://stages/world_1/intro.tscn
Adding level    True    res://stages/world_1/forest_fun.tscn
Adding level    True    res://stages/world_1/roller_coaster.tscn
Adding level    True    res://stages/gcon/demo_gcon_004.tscn
Adding level    True    res://stages/gcon/demo_gcon_006.tscn
added to tree
[Thread 0x7fffe8058700 (LWP 259984) exited]
[New Thread 0x7fffe8058700 (LWP 259986)]
load: res://stages/world_1/forest_fun.tscn
LOAD: FREEING
LOAD: START_PROGRESS
[Thread 0x7fffe8058700 (LWP 259986) exited]
--Type <RET> for more, q to quit, c to continue without paging--

Thread 1 "godot-3.2" received signal SIGSEGV, Segmentation fault.
0x000000000143db6c in memdelete<Thread> (p_class=0x1490) at ./core/os/memory.h:117
117                     p_class->~T();
(gdb) bt
#0  0x000000000143db6c in memdelete<Thread> (p_class=0x1490) at ./core/os/memory.h:117
#1  0x0000000003b3e059 in _Thread::wait_to_finish (this=0x787f460) at core/bind/core_bind.cpp:2814
#2  0x0000000001512377 in MethodBind0R<Variant>::call (this=0x5591210, p_object=0x787f460, p_args=0x0, p_arg_count=0, r_error=...) at ./core/method_bind.gen.inc:237
#3  0x00000000038e9190 in Object::call (this=0x787f460, p_method=..., p_args=0x0, p_argcount=0, r_error=...) at core/object.cpp:922
#4  0x00000000038dfde2 in MessageQueue::_call_function (this=0x55fca70, p_target=0x787f460, p_func=..., p_args=0x7ffff621c080, p_argcount=0, p_show_error=true) at core/message_queue.cpp:250
#5  0x00000000038e00a9 in MessageQueue::flush (this=0x55fca70) at core/message_queue.cpp:297
#6  0x0000000002b1f654 in SceneTree::idle (this=0x5953420, p_time=0.0166666675) at scene/main/scene_tree.cpp:537
#7  0x0000000001463a82 in Main::iteration () at main/main.cpp:2107
#8  0x0000000001432442 in OS_X11::run (this=0x7fffffffcf10) at platform/x11/os_x11.cpp:3233
#9  0x00000000014226bc in main (argc=1, argv=0x7fffffffd738) at platform/x11/godot_x11.cpp:56

Steps to reproduce:

Load Jetpaca's stage select
Select level 2
Go back (Escape)
Select level 2 again
Go back (Escape)
Repeat ad lib until it crashes

Sometimes I experienced it relatively easily by selecting Level 1 first, then exiting then Level 2 (crash on load), but other times I had to repeat many times on a single level to finally get it to crash.

Crash still happens with 3.2.4.beta.custom_build. 279f4fbb5
The easiest fix is to change:
options.thread.call_deferred("wait_to_finish")

to
options.thread.wait_to_finish()

Address sanitizer log
==157563==ERROR: AddressSanitizer: heap-use-after-free on address 0x613000066e78 at pc 0x000011d87c93 bp 0x7ffff256d4b0 sp 0x7ffff256d4a8
WRITE of size 8 at 0x613000066e78 thread T0
    #0 0x11d87c92 in Dictionary::_unref() const /mnt/Miecz/godot3.2/core/dictionary.cpp:189:5
    #1 0x11d8a2e4 in Dictionary::~Dictionary() /mnt/Miecz/godot3.2/core/dictionary.cpp:284:2
    #2 0x122c7282 in Variant::clear() /mnt/Miecz/godot3.2/core/variant.cpp:1142:48
    #3 0x122c464a in Variant::reference(Variant const&) /mnt/Miecz/godot3.2/core/variant.cpp:921:4
    #4 0x122de6fe in Variant::operator=(Variant const&) /mnt/Miecz/godot3.2/core/variant.cpp:2588:3
    #5 0x12e9c364 in _Thread::wait_to_finish() /mnt/Miecz/godot3.2/core/bind/core_bind.cpp:2833:11
    #6 0x13089a61 in MethodBind0R<_Thread, Variant>::call(Object*, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/./core/method_bind.gen.inc:325:17
    #7 0x11fe9bbb in Object::call(StringName const&, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/core/object.cpp:919:17
    #8 0x11fb9c99 in MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) /mnt/Miecz/godot3.2/core/message_queue.cpp:250:12
    #9 0x11fbaf43 in MessageQueue::flush() /mnt/Miecz/godot3.2/core/message_queue.cpp:297:6
    #10 0xba96514 in SceneTree::iteration(float) /mnt/Miecz/godot3.2/scene/main/scene_tree.cpp:483:33
    #11 0x1ef4736 in Main::iteration() /mnt/Miecz/godot3.2/main/main.cpp:2080:45
    #12 0x1db92a0 in OS_X11::run() /mnt/Miecz/godot3.2/platform/x11/os_x11.cpp:3410:7
    #13 0x1d29f94 in main /mnt/Miecz/godot3.2/platform/x11/godot_x11.cpp:56:6
    #14 0x7f7ab99d70b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16
    #15 0x1c7f2ad in _start (/usr/bin/godotls+0x1c7f2ad)

0x613000066e78 is located 312 bytes inside of 360-byte region [0x613000066d40,0x613000066ea8)
freed by thread T0 here:
    #0 0x1cf776d in free (/usr/bin/godotls+0x1cf776d)
    #1 0x126d6c69 in Memory::free_static(void*, bool) /mnt/Miecz/godot3.2/core/os/memory.cpp:178:3
    #2 0x1decdfc in void memdelete<Reference>(Reference*) /mnt/Miecz/godot3.2/./core/os/memory.h:119:2
    #3 0x1dec72e in Ref<Reference>::unref() /mnt/Miecz/godot3.2/./core/reference.h:279:4
    #4 0x120fc05e in RefPtr::unref() /mnt/Miecz/godot3.2/core/ref_ptr.cpp:90:7
    #5 0x122c7220 in Variant::clear() /mnt/Miecz/godot3.2/core/variant.cpp:1129:20
    #6 0x1d2b988 in Variant::~Variant() /mnt/Miecz/godot3.2/./core/variant.h:444:29
    #7 0x11d8d76d in Pair<Variant const*, Variant>::~Pair() /mnt/Miecz/godot3.2/./core/pair.h:35:8
    #8 0x11d8d704 in List<Pair<Variant const*, Variant>, DefaultAllocator>::Element::~Element() /mnt/Miecz/godot3.2/./core/list.h:51:8
    #9 0x11d8d694 in void memdelete_allocator<List<Pair<Variant const*, Variant>, DefaultAllocator>::Element, DefaultAllocator>(List<Pair<Variant const*, Variant>, DefaultAllocator>::Element*) /mnt/Miecz/godot3.2/./core/os/memory.h:128:13
    #10 0x11d8d501 in List<Pair<Variant const*, Variant>, DefaultAllocator>::_Data::erase(List<Pair<Variant const*, Variant>, DefaultAllocator>::Element const*) /mnt/Miecz/godot3.2/./core/list.h:174:4
    #11 0x11d8c989 in List<Pair<Variant const*, Variant>, DefaultAllocator>::erase(List<Pair<Variant const*, Variant>, DefaultAllocator>::Element const*) /mnt/Miecz/godot3.2/./core/list.h:369:22
    #12 0x11d8c6e8 in List<Pair<Variant const*, Variant>, DefaultAllocator>::clear() /mnt/Miecz/godot3.2/./core/list.h:405:4
    #13 0x11d8c4b4 in List<Pair<Variant const*, Variant>, DefaultAllocator>::~List() /mnt/Miecz/godot3.2/./core/list.h:726:3
    #14 0x11d94c76 in OrderedHashMap<Variant, Variant, VariantHasher, VariantComparator, (unsigned char)3, (unsigned char)8>::~OrderedHashMap() /mnt/Miecz/godot3.2/./core/ordered_hash_map.h:47:7
    #15 0x11d94bfd in DictionaryPrivate::~DictionaryPrivate() /mnt/Miecz/godot3.2/core/dictionary.cpp:37:8
    #16 0x11d8c094 in void memdelete<DictionaryPrivate>(DictionaryPrivate*) /mnt/Miecz/godot3.2/./core/os/memory.h:117:13
    #17 0x11d87c74 in Dictionary::_unref() const /mnt/Miecz/godot3.2/core/dictionary.cpp:187:3
    #18 0x11d8a2e4 in Dictionary::~Dictionary() /mnt/Miecz/godot3.2/core/dictionary.cpp:284:2
    #19 0x122c7282 in Variant::clear() /mnt/Miecz/godot3.2/core/variant.cpp:1142:48
    #20 0x122c464a in Variant::reference(Variant const&) /mnt/Miecz/godot3.2/core/variant.cpp:921:4
    #21 0x122de6fe in Variant::operator=(Variant const&) /mnt/Miecz/godot3.2/core/variant.cpp:2588:3
    #22 0x12e9c364 in _Thread::wait_to_finish() /mnt/Miecz/godot3.2/core/bind/core_bind.cpp:2833:11
    #23 0x13089a61 in MethodBind0R<_Thread, Variant>::call(Object*, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/./core/method_bind.gen.inc:325:17
    #24 0x11fe9bbb in Object::call(StringName const&, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/core/object.cpp:919:17
    #25 0x11fb9c99 in MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) /mnt/Miecz/godot3.2/core/message_queue.cpp:250:12
    #26 0x11fbaf43 in MessageQueue::flush() /mnt/Miecz/godot3.2/core/message_queue.cpp:297:6
    #27 0xba96514 in SceneTree::iteration(float) /mnt/Miecz/godot3.2/scene/main/scene_tree.cpp:483:33
    #28 0x1ef4736 in Main::iteration() /mnt/Miecz/godot3.2/main/main.cpp:2080:45
    #29 0x1db92a0 in OS_X11::run() /mnt/Miecz/godot3.2/platform/x11/os_x11.cpp:3410:7

previously allocated by thread T0 here:
    #0 0x1cf79ed in malloc (/usr/bin/godotls+0x1cf79ed)
    #1 0x126d516a in Memory::alloc_static(unsigned long, bool) /mnt/Miecz/godot3.2/core/os/memory.cpp:82:14
    #2 0x126d4f64 in operator new(unsigned long, char const*) /mnt/Miecz/godot3.2/core/os/memory.cpp:42:9
    #3 0x1213b4c0 in Object* ClassDB::creator<_Thread>() /mnt/Miecz/godot3.2/./core/class_db.h:143:10
    #4 0x11cf74e7 in ClassDB::instance(StringName const&) /mnt/Miecz/godot3.2/core/class_db.cpp:559:9
    #5 0x21f2a74 in GDScriptNativeClass::instance() /mnt/Miecz/godot3.2/modules/gdscript/gdscript.cpp:82:9
    #6 0x21f24db in GDScriptNativeClass::_new() /mnt/Miecz/godot3.2/modules/gdscript/gdscript.cpp:69:14
    #7 0x2286031 in MethodBind0R<GDScriptNativeClass, Variant>::call(Object*, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/./core/method_bind.gen.inc:325:17
    #8 0x11fe9bbb in Object::call(StringName const&, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/core/object.cpp:919:17
    #9 0x1234c7e8 in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) /mnt/Miecz/godot3.2/core/variant_call.cpp:1129:14
    #10 0x2470c91 in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) /mnt/Miecz/godot3.2/modules/gdscript/gdscript_function.cpp:1088:12
    #11 0x2225ee1 in GDScriptInstance::call(StringName const&, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/modules/gdscript/gdscript.cpp:1238:21
    #12 0x11fe95cf in Object::call(StringName const&, Variant const**, int, Variant::CallError&) /mnt/Miecz/godot3.2/core/object.cpp:898:26
    #13 0x1234c7e8 in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) /mnt/Miecz/godot3.2/core/variant_call.cpp:1129:14
    #14 0x2470d59 in GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) /mnt/Miecz/godot3.2/modules/gdscript/gdscript_function.cpp:1091:12
    #15 0x22270e6 in GDScriptInstance::_ml_call_reversed(GDScript*, StringName const&, Variant const**, int) /mnt/Miecz/godot3.2/modules/gdscript/gdscript.cpp:1269:13
    #16 0x222744b in GDScriptInstance::call_multilevel_reversed(StringName const&, Variant const**, int) /mnt/Miecz/godot3.2/modules/gdscript/gdscript.cpp:1276:3
    #17 0xb936b96 in Node::_notification(int) /mnt/Miecz/godot3.2/scene/main/node.cpp:149:28
    #18 0x20e234e in Node::_notificationv(int, bool) /mnt/Miecz/godot3.2/./scene/main/node.h:46:2
    #19 0x11fd8bd6 in Object::notification(int, bool) /mnt/Miecz/godot3.2/core/object.cpp:929:2
    #20 0xb940b9d in Node::_propagate_ready() /mnt/Miecz/godot3.2/scene/main/node.cpp:196:3
    #21 0xb94057a in Node::_propagate_ready() /mnt/Miecz/godot3.2/scene/main/node.cpp:188:21
    #22 0xb96264e in Node::_set_tree(SceneTree*) /mnt/Miecz/godot3.2/scene/main/node.cpp:2571:4
    #23 0xba956eb in SceneTree::init() /mnt/Miecz/godot3.2/scene/main/scene_tree.cpp:463:8
    #24 0x1db8ff8 in OS_X11::run() /mnt/Miecz/godot3.2/platform/x11/os_x11.cpp:3397:13
    #25 0x1d29f94 in main /mnt/Miecz/godot3.2/platform/x11/godot_x11.cpp:56:6
    #26 0x7f7ab99d70b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: heap-use-after-free /mnt/Miecz/godot3.2/core/dictionary.cpp:189:5 in Dictionary::_unref() const

Still occasionally crashing in a18df7178. I'm wary of working it around in Jetpaca's code as this might bite other users who wouldn't expect the engine to crash on them.
If the problematic code in Jetpaca is not supported, we need to make it very clear in the documentation that such misuse can lead to crashes.
[1] /lib64/libc.so.6(+0x3b580) [0x7f2dc9d80580] (??:0)
[2] void memdelete<Thread>(Thread*) (/home/akien/Projects/godot/godot-3.2/./core/os/memory.h:117)
[3] _Thread::wait_to_finish() (/home/akien/Projects/godot/godot-3.2/core/bind/core_bind.cpp:2833)
[4] MethodBind0R<Variant>::call(Object*, Variant const**, int, Variant::CallError&) (/home/akien/Projects/godot/godot-3.2/./core/method_bind.gen.inc:238 (discriminator 4))
[5] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (/home/akien/Projects/godot/godot-3.2/core/object.cpp:919 (discriminator 1))
[6] MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) (/home/akien/Projects/godot/godot-3.2/core/message_queue.cpp:250)
[7] MessageQueue::flush() (/home/akien/Projects/godot/godot-3.2/core/message_queue.cpp:299)
[8] SceneTree::idle(float) (/home/akien/Projects/godot/godot-3.2/scene/main/scene_tree.cpp:538)
[9] Main::iteration() (/home/akien/Projects/godot/godot-3.2/main/main.cpp:2104)
[10] OS_X11::run() (/home/akien/Projects/godot/godot-3.2/platform/x11/os_x11.cpp:3608)
[11] godot-3.2(main+0xfa) [0x138c54c] (/home/akien/Projects/godot/godot-3.2/platform/x11/godot_x11.cpp:57)
[12] /lib64/libc.so.6(__libc_start_main+0xea) [0x7f2dc9d6ce4a] (??:0)
[13] godot-3.2(_start+0x2a) [0x138c3aa] (??:?)

Still occasionally crashing in a18df7178. I'm wary of working it around in Jetpaca's code as this might bite other users who wouldn't expect the engine to crash on them.
If the problematic code in Jetpaca is not supported, we need to make it very clear in the documentation that such misuse can lead to crashes.
[1] /lib64/libc.so.6(+0x3b580) [0x7f2dc9d80580] (??:0)
[2] void memdelete<Thread>(Thread*) (/home/akien/Projects/godot/godot-3.2/./core/os/memory.h:117)
[3] _Thread::wait_to_finish() (/home/akien/Projects/godot/godot-3.2/core/bind/core_bind.cpp:2833)
[4] MethodBind0R<Variant>::call(Object*, Variant const**, int, Variant::CallError&) (/home/akien/Projects/godot/godot-3.2/./core/method_bind.gen.inc:238 (discriminator 4))
[5] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (/home/akien/Projects/godot/godot-3.2/core/object.cpp:919 (discriminator 1))
[6] MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) (/home/akien/Projects/godot/godot-3.2/core/message_queue.cpp:250)
[7] MessageQueue::flush() (/home/akien/Projects/godot/godot-3.2/core/message_queue.cpp:299)
[8] SceneTree::idle(float) (/home/akien/Projects/godot/godot-3.2/scene/main/scene_tree.cpp:538)
[9] Main::iteration() (/home/akien/Projects/godot/godot-3.2/main/main.cpp:2104)
[10] OS_X11::run() (/home/akien/Projects/godot/godot-3.2/platform/x11/os_x11.cpp:3608)
[11] godot-3.2(main+0xfa) [0x138c54c] (/home/akien/Projects/godot/godot-3.2/platform/x11/godot_x11.cpp:57)
[12] /lib64/libc.so.6(__libc_start_main+0xea) [0x7f2dc9d6ce4a] (??:0)
[13] godot-3.2(_start+0x2a) [0x138c3aa] (??:?)

The crash seems fixed by #45618 :tada:
Now it throws a non-crashing error instead, rightly pointing out that the Jetpaca code is doing something fishy (as we found out previouly since changing Jetpaca code could fix the crash):
ERROR: ~_Thread: Reference to a Thread object was lost while the thread is still running...
   At: core/bind/core_bind.cpp:2847.


Broken long rooms names

Nothing important but long room names require some changes in CSS ;) ellipsis doesn't work.

Yes it is fixed in https://github.com/antoine92190/vue-advanced-chat/commit/6abefb3e5214cadc002f66cb99244ee1ee5dffa9
Will release an update this weekend


After days of working, app crashes on release when progaurd is true

Hi. I was doing fine with my react native app. I made some changes to make my release apk smaller in size which were removing intel abi's from the output and enabling proguard. Everything was fine until I added some proguard rules to make it work with some library. But suddenly, the app installs but when running it crashes. This happens only in release mode and it stops when proguard is off! By the way it use to work a couple of days I don't know what happened that it suddenly crashes on start! This is the error by the way:
12-10 01:27:56.359   650   714 E AndroidRuntime: FATAL EXCEPTION: create_react_context
12-10 01:27:56.359   650   714 E AndroidRuntime: Process: ir.bkaa.tatami, PID: 650
12-10 01:27:56.359   650   714 E AndroidRuntime: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libfb.so caused by: Didn't find class "com.facebook.jni.HybridData$Destructor" on path: DexPathList[[zip file "/data/app/ir.bkaa.tatami-A3apYo8mYBy5LppN0ninMw==/base.apk"],nativeLibraryDirectories=[/data/app/ir.bkaa.tatami-A3apYo8mYBy5LppN0ninMw==/lib/arm64, /data/app/ir.bkaa.tatami-A3apYo8mYBy5LppN0ninMw==/base.apk!/lib/arm64-v8a, /system/lib64]]
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.b(:8)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.a(Unknown Source:106)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.a(Unknown Source:77)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.a(Unknown Source:1)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.jni.HybridData.<clinit>(Unknown Source:2)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.react.bridge.WritableNativeMap.initHybrid(Native Method)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.react.bridge.WritableNativeMap.<init>(Unknown Source:0)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.react.jscexecutor.a.create(Unknown Source:2)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at com.facebook.react.A.run(Unknown Source:58)
12-10 01:27:56.359   650   714 E AndroidRuntime: 	at java.lang.Thread.run(Thread.java:764)

Why is this happening?? I really can't understant why should it work for a few days and then stop working?!
I have tried to clean and delete all caches for android but again it did not work!
React Native version:
System:
    OS: macOS 10.15.1
    CPU: (8) x64 Intel(R) Core(TM) i7-4750HQ CPU @ 2.00GHz
    Memory: 149.70 MB / 8.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.13.0 - ~/.nvm/versions/node/v12.13.0/bin/node
    npm: 6.12.0 - ~/.nvm/versions/node/v12.13.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 23, 28, 29
      Build Tools: 28.0.3, 29.0.2
      System Images: android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom
  IDEs:
    Android Studio: 3.5 AI-191.8<IP_ADDRESS>77832
    Xcode: 11.2/11B52 - /usr/bin/xcodebuild
  npmPackages:
    react: 16.9.0 => 16.9.0
    react-native: 0.61.4 => 0.61.4

I don't know how to reproduce it! Btw here is my app/build.gradle:
buildscript {
    repositories {
        maven { url 'https://plugins.gradle.org/m2/' } // Gradle Plugin Portal
    }
    dependencies {
        classpath 'gradle.plugin.com.onesignal:onesignal-gradle-plugin:[0.12.1, 0.99.99]'
    }
}

apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'

apply plugin: "com.android.application"
apply plugin: 'com.google.gms.google-services'

import com.android.build.OutputFile

/**
 * The react.gradle file registers a task for each build variant (e.g. bundleDebugJsAndAssets
 * and bundleReleaseJsAndAssets).
 * These basically call `react-native bundle` with the correct arguments during the Android build
 * cycle. By default, bundleDebugJsAndAssets is skipped, as in debug/dev mode we prefer to load the
 * bundle directly from the development server. Below you can see all the possible configurations
 * and their defaults. If you decide to add a configuration block, make sure to add it before the
 * `apply from: "../../node_modules/react-native/react.gradle"` line.
 *
 * project.ext.react = [
 *   // the name of the generated asset file containing your JS bundle
 *   bundleAssetName: "index.android.bundle",
 *
 *   // the entry file for bundle generation
 *   entryFile: "index.android.js",
 *
 *   // https://facebook.github.io/react-native/docs/performance#enable-the-ram-format
 *   bundleCommand: "ram-bundle",
 *
 *   // whether to bundle JS and assets in debug mode
 *   bundleInDebug: false,
 *
 *   // whether to bundle JS and assets in release mode
 *   bundleInRelease: true,
 *
 *   // whether to bundle JS and assets in another build variant (if configured).
 *   // See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
 *   // The configuration property can be in the following formats
 *   //         'bundleIn${productFlavor}${buildType}'
 *   //         'bundleIn${buildType}'
 *   // bundleInFreeDebug: true,
 *   // bundleInPaidRelease: true,
 *   // bundleInBeta: true,
 *
 *   // whether to disable dev mode in custom build variants (by default only disabled in release)
 *   // for example: to disable dev mode in the staging build type (if configured)
 *   devDisabledInStaging: true,
 *   // The configuration property can be in the following formats
 *   //         'devDisabledIn${productFlavor}${buildType}'
 *   //         'devDisabledIn${buildType}'
 *
 *   // the root of your project, i.e. where "package.json" lives
 *   root: "../../",
 *
 *   // where to put the JS bundle asset in debug mode
 *   jsBundleDirDebug: "$buildDir/intermediates/assets/debug",
 *
 *   // where to put the JS bundle asset in release mode
 *   jsBundleDirRelease: "$buildDir/intermediates/assets/release",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in debug mode
 *   resourcesDirDebug: "$buildDir/intermediates/res/merged/debug",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in release mode
 *   resourcesDirRelease: "$buildDir/intermediates/res/merged/release",
 *
 *   // by default the gradle tasks are skipped if none of the JS files or assets change; this means
 *   // that we don't look at files in android/ or ios/ to determine whether the tasks are up to
 *   // date; if you have any other folders that you want to ignore for performance reasons (gradle
 *   // indexes the entire tree), add them here. Alternatively, if you have JS files in android/
 *   // for example, you might want to remove it from here.
 *   inputExcludes: ["android/**", "ios/**"],
 *
 *   // override which node gets called and with what additional arguments
 *   nodeExecutableAndArgs: ["node"],
 *
 *   // supply additional arguments to the packager
 *   extraPackagerArgs: []
 * ]
 */

project.ext.react = [
    entryFile: "index.js",
    enableHermes: false,  // clean and rebuild if changing
]

apply from: "../../node_modules/react-native/react.gradle"

/**
 * Set this to true to create two separate APKs instead of one:
 *   - An APK that only works on ARM devices
 *   - An APK that only works on x86 devices
 * The advantage is the size of the APK is reduced by about 4MB.
 * Upload all the APKs to the Play Store and people will download
 * the correct one based on the CPU architecture of their device.
 */
def enableSeparateBuildPerCPUArchitecture = true

/**
 * Run Proguard to shrink the Java bytecode in release builds.
 */
def enableProguardInReleaseBuilds = true

/**
 * The preferred build flavor of JavaScriptCore.
 *
 * For example, to use the international variant, you can use:
 * `def jscFlavor = 'org.webkit:android-jsc-intl:+'`
 *
 * The international variant includes ICU i18n library and necessary data
 * allowing to use e.g. `Date.toLocaleString` and `String.localeCompare` that
 * give correct results when using with locales other than en-US.  Note that
 * this variant is about 6MiB larger per architecture than default.
 */
def jscFlavor = 'org.webkit:android-jsc:+'
/**
 * Whether to enable the Hermes VM.
 *
 * This should be set on project.ext.react and mirrored here.  If it is not set
 * on project.ext.react, JavaScript will not be compiled to Hermes Bytecode
 * and the benefits of using Hermes will therefore be sharply reduced.
 */
def enableHermes = project.ext.react.get("enableHermes", false);

android {
    compileSdkVersion rootProject.ext.compileSdkVersion

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    defaultConfig {
        applicationId "ir.bkaa.tatami"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode 1
        versionName "1.0"
        ndk {
            abiFilters "armeabi-v7a", "arm64-v8a"
        }
    }

    signingConfigs {
        release {
            if (project.hasProperty('MYAPP_RELEASE_STORE_FILE')) {
                storeFile file(MYAPP_RELEASE_STORE_FILE)
                storePassword MYAPP_RELEASE_STORE_PASSWORD
                keyAlias MYAPP_RELEASE_KEY_ALIAS
                keyPassword MYAPP_RELEASE_KEY_PASSWORD
            }
        }
    }
    splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk true  // If true, also generate a universal APK
            include "armeabi-v7a", "arm64-v8a"
        }
    }
    signingConfigs {
        debug {
            storeFile file('debug.keystore')
            storePassword 'android'
            keyAlias 'androiddebugkey'
            keyPassword 'android'
        }
    }
    buildTypes {
        debug {
            signingConfig signingConfigs.debug
        }
        release {
            // Caution! In production, you need to generate your own keystore file.
            // see https://facebook.github.io/react-native/docs/signed-apk-android.
            signingConfig signingConfigs.debug
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
    }
    // applicationVariants are e.g. debug, release
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            // For each separate APK per architecture, set a unique version code as described here:
            // https://developer.android.com/studio/build/configure-apk-splits.html
            def versionCodes = ["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]
            def abi = output.getFilter(OutputFile.ABI)
            if (abi != null) {  // null for the universal-debug, universal-release variants
                output.versionCodeOverride =
                        versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
            }
        }
    }
}

dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.facebook.react:react-native:+"  // From node_modules
    implementation 'com.google.firebase:firebase-analytics:17.0.1'

    if (enableHermes) {
        def hermesPath = "../../node_modules/hermes-engine/android/";
        debugImplementation files(hermesPath + "hermes-debug.aar")
        releaseImplementation files(hermesPath + "hermes-release.aar")
    } else {
        implementation jscFlavor
    }
}

// Run this once to be able to run the application with BUCK
// puts all compile dependencies into folder libs for BUCK to use
task copyDownloadableDepsToLibs(type: Copy) {
    from configurations.compile
    into 'libs'
}

project.ext.vectoricons = [
    iconFontNames: [ 'Ionicons.ttf', 'AntDesign.ttf', 'FontAwesome.ttf', 'FontAwesome5_Regular.ttf', 'FontAwesome5_Solid.ttf' ] // Name of the font files you want to copy
]
apply from: "../../node_modules/react-native-vector-icons/fonts.gradle"

apply from: file("../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesAppBuildGradle(project)

Thanks!

Same issue, my app crash when set progaurd is true

Same issue, my app crash when set progaurd is true

My app used to work with proguard but without any changes it stopped working! I am gonna reinstall android studio and see what happens

if you're using ProGuard, you will need to add this rule in proguard-rules.pro
-keep class com.facebook.hermes.unicode.** { *; }

could you try again after upgrading your react native version to 0.61.5? it seems  fixed.
reference: https://github.com/facebook/react-native/issues/14170

could you try again after upgrading your react native version to 0.61.5? it seems fixed.
reference: #14170

Thanks for your help. I think that rule is only for enabling hermes engine and not my issue. Anyways, thanks

Ok I got it working. I first tried to reinstall Android studio but it did not work. I then cleaned all my files with git clean -f -d -X and rebuilt the project and now it works!
P.S. I had tried cd android && ./gradlew clean but it did not work.


integrations: Add webhook code, API endpoint, and tests for FourSquare.

Automated message from Dropbox CLA bot
@540KJ, it looks like you've already signed the Dropbox CLA. Thanks!


Clean code and add pkgdown site

Dear @PoisonAlien,
In this PR,

I clean all R code in R/ by running styler::style_pkg().
Add a static website for maftools under docs, it has similar UI as https://shixiangwang.github.io/sigminer/. I used pkgdown::build_site(examples = FALSE) to generate this site. Once you accept this PR, you can open the GitHub page setting in repository setting, like

I grouped all available functions in Maftools, so users can easily search and read documentation.

You can manage the function indices in config file _pkgdown.yml.
Hope this PR will make maftools more user-friendly. :)
Best,
Shixiang

Hi @ShixiangWang ,
Thanks a lot for this PR! Very impressive. However there are couple of things for which I wont be able to accept the PR.
I am used to particular coding style and I am more comfortable that way - its also how I learnt R. style_pkg seems to change many of those things. I would rather keep things the way they are.
For the bookdown package - yes I have one those already. Only reason I did not push because it does not add anything new or valuable to the package and ends up as an additional code and which requires maintenance. Package vignette is already doing the same job as the bookdown site and its has never been the issue.
Clearly you have put a lots of effort and time into this and it pains me to not merge it. Please accept my apologies and I hope you don't take it as negative response. Your contributions have always been super helpful.
Cheers.

@PoisonAlien Thanks for the response. I want to note that the management of the functions in https://github.com/ShixiangWang/maftools/blob/docs/_pkgdown.yml could give users a roadmap of maftools, hope you can show it somewhere.
I am closing this PR now.


Outdated process for switching to invoice payments

The process described in this page no longer looks accurate, as payment methods have moved to Cost Management and are not found in the Subscription blade. Additionally, "Pay by check/wire transfer" is not available in the new Cost Management page either.

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

ID: f8d2fa09-4a5b-c6c0-6d2e-c3d4f580cb02
Version Independent ID: ffd52cd6-8db6-c394-a991-525fab99847a
Content: Pay for Azure subscriptions by check or wire transfer
Content Source: articles/cost-management-billing/manage/pay-by-invoice.md
Service: cost-management-billing
Sub-service: billing
GitHub Login: @bandersmsft
Microsoft Alias: banders

@miguelarcilla Hi there. I've just tested steps in the article with a pay-as-you-go subcription (Offer ID MS-AZR-003P) and they're still valid.
What is the Offer ID that you have for your subscription?

@miguelarcilla The steps we have documented at https://docs.microsoft.com/azure/cost-management-billing/manage/pay-by-invoice are still valid for MOSP (pay-as-you-go) subscriptions. As discussed in the article, not everyone can automatically switch to pay by check/wire transfer using the Azure portal . If you want to change your billing method but the Azure portal won't allow you to, then you can request to pay by check/wire transfer using the information in the https://docs.microsoft.com/azure/cost-management-billing/manage/pay-by-invoice#submit-a-request-to-set-up-pay-by-check-or-wire-transfer section of the article.
#please-close

@bandersmsft Apologies for the delay here, missed the notification on this issue.
I am supporting another customer who I assumed was on Microsoft Customer Agreement, but it is likely that they are still on MOSP. I see the excerpt in the documentation noting that "If you have a Microsoft Online Services Program (pay-as-you-go) account and you've been approved to pay by check or wire transfer, you can switch your payment method in the Azure portal."
I've guided them through the Help + Support process and we are working on the approval to change payment methods.
Thanks for reviewing this.


Panic while training

After a while training, I got a panic. So here is the output log and I'm joining the .bin file that causes that.
shakespeare.bin.gz
$ echo "starting sequence for the sampling" | ./min-char-rnn -restore shakespeare.bin -train
2017/11/16 20:43:54 [100] {NaN}
2017/11/16 20:43:54 [200] {NaN}
2017/11/16 20:43:55 [300] {NaN}
2017/11/16 20:43:55 [400] {NaN}
2017/11/16 20:43:56 [500] {NaN}
2017/11/16 20:43:56 [600] {NaN}
2017/11/16 20:43:57 [700] {NaN}
2017/11/16 20:43:57 [800] {NaN}
2017/11/16 20:43:58 [900] {NaN}
2017/11/16 20:43:58 [1000] {NaN}
panic: runtime error: index out of range

goroutine 1 [running]:
gonum.org/v1/gonum/stat/distuv.Categorical.Rand(0xc4201918c0, 0x41, 0x41, 0xc420191b00, 0x41, 0x41, 0xc420487988, 0xc420191b00)
	/home/dolanor/go/src/gonum.org/v1/gonum/stat/distuv/categorical.go:124 +0x129
github.com/owulveryck/min-char-rnn/codec/char.(*Char).ApplyDist(0xc420081290, 0xc420191440, 0x41, 0x41, 0xc420191440, 0x41, 0x41)
	/home/dolanor/go/src/github.com/owulveryck/min-char-rnn/codec/char/char.go:211 +0x2ba
github.com/owulveryck/min-char-rnn/codec.(Codec).ApplyDist-fm(0xc420191440, 0x41, 0x41, 0xfff8000000000000, 0xc420191440, 0x41)
	/home/dolanor/go/src/github.com/owulveryck/min-char-rnn/main.go:107 +0x4d
github.com/owulveryck/min-char-rnn/rnn.(*RNN).Predict(0xc42009e388, 0xc420170000, 0x23, 0x40, 0x1f4, 0xc420487d78, 0x19, 0x19, 0x922530)
	/home/dolanor/go/src/github.com/owulveryck/min-char-rnn/rnn/rnn.go:329 +0x460
main.main()
	/home/dolanor/go/src/github.com/owulveryck/min-char-rnn/main.go:107 +0x751

I will have a look.
I don't check the size of the neurons and the matrices, so it may be a consequence of different environment variables between the initial training and the "retraining" (with restore).
Can you provide the environment variables as well please ?

Sorry I took so much time to answer.
It was the same settings as for the shakespeare training.


Where is the training script?

Hi, your work is so elegant and powerful and I am very interested about it, could you please provide the training script?

Currently, we will not release the training code. But the detailed training process can be seen in https://proceedings.neurips.cc/paper/2021/file/96b250a90d3cf0868c83f8c965142d2a-Supplemental.pdf

Hi,bro：
Do you accomplish DCVC training code?

Hi, your work is so elegant and powerful and I am very interested about it, could you please provide the training script?
Hi,bro：Do you accomplish DCVC training code?

Currently, we will not release the training code. But the detailed training process can be seen in https://proceedings.neurips.cc/paper/2021/file/96b250a90d3cf0868c83f8c965142d2a-Supplemental.pdf

Hi teacher,if you can provide the training code,your work can help many people who are interested in video compression.


Support Typescript + React

This doesn't appear to work in a Typescript project using React. If I use the lower case <wired-button>, Typescript gives the error, Property 'wired-button' does not exist on type 'JSX.IntrinsicElements'. If I use <WiredButton> as if it were a React component, I get a runtime error, TypeError: Class constructor WiredButton cannot be invoked without 'new'. Is there any way to fix one/both of these errors, or modify the library so it can be used in Typescript + React projects?

create-react-app does not transpile third party to es5.
Here's a react working example: https://stackblitz.com/edit/wired-elements-react?file=index.js
You can also just include the build package directly in your home page

Do you mean that this is a similar problem as this StackOverflow question? If so, I can probably fiddle with the Webpack config if necessary to get things working. That said, Typescript might still have problems, since I don't see a Typescript definition file, either in this project or on DefinitelyTyped. Would it be possible for you to create one?

The latest comes with Typescript definition files and better structured to work with React and Vuew.
Also here's an example of using wired-elements in React: https://codesandbox.io/embed/xrll5wyl8w

I'm getting this same error in 2021. Next.js + Typescript environment

I'm getting this same error in 2021. Next.js + Typescript environment

Have successful setup of wired elements in react + ts project. What I did:

Install elements from npm (+ roughjs package #179 ):npm i wired-elements<EMAIL_ADDRESS>

Create src/wired.d.ts to have proper typings:declare namespace JSX {
  interface IntrinsicElements {
    "wired-button": import("wired-elements").WiredButton | React.ButtonHTMLAttributes<HTMLButtonElement>;
    "wired-calendar": import("wired-elements").WiredCalendar | React.HTMLAttributes<HTMLElement>;
    "wired-card": import("wired-elements").WiredCard | React.HTMLAttributes<HTMLElement>;
    "wired-checkbox": import("wired-elements").WiredCheckbox | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-combo": import("wired-elements").WiredCombo | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-dialog": import("wired-elements").WiredDialog | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-divider": import("wired-elements").WiredDivider | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-fab": import("wired-elements").WiredFab | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-icon-button": import("wired-elements").WiredIconButton | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-image": import("wired-elements").WiredImage | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-input": import("wired-elements").WiredInput | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-link": import("wired-elements").WiredLink | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-listbox": import("wired-elements").WiredListbox | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-progress": import("wired-elements").WiredProgress | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-radio": import("wired-elements").WiredRadio | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-search-input": import("wired-elements").WiredSearchInput | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-slider": import("wired-elements").WiredSlider | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-spinner": import("wired-elements").WiredSpinner | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-tabs": import("wired-elements").WiredTabs | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-textarea": import("wired-elements").WiredTextarea | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-toggle": import("wired-elements").WiredToggle | React.HtmlHTMLAttributes<HTMLElement>;
    "wired-video": import("wired-elements").WiredVideo | React.HtmlHTMLAttributes<HTMLElement>;
  }
}


Add QR code to stores / listings

Reddit user /r/vendanto made the following suggestion:
https://www.reddit.com/r/OpenBazaar/comments/ahcgsx/openbazaar_megathread_post_bugs_troubleshooting/eedbskj/

With showing a QR code which I can scan with the Haven app, on the place where it states "buy now", I might be able to pay this product by using the Haven app.

Adding a QR code onto stores / listings on the site would allow users to easily navigate to them on mobile applications which understand the address scheme.

Done.


a fix for #1268

Pull request checklist

[x] All tests pass. Demo project builds and runs.
[x] I have resolved any merge conflicts.
[x] I have followed the coding style, and reviewed the contributing guidelines. Confirmation: ____

This fixes issue #1268.
What's in this pull request?

This is for PR #1669

This is the PR that is able to merge without extra commits, #1669. @jessesquires

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

Merging [#1713][cc-pull] into [develop][cc-base-branch] will not change coverage

@@            develop      #1713   diff @@
==========================================
  Files            62         62
  Lines          2221       2221
  Methods         612        612
  Messages          0          0
  Branches        134        134
==========================================
  Hits           1353       1353
  Misses          793        793
  Partials         75         75

[][cc-pull]

Powered by Codecov. Last updated by [689da61...a92e13d][cc-compare]
[cc-base-branch]: https://codecov.io/gh/jessesquires/JSQMessagesViewController/branch/develop?src=pr
[cc-compare]: https://codecov.io/gh/jessesquires/JSQMessagesViewController/compare/689da61cd937d428507e1824136edaac8fdd1b51...a92e13d767c0222f45603c9f464f4682af7878d5?src=pr
[cc-pull]: https://codecov.io/gh/jessesquires/JSQMessagesViewController/pull/1713?src=pr

@jessesquires Just remind you that this is ready to merge I think? Let me know if there is something wrong with it. Cheers~ 😃

Thanks @Lucashuang0802 ! 😄
Just tested this patch and it doesn't seem to work.
Going to close this for now until we find a better fix.

I'm so sorry that I did not test it thoroughly. Without telling the customization, it seems to be tough to make padding. So, I create a new property bottomContentAdditionalInset just like topContentAdditionalInset to let developers to choose the customization they want. Already include a small sample in viewDidLoad from DemoMessagesViewController.

https://github.com/Lucashuang0802/JSQMessagesViewController/commit/e7038e715a74236ddb18ad6a865844b032bae931 Sorry, I forget to include this.

👍
See my comment: https://github.com/jessesquires/JSQMessagesViewController/issues/1268#issuecomment-149773956
Instead of a bunch of individual properties, we should provide 1 insets property

Right, I did read that before I made the unfixed commit. I probably forgot to check it again. Sorry about that. It's updated and rebased already: https://github.com/Lucashuang0802/JSQMessagesViewController/commit/936ae77d57ebe1b4924c42ee339ba0e9d5091c12

submit a new PR? 😄

@jessesquires not a problem, #1737


[Bug]: UFW firewall ignored, bind ports to <IP_ADDRESS> not <IP_ADDRESS>

Description
ufw rules are being ignored. i disabled all incoming connections, but i can still access http://server-ip:5120
from what i can tell, coolify needs to bind to <IP_ADDRESS> to fix this. because binding to <IP_ADDRESS> binds to all interfaces
before - coolify
<IP_ADDRESS>:5120->5120/tcp, :::5120->5120/tcp
after - desired
<IP_ADDRESS>:5120->5120/tcp
If feasible, bind the container's port 5120 to a specific interface like <IP_ADDRESS> (localhost only) instead of <IP_ADDRESS> (all interfaces). This prevents direct external access.
Minimal Reproduction (if possible, example repository)
docker ps
Exception or Error
No response
Version
beta 224

for now, i solved this using https://github.com/chaifeng/ufw-docker


SCC Expansion Bug

The SCC expansion doesn't fully expand some nodes that it needs to, making it look like some attractors are motif-avoidant when in fact they are not. An example occurs in random_nk2/n20_29.bnet

resolved by #118 (merged via #119)


Fix delete index template failed when the index template matches a data stream but is unused

Description
Index templates without a explicit data_stream attribute cannot be used by data stream actually, but when deleting an ordinary index template which is not used by any data stream,  if the index patterns match a data stream, then the delete operation fails with an exception unable to remove composable templates [test] as they are in use by a data streams [test]. This PR fixes the bug and add some test code.
Related Issues
Resolves https://github.com/opensearch-project/OpenSearch/issues/9194
Check List

[x] Functionality includes testing.
[ ] API changes companion pull request created, if applicable.
[ ] Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@reta @dblock @andrross could you help to review this PR, thank you!


Jetbrains Gateway client support

Project description
Jetbrains Gateway client allows you to connect local jetbrains editors to remote instances.
I've opened a thread on the discourse to see if anyone has already packaged this somewhere: https://discourse.nixos.org/t/jetbrains-gateway-client-support-on-nixos/18108
Metadata

homepage URL: https://www.jetbrains.com/remote-development/gateway/
source URL: N/A
license: unfree
platforms: unix, linux, darwin

Jetbrains has become more serious about pushing their remote developement model, for instance: https://blog.jetbrains.com/blog/2022/04/28/jetbrains_partners_with_gitpod/. It seems Jetbrains is trying to push this as a new standard, whether or not they succeed, I think it is prudent to try and bring it to NixOS.
It's been determined that running the jetbrains gateway app in and of itself is possible as suspected: https://discourse.nixos.org/t/jetbrains-gateway-client-support-on-nixos/18108/2
Unfortunately gateway seems to download and run it's own client instances of the IDEs, not our nix packaged ones. This is where my debugging skills have left me, I am neither familiar enough with jetbrains internals or how NixOS packages it it.
@edwtjo, @gytis-ivaskevicius, and @steinybot, I figured I would ping you to see if you have any ideas, since yall are the maintainers for jetbrains.idea-ultimate.

(also cc @Mic92)


Question regarding v3.0.0

"With the next major release of Homebrewery, v3.0.0, this tool will no longer support raw HTML input for brew code. All brews made previous to the release of v3.0.0 will still render normally."
Does this mean we will no longer be able to add images, divs and make all the cool effects we are able to do using HTML?
Is there a particular reason for this decision?
When can we expect the new v3.0.0 ?
many thanks

iirc @stolksdorf said that most of the help requests he gets boil down to someone fucking up the html in their brew, destroying it. i think he also stated that we will still be able to include images and such in v3, but there will be some markup-like code to do it, that shouldn't break the brew.
there is no ETA for v3, as far as i know.

Thanks

Thanks for answering @HeruAsatru.
So images don't require HTML. I'm actually building a new Markdown engine that would allow div creation. Getting rid of HTML doesn't mean getting mean getting rid of CSS, which is where all those cool effects come from. @HeruAsatru nailed it with people just not understanding how to format HTML properly, and the HTML/Markdown spec being so loose that it's really hard to track down brew issues. Worst of all these little errors end up effecting the page, so it looks like it's an issue with Homebrewery, not with the formatting. It's incredibly tedious for me to make sure there's actually a bug versus just bad HTML, hence why there's so many outstanding issues on this project, I simply just can't vet them all (nor do I want to).
Re: v3. It's super side-tracked. There's like at least 40hrs of work to be done on it. Homebrewery was suppose to be a fun lil personal project, I never expected it to be so popular!
V3 is me trying to actually approach the project professionally (tests, consistent API, better admin tooling, tighter rendering engine, backwards compatibility, faster DB reads/writes, upgrades to newer web tech, account integration with 3rd for recovery, reliable rendering, better security, etc. etc.), because of that the scope has grew a ton. It's hard to sequester away so much free time to make it happen.


Custom indexing

Closes #12

Waiting for JuliaLang/julia#33394

Julia fix merged, so this should work in next Julia release (after 1.2.0).


Update: Reference messaging bridge pattern when refactoring to Azure Service Bus

For "lift and shift" migrations, when refactoring to Azure Service Bus, it can reduce the risk to migrate endpoints one at a time instead of all at once. This change makes reference to the "messaging bridge" pattern as a means of accomplishing that

@MicrosoftDocs/cloud-architecture-content-team-pr-reviewers - Please review the proposed changes. If you want to move forward with the content, add a sign-off.
#label:"pending-content-team/business-approval"
Cc: @MicrosoftDocs/public-repo-pr-review-team

Hi @kbaley - thanks very much for your contribution. Can you also work this implementation into your addition, to cite an example: https://github.com/Microsoft/Microsoft-Message-Bridge ?

#label:"cact-review-in-progress"

@BryanLa Done. I included another example implementation of it as well.

@BryanLa Done. I included another example implementation of it as well.

Great, thank you @kbaley . We're planning to have a related discussion re: our patterns library in a couple of weeks, and possibly adding this as a new pattern article. We may move some of the implementation ideas to that article, and point to it from this one. Just wanted to give you a heads up that we'll probably hold off on this merge until we resolve that part.

@BryanLa That makes sense. I thought the same thing and have started a Message Bridge article already. If you like, I can post that up as a starting point for you. I usually find it easier to edit an existing draft than to start from scratch.

@BryanLa Actually, I see that a PR is already started for the new article by my colleague, Szymon.

Anything new to report on this, @BryanLa.  Can this PR be closed?

@ckittel - still discussing this one and #4068. I just sent you an email update..

@kbaley - thanks again for your contribution and patience.
We discussed both this PR and PR 4068 today. The plan of action is to:

merge your contribution as-is (without citing the other/older implementations)
review and work with SzymonPobiega on PR 4068 over the next 2 months, to draft the messaging bridge pattern article in our patterns library
go back and update Migrate your e-commerce solutions to Azure and other articles, to point to the new messaging bridge pattern article

cc: @ckittel @RobBagby

CACT #sign-off
#remove-label:"do-not-merge"
#label:"ready-to-merge"


BitTorrent handshake decoding fails when calling decode_messages

BitTorrent handshake decoding fails when calling decode_messages. It works fine for a single message with decode_message.

I'm working on it :)


Redirect related domains

redirects hosts that are not in an allow list to www.pointfree.co

@stephencelis ok done! give it another look!


ArrayIndexOutOfBoundsException: length=2; index=10 on Android

 java.lang.ArrayIndexOutOfBoundsException: length=2; index=10
                                                                  at com.crashlytics.android.core.CrashTest.indexOutOfBounds(CrashTest.java:30)
                                                                  at com.crashlytics.android.core.CrashlyticsCore.crash(CrashlyticsCore.java:639)
                                                                  at com.crashlytics.android.Crashlytics.crash(Crashlytics.java:321)
                                                                  at com.smixx.fabric.SMXCrashlytics.crash(SMXCrashlytics.java:28)
                                                                  at java.lang.reflect.Method.invoke(Native Method)
                                                                  at java.lang.reflect.Method.invoke(Method.java:372)

Fabric isn't recognizing my app
Crashlytics.crash(); does not work
and I have the error above
From the logs, I see that Fabric is initializing correctly
01-28 07:04:16.501 20800-20800/net.app.br D/Fabric: Initializing io.fabric.sdk.android:fabric [Version: <IP_ADDRESS>], with the following kits:
                                                       com.crashlytics.sdk.android:beta [Version: <IP_ADDRESS>]
                                                       com.crashlytics.sdk.android:crashlytics [Version: <IP_ADDRESS>]
                                                       com.crashlytics.sdk.android:answers [Version: <IP_ADDRESS>]
                                                       com.crashlytics.sdk.android.crashlytics-core [Version: <IP_ADDRESS>]

.crash() is supposed to crash your app so it's working correctly. You shouldn't be calling crash() unless you're trying to test crashing.
As you can see from the stack trace the crash is coming from the CrashTest class inside Crashlytics which means this lib is correctly calling through to the Native SDK and that you have that configured properly.

I fell for this too.


Change LAYER_AUCTION to LAYER_STABLE and now is used to store the sta…

…ble pets in the player stable layer

I use layer auction for other things... Are u removing it?

He change the name to stable and chage behavior of stablemaster storing pet there.  You vam use this layer again with no problem.

Since it can be used in multiple ways, while holding stabled pets is done only by one specific npc kind, what about giving it a more generic name? To remark it could be used for other stuff

I dont know if I understand well what u say. If players store pets there, Could it be used for others things? I mean, Are u saying it  can store pets and more stuff?
nolok said "stabled pets is done only by one specific npc kind", I dont understand. It is an npc that uses that layer, but it uses player's layer, not vendor layer, right?

Layer can be use for what you want. Just use the layer number like you did previously. Name is just a define in the source.
But be aware, this layer will now receive you pet stabled.
That said, now npc stablekeeper now use this layer ON the player to store pet.before npc was storing pet on the NPC bank because If you store pet on bank of player, player was able to see it. With this fix, pet will be now store on player on this layer. Before this fix, If you kill a stable npc, player loose all the pet the NPC had on his bank.
@Raylde i say true?

I mean that the layer can be used for auctioned items, stabled pets and other stuff, so instead of changing a specific name for another specific name, i feel that a more generic one would be more appropriate

OK, I took a look on the source. Layer can be used for any kind of stuff as stable system only count t_figurines. Anyway this change have 2 problems or possible problems for servers that use auction system.
1: If someone use auction system to try to sell a horse (t_figurine) or any other mount using that layer, that mount will appear on the stable system. (unless t_figurine's link is not player's uid)
2: If someone use auction system, it will show stabled pets until you modify the script to ignore t_figurines. (or to ignore linked t_figurines)
//
All t_figurines are linked to the one who shrink it? or it is linked only when it is stabled?

As u can see, the code check if "t_figurine->link" is the player using stable system. That check was neccesary when all t_figurines  from diferent players were in the same layer of the npc. Now seems to be useless so we could remove that check. The only reason to keep that check is to solve the problems I mentioned. This way u could remove "link" from T_figurine to avoid it to be shown at stable's dialog. And u can tell auction system to ignore t_figurines that are linked to a player.
Another question: if I put a t_figurine inside a backpack that is inside layer_stable, will it be shown? or system do not check inside containers of that layer?

What about keep layer auction and create a new layer for layer stable? For me its important to store the pet on the player itself. It's a major bug in sphere when you kill the npc the mount dissapear lol.

What about keep layer auction and create a new layer for layer stable? For me its important to store the pet on the player itself. It's a major bug in sphere when you kill the npc the mount dissapear lol.

There are few ways to avoid ur problem by script.
1-
Make Invul your stable master.
2-
ON=@death
f_get_mounts_into_players_bank
3-
on=@death
f_get_mount_somewhere_and_get_them_back_to_stable_master_when_he_spawn.
//u can use the spawn to store the id of the container where the mounts are. And call it back when a new stable_master spawns. It is not hard to script and for me is the best solution to your problem.
//
I would agree maybe creating another layer for it could be fine.  It would avoid conflict with auction_system or other custom system that use auction_layer. But if someone wants to have old system, where pets can only be retrieved where they were stabled, the options are: Create custom stable system or compile custom sphereX.
Should we add a triggers to let people customize?
On=@petretrieve
local.figurine -> uid of the figurine inside the for
Return 1 ->Avoid pet to be shown at stable's dialog.
On=@petstable
src->Player
|-> Stable_master npc
argo->Pets trying to be stabled
Whatever u choose to do is fine for me. Im forced to compile my own sphere anyway and I dont care to much about this. But I like to share my point of view as it seems that nobody thought about the possible problem or backwards compatibility.


Show file extension when creating a new file

Is your feature request related to a problem?
When creating a new File in Windows Explorer or exporting a file from Software like Photoshop, the File extension usually gets shown in the naming input field.
Describe the solution
Show the File extension behind the cursor in the input field.
This helps to

Reassure the user that they are creating the right File
Gives the user a chance to still change the file type easily
Users are accustomed to it, so it helps to avoid things like "File.txt.txt"

Describe alternatives you've considered
If there was no dialogue and the File would be created in the Folder window like in Win Explorer, it would still be necessary
Scope

Capability
Priority

This proposal will allow users to see the file extension in an inline text box when creating a new file
Must

This proposal will allow users to edit the file extension when creating the file
Could

This proposal will get disabled with a feature to toggle file extensions
Could

If Files had a option to toggle File extensions, it could make sense to disable the extension in the dialogue, too i am not sure what users would prefer here, but Windows Explorer does it that way.
If the functionality gets toggled by a show file extensions feature, or the feature does not get implemented this way I think it would be helpful to signal the user that he is indeed creating the file he wants to with text in the file creation dialogue.
For example:
Creating New Text File
Insert File Name
Instead of just:
Insert File Name
(like in the screenshot below)
Additional comment

App Version: <IP_ADDRESS>

@mangoepic Do you mind if I change this feature request to include support for an inline text box (similar to what you see when you rename an item) when creating items?

@yaichenbaum do you mean an option to have file creation that looks like in windows explorer instead of the pop up dialogue?
personally i kinf of like the dialogue, it looks cool and modern, but i haven't used it too much yet .. so can't really say? But if you like this feature i mean sure go ahead, users would probably expect this behaviour anyways? maybe as an option?

Since you can add a extention in the rename and creation text feilds im going to close this.


Improve compilation time of IResearchQueryOptimizationTest

Scope & Purpose
Improve compilation time (at least with clang and RelWithDebInfo). For me this is the difference between >22min and 2min 30s.

merged as part of https://github.com/arangodb/arangodb/pull/9486


Clean up KerasImageFileEstimator params

Before releasing DLP 1.0, we should take the opportunity to clean-up KerasImageFileEstimator's params. Specifically we should:

Update KerasImageFileEstimator.validateParams to check that the imageLoader and modelFile params aren't being tuned. Right now if a user passes said params in a paramMap passed to fit or fitMultiple, we silently ignore the passed params & just use the param values already set in the estimator.
Check to make sure we don't have any other untunable params like those mentioned above.
Remove unused params e.g. inputImageNodeName, outputImageNodeName

https://github.com/databricks/spark-deep-learning/pull/116 and https://github.com/databricks/spark-deep-learning/pull/117 fixes this

Thanks @yogeshg for the PRs! Closing this issue :)


order-by change

Hey Andrew, one of the side effects of this recent change (be6dbbbc39561567b8ee0e32ffb30766403b297d) was that the following order-by clause ceases working.   That was not my intention. Sorry for the problems (I really need to write some tests for this library). My intention was to add the ability to sort by index. Looking at the code, I'm wondering if there's a way to fix this, although it might take an API change, ie going from &rest fields to just fields and passing in fields as a list manually.
I can try to take a look in the next few days, but if you get a chance, please feel free to open a PR.
Thanks for hte heads up!

You know, I'm actually wondering if we should just add an order-by-idx command. It would preserve backwards compatibility with the old version of the call. Thoughts?

Thanks for your help and sorry for my anaemic first post, it was too late at night... order-by-idx is fine with me and I feel I should write it for you but I'm too tired to work out if it needs to be termval 41 or something else...
But don't do it just on my account either as I now have a quicklisp local-projects version of cl-rethinkdb, reverted before this change, and I'll be happy there for sometime/forever...


Error compiling in Windows Ubuntu WSL 2: "recompile with -fPIE"

I tried to compile openfast in Windows wsl 2 - Ubuntu 20.04. But after the make command the shell asks to recompile with -fpie, i tried the command make -j6 -fpie, but is not a recognizable command according to make.
Bug description
[ 99%] Linking Fortran executable openfast
/usr/bin/ld: ../../modules/map/libmapcpplib.a(mapapi.c.o): relocation R_X86_64_32 against symbol `cable_library_meter' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ../../modules/map/libmapcpplib.a(maperror.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ../../modules/map/libmapcpplib.a(mapinit.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ../../modules/map/libmapcpplib.a(outputstream.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ../../modules/map/libmapcpplib.a(bstrlib.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ../../modules/map/libmapcpplib.a(jacobian.c.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ../../modules/map/libmapcpplib.a(lineroutines.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: ../../modules/map/libmapcpplib.a(numeric.c.o): relocation R_X86_64_32 against symbol `inner_function_evals' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status
make[2]: *** [glue-codes/openfast/CMakeFiles/openfast.dir/build.make:126: glue-codes/openfast/openfast] Error 1
make[1]: *** [CMakeFiles/Makefile2:1843: glue-codes/openfast/CMakeFiles/openfast.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[100%] Linking CXX static library libopenfastlib.a
[100%] Built target openfastlib
make: *** [Makefile:136: all] Error 2"

CMakeCache.txt
log.txt
To Reproduce
git clone https://github.com/OpenFAST/OpenFAST.git
cd OpenFAST
mkdir build
cd build
cmake ../
make -j6
OpenFAST Version
I tried the releases v2.5.0 and v2.6.0, but i got the same behaviour.
System Information (please complete the following information):
Windows 10 Pro; 21H1; 19043.985; Windows Feature Experience Pack 120.2212.2020.0
"wsl -l -v
NAME            STATE           VERSION
Ubuntu-20.04    Running         2"

I don't have a good guess on this, but one thing that stands out from the CMakeCache is that you're C++ and C compilers are those distributed with OpenFOAM. Can you try installing GCC (apt-get install gcc) and reconfiguring CMake? You'll have to delete your existing CMakeCache.txt since you are changing the compiler.

Thank you!
@rafmudaf Your guess is correct.
I don't know why cmake linked to c++ and c of openfoam, i had already installed gcc and other requirements.


Native DateTime64 column

Hi Clickhouse dev team,
Has it been considered to add a native DateTime64 column type which would have the exact same functionality as the existing DateTime, but rather than storing seconds since epoch in an UInt32, store nanos since epoch in a UInt64?
I get that you could kind of emulate the functionality by just using an UInt64 to store the timestamp as nanos since epoch, but it would be significantly less convenient (eg. it doesn't wouldn't easily do timezone conversions, not do formatting, not have all the addTime functions for shifts and also the aggregations/sampling would be more complicated than need be).
Thanks for your time,
Martijn

https://github.com/yandex/ClickHouse/issues/3507

@den-crane Thanks for the reference, I managed to overlook that issue in my search. The issue raised there is the memory consumption for the lookup tables (I haven't dug into the implementation yet), but if you keep the resolution of the lookup tables the same, 2^32 seconds = 136 years and 2^64 nanos = 584 years, which would keep the increase in memory consumption limited to about 4x for the lookup tables. Furthermore, you could maybe limit the amount of entries in the lookup table to the same range as the 32-bit value if the memory constraint is really an issue.
@alexey-milovidov I'd be curious to know the reasoning behind marking the issue as wontfix: infeasible? not prioritized? I obviously have a lot less experience with the code base so would be interested in your thoughts.

I don't really understand what is the difference if you store fraction in another column?
Just convince for in your backend?

Convenience is definitely a big part of it with proper formatting etc when running analytic queries but also general table cleanliness and preventing bugs in accidentally rounding the times when forgetting the fractional part. Lastly I recently added an asof join to ClickHouse which currently only performs the asof operation on the last column (similar to kdb+), which would have to have significantly more complexity if it needed to understand multi column asof joins. A DateTime64 / nanos since epoch column would solve all of these issues and I can imagine it could be an useful feature for anyone currently falling back on splitting out the fractional part.

IMHO it's nice to have 'someday', currently not high priority task at all. I would say that option with storing microseconds since Epoch in signed Int64 (exactly like in JavaScript Date) sounds better than nanoseconds (nanoseconds is too granular for most of database tasks, with microseconds DateTime64 can process any timestamp ranges you can imagine, i.e. you can store dates of birth of  Ramesses I and James T. Kirk).
The biggest disadvantage of high granular timestamp is that micro/nanoseconds fractions are quite 'random', i.e. have too big entropy and compresses very bad, data processing speed is obviously depends on data size (both compressed and uncompressed). Where conditions by timestamp are very common. So your WHERE conditions will need to process twice of data, and will require 5-10 times more data to read from disk (because usual 32bit timestamps are compressed really good almost always). And it will need to use bigger lookup tables and use more complicated calculations.
So your selects will become significantly slower. And it database will have 64 bit time a lot of people will pick it first even if they don't really need that... So it will down Clickhouse for a lot of people.

There are some examples of use cases where it's useful (if not required) to have nanosecond precision, one of them is finance/trading (for pricing/trade/response time analytics).
I agree that it compresses less well, though I'd argue that if the high precision information is needed then there is not much you can do about that (and you'd get the same performance just using UInt64). Furthermore, in the odd case that you do store second-aligned timestamps in the DateTime64 field it should still compress pretty well, though you are still hitting the memory bottleneck of having to load twice as much data.
As for your last argument, a similar case could be made for Float64 and Float32. Some people would pick double precision even though they don't need it, but you'd think that people who run databases in which the difference in performance matters would be aware of the trade-offs between the different field types. Even more so for timestamps, as the granularity is more directly exposed to whoever interfaces with the db.
An option, rather than just adding a plain DateTime64 is to also make the granularity a parameter (currently for DateTime only the timezone is), such that users can select whether they want nanos/micros/millis/seconds since epoch in a 64 bit value, but (1) it might require quite a lot of code to handle all the conversions etc in case of people trying to shift/compare/join/etc on different granularities and (2) having to limit the time span inside the conversion tables (as 2^64 (milliseconds)) is quite a long time.

There are some examples of use cases where it's useful (if not required) to have nanosecond precision, one of them is finance/trading (for pricing/trade/response time analytics).

Of course there are some special scenarios when nanoseconds or even picosecond are needed.
I think that database should give a 'good enough' option for medium user, and a building blocks for complicated usage scenarios. Currently you can implement any precision with 2 fields, anyway for a fraction part of time (no matter if it's micro/nano/picoseconds) you don't need to apply any wierd calendar / timezones logic, and the speed of such an implementation will be comparible to DateTime64 in the cases then you need full precision, and much faster then you don't need that. So it's only convenience issue. As an alternative one Decimal filed and some extra typecasting 'magic' can be used.  Adding DateTime64 is a also quite a big task, for now it's not in priority.

@filimonov : MySQL and Postgres natively support datetime(6) and timestamp(6) that have microsecond precision. If you want to replicate them, you need to support this data type. I think MariaDB column store just added it. https://mariadb.com/kb/en/library/columnstore-data-types/

@filimonov : MySQL and Postgres natively support datetime(6) and timestamp(6) that have microsecond precision. If you want to replicate them, you need to support this data type. I think MariaDB column store just added it. https://mariadb.com/kb/en/library/columnstore-data-types/

I write above: "(DateTime64 is) nice to have someday. ... option with storing microseconds since Epoch in signed Int64 (exactly like in JavaScript Date) sounds better than nanoseconds".
So i agree that microseconds is nice thing. I'm not convinced about nanoseconds. Can you list some database supporting sub-microseconds (nanoseconds) precision? If the precision can be optionated (like in Decimal datatype) - nanoseconds can be acceptable, but not by default.

There are some examples of use cases where it's useful (if not required) to have nanosecond precision, one of them is finance/trading (for pricing/trade/response time analytics).

How do you deal with those cases in other databases?

Datetime(6), timestamp(6), Datetime(3), timestamp(3) are supported by databases like MySQL, Postgres, Redshift, MariaDB column store, SAP IQ. For nanoseconds, people use an unsigned bigint (10 for epoch and 9 for nanoseconds).

For nanoseconds, people use an unsigned bigint (10 for epoch and 9 for nanoseconds).

That's exactly what i'm trying to say :) Microseconds is maximum precision usually needed from database (please read my comments above once again).

I was replying to your question :

How do you deal with those cases in other >databases?

Please implement sub-second precision (milli and micro seconds) rather than second only. That’s enough for most cases. Timestamp(9) might be possible to implement with 64 bits but I doubt Datetime(9) is doable. That is low priority IMHO. For the milli and microsecond precision required for compatibility (heterogeneous replication and migration), you may want to create another feature request.

I was replying to your question.

Question was about nanoseconds :) Nevermind. I glad that we agree that microseconds are needed, while nanoseconds - sounds a bit like overkill.

@den-crane

I don't really understand what is the difference if you store a seconds' fraction in another column?
Just convince for in your backend?

Better compression of integer part.
A room for optimization if we will be able to read just integer part.

This is being addressed.

#7170 work in progress

#7170 work in progress

in fact, it is ready for review, so anyone willing to do that is welcome.


merge from template-sync/template-arlac77-github

.github/workflows/ci.yml

chore: add<EMAIL_ADDRESS>(jobs.test-node.steps.uses)
chore: add<EMAIL_ADDRESS>(jobs.release.steps.uses)

.github/workflows/codeql_analysis.yml

chore: add<EMAIL_ADDRESS>(jobs.analyze.steps.uses)

.github/workflows/update_package_lock.yml

chore: add<EMAIL_ADDRESS>(jobs.update_package_lock.steps.uses)

.github/workflows/update_readme_api.yml

chore: add<EMAIL_ADDRESS>(jobs.update_readme_api.steps.uses)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 22.976%

Totals

Change from base Build<PHONE_NUMBER>1:
0.0%

Covered Lines:
102

Relevant Lines:
453

💛  - Coveralls


[prim] Add sync clear input to prim_fifo_async

Related Issue: https://github.com/lowRISC/opentitan/pull/15727
It is generally recommended to use same reset source (but synchronize to the port clock if needed) for both write/read ports of the asynchronous FIFO. When reset occurs, the read, write depths are reset abruptly as the reset is async reset. This may trigger metastability errors on Reset Domain Cross checker tools.
One solution is to create sync assert sync de-assert reset synchronizer.

@vogelpi: Feels like a can of worms, wouldn't address this for PROD. We know and control the reset sources, so we can control the clearing of both sides. I would investigate if there are scenarios where we don't reset both sides. There are not many of those FIFOs.
@moidx: We did a similar check in the RTL for ES.

For what it's worth, I don't think a synchronous clear mixes well with an async FIFO with circular buffers. In addition, the original motivating module has changed to not use an async FIFO: The TPM RdFIFO is now a linear buffer in a two-port SRAM, where only one transaction is ever present at a time, and the data always begins from offset 0.
I'd recommend closing the issue.

It's a can of worms, for sure, and the TPM RdFIFO was the genesis of this issue so the point seems to be moot there now.
Could we enumerate the places in the design where prim_fifo_async is used here / in an issue (e.g. with check boxes)?  And then do the suggested investigation to see if there are cases where we don't reset both sides?

Response WIP
prim_fifo_async is currently instantiated as follows:
https://github.com/lowRISC/opentitan/blob/46ac5a7210e31ff4f2027b822cc9c163d78b99b2/hw/ip/spi_device/rtl/spi_tpm.sv#L1314-L1332
--> same reset signal for read and write port

https://github.com/lowRISC/opentitan/blob/46ac5a7210e31ff4f2027b822cc9c163d78b99b2/hw/ip/spi_device/rtl/spid_status.sv#L263-L282
--> same reset signal for read and write port

https://github.com/lowRISC/opentitan/blob/46ac5a7210e31ff4f2027b822cc9c163d78b99b2/hw/ip/tlul/rtl/tlul_fifo_async.sv#L28-L59
https://github.com/lowRISC/opentitan/blob/46ac5a7210e31ff4f2027b822cc9c163d78b99b2/hw/ip/tlul/rtl/tlul_fifo_async.sv#L65-L96

There's a related module, prim_fifo_async_simple, which is currently instantiated as follows:
https://github.com/lowRISC/opentitan/blob/46ac5a7210e31ff4f2027b822cc9c163d78b99b2/hw/vendor/pulp_riscv_dbg/src/dmi_cdc.sv#L85-L101
https://github.com/lowRISC/opentitan/blob/46ac5a7210e31ff4f2027b822cc9c163d78b99b2/hw/vendor/pulp_riscv_dbg/src/dmi_cdc.sv#L103-L119

@andreaskurth to decide on next steps and determine if this should be part of M4.

@vogelpi is auditing the RTL. TL-UL instances have different reset connections. Inspecting to see if the resets are derived from the same root.
Alex: It is also ok if the reset connected to the FF takes longer to ensure the overlap is on the right signal to ensure transactions don't fall through.

Relevant resets for tlul_fifo_async are in xbar_main:
https://github.com/lowRISC/opentitan/blob/50c4e6f0764f0225479efe924e8177b220cd3ec2/hw/top_earlgrey/rtl/autogen/top_earlgrey.sv#L2829-L2833
These all reset together when the whole LC domain is reset:
https://github.com/lowRISC/opentitan/blob/50c4e6f0764f0225479efe924e8177b220cd3ec2/hw/top_earlgrey/ip_autogen/rstmgr/rtl/rstmgr.sv#L264-L266
There is no software control of these infrastructure resets, so the only source is that LC domain reset. In addition, all the downstream nodes in the TL-UL fabric are also reset with that LC domain reset.

Thanks @a-will for looking into this and feeding back! I started looking at the very same place but was then interrupted by something else before drawing a conclusion.
Based on your assessment that:

These resets all reset together when the whole LC domain is reset, and
There is no software control of these infrastructure resets,

I am thinking that we don't need to do anything here for the current designs. Theoretically, we could think to look into this again for future releases. However, if we really wanted to reset these resets more independently, we probably would need to do a bigger overhaul of the entire reset architecture and investigate many other RDCs (e.g. EDN connections, RV_DM etc.). I am not sure how likely that is.
My suggestion would thus be to simply close this as not planned.

Thanks @andreaskurth, @a-will and @vogelpi for your assessment.
Leaving this issue as part of M4 to document the auditing work.
Closing as not planned change based on the analysis outcome.


Pause a phased release using Spaceship

Question Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Question Subject
How to pause a phased release using Spaceship.
Question Description
We would like to have control over the release once we have started rolling out our phased release.
For what we can read in the docs, this is possible using AppStoreConnect:

While your app is in phased release, you can choose to pause the release for a total of 30 days, regardless of the number of pauses. If you remove your app from sale, your current phased release will stop and will not be available for that version again.

You can pause your release for a total of 30 days. For example, if you pause your release for 10 days, and then resume, you will have 20 days left to pause the release a second time. If you resume a release that was previously paused, your phased release will pick up on the day it was left off when it was paused.

Looking at the source code, we couldn't find any place to control this.
  # Currently phased_release doesn't seem to have all the features enabled
  #
  #     => {"state"=>{"value"=>"NOT_STARTED", "isEditable"=>true, "isRequired"=>false, "errorKeys"=>nil},
  #        "startDate"=>nil,
  #        "lastPaused"=>nil,
  #        "pausedDuration"=>nil,
  #        "totalPauseDays"=>30,
  #        "currentDayNumber"=>nil,
  #        "dayPercentageMap"=>{"1"=>1, "2"=>2, "3"=>5, "4"=>10, "5"=>20, "6"=>50, "7"=>100},
  #        "isEnabled"=>true}
  #

There are some fields for that: pausedDuration and totalPauseDays, but looks like the client doesn't have the functionality right now.
We would like to know if this is currently possible, what are the caveats around it. And if it's not in palce we can consider adding it to the repository.
Thanks in advance!

And if it's not in palce we can consider adding it to the repository.

That sounds like a great idea. Please make sure to keep the existing code backwards compatible 👍

Thanks @janpio . Let's see how we move this forward. Thanks!

I want to know how to start phased release?
I found this method Spaceship::TunesClient.release!, but it seems not for phased release.

Thanks @janpio . Let's see how we move this forward. Thanks!

Any progress?


The root detection logic used by Cordova framework is not applicable to API 26 and above

Cordova framework consists of "RootDetection" class. This class implements root detection logic which is applicable to API 25 and below.
During testing one of the mobile application, we found that the root detection logic is not applicable to API 26 and above.

Hello. Could you provide on which version of cordova, cordova-platform i can reproduce this bug.
I've installed 7.0.1 cordova with<EMAIL_ADDRESS>Run demo app with installed root plugin on pixel _api_26 emulator and successfully debugged with android studio.
Need more information or demo app to reproduce.
Did't find any RootDetection on github cordova repos

Hi!
I have the same problem,my version are:
android 6.2.3
cordova 7.1.0


distogram database

Is there a distogram database of all the publicly released protein structure? Is it possible to search for a similar structure through distogram? What is the best way to find proteins with similar structure?

I contacted Alphafold database to ask whether the intermediate data are available somewhere and I'm waiting for the answer (but I will try to double check spam folder)

Hi, sorry, a database of distograms is not currently available. The AlphaFold Protein Structure Database currently contains only the predicted coordinates, predicted LDDT and the Predicted Aligned Error.


feat(search): explain decompounding at query time

Please add the following modifications to both query and searchReponse object
Addition to existing JSON schemas
Query: new optiona parameter explain
{
  "explain": string?
}

SearchResponse: new explain response field
        "explain": {
            "match": {
                "alternatives": [
                    {
                        "type": string,
                        "words": string[],
                        "typos": int,
                        "offset": int,
                        "length": int
                    }
                 ]
            }
         }

also just for definitely typed


Add AdjArrayBQM.data and AdjArrayBQM.from_data

We need to use cdef classes for the reference counting to work correctly. I will see if there are ways to reduce the boilerplate but the typing creates a lot of repetition.


No ability to set TcpClient.NoDelay to true

Hi,
There does not seem to be a way to configure the underlying socket connection to send small messages immediately. You would typically do this on a simple TcpClient by setting the NoDelay property to true. As it now stands the application will wait a few milliseconds for more potential data before it completes a TCP segment and puts it on the wire. Would it be possible to enable this behaviour somehow? This would be very beneficial for low latency applications.
Thanks

You're looking at the wrong layer. WebSockets don't own the underlying socket, the server does. I suggest asking this question in https://github.com/aspnet/KestrelHttpServer.

There does not seem to be a way to configure the underlying socket connection to send small messages immediately. You would typically do this on a simple TcpClient by setting the NoDelay property to true. As it now stands the application will wait a few milliseconds for more potential data before it completes a TCP segment and puts it on the wire. Would it be possible to enable this behaviour somehow? This would be very beneficial for low latency applications.

Also NoDelay is true by default.


updated pileup to bypass null json responses

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/mango-prb/319/
Test PASSed.


Zoom SDK 5.

i get error

I have the same problem, will there be an update?

same problem
flutter_zoom_sdk: ^1.1.0+4

Anyone is welcome to use my fork. I've just updated both Android and iOS SDKs to the latest versions (5.14.0):
flutter_zoom_sdk:
git:
url: https://github.com/craigspicer/flutter_zoom_sdk.git
ref: main
Run the same command after adding the above to your PubSpec.yaml:
flutter pub run flutter_zoom_sdk:unzip_zoom_sdk
I also added a method:
returnToMeeting();
and functionality so that the user does not get asked for details when joining:
userEmail: {email},
userId: {uid},


 It is part of my continued work on the Ruby formatter sponsored by the Ruby association (https://www.ruby.or.jp/en/news/20211025). The goal is to enhance the PrettyPrint class enough to support all of the necessary print functionality that the formatter will require in order to print out Ruby source correctly.
First, let's take a look at how PrettyPrint works today. PrettyPrint has 3 primitives:

Group - an object that represents a set of content and its associated breakpoints. These objects are usually nested. When one of them no longer fits on a single line, it is broken at all of its associated breakpoints. For example, if you have something like [text("abc"), breakable, text("def")] and that group no longer fits on one line, then you will have two lines of output.
Breakable - an object that represents a location where a line of content can be split. When it is created, if the current group is broken already, then it inserts a newline and carries on. If it is not, then it adds itself to the output buffer.
Text - this is a set of objects that are appended to a buffer. If the buffer overflows the maximum print width for the line, then the surrounding group is broken and the buffer is flushed to the output.

With those primitives in place, the printer maintains a buffer of content that is being added. If the buffer overflows the line, the content is flushed until another group is hit or there are no more breakpoints.
There are a couple of limitations with the current approach.

PrettyPrint assumes that content in Text will not change its representation if it is contained within a broken group versus contained within a flat group. This isn't a problem for the existing uses of PrettyPrint, but for my purposes of building a formatter, it definitely is. Consider something like trailing commas (where you want a comma if it is broken but nothing if it's not) or block operators (where you would use a do and end for multi-line (broken group) or braces for single line (flat group)).

The Breakable class assumes that you always want to indent the subsequent line up to the current indentation level. This is true in most cases, and certainly for all the existing use cases. But there are times when you don't want that behavior (for example if you're in the middle of a nested indentation structure but have to force content to start at the beginning of the next line as in a comment with =begin..=end bounds).

There's no way to force a group to break. You can access the current group in the printer with current_group, but that won't force the parent groups to break. Without hacking around a lot of stuff, it's difficult to get this behavior. This is necessary if you want to ensure a newline is added and respected, like after a keyword where it would be necessary.

This commit adds a couple new nodes to the printing tree, as well as enhancing the Breakable class. First, the new nodes:

Align - this node effectively wraps the old @indent variable but allows you to align content within any of the other containers. You can also align to a string now instead of just an integer, which will print that string before each line.
BreakParent - enforces that the surrounding group and all ancestral groups are broken.
IfBreak - contains two sets of nodes, one for if the surrounding group is broken and one for if the surrounding group is flat.
Indent - similar to the align node, but you don't have to specify anything and it just indents by one level.
LineSuffix - this is a big enhancement to the printing algorithm that maintains a separate buffer for content that should be flushed before the next newline. This is convenient for implementing things like heredocs and trailing comments.
Trim - a rarely used but important node that trims off whitespace that has already been added to the buffer in the case that you need to force something to begin at the start of the next line.

As for the enhancements to Breakable:

It now accepts a force parameter (default to false), which will insert a BreakParent and slightly change semantics so that a newline is always added.
It now accepts an indent parameter (default to true), which allows you to specify if you want the subsequent line to indent automatically.

For the most part, the code is completely compatible with the previous version.
There are a couple of things that were removed that appeared to be all internally-facing functions. When they were removed all of the tests still passed, so I'm assuming they were only called internally. I can certainly add them back if it's deemed too risky but I very much doubt this is a problem.

indent attr_reader which is now encapsulated in the printing algorithm
group_queue attr_reader which had a reference to a queue that is no longer necessary
break_outmost_groups method, which is now encapsulated in the printing algorithm
group_sub method, which was only called by the group method anyway and is no longer necessary

There were a bunch of things that were added, including:

force and indent parameters to the breakable method (they both have defaults so this shouldn't be an issue)
Align, BreakParent, IfBreak, Indent, LineSuffix, and Trim nodes
Buffer::DefaultBuffer, Buffer::StringBuffer, and Buffer::ArrayBuffer, which is just there to provide the ability to trim trailing whitespace
PrettyPrint.visit(doc, visitor), which is useful for debugging and also necessary for propagating break parent nodes up the tree

All in all, none of the tests had to change, which is a good sign.
From the user of this class's perspective, nothing is different. Internally however, there's a bunch of additional functionality and a lot more control over the printing algorithm! Also the ability to debug has been greatly enhanced with pretty_print methods on each of the nodes and the ability to walk the print tree nodes before they're printed.

I opened this on ruby/ruby and got the feedback that this was a little large for a review 😅. Totally understandable. I'm planning on breaking this up into multiple PRs, but I figured I'd put this up in the meantime while I get that figured out.

It may be a good idea to create a feature at https://bugs.ruby-lang.org/projects/ruby-master.

Thanks @duerst, I opened the issue here: https://bugs.ruby-lang.org/issues/18654.


Fix affinity translation

For affinity translation, instead of writing to the k8s spec,which requires extra logic to converting the original format to k8s affinity, just put it in the values pass through to make sure things work correctly.

@richardwxn: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

test_operator
bd9b15d5135740b55c12703f04adc717d843bb5c
link
/test test_operator

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

In response to a cherrypick label: #690 failed to apply on top of branch "release-1.4":
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M	cmd/mesh/testdata/manifest-migrate/output/values.yaml
M	pkg/translate/translate_value.go
M	pkg/translate/translate_value_test.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/translate/translate_value_test.go
CONFLICT (content): Merge conflict in pkg/translate/translate_value_test.go
Auto-merging pkg/translate/translate_value.go
Auto-merging cmd/mesh/testdata/manifest-migrate/output/values.yaml
Patch failed at 0001 Fix affinity translation