Running fmriprep on M1 chip Mac Mini (using Docker Wrapper)

I was trying to use fmriprep on my M1 chip Mac Mini with Docker Wrapper. After I typed in the command in terminal, it started to test BIDS compatibility. It went well till saying 'Slic-timing correction will be included', then error messages pop up.
I wonder if it's a M1 chip issue or I did something wrong. I actually successfully did the same preprocessing using fmriprep on another Windows 10 Laptop.
Any help is appreciated.
Below is my command and the error messages:
(base) yuqianni@Yuqians-Mac-mini ~ % fmriprep-docker /Users/yuqianni/Desktop/affective_video_raw_data /Users/yuqianni/Desktop/affective_video_preprocessing participant --participant-label 02 --fs-license-file /Users/yuqianni/Freesurfer/freesurfer.txt --fd-spike-threshold 0.5 --dvars-spike-threshold 1.5
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Warning: <8GB of RAM is available within your Docker environment.
Some parts of fMRIPrep may fail to complete.
Continue anyway? [y/N]y
RUNNING: docker run --rm -e DOCKER_VERSION_8395080871=20.10.7 -it -v /Users/yuqianni/Freesurfer/freesurfer.txt:/opt/freesurfer/license.txt:ro -v /Users/yuqianni/Desktop/affective_video_raw_data:/data:ro -v /Users/yuqianni/Desktop/affective_video_preprocessing:/out nipreps/fmriprep:20.2.1 /data /out participant --participant-label 02 --fd-spike-threshold 0.5 --dvars-spike-threshold 1.5
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
<EMAIL_ADDRESS>

This dataset appears to be BIDS compatible.

        Summary:                Available Tasks:            Available Modalities:
        56 Files, 2.77GB        Functional localizer        T1w
        11 - Subjects           Passive Viewing             bold
        1 - Session

	If you have any questions, please post on https://neurostars.org/tags/bids.

210627-02:47:56,244 nipype.workflow IMPORTANT:

    Running fMRIPREP version 20.2.1:
      * BIDS dataset path: /data.
      * Participant list: ['02'].
      * Run identifier: 20210627-024727_75af46ec-dd70-4569-b17a-3f5aa343f084.
      * Output spaces: MNI152NLin2009cAsym:res-native.
      * Pre-run FreeSurfer's SUBJECTS_DIR: /out/freesurfer.
210627-02:47:58,315 nipype.workflow INFO:
	 No single-band-reference found for sub-02_task-functionallocalizer_run-01_bold.nii.gz.
210627-02:47:59,929 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
210627-02:48:00,252 nipype.workflow INFO:
	 No single-band-reference found for sub-02_task-view_run-01_bold.nii.gz.
210627-02:48:01,632 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
210627-02:48:01,953 nipype.workflow INFO:
	 No single-band-reference found for sub-02_task-view_run-02_bold.nii.gz.
210627-02:48:03,337 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
Process Process-2:
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/workflow.py", line 82, in build_workflow
    retval["workflow"] = init_fmriprep_wf()
  File "<string>", line 2, in __setitem__
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/managers.py", line 796, in _callmethod
    kind, result = conn.recv()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 250, in recv
    buf = self._recv_bytes()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 407, in _recv_bytes
    buf = self._recv(4)
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 383, in _recv
    raise EOFError
EOFError
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/managers.py", line 788, in _callmethod
    conn = self._tls.connection
AttributeError: 'ForkAwareLocal' object has no attribute 'connection'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/miniconda/bin/fmriprep", line 10, in <module>
    sys.exit(main())
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/run.py", line 45, in main
    fmriprep_wf = retval.get("workflow", None)
  File "<string>", line 2, in get
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/managers.py", line 792, in _callmethod
    self._connect()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/managers.py", line 779, in _connect
    conn = self._Client(self._token.address, authkey=self._authkey)
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 492, in Client
    c = SocketClient(address)
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 619, in SocketClient
    s.connect(address)
ConnectionRefusedError: [Errno 111] Connection refused
Sentry is attempting to send 0 pending error messages
Waiting up to 2 seconds
Press Ctrl-C to quit
fMRIPrep: Please report errors to https://github.com/nipreps/fmriprep/issues

I haven't seen anything like this before. It appears to be synchronization issue, but it's internal to the Python multiprocessing API, so I'm not sure how we would fix it.
Does this happen reliably?

Yes, I tried multiple times. and changed the subject labels, the issue still exists.

I'm going to (reluctantly) ping @oesteban. There's something nasty going on with process managers, but Googling and a little bit of digging into CPython is not buying me much clarity.

Perhaps overriding the use of forkserver?

I wonder if we even need to set the multiprocessing start method anymore, now that we can read/write to the config file.

I wonder if we even need to set the multiprocessing start method anymore, now that we can read/write to the config file.

Yes, we still need to do this.
The reason being that we want to start the forkserver as soon as possible in the runtime, when the memory fingerprint is minimal (typically ~850MB at that point on a Linux box). We want to use the forkserver because it starts as many workers as you request, and when the workers are cleansed (and replaced with a fresh one), they start with the same memory fingerprint of the original fork (remember, ~850MB for fMRIPrep when the forkserver is initiated).
On Mac this should not be necessary in principle. 1) I think mac uses spawn to start subprocesses, so there's no step where virtual memory blows up when forking; 2) even if it used fork, the problem comes from how CPython handles memory in Linux (it does not release memory from previously used imports, which is not the case in Windows and, probably -I'm not sure- in mac).
Long story short, forkserver is still necessary on Linux.

The problem is that they're using docker on Mac, so we can't dispense with forkserver. The underlying Python is still Linux.

Ugh - thought it was baremetal installation.

Sorry about confusion. I'm using the Docker Wrapper.

@JuYuqian, I think I have a fix in #2435. Would you give the following a try?
git clone https://github.com/nipreps/fmriprep.git
git -C fmriprep fetch origin pull/2435/head
git -C fmriprep checkout FETCH_HEAD

You should see something like:
Cloning into 'fmriprep'...
remote: Enumerating objects: 30475, done.
remote: Counting objects: 100% (242/242), done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 30475 (delta 143), reused 206 (delta 127), pack-reused 30233
Receiving objects: 100% (30475/30475), 40.23 MiB | 14.21 MiB/s, done.
Resolving deltas: 100% (22401/22401), done.
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 5 (delta 4), reused 5 (delta 4), pack-reused 0
Unpacking objects: 100% (5/5), 717 bytes | 717.00 KiB/s, done.
From https://github.com/nipreps/fmriprep
 * branch              refs/pull/2435/head -> FETCH_HEAD
Note: switching to 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 314dc39a FIX: Fall-back to initializing workflow in main process

Then you can patch this into the Docker container with fmriprep-docker as follows:
fmriprep-docker --patch fmriprep=fmriprep/fmriprep [...]

Where [...] is the rest of your usual command.

Thank you, @effigies ,
After 'cloning into 'fmriprep......'', I tried these two commands, but neither works. Maybe I typed the command in a wrong way?
fmriprep-docker --patch fmriprep=fmriprep/fmriprep /Users/yuqianni/Desktop/affective_video_raw_data /Users/yuqianni/Desktop/affective_video_preprocessing participant --participant-label 01 --fs-license-file /Users/yuqianni/Freesurfer/freesurfer.txt
fmriprep-docker --patch fmriprep=fmriprep/fmriprep fmriprep-docker /Users/yuqianni/Desktop/affective_video_raw_data /Users/yuqianni/Desktop/affective_video_preprocessing participant --participant-label 01 --fs-license-file /Users/yuqianni/Freesurfer/freesurfer.txt
Both command gave me this error:
Traceback (most recent call last):
  File "/Users/yuqianni/.local/bin/fmriprep-docker", line 8, in <module>
    sys.exit(main())
  File "/Users/yuqianni/.local/lib/python3.8/site-packages/fmriprep_docker.py", line 349, in main
    opts, unknown_args = parser.parse_known_args()
  File "/Users/yuqianni/opt/anaconda3/lib/python3.8/argparse.py", line 1800, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/Users/yuqianni/opt/anaconda3/lib/python3.8/argparse.py", line 2006, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/Users/yuqianni/opt/anaconda3/lib/python3.8/argparse.py", line 1946, in consume_optional
    take_action(action, args, option_string)
  File "/Users/yuqianni/opt/anaconda3/lib/python3.8/argparse.py", line 1874, in take_action
    action(self, namespace, argument_values, option_string)
  File "/Users/yuqianni/.local/lib/python3.8/site-packages/fmriprep_docker.py", line 236, in __call__
    k, v = kv.split("=")
ValueError: not enough values to unpack (expected 2, got 1)

Oh, you may need to put the patch flag at the end, not the beginning.

Thank you. It started successfully. I'll let it run over night to see if it can complete sucessfully.
Here is what I see so far:
(base) yuqianni@Yuqians-Mac-mini ~ % fmriprep-docker /Users/yuqianni/Desktop/affective_video_raw_data /Users/yuqianni/Desktop/affective_video_preprocessing participant --participant-label 01 --fs-license-file /Users/yuqianni/Freesurfer/freesurfer.txt --fd-spike-threshold 0.5 --dvars-spike-threshold 1.5 --patch fmriprep=fmriprep/fmriprep
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Warning: <8GB of RAM is available within your Docker environment.
Some parts of fMRIPrep may fail to complete.
Continue anyway? [y/N]y
RUNNING: docker run --rm -e DOCKER_VERSION_8395080871=20.10.7 -it -v /Users/yuqianni/fmriprep/fmriprep:/usr/local/miniconda/lib/python3.7/site-packages/fmriprep:ro -v /Users/yuqianni/Freesurfer/freesurfer.txt:/opt/freesurfer/license.txt:ro -v /Users/yuqianni/Desktop/affective_video_raw_data:/data:ro -v /Users/yuqianni/Desktop/affective_video_preprocessing:/out nipreps/fmriprep:20.2.1 /data /out participant --participant-label 01 --fd-spike-threshold 0.5 --dvars-spike-threshold 1.5
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
You are using fMRIPrep-0+unknown, and a newer version of fMRIPrep is available: 20.2.1.
Please check out our documentation about how and when to upgrade:
https://fmriprep.readthedocs.io/en/latest/faq.html#upgrading
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
<EMAIL_ADDRESS>
This dataset appears to be BIDS compatible.

        Summary:                Available Tasks:            Available Modalities:
        56 Files, 2.77GB        Functional localizer        T1w
        11 - Subjects           Passive Viewing             bold
        1 - Session

	If you have any questions, please post on https://neurostars.org/tags/bids.

/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
210702-04:34:32,1 nipype.workflow IMPORTANT:

    Running fMRIPREP version 0+unknown:
      * BIDS dataset path: /data.
      * Participant list: ['01'].
      * Run identifier: 20210702-043401_8ff1d701-e9a8-4ec1-9607-1a2fbe52c5cb.
      * Output spaces: MNI152NLin2009cAsym:res-native.
      * Pre-run FreeSurfer's SUBJECTS_DIR: /out/freesurfer.
210702-04:34:34,160 nipype.workflow INFO:
	 No single-band-reference found for sub-01_task-functionallocalizer_run-01_bold.nii.gz.
210702-04:34:35,900 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
210702-04:34:36,239 nipype.workflow INFO:
	 No single-band-reference found for sub-01_task-view_run-01_bold.nii.gz.
210702-04:34:37,702 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
210702-04:34:38,32 nipype.workflow INFO:
	 No single-band-reference found for sub-01_task-view_run-02_bold.nii.gz.
210702-04:34:39,497 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
Process Process-2:
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/workflow.py", line 82, in build_workflow
    retval["workflow"] = init_fmriprep_wf()
  File "<string>", line 2, in __setitem__
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/managers.py", line 796, in _callmethod
    kind, result = conn.recv()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 250, in recv
    buf = self._recv_bytes()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 407, in _recv_bytes
    buf = self._recv(4)
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/connection.py", line 383, in _recv
    raise EOFError
EOFError
210702-04:34:46,690 nipype.workflow WARNING:
	 Could not build workflow in separate process. Attempting to build in main process. This may impact memory footprint.
210702-04:34:51,883 nipype.workflow IMPORTANT:

    Running fMRIPREP version 0+unknown:
      * BIDS dataset path: /data.
      * Participant list: ['01'].
      * Run identifier: 20210702-043401_8ff1d701-e9a8-4ec1-9607-1a2fbe52c5cb.
      * Output spaces: MNI152NLin2009cAsym:res-native.
      * Pre-run FreeSurfer's SUBJECTS_DIR: /out/freesurfer.
210702-04:34:55,318 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
210702-04:34:56,782 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
210702-04:34:58,240 nipype.workflow IMPORTANT:
	 Slice-timing correction will be included.
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
Could not generate CITATION.html file:
pandoc -s --bibliography /usr/local/miniconda/lib/python3.7/site-packages/fmriprep/data/boilerplate.bib --filter pandoc-citeproc --metadata pagetitle="fMRIPrep citation boilerplate" /out/fmriprep/logs/CITATION.md -o /out/fmriprep/logs/CITATION.html
Could not generate CITATION.tex file:
pandoc -s --bibliography /usr/local/miniconda/lib/python3.7/site-packages/fmriprep/data/boilerplate.bib --natbib /out/fmriprep/logs/CITATION.md -o /out/fmriprep/logs/CITATION.tex
210702-04:35:20,218 nipype.workflow IMPORTANT:
	 fMRIPrep started!
210702-04:36:20,938 nipype.workflow WARNING:
	 Some nodes exceed the total amount of memory available (1.75GB).

It still doesn't work, unfortunately. After letting it running over night, this is what I got:
210702-04:35:20,218 nipype.workflow IMPORTANT:
	 fMRIPrep started!
210702-04:36:20,938 nipype.workflow WARNING:
	 Some nodes exceed the total amount of memory available (1.75GB).
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
/usr/local/miniconda/lib/python3.7/site-packages/bids/layout/validation.py:46: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
210702-04:36:33,318 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.func_preproc_task_functionallocalizer_run_01_wf.func_derivatives_wf.raw_sources" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_functionallocalizer_run_01_wf/func_derivatives_wf/raw_sources".
210702-04:36:33,322 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_01_wf.func_derivatives_wf.raw_sources" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_view_run_01_wf/func_derivatives_wf/raw_sources".
210702-04:36:33,333 nipype.workflow INFO:
	 [Node] Running "raw_sources" ("nipype.interfaces.utility.wrappers.Function")
210702-04:36:33,339 nipype.workflow INFO:
	 [Node] Running "raw_sources" ("nipype.interfaces.utility.wrappers.Function")
210702-04:36:33,356 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.func_preproc_task_functionallocalizer_run_01_wf.func_derivatives_wf.raw_sources".
210702-04:36:33,363 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_01_wf.func_derivatives_wf.raw_sources".
210702-04:36:35,920 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_02_wf.func_derivatives_wf.raw_sources" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_view_run_02_wf/func_derivatives_wf/raw_sources".
210702-04:36:35,929 nipype.workflow INFO:
	 [Node] Running "raw_sources" ("nipype.interfaces.utility.wrappers.Function")
210702-04:36:35,946 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_02_wf.func_derivatives_wf.raw_sources".
210702-04:36:36,836 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.lap_tmpl" in "/tmp/work/fmriprep_wf/single_subject_01_wf/anat_preproc_wf/brain_extraction_wf/lap_tmpl".
210702-04:36:36,845 nipype.workflow INFO:
	 [Node] Running "lap_tmpl" ("nipype.interfaces.ants.utils.ImageMath"), a CommandLine Interface with command:
ImageMath 3 tpl-OASIS30ANTs_res-01_T1w_maths.nii.gz Laplacian /home/fmriprep/.cache/templateflow/tpl-OASIS30ANTs/tpl-OASIS30ANTs_res-01_T1w.nii.gz 1.5 1
210702-04:36:38,691 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_01_wf.initial_boldref_wf.val_bold" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_view_run_01_wf/initial_boldref_wf/val_bold".
210702-04:36:38,697 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.func_preproc_task_functionallocalizer_run_01_wf.initial_boldref_wf.val_bold" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_functionallocalizer_run_01_wf/initial_boldref_wf/val_bold".
210702-04:36:38,731 nipype.workflow INFO:
	 [Node] Setting-up "_val_bold0" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_functionallocalizer_run_01_wf/initial_boldref_wf/val_bold/mapflow/_val_bold0".
210702-04:36:38,731 nipype.workflow INFO:
	 [Node] Setting-up "_val_bold0" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_view_run_01_wf/initial_boldref_wf/val_bold/mapflow/_val_bold0".
210702-04:36:38,741 nipype.workflow INFO:
	 [Node] Running "_val_bold0" ("niworkflows.interfaces.images.ValidateImage")
210702-04:36:38,746 nipype.workflow INFO:
	 [Node] Running "_val_bold0" ("niworkflows.interfaces.images.ValidateImage")
210702-04:36:39,83 nipype.workflow INFO:
	 [Node] Finished "_val_bold0".
210702-04:36:39,83 nipype.workflow INFO:
	 [Node] Finished "_val_bold0".
210702-04:36:39,90 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.func_preproc_task_functionallocalizer_run_01_wf.initial_boldref_wf.val_bold".
210702-04:36:39,95 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_01_wf.initial_boldref_wf.val_bold".
210702-04:36:40,521 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_02_wf.initial_boldref_wf.val_bold" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_view_run_02_wf/initial_boldref_wf/val_bold".
210702-04:36:40,532 nipype.workflow INFO:
	 [Node] Setting-up "_val_bold0" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_view_run_02_wf/initial_boldref_wf/val_bold/mapflow/_val_bold0".
210702-04:36:40,536 nipype.workflow INFO:
	 [Node] Running "_val_bold0" ("niworkflows.interfaces.images.ValidateImage")
210702-04:36:40,695 nipype.workflow INFO:
	 [Node] Finished "_val_bold0".
210702-04:36:40,703 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.func_preproc_task_view_run_02_wf.initial_boldref_wf.val_bold".
210702-04:36:40,890 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.func_preproc_task_functionallocalizer_run_01_wf.initial_boldref_wf.gen_ref" in "/tmp/work/fmriprep_wf/single_subject_01_wf/func_preproc_task_functionallocalizer_run_01_wf/initial_boldref_wf/gen_ref".
210702-04:36:40,904 nipype.workflow INFO:
	 [Node] Running "gen_ref" ("niworkflows.interfaces.registration.EstimateReferenceImage")
210702-04:36:41,498 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.full_wm" in "/tmp/work/fmriprep_wf/single_subject_01_wf/anat_preproc_wf/brain_extraction_wf/full_wm".
210702-04:36:41,516 nipype.workflow INFO:
	 [Node] Running "full_wm" ("nipype.interfaces.utility.wrappers.Function")
210702-04:36:43,752 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.full_wm".
210702-04:36:44,605 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.anat_preproc_wf.brain_extraction_wf.res_tmpl" in "/tmp/work/fmriprep_wf/single_subject_01_wf/anat_preproc_wf/brain_extraction_wf/res_tmpl".
210702-04:36:44,832 nipype.workflow INFO:
	 [Node] Running "res_tmpl" ("niworkflows.interfaces.images.RegridToZooms")
210702-04:36:49,515 nipype.workflow INFO:
	 [Node] Setting-up "fmriprep_wf.single_subject_01_wf.bidssrc" in "/tmp/work/fmriprep_wf/single_subject_01_wf/bidssrc".
exception calling callback for <Future at 0x4060038898 state=finished raised BrokenProcessPool>
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.
210702-04:36:49,643 nipype.workflow INFO:
	 [Node] Running "bidssrc" ("niworkflows.interfaces.bids.BIDSDataGrabber")
210702-04:36:49,648 nipype.interface INFO:
	 No "t2w" images found for sub-01
210702-04:36:49,649 nipype.interface INFO:
	 No "flair" images found for sub-01
210702-04:36:49,649 nipype.interface INFO:
	 No "fmap" images found for sub-01
210702-04:36:49,649 nipype.interface INFO:
	 No "sbref" images found for sub-01
210702-04:36:49,650 nipype.interface INFO:
	 No "roi" images found for sub-01
exception calling callback for <Future at 0x406129fa58 state=finished raised BrokenProcessPool>
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.
exception calling callback for <Future at 0x40612e9e48 state=finished raised BrokenProcessPool>
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.
210702-04:36:49,707 nipype.workflow INFO:
	 [Node] Finished "fmriprep_wf.single_subject_01_wf.bidssrc".
exception calling callback for <Future at 0x405ef0dfd0 state=finished raised BrokenProcessPool>
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 324, in _invoke_callbacks
    callback(self)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback
    result = args.result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 425, in result
    return self.__get_result()
  File "/usr/local/miniconda/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.

That error usually occurs when you don't have enough memory - can you try upping the amount of memory available to Docker? https://stackoverflow.com/a/44533437

And it looks like the bug fix works, so I'll go ahead and merge it.

I increased memory in Docker and fmriprep has been running for a while without error. Thank you so much for the help. I'll update again once it finishes.

Here is an update:
I allocated 6 CPUs and 12 GB memory to docker on my M1 chip Mac mini to process one subject's data (2 runs, each run has 365 volumes). I tried twice with --fs-no-reconall. The first time, it failed with a memory error. The second time, it has been running for more than 10 hours, but still hasn't finished yet, no error though. I ran the same preprocess with --fs-no-reconall on a Windows laptop with 4 cores and 8 GB memory, it took about 4 hours.
I also tried preprocess the same subject's data using the M1 Mac mini with reconall included. It hang with the following for more than 8 hours:
[Node] Finished "fmriprep_wf.single_subject_03_wf.anat_preproc_wf.surface_recon_wf.t1w2fsnative_xfm"
So after letting it running for about 20 hours in total, I stopped it. The same process can usually be finished with my 8GB memory Windows laptop within 20 hours.
So seems like running the Docker image on M1 chip Mac mini is much slower than running it on Windows PC, even the Mac Mini has more CPU and memory allocated to Docker. Maybe partially because the Docker image is linux/amd64 whereas the new Mac mini is arm? I saw a discussion talking about running amd64 images on M1 Mac may run into memory allocation problems:
https://github.com/docker/for-mac/issues/5204#issuecomment-826629491

Interesting. Thanks for the update, and that makes some sense. I can see a few ways forward, in order of easiest to coolest:

Run fMRIPrep on x86_64 chips.
Set up a native installation on your M1.
Work on building an ARM-based Docker image. If you can get this to a solid point, we could start publishing ARM tags to dockerhub.

If we do start supporting multiple architectures, we'll need to add that to the reporting.

Thank you. I may try to set up a native installation on my M1 some time. But I'm not really a programmer so I lack the skill to build an ARM-based Docker image (really hope I have the skill though). Still, I agree that supporting multiple architecture is a great way moving forward.

Sounds good. I think we can close this for now. If you start work on a native installation or Docker image and need some guidance, then we can either reopen or start a new issue.

Sure, thanks a lot for the help!

Just one little addition to this thread: When activating Rosetta in Docker one can get a decent performance with x86 images on ARM:


Move and modify behaviour of target_cluster function

The function target_cluster was moved from rule_extraction.jl to time_series_clustering.jl, which makes more sense
It now returns vector identifying scenarios that belong to target cluster instead of the target cluster index
It now merges the best cluster with the second one if the number of scenarios inside it is below some threshold

Closes #423 .

Suggesting minor changes for your review

I have implemented all your suggestions.

Two minor comments. Will merge once addressed.

@ConnectedSystems  done!


Add parent property to nodes

@thysultan I've adjusted the code to your suggestions, please take a second look

LGTM, have you experimented with that emotion plugin with theses changes to see if it affords the leverage you'd need to implement it?

LGTM, have you experimented with that emotion plugin with theses changes to see if it affords the leverage you'd need to implement it?

Yes, existing tests pass - but I need to add more, I already see this implementation here is broken for a couple of cases, for example:
compile(`.user{@media{@supports{b:1}}}`)

here the declaration should point to @supports and @supports should point to @media, which is not the case. Need to dig deeper into the algorithm to fix this - gonna ping u back once I figure this out.

here the declaration should point to @supports and @supports should point to @media, which is not the case.

What do they point to as it stands?

I think I got it right this time. However, parse has 9 parameters now - is that OK? Not sure if engines treat all functions equally (in that regard). It has somewhat weird effect that for this:
.user{@media{w:1;}}

we end up with a @media {.user{}} rule pointing to @media as its parent while having w:1; declaration as to its child which in turn also points to @media as its parent. While a little bit weird at first, it is semantically correct - it would be weirded if that rule (which is always automatically created even if there are no declarations for it) would have been pointing to anything else.

here the declaration should point to @supports and @supports should point to @media, which is not the case.

What do they point to as it stands?

that declaration was pointing to auto-created @supports{.user{}} and @supports was pointing to auto-created @media{.user{}}

@thysultan changed to use that syntax

LGTM

Pull Request Test Coverage Report for Build c1e3b611f6f32f5bfc8255a8316f5486e3803c7f-PR-204
Details

12 of 12 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 24f984a77b2ccb41c5a2bf273b9af4be09c602c1:
0.0%

Covered Lines:
236

Relevant Lines:
236

💛  - Coveralls

Pull Request Test Coverage Report for Build c1e3b611f6f32f5bfc8255a8316f5486e3803c7f-PR-204
Details

12 of 12 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 24f984a77b2ccb41c5a2bf273b9af4be09c602c1:
0.0%

Covered Lines:
236

Relevant Lines:
236

💛  - Coveralls


fix: jumbotron update, and mobile header

What does this PR do?

jumbotron update;
mobile header.

Type of change

[ ] Chore
[x] Bug fix
[ ] New feature
[ ] Documentation update

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (1490ade) 93.63% compared to head (b01e5ba) 93.63%.

Additional details and impacted files
@@           Coverage Diff           @@
##              dev     #503   +/-   ##
=======================================
  Coverage   93.63%   93.63%
=======================================
  Files          20       20
  Lines         330      330
  Branches       76       76
=======================================
  Hits          309      309
  Misses         10       10
  Partials       11       11

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


Provide an option to get a stack trace

I'm finding it hard to debug with messages like:
Cannot read property 'length' of undefined

Is there a way to get a stack trace on unhandled errors?

Yikes.  Disregard this.  It was a problem higher up.


how to?

can you make a about how to install and run ?

I started this one but lately discontinued it... if you are looking for an npm package then look for simpleclouduploader in my repo which handles quite well to upload media from network.. let me know in case you need any help on that


WIP: Uroot

This builds a u-root, but the integration with tamago-example is poor. Also, how do we want to integrate it the commands? do we call the u-root run command or ... I'm not really sure.
Once u-root is build, I change the run function as follows:
func run() {
log.Printf("run os.Args %q", os.Args)
err := bbmain.Run("tamago-example")
which ends up calling the tamago CLI.
Clearly, there is stuff to figure out here, but I'm amazed this works at all ...

Please move this to its own repository, I feel this is too invasive for tamago-example. Thanks!

Please move this to its own repository, I feel this is too invasive for tamago-example. Thanks!

And when doing so I'd suggest to remove any non u-root functionality and keep only the bare minimum from tamago-example so that the u-root integration is as focused as possible.


Fixed transform-react-inline-elements dependency removal.

The transform-react-inline-elements dependency was not completely removed.

Perfect, thank you!


Long CUDA kernels, long overall run times and CudnnLegacyConvRunner related errors with pjit on ampere GPUs

Using pjit on Ampere GPUs results in longer run times (This issue persists even if I build jaxlib from source with arch support explicitly enabled for 8.0 devices). I've created a small program that does distributed matmul (multi_layer_pjit_matmul.zip).
Following is a profile of the program on Ampere GPUs captured using nsight systems. There are a lot of cudaFree calls and I'm not sure if they're necessary. The program takes 10 min to run, while the actual computation happens at the very end in just a few seconds.

For comparison,  here's a profile of the same program on Volta GPU:

Secondly, running another program that uses flax and which does spatial parallel convolution using pjit on Ampere devices results in the following error. Is this a known issue? Or does anyone have any idea about the underlying cause and any workarounds?
2021-11-22 21:32:28.481653: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2086] Execution of replica 0 failed: INTERNAL: CudnnLegacyConvRunner cached across multiple StreamExecutors.
2021-11-22 21:32:28.481729: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2086] Execution of replica 0 failed: INTERNAL: CudnnLegacyConvRunner cached across multiple StreamExecutors.
2021-11-22 21:32:28.481795: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2086] Execution of replica 0 failed: INTERNAL: CudnnLegacyConvRunner cached across multiple StreamExecutors.
2021-11-22 21:32:28.481833: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2086] Execution of replica 0 failed: INTERNAL: CudnnLegacyConvRunner cached across multiple StreamExecutors.
2021-11-22 21:32:28.481884: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2086] Execution of replica 0 failed: INTERNAL: CudnnLegacyConvRunner cached across multiple StreamExecutors.
2021-11-22 21:32:28.481915: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2086] Execution of replica 0 failed: INTERNAL: CudnnLegacyConvRunner cached across multiple StreamExecutors.
2021-11-22 21:32:28.481952: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2086] Execution of replica 0 failed: INTERNAL: CudnnLegacyConvRunner cached across multiple StreamExecutors.
2021-11-22 21:32:34.303972: E external/org_tensorflow/tensorflow/compiler/xla/service/collective_ops_utils.h:216] This thread has been waiting for 5000ms for and may be stuck: participant NcclCliqueParticipantData{rendezvous_key=RendezvousKey{run_id=RunId: 72, global_devices=[0,1,2,3,4,5,6,7], num_local_participants=8, collective_op_kind=cross_module, op_id=9}, device_ordinal=1, stream=0x5d7bea0} waiting for all participants to arrive at rendezvous RendezvousKey{run_id=RunId: 72, global_devices=[0,1,2,3,4,5,6,7], num_local_participants=8, collective_op_kind=cross_module, op_id=9}
2021-11-22 21:32:38.481836: F external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_stream_executor_client.cc:2226] Replicated computation launch failed, but not all replicas terminated. Aborting process to work around deadlock. Failure message (there may have been multiple failures, see the error log for all failures):

CudnnLegacyConvRunner cached across multiple StreamExecutors.
Aborted (core dumped)

Version details:
jax                              0.2.26
jaxlib                           0.1.74+cuda11.cudnn82

ii  libcudnn8                   <IP_ADDRESS>-1+cuda11.4               amd64        cuDNN runtime libraries

We think the second of these problems was fixed by https://github.com/tensorflow/tensorflow/commit/eb8025bcaf25d9ddf2ca6a7015a13b179b239c9b, which didn't make it into the last jaxlib release. (You can build a jaxlib from TF / XLA head by editing the WORKSPACE file in the JAX root directory; see the comments in that file.)
We don't know what's happening with the first one yet.

@hawkinsp I see, I'll check out the fix for the second problem. Thanks!
Just to clarify for the first one, you're already aware of it, right? Let me know if you need any other information from my side.

Yes, we've reported this to the XLA:GPU team so they can take a look (b/207418070 for internal reference). Thanks for the clear report.

Hi curious if the second of the problem is included in the latest jaxlib release: 0.1.75?

Yes, I believe tensorflow/tensorflow@eb8025b is included in jaxlib 0.1.75.

I'm guessing this issue is long fixed, because we routinely run distributed matmuls (in the form of transformer models!) on Ampere. Please comment if it's still a problem!


chore: update git ignore

For us Mac users :)

Thanks for the suggestion.  This is an OS-specific file though, and is not specific to the nature of this project, so I would recommend adding it to a global .gitignore locally instead.  For example see https://dev.to/lpheller/quickly-ignore-dsstore-files-globally-ecd


Check the UX

Check for UX.Getting on iPhone XS Max dev app v1.9.5(333)

Verified this issue on dev app v1.9.5(335)


Testing out the update of net-ssh

From 2.9.2 to 3.0.2.  The main goal of this branch (right now) is to generate a working package that we can test with.
Before this could be merged we would need to update and probably release the following projects

Test Kitchen (change already in master, just needs 1.5.0 release)
R-train (needs a branch merge and release)

The software definition can be deleted after it is released

Chef (needs a branch merge and release)
Chef Provisioning (needs a branch merge and release)
Berkshelf (needs a branch merge and release)

I think the above is the order they need releasing it, but we'll need to test that.  There are circular dependencies between a lot of these.
Fixes https://github.com/chef/chef-provisioning/issues/446

The biggest change between Net::SSH 3.0 and 2.9 is the change from raising Timeout::Error to raising Net::SSH::ConnectionTimeout.  In all the software we're changing I've added that error to any retry loops where we were previously retrying Timeout::Error.
The question is: is this considered a breaking change that can only be released with a major version change?  If a user has a cookbook where they are currently depending on catching Timeout::Error and retrying that, I'm sure they would say 'yes'.

@tyler-ball chef-provisioning drivers probably catch Timeout::Error sometimes, so we'd need to go through those as well to preserve backcompat.

yeah i'd say its pretty unlikely that its cookbooks that are using this.
and i think its fair to say that this is an internal API change as well, and the maintainers of any software that breaks all need to do a point release to catch the different exception.

@jkeiser good call - I checked chef-provisioning-(aws|ssh|vagrant|docker|fog) without finding problems

:+1:

:+1:

The appveyor test succeeded, but for some reason it is hanging - https://ci.appveyor.com/project/chef/chef-dk/build/546.  I'm going to rebase and merge


Setup Release Process

We'll be building our package with DNT and publishing to JSR, NPM, and https://deno.land

Single package: @effection/contrib
One changelog per module
Each module has no other dependencies except for effection.

We need to set up covector to manage our changesets via GitHub workflows. The highest priority publication is JSR.

Each module has no other dependencies except for effection.

What about things like tinyexec, how will we include those dependencies?

I think we pass them in as a function argument, right?


No instruction for use with Huggingface models

Why there are no instructions to use with open source embedding models? The notebook does not work because you can not create docs/data and fill it unless you are paying for OpenAI api.

Thanks for your post - we are working on an example based on open source models from hugging face.
I will publish an article at medium, if its done.  You can subscribe there to get an email when its publish, if you want to.

Thank you for your answer. I appreciate your hard work and will be waiting for the article.

Here is a another article with code by Kennedy Selvadurai of using spotlight visualization with TinyLlama 1.1B: Visualizing FAISS Vector Space to Understand its Influence on RAG Performance

Hi @bahadirery, there is also docstring on top of the assistant module which briefly explains how to use different models (Hugging Face, OpenAI, Azure OpenAI). You can use them interchangeably (even combine OpenAI embeddings with HF LLMs or vice versa).
In case you don't want to add our repository to dependencies, just unravel the code from the module:
import torch
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.llms.huggingface_pipeline import HuggingFacePipeline
from transformers import pipeline

# Use desired models here
embeddings_model_name = "thenlper/gte-base"
llm_name = "google/flan-t5-base"

device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")
embeddings_model = HuggingFaceEmbeddings(
    model_name=embeddings_model_name,
    encode_kwargs={"normalize_embeddings": True},
    model_kwargs={"device": device},
)
llm = HuggingFacePipeline(
    pipeline=pipeline(model=llm_name, device=device, max_length=2048)
)

For usage example, refer to the @markus-stoll's article or module docstring mentioned above.


[Feature Request] Remove errors when they are fixed

Is your feature request related to a problem? Please describe.
While trying to learn and use the code-first experience, I was confused by the Prompt flow errors in the IDE. After check the details of each error, it seems like a point in time error during my flow development. However, even my flow is fixed and can run successfully, the accumulated PF errors don't go away. It's annoying to dismiss them one by one.

Describe the solution you'd like
Don't show errors when they are no longer valid (or have been fixed).
Describe alternatives you've considered
It might be a more natural place to show PF errors in VSCode Problem instead of having a pop up.

Additional context
N/A

Hello?


Update author on virtual-machines-tagging-arm.md

Hi @mmccrory, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;


The user system:serviceaccount:kube-system:microscope cannot list ciliumendpoints.cilium.io at the cluster scope error

Hi there,
I've deployed Microscope in Minikube, the pod is running successfully but can not execute any microscope filter.
$ kubectl apply -f https://raw.githubusercontent.com/cilium/microscope/master/docs/microscope.yaml
$ kubectl exec -it microscope -n kube-system -- sh
...
/usr/src/microscope # microscope --from-selector piggyback=ok

closing
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/bin/microscope/__main__.py", line 137, in <module>
  File "/bin/microscope/__main__.py", line 123, in main
  File "/bin/microscope/microscope/monitor/monitor.py", line 324, in run
  File "/bin/microscope/microscope/monitor/monitor.py", line 343, in get_monitor_command
  File "/bin/microscope/microscope/monitor/monitor.py", line 410, in retrieve_endpoint_data
  File "/bin/microscope/kubernetes/client/apis/custom_objects_api.py", line 823, in list_cluster_custom_object
  File "/bin/microscope/kubernetes/client/apis/custom_objects_api.py", line 923, in list_cluster_custom_object_with_http_info
  File "/bin/microscope/kubernetes/client/api_client.py", line 321, in call_api
  File "/bin/microscope/kubernetes/client/api_client.py", line 155, in __call_api
  File "/bin/microscope/kubernetes/client/api_client.py", line 342, in request
  File "/bin/microscope/kubernetes/client/rest.py", line 231, in GET
  File "/bin/microscope/kubernetes/client/rest.py", line 222, in request
kubernetes.client.rest.ApiException: (403)
Reason: Forbidden
HTTP response headers: HTTPHeaderDict({'Content-Type': 'application/json', 'X-Content-Type-Options': 'nosniff', 'Date': 'Thu, 26 Apr 2018 17:36:27 GMT', 'Content-Length': '323'})
HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"ciliumendpoints.cilium.io is forbidden: User \"system:serviceaccount:kube-system:microscope\" cannot list ciliumendpoints.cilium.io at the cluster scope","reason":"Forbidden","details":{"group":"cilium.io","kind":"ciliumendpoints"},"code":403}

I've review the docs/microscope.yaml and can see the system:serviceaccount:kube-system:microscope defined properly.
I'm using:

minikube version: v0.25.0
kubernetes version: 1.8
RBAC enabled
kubectl version: 1.9.2
mac osx: 10.13.4

Any idea?.
Thanks.

That worked!
Regards.


Uninstall support

closes #144, #23, #82

This is awesome. This was the last feature that was holding me back from making pnpm my default!

Almost ready. I have to fix bins for Windows and the pnpm -v command

@rstacruz, I think this one is ready to be merged. Could you please review it? The main idea is to store the internal/external dependencies in a store.json file. This allows the uninstall to work on shared stores.
I also added locking. The tests that check the locking sometimes fail. If this will be too frequent, I'll try to make them more stable in a later pull request


Contributor updates for repo-specific documentation

This PR updates README.md, INSTALLATION.md, and CONTRIBUTING.md  to provide information about installation and contribution that are specific to this repo.
@anissa111 Please note that RTD files under /docs directory should be updated after this PR is merged in order to have RTD link to repo-specific files here.
ALL: Please have your suggestions as inline comments to the files changed, then I will incorporate them ASAP to the documents.

@clyne @michaelavs,  my apologies that this PR was forgotten for a while. Could you please give it a new review as I addressed your comments?


OAS3 in file ooapiv5_MBO.yaml needs update

I don't see the property preferredName in this definitions, that is really in the specification

just repackackaged in 19c9142f74217d3d7bd5bd4fe5e003f6eaf0a4a8


⚠ Bofrost.es has degraded performance

In a03e883, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1559 ms

Resolved: Bofrost.es performance has improved in 6facf01 after 8 minutes.


Cask not running after failed "cask install"; complains about "/user//Cask" is missing

At the start brew and cask were installed, apparently ok.
First I tried to install Inkscape via Cask, and it failed in the middle of the process complaining that "Cask" file was missing:
Carloss-Mac-Pro:~ cribeiro$ cask install inkscape
Contacting host: melpa.milkbox.net:80
Contacting host: elpa.gnu.org:80
Contacting host: melpa.milkbox.net:80
...
Compiling /Users/cribeiro/.emacs.d/.cask/24.5.1/bootstrap/package-build-20150603.1934/package-build.el...
Wrote /Users/cribeiro/.emacs.d/.cask/24.5.1/bootstrap/package-build-20150603.1934/package-build.elc
Done (Total of 2 files compiled, 1 skipped)
Cask file does not exist: "/Users/cribeiro/Cask"

Now cask is still installed (according to brew anyway) but doesn't run anymore:
Carloss-Mac-Pro:~ cribeiro$  brew list cask
/usr/local/Cellar/cask/0.7.2/.no-upgrade
/usr/local/Cellar/cask/0.7.2/bin/cask
/usr/local/Cellar/cask/0.7.2/cask-bootstrap.el
/usr/local/Cellar/cask/0.7.2/cask-cli.el
/usr/local/Cellar/cask/0.7.2/cask.el
/usr/local/Cellar/cask/0.7.2/package-legacy.el
/usr/local/Cellar/cask/0.7.2/share/emacs/ (2 files)
/usr/local/Cellar/cask/0.7.2/share/zsh/site-functions/cask_completion.zsh
/usr/local/Cellar/cask/0.7.2/templates/ (2 files)

Carloss-Mac-Pro:~ cribeiro$ cask install inkscape
Cask file does not exist: "/Users/cribeiro/Cask

I tried a cleanup as recommended in some tickets with no luck:
Carloss-Mac-Pro:~ cribeiro$ brew cleanup
Removing: /usr/local/Cellar/bdw-gc/7.2e... (64 files, 1,6M)
Removing: /usr/local/Cellar/gettext/<IP_ADDRESS>... (1835 files, 19M)
Removing: /usr/local/Cellar/glib/2.40.0_1... (410 files, 18M)
Removing: /usr/local/Cellar/glibmm/2.40.0... (1594 files, 40M)
Removing: /usr/local/Cellar/libpng/1.6.10... (17 files, 1,3M)
Removing: /usr/local/Cellar/libsigc++/2.3.1... (619 files, 13M)
Removing: /usr/local/Cellar/xz/5.0.5... (58 files, 1,5M)
Removing: /Library/Caches/Homebrew/bdw-gc-7.2e.mavericks.bottle.tar.gz... (460K)
Removing: /Library/Caches/Homebrew/boost-build-1.55.0.tar.gz... (1,8M)
Removing: /Library/Caches/Homebrew/emacs-24.3.tar.gz.incomplete... (12M)
Removing: /Library/Caches/Homebrew/gdbm-1.11.mavericks.bottle.tar.gz... (132K)
Removing: /Library/Caches/Homebrew/geos-3.4.2.mavericks.bottle.tar.gz... (1,9M)
Removing: /Library/Caches/Homebrew/gettext-<IP_ADDRESS>.mavericks.bottle.tar.gz... (5,6M)
Removing: /Library/Caches/Homebrew/glib-2.40.0_1.mavericks.bottle.tar.gz... (4,8M)
Removing: /Library/Caches/Homebrew/glibmm-2.40.0.mavericks.bottle.tar.gz... (7,6M)
Removing: /Library/Caches/Homebrew/harfbuzz-0.9.40.mavericks.bottle.1.tar.gz... (692K)
Removing: /Library/Caches/Homebrew/intltool-0.50.2.mavericks.bottle.tar.gz... (96K)
Removing: /Library/Caches/Homebrew/libpng-1.6.10.mavericks.bottle.tar.gz... (432K)
Removing: /Library/Caches/Homebrew/libsigc++-2.3.1.mavericks.bottle.tar.gz... (3,7M)
Removing: /Library/Caches/Homebrew/openssl-1.0.1g.mavericks.bottle.tar.gz... (3,1M)
Removing: /Library/Caches/Homebrew/proj-4.8.0.mavericks.bottle.tar.gz... (3,1M)
Removing: /Library/Caches/Homebrew/python-2.7.6_1.mavericks.bottle.tar.gz... (18M)
Removing: /Library/Caches/Homebrew/readline-6.3.5.mavericks.bottle.tar.gz... (740K)
Removing: /Library/Caches/Homebrew/sqlite-<IP_ADDRESS>.mavericks.bottle.tar.gz... (896K)
Removing: /Library/Caches/Homebrew/ssh-copy-id-6.6p1.mavericks.bottle.tar.gz... (56K)
Removing: /Library/Caches/Homebrew/wget-1.15_1.mavericks.bottle.tar.gz... (348K)
Removing: /Library/Caches/Homebrew/xz-5.0.5.mavericks.bottle.3.tar.gz... (408K)
Removing: /Users/cribeiro/Library/Logs/Homebrew/bash-completion... (2 files, 8,0K)
Removing: /Users/cribeiro/Library/Logs/Homebrew/python... (2 files, 172K)
Carloss-Mac-Pro:~ cribeiro$ brew cask cleanup
Error: Unknown command: cask
Carloss-Mac-Pro:~ cribeiro$ brew install cask
Warning: cask-0.7.2 already installed
Carloss-Mac-Pro:~ cribeiro$

OOps. Seems like a big mess-up of mine.

Issue closed for a while but what's the solution?

OP closed the issue because it was simply user error. The solution is to closely follow what USAGE.md says, section Installing Casks:

The command brew cask install accepts a Cask token as returned by brew cask search. Let’s try to install Google Chrome:

$ brew cask install google-chrome

If your questions are not answered in USAGE.md, do not hesitate to open a new issue. Thanks!


can you provide h function for customize renderer.

Discussed in https://github.com/solidjs/solid/discussions/1612

Originally posted by zsytssk March 10, 2023
I'm writing a solidjs customize renderer for weapp support. and I need h function in some scenarios.
I have try use hyper-dom-expressions.createHyperScript but I get some errors, weapp environment don't support dom api like Node, and customize renderer don't export assign,dynamicProperty,SVGElements api.
can you provide a h function  or createHyperScript for  customize renderer.

As this is already discussion. I'm going to leave this there.


Feature - List helpers in $util.list

List helpers in $util.list
$util.list contains methods to help with common List operations, such as removing or retaining items from a list for filtering use cases.
$util.list.copyAndRetainAll(List, List) : List
Makes a shallow copy of the supplied list in the first argument, retaining only the items specified in the second argument, if they are present. All other items will be removed from the copy.
$util.list.copyAndRemoveAll(List, List) : List
Makes a shallow copy of the supplied list in the first argument, removing any items where the item is specified in the second argument, if they are present. All other items will be retained in the copy.
$util.list.sortList(List, Boolean, String) : List
Sorts a list of objects, which is provided in the first argument. If the second argument is true, the list is sorted in a descending manner; if the second argument is false, the list is sorted in an ascending manner. The third argument is the string name of the property used to sort a list of custom objects. If it's a list of just Strings, Integers, Floats, or Doubles, the third argument can be any random string. If all of the objects are not from the same class, the original list is returned. Only lists containing a maximum of 1000 objects are supported.

Fully agree this makes sense - we don't use the $util.list helpers at Skyhook but if you want to PR this it would be much appreciated. Alternatively I'm sure we'll end up adding in at some point


RP2040: support PLL On/Off control

Simple improvement that adds control over SYS and USB PLLs in RPi Pico (RP2040) MCU.
Old implementation did not work because it always targeted clocks_hw register that does not include PLL power bits.

@yonsch
Could you take a look?

@krzysztofgawrys
Please correct CI errors.

@krzysztofgawrys
Please correct CI errors.

Please have a look

just fixed compliance of the commit message - @yonsch please have a look :)

@yonsch
Could you take a look?


Provide a reference DataConnection / Bucket Model as Fallback

Tasks:

[ ] Update to latest OpenShift AI version
[ ] Provide a fallback

Update to OpenShift AI 2.16 do not solve the issue

Looks like this is a duplicate #86


Prepare libhxl-python 5.0 release

[ ] ensure no open pull requests
[ ] run unit tests in dev
[ ] update version to "5.0" in setup.py and hxl/__init__.py
[ ] check CHANGELOG
[ ] install and test in clean virtualenv
[ ] commit changes
[ ] merge to test and push
[ ] merge to main and push
[ ] create libhxl PyPi release: pip install twine && python setup.py sdist && twine upload dist/libhxl-5.0*
[ ] wait until the new release is visible on PyPi https://pypi.org/project/libhxl/5.0/
[ ] add git tag "5.0"
[ ] create GitHub release

Moved into a Google Doc: https://docs.google.com/document/d/1She9AAPGLy410N7f1eCmojOvXuHBIH2WAS1ljJXv1KA/edit?usp=sharing


Authz helper

this pull add helper to populate rpc paths related to fp tests to simplify testing authz.

Pull Request Functional Test Report for #2099 / 66e09e0d240c43109c62f00a27fc74978489dedd
No tests identified for validation.
Help


Localization in Html Strings

@DamianEdwards is there a plan to localize HTML strings in the following
HtmlString, MvcHtmlString, HttpServerUtility.HtmlEncode, HttpUtility.HtmlEncode and <%: %>  Code Nugget Syntax

We're working on that right now over in the MVC repo

Thanks ..


arrow ingestion panic

We've been test-running Parca with arrow ingestion enabled and ran into this panic. It might be unrelated but I believe we haven't seen this before:
panic: programming error; unable to find granule for part

goroutine 75 [running]:
github.com/polarsignals/frostdb.addPartToGranule({0xc0566cefc0, 0x1, 0xf520c5?}, 0xc0544cd040?)
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/table.go:1324 +0x12b
github.com/polarsignals/frostdb.(*TableBlock).compactGranule.func2(0xc008fbda28?)
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/compaction.go:455 +0x34
github.com/polarsignals/frostdb/parts.(*List).Iterate(0xc0459e9dc0, 0xc08b49fb60)
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/parts/part_list.go:90 +0x5f
github.com/polarsignals/frostdb.(*TableBlock).compactGranule(0xc000467180, 0xc0095e8280, 0xc0001a8078)
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/compaction.go:454 +0x83c
github.com/polarsignals/frostdb.(*TableBlock).compact.func1({0x51e9340?, 0xc0095e8280})
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/compaction.go:150 +0x125
github.com/google/btree.(*node[...]).iterate(0x52582a0, 0x2, {{0x0?, 0x0?}, 0x0?}, {{0x0?, 0x0?}, 0x0?}, 0x0, 0x1, ...)
        github.com/google/btree@v1.1.2/btree_generic.go:522 +0x3f7
github.com/google/btree.(*node[...]).iterate(0x52582a0, 0xc032960940, {{0x0?, 0x0?}, 0x7?}, {{0x0?, 0x0?}, 0x1?}, 0x0, 0x0, ...)
        github.com/google/btree@v1.1.2/btree_generic.go:527 +0x4be
github.com/google/btree.(*BTreeG[...]).Ascend(0xc000467180?, 0xfc05a0?)
        github.com/google/btree@v1.1.2/btree_generic.go:779 +0x49
github.com/google/btree.(*BTree).Ascend(...)
        github.com/google/btree@v1.1.2/btree_generic.go:1029
github.com/polarsignals/frostdb.(*TableBlock).compact(0xc000467180, 0xc0001a8078)
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/compaction.go:138 +0xc7
github.com/polarsignals/frostdb.(*compactorPool).compactLoop(0xc0013a1dd0, {0x5216018, 0xc000420140})
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/compaction.go:127 +0x2ed
github.com/polarsignals/frostdb.(*compactorPool).start.func1()
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/compaction.go:99 +0x66
created by github.com/polarsignals/frostdb.(*compactorPool).start
        github.com/polarsignals/frostdb@v0.0.0-20230227172736-d0eea82a3fcb/compaction.go:97 +0x6d

This was previously an ordering issue. We fixed this for parquet ingestion and now have an unsorted_inserts_total metric but the equivalent is unfortunately not implemented for the arrow ingestion path. I would bet that the arrow records are not sorted as expected.

The SeriesToArrowRecord function definitely doesn't sort the row like the normal path does, so it's definitely that.

Above PR seems to have fixed this panic, though we should still add the sorting guardrail.

Seeing this panic when updating to the latest FrostDB in Epimetheus too.
It works in bb0c4c0b but doesn't in 74bb058c
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x101629ec8]

goroutine 195 [running]:
github.com/apache/arrow/go/v10/arrow/array.(*String).Value(...)
        /Users/metalmatze/pkg/mod/github.com/apache/arrow/go/v10@v10.0.1/arrow/array/string.go:53
github.com/polarsignals/frostdb/pqarrow.appendToRow({0x1402070db00, 0x15, 0x2b}, {0x1041abbf0?, 0x1400111aff0?}, 0x645b?, 0x0?, 0x1?, 0x19?)
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/pqarrow/parquet.go:48 +0x4b8
github.com/polarsignals/frostdb/pqarrow.getRecordRow(0x1420461dc20?, 0x140001a8930?, {0x1041a92e8, 0x14001539950}, 0x3?, {0x14005f00000, 0x2b, 0x2?}, {0x140015c3000, 0x2b, ...})
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/pqarrow/parquet.go:85 +0x10c
github.com/polarsignals/frostdb/pqarrow.RecordToFile(0x140001a89a0, 0x1400089d560, {0x1041a92e8, 0x14001539950})
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/pqarrow/parquet.go:174 +0x244
github.com/polarsignals/frostdb/parts.(*Part).SerializeBuffer(0x140001a89a0?, 0x1041677c0?, 0x1420461c960?)
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/parts/part.go:50 +0x34
github.com/polarsignals/frostdb/parts.(*Part).AsSerializedBuffer(0x14001386c00, 0x140001a89a0)
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/parts/part.go:66 +0xbc
github.com/polarsignals/frostdb.compactLevel0IntoLevel1(0x1400020a300, 0x1?, {0x14001646418, 0x1, 0x1}, {0x0, 0x0, 0x0?}, 0x3ff0000000000000, 0x14007a6fb48)
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/compaction.go:565 +0x2e8
github.com/polarsignals/frostdb.(*TableBlock).Serialize.func2({0x10416cc60?, 0x14001386c40?})
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/table.go:1443 +0x13c
github.com/google/btree.(*node[...]).iterate(0x1041c48a0, 0x50, {{0x0?, 0x0?}, 0x0?}, {{0x0?, 0x0?}, 0x48?}, 0x0?, 0x0, ...)
        /Users/metalmatze/pkg/mod/github.com/google/btree@v1.1.2/btree_generic.go:522 +0x314
github.com/google/btree.(*BTreeG[...]).Ascend(0x140001a8930?, 0x1400020a280?)
        /Users/metalmatze/pkg/mod/github.com/google/btree@v1.1.2/btree_generic.go:779 +0x50
github.com/google/btree.(*BTree).Ascend(...)
        /Users/metalmatze/pkg/mod/github.com/google/btree@v1.1.2/btree_generic.go:1029
github.com/polarsignals/frostdb.(*TableBlock).Serialize(0x1400020a300, {0x10416fb80, 0x14001584038})
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/table.go:1431 +0x3d0
github.com/polarsignals/frostdb.(*TableBlock).Persist.func1()
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/store.go:29 +0x60
created by github.com/polarsignals/frostdb.(*TableBlock).Persist
        /Users/metalmatze/pkg/mod/github.com/polarsignals/frostdb@v0.0.0-20230309224239-74bb058c1c64/store.go:27 +0x1c0

Gonna close this issue as the sorting resolves the original panic. If you're still seeing the different panic you reported @metalmatze please open a separate issue and tag me on it.


Integrate BatchGroup rendering into CaptureViewElement

This adds a property RequestSeparateRenderGroup to CaptureViewElement.
If true, a CaptureViewElement will automatically create a new
render group with a unique name, and all of its contents and children
will be rendered in the new group, and all content will be restricted
to the extents of the element.
Performance before and after (tl;dr: basically no difference).

@beckerhe @florian-kuebler After rebasing this on Pierric's changes for the new track header layout, the track headers are now visible to the left of the timeline and the horizontal scroll bar. I need to investigate how I want to deal with this, the reason is that the TrackContainer extends past the screen due to scrolling. Everything else is fixed now, I'll re-request a review after I've addressed this, not sure if it'll be a small change or a bit more effort.

Very cool, thanks for this @reichlfl . For debugging, would it be easy to toggle this feature on/off?

Very cool, thanks for this @reichlfl . For debugging, would it be easy to toggle this feature on/off?

I have another PR in flight to visualize the groups for debugging: https://github.com/google/orbit/pull/4761
Do you think disabling is still needed with this?


Unable to take a screenshot and match on the first test run

When Im trying to run:
const screen = await takeScreenshot('something')
expect(screen).toMatchBaseline()
I get this error again and again:

Additional info:
Im able to press a button with testID in my app and moving forward to the next screen.

Hey @NetanelH2
This is not the fix but setting jest timeout might help.
jest.setTimeout(50000);

describe('<Login/>', () => {
    it('takes a screenshot of the Login screen', async () => {
        await toExist('LoginWithEmailButton');
        await press('LoginWithEmailButton');
        const screen = await takeScreenshot('login');
        await toExist('goBackTestID');
        await press('goBackTestID');
        expect(screen).toMatchBaseline();
    });
});

I've also noticed this happening occasionally on my side. It seems more prevalent on CI runs. I did a short investigation a few weeks ago and it seems to be caused by some race condition in the Websocket code. in some cases the websocket is expecting JSON responses (which represent the actions performed in tests as far as I can tell) but the initial connection message is plain text.
I did poke around briefly in the code but didn't have the time to dig into it. maybe one of the maintainers has an idea where the error could be.


Change Kafka collection approach to represent storage backpressure

http and scribe collectors accept requests, returning early. A thread will later persist to storage or error. We need to do this as we don't want to make instrumentation block.
We use the same approach in kafka at the moment, but we might want to reconsider it.
Right now, a surge in writes to elasticsearch will result in errors, as elasticsearch threads drop messages it can't store. Instead of reading more than we know we can store.. why don't we slow down and consume from kafka at the rate we can store?
For example, we could implement backpressure by linking the storage operations to the kafka consumer threads. If storage operations slow down, the kafka queue will build up, something relatively easy to monitor.
Any thoughts on the idea or other alternatives?

cc @eirslett @kristofa @prat0318 @liyichao @anuraaga @basvanbeek @abesto thoughts?

For example, right now, if too many writes go to Elasticsearch, we get logs like this. Seems that in Kafka, we could have an opportunity to just read less..
org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.transport.TransportService$4@3b438fe4 on EsThreadPoolExecutor[index, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@6ed30c21[Running, pool size = 8, active threads = 8, queued tasks = 200, completed tasks = 72]]

Sounds like a good idea to me!

Just curious, we are thinking to modifying just kafka transport because it can handle throttling and none of http/scribe can, correct?
Overall, looks a good idea.

@prat0318 exactly

Hi, any update ?

Here's the current thinking.
So Kafka implies running zookeeper. We have an adaptive sampler which uses zookeeper to store the target rate that the storage layer is capable of. We could re-use this code to rate limit kafka consumers (and/or drop), without adding a new service dependency (because kafka already needs zookeeper).
There's a problem we might have, which is that kafka marks slow consumers dead (I hear).
thoughts?

nows a good time to start working on this, since the elasticsearch code is stabilizing cc @openzipkin/elasticsearch

easiest dead simple start on this is to make storage block the kafka stream loop

Is there something 3rd lib can support Kafka  with Zipkin?

If you look at zipkin-aws and zipkin-azure in both cases you can add a
custom collector. So yes you could make a third party kafka collector that
does backpressure nicely. However it would be even nicer to contribute such
a change upstream as all we are missing is hands to help!
On 14 Mar 2017 10:33, "宋鑫"<EMAIL_ADDRESS>wrote:

Is there something 3rd lib can support Kafka with Zipkin?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/issues/1181#issuecomment-286354335,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD610BJdzbqwIHbf0JVZerha96nhgr_ks5rllDegaJpZM4JKK1i
.

Kafka will only hand you the messages as fast as you can receive them, so indeed, if backpressure is ever needed we could make a blocking version of the collector.

There's a problem we might have, which is that kafka marks slow consumers dead (I hear).

Indeed, this refers to https://kafka.apache.org/documentation/#max.poll.interval.ms . Default value is 5 minutes though, if the storage write from the latest message poll did not complete within 5 minutes you have other issues mkay.


A11y guards and type checks

There are some a11y setters that could benefit from guards (don't rebuild/change things if the value didn't ACTUALLY change) and type checks (asserts). This should enhance performance, and will catch bugs earlier.
For instance, to augment the current version of setAriaLabel:
setAriaLabel: function( ariaLabel ) {
  this._ariaLabel = ariaLabel;

  this.setAccessibleAttribute( 'aria-label', ariaLabel );
},

it could be enhanced with:
setAriaLabel: function( ariaLabel ) {
  assert && assert( ariaLabel === null || typeof ariaLabel === 'string' );

  if ( this._ariaLabel !== ariaLabel ) {
    this._ariaLabel = ariaLabel;

    this.setAccessibleAttribute( 'aria-label', ariaLabel );
  }
},

Added asserts in the above commit, the rest will be handled by #800.
Tested with scenery tests, a11y and normal fuzzing, and looking at a few a11y views.
Closing


OKE-29394 Ingress state build failure when ingress reference non-existent ingress class

Added code to skip ingress if no usable ingressclass is found.

Duplicate.
https://github.com/oracle/oci-native-ingress-controller/pull/33


Update bPoint.py

Should fix this case where you'd want tangent points to be smooth

this is not good, the next segment should be checked if its a curve if the current segment is a line.
bType = None
if point.smooth:
    if typ == "curve":
        bType = "curve"
    elif typ == "line":
        nextSegment = self._nextSegment
        if nextSegment is not None and nextSegment.type == "curve":
            bType = "curve"
        else:
            bType = "corner"
elif typ in ("move", "line", "curve"):
    bType = "corner"

if bType is None:
    raise FontPartsError("A %s point can not be converted to a bPoint."
                                 % typ)

Shouldn't there be a "tangent" BPoint type? From our slack discussion:

shouldn’t there be “corner” (any point that is not “smooth”), “curve” (a point that is smooth that is between two curve segments) and “tangent” (a point that is smooth that connects a straight line and a curve segment).

BPoints are the old Fontographer notion of points, and it distinguished between those three as well, and it makes sense from a BPoint perspective.

(Note that I don't really care how this ends up, I'm not a user of BPoints at all. Just remembering Fontographer here with some fuzzy feelings :) )

+1 targents point type but that is maybe an other discussion/issue/PR

@typemytype my apologies, I put out a quick fix to start a PR with Erik...thanks for all of this!

Thanks @benkiel and @typemytype!


Make option for independent axes across panels when grouping

Allow for independent chart scaling when grouping by a variable - it would be nice if a user could tell codebook for a certain variable to scale each plot differently. For example, if you group by lab test in a vital sign dataset, you get 1 plot for each test on a scale from 0-160. This produces a nice plot for blood pressure & heart rate, but not for temperature.  SDTM and ADaM datasets are vertical, often with a test/parameter variable.
(From SDF)

Most important use case is probably for continuous measures since categorical charts already have an option to toggle between # and %.
To implement, we can add a "commonScale" option to each continuous variable that determines whether the panels in the histogram/boxplot renderer have a common scale (the current default) or not. Leaning towards not making this configurable for now - it can just be set via the user in the chart controls.
Key code in the renderer is here. Will also need a new ./charts/createHistogramBoxPlotControls/js method to handle the toggle.

Test Notes:

No changes when no group variable is specified
When group is specified a new "Standardize x-axis?" checkbox should be visible for continuous variables.
When checkbox is clicked, all x- and y-axis should have the same range for all panels.
When checkbox is not clicked, x- and y-axis should vary to match the range for each individual panel.

For a good test case (matching the SDF request above):

LoadADBDC.csv in cat
Click hide all charts
Open Settings tab and check 'group' column for the 'test' row
Open codebook tab and group by test
Expand the "STRESN" chart. Notice the tiny histograms for most panels
Unselect the  "Standardize axes across panels?" checkbox, and observe the improved histograms

Tested and confirmed functionality of new "Standardize axes across panels?" checkbox in all browsers.


nixos-install: add support for flakes

Motivation for this change
Use nixos-install with a flake.nix.
Things done
I've just copied code from nixos-rebuild, not sure whether all this is correct.

[X] Add support for --flake and other options like in nixos-rebuild.
[X] Quote variables to please ShellCheck (I hope I've not done any mistake in doing so).
[X] Use pkgs.nixFlakes instead of nix when --flake is involved.
[X] Document --flake.
[X] Fix documentation by using the URI fragment syntax.

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

I just want to note to nixos devs to please not merge this PR without the documentation. I hope that doesn't sound rigid, but I think it's more likely, if this isn't documented in the same PR, to take a significantly longer time to be documented.

IMHO jq should be added to PATH as it had been done for nixos-rebuild

@vlaci tools.nix puts jq into PATH and nixos-install is an output of this.

@worldofpeace are you sure? my installer iso built from unstable does not have it by default, and I only see it scoped to nixos-rebuild in tools.nix

@worldofpeace are you sure? my installer iso built from unstable does not have it by default, and I only see it scoped to nixos-rebuild in tools.nix

Ooh, I thought you meant for the wrapped PATH for nixos-install, but actually you mean as a utility available in nixos by default. I think that's excessive, and we certainly wouldn't want to undo the wrapping for the tools as that would make them non-hermetic. So I would consider adding jq out of scope for this particular change as jq isn't really a necessary utility outside of these programs that need them.

@worldofpeace are you sure? my installer iso built from unstable does not have it by default, and I only see it scoped to nixos-rebuild in tools.nix

Ooh, I thought you meant for the wrapped PATH for nixos-install, but actually you mean as a utility available in nixos by default. I think that's excessive, and we certainly wouldn't want to undo the wrapping for the tools as that would make them non-hermetic. So I would consider adding jq out of scope for this particular change as jq isn't really a necessary utility outside of these programs that need them.

No, I have meant nixos-install in the first place then I have misunderstood you :)
Anyway, this PR does not add jq in the path for nixos-install and it isn't already there. What am I missing?
It is set for nixos-enter in https://github.com/ju1m/nixpkgs/blob/nixos-install/nixos/modules/installer/tools/tools.nix#L34
but is not for nixos-install at https://github.com/ju1m/nixpkgs/blob/nixos-install/nixos/modules/installer/tools/tools.nix#L23
Sorry I have meant to put the links in the first comment but somehow missed it.

Oh, lol @vlaci understood.

hardware-configuration.nix imports <nixpkgs/nixos/modules/installer/scan/not-detected.nix>. I'm not sure how, but we should somehow take care of this when using flakes.

By having a module which does whatever detected.nix / not-detected.nix do (which is not a lot currently) depending on a boolean value which nixos-install should write in hardware-configuration.nix ?

For hardware-configuration not detected and anything that wants to use <nixpkgs> we'll have to conditionally change the syntax to like inputs.nixpkgs.nixosModules.notDetected. IIRC at a glance there's a lot of code that would have to be different.

Ok never mind, it uses modulesPath anyway these days. You probably meant the case where people already have a generated hardware-configuration.nix.. I guess they can just regenerate it then?

 I actually generated a fresh config in my temporary /mnt mount, but I used the default nixos-generate-config from my 20.03 system for that purpose, so never mind then :)

@ma28 Oh awesome https://github.com/NixOS/nixpkgs/commit/c45295d47e91fef3fdb13ee11fc24ebff8ad7288#diff-14ed97ea0350115b36b0b8d884db5667 no action needed :sparkles:

I've tried to incorporate your feedbacks as I could. Please let me know if something is missing or wrong.

@ofborg test installer.simple
(Feel free to check additional installer tests, but I believe this is the simplest (heh) of the bunch that tests nixos-install.)

So @cole-h cleared up on IRC that my reading skills aren't that great today :rofl:
worldofpeace: btw we went over that yesterday -- in a trap, single quotes don't prevent expansion unless the variable is single-quoted inside those single-quotes (iirc)

I think jq is still missing from https://github.com/NixOS/nixpkgs/blob/607f5a6755dddb0b6ecce5bb227234db1a527501/nixos/modules/installer/tools/tools.nix#L25 (just stumbled upon this, as jq is not in my default PATH)

I think jq is still missing from
https://github.com/NixOS/nixpkgs/blob/607f5a6755dddb0b6ecce5bb227234db1a527501/nixos/modules/installer/tools/tools.nix#L25
(just stumbled upon this, as jq is not in my default PATH)

You're right. I think it just disappeared from the diff at some point.

fixed in https://github.com/NixOS/nixpkgs/commit/a39ad857267091e3f75016f09589405a6a41e658

backported to 20.09 281c8991a21915f856f6f882626f84f10052f23e

https://github.com/NixOS/nixpkgs/blob/c8ccfdb5f4a59d371eb589308679b55783b393b8/nixos/modules/installer/tools/nixos-install.sh#L155-L157
This builds the flake in /nix instead of /mnt/nix, which makes nixos-install run out of memory for me on a live CD.
It doesn't seem like nix build has something like a --store flag, should I open a separate issue?

Actually, all nix commands have a --store flag, because --store ... is shorthand for --option store .... I'll have a PR ready shortly.


Add: Jeremy's scripts activity

This is the start of an activity that @ucodery put together on entry points and scripts.
This is Jeremy's amazing work not mine!! i'm just opening the PR so my name is on the commit .
We didn't have a packaging directory yet but the idea here would be to create activities that link to our tutorials and also take advantage of the copier template that @midnighter created!!
I suspect a few people will be ahead during the packaging workshop. Also, I suspect that things will move faster now that we have a template. It would be useful to discuss scripts and entry points during that workshop!

(btw in case this isn't clear, none of these comments are intended as blockers, i think the context for this lesson is intended to be taught in the current workshop, so plz feel free to merge and iterate and whatnot)

hi all - i'm so sorry that i am slowing things down. A few notes - if you want to merge this and open a new pr with modifications so you are more in control of the edits you are welcome to do that! however you want to move forward, just let me know what will make things easiest and what will ensure that I am not in the way of things moving forward!

Before merging, we'd only want to add a link to the content from the home page / top nav! But again, feel free to merge this once you are happy with it and then open new PR's and issues as needed.

I am closing this PR in favor of #97 which I actually control. I managed to get CI working by doing this, but I left all the commits from this PR untouched, so should be easy to brows what's new. If I don't see any objections I will merge that one EoW. As always feel free to bug me here or on slack with thoughts on the lesson post-merge.


ccmbridge tests

integration tests, create a cluster at version, run sstable2json and verify output

python ccm lib seems to work well enough, close-not fixed


HLS manifests that include in-stream (subtitle) text track(s) fail to load on Chromecast (gen. 1)

sample HLS manifests:

https://cdn.theoplayer.com/video/elephants-dream/playlist-single-audio.m3u8
https://bitdash-a.akamaihd.net/content/sintel/hls/playlist.m3u8

rather than going into excruciating detail, I'll summarize:

tested on Chromecast gen. 1
tested with:

Cast Receiver v2
Cast Receiver v3 (CAF)
chrome.cast.media.DEFAULT_MEDIA_RECEIVER_APP_ID

sample streams won't play

other HLS manifests that don't include any in-stream (subtitle) text tracks do play well

this generalization also applies to HLS manifests that contain video streams with embedded/muxed closed captions

questions:

is this a known issue or limitation

I only own gen. 1 devices and haven't tested on newer hardware, which shouldn't matter as this is clearly a software issue

do these streams work for you?

questions (not directly related to issue):

assuming this issue were fixed, what is the correct way for the sender to manage the visibility of in-stream (subtitle) text tracks?

should the master manifest be parsed by the sender and the URL of each inner #EXT-X-MEDIA:TYPE=SUBTITLES manifest be added and managed as an external text track?

is there a similar API to manage the visibility of embedded/muxed closed captions?

can they even be displayed on the Chromecast?

update: docs for the TextTracksManager class seems to answer these questions

It's possible that I'm attributing these observations to the presence of in-stream subtitles only because that's the topic in which I'm currently working.
I just tested a completely unmodified copy of the official reference sender app for Chrome that uses CAF APIs on both sender and receiver. None of the .mp4 media URLs play on any of my gen. 1 devices.
If I were to copy any of these .mp4 media URLs on a sender app for Chrome that doesn't use framework APIs (ex: Clappr), it plays fine.
This new observation makes me think that something much more fundamental has recently been broken.. either in the receiver SDK, or possibly even in a recent firmware update.
Any insight?

cross-reference: issue added to tracker

Closing as the issue is being followed up in the tracker


Feat: add more video challenges

Adding more video challenges for new Python curriculum.

Alright, I think this LGTM. We can iron out any bugs if they show up.


This block needs update to the code to support centralized LAW across the region.

This block needs update to the code to support centralized LAW across the region.
traffic_analytics = {
enabled                             = true
Request to update code to support Centralized LAW in different region. In portal LAW in different region works
log_analytics_workspace_destination = "cus_logs"     # This needs update to support centralized LAW acroos the region
interval_in_minutes                 = "10"
}
Originally posted by @riteshmehta66 in https://github.com/aztfmod/terraform-azurerm-caf/issues/870#issuecomment-993530739

mistake. closing. Original issue #870 still open


[tests-only][full-ic]Refactor feature files to add correct description

Description

Related Issue

Fixes <issue_link>

Motivation and Context

How Has This Been Tested?

test environment:
test case 1:
test case 2:
...

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Technical debt
[ ] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

:boom: Acceptance test Core-API-Tests-ocis-storage-5 failed. Further test are cancelled...


Include toolbar options in the markdown editor

Description
The HTML editor uses a 3rd party library called Jodit to provide a WYSIWYG editor experience for entering HTML. The Markdown editor however does not provide much in the way of supporting editing options. There is a link to a help page for markdown syntax, but it leaves the entry of text up to the user.
One way to improve this is to include custom toolbar options to handle the basic markdown syntax - such as inserting bold/italic text, headings etc.
Additional context
Markdown syntax is not very complex, so I believe the only necessary options to include would be:

Bold - to enter **text**
Italic - to enter _text_
Headings - to enter various heading levels - #, ##, etc
Quote - to enter > text
Bullet and numbered lists

There are currently three existing toolbar buttons in our markdown editor already, these can remain and be supplemented with the actions above.

Another alternative could be to search for a 3rd party WYSIWYG markdown editor, but this may be overkill since the possible actions above are not very complicated.

I'd prefer this to be started once #418 - the PR #572 has reorganised code around the content editors which may be useful for this issue.


Check administrator only when security is enabled

Why are the changes needed?

This PR aims to improve out-of-box UX.
Currently, administrators' checking is enforced even when security is disabled, and we are going to deliver the preview of Web UI in 1.8, it may confuse users who use the default configuration to launch Kyuubi sever and explore Kyuubi WebUI (because the user "anonymous" can not visit all users' sessions/engines without being configured as an administrator).
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Was this patch authored or co-authored using generative AI tooling?

No

LGTM