ValueError: Could not build path with entities

What happened?
when I run pre-process with fmriprep, it shows this value error. But this error doesn't interrupt the preprocessing, so I want to ask what is the result of this problem, how should I fix it, and should I interrupt the preprocessing to fix the bug or wait for it to finish?
Traceback:
	Traceback (most recent call last):
	  File "/opt/conda/lib/python3.9/site-packages/nipype/interfaces/base/core.py", line 397, in run
	    runtime = self._run_interface(runtime)
	  File "/opt/conda/lib/python3.9/site-packages/niworkflows/interfaces/bids.py", line 629, in _run_interface
	    raise ValueError(f"Could not build path with entities {out_entities}.")
	ValueError: Could not build path with entities {'subject': '001', 'run': 04, 'suffix': 'bold', 'datatype': 'figures', 'extension': 'html', 'desc': 'summary'}.

What command did you use?
fmriprep-docker /Users/bogengsong/Desktop/fmri/bids /Users/bogengsong/Desktop/fmri/bids/result --participant-label 001 --fs-license-file /Users/bogengsong/Desktop/license.txt --fs-no-reconall  --skip-bids-validation

What version of fMRIPrep are you running?
lastest version
How are you running fMRIPrep?
Docker
Is your data BIDS valid?
Yes
Are you reusing any previously computed results?
No
Please copy and paste any relevant log output.
No response
Additional information / screenshots
No response

Can you run the BIDS validator on your dataset and share the results?

lastest version

Please also be specific. You can find the version by running fmriprep-docker --version

Hi Taylor and Chris
Sorry for the late reply. I use the web version of bids validator. I
uploaded my bids folder, which I created by dcm2bids -d, into the bids
validator. And the attachment is the result.
And the version of my fmriprep is fMRIPrep v23.0.2.
Best
On Thu, Jun 8, 2023 at 1:25 PM Chris Markiewicz @.***>
wrote:

lastest version
Please also be specific. You can find the version by running fmriprep-docker
--version
—
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nipreps_fmriprep_issues_3026-23issuecomment-2D1583061950&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=h9hQ2yfZvPYLA9XZ2bbMqw&m=hG0T5QnE7yq57-Mh2bAZXwyPYTcfcgOjYidd7j6A_Yzx0stDGVEzOySU6JRnaLJq&s=Xkvf7E1Hr6u4o4onjy2HdxfGQBa1cwxKGrU0eiuWv2c&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AUPXVVRLDUUWCKZFJ4CYLODXKIDHXANCNFSM6AAAAAAY45UCQU&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=h9hQ2yfZvPYLA9XZ2bbMqw&m=hG0T5QnE7yq57-Mh2bAZXwyPYTcfcgOjYidd7j6A_Yzx0stDGVEzOySU6JRnaLJq&s=w1GE7zxTbPa8eDMZ0nKdXfXw_H01dldIfWfuh6zy63k&e=
.
You are receiving this because you authored the thread.Message ID:
@.***>

File Path: Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Type:		Error
File:		sub-001_run-01_epi.json
Location:		bids2/sub-001/fmap/sub-001_run-01_epi.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-01_epi.json

Type:		Error
File:		sub-001_run-01_epi.nii.gz
Location:		bids2/sub-001/fmap/sub-001_run-01_epi.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-01_epi.nii.gz

Type:		Error
File:		sub-001_run-02_epi.json
Location:		bids2/sub-001/fmap/sub-001_run-02_epi.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-02_epi.json

Type:		Error
File:		sub-001_run-02_epi.nii.gz
Location:		bids2/sub-001/fmap/sub-001_run-02_epi.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-02_epi.nii.gz

Type:		Error
File:		sub-001_run-03_epi.json
Location:		bids2/sub-001/fmap/sub-001_run-03_epi.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-03_epi.json

Type:		Error
File:		sub-001_run-03_epi.nii.gz
Location:		bids2/sub-001/fmap/sub-001_run-03_epi.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-03_epi.nii.gz

Type:		Error
File:		sub-001_run-01_bold.json
Location:		bids2/sub-001/func/sub-001_run-01_bold.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-01_bold.json

Type:		Error
File:		sub-001_run-01_bold.nii.gz
Location:		bids2/sub-001/func/sub-001_run-01_bold.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-01_bold.nii.gz

Type:		Error
File:		sub-001_run-02_bold.json
Location:		bids2/sub-001/func/sub-001_run-02_bold.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-02_bold.json

Type:		Error
File:		sub-001_run-02_bold.nii.gz
Location:		bids2/sub-001/func/sub-001_run-02_bold.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-02_bold.nii.gz

Type:		Error
File:		sub-001_run-03_bold.json
Location:		bids2/sub-001/func/sub-001_run-03_bold.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-03_bold.json

Type:		Error
File:		sub-001_run-03_bold.nii.gz
Location:		bids2/sub-001/func/sub-001_run-03_bold.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-03_bold.nii.gz

Type:		Error
File:		sub-001_run-04_bold.json
Location:		bids2/sub-001/func/sub-001_run-04_bold.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-04_bold.json

Type:		Error
File:		sub-001_run-04_bold.nii.gz
Location:		bids2/sub-001/func/sub-001_run-04_bold.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_run-04_bold.nii.gz

Type:		Error
File:		sub-001_2023-06-18T144127.533910.log
Location:		bids2/tmp_dcm2bids/log/sub-001_2023-06-18T144127.533910.log
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	sub-001_2023-06-18T144127.533910.log

Type:		Error
File:		001_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329.json
Location:		bids2/tmp_dcm2bids/sub-001/001_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	001_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329.json

Type:		Error
File:		001_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/001_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	001_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329.nii.gz

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00004.json
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00004.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00004.json

Type:		Error
File:		002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00004.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00004.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	002_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00004.nii.gz

Type:		Error
File:		003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json
Location:		bids2/tmp_dcm2bids/sub-001/003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json

Type:		Error
File:		003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz

Type:		Error
File:		003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json
Location:		bids2/tmp_dcm2bids/sub-001/003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json

Type:		Error
File:		003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz

Type:		Error
File:		003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json
Location:		bids2/tmp_dcm2bids/sub-001/003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json

Type:		Error
File:		003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	003_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz

Type:		Error
File:		004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json
Location:		bids2/tmp_dcm2bids/sub-001/004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.json

Type:		Error
File:		004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00001.nii.gz

Type:		Error
File:		004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json
Location:		bids2/tmp_dcm2bids/sub-001/004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.json

Type:		Error
File:		004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00002.nii.gz

Type:		Error
File:		004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json
Location:		bids2/tmp_dcm2bids/sub-001/004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.json

Type:		Error
File:		004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	004_NEW_REGION_HUANG_LIANG_20230519_134329_352000_AAHead_Scout_20230519134329_i00003.nii.gz

