Unable to use local Dask with coiled-runtime=0.0.3

When I create an environment with coiled-runtime version 0.0.3, I am unable to use local dask client.
Steps to reproduce:

Create environment.yml with these contents:

name: coiled_test_dask
channels:
- conda-forge
dependencies:
- python=3.9
- coiled-runtime=0.0.3
- dask

Launch interactive python:

python -i

Attempt to create a client:

from dask.distributed import Client
client = Client()

The full traceback is below:

objc[2848]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2848]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2847]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2847]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2849]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2849]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2850]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2850]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2851]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2851]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2852]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2852]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2853]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2853]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2854]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2854]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2855]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2855]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2856]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2856]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2857]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2857]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2858]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2858]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2859]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2859]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2860]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2860]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2861]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2861]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2862]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2862]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2863]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2863]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2864]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2864]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2865]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2865]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2866]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2866]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2867]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2867]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2869]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2868]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2869]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2868]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2870]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2870]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2871]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2871]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2872]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2872]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2873]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2873]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2874]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2874]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2875]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2875]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2876]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2876]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2877]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2877]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2878]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2878]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2879]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2879]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2880]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2880]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2881]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2881]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2882]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2882]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2883]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2883]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2884]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2884]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2885]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2885]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2886]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2886]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2887]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2887]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2888]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2888]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2889]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2889]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2890]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2890]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2891]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2891]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2892]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2892]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2893]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2893]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2894]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2894]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2895]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2895]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
distributed.nanny - ERROR - Nanny failed to start process
Traceback (most recent call last):
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/nanny.py", line 691, in start
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/process.py", line 32, in _call_and_set_future
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/process.py", line 186, in _start
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/process.py", line 121, in start
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/context.py", line 291, in _Popen
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_forkserver.py", line 35, in __init__
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_fork.py", line 19, in __init__
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_forkserver.py", line 42, in _launch
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/spawn.py", line 176, in get_preparation_data
OSError: [Errno 24] Too many open files
objc[2896]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2896]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2897]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2897]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2898]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2898]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2899]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2899]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2900]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2900]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2901]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2901]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2902]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2902]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2903]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2903]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2904]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2904]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2905]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2905]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2906]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2906]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2907]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2907]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2908]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2908]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2909]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2909]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2910]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2910]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/forkserver.py", line 258, in main
    fds = reduction.recvfds(s, MAXFDS_TO_SEND + 1)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/reduction.py", line 159, in recvfds
    raise EOFError
EOFError
distributed.nanny - ERROR - Nanny failed to start process
Traceback (most recent call last):
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/nanny.py", line 691, in start
    await self.process.start()
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/process.py", line 32, in _call_and_set_future
    res = func(*args, **kwargs)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/process.py", line 186, in _start
    process.start()
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/context.py", line 291, in _Popen
    return Popen(process_obj)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_forkserver.py", line 51, in _launch
    self.sentinel, w = forkserver.connect_to_new_process(self._fds)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/forkserver.py", line 90, in connect_to_new_process
    child_r, parent_w = os.pipe()
OSError: [Errno 24] Too many open files
objc[2911]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2911]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2913]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2913]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2914]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2914]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2915]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2915]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2916]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2916]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2917]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2917]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2918]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2918]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2919]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2919]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2920]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2920]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2921]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2921]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2922]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2922]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2923]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2923]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2924]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2924]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2925]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2925]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2926]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2926]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2927]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2927]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2928]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2928]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2929]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2929]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2930]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2930]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2931]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2931]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2932]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2932]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2933]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2933]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2934]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2934]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2935]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2935]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
objc[2936]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[2936]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
distributed.nanny - ERROR - Nanny failed to start process
Traceback (most recent call last):
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/nanny.py", line 691, in start
    await self.process.start()
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/process.py", line 32, in _call_and_set_future
    res = func(*args, **kwargs)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/site-packages/distributed/process.py", line 186, in _start
    process.start()
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/context.py", line 291, in _Popen
    return Popen(process_obj)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/popen_forkserver.py", line 51, in _launch
    self.sentinel, w = forkserver.connect_to_new_process(self._fds)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/forkserver.py", line 89, in connect_to_new_process
    parent_r, child_w = os.pipe()
OSError: [Errno 24] Too many open files
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/forkserver.py", line 258, in main
    fds = reduction.recvfds(s, MAXFDS_TO_SEND + 1)
  File "~/miniconda/envs/coiled_test_dask/lib/python3.9/multiprocessing/reduction.py", line 159, in recvfds
    raise EOFError
EOFError

Below are the dask and distributed versions:

import dask; print(dask.version)
2022.01.0
import distributed; print(distributed.version)
2022.01.0

These are installed automatically via conda on MacOS.

Thanks for reporting @SultanOrazbayev. Unfortunately I'm not able to reproduce. I get the following when running locally on my mac
Python 3.9.12 | packaged by conda-forge | (main, Mar 24 2022, 23:23:20)
[Clang 12.0.1 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from dask.distributed import Client
>>> client = Client()
>>> client
<Client: 'tcp://<IP_ADDRESS>:58036' processes=4 threads=8, memory=16.00 GiB>

I see OSError: [Errno 24] Too many open files in the logs you posted. Maybe you have too many connections open elsewhere on your machine (xref https://distributed.dask.org/en/stable/faq.html#too-many-open-file-descriptors)? A few related questions come to mind:

Are you able to consistently reproduce this error?
What happens if you restart your machine and try again -- does the error still happen?
What happens if you increase your ulimit before running python -i? (e.g. run ulimit -n 5000 and then python -i)

Are you able to consistently reproduce this error?

Yes, on a Mac. On Ubuntu, the issue is not reproduced.

What happens if you restart your machine and try again -- does the error still happen?

Yes, after restarting Mac, the error remains.

What happens if you increase your ulimit before running python -i? (e.g. run ulimit -n 5000 and then python -i)

Same error happens: "objc[1061]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug."
Since the Ubuntu install works fine, I suspect there is something wrong with my Mac, so I hope this issue is OK to close.

Just in case someone will have a similar problem, here's how I fixed it:

deleted dot-config files related to conda and dask:

rm -vi .condarc .dask/config.yaml

deleted and reinstalled conda. Now, local client works without problems.


Blazor custom-reconnect docs do not appear to match actual behaviour

Describe the bug
The doc page https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.0
contains a description of adding a #components-reconnect-modal element, and the way in which the framework will embellish the element with various state-dependent classes.  This includes
components-reconnect-hide – The client has an active connection, hide the UI.

It doesn't appear that this class actually is added in normal operation.
To Reproduce

Add the following element to _host.cshtml in a s/s Blazor app

  <div id="components-reconnect-modal"> </div>

Run the app so that it's operating correctly (i.e. it's connected)
Use the browser's dev tools to inspect the components-reconnect-modal div you added.
Observe that it has no added classes.  The docs imply it should have "components-reconnect-hide"
If you stop the server, you can observe that the framework will correctly change the class of this element - it's just the initial condition which is not handled.

There is a simple workaround which is to add class="components-reconnect-hide" to the element, but the docs don't imply this is necessary, and I'm not clear if this is a doc issue or an actual problem.
Further technical details

ASP.NET Core version
3.0

Include the output of dotnet --info
You really don't want all of that...
3.0.100 [C:\Program Files\dotnet\sdk]

The IDE (VS / VS Code/ VS4Mac) you're running on, and it's [sic - this apostrophe was in the template, honest] version
VS 2019 16.3.5

Thanks for contacting us, @willdean.
@javiercn did we forget to add this, or things change and the docs need to be updated?

@mkArtakMSFT You beated me :).
I think this might just need a doc update? If you add your own its likely you need to place components-reconnect-hide in the component as a starting point.
I think that the moment you use a custom display you need to handle 3 cases.

Initial: components-reconnect-modal.
During reconnection: components-reconnect-modal components-reconnect-show
After successful reconnection: components-reconnect-modal components-reconnect-hide

.components-reconnect-modal {
  display: none;
}

.components-reconnect-modal.components-reconnect-show {
  display: block;
}

We should update the docs to reflect this. We should consider in the future putting this directly on the template instead of the current shenanigans that we do. It's a bit more code but it's much straight-forward

.components-reconnect-modal
should be
`#components-reconnect-modal'
It's an ID - the states are indicated by classes.

.components-reconnect-modal
should be
#components-reconnect-modal
It's an ID - the states are indicated by classes.

Thanks, it was an oversight on my part. I've updated the rule.


<EMAIL_ADDRESS>

Description
Currently, I'm working on new, AFPv5 compatible wrapper.
The new version requires<EMAIL_ADDRESS>and higher.
To-Do list:

[x] wrapper for CE version should be available by import {...} from 'angular-handsontable'
[x] wrapper for PRO version should be available by import {...} from 'angular-handsontable/pro'
[x] tests
[x] should works properly with ng build --prod
[x] should works properly with ng build --prod --aot
[x] should be possible to use the wrapper in dev environment ng serve
[x] npm package should be free from unnecessary files (src, tests)

If you have any idea, what else I should add to the wrapper, share it in a comment.

Hi @SimonKnu, actually today ;)

At the very beginning, I would like to say "Thank you!" for @dherges and his project https://github.com/dherges/ng-packagr. Without his work (and community, of course) creating angular wrapper is a nightmare.
So, let's back to the point. We've decided to release one more beta version: 1.0.0-beta4

Why?

Actually, there are a few things:

handsontable-pro in angular project.
And we did it. You can install npm i @handsontable-pro/angular handsontable-pro and everything should works. Of course, currently, there are some limitations. Wrapper works with @angular/cli 1.5.0+ (Angular 5) and zone.js 0.8.19+.
But.
What's about support for Angular 4? (it's an LTS version). We have no answer, yet.
Perhaps, we have to release wrappers separately for Angular 4, Angular 5 and any next version.
My first idea here is to release wrappers as in below example:
<EMAIL_ADDRESS>require<EMAIL_ADDRESS><EMAIL_ADDRESS>require<EMAIL_ADDRESS><EMAIL_ADDRESS>will require<EMAIL_ADDRESS>

Simple installation process.
And this is also done. If you want to use Handsontable in your project you can follow this step by step instruction:

install a wrapper and Handsontable
npm i @handsontable-pro/angular handsontable-pro
import HotTableModule to your app.module.ts
import { HotTableModule } from '@handsontable-pro/angular';
and add our module to array with rest of imported modules,
add @import '~handsontable-pro/dist/handsontable.full.css'; into your style.css file
add <hot-table></hot-table> into your template.

Single npm package for CE and PRO version.
After a few tries to do it, we've decided to release separated wrappers as a scoped packages.
@handsontable/angular for Handsontable CE
@handsontable-pro/angular for Handsontable PRO
We've figured out a lot of issues with bundling, extra configs for tsc and @angular/cli and etc.

What's next?

We have to find a solution for Angular 4.
Publishing process must be automated.
We have to update documentation.

I tried using the module but it gave me the following error.
Error: StaticInjectorError(AppModule)[HotTableComponent -> HotTableRegisterer]:    StaticInjectorError(Platform: core)[HotTableComponent -> HotTableRegisterer]:      NullInjectorError: No provider for HotTableRegisterer!     at _NullInjector.get (core.js:1002)     at resolveToken (core.js:1300)     at tryResolveToken (core.js:1242)     at StaticInjector.get (core.js:1110)     at resolveToken (core.js:1300)     at tryResolveToken (core.js:1242)     at StaticInjector.get (core.js:1110)     at resolveNgModuleDep (core.js:10850)     at NgModuleRef_.get (core.js:12083)     at resolveDep (core.js:12573)

Hi @anandhuajayakumar,
could you create a new issue with information about a version of angular and/or angular-cli?

@swistach  the error was removed when i added HotTableRegisterer as a provider.
I am using angular cli version 1.6.8 and typescript version 2.5.3.
But even though there ain't error the filters are not working.

@anandhuajayakumar you can also replace HotTableModule withHotTableModule.forRoot() in imports array in app.module.ts file.
If you find new problem, please create new issue (you can do it here: New issue


Edge Storage Research

Investigation on the existing open-source distributed storage projects, e.g.

Anna
OrbitDB
EdgeFS
Azure Cosmos DB, see description in this paper
Other?

To-do:

Compare the use cases these projects target
Compare the available features of these projects
Compare the underlying technology of these projects
Brainstorm a full list of possible features for Edge Storage
Brainstorm a full list of possible use cases for Edge Storage

The end goal of this task is to identify potential edge storage features for edge.
Time:
Target by 1/7

added "end goal" to the description

Scope statement:
There are two-level CRDT in geo-distributed storage:
(1) Application-level CRDT: embed CRDT operations to applications
(2) Storage-level CRDT: CRDT is a consensus component to the storage solution.
What I am focusing here is Option (2).
Progress:
[Done] IPFS
[Done] OrbitDB
[Done] EdgeFS
[Pending] AntidoteDB
[Pending] Riak


sampler test cases

Currently, the test cases for the sampler use binary files as input which makes it difficult or impossible to understand and edit test cases. It would be great if we had a compact, readable, and self-contained text representation (eg. Alchemy format with atoms, predicates, weights).
Across different test cases, we then want to keep all parameters fixed except for the issue that we are testing. Eg. the epsilon from target expectation, number of samples, etc may be fixed, while we vary factors.

@netj draws a similar point in https://github.com/HazyResearch/sampler/commit/9296be214f40acda711d84ff4045154deccc5f2d#commitcomment-11008261 that we could easily use the "format-converter in DeepDive" to produce the binary given a text input. I think this should be pretty easy to do (maybe also with the Bats thing for testing that @netj used in that ticket?)
Ce

That sounds great, that solves the issue!
Longer term, we may still want to switch to an even more readable representation. I think the text format is still pretty hard to parse for a human, especially when compared to the Alchemy format, but I think for now it's great.
Another minor point: I like using a testing framework that is less complex than C++, but we are now using 4 different testing frameworks (for C++, scala, python, bash). It seems we could simplify by sticking to python for this. I imagine a future version of deepdive which only uses C++ and python.


[top_earlgrey] Timing optimizations for production

This is a tracker for timing optimizations for Earlgrey-PROD.
Planned for M3:

[x] Decouple sram_ctrl's a_ready TL-UL signal from a_valid
--> #22497
[x] Decouple sram_ctrl's a_ready TL-UL signal from a_opcode (through tlul_we)
--> #22497
[x] Break path from tl_i to tl_o in tlul_sram_adapter
--> #22588
[x] Rework tlul_err_resp
--> #22588
[ ] Reduce the number of PRINCE rounds for the ICache scrambling back to 5 effective rounds.
--> #22948

Update: PRs to fix all feedthrough paths between Ibex and SRAM_CTRL (the critical path of the design) were filed and merged, an RC was tagged and sent to the PD team to trigger a new synthesis run and the generation of a timing report. We're now waiting for feedback.

By @vogelpi: Discussed with PD team yesterday, feedback pending.
By @andreaskurth: Timing closure for M3 is not required. Can be moved to M4 if needed.
By @moidx: That would be my recommendation as well, given the timeline.

Update: we got feedback from the PD team. There are some violations left between the ICache and the main SRAM that we can hopefully get rid of by reducing the number of scrambling rounds in the ICache again. This is acceptable from a security viewpoint.


cub200-2011，config文件中的参数设置没变batch=16，双卡训练，准确率最高在0.869。

batchsize=16,两块GPU训练，学习率0.001，达不到论文中的0.875的准确率。请问，你们达到的是怎么设置的参数？训练了多少epoch?

Hi @weihua93
How many epochs you conduct when the accuracy is 0.869?
Thanks

Hi @weihua93
How many epochs you conduct when the accuracy is 0.869?
Thanks

183

Thanks

hi, I have some problems on the pretrained model of ResNet50 on ImageNet, which pretrained model did you use, the 224224 one or the 448448 one?

I used 448

I used 448

Thank you!  While I can't find the pretrained model with size of 448, Can you send me one? my email is<EMAIL_ADDRESS>

The provided one is 448

The provided one is 448

you mean here provided the one of 448, I just can't open the link

I have sent your email. Please check it.
Let me know your result from scratch if you train model

I have sent your email. Please check it.
Let me know your result from scratch if you train model
Sorry，I still can't open the link you send me.

So sorry to touble you.

+1, 试了多种batch_size，多卡组合，准确率最高只能到0.868

I got the best accuracy of 87.3% (K=4) in epoch 127 following default setting. Although the accuracy fluctuates between 86.8% and 87.3% from epoch 127 to epoch 156 (I stopped in epoch 156).

@MichaelLiang12 Did you use the defaulted parameters to get  87.3%? or made some change on the config ?

Just as I said, I followed default setting with no changes.


docs(examples): simple asset transfer in the new architecture

Description
As a developer/contributor I want to have updated documentation about the simple asset transfer demo that I saw during the Hyperledger Global Forum 2020 talk so that I am not confused about the fact that (currently) there is no such documentation since we've moved over to the new architecture.
Context:
A fully fledged example has been developed as part of v0.2.0, but it does not do asset transfer yet so it only partially resolved the
original version of this issue (OG is here: #189 )
See also my comment: https://github.com/hyperledger/cactus/issues/189#issuecomment-716914627
Acceptance Criteria
1.The simple asset transfer use-case is re-written from scratch to match the new arch
2. The new documentation closes the loop regarding asset export verification and error handling as well (thanks to Arnaud for pointing out the lack of these)
cc: @sfuji822 @takeutak @jonathan-m-hamilton

Hello @petermetz can you assign this to me? Thank you

Hello @jagpreetsinghsasan I am also helping on this one, Thanks!

Created spike #2655 so that @ruzell22 and @aldousalvarez can estimate the complexity of this task


Fix for mock store and :BindToClose()

I can't seem to fix merge requests from here, once you fix that I can merge

I think you're write about the BindToClose in studio. I don't wanna bother you to change, I will merge and change with my commits


Reversing typing order during animation breaks component

Version
0.4.1
Steps to reproduce

Set typing prop to 1
Change typing prop to -1 during the typing animation
Set typing prop to 1 again after animation

Expected behavior
It should (1.) start typing, (2.) erase the currently typed, and (3.) start typing again
Actual behavior
The plugin sets the visibleChars value in state to a value 1 of from what is should be.
E.g., on erase, visibleChars should be -1, but if you change typing during the transition, it is set to -2. After that wrong value, it toggles between -2 and -1 instead of -1 and the length of the sentence.

I made a pull request for this issue.
https://github.com/ianbjorndilling/react-typewriter/pull/34


grafana-toolkit is No longer supported. change to Use grafana create-plugin

This repo still uses grafana-toolkit for plugin development and build. Need some changes in this repo

thank you for the issue @ankita-sharma-1
would you mind contributing the change ?
Thx!


Workaround problem with fusion in CUDA 9

Description
Fixes #17020
The problem comes from the bug in how NVRTC in CUDA 9 handles the default-device flag. That flag is supposed to mark all the functions in the file as __device__ functions, but it should leave the functions decorated differently (like kernels decorated with __global__) alone. This is the behavior in CUDA 10+. In CUDA 9, however, this __device__ attribute is applied to every function (including kernels), which is incompatible with __launch_bounds__() attribute that we use for kernels.
This PR removes the usage of default-device flag for NVRTC compilation and instead manually decorates all the required functions as __device__

Awesome stuff! Thank you @ptrendx and @DickJC123 - this puts CD back on track ^^


Run build_android.sh in Jenkins

Yeah... perhaps they run some super old version of bash...? I'll investigate.

Output on Jenkins (for android build):
00:01:10.495 Bash: GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
00:01:10.495 Caffe2 path: /var/lib/jenkins/workspace
00:01:10.495 Using Android NDK at /opt/ndk

Output on Travis:
Bash: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Caffe2 path: /home/travis/build/caffe2/caffe2
Using Android NDK at /opt/android_ndk

Missed a critical detail: Travis runs sh ./.travis/build.sh so it likely uses a minimal non-Bash shell.

We don't run tests for the Android build, which is why it was failing. I updated the configuration to allow a test build to finish without test result files.
@caffe2bot retest this please

@Yangqing This is now good to go.

Rebased to fix merge conflict

Unrelated Travis failure (see #1504).


[digdag-ui] Task RESUME button does not work properly

RESUME button does not work properly since digdag version : 0.10.*
(command: digdag enable works fine.)

Hello, @shoot16625 It seems that the issue is duplicate #1648. Could you check the error message? If the same output, it will fix in 0.10.4.

Thank you for your contact!!


chore(deps): update dependency org.jasig.portal:uportal-spring to v5.6.0

This PR contains the following updates:

Package
Update
Change
References

org.jasig.portal:uPortal-spring
minor
5.5.0 -> 5.6.0
homepage, source

Release Notes

Jasig/uPortal
v5.6.0
Compare Source
This new minor lease of uPortal includes some new capabilities.
Important Update Note!
The following sub-modules were removed from uPortal 5.6:

uPortal-api-platform
uPortal-api-platform-impl

These modules were not in use and won't be missed, but one of them (uPortal-api-platform) received some special handling in uPortal-start.  Consequently, there are required changes to uPortal-start that must be made before uPortal 5.6 will work with uPortal-start.
The recommended way to get these required changes is to update your uPortal-start with changes from Apereo using Git.  Use Git to bring in the changes necessary to run uPortal 5.6 in uPortal-start.
List of Changes
Features

Remove the uPortal-platform-api and uPortal-platform-api-impl modules, since they are unused and unnecessary see note above (#1673)
Allow admins to specify custom text for a portlet to display when it is in MAINTENANCE lifecycle state (#1677)

Fixes

Address several findbugs/compiler warnings that appear in the console during builds (#1675)
Moved portlet options outside the portlet title (#1699)
Add 'Authorization' to the default value(s) for cors.allowed.headers because of our recent changes to support two-legged OAuth (#1697)

Documentation Changes

Update links to previous versions of the uPortal manual (#1672)

Chores

Update numerous dependencies (#1674, #1676, #1678, #1679, #1680, #1682, #1683, #1684, #1685, #1686, #1687, #1688, #1689, #1690, #1692, #1693, #1694, #1695, #1696, #1698, #1700, #1701, #1702, #1703, #1704)

v5.5.1
Compare Source
This is a patch release on the uPortal 5.5.x line. It provides dependent library updates and a fix for the search results page.
Fixes

Prevent an uncommon but difficult to troubleshoot error when the lifecycle state of a portlet is null (#1648)
Allow the searchRest.jsp to use the type parameter that was recently added to the SearchRESTController (#1671)

Chores

Dependency updates (#1606, #1611, #1615, #1616, #1617, #1618, #1620, #1621, #1630, #1631, #1635, #1637, #1638, #1639, #1640, #1641, #1642, #1643, #1644, #1645, #1646, #1647, #1649, #1650, #1651, #1658, #1661, #1662, #1663, #1664, #1665, #1666, #1667, #1670)

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR is stale, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

Available now for Enterprise: Renovate Pro with real-time webhook handling and priority job queue.

PR has been edited
:construction_worker: This PR has received other commits, so Renovate will stop updating it to avoid conflicts or other problems. If you wish to abandon your changes and have Renovate start over you may click the "rebase" checkbox in the PR body/description.


Integrating third-party LLMs for Evaluating Chinese-native RAGs

Hi there,
Thank you for bringing the elegant RAG Assessment framework to the community.
I am an AI engineer from Alibaba Cloud, and our team has been fine-tuning LLM-as-a-Judge models based on the Qwen foundation LLMs. Through extensive optimizations, our latest model has achieved GPT-4 level alignment with human preferences (indeed, it's performing approximately 5% better on our benchmarks) and it is particularly optimized for Chinese language support.
We are very interested in integrating our model as an evaluation LLM within RAGAS. Additionally, we would be happy to support the use of LLM hosted on Alibaba Cloud's LLM serving platform, EAS, as extension to the current support of AWA, Azure, and Google Vertex AI.
Please let me know if these contributions could be included in RAGAS.
I look forward to your response.
Best regards,
Renjun

@hurenjun would love to explore this further too? what would be the best way forward you have in mind?
would the models be open-sourced by the way? I think it would be really helpful for the chinese userbase because we had a few model that were not supported/working as expected.

Hi @jjmachan, we could offer two methods, following the existing practices of ragas, for integrating our models:

We have supported users in accessing our judge models via an API key. We can integrate this approach into RAGAS to facilitate quick access for users, similar to the current OpenAI/Together model.

We will enable users to deploy our latest judge models on their own resources within Alibaba Cloud. We can assist in implementing support for Alibaba Cloud's EAS as an addition to the current integrated LLM services from Azure, AWS, and Vertex.

In addition, we will continue to iterate on our models and will open-source them as part of our contribution to the community. Currently, we have a paper under double-blind review. I will figure out the best way to do this without violating the anonymity requirement.

@jjmachan Hi, is there any feedback on the above proposal?

@hurenjun I think you can check https://docs.ragas.io/en/stable/howtos/customisations/bring-your-own-llm-or-embs.html
Also, aliyun API compatible with Openai. you could replace base_url.

@landhu Thank you for your comment.
That should work. And I am considering that ragas could maintain some third-party LLMs for evaluation and other purposes, like those on huggingface, in addition to the OpenAI models.

hey @hurenjun sorry about the delay but we are working on #1237 which will have tabs for popular LLM providers in the getting started page. This should make it easier to use.
In the mean time we can maybe write a specific notebook in the how to guides as well if that would help users too - what do you think?

@jjmachan That's gonna be very helpful, especially for developers in regions without directyt access to openai models.
Looking forward to the new feature.

will keep you posted 🙂


🐛 Bug Report: relations consumesApi and providesApi not showing at same time

📜 Description
I don't even know if I am doing the correct way to achieve what I want, but for now, I'm trying this way. For context, we have a system with a lot of micro services and we decided to implement Backstage. On this right moment, I'm learning how to insert and create the relation between Components and APIs. And at first moment, I am facing this problem.
I'm trying to show simples relations between components and APIs. I have a component that provides an API and consumes an API at the same time. I have a simple YAML file like this:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: address-management
spec:
  type: service
  lifecycle: experimental
  owner: boss-team
  system: boss
  consumesApi: [ProfileManagement]
  providesApis: [AddressManagement]

The other entities are defined as well. But for some reason, when I have the relation consumesApi and providesApis at the same time, the diagram generated by Backstage doesn't show this relations, showing only  the providesApis.
PS: if I'm doing something wrong or misunderstood the concepts of Backstage, PLEASE help me and teach me. I would appreciate so much any help.
👍 Expected behavior
It should show the component on the diagram with the two relations (providesApi and consumesApi) at the same time. Like in the below image (edited to illustrate).

👎 Actual Behavior with Screenshots
Show only the relation providesApi like on the below image.

👟 Reproduction steps
1 - Finish the Getting Started guide installation;
2 - Go to examples/entities.yaml and register a component that consumes and provide API at the same time;
3 - Access the component and observe the diagram.
📃 Provide the context for the Bug.
I tried a lot of things found on the docs and on the web, but nothing has fixed the problem.

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

I'm so sorry for bother you with this, guys. After so much time spent on it, finally I could figure out what I was missing. And this is so sad...
I'm declaring like this:
consumesApi: ['api:AddressManagement']
And the correct way is:
consumesApis: ['api:AddressManagement']
The s solved my problem. I so sorry guys.
Keep up with the absolute great word.


catch divide by zero in ratio computation

Hello,
Thanks for writing this libary, its great. However i run into an issue when solving simple constrained least squares problems. Depending on the samples in a batch it can happen that rho is updated even tho tol_dual_rel_norm is 0 for one of the samples. This leads to nan values because we divide by 0. I fixed this by simply checking for nans before updating rho.
If there is a smarter way to prevent this please let me know

Thanks for your interest in our library and for catching this bug! Your solution seems to work; however, it's important to note that "ratio" is a vector (one element for each QP in the batch). So ensuring that all ratios must be finite would potentially inhibit some valid ratios from updating if even just one ratio value is Nan or Inf. I have a fix that clamps values (so that we never have a diving by zero issue). I also think it would be advantageous to only update rho if the primal and dual error is larger than some threshold (say 1e-5). In my experience; updating rho when both primal/dual errors are relatively small can lead to slower convergence.
Would you be able to provide a reproducible example so that I can ensure the fix addresses the edge cases that you are finding? Thanks again!

Hey thanks for taking the time and looking at it :). Here is a toy example of a 1d constrained least squares problem Ax=b where x is bound to [-1, 1].
import torch

from lqp_py.solve_box_qp_admm_torch import torch_solve_box_qp
from lqp_py.control import box_qp_control

lin_system_A = torch.tensor([[[1.0730e-04]], [[1.1975e-01]]])
lin_system_b = torch.tensor([[[-0.0905]], [[-0.0615]]])

n_batch = lin_system_A.shape[0]
n = lin_system_A.shape[1]
m = lin_system_A.shape[2]

Q = torch.block_diag(torch.zeros((n, n), dtype=torch.double), torch.eye(m, dtype=torch.double)).unsqueeze(0).repeat(n_batch, 1, 1)
p = torch.zeros((n_batch, n + m, 1), dtype=torch.double)
A = torch.cat([lin_system_A, -torch.eye(n, dtype=torch.double).unsqueeze(0).repeat(n_batch, 1, 1)], dim=2)
b = lin_system_b

lb = torch.cat([-torch.ones(n_batch, n, 1, dtype=torch.double), -torch.ones(n_batch, m, 1, dtype=torch.double) * torch.inf], dim=1)
ub = torch.cat([torch.ones(n_batch, n, 1, dtype=torch.double), torch.ones(n_batch, m, 1, dtype=torch.double) * torch.inf], dim=1)

control = box_qp_control(max_iters=1000, eps_rel=1e-6, eps_abs=1e-6, verbose=False)
sol = torch_solve_box_qp(Q=Q,
                         p=p,
                         A=A,
                         b=b,
                         lb=lb,
                         ub=ub,
                         control=control)

alpha = sol["z"][:, :n].squeeze(2)

print(alpha)

Thank you for the reproducible example! I've added some clamping and adaptive rho thresholding to avoid divide by zero and other non-finite rho issues. The commit changes are found here. You can pull down from main to incorporate the changes. Thanks again and please follow-up if you continue to encounter issues.


Kanban Board Setup

Github Project
There are 2 members in our team

Assignments:
Team member 1 --> @hunter4466
Team member 2 --> @smunozmo

Hi Team,
Good job so far! However,
There are some issues that you still need to work on to go to the next project but you are almost there!
Required Changes ♻

[ ] Please add user's avatar on each card check what I mean

Cheers and Happy coding!👏👏👏
Feel free to leave a question, or a comment on the PR thread if something is not clear 100%.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

STATUS: APPROVED :100:
Thank you for implementing all the project requirements, you've done a great job :trophy: There is nothing else to say other than... it's time to merge it :champagne:  :tada: Congratulations
Cheers and Happy coding! :clap:  :computer:  :wine_glass:
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Optional suggestions
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.
You can also consider:

N/A
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

_As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


dev-cmd: add request-bottle command

[ ] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Companion command for new workflow at homebrew-core, introduced in: https://github.com/Homebrew/homebrew-core/pull/57558
Name of this command should be changed, cause there is one in homebrew-linux-dev, named the same. I just didn't think of a better one yet.

I'm wondering if https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/ could replace (or at least "act consistently to") this?


Support for Vite 5

I am currently using --force when running npm install.  The script seems to function despite the old peer dependency.  I have not tried the output file within an ESP environment.

@jsaddiction  You can use the changes in this PR : Deps changes


New webserver not running - manual intervention needed?

It seems like uWSGI still isn't being exposed by Nginx, despite the #515 hotfix, and somehow the old server.py is running on port 80 even though startup.d/70-webserver.sh should be killing it. In addition, neither Nginx nor uWSGI seem to be logging to logs/ as should have happened in as of #515 and #488 respectively.
Is it possible to check whether:

etc/nginx/chaos_uwsgi has been linked to /etc/nginx/sites-enabled,
Nginx has been reloaded and isn't erroring,
The Nginx logs have been linked to logs/,
uWSGI is actually running (seems to be, according to stderr), and
chaos_server has been killed correctly?

(Not sure who to ping - is @amoffat the host?)

linked etc/nginx/chaos_uwsgi to /etc/nginx/sites-enabled
linked the nginx log files to log/
killed the chaos_server and brought it back up
reloaded nginx

I'm not sure how to test the new webserver, can anyone check that the expected behavior is now happening?
Side note, I'll try to work on our full docker deployments today, this way we can manage the server's dependencies from the Dockerfile and have fewer problems like these

/vote close Seems to be working - the status code page rendering endpoint should show the code given with the ?status parameter.

What ever someone just did, its back. Like this very instant it come up

@Moulick it keeps going down then coming back up.


Log a message indicating all modules excluding standalone ones are ready

Signed-off-by: Kai-Uwe Hermann<EMAIL_ADDRESS>

Looks good. In case multiple standalone modules are loaded, the message will be repeated right?

Yes, but I'm thinking of changing this to be able to log more detailed output when a standalone module registers itself with the manager


yt-dlp does not show the webm-dash formats on the last version (2024.08.01)

Last version (2024.08.01) yt-dlp -F doesn't show webm-dash formats (278,242,243, etc). Although formats exist
And you can't download this formats
Previous version works fine (2024.07.25)

wrong issue tracker
https://github.com/yt-dlp/yt-dlp/issues


right-click events

Hello,
Do you consider adding the events:
rightClick
rightClickStage
rightClickNode
rightClickNodes
?
It's useful to display a popup or a context menu without impacting the browsing activity in the graph.

Wondering if anyone has been able to get righClick events working on Chrome?  They are working fine for me in Firefox but not at all in Chrome.  I suspect it may be the Chrome contextMenu but have disabled that and still no luck.

It's very hacky and I would much prefer to use the sigma events but this seems to be working for the moment.
    if (document.addEventListener) {
        document.addEventListener('contextmenu', function(e) {
          //my custom functionality on right click
            e.preventDefault();
        }, false);
    } else {
        document.attachEvent('oncontextmenu', function() {
            //my custom functionality on right click
            window.event.returnValue = false;
        });
    };

@apitts no issue with it, see how I've done in sigma.plugins.tooltips

@sheymann Thanks for that!  Good to know it's just my issue as it narrows it down a lot. I see how you have removed the contextmenu in the tooltips plugin.  The only thing I can think of at the moment is it might be something specific to Chrome on Ubuntu that's giving me the issue...I'll try testing it on Windows once I have access to a Windows machine.  Definitely doesn't look like a sigma issue though.


Ship Swift Atomics 1.1

Candidate commit: 2a2be812fa7412cc567e7577c02e13e4ab9020ec
Diff: https://github.com/apple/swift-atomics/compare/1.0.3...main

[x] Review CMake configuration for missed source files
[x] Review diffs for stray changes
[x] Update copyright year in file headers (https://github.com/apple/swift-atomics/pull/80)
[ ] Update README
[ ] Draft release notes
[ ] Announce new release on the forum

Testing progress:
macOS/AS

[ ] macOS 13.3, Apple Silicon, Xcode 14.3, Swift 5.9 (swift.org developer snapshot as of 2023-03-30)
[ ] macOS 13.3, Apple Silicon, Xcode 14.3, Swift 5.8
[x] macOS 13.3, Apple Silicon, Xcode 14.2, Swift 5.7.2
[x] macOS 13.3, Apple Silicon, Xcode 13.4.1, Swift 5.6.1

macOS/x86_64

[ ] macOS 12.5, x86_64, Xcode 14.3, Swift 5.9 (swift.org developer snapshot as of 2023-03-30)
[ ] macOS 13.3, x86_64, Xcode 14.3, Swift 5.8
[ ] macOS 13.3, x86_64, Xcode 14.2, Swift 5.7.2
[ ] macOS 12.5, x86_64, Xcode 13.4.1, Swift 5.6.1

Linux/Aarch64

[x] Ubuntu 20.04, Aarch64, Swift main nightly build as of 2023-03-30
[x] Ubuntu 20.04, Aarch64, Swift 5.9 nightly build as of 2023-03-30
[x] Ubuntu 20.04, Aarch64, Swift 5.8 release
[x] Ubuntu 20.04, Aarch64, Swift 5.7.3 release
[x] Ubuntu 20.04, Aarch64, Swift 5.6.3 release

Linux/x86_64

[ ] Ubuntu 20.04, x86_64, Swift 5.9 nightly build as of 2023-03-30
[ ] Ubuntu 20.04, x86_64, Swift 5.8 release
[ ] Ubuntu 20.04, x86_64, Swift 5.7.3 release
[ ] Ubuntu 20.04, x86_64, Swift 5.6.3 release

Windows 11/x86_64 (unsupported due to #56)

[ ] ~Windows 11, x86_64, Swift main nightly build as of 2023-03-28~
[ ] ~Windows 11, x86_64, Swift 5.8 release~
[ ] ~Windows 11, x86_64, Swift 5.7.3 release~
[ ] ~Windows 11, x86_64, Swift 5.6.3 release~

Note: ~Swift 5.8 has not shipped yet; I'll hold testing that for now.~

Building using xcodebuild with library evolution enabled currently breaks due to #54, under Swift 5.7.1 (and 5.8). We will have to live with this for now.
[22 xcodebuild.library-evolution] xcodebuild -scheme swift-atomics -destination generic/platform=macOS -destination generic/platform=iOS BUILD_LIBRARY_FOR_DISTRIBUTION=YES

/Users/lorentey/Library/Developer/Xcode/DerivedData/swift-atomics-ceuvqitsfiwgtwejiuxxrfrjfari/Build/Intermediates.noindex/swift-atomics.build/Debug-iphoneos/AtomicsTests.build/Objects-normal/arm64/AtomicsTests.private.swiftinterface:4:8: error: missing required module '_AtomicsShims'
import Atomics
       ^
/Users/lorentey/Library/Developer/Xcode/DerivedData/swift-atomics-ceuvqitsfiwgtwejiuxxrfrjfari/Build/Intermediates.noindex/swift-atomics.build/Debug-iphoneos/AtomicsTests.build/Objects-normal/arm64/AtomicsTests.private.swiftinterface:1:1: error: failed to verify module interface of 'AtomicsTests' due to the errors above; the textual interface may be broken by project issues or a compiler bug
// swift-interface-format-version: 1.0
^

TSan tests are failing on Ubuntu with signal 9. I'm ignoring this.

xcodebuild.test.macCatalyst is failing with 5.6.1 under macOS due to an Xcode issue with test bundles and code signing on Mac Catalyst. Ignoring.

Evidently Swift Atomics has been quietly failing on Windows since forever.
(https://github.com/apple/swift-atomics/issues/56, https://github.com/apple/swift/issues/60534, https://github.com/apple/swift-installer-scripts/pull/144)
My own Windows testing is blocked on elementary problems with Swift packages on my Windows box that I don't really have time or energy to investigate.
<unknown>:0: error: missing required module 'SwiftShims'

Ah, reinstalling VS2019 & Swift 5.9 restored SwiftPM to working order. Windows platform support continues to be blocked on https://github.com/apple/swift-atomics/issues/56. Ignoring.

Ah, reinstalling VS2019 & Swift 5.9 restored SwiftPM to working order. Windows platform support continues to be blocked on #56. Ignoring.

Windows support for Swift Atomics 1.0.x did work with VS 2022, but I’m not sure if 1.1 breaks it again.
We’ll try to solve the problem in main, and then back port it to 5.8/5.9. The workaround continues to make sense.

I got further!

Carefully read the Getting Started instructions at https://www.swift.org/getting-started/#on-windows. Then sigh and forget them.

Install VS 2022 with the following incantation:
curl -sOL https://aka.ms/vs/17/release/vs_community.exe
start /w vs_community.exe --passive --wait --norestart --nocache --installPath "%ProgramFiles(x86)%\Microsoft Visual Studio\2022\Community" --add Microsoft.VisualStudio.Component.Windows10SDK.19041 --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64
del /q vs_community.exe

Download and install swift 5.8 from swift.org.

Add a random symlink:
cd \Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\lib\swift
mklink /D clang ..\clang\15.0.0

swift build in a local clone of swift-atomics will now progress to:
C:\Users\Karoy Lorentey\Documents\swift-atomics>swift --version
compnerd.org Swift version 5.8 (swift-5.8-RELEASE)
Target: x86_64-unknown-windows-msvc

C:\Users\Karoy Lorentey\Documents\swift-atomics>swift build
Building for debugging...
error: emit-module command failed due to exception 3 (use -v to see invocation)
error: failed parsing the Swift compiler output: unexpected JSON message: : dataCorrupted(Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "kind", intValue: nil)], debugDescription: "invalid kind", underlyingError: nil))

C:\Users\Karoy Lorentey\Documents\swift-atomics>swift build
Building for debugging...
error: emit-module command failed due to exception 3 (use -v to see invocation)
error: failed parsing the Swift compiler output: unexpected JSON message: : dataCorrupted(Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "kind", intValue: nil)], debugDescription: "invalid kind", underlyingError: nil))

Interesting… What about swift build -v? I’d like to inspect the failing command line.

Here goes!
C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swift-frontend.exe -frontend -emit-module -experimental-skip-non-inlinable-function-bodies-without-types C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\AtomicInteger.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\AtomicMemoryOrderings.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\AtomicOptional.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\AtomicRawRepresentable.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\AtomicStrongReference.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\AtomicValue.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\DoubleWord.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\autogenerated\AtomicBool.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\autogenerated\AtomicLazyReference.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\autogenerated\HighLevelTypes.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\autogenerated\IntegerConformances.swift C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\Atomics\autogenerated\PointerConformances.swift -target x86_64-unknown-windows-msvc -disable-objc-interop -sdk C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk -I C:\Users\Karoy Lorentey\Documents\swift-atomics\.build\x86_64-unknown-windows-msvc\debug -I C:\Library\Developer\Platforms\Windows.platform\Developer\Library\XCTest-development\usr\lib\swift\windows -I C:\Library\Developer\Platforms\Windows.platform\Developer\Library\XCTest-development\usr\lib\swift\windows\x86_64 -color-diagnostics -enable-testing -g -module-cache-path C:\Users\Karoy Lorentey\Documents\swift-atomics\.build\x86_64-unknown-windows-msvc\debug\ModuleCache -swift-version 5 -Onone -D SWIFT_PACKAGE -D DEBUG -empty-abi-descriptor -resource-dir C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\lib\swift -enable-anonymous-context-mangled-names -Xcc -fmodule-map-file=C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\_AtomicsShims\include\module.modulemap -Xcc -I -Xcc C:\Users\Karoy Lorentey\Documents\swift-atomics\Sources\_AtomicsShims\include -module-name Atomics -emit-module-doc-path C:\Users\Karoy Lorentey\Documents\swift-atomics\.build\x86_64-unknown-windows-msvc\debug\Atomics.swiftdoc -emit-module-source-info-path C:\Users\Karoy Lorentey\Documents\swift-atomics\.build\x86_64-unknown-windows-msvc\debug\Atomics.swiftsourceinfo -emit-dependencies-path C:\Users\Karoy Lorentey\Documents\swift-atomics\.build\x86_64-unknown-windows-msvc\debug\Atomics.build\Atomics.emit-module.d -parse-as-library -o C:\Users\Karoy Lorentey\Documents\swift-atomics\.build\x86_64-unknown-windows-msvc\debug\Atomics.swiftmodule
error: compile command failed due to exception 3 (use -v to see invocation)
error: failed parsing the Swift compiler output: unexpected JSON message: : dataCorrupted(Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "kind", intValue: nil)], debugDescription: "invalid kind", underlyingError: nil))

I cannot reproduce it with Swift 5.7.3🤔 With VS 17.5.3 and Swift 5.7.3, you don’t even need the mklink workaround to build Atomics.
I suspect this could be some Swift 5.8 regression.

Huh. I also see it with 5.7.3; so presumably something is messed up on my end.
Can I delegate the testing to you? 🙈 Do these pass for you on 5.7.3?
swift test -c debug
swift test -c release

The need for custom installation steps will preclude Windows from being a supported platform, but it would be good to know if the underlying code will eventually work!

Hm, xcodebuild.build.watchOS-simulator is failing on Xcode 14.3 (Swift 5.8). Apparently the generic/platform=watchOS Simulator destination still includes i386 code, but predictably Xcode doesn't ship with an XCTest overlay for it.
xcrun xcodebuild -scheme swift-atomics -configuration Release -destination generic/platform=watchOS Simulator -derivedDataPath /tmp/run-full-tests.sh.s6EQf/xcodebuild build

...
Ld /tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/swift-atomics.build/Release-watchsimulator/AtomicsTests.build/Objects-normal/i386/Binary/AtomicsTests normal i386 (in target 'AtomicsTests' from project 'swift-atomics')
    cd /Users/lorentey/Git/swift-atomics
    /Applications/Xcode-MAS.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Xlinker -reproducible -target i386-apple-watchos4.0-simulator -bundle -isysroot /Applications/Xcode-MAS.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator9.4.sdk -L/tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/EagerLinkingTBDs/Release-watchsimulator -L/tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Products/Release-watchsimulator -L/Applications/Xcode-MAS.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/usr/lib -F/tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/EagerLinkingTBDs/Release-watchsimulator -F/tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Products/Release-watchsimulator/PackageFrameworks -F/tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Products/Release-watchsimulator/PackageFrameworks -F/tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Products/Release-watchsimulator -iframework /Applications/Xcode-MAS.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/Library/Frameworks -iframework /Applications/Xcode-MAS.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator9.4.sdk/Developer/Library/Frameworks -filelist /tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/swift-atomics.build/Release-watchsimulator/AtomicsTests.build/Objects-normal/i386/AtomicsTests.LinkFileList -Xlinker -rpath -Xlinker /usr/lib/swift -Xlinker -rpath -Xlinker @loader_path/Frameworks -Xlinker -rpath -Xlinker @loader_path/../Frameworks -Xlinker -rpath -Xlinker @loader_path/Frameworks -dead_strip -Xlinker -object_path_lto -Xlinker /tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/swift-atomics.build/Release-watchsimulator/AtomicsTests.build/Objects-normal/i386/AtomicsTests_lto.o -Xlinker -objc_abi_version -Xlinker 2 -fobjc-link-runtime -L/Applications/Xcode-MAS.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/watchsimulator -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/swift-atomics.build/Release-watchsimulator/AtomicsTests.build/Objects-normal/i386/AtomicsTests.swiftmodule -framework XCTest -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/swift-atomics.build/Release-watchsimulator/AtomicsTests.build/Objects-normal/i386/AtomicsTests_dependency_info.dat -o /tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/swift-atomics.build/Release-watchsimulator/AtomicsTests.build/Objects-normal/i386/Binary/AtomicsTests -Xlinker -add_ast_path -Xlinker /tmp/run-full-tests.sh.s6EQf/xcodebuild/Build/Intermediates.noindex/swift-atomics.build/Release-watchsimulator/Atomics.build/Objects-normal/i386/Atomics.swiftmodule
ld: warning: ignoring file /Applications/Xcode-MAS.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/Library/Frameworks/XCTest.framework/XCTest, file is universal (x86_64,arm64) but does not contain the i386 architecture: /Applications/Xcode-MAS.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/Library/Frameworks/XCTest.framework/XCTest
ld: warning: Could not find or use auto-linked library 'XCTestSwiftSupport'
Undefined symbols for architecture i386:
[...]

This is an Xcode issue (or perhaps a problem in the test script). Ignoring.

The need for custom installation steps will preclude Windows from being a supported platform, but it would be good to know if the underlying code will eventually work!

AFAIK VS 2022 (17.5+) actually eliminates the need for it. A fix through the installer is still desired anyway. We may need to clarify that at the moment we need VS 17.5+ on Windows.

[x] swift test -c debug (passed)
[ ] swift test -c release (in progress)

That is excellent news! I'll include some text announcing experimental Windows support in the release notes. (I really hope we'll soon be able to migrate this package to native atomic intrinsics, too -- that should eliminate all of the C-related headaches.)

I think I'll do most Intel testing on macOS via Rosetta, with limited testing on an actual Intel CPU on Monday.

Oops:
Test Suite 'BasicAtomicDoubleWordTests' started at 2023-04-01 03:36:23.462
Test Case 'BasicAtomicDoubleWordTests.test_compareExchange_acquiring' started at 2023-04-01 03:36:23.462
Assertion failed: atomic_is_lock_free(&storage.value), file C:\Users\Administrator\Developer\swift-atomics\Sources\_AtomicsShims\include/_AtomicsShims.h, line 227

Oh, that's unfortunate. Windows definitely requires CMPXCHG16B these days, so this must be due to the C stdlib not getting updated. Native atomics should solve that, eventually.

xcodebuild.test.tvOS-simulator failed on Xcode 13.4.1 (Swift 5.6.1) under Rosetta -- it wasn't able to find a suitable simulator device. I'm going to ignore this as unrelated noise.

xcodebuild doesn't like building projects with swift.org toolchains, so I'll limit 5.9/main testing to SwiftPM and CMake.
2023-04-01 00:52:13.552 xcodebuild[49178:697838] Writing error result bundle to /var/folders/hb/5vvxj2m13_7_h40q22pt9s9w0000gn/T/ResultBundle_2023-01-04_00-52-0013.xcresult
xcodebuild: error: Could not resolve package dependencies:
  Invalid manifest (compiled with: ["/Library/Developer/Toolchains/swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-30-a.xctoolchain/usr/bin/swiftc", "-vfsoverlay", "/var/folders/hb/5vvxj2m13_7_h40q22pt9s9w0000gn/T/TemporaryDirectory.anJQwJ/vfs.yaml", "-L", "/Applications/Xcode-MAS.app/Contents/PlugIns/IDESwiftPackageCore.framework/Versions/A/Frameworks/SwiftPM.framework/SharedSupport/ManifestAPI", "-lPackageDescription", "-Xlinker", "-rpath", "-Xlinker", "/Applications/Xcode-MAS.app/Contents/PlugIns/IDESwiftPackageCore.framework/Versions/A/Frameworks/SwiftPM.framework/SharedSupport/ManifestAPI", "-target", "x86_64-apple-macos12.0", "-sdk", "/Applications/Xcode-MAS.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk", "-swift-version", "5", "-I", "/Applications/Xcode-MAS.app/Contents/PlugIns/IDESwiftPackageCore.framework/Versions/A/Frameworks/SwiftPM.framework/SharedSupport/ManifestAPI", "-sdk", "/Applications/Xcode-MAS.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk", "-package-description-version", "5.6.0", "-Xfrontend", "-serialize-diagnostics-path", "-Xfrontend", "/Users/lorentey/Library/Caches/org.swift.swiftpm/manifests/ManifestLoading/swift-atomics.dia", "/Users/lorentey/Git/swift-atomics/Package.swift", "-disallow-use-new-driver", "-o", "/var/folders/hb/5vvxj2m13_7_h40q22pt9s9w0000gn/T/TemporaryDirectory.YEdaUn/swift-atomics-manifest"])
<unknown>:0: warning: legacy driver is now deprecated; consider avoiding specifying '-disallow-use-new-driver'
<unknown>:0: error: unable to execute command: <unknown>

Ah, my TSan tests on Linux appear to be failing because they're running out of memory, and the process gets killed by the kernel. 💡Fair enough.

OK, testing complete; 1.1 is ready to get tagged.

Apparently the generic/platform=watchOS Simulator destination still tries to build i386 code, but predictably Xcode doesn't ship an XCTest overlay for it.
xcrun xcodebuild -scheme swift-atomics -configuration Release -destination generic/platform=watchOS Simulator -derivedDataPath /tmp/run-full-tests.sh.s6EQf/xcodebuild build

Just wanted to mention that I ran into this recently in Xcode 15 and a quick workaround that I found was to use the non-Simulator variant.
-destination "generic/platform=watchOS"

Also works in tandem with Any watchOS Device. (Note that using Any watchOS Simulator Device still fails.)
-destination "generic/platform=watchOS,name=Any watchOS Device"


Can't seem to get the correct column name when using time series format

Hey there,
I am a huge fan of your products and especially your Business Chart integration saved me countless times. Thanks so much! :)
However, I do have a small issue right now. My data comes from a TimescaleDB and I am using Version 6.0.0 of your plugin.
I have a query that basically looks like that:
`SELECT interval as time,
(last_value - LAG(last_value) OVER (PARTITION BY id ORDER BY interval)) AS value_difference,
meter_name
FROM
interval_data
ORDER BY
interval, meter_name;
and I have Grafana set to use Time Series as my data format. As you can see in Grafana the title of the column consists of 'value_difference' and then besides the meter_name. If I use Grafanas visualisation options this combination of values can be seen in the tooltip and also in the legend.

However, when I try to access the title in business charts by using .name on one of the fields I simply get back 'value_difference' for every field which makes it impossible to create a meaningful legend.

Do you know a way to somehow transform the data in Grafana or simply use the correct call in echarts?

@Bragor95 Thank you for your question.
Here is simple example like yours.

I use the visual editor

code example:
console.log('console >>> context',context)
return {
  dataset: context.editor.dataset,
  series: context.editor.series,
  legend: {
    data: ['Line', 'Line2']
  },
  grid: {
    bottom: "3%",
    containLabel: true,
    left: "3%",
    right: "4%",
    top: "4%"
  },
  xAxis: {
    type: "category"
  },
  yAxis: {
    type: 'value',
  },
}

To set legend in visual editor, please add legend property to chart settings. Note, that names in data should be the same in
context.editor.series for each series, another words the same with name in editor for series
I keep console.log('console >>> context',context) as an example, please you can use it with developer mode in the browser to check all parameters available in context for code editor
You can use
console.log('console >>> context', context.panel.data.series[0].fields)
To check fields with names from the data. It can help you to use appropriate field names

Please use it fields for legend->data, but it should be the same with appropriate series name property
apache
Let me know if you find it helpful

Thank you very much! This was very helpful :)


Allow variables in workspace config folders

I would like to do the following in .code-workspace files:
{
	"folders": [
		{
			"path": "some/project"
		},
		{
			"path": "another/project"
		},
		{
			"path": "${userHome}/.known/path"
		}
	],
	"settings": {}
}

/duplicate of #44755

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Changing lanes then changing back causes lane change assist to continue trying to change lanes in the previous direction.

Describe the bug
Signaling and using lane change assist to change lanes back and fourth in rapid succession, like when passing a parked car, causes lane change assist to continue trying to change lanes in the first direction signaled, and will fight you on the change back to the original lane.
For example: You're in the right lane and there is a parked car in front, you signal and change left to pass the parked car with lane change assist, then immediately signal right again before lane change assist completes. After lane change assist completes the left lane change, it will think you're signaling and trying to make another left lane change despite signaling right. OP will fight you during the entirety of the right lane change.
How to reproduce or log data
Signal and change lanes in one direction, then immediately signal in the opposite direction while the initial lane change is still completing. After the initial lane change completes, OP will think that you're trying to make a second lane change in the same direction, instead of back to your previous lane as you've signaled.
Expected behavior
For lane change assist to realize that the direction signaled has changed.
Device/Version information (please complete the following information):

Device: Comma2
Dongle ID: 903210ecc0cb706b
Route: 903210ecc0cb706b|2021-06-02--23-18-38--11
Timestamp: 23:30:00
Version: 0.8.4
Car make/model: VW Golf R Manual

Additional context
IIRC, if you turn your signal off, and then re-trigger it will "fix" the problem, however if you re-trigger your signal in a different direction from the first one while lane change assist is working, it will not realize the direction has changed.
Talking to @jyoung8607, he thinks  it may have regressed in #20765
Let me know if you have more questions. :)

You're right, that is a regression from that PR. I changed the logic to determine lane change direction in the preLaneChange state now. The first state was skipped when you make more than one lane change in succession.


Find the first repeating charatcter in the string using stream functions

Given a String, find the first repeated character in it using Stream functions?
Input :
String input = "Java Articles are Awesome";
Output = a
Hi @shreyamalogi , This was one of the interview question that was asked to me, I am raising the issue for it. Please assign this issue to me.

#197


1 hour for deploying StackStorm is too slow

Looks like the Action to deploy StackStorm is running for more than 1 hour (https://github.com/bitovi/operations-stackstorm/actions/runs/4049048877).
It normally takes 10-15mins to install StackStorm in the ansible-st2 tests running GH Actions -> Ansible -> Docker locally. See https://github.com/StackStorm/ansible-st2/actions/runs/4049822952
We have to figure out where's the bottleneck and fix it because this is unacceptably slow, but quick look it's Ansible provisioning that takes the biggest chunk of time.

Going to  spend a few minutes messing around with https://techadminblog.com/get-execution-time-of-each-task-ansible/ to see if I can get the length of the tasks out of Ansible

Alright, I just started a run that has timers on. Here is an example log from it;
Tuesday 31 January 2023  20:32:30 +0000 (0:00:00.144)       0:00:00.144 *******
ok: [<IP_ADDRESS>]
TASK [install : Install required system packages] ******************************
Tuesday 31 January 2023  20:32:53 +0000 (0:00:22.382)       0:00:22.527 ******* ```

I expect we should be able to gleam some insight into which tasks are the bottlenecks at the very least