Type:		Error
File:		005_NEW_REGION_HUANG_LIANG_20230519_134329_352000_localizer_fl2d_sag_for_ACPC_64ch_20230519134329.json
Location:		bids2/tmp_dcm2bids/sub-001/005_NEW_REGION_HUANG_LIANG_20230519_134329_352000_localizer_fl2d_sag_for_ACPC_64ch_20230519134329.json
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	005_NEW_REGION_HUANG_LIANG_20230519_134329_352000_localizer_fl2d_sag_for_ACPC_64ch_20230519134329.json

Type:		Error
File:		005_NEW_REGION_HUANG_LIANG_20230519_134329_352000_localizer_fl2d_sag_for_ACPC_64ch_20230519134329.nii.gz
Location:		bids2/tmp_dcm2bids/sub-001/005_NEW_REGION_HUANG_LIANG_20230519_134329_352000_localizer_fl2d_sag_for_ACPC_64ch_20230519134329.nii.gz
Reason:		Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder.
Evidence:	005_NEW_REGION_HUANG_LIANG_20230519_134329_352000_localizer_fl2d_sag_for_ACPC_64ch_20230519134329.nii.gz

======================================================
File Path: Subject label in the filename doesn't match with the path of the file. File seems to be saved in incorrect subject directory.
Type:		Error
File:		sub-001_2023-06-18T144127.533910.log
Location:		bids2/tmp_dcm2bids/log/sub-001_2023-06-18T144127.533910.log
Reason:		Subject label in the filename doesn't match with the path of the file. File seems to be saved in incorrect subject directory.
Evidence:	File: /tmp_dcm2bids/log/sub-001_2023-06-18T144127.533910.log is saved in incorrect subject directory as per sub-id in filename.

======================================================
File Path: Tabular file contains custom columns not described in a data dictionary
Type:		Warning
File:		participants.tsv
Location:		bids2/participants.tsv
Reason:		Tabular file contains custom columns not described in a data dictionary
Evidence:	Columns: age, sex, group not defined, please define in: /participants.json

======================================================
File Path: The Authors field of dataset_description.json should contain an array of fields - with one author per field. This was triggered based on the presence of only one author field. Please ignore if all contributors are already properly listed.
Type:		Warning

======================================================
File Path: The Name field of dataset_description.json is present but empty of visible characters.
Type:		Warning

======================================================

Okay. You need to get your dataset to be BIDS valid. We can't support issues that result from trying to use fmriprep on invalid datasets. I would recommend consulting neurostars. You'll want a full listing of the dataset in addition to the validator output.


Memory leak fixes

Went looking for memory leaks in Polycode. Found a LOT.
In this pull request, I broke my changes into four commits because some of the changes I made seemed "controversial" and I wanted you to have the ability to take or leave some of them.
Commit 1: Basic no-brainer leak fixing
Commit 2: Virtual destructors. IMO basically every destructor in Polycode should be virtual because any class could potentially be subclassed by a Polycode user, and I ran into situations even in basic Polycode where destructors weren't being called (and memory was leaking) for lack of virtualness. I did NOT virtualize the following classes: particle , quaternion, vertex, matrix4, String, Data; because I figured (1) these objects are getting created in mass quantities (2) these objects are often really tiny, so there is some reason to think there's actually a real downside to giving those classes a vtable.
Commit 3: A few objects had owned variables which sometimes, but not always, might be appropriate to outlive the object. For example a Scene has many children and a default camera. Looking at the destructor I find commented out code to delete all the children. Instead of commenting it out, I added an "ownsChildren" flag and it deletes or doesn't depending on whether the flag says to. This means the user can actually decide which behavior they want. Also impacted here: Screen, SceneMesh (because sometimes it owns its Skeleton and sometimes it doesn't).
Commit 4: As part of the virtual destructors patch PhysicsSceneEvent needed to be modified, but the patch didn't apply because the commit I was branching from didn't include pull request #90, so I just went ahead and added a tiny commit adding a "virtual" to #90.
Note: I looked at the CollisionScene classes, but not the PhysicsScreen or PhysicsScene classes yet. I feel confident the latter two will also have lots of leaks.

Latest commit adds PhysicsScene so all 3D physics stuff is now leak audited. I haven't done any 2D physics stuff though.
Note that d1ae9d8 calls Scene(false) so it will have bad effects unless you also merge in #96.


update links to the blog post referenced to fix the internet 😁

I know these are old and not probably not referenced but in the interest of preserving links I'm updating this info 😀

@Gordon-Beeming : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@Gordon-Beeming Thanks for updating the links to your content.

@Gordon-Beeming - Thanks for the update. I appreciate it.


Kotlin DSL patch

Kotlin DSL using createType().javaType on reified generic instance sometimes fail, replaced with typeOf<...>() function which was created for this specific scenario.
Additionally added a test for the functionInteractionInstance() utility method, removed reified keyword where not needed.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 79.77%. Comparing base (14915fa) to head (ba362e9).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1698   +/-   ##
=======================================
  Coverage   79.77%   79.77%
=======================================
  Files         144      144
  Lines        4865     4865
  Branches      161      161
=======================================
  Hits         3881     3881
  Misses        984      984

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


nav: inconsistent search results

We can't really fix this, we don't do any filtering on the results from the HERE search api. And we previously found that this api gives the best results compared to others.


Race condition between multiple sagas listening to same action

Description
I have 2 sagas listening to the same action using takeLatest. When that action is dispatched, I expect both sagas to be run concurrently. Both sagas write to the same variable in Redux, causing a race condition (I know this is bad - I have removed the race condition, but I am trying to understand it better). I expect that the saga who finishes last will have their value persisted in Redux.
I have a CodeSandbox to demonstrate this scenario https://codesandbox.io/s/ywjlkown5v. This is using redux-saga 0.16.0.
In the demo, when I have
const saga = function*() {
  yield takeLatest("ADD_MESSAGE", appendSaga);
  yield takeLatest("ADD_MESSAGE", noopSaga);
};

the appendSaga "wins" by finishing last, and I see "foofoofoo" after clicking the button a few times. Then, when I change it to
const saga = function*() {
  yield takeLatest("ADD_MESSAGE", noopSaga);
  yield takeLatest("ADD_MESSAGE", appendSaga);
};

the appendSaga still "wins" and I see "foofoofoo".
What's interesting is when I upgrade redux-saga to 1.0.2, the behavior changes. Here is the same sandbox with 1.0.2 https://codesandbox.io/s/moon9kw43x
Now the order of my takeLatest calls matters. When I have
const saga = function*() {
  yield takeLatest("ADD_MESSAGE", appendSaga);
  yield takeLatest("ADD_MESSAGE", noopSaga);
};

the noopSaga "wins" by finishing last, and I see "" after clicking the button a few times. And when I change it to
const saga = function*() {
  yield takeLatest("ADD_MESSAGE", noopSaga);
  yield takeLatest("ADD_MESSAGE", appendSaga);
};

the appendSaga "wins" and I see "foofoofoo".
Why did this behavior change in 1.0? Is this expected? I searched the release notes but failed to find the relevant change.

If I understand correctly, your problem can be rephrased in that the sagas used to run in parallel in 0.16 but in 1.0 they will run in sequence? If so, as a newcomer to redux-saga I think the new behavior makes a lot more sense, and if you want your sagas to execute in parallel then wrap them in all().
Hope this helps and I just didn't completely miss the point :)

This is side-effect of this change:

internal stdChannel got reworked to be a singleton object (it is wrapped multicastChannel's instance'), also it is an exported API to support new runSaga's signature - this should also result in being a small perf boost

Previously when we had 1 stdChannel per saga our scheduler was "released" (semaphore was decremented) after each put on such channel and in this particular situation it lead to a flush of the queued actions because it managed to go to 0.
The same thing happens in v1 (releasing, flushing etc) but we release only after "full pass" - after an action has a chance to reach each existing task, so in this particular situation - there is only a single release in comparison to 2 releases of our internal semaphore in previous versions of the saga.


Fix MSVC warning. I can't test it, but now it matches the prototypes.

Change cast (char*) to (char *). Doesn't seem required style, but the space is used over 98% of the time; so...

thanks!


resolves #899 Flaky ZManaged tests

@mschuwalow Let me know when this is ready for a final pass!

Thanks for your work here! Merging now so we can help remove spurious test failures sooner.


Top-1 accuracy on ImageNet drops between runs -- only difference is FFCV

Hello,
Training a ResNet50 on ImageNet for a project and noticed the following issues:

Top-1 Accuracy drops significantly and the PyTorch DataLoader version is almost always better on the test set.
There is a less drastic difference in terms of training-time metrics but there is around 2% drop in accuracy per epoch in comparison.
There is little to no speedup due to FFCV on RTXA6000 GPU.

For some context

Dataset was generated using the ffcv-imagenet repository and the standard parameters of 500, 0.50, 90. I have provided the dataloader object I have created below to note if there is any issue.
Every other component is exactly the same for the two runs
In the first epoch of FFCV the time is 38 minutes per epoch, and this does no improve at all. With a PyTorch DataLoader timing is 41 minutes per epoch, barely noticeable.
The training was taking place in FP32.

class FFCVImageNet:
    def __init__(self, args):
        super(FFCVImageNet, self).__init__()

        data_root = '../imagenet-data/'

        IMAGENET_MEAN = np.array([0.485, 0.456, 0.406]) * 255
        IMAGENET_STD = np.array([0.229, 0.224, 0.225]) * 255
        DEFAULT_CROP_RATIO = 224/256
        train_image_pipeline = [RandomResizedCropRGBImageDecoder((224, 224)),
                            RandomHorizontalFlip(),
                            ToTensor(),
                            ToDevice(torch.device('cuda:0'), non_blocking=True),
                            ToTorchImage(),
                            NormalizeImage(IMAGENET_MEAN, IMAGENET_STD, np.float32)]

        val_image_pipeline = [CenterCropRGBImageDecoder((256, 256), ratio=DEFAULT_CROP_RATIO),
                              ToTensor(),
                              ToDevice(torch.device('cuda:0'), non_blocking=True),
                              ToTorchImage(),
                              NormalizeImage(IMAGENET_MEAN, IMAGENET_STD, np.float32)]

        label_pipeline = [IntDecoder(),
                            ToTensor(),
                            Squeeze(),
                            ToDevice(torch.device('cuda:0'), non_blocking=True)]

        self.train_loader = Loader(data_root + 'train_500_0.50_90.ffcv',
                              batch_size  = args.batch_size,
                              num_workers = args.workers,
                              order       = OrderOption.QUASI_RANDOM,
                              os_cache    = True,
                              drop_last   = True,
                              pipelines   = { 'image' : train_image_pipeline,
                                              'label' : label_pipeline},
                              )

        self.val_loader = Loader(data_root + 'val_500_0.50_90.ffcv',
                            batch_size  = args.batch_size,
                            num_workers = args.workers,
                            order       = OrderOption.SEQUENTIAL,
                            drop_last   = False,
                            pipelines   = { 'image' : val_image_pipeline,
                                            'label' : label_pipeline},
                            )

As you can see above, the performance is far worse when FFCV is used.
Would appreciate any insight into why this is happening and what could be done to improve.
Thanks!

Hi @SreeHarshaNelaturu ! What training code are you using?

Hi @andrewilyas thanks for the prompt response. This a custom harness we wrote on our own for training + pruning networks. Could you let me know any specific aspects I could send across?
Btw, I found one interesting result that seems to have fixed the problem almost -- that is adding "shuffled_indices=True" while regenerating the beton.
The loss/accuracy curves now look like this

Blue - FFCV (w/o shuffle_indices = True while creating the beton)
Orange - PyTorch DataLoader
maroon - FFCV (w/ shuffle indices = True while creating the beton)
Hope this could help people out, I think this is related to usage of OrderOption.QUASI_RANDOM as indicated in issue #304 .
Regarding speed-up
I also tested this on the CelebA dataset, and could provide code to reproduce -- there was little or no speedup achieved due to use of FFCV and there are very little throughput gains using FFCV (38 mins v/s 41 mins) on ImageNet [Device: NVIDIA A6000]
Is this speedup only to be expected on mixed-precision training?
(Please let me know if its better to open a different issue for the speedup related component)
Cheers!


Update version for transcribestreaming with new supported language

New version available:
// https://mvnrepository.com/artifact/software.amazon.awssdk/transcribestreaming
compile group: 'software.amazon.awssdk', name: 'transcribestreaming', version: '2.13.39'

I am closing the issue as transcribestreaming in build file is already upgraded to version 2.16.30 . Feel free to reopen to continue the discussion of anything else comes up with more details.


Fix navbar a11y landmarks

Will fix https://github.com/zopaUK/react-components/issues/684

:tada: This PR is included in version 4.43.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Upgrade version of CherryPy

Fixes #11080
Status
not-tested
Description
Upgrade version of CherryPy only.
Is it backward compatible (if not, which system it affects?)
MAYBE
Related PRs
https://github.com/cms-sw/cmsdist/pull/8032
https://github.com/dmwm/WMCore/pull/11248
External dependencies / deployment changes
https://github.com/cms-sw/cmsdist/pull/8032

@amaltaro this PR only update CherryPy version. Let's see how jenkins will came out.

ok, new build came up clean. The RPMs are ready and correspond to docker approach.

@amaltaro please provide instructions how to trigger WMCore docker build using this set of RPMs, and how to setup private service deployment for testing.

I fear my answer is not going to be satisfying for you, but we are not yet able to fully test these things in the cmsweb-testXXX clusters (Erik had some good progress on this though). So, the only ways to test it would be:
a) deploy services in cmsweb-testbed
b) deploy services in a private VM (but a couple of microservices are no longer functional since a python3 mongodb update).
To test those changes you provided in the cmsdist repository, you can (ideally, one would build things in a private repository before merging things in comp_gcc630):

merge the cmsdist PR, once all the required changes are in place
wait for new RPMs to show up in cmsrep repository (likely something like HG2208d-compX)
deploy this HG tag above

On what concerns the deployment of this on VMs, we have a single script for this or a sequence of steps, all documented here:
https://github.com/dmwm/WMCore/wiki/WMCore-central-services-deployment
Anyways, it looks like you still have to sort out the cryptography dependency update. Once you converge on that, I can help you out with further tests.

This PR may be obsolete if we merge https://github.com/cms-sw/cmsdist/pull/8032 which covers the changes here.

This PR has been superseeded by https://github.com/dmwm/WMCore/pull/11258
Closing this one out.


Update more-comparisons.js

more comparisons

@NOname-awa I don't know any other way to contact you, but I want to ask for your permission if this ported version of your extension can be released on Gandi https://github.com/Gandi-IDE/custom-extension/pull/107

ok, thank you


Delete circle.yml

          1 Warning

:warning:
Please provide a changelog summary in the Pull Request description @KrauseFx

  Generated by :no_entry_sign: Danger


⚠ Bofrost.de has degraded performance

In bdd622c, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1571 ms

Resolved: Bofrost.de performance has improved in 1ffcb8b after 6 minutes.


Visualisation of data after augmentation.

can we view the images generated by data augmentation? if yes then how?

When you create a generator, you can specify a directory where to save the files
datagen = ImageDataGenerator()
generator = datagen.flow_from_directory(
    data_dir,
    target_size=(img_width, img_height),
    batch_size=batch_size,
    save_to_dir='images'
)

@ink1 got it, Thanks.👍😁


(ruka) add prometheus-snmp-exporter

Based on #280

This PR will need to be rebased after #280 is merged.

Rebased after the merge of #280 .


Use GITHUB_ENV instead of set-env

https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

Action and workflow authors who are setting environment variables via stdout should update any usage of the set-env and add-path workflow commands to use the new environment files.

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


Create toast that communicate with serviceWorker

Like:

New version is available, please refresh to update. Click here
This app can works offline dong. Install now
etc

Related with #46


Develop

Codecov Report

Merging #34 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #34   +/-   ##
=======================================
  Coverage   97.82%   97.82%
=======================================
  Files          13       13
  Lines         322      322
=======================================
  Hits          315      315
  Misses          7        7

Continue to review full report at Codecov.

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


Handle BaseException in pytest_exception_interact

When using pytest.raises() and the exception is not raised pytest will raise an exception of the Failed class, which inherits from BaseException, not Exception. This would cause an assertion error when recoding the span, which causes pytest to crash

Awesome, thanks!
We've also seen some problems with traces not being flushed, so we have a fix for that as well coming, probably next week. Just in case you want to wait and potentially include that in the release as well :)

Awesome to hear, please keep them coming!  I don't mind releasing each update individually, I'll get one out soon.

https://pypi.org/project/pytest-opentelemetry/0.6.1/ :tada:


Patch 3

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

It looks like you're working at Microsoft (neerajkh). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@nk773
I'll merge this pull request, but in the future, as a Microsoft employee with changes of this scope, please start using the private repo so we can get validation. Thanks.
Tools/set-up https://github.com/Azure/azure-content/blob/master/contributor-guide/tools-and-setup.md
How to submit a pull request https://github.com/Azure/azure-content/blob/master/contributor-guide/tools-and-setup.md


flutter create -t plugin should not create no-op iOS folders in 1.20.0 stable release

When 1.20 releases, we should make flutter create -t plugin command not creating no-op iOS folders anymore.
Also, we will add a lower flutter SDK bound setting to 1.20.0 for all the newly created plugins.
Ideally, we'd like to land this change to the 1.20.0 release branch as it goes out.

Pending cherry pick at https://github.com/flutter/flutter/pull/62372

@cyanglaz what's your plan for testing this once we have it on-branch (but before we release it as 1.20.0)?

@pcsosinski
We have unit tests covering the "removing no-op ios" folder bit.
For 1.20.0 lower constraint, we will need to add similar unit tests.

Fixed by https://github.com/flutter/flutter/pull/62990


feat: Separate load and play for VideoLoader

@Frosty-J @dasisdormax As you guys have most interacted with it (I think), what's your opinion?

Thanks for your work on this feature.
About the VideoLoader:
I assume this is meant to be used with the libGDX AssetManager? If so, I don't personally need it but I think it will be useful for other users. Please correct me if I'm wrong.
About the separated load and play:
I couldn't do much testing so far, but looking at the code the changes look good to me.
Looking at the pause functions, I noticed that the playRequested flags are set and reset differently between platforms. Without looking in detail, I think this may break the play / pause workaround that I used previously.
I personally am fine with breaking this workaround, as long as we update the README as well.

Thanks for taking a look!

About the VideoLoader

Correct

About the separated load and play

I changed the readme. I might also have fixed your workaroud, but not sure. Can you try and give some feedback if you have time? Especially iOS since I can't test it.

I've not tried this but it looks good. We might want to keep play(FileHandle file) as a method that calls load() and play() to avoid breaking projects without so much as a deprecation warning.


OVDB-15: Enable warnings as errors

Add -Werror flag to strict mode to enable warnings as errors.

As mentioned on the ticket, wrong version of gcc being used for h17, travis isusing 5.4. Should try using 6.3.1, I'm getting warnings with 6.4.


add Dataplanes.create method

@ndr-brt after resolving the conflicts, the tests failed but when I run them locally all the tests succeeded

@chaimaMeliani is failing on my side as well, try to run a ./gradlew clean before, that will force the openapi spec file to be downloaded again

it's because a new counterPartyAddress has been added (that will replace connectorAddress), in the actual EDC they can be used alternatively, but the spec is more strict. Anyway yesterday we had the 0.4.0 release so we can stick to that version instead of using the SNAPSHOT ones (that could change from one day to the other)

@ndr-brt should I open a new PR in which I replace the connectorAddress by the counterPartyAddress in the contractRequest and the transferRequest to resolve the issue ?

@ndr-brt should I open a new PR in which I replace the connectorAddress by the counterPartyAddress in the contractRequest and the transferRequest to resolve the issue ?

it would make more sense to have this separated, maybe you can do that in #58 directly


Fixing peek params for non-cgat-flow repositories

peek_params was using pipeline directory when config was run, irrespective of value of working dir. This doesn't work if the pipeline is not a cgat-flow pipeline and pipeline_genesets is not in the same directory. Need to change operator priority of and and or.
Unfortunately this still doesn't fix the problem that it won't know where to look if workingdir is set to '?!', but its not in the cgat-flow directory.

Hi, sorry not sure if im understanding your problem. Are you able to elaborate in more detail what you are specifically trying to do? Do you have test case?
I am able to run pipelines outside the cgat-flow directory and don't have any issues.

Most pipelines have a peek_params at the start that loads parameters from the genesets pipeline.
To find out where to find the genesets pipeline is, it looks in the pipeline.yml.
When you do pipeline_mypipe.py config, most likely annotations_dir is set to ?!, so the pipeline will not be able to find an annotations dir to get the config from.
These lines in config.py deal with this possibility:
if ("config" in sys.argv or "check" in sys.argv or "clone" in sys.argv and workingdir == "?!"):
        workingdir = os.path.join(get_params()["pipelinedir"],
                                  "pipeline_" + pipeline)

The idea is that if config, check or clone is run, and workingdir is set to ?! (which is the parameter provided to peek_params(workingdir=PARAMS["annotation_dir"]), then the '?!' is overwritten with pipeline_genesets from the same directory as the current pipeline file.
There are two problems with this.
The first is that ("config" in sys.argv or "check" in sys.argv or "clone" in sys.argv and workingdir == "?!") is interpreted as
("config" in sys.argv) or
("check" in sys.argv) or
("clone" in sys.argv and workingdir == "?!")

when we want it interpreted as
("config" in sys.argv or "check" in sys.argv or "clone" in sys.argv) and
(workingdir == "?!")

so in the old formulation, workingdir is only checked if the command is clone, not if it is config or check.  This means that whenever you run config, workingdir is being overwritten with %(pipeinedir)s/pipeline_genesets whatever annotations_dir is set to in %(pipelinedir)s/pipeline.yml.
This is a problem, because if you are developing a pipeline in a directory that does not contain pipeline_genesets, it will cause the an error.
To reproduce this behaviour, create the following new pipeline in a non cgatflow location, say ~/devel/mypipe/pipeline_mypipe.py:
from cgatcore import pipeline as P
from ruffus import originate

PARAMS = P.get_parameters(
    [os.path.join(P.snip(__file__, ".py"), "pipeline.yml"),
    "pipeline.yml"] )

PARAMS.update(P.peek_parameters(
    PARAMS["annotations_dir"],
    "genesets",
    prefix="annotations_",
    update_interface=True,
    restrict_interface=True))

@originate("test")
def dummy(outfile):
    P.touch(outfile)

with a pipeline.yml in ~/mypipe/pipeline_mypipe/pipeline.yml that contains:
annotations:
    dir: PATH_TO_ANNOTATIONS

(with the actual path subbed in) - actually, it doesn't matter what you put here.
Now go to a new directory and run
$ python ~/devel/mypipe/pipeline_mypipe.py config

Changing to the new formulation only solves half the problem though. Under the suggested change config will actually load the annotations interface from the location specified in ~/devel/mypipe/pipeline_mypipe/pipeline.yml, but really, you'd like to not hard code a location there, but put ?!. But if you do this, config will still fall back on trying to load ~/devel/mypipe/pipeline_genesets/pipeline.yml.

Thanks @IanSudbery I get it now. I will attempt to run your example

Hi @IanSudbery , I managed to have a quick look at this. Could all of this not be handled in the PARAMS better by also parameterising the pipeline name? i.e.:
PARAMS.update(P.peek_parameters(
    PARAMS["annotations_dir"],
    "genesets",
    prefix="annotations_",
    update_interface=True,
    restrict_interface=True))

to
PARAMS.update(P.peek_parameters(
    PARAMS["annotations_dir"],
    PARAMS["annotation_pipelinename"],
    prefix="annotations_",
    update_interface=True,
    restrict_interface=True))

Then it wouldn't fallback to using pipeline_genesets?

I don't understand? How is this different? Presumably you would put "genesets" in your template pipeline.yml, and then it would evaluate to the same thing?
I wonder if the real solution is that if you are cloning, or contiging, or checking, you don't actually need to import the config values, so perhaps if clone, config or check is the command and workingdir="?!", then the function should just return without doing anything (perhaps with a warning)?

Maybe I'm reading the code wrong, but the having annotation_dir: ?! still tries to load ~/devel/mypipe/pipeline_genesets/  because the pipeline name is hard coded to genesets? Then you could add warnings that no pipeline name has been set and it returns nothing.
I agree that the solution should be return a warning (or at least a better warning that it returning that it can't find the working directory).

Two things here:
at the moment is doesn't even check what is in annotation_dir most of the
time because the if statement is wrong.
But that aside, the point is that the pipeline name is not the name of
this pipeline, its the name of the external pipeline whose parameters one
wants to import. That extranal pipeline will always be the same for a given
script, irrespective of the fact particular that different runs of the
external pipeline might be required for different runs of the current
script.
Anyway, I think we have a solution? I would code it up, but I'm super busy.
I'll try to remember to do it before Christmas if not one else gets there
first.

To be honest I haven't looked at this in a lot of detail, iv had meningitis last week and still recovering, but I think the solution should work.

Sorry to hear that Adam. Hope you are recovering well. I'll see what I can
do about implementing this.

Just wondering if this needed to be looked at again?

This PR still fixes the problem of the incorrect grouping of conditions. The main fact that peek_parameters will still throw an error if run with a non-cgatflow pipeline remains.
Its sat dormant because we've stopped really using peek_paramters as it just makes pipelines difficult to share as standalone entities.  I suspect that your solution - return nothing, is still the correct one.


Detection emotions with Azure Api Faces

Hello,
in this version, we use Azure API faces detections to scan faces in photo and we display the results like below

How to use :

Take a photo with many people if you want

Select the photo

Click the button "Detect faces" (async process)

See the results

Don't forget to populate your api key...

You should check PR #21 instead. Same code but with all checks passed.

Thanks for completing the challenge! Fill out this form so we can send you the swag! https://aka.ms/cog-svcs-swag


Change the btrfs_noversion check to be automatic

cc @vbatts :heart:

I tested this on Debian Wheezy and Ubuntu Trusty/14.04. :+1:
(I also tested Ubuntu Precise/12.04, and determined that apparently, version 0.19+20100601-3ubuntu3 of btrfs-tools is not greater than 3.8, and is missing basic things like btrfs/ioctl.h, so we just can't even go there.)

Excellent, this totally worked on Windows, too (as in, didn't cause trouble and blow up).

LGTM

LGTM


[BUG] SDKClient execute() fails with NPE

What is the bug?
SDKClient use of execute() implemented in #491 fails with NPE (actions is null) here:
TransportAction<Request, Response> transportAction = actions.get(action);

The root cause is that we incorrectly attempt to access an injected actions map:
// Used by client.execute
@SuppressWarnings("rawtypes")
@Inject
private Map<ActionType, TransportAction> actions;

However, the way Guice handles injection it's by class, and there are no Map.class objects injected (nor should there be).
How can one reproduce the bug?

Run an extension and use the execute() method from SDKClient or SDKRestClient.
Observe REST error response that "actions" is null.

What is the expected behavior?
actions.get(action) returns an instance of a class implementing TransportAction.
Do you have any additional context?
The implementation was ported from NodeClient with this field populated by the initialize() method:
private Map<ActionType, TransportAction> actions;

This code from Node.java was not included in ExtensionsRunner shortly after injection completes, so porting it should fix this bug:
client.initialize(injector.getInstance(new Key<Map<ActionType, TransportAction>>() {}));

A couple things were happening here:

(This bug) Injection wasn't working because SDKClient was instantiated before the injection.  This wasn't seen in the HelloWorld test case because of the initialization order was different.
(Other bugs) The Injector was becoming unreachable due to GC and we were losing reference to all injected objects.


Cleanup autoscaler log statements

Remove the info log lines for autoscaling
Add debug logs for the autoscaler processing and executing of callbacks

@corindwyer +1


contactusplaceholder

Closes
Closes #1132
Description
when we are typing the text was coinciding with what we are typing I changed it.
Screenshots

Note to reviewers

Checklist:

[x] I have linked the PR to the correct issue.
[x] I have read the Contribution Guidelines
[x] I have built and tested the changes, and they do not break or show any errors.

can you please review my pr @Vaishnavi-Patil2211

can you please review my pr @Vaishnavi-Patil2211


Lack of license

Right now the terms on which you share your code are not clear.

I've added a license now.


Simplify metadata fields in combined schemas

We don't support simplification for metadata fields like minItems, minimum, maxLength etc. in combined schemas like anyOf, oneOf, allOf. This issue is a tracker for each missed field.

Number/Integer:

[ ] minimum
[ ] exclusiveMinimum
[ ] maximum
[ ] exclusiveMaximum
[ ] multipleOf

String:

[ ] minLength
[ ] maxLength
[ ] pattern

Array:

[ ] minItems
[ ] maxItems
[ ] uniqueItems

Object:

[ ] minProperties
[ ] maxProperties

All

[ ] examples

Please update if something was not included.

Still relevant

still valid? @jonaslagoni


[Bug] ubuntu: pdebuild is suddenly too slow (+ 25minutes)

Issue Description
pdebuild requires too long time to compile the source code.

more than: 25 minutes

..... Omission .....
dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1)
dpkg-source: warning: source directory 'nnstreamer' is not <sourcepackage>-<upstreamversion> 'nnstreamer-2018.6.15'
dpkg-source: info: using source format '1.0'
dpkg-source: info: building nnstreamer in nnstreamer_2018.6.15.tar.gz <---- Spends too long time.!!!!

Expected Result
The binaries has to be generated within 3minutes (on average).
How to Reproduce
$ time pdebuild
Further Information

Exact OS version: Ubuntu 16.04 LTS x86_64
log message

www-data@AI2Quadro02:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"

www-data@AI2Quadro02:~$ time pdebuild

. . . Omission . . .
dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1)
dpkg-source: warning: source directory 'nnstreamer-github.sec.samsung.net' is not <sourcepackage>-<upstreamversion> 'nnstreamer-2018.6.15'
dpkg-source: info: using source format '1.0'
dpkg-source: info: building nnstreamer in nnstreamer_2018.6.15.tar.gz <----------- TOO SLOW!!!
dpkg-source: info: building nnstreamer in nnstreamer_2018.6.15.dsc
 dpkg-genchanges -S >../nnstreamer_2018.6.15_source.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build nnstreamer-github.sec.samsung.net
dpkg-buildpackage: source-only upload: Debian-native package
I: using fakeroot in build.

. . . Omission . . .

make[2]: Entering directory '/build/nnstreamer-2018.6.15/build'
make[2]: Nothing to be done for 'preinstall'.
make[2]: Leaving directory '/build/nnstreamer-2018.6.15/build'
Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "None"
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/include/nnstreamer/tensor_typedef.h
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/include/nnstreamer/tensor_common.h
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/include/nnstreamer/tensor_filter_custom.h
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/include/nnstreamer/tensor_meta.h
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/pkgconfig/nnstreamer.pc
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libcommon.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_converter.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensor_converterStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_filter.so
-- Set runtime path of "/build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_filter.so" to ""
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_filter_tflitecore.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_filter_tfcore.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensordec.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensordecStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_sink.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensor_sinkStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensormux.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensormuxStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensordemux.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensordemuxStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensorsplit.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensorsplitStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_transform.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensor_transformStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/gstreamer-1.0/libtensor_load.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensor_loadStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libnnstreamer_customfilter_passthrough.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libnnstreamer_customfilter_passthrough_variable.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libnnstreamer_customfilter_scaler.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libnnstreamer_customfilter_scaler_allocator.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libnnstreamer_customfilter_average.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtesttensors.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtesttensorsStatic.a
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensorscheck.so
-- Installing: /build/nnstreamer-2018.6.15/debian/tmp/usr/lib/libtensorscheckStatic.a
make[1]: Leaving directory '/build/nnstreamer-2018.6.15/build'
   dh_install -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_installdocs -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_installchangelogs -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_perl -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_link -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_strip_nondeterminism -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_compress -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_fixperms -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_strip -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_makeshlibs -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_shlibdeps -O--buildsystem=cmake -O--builddirectory=build -O--parallel
dpkg-shlibdeps: warning: debian/nnstreamer/usr/lib/gstreamer-1.0/libtensor_filter_tflitecore.so contains an unresolvable reference to symbol dlsym: it's probably a plugin
dpkg-shlibdeps: warning: 2 other similar warnings have been skipped (use -v to see them all)
dpkg-shlibdeps: warning: couldn't find library libtensor_filter_tflitecore.so needed by debian/nnstreamer/usr/lib/gstreamer-1.0/libtensor_filter.so (ELF format: 'elf64-x86-64'; RPATH: '')
dpkg-shlibdeps: warning: couldn't find library libtensor_filter_tfcore.so needed by debian/nnstreamer/usr/lib/gstreamer-1.0/libtensor_filter.so (ELF format: 'elf64-x86-64'; RPATH: '')
dpkg-shlibdeps: warning: can't extract name and version from library name 'libpywrap_tensorflow_internal.so'
dpkg-shlibdeps: warning: can't extract name and version from library name 'libpywrap_tensorflow_internal.so'
   dh_installdeb -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_gencontrol -O--buildsystem=cmake -O--builddirectory=build -O--parallel
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe
   dh_md5sums -O--buildsystem=cmake -O--builddirectory=build -O--parallel
   dh_builddeb -O--buildsystem=cmake -O--builddirectory=build -O--parallel
dpkg-deb: building package 'nnstreamer' in '../nnstreamer_2018.6.15_amd64.deb'.
dpkg-deb: building package 'nnstreamer-dev' in '../nnstreamer-dev_2018.6.15_amd64.deb'.
 dpkg-genchanges  >../nnstreamer_2018.6.15_amd64.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build nnstreamer-2018.6.15
dpkg-buildpackage: full upload; Debian-native package (full source is included)
I: copying local configuration
I: Copying back the cached apt archive contents
I: unmounting dev/pts filesystem
I: unmounting run/shm filesystem
I: unmounting proc filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build/23020 and its subdirectories
I: Current time: Tue Sep 11 21:26:42 KST 2018
I: pbuilder-time-stamp:<PHONE_NUMBER>

real    25m53.169s
user    25m0.012s
sys     1m13.932s
www-data@AI2Quadro02:~/html/nnstreamer$

When we fork git repository newly, pdebuild is faster than the existing repository.
It's strange. I don't know what happened to the existing nnstreamer git repository. :(
I: Copying back the cached apt archive contents
I: unmounting dev/pts filesystem
I: unmounting run/shm filesystem
I: unmounting proc filesystem
I: cleaning the build env
I: removing directory /var/cache/pbuilder/build/16721 and its subdirectories
I: Current time: Thu Sep 13 11:42:43 KST 2018
I: pbuilder-time-stamp:<PHONE_NUMBER>

real	6m20.911s
user	1m32.384s
sys	0m18.178s

If generating source-archive is taking too much time, try git gc and git clean.

NNStreamer build time summary:
The build time of NNStreamer CI  is as following:

Tizen x86_64 build: 173s (2m)
Tizen armv7l build:  63s (1m)
Ubuntu x86_64 build: 657s (11m) <------- Originally 35m, But now is 11m for paltform package's clean build

pdebuild test on temporal NNStreamer CI server: 14 minutes

[DEBUG] starting 'pdebuild --use-pdebuild-internal' command.
[DEBUG] pdebuild start at :
Thu, 13 Sep 2018 19:49:07 +0900
[DEBUG] pdebuild finished at :
Thu, 13 Sep 2018 20:03:49 +0900

It is sometimes related to a slow network speed.

@ohsewon , PTAL, Please give me your opinion, Could we close this PR?

Yes we can. A new issue will be open when the same problem is occured.


Update MXD HTTP client calls (Postman Collection) to EDC 0.7.0

After DIM is successfully integrated.

Addressed in PR: https://github.com/eclipse-tractusx/tutorial-resources/pull/417


Proposition : use STRING_TYPE instead of NAME_TYPE

Hi,
What would you think about using STRING_TYPE instead of the NAME_TYPE in LivewireTokenParser::parse() ?
This would allow calling components placed in a folder, like Livewire allows you to do (using the dot notation).
This would be a breaking change though, because the current notation would not work anymore. Maybe it is possible to allow both STRING_TYPE and NAME_TYPE, but I'm not sure how...

Hey @kblais, thanks for your proposal. Can you provide an example of an use-case that would open up? And what current cases would be broken by changing the type?
Cheers!

Hey @kblais, thanks for your proposal. Can you provide an example of an use-case that would open up? And what current cases would be broken by changing the type?
Cheers!

Well, imagine you have a component like \App\Http\LiveWire\Table\TextSearchField.
In Blade Livewire, you can call it using <livewire:table.text-search-field> (or, but i'm not sure, with the shortcut @livewire('table.text-search-field')).
With Twig Livewire, you can't call this component using {% livewire table.text-search-field %}, because Twig will throw an ErrorException Unexpected token "punctuation" of value "." ("end of statement block" expected)..
You can't either use {% livewire 'table.text-search-field' %}, because it will throw a new ErrorException Unexpected token "string" of value "tables.userTable" ("name" expected)..
Using STRING_TYPE instead of the NAME_TYPE would force developpers to put ' around the name of the component, like this : {% livewire 'component-name' %}. I've been (quickly) searching if there was an easy way to expect either NAME_TYPE or STRING_TYPE, but couldn't find it...

Well, imagine you have a component like \App\Http\LiveWire\Table\TextSearchField.
In Blade Livewire, you can call it using <livewire:table.text-search-field> (or, but i'm not sure, with the shortcut @livewire('table.text-search-field')).
With Twig Livewire, you can't call this component using {% livewire table.text-search-field %}, because Twig will throw an ErrorException Unexpected token "punctuation" of value "." ("end of statement block" expected)..
You can't either use {% livewire 'table.text-search-field' %}, because it will throw a new ErrorException Unexpected token "string" of value "tables.userTable" ("name" expected)..
Using STRING_TYPE instead of the NAME_TYPE would force developpers to put ' around the name of the component, like this : {% livewire 'component-name' %}. I've been (quickly) searching if there was an easy way to expect either NAME_TYPE or STRING_TYPE, but couldn't find it...

Thanks for the explanation, that makes sense and i think it's a good idea to move to the STRING_TYPE in the future. As it's a breaking change, we can only make this for the v2 release. I'll keep this issue open for now and revisit it for a future release so that we may can combine multiple breaking changes.
PR's to change this with tests are welcome!

Thanks for the explanation, that makes sense and i think it's a good idea to move to the STRING_TYPE in the future. As it's a breaking change, we can only make this for the v2 release. I'll keep this issue open for now and revisit it for a future release so that we may can combine multiple breaking changes.
PR's to change this with tests are welcome!

Supported added with #4

Supported added with #4


IoU only 0.843? How can we achieve 92.37%±0.98 IoU showed in UNet++ paper?

<UNet++: Redesigning Skip Connections to Exploit Multiscale Features in Image Segmentation> shows a high IoU of DSB2018 up to 92.37%.
This repo has any differences? Or do we need some tricks? have you think about it?
Hoping for reply. Thanks

and DSB2018 is a instance-level dataset. Can we just adjust the instance-level mask to a bileval mask?

@LiuFG
I think the main reason is that the environment of the experiment in this repository is different from that of the author. However, the paper doesn't describe the details, so it can't be reproduced... I'd like to know any good ideas.

Can we just adjust the instance-level mask to a bileval mask?
What does bileval mean?

@4uiiurz1
Thank you. I mean Binary mask. just mistak, sorry for that

@LiuFG
I see.

@LiuFG, Can you reproduce the IoU of DSB2018 up to 92.37%？Thank You！
@4uiiurz1 ，Any sugesstions for us to improve the IoU? Thank You!


Simplify manager init function

Hey @Ziinc I have simplified the handle_continue function a bit (e.g. combined operations for requests and URLs). Hopefully, that looks ok to you.

Another problem I am thinking of is that if we have a huge list of links it may be the case that we will block the requests storage with store operations. So it will be almost impossible to do the pop :(. Maybe we should add a small delay to the async operation, just in case, so it's possible to do something with workers?

@Ziinc I have addressed the issues you have pointed out. (Mainly moved all requests back to the handle_continue)


add several Byzantine robust algorithms

add several Byzantine robust algorithms and modify some auxiliary files

This pr is modified from #542


Is ros2-rviz available on android ?

I know there is a ros1 version https://github.com/qiao-tw/rviz-for-android,  Is there any ros2 version for rviz android?

Please open questions like this on https://answers.ros.org, which is our central Question and Answer site.  You'll get a better answer there, and it will be searchable for the future.
Make sure to include a lot of information on what platform you are using, which ROS distribution you are using, and the exact steps you took.


Search

Can Search be added back into the API? I planned on using it for a project but I discovered it was disabled.
Update: If possible, could the last updated API be reenabled again as well?

It's still there use the ?sort=updated and ?keywords=<your search here> instead
Example /shows/1?keywords=Game

Well I need more of an overall search like there previously was

Search works in the same way, it returns pages of 50 results matching the keywords
what do you need it to do? or what was it doing before that its not doing now?

I managed to come up with a solution using the ?keywords=<your search here> option.


Two useful packages

Will it be possible to get 2 AUR packages that I really like as an Arch user?
The first is downgrade to downgrade certain packages when troubleshooting your system. Quite useful to experienced users
The second is arch-update. A great script that doesn't just do normal +Aur +Flatpak updates. It informs about the latest news from Arch Linux, allows you to remove orphaned packages and old packages from the cache. It processes pacnew/pacsave files. And also offers a restart if there has been a kernel update.
For more information: https://github.com/Antiz96/arch-update
Thanks in advance.
Stéphane

those 2 packages are now available on the astromatto repo to be installed. Feel free to add a documentation section on the README @sc74


Students' Class View

Component that's going to be used in student's default view after Authentication. Contains a list of classes they're in and active polling sessions they can join.
Wireframe:

In my opinion, the quick join should not be searchable. The use case for a quick join would be a small group (not a class) who wants to do a quick poll or a series of questions. In that case, it should be private and only accessible to the members in that group, with a code.

Could use a button for adding a new class


Loading 15mb file

objc[56628]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff894d6c90) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x10fd1ccd8). One of the two will be used. Which one is undefined.
It asks me to save the file somewhere but it doesn't display it. It is a mixed binary/ascii file
I am opening files by drag and drop
I also can't edit any files

I came to this result now:
Error opening buffer IoError("stream did not contain valid UTF-8")
thread 'main' panicked at 'not yet implemented: Error handling for open_buffer: IoError("stream did not contain valid UTF-8")', xray_core/src/workspace.rs:205:29
note: Run with RUST_BACKTRACE=1 for a backtrace.
seems to be the answer


Add/Remove Reaction as User

Is it possible to add and remove a reaction as an actual user, instead of as the bot?
I am able to process the reaction_added event and see which user is associated with the reaction, and I'm able to set reactions on existing messages by storing the timestamp and calling client.reactions.add, but any reactions set from the bot just show up as the bot, losing any user association. Additionally, if I try to remove a reaction set on a slack message from slack, from the server through the bot, I get a no_reaction error, presumably because the bot user doesn't match the user that originally added the reaction in slack.
Or is there another way entirely to achieve this? I can imagine there are privacy/security implications of the bot performing actions on your behalf though.

@filmaj ah, hello again! Always reminded how small of a world tech is 😆 I'm working on a new company having absolutely nothing to do with open source mobile dev (😅) and we're building a slack bot for our main product. I'm really loving the Bolt SDK, nice work!
And thank you, that makes sense. Right now I'm exclusively using bot tokens so I'll have to consider if the per-user token experience makes sense for our app. In the meantime I think what might make sense for us is to have reactions be read-only on our web app so at least users can see them but not try to write back to the slack channel given we're not using user tokens at the moment.

@mlynch what kind of experience are you trying to achieve? If you can describe the use case a bit, I can riff of some ideas/UX interactions that I've seen in other apps that may work for your situation.


copy as sql return bad result if the result is sorted

System information:

Operating system (distribution) and version  Windows 11 21H2
DBeaver version     <IP_ADDRESS>205220912
Additional extensions

Connection specification:

Database name and version   5.6.28-cdb2016-log
Driver name   com.mysql.cj.jdbc.Driver  Driver for MySQL 8 and later
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:
copy as sql return bad result if the result is sorted
Steps to reproduce, if exist:
CREATE TABLE `foo` (
  `a` int(10) unsigned NOT NULL DEFAULT '0' ,
  `b` int(10) unsigned NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

insert into foo(a,b)value(1,1001);
insert into foo(a,b)value(2,2001);
insert into foo(a,b)value(3,3001);
insert into foo(a,b)value(4,4001);

# select result
select * from foo;

prepare data for table foo

we click line 3 which value is (3, 3001)and copy as sql will get result INSERT INTO foo (a,b) VALUES (3,3001);
that's ok~
click the button and let a col desc like this

then clien line 3 which value is (2,2001) and copy as sql will get result INSERT INTO foo (a,b) VALUES (3,3001); , actually expect result is INSERT INTO foo (a,b) VALUES (2,2001);

Include any warning/errors/backtraces from the logs

log.log
dbeaver-debug.log

Hello @Heliner,
Thanks for the bug report. As a workaround, you can disable client-side ordering in the preferences.

ths, I will  try it


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v3.3 to before v5.15.11",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3c4d05c8056724aff3abc20650807dd828fded54",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e5d28205bf1de7082d904ed277ceb2db2879e302"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "3c4d05c8056724aff3abc20650807dd828fded54",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "e5d28205bf1de7082d904ed277ceb2db2879e302",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "inet_diag: fix kernel-infoleak for UDP sockets\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15.11 by commit e5d28205bf1de7082d904ed277ceb2db2879e302, it was introduced in version v3.3 by commit 3c4d05c8056724aff3abc20650807dd828fded54. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2021-1002740


collect-info.sh: Collect kube specific info on kubevirt eve

If it is kubevirt type eve, collect the kube specific info we need to help with debugging the issues.

Ah missed that. Will update.

Once the conflict is resolved this can be merged,

Resolved the conflict and committed using web editor

I would add it makes sense to collect
kubectl get all
kubectl get events
kubectl logs - at least for important pods.

I would add it makes sense to collect
kubectl get all
kubectl get events
kubectl logs - at least for important pods.

This is first version. We will keep adding as the testing progresses and we learn more.

Submitted new PR https://github.com/lf-edge/eve/pull/3741 to address the conflicts. I am closing this one. Please approve and merge PR 3741.


contribute-nearcore: add info on ROCKSDB_LIB_DIR and other minor updates

Most notably, add a section about compiling while using rocksdb
library provided by the system.  Based on my observation, this helps
with OOMs.  I think (though I haven’t tested it) that rust-rocksdb
builds rocksdb library with LTO enabled which consumes bunch of
memory.
While at it, make some minor fixes to the document.  Change ‘bash’
preformatted blocks to ‘console’ where the latter is more appropriate
and remove mention of start_localnet.py script which no longer
exists.

largely LGTM.