text:
BIDS Configuration (--bids-filter-file) for fieldmaps not respected

It looks like the specification for the fmap key enlisted in --bids-filter-file isn't used when pulling fmaps for a given BOLD file in init_func_preproc_wf. As a result all fmaps for the target BOLD file are used (even when the are incompatible with eachother, i.e different voxel resolutions) even when the BIDS config specifies that some files should be ignored.
What version of fMRIPrep are you using?
LTS 20.2.0
What kind of installation are you using? Containers (Singularity, Docker), or "bare-metal"?
Singularity
What is the exact command-line you used?
fmriprep /bids /output participant --participant_label $PLABEL \
    --bids-filter-file /resources/bids_configuration/spinecho_select.json \
    --nprocs 36 --omp-nthreads 8  -vv --output-spaces T1w \
    MNI152NLin2009cAsym fsaverage fsaverage5 \
    --bold2t1w-init register --bold2t1w-dof 6  \
    --use-syn-sdc --fs-license-file /license/license.txt

Have you checked that your inputs are BIDS valid?
Yes
The BIDS configuration file spinecho_select.json is configured as:
{
  "fmap": {"datatype": "fmap", "acquisition": null},
  "bold": {"datatype": "func", "suffix": "bold"},
  "sbref": {"datatype": "func", "suffix": "sbref"},
  "flair": {"datatype": "anat", "suffix": "FLAIR"},
  "t2w": {"datatype": "anat", "suffix": "T2w"},
  "t1w": {"datatype": "anat", "suffix": "T1w"},
  "roi": {"datatype": "anat", "suffix": "roi"}
}

I think the problematic line can be found here:
https://github.com/nipreps/fmriprep/blob/c707938e1462e77b1c3a1216a855ceb0aba70845/fmriprep/workflows/bold/base.py#L213-L215
Where fieldmap_wrangler doesn't know about the config.execution.bids_filter spec so it ends up pulling all files under "fmap".
I'd be more than happy to put together a small patch for this either in SDCFlows fieldmap_wrangler or possibly directly following the problematic line!
Let me know if that'd be useful for you, and how you'd like me to proceed!

Thanks for reporting that issue.
So if I understand the bids contains multiple fieldmaps for the same acquisition (ie. multiple IntendedFor), this is uncommon but I see nothing against that in the BIDS specification. I suppose this was meant to offer multiple distortion correction options for the same data.
For the moment pybids.BIDSLayout.get_fieldmaps does not allow specifying additional filters to handle that case.
IMO the best fix would be to modify fmriprep, sdcflows and pybids to pass the additional filters. @oesteban WDYT?
To avoid waiting for these changes to be included in a new release, you can pre-index the BIDS dataset with pybids specifying ignore with regexp(s) for the fieldmaps you want to exclude and then run fmriprep passing the pre-indexed database path to --bids-database-dir.

For the moment pybids.BIDSLayout.get_fieldmaps does not allow specifying additional filters to handle that case.

The new release of SDCFlows will not rely on get_fieldmaps - meaning, we need to come up with different solutions for the LTS and for 20.3+.
In addition, there's bids-standard/bids-specification#622 touching upon this very same issue. I think that, if the PR is finally merged, then PyBIDS will incorporate quite a bit of resources to better handle fieldmaps.
The confluence of both circumstances (the API breaking -or shattering- in SDCFlows and the update of BIDS/PyBIDS on fieldmaps) makes me lean towards marking this issue as wontfix.

Thanks for reporting that issue.
So if I understand the bids contains multiple fieldmaps for the same acquisition (ie. multiple IntendedFor), this is uncommon but I see nothing against that in the BIDS specification. I suppose this was meant to offer multiple distortion correction options for the same data.
For the moment pybids.BIDSLayout.get_fieldmaps does not allow specifying additional filters to handle that case.
IMO the best fix would be to modify fmriprep, sdcflows and pybids to pass the additional filters. @oesteban WDYT?
To avoid waiting for these changes to be included in a new release, you can pre-index the BIDS dataset with pybids specifying ignore with regexp(s) for the fieldmaps you want to exclude and then run fmriprep passing the pre-indexed database path to --bids-database-dir.

That's correct, we're currently running a study which happens to collect both SpinEcho and SBRef to use for distortion correction. We'd want to process the data both ways in order to get an idea of whether we can drop SpinEcho moving forward.
We decided against pre-indexing because we'd want to process the data as it comes in and re-indexing on every run would have been troublesome. However it looks like this isn't as simple as I imagined it would be w/the dependencies complicating the picture - we'll try to make @bpinsard's suggest work for now.
Appreciate you taking the time to look into this!

That's correct, we're currently running a study which happens to collect both SpinEcho and SBRef to use for distortion correction. We'd want to process the data both ways in order to get an idea of whether we can drop SpinEcho moving forward.

Please have a look into bids-standard/bids-specification#622 because I think it will definitely cover your current use-case (meaning, you are acquiring two types of fieldmap estimation approaches). Something interesting for you to look at (and which will only be possible after the big refactor we are making of SDCFlows) is whether you gain accuracy by estimating the fieldmap with both routes and then average the result.
Please note that I'm saying that addressing the problem modifying --bids-filters is not worth the pain for the LTS, in my opinion. That doesn't mean fMRIPrep should not support your use-case. On the contrary, with the new SDCFlows 1.4 I hope that fMRIPrep will soon be able to handle many sources of fieldmaps and combine them meaningfully. But the technical limitations of current settings and the inflexibility of the LTS in regards software dependencies makes this bug something that we might better let just be.

It might be worth it to make a note of this somewhere maybe

As I said, this will be addressed - but probably with a solution very different from --bids-filters

Please have a look into bids-standard/bids-specification#622 because I think it will definitely cover your current use-case (meaning, you are acquiring two types of fieldmap estimation approaches)...

Thanks Oscar! I took a more thorough look at the discussion this time.. i was about to make a comment suggesting allowing for multiple B0FieldSources but you seem to be ahead of me!
Building off that, i understand this is specific to my rather uncommon use-case, but do you foresee pipelines like fMRIPrep/dMRIPrep being able to specify  B0FieldSource identifiers as optional arguments to choose which fieldmap estimation technique to use (i.e if an array of B0FieldSources are spec'd in the side-car and you want to use only 1 of the B0FieldSources)?

Something interesting for you to look at (and which will only be possible after the big refactor we are making of SDCFlows) is whether you gain accuracy by estimating the fieldmap with both routes and then average the result.

This is an intriguing suggestion! I'll keep an eye out for that update to test it on my data when it drops!

Building off that, i understand this is specific to my rather uncommon use-case, but do you foresee pipelines like fMRIPrep/dMRIPrep being able to specify B0FieldSource identifiers as optional arguments to choose which fieldmap estimation technique to use (i.e if an array of B0FieldSources are spec'd in the side-car and you want to use only 1 of the B0FieldSources)?

Yes, I definitely see that tools will need an interface to override the settings of the BIDS dataset. And I think this would be fine and useful oftentimes, IFF the tools also clearly report when and how the user made these customizations - so that the transparency and repeatability of what is done is ensured.

I'll keep an eye out for that update to test it on my data when it drops!

Well, I'm pushing hard - but this is a monster refactor so I can't make any promises.

Is this issue still of interest to anybody here?

@effigies we've worked around this issue on our end! So not pressing for me personally.
I think maybe indicating this behaviour in documentation could be worthwhile if it's not already there?

@effigies - I've just found this issue, since I'm having problems when running fmriprep for a specific session, my filter includes "fmap": {"datatype": "fmap", "session": "1year"}, but I still have fmap directory for other sessions.

@djarecka What version of fMRIPrep are you using? This should be resolved in 22.1.

I've just double checked and I do have the same issue with 21.0.2 and 22.1.0

Could you share your whole filter file?

Oh, I see. We fixed it in sdcflows but haven't hooked it up here.

filter file:
{
  "bold": {
    "datatype": "func",
    "suffix": "bold",
    "session": "baseline",
    "reconstruction": "unco"
  },
  "t1w": {
    "datatype": "anat",
    "suffix": "T1w",
    "session": "baseline"
  },
  "t2w": {
    "datatype": "anat",
    "suffix": "T2w",
    "session": "baseline"
  },
  "fmap": {
    "datatype": "fmap",
    "session": "baseline"
  }
}

in the output:
[10:44][13.87][-20%]djarecka@openmind7:sub-MM273$ tree -L 1 ses-*
ses-1year
└── fmap
ses-baseline
├── anat
├── fmap
└── func

authors: bpinsard djarecka effigies jerdra oesteban

repo: nipreps/fmriprep


text:
SDC is not working on multiple files only

What happened?
Hi, experts
I got the fmriprep results ‘Susceptibility distortion correction: FMB (field map-based) - phase-difference map’ in case I analyzed just one fMRI file.
However, when analyzing three files in the same way, the following error appears:
KeyError: “‘phasediff_fmap0’ is already in mapping”
I don’t know if this config file is the correct way.
These fMRI fieldmap files were gained in Simens and had two magnitude files and one phasediff file.
Below is the explanation in part of the config file.
I put “B0FieldSource”: [“phasediff_fmap0”] in func(rest) section.
Also put “B0FieldIdentifier”: “phasediff_fmap0” in two magnitude sections and one phasediff section.
What command did you use?
fmriprep-docker d:\t15 d:\t15\derivatives --fs-license-file d:\freesurfer.txt

What version of fMRIPrep are you running?
fMRIPrep v24.0.1
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.
RUNNING: docker run --rm -e DOCKER_VERSION_8395080871=27.1.1 -it -v d:\freesurfer.txt:/opt/freesurfer/license.txt:ro -v d:\t15:/data:ro -v d:\t15\derivatives:/out nipreps/fmriprep:24.0.1 /data /out participant
bids-validator@1.14.6
(node:9) Warning: Closing directory handle on garbage collection
(Use `node --trace-warnings ...` to show where the warning was created)
        1: [WARN] 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. (code: 102 - TOO_FEW_AUTHORS)

        Please visit https://neurostars.org/search?q=TOO_FEW_AUTHORS for existing conversations about this issue.

        2: [WARN] The Name field of dataset_description.json is present but empty of visible characters. (code: 115 - EMPTY_DATASET_NAME)

        Please visit https://neurostars.org/search?q=EMPTY_DATASET_NAME for existing conversations about this issue.

        Summary:                  Available Tasks:        Available Modalities:
        41 Files, 415.49MB        rest                    MRI
        3 - Subjects
        1 - Session

        If you have any questions, please post on https://neurostars.org/tags/bids.
240824-16:21:18,689 nipype.workflow IMPORTANT:
         Running fMRIPrep version 24.0.1

         License NOTICE ##################################################
         fMRIPrep 24.0.1
         Copyright The NiPreps Developers.

         This product includes software developed by
         the NiPreps Community (https://nipreps.org/).

         Portions of this software were developed at the Department of
         Psychology at Stanford University, Stanford, CA, US.

         This software is also distributed as a Docker container image.
         The bootstrapping file for the image ("Dockerfile") is licensed
         under the MIT License.

         This software may be distributed through an add-on package called
         "Docker Wrapper" that is under the BSD 3-clause License.
         #################################################################
240824-16:21:18,708 nipype.workflow IMPORTANT:
         Building fMRIPrep's workflow:
           * BIDS dataset path: /data.
           * Participant list: ['y072', 'y073', 'y074'].
           * Run identifier: 20240824-162111_25609c1e-6e57-4ac0-8ab0-1760c929ab31.
           * Output spaces: MNI152NLin2009cAsym:res-native.
           * Pre-run FreeSurfer's SUBJECTS_DIR: /out/sourcedata/freesurfer.
240824-16:21:19,47 nipype.workflow INFO:
         ANAT Stage 1: Adding template workflow
240824-16:21:19,250 nipype.workflow INFO:
         ANAT Stage 2: Preparing brain extraction workflow
240824-16:21:19,295 nipype.workflow INFO:
         ANAT Stage 3: Preparing segmentation workflow
240824-16:21:19,297 nipype.workflow INFO:
         ANAT Stage 4: Preparing normalization workflow for ['MNI152NLin2009cAsym']
240824-16:21:19,301 nipype.workflow INFO:
         ANAT Stage 5: Preparing surface reconstruction workflow
240824-16:21:19,311 nipype.workflow INFO:
         ANAT Stage 6: Preparing mask refinement workflow
240824-16:21:19,313 nipype.workflow INFO:
         ANAT No T2w images provided - skipping Stage 7
240824-16:21:19,313 nipype.workflow INFO:
         ANAT Stage 8: Creating GIFTI surfaces for ['white', 'pial', 'midthickness', 'sphere_reg', 'sphere']
240824-16:21:19,321 nipype.workflow INFO:
         ANAT Stage 8: Creating GIFTI metrics for ['thickness', 'sulc']
240824-16:21:19,324 nipype.workflow INFO:
         ANAT Stage 8a: Creating cortical ribbon mask
240824-16:21:19,326 nipype.workflow INFO:
         ANAT Stage 9: Creating fsLR registration sphere
240824-16:21:19,328 nipype.workflow INFO:
         ANAT Stage 10: Creating MSM-Sulc registration sphere
240824-16:21:19,424 nipype.workflow INFO:
         B0 field inhomogeneity map will be estimated with the following 1 estimator(s): [<EstimatorType.PHASEDIFF: 3>].
240824-16:21:19,442 nipype.workflow INFO:
         Setting-up fieldmap "phasediff_fmap0" (EstimatorType.PHASEDIFF) with <sub-y072_ses-2_magnitude1.nii, sub-y072_ses-2_magnitude2.nii, sub-y072_ses-2_phasediff.nii>
240824-16:21:19,456 nipype.workflow INFO:
         No single-band-reference found for sub-y072_ses-2_task-rest_run-01_bold.nii.
240824-16:21:19,467 nipype.workflow INFO:
         Stage 1: Adding HMC boldref workflow
240824-16:21:19,470 nipype.workflow INFO:
         Stage 2: Adding motion correction workflow
240824-16:21:19,473 nipype.workflow INFO:
         Stage 3: Adding coregistration boldref workflow
240824-16:21:19,501 nipype.workflow IMPORTANT:
         BOLD series will be slice-timing corrected to an offset of 0.961s.
240824-16:21:19,546 nipype.workflow INFO:
         No single-band-reference found for sub-y072_ses-2_task-rest_run-02_bold.nii.
240824-16:21:19,557 nipype.workflow INFO:
         Stage 1: Adding HMC boldref workflow
240824-16:21:19,559 nipype.workflow INFO:
         Stage 2: Adding motion correction workflow
240824-16:21:19,561 nipype.workflow INFO:
         Stage 3: Adding coregistration boldref workflow
240824-16:21:19,590 nipype.workflow IMPORTANT:
         BOLD series will be slice-timing corrected to an offset of 0.96s.
240824-16:21:19,833 nipype.workflow INFO:
         ANAT Stage 1: Adding template workflow
240824-16:21:19,835 nipype.workflow INFO:
         ANAT Stage 2: Preparing brain extraction workflow
240824-16:21:19,871 nipype.workflow INFO:
         ANAT Stage 3: Preparing segmentation workflow
240824-16:21:19,873 nipype.workflow INFO:
         ANAT Stage 4: Preparing normalization workflow for ['MNI152NLin2009cAsym']
240824-16:21:19,878 nipype.workflow INFO:
         ANAT Stage 5: Preparing surface reconstruction workflow
240824-16:21:19,887 nipype.workflow INFO:
         ANAT Stage 6: Preparing mask refinement workflow
240824-16:21:19,888 nipype.workflow INFO:
         ANAT No T2w images provided - skipping Stage 7
240824-16:21:19,888 nipype.workflow INFO:
         ANAT Stage 8: Creating GIFTI surfaces for ['white', 'pial', 'midthickness', 'sphere_reg', 'sphere']
240824-16:21:19,896 nipype.workflow INFO:
         ANAT Stage 8: Creating GIFTI metrics for ['thickness', 'sulc']
240824-16:21:19,900 nipype.workflow INFO:
         ANAT Stage 8a: Creating cortical ribbon mask
240824-16:21:19,902 nipype.workflow INFO:
         ANAT Stage 9: Creating fsLR registration sphere
240824-16:21:19,903 nipype.workflow INFO:
         ANAT Stage 10: Creating MSM-Sulc registration sphere
Process Process-2:
Traceback (most recent call last):
  File "/opt/conda/envs/fmriprep/lib/python3.11/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/opt/conda/envs/fmriprep/lib/python3.11/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/fmriprep/cli/workflow.py", line 126, in build_workflow
    retval['workflow'] = init_fmriprep_wf()
                         ^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/fmriprep/workflows/base.py", line 94, in init_fmriprep_wf
    single_subject_wf = init_single_subject_wf(subject_id)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/fmriprep/workflows/base.py", line 515, in init_single_subject_wf
    fmap_estimators, estimator_map = map_fieldmap_estimation(
                                     ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/fmriprep/workflows/base.py", line 763, in map_fieldmap_estimation
    fmap_estimators = find_estimators(
                      ^^^^^^^^^^^^^^^^
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/sdcflows/utils/wrangler.py", line 354, in find_estimators
    e = fm.FieldmapEstimation(
        ^^^^^^^^^^^^^^^^^^^^^^
  File "<attrs generated init sdcflows.fieldmaps.FieldmapEstimation>", line 7, in __init__
    self.__attrs_post_init__()
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/sdcflows/fieldmaps.py", line 434, in __attrs_post_init__
    _estimators[self.bids_id] = self.paths()
    ~~~~~~~~~~~^^^^^^^^^^^^^^
  File "/opt/conda/envs/fmriprep/lib/python3.11/site-packages/sdcflows/utils/bimap.py", line 144, in __setitem__
    raise KeyError(
KeyError: "'phasediff_fmap0' is already  in mapping"
fMRIPrep: Please report errors to https://github.com/nipreps/fmriprep/issues

Additional information / screenshots
[dcm2bids] config file
{
"dcm2niixOptions": "-ba n",
"descriptions": [
{
"datatype": "anat",
"suffix": "T1w",
"criteria": {
"SeriesDescription": "t1*",
"EchoTime": 0.00236,
"RepetitionTime": 2.3
},
"sidecar_changes": {
"ProtocolName": "T1"
}
},
{
"datatype": "anat",
"suffix": "FLAIR",
"criteria": {
"SeriesDescription": "t2*",
"EchoTime": 0.093,
"RepetitionTime": 9
},
"sidecar_changes": {
"ProtocolName": "FLAIR"
}
},
{
"id": "id_task-rest",
"datatype": "func",
"suffix": "bold",
"custom_entities": "task-rest",
"criteria": {
"EchoTime": 0.03,
"RepetitionTime": 2
},
"sidecar_changes": {
"TaskName": "rest",
"B0FieldSource": ["phasediff_fmap0"]
}
},
{
"datatype": "fmap",
"suffix": "magnitude1",
"criteria": {
"ProtocolName": "field_map",
"EchoTime": 0.00492
},
"sidecar_changes": {
"IntendedFor": ["id_task-rest"],
"B0FieldIdentifier": "phasediff_fmap0"
}
},
{
"datatype": "fmap",
"suffix": "magnitude2",
"criteria": {
"ProtocolName": "field_map",
"EchoTime": 0.00738,
"ImageType": ["ORIGINAL", "PRIMARY", "M", "ND"]
},
"sidecar_changes": {
"IntendedFor": "id_task-rest",
"B0FieldIdentifier": "phasediff_fmap0"
}
},
{
"datatype": "fmap",
"suffix": "phasediff",
"criteria": {
"ProtocolName": "field_map",
"EchoTime": 0.00738,
"ImageType": ["ORIGINAL", "PRIMARY", "P", "ND", "PHASE"]
},
"sidecar_changes": {
"IntendedFor": ["id_task-rest"],
"B0FieldIdentifier": "phasediff_fmap0"
}
}
]
}

Duplicate of https://github.com/nipreps/sdcflows/issues/455

source: gharchive/issue

authors: effigies sognoe

license_type: permissive

license_source: github-api


text:
svn2git fails if branch contains shell special characters

Running svn2git --rebase on a previously converted repository of http://antville.googlecode.com/svn shows the following output:
Switched to branch 'Juliette'
sh: Syntax error: "(" unexpected
sh: Syntax error: "(" unexpected
Switched to branch 'antville_1_0'
...
Switched to branch 'master'
Counting objects: 29403, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7614/7614), done.
Writing objects: 100% (29403/29403), done.
Total 29403 (delta 21404), reused 29403 (delta 21404)

As far as I can see there is a branch juliette but not Juliette (with upper-case J).
What could be the reason for the Syntax error? Obviously the command itself does not fail, so can I ignore this?

this happens if a svn-branch has a "(" in the name. This can be solved if the commands "git branch --track..." and "git checkout..." are "("-saved.
line 234-247:
svn_branches.each do |branch|
branch = branch.gsub(/^svn//,'').strip
if @options[:rebase] && (@local.include?(branch) || branch == 'trunk')
lbranch = branch
lbranch = 'master' if branch == 'trunk'
run_command("git checkout -f "#{lbranch}"")
run_command("git rebase remotes/svn/#{branch}")
next
end
    next if branch == 'trunk' || @local.include?(branch)
    run_command("git branch --track \"#{branch}\" \"remotes/svn/#{branch}\"")
    run_command("git checkout \"#{branch}\"")
  end

I almost completely missed this.  In the future, please issue a pull request when you have a patch.  It makes it a lot easier to keep track of things (and give proper attribution when merged).

Will do (pull requests).
Thanks a lot!

authors: nirvdrum p3k sleicht

license: mit

license_source: bigquery


text:
Port POI patches

POI patches:

bug 60260: parse unicode sheet names
bug 60601: unset hyperlinks after removing them individually from the DOM
bug 60601: allow SXSSFITestDataProvider.writeOutAndReadBack(Workbook wb) to work on SXSSFWorkbooks and XSSFWorkbooks
bug 60601: hyperlinks have to be removed one by one to avoid other errors
bug 60601: unlink hyperlinks from a sheet if all hyperlinks have been removed. Patch from Joachim Piketz
refactor duplicated code in TestXSSFSheet#setColumnGroupCollapsed; remove unnecessary int to short casts

Since #1329 merge, there are some conflicts in TestXSSFSheet.cs. Can you help resolve the conflicts? I'm not so familar with the group column logic

There are two functions IsSetHyperlinks and IsSetHyperLinks in class CT_Worksheet. They have the same function。And IsSetHyperLinks is never used, so remove it.

What's the plan for TestSetColumnGroupCollapsed? I think @artem-iron has made it work. Has any bug been ported from POI 3.16?

I think it's due to outdated code implementation of XSSFSheet.GroupColumn and XSSFSheet.SetColumnGroupCollapsed. It is completely different from POI 3.16, I tried porting it, but it would cause some other test cases to fail.
I plan to start porting after completing POI 3.16.

@antony-liu I don't see you changed any code about TestSetColumnGroupCollapsed in the file changes. Is it caused by the incorrect merge? Can we follow Artem's implementation? At least, his changes don't break the unit test.

The merge is wrong. You should not remove the Assert code from Artem.
Can you rollback and remerge? And then re-enable TestSetColumnGroupCollapsed test

OK. I have reverted it, and enabled the test TestSetColumnGroupCollapsed.
The commit https://github.com/nissl-lab/npoi/pull/1434/commits/1ade0af094a6969b94480099c912fb2bf5cbf6e4 change code of TestSetColumnGroupCollapsed. But it is not compatible with method XSSFSheet.GroupColumn and XSSFSheet.SetColumnGroupCollapsed.

LGTM

source: gharchive/pull-request

authors: antony-liu tonyqus

repo: nissl-lab/npoi


text:
Fix typescript types

Fix of the issue mentioned in #68 - the main Typescript API is broken, stating description instead of descriptions.

Please, create a tag for this fix.

authors: RafalBDS matheusrufca


text:
mongodb: allow client to set skip and limit when calling find

Signed-off-by: Alexandre Terrasa alexandre@moz-code.org

+1

+1

authors: BlackMinou Morriar privat

repo: nitlang/nit


text:
404ページを追加 #26

close #26

@tadaren
リリースブランチに向けて

authors: NAKNAO-nnct tadaren

license: MIT


text:
feat: add support for telemetry

part of https://github.com/nitrictech/nitric/issues/329

Codecov Report
Base: 28.51% // Head: 28.51% // Decreases project coverage by -0.00% :warning:

Coverage data is based on head (141fc10) compared to base (013a174).
Patch coverage: 37.77% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #385      +/-   ##
===========================================
- Coverage    28.51%   28.51%   -0.01%
===========================================
  Files           53       53
  Lines         4681     4797     +116
===========================================
+ Hits          1335     1368      +33
- Misses        3222     3301      +79
- Partials       124      128       +4

Flag
Coverage Δ

unittests
28.51% <37.77%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/project/container_helper.go
61.53% <0.00%> (-11.19%)
:arrow_down:

pkg/project/function_helpers.go
40.00% <0.00%> (-3.48%)
:arrow_down:

pkg/project/types.go
8.76% <ø> (ø)

pkg/provider/pulumi/azure/azure.go
5.68% <0.00%> (-0.07%)
:arrow_down:

pkg/provider/pulumi/common/image.go
0.00% <0.00%> (ø)

pkg/provider/pulumi/gcp/project.go
75.67% <ø> (ø)

pkg/runtime/types.go
85.71% <ø> (ø)

pkg/runtime/wrapper.go
11.95% <17.18%> (+11.95%)
:arrow_up:

pkg/provider/pulumi/gcp/gcp.go
39.81% <42.85%> (-1.40%)
:arrow_down:

pkg/provider/pulumi/aws/aws.go
48.05% <57.14%> (-1.11%)
:arrow_down:

... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

either first should be fine.

authors: asalkeld codecov-commenter

repo: nitrictech/cli


text:
flake interface: source, projectRoot vs relPath are confusing.

Nowadays we have three points where you can configure source paths:
This just works fine and doesnt require any more configuration when flake.nix and the node project is in the source of your git repository.
But as soon as you have a nested folder and multiple sub-projects this leads to confusion.
Why do i have 3 different options, also their names are non-intuitive.
I guess source is equal to src in the underlying mkDerivation, so I'd like to keep its name to make that clear.
also projectRoot and relPath seem a little weird to me, didnt understand quite yet what they actually do.
# flake.nix
config.projectRoot = ./website;
source = ./website;

# projects.toml
relPath = "website"

@DavHau  If you are already considering to refactor the flake interface you might take that into account.

I'll close this for now in an effort the keep the list of open issues review-able, but feel free to re-open if you think that it's still confusing in the v1 api draft.

authors: hsjobeki phaer


text:
How can I use this nix snippet?

I'm new to nix so I'm not sure how to add this generated nix package as a dependency into my flake.nix file.
Can you give me some minimal example using this generated nix package? It will be really helpful.

if you run nix flake show at the root of this repo, you will see packages.x86-64_linux.default which you can install from your flake:

add this repo as input of your flake: inputs.luarocks-nix.url = "github:nix-community/luarocks-nix";
somewhere in you config, eg.environment.systemPackages, add this self.inputs.luarocks-nix.packages.x86-64_linux.default

You can also do a nix run github:nix-community/luarocks-nix to launch the program directly

Thank you for your response.
I think I was unclear. I was able to use this program via nix run -p luarocks-nix, and I get nix snippet generated with luarocks nix tree-sitter-http command:
{ buildLuarocksPackage, fetchurl, fetchzip, luaOlder, luarocks-build-treesitter-parser }:
buildLuarocksPackage {
  pname = "tree-sitter-http";
  version = "0.0.31-1";
  knownRockspec = (fetchurl {
    url    = "mirror://luarocks/tree-sitter-http-0.0.31-1.rockspec";
    sha256 = "1kp1n0q1v2nkc8nckgy8wjp71jy5ycskma5s6p01b4x7z8yp6b04";
  }).outPath;
  src = fetchzip {
    url    = "https://github.com/rest-nvim/tree-sitter-http/archive/231f1b1bafd12e46c8ed8c21dbbdd940d9f15e94.zip";
    sha256 = "1k6vj0ml90l0hc3qj05hhkzyrf437cf594dgprsgk99dfyxkpj5b";
  };

  disabled = luaOlder "5.1";
  nativeBuildInputs = [ luarocks-build-treesitter-parser ];

  meta = {
    homepage = "https://github.com/rest-nvim/tree-sitter-http";
    description = "tree-sitter parser for http";
    license.fullName = "UNKNOWN";
  };
}

I'm going to use this generated nix package as a dependency in my project rest.nvim.
But I have no idea how to use this nix snippet (function?) in my project's flake.nix file.

I am a rest.nvim maintainer as well so I am eager to help. Do you want to package rest.nvim for nix in the upstream repo ?
I find using nix for vim plugins cumbersome. I use nix only for a few selected plugins, and https://github.com/nvim-neorocks/rocks.nvim for the rest.

I'm glad you are willing to help with rest.nvim!
I just want to add tree-sitter-http to testing dependency. Not packaging the plugin itself to nix.
Manually testing for both stable & nightly neovim is tedious. So I'm considering using nix like rocks.nvim does in its repo internally.^1
But as tree-sitter-http is not packaged to nix, I can't add it to testing dependency.
I'm coming from this issue.
I opened a draft PR in rest.nvim repo. can you have a look on it?

authors: boltlessengineer teto

repo: nix-community/luarocks-nix


text:
Open VSX 404 error because of lowercased URL

Currently on b2ca2718d4953bc2b41592d2a6b76e3d28236e69 and found that open-vsx.wakatime.vscode-wakatime errors out:
trying https://open-vsx.org/api/wakatime/vscode-wakatime/24.2.0/file/wakatime.vscode-wakatime-24.2.0.vsix
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
^M  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--    0
curl: (22) The requested URL returned error: 404
error: cannot download vscode-wakatime-24.2.0.zip from any mirror

When compared with the correct link:
https://open-vsx.org/api/WakaTime/vscode-wakatime/24.2.0/file/WakaTime.vscode-wakatime-24.2.0.vsix

The difference is that the namespace WakaTime is not lowercased but retains its capitalization. Probably the same is also true for the extension ID, but in this case it's all lowercase.
As a quick workaround, vscode-marketplace.wakatime.vscode-wakatime works fine.

Same issue with open-vsx.editorconfig.editorconfig for which the correct URL is https://open-vsx.org/api/EditorConfig/EditorConfig/0.16.6/file/EditorConfig.EditorConfig-0.16.6.vsix. This also has both namespace and extension ID requiring "proper" capitalization.
I'm currently working around this using nix store add-file to add the manually downloaded (and renamed) files to the nix store.

@Jet132, I now use original names and versions in data/cache/*.json files. This works for me
nix build github:nix-community/nix-vscode-extensions/c4c
7f030776a8092de2f05e339f0cd9a68e40bd8#extensions.x86_64-linux.open-vsx.wakatime.vscode-wakatime

Thank you for the fix, works perfectly :+1: Also for the software in general
One sidenote: would have been nice if you had referenced this issue in the commit to make it easier to find

Fixed somewhere around ef51bab10c57c1bc0838cccab9210e89b7a6bcf9

repo: nix-community/nix-vscode-extensions


text:
Packer failing

Running packer on Windows fails
    virtualbox-iso: building path(s) ‘/nix/store/1yhdxv73pz31xc9qb7184js1m2wzwjjb-sudoers’
    virtualbox-iso: >>> /nix/store/i8534j6r4mhw19aixas5g2ah4r17vx6x-sudoers-in: syntax error near line 18 <<<
    virtualbox-iso: >>> /nix/store/i8534j6r4mhw19aixas5g2ah4r17vx6x-sudoers-in: syntax error near line 24 <<<
    virtualbox-iso: >>> /nix/store/i8534j6r4mhw19aixas5g2ah4r17vx6x-sudoers-in: syntax error near line 25 <<<
    virtualbox-iso: parse error in /nix/store/i8534j6r4mhw19aixas5g2ah4r17vx6x-sudoers-in near line 18
    virtualbox-iso: builder for ‘/nix/store/97d6mb47w9gvy80hiink67x3a0z1cpnx-sudoers.drv’ failed with exit code 1
    virtualbox-iso: cannot build derivation ‘/nix/store/qr9y5na2xr9x655hl3s68g0xf66lm0q1-etc.drv’: 1 dependencies couldn't be built
    virtualbox-iso: building path(s) ‘/nix/store/9cj3shisi6yh1kbhrlgjwl1lcw0hy6d2-users-groups.json’
    virtualbox-iso: cannot build derivation ‘/nix/store/0bs048837g4fippjxb211n9wb5hbxql6-nixos-system-nixbox-17.09.2853.b222a0713f4.drv’: 1 dependencies couldn't be built
    virtualbox-iso: error: build of ‘/nix/store/0bs048837g4fippjxb211n9wb5hbxql6-nixos-system-nixbox-17.09.2853.b222a0713f4.drv’ failed
==> virtualbox-iso: Deregistering and deleting VM...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 100

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Script exited with non-zero exit status: 100

==> Builds finished but no artifacts were created.

maybe try looking at the generated config to see if it contains windows line endings or not. I don't have a Windows machine handy.

Oh that could be an issue. I'll look at that later.

Yeah that's what is going on here. There was a previous issue, #15, which referenced this same log.
Might be worth putting a note in the readme to help users avoid this pitfall as it's pretty hard to tell what's going on when it happens.

authors: Moredread nixy zimbatm

repo: nix-community/nixbox


text:
Implement I/O Safety

Most Nix functions that involve files use RawFd arguments, but those are difficult to use correctly.  For example, it's easy to use-after-close.  Rust nightly just added I/O Safety traits that fix most of the problems with RawFd.  It's a very good fit for Nix. We should begin using them as soon as possible.  They're on track to be released as part of Rust 1.63.0, which will probably be released on 11-August.
https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md

[x] pty (#1921)
[x] sched (#1931)
[x] poll (#1937, #2134)
[ ] unistd
[x] sendfile (#1926)
[x] sys/select(#1940, #2136)
[x] sys/uio (#1931)
[x] sys/termios (#1921)
[x] sys/inotify (#1913)
[x] sys/wait (#1923)
[x] sys/signalfd (#1874)
[x] sys/event (#1943)
[x] sys/statvfs (#1927)
[ ] sys/stat
[ ] sys/signal
[x] sys/statfs (#1919)
[x] sys/epoll (#1882 )
[x] sys/eventfd (#1928)
[ ] sys/aio (#1910)
[x] sys/socket/sockopt (#1915)
[x] sys/timerfd (#1933)
[x] sys/socket/addr (#1915)
[x] sys/socket (#1915)
[x] sys/mman (#1916)
[ ] sys/dir
[x] sys/memfd (#1928)
[ ] sys/fcntl
[x] sys/kmod (#1922)

A tracking issue over at io-lifetimes (crate referenced by the linked RFC) may be of interest.
rustix, a crate similar to nix also implements the new I/O safety traits (via using io-lifetimes) if that's helpful to reference.

I lack the knowledge of how you'd approach this, but the main takeaway from the io-lifetimes tracking issue seems to describe two approaches (with or without the io-lifetimes dependency):

They may require a Minimum Supported Rust Version bump too, though another option is to use io-lifetimes once the change to have it re-export std's types and traits by default lands.

Once bumping MSRV becomes acceptable for the project, you can drop io-lifetimes?

Given that Rust 1.63.0 just dropped and I/O safety is now in the standard library, it might be worth it to bump the MSRV.
If the bump is desired, I can implement the change, moving the input file descriptors to BorrowedFd and the output file descriptors to OwnedFd.

I've got a wip branch changing around half so far of the uses of RawFd to the io-safe versions.

When I/O safety lands on nix, raw file descriptor arguments like  fd: RawFd can be replaced with <F: AsFd>(fd: &F), this will be a really good improvement!

@coolreader18 Mind trying to merge what you've got? I don't see the need to convert everything at once... any progress in this direction is a net improvement IMO.

@asomers I'd be willing to take a crack at this over the weekend assuming there's review bandwidth.

I've been thinking about this some more... what's our backwards compat story? Do we add an io_safety feature that has the new wrappers and deprecate all the old ones? Or do we just pull the plug and make everyone use the new types?
cc @rtzoeller

Since we're pre-1.0, we don't technically have to maintain backwards-compat.  And in the past, we sometimes haven't.  If you were only going to modify one or two functions, I'd say add new methods and deprecate the old ones.  But this change is way too big.  Better to pull the plug all at once, I'd say.

As it's partially a safety concern, I think a break would be justified, as significant as it would be.

Sounds good! Based on discussion over at rustix, I'll need to update my PR to not take fds in by reference. #1862 needs to go through first anyway, so I'll update stuff after that.
Another possibility that's crossed my mind: we could have an extension trait on fds so that you can say fd.read(...). I don't think this is a good idea because it'll be confusing with functions that take in multiple fds, but I wanted to throw it out there.

The extension trait sounds confusing to me, just because it's such a big break from Nix's existing API.

#1874 adds I/O safety to signalfd

@asomers #1863 covers most of unistd, fcntl, and sys/stat but not all since I didn't have the energy to convert weirder syscalls. The easiest way to see what's left will be to search for "RawFd".

Module sys/inotify will be handled in #1913

#1919 adds I/O safety for module sys/statfs

sys/termios and pty will be covered in #1921

Also worth noting that the convention I'm going with is to take fds by value (foo<Fd: AsFd>(fd: Fd)) as per this discussion: https://github.com/bytecodealliance/rustix/issues/446

For the first reason why we should take AsFd by value given by the author of rustix:

This makes it work more like AsRef, which is typically passed by value rather than by reference.

In Nix, we are doing something like:
fn path_related_fn<P: NixPath>(path: &P)

I vote for pass-by-value, unless somebody can come up with a single case where it wouldn't work.  After all, the standard library already provides impl<T: AsFd> AsFd for &T

Then for the PRs that take AsFd by reference and are merged, we need to change them:
#1916
#1919
#1922
#1922

I just updated this tracking issue, looking at those unfinished modules, most of them are in PR #1863, friendly ping @SUPERCILEX, would you like to split the parts that won't involve the design issue (non-xxat functions) to other PRs

@SteveLauC I won't have time to work on this, so I would recommend taking my first commit from that PR (https://github.com/nix-rust/nix/pull/1863/commits/30b32c4b7b2c9be7e74ee504197fec0341cd3854) and resolving the conflicts.

authors: SUPERCILEX SteveLauC asomers coolreader18 notgull polarathene

repo: nix-rust/nix


text:
Add setfsuid and setfsgid implementation for filesystem checks

I noticed that the filesystem checks API setfsuid and setfsgid where missing (while available in libc). This PR adds the implementation for both of them.

According to the man page, those syscalls are obsolete.  Do you have an actual use case for them?  If not, then we should reject this PR in the interest of resisting bloat.

As far as I understand the note you are referring to:

At the time when this system call was introduced, one process could send a signal to another process with the same effective user ID. This meant that if a privileged process changed its effective user ID for the purpose of file permission checking, then it could become vulnerable to receiving signals sent by another (unprivileged) process with the same user ID. The filesystem user ID attribute was thus added to allow a process to change its user ID for the purposes of file permission checking without at the same time becoming vulnerable to receiving unwanted signals. Since Linux 2.0, signal permission handling is different (see kill(2)), with the result that a process can change its effective user ID without being vulnerable to receiving signals from unwanted processes. Thus, setfsuid() is nowadays unneeded and should be avoided in new applications (likewise for setfsgid(2)).

states that setfsuid is not required anymore if the purpose was to protect the process from receiving signals from another process having the same effective UID, while it doesn't say that setfsuid should be avoided in general because obsolete.
I have a specific use case for this, that is I need to be able to check filesystem permissions per thread, and using seteuid would require to lock every thread with write access, not allowing parallel checks (source).

It looks like it failed on nightly the second run (https://travis-ci.org/nix-rust/nix/jobs/656330684?utm_medium=notification&utm_source=github_status), where the first run passed and the only change only included the changelog. Could you please have a look @asomers?

It looks like a new Rust nightly has added some lints.  I'll fix this in a separate PR, then you can rebase.

Actually, it looks like the failures were due to a bug in the compiler.  I just restarted the build, it used a newer compiler version than the previous build (nightly-2020-02-28 vs nightly-2020-02-27), and it passed this time.

Please squash your commits.  Then I'll merge.

That failure happened deep within libstd.  Perhaps a QEMU bug?
bors retry

authors: asomers gliderkite


text:
No longer support Rust 1.1

Since tempdir is broken on Rust 1.1 I propose to push the minimum supported Rust version to 1.2.

@homu r+

:pushpin: Commit 088c9c2 has been approved by posborne

:zap: Test exempted - status

authors: fiveop homu posborne


text:
ld: library not found for -lintl (macOS with Macports)

Since commit 45676e7f836a13c194fb8ab1a53e30b250333f31 I'm receiving an error while compiling cpsm with Python3 support:
(I'm using macOS with Macports, and not Homebrew)
$ PY3=ON ./install.sh

Python 3 selected by PY3=ON
-- The C compiler identification is AppleClang 9.0.0.9000039
-- The CXX compiler identification is AppleClang 9.0.0.9000039
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   program_options
-- Found PythonInterp: /opt/local/bin/python3 (found suitable version "3.6.4", minimum required is "3")
-- Found PythonInterp: /opt/local/bin/python3 (found version "3.6.4")
-- Found PythonConfig: -I/opt/local/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -I/opt/local/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m; -L/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/config-3.6m-darwin -lpython3.6m -lintl -ldl -framework CoreFoundation
-- Found ICU header files in /opt/local/include
-- Found ICU libraries: /opt/local/lib/libicuuc.dylib
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rafi/.cache/vim/dein/repos/github.com/nixprime/cpsm/build
Scanning dependencies of target cpsm_core
[ 11%] Building CXX object CMakeFiles/cpsm_core.dir/src/str_util.cc.o
[ 22%] Linking CXX static library libcpsm_core.a
[ 22%] Built target cpsm_core
Scanning dependencies of target cpsm_cli
[ 33%] Building CXX object CMakeFiles/cpsm_cli.dir/src/cpsm_cli_main.cc.o
[ 44%] Linking CXX executable cpsm_cli
[ 44%] Built target cpsm_cli
Scanning dependencies of target cpsm_py
[ 55%] Building CXX object CMakeFiles/cpsm_py.dir/src/ctrlp_util.cc.o
[ 66%] Building CXX object CMakeFiles/cpsm_py.dir/src/python_extension.cc.o
[ 77%] Linking CXX shared library cpsm_py.so
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [cpsm_py.so] Error 1
make[1]: *** [CMakeFiles/cpsm_py.dir/all] Error 2
make: *** [all] Error 2

I can reproduce this. Still thinking about how to fix it.
python-config is officially recommended over distutils.sysconfig for configuring linking against Python, and the major difference between python-config and the previous distutils.sysconfig-based approach - the addition of $LIBS - was needed to fix #35 by linking against libutil.
In this case, MacPorts links Python against libintl, which is part of gettext, but doesn't put libintl anywhere the system linker will look for it:
$ otool -L /opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/config-3.6m-darwin/libpython3.6.dylib
...
    	/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)

As a workaround you can sudo ln -s /opt/local/lib/libintl.8.dylib /usr/local/lib/libintl.8.dylib.

Thanks for the detailed explanation. I've tried symlinking as a work-around, but still getting the same error unfortunately.

Same issue though I'm using homebrew

It seems my issue was related to using asdf version manager. I tried using homebrew python and the build succeeded.

The issue with pyenv may be fixed in v2.3.2 via adding the Homebrew LDFLAGS.

authors: dnicolson jdsutherland nixprime rafi

repo: nixprime/cpsm


text:
JFrog Bintray

Hi!,
Can you upload the library to Bintray to use it with Gradle?
https://bintray.com/search?query=jpigpio
Best regards,
Javier

That bintray.com is interesting. I've uploaded most recent build from my fork (which is currently in sync with Niel's master) - you can use it until Neil decides to publish it officially :-)

Thank you!
I have added to my build.gradle file but not works.  "The import jpigpio cannot be resolved"
repositories {
// Use 'jcenter' for resolving your dependencies.
// You can declare any Maven/Ivy/file repository here.
jcenter()
mavenLocal()
mavenCentral()
maven {
url  "http://dl.bintray.com/jerady/maven"
url  "http://dl.bintray.com/hansolo/Enzo"
url  "http://dl.bintray.com/jozef/pub-java"
}
}
dependencies {
// The production code uses the SLF4J logging API at compile time
compile 'org.slf4j:slf4j-api:1.7.21'
compile 'com.lynden:GMapsFX:2.0.9'
compile 'eu.hansolo:colors:1.+'
compile 'eu.hansolo:Medusa:4.+'
compile 'de.jensd:fontawesomefx-commons:8.12'
compile 'de.jensd:fontawesomefx-controls:8.12'
compile 'de.jensd:fontawesomefx-fontawesome:4.6.3'
compile 'de.jensd:fontawesomefx-materialicons:2.2.0'
compile 'de.jensd:fontawesomefx-octicons:4.3.0'
compile 'de.jensd:fontawesomefx-icons525:2.6.0'
compile 'de.jensd:fontawesomefx-weathericons:2.0-3'
compile 'de.jensd:shichimifx:1.0.5'
compile 'de.dimaki:refuel:0.0.5'
compile 'org.apache.httpcomponents:httpclient:4.3.6'
compile 'org.controlsfx:controlsfx:8.40.11'
compile 'eu.hansolo.enzo:Enzo:0.3.6'
compile 'jozef:pub-java:JPigpio:1.0.10-js'
This line I made up:
compile 'jozef:pub-java:JPigpio:1.0.10-js'

What would be the correct path?
Best regards

authors: hexagon-robotics sovcik

repo: nkolban/jpigpio


text:
[BUG] The bot is SUPER agressive when it cant hit moonraker

What happened and in what context?
So I was doing updates and I updated telegram to the latest version and that went fine. Then I updated moonraker and it had some issues I had to work through. And while it was down, telegram sent me a message letting me know. It seemed like the messages were at least every 30 seconds, maybe a little faster. It might be a good idea to just limit it to one message when it doesn't connect. Or at least once every 30 minutes or so.
If needed, paste the relevant bot log contents here.
No response
If needed, paste the relevant bot journal contents here.
No response
What branch does this occur on?
master
Reports only on latest master or development branches!

[X] I have updated to latest development/master version before submitting the bug

This is something which definately will need some attention in the next release

Fixed in 2.0.0

repo: nlef/moonraker-telegram-bot


text:
Add ability to pass multiple configs

This change adds the ability to pass mutliple configuration files this is useful for moving common configuration sections to a separate config file. Values are overridden in the order in which the config files are passed with '-c'.

Standby on this. I realized I broke the default case with no '-c' provided

What do you think about includes, akin to how klipper handles it?
We were considering it for some time, but except the two of us, no interest was ever there.

It seems like it could replace a large portion of he secrets handling as well.

We'll put this request on hold then, and look at how to implement the include sections nicely.

Sounds good to me. Thanks!

reimplemented in #269


text:
Save in markdown

It would be great to convert back into markdown before saving in page content.
To respect the Kramdown syntax, it would be done from the content blocks by looking for a markdown=1 attribute next to data-editable.

Implemented with https://github.com/Elephant418/Markdownify .
Tables are not converted, maybe other advanced syntaxes too. But basics are working.

repo: nliautaud/pico-content-editor


text:
Add async API

It would be great if read_pdf supported an async variant so we could await the result. This would allow us to easily perform concurrent work while waiting the multiple seconds the API can take to respond.

Hi @ianschmitz @jzribi3, @fede0bello, @lucacampanella
Ran into the same and submitted #109

authors: hellerphilipp ianschmitz

repo: nlmatics/llmsherpa


text:
Fix 'const' qualifier on bool& has no effect

Disable the to_json overload for std::vector<bool>::reference when std::vector<bool>::reference is the same as basic_json::boolean_t&.
Thanks, @georgthegreat, for pointing out this issue.
Closes #3677.

Coverage remained the same at 100.0% when pulling 3cc06f90971c60fcd1975892ab84f6e218495aae on falbrechtskirchinger:fix-bool-ref into 9e1a7c85e342a5edec6cc3e96087d4070f55bea7 on nlohmann:develop.

Do we have a chance to add a regression test?

Not without external dependencies. And the warning flag seems to be new.

This does not work, unfortunately.
clang12 still issues a warning when he sees const bool&:
include/nlohmann/detail/conversions/to_json.hpp:274:39: error: 'const' qualifier on reference type 'std::vector<bool>::reference' (aka 'bool &') has no effect [-Werror,-Wignored-qualifiers]
inline void to_json(BasicJsonType& j, const std::vector<bool>::reference& b) noexcept

Oh, that's because I made at least one mistake.

Still no
include/nlohmann/detail/conversions/to_json.hpp:272:36: error: 'const' qualifier on reference type 'std::vector<bool>::reference' (aka 'bool &') has no effect [-Werror,-Wignored-qualifiers]
               std::is_convertible<const std::vector<bool>::reference&, typename BasicJsonType::boolean_t>::value
                                   ^~~~~~
include/nlohmann/detail/conversions/to_json.hpp:274:39: error: 'const' qualifier on reference type 'std::vector<bool>::reference' (aka 'bool &') has no effect [-Werror,-Wignored-qualifiers]
inline void to_json(BasicJsonType& j, const std::vector<bool>::reference& b) noexcept

I could try flipping those checks, hoping the compiler short-circuits and doesn't get to the is_convertible check which seems to trigger the earning.

And why const_reference fix proposed #3677 would not work?

In the end, it would still conflict with the existing overload.

One more try. I'm grasping at straws with this one. If it doesn't work, we may just have to suppress the warning for that function.

It looks like the latter version will work for us.
Thanks, @falbrechtskirchinger!

Probably not a bad idea to also do the change from 3677 and use const_reference.

No, that doesn't work. ::reference and ::const_reference are different types. In fact, ::const_reference is bool in stdlibc++.
Assuming my last fix attempt works, I was going to give ::const_reference the same treatment.

I decided against dealing with std::vector<bool>::const_reference for now. Chances are, I'd make matters worse for everyone instead of fixing things for some hypothetical STL.

And it turns out, that libc++ does use a different type for const_reference:
no known conversion from 'std::__1::vector<bool, std::__1::allocator<bool> >::const_reference' (aka '__bit_const_reference<std::__1::vector<bool, std::__1::allocator<bool> > >')

Guess I'll have to add it after all.

Let me walk you through the enable_if constraint:
Since we already have a to_json function for BasicJsonType::boolean_t, we need to disable the vector<bool>::reference/vector<bool>::const_reference overload, if:

vector<bool>::reference is the same as BasicJsonType::boolean_t &, or
vector<bool>::const_reference, stripped of cvref qualifiers, is the same as BasicJsonType::boolean_t.

This covers all tested and reported STLs.

authors: coveralls falbrechtskirchinger georgthegreat gregmarr nlohmann

repo: nlohmann/json


text:
Aimed at the fixing compilation error https://github.com/nlohmann/json/issues/4197. It was a school project, asking me to make contributions. Sorry for the inconvenience I made.

[Describe your pull request here. Please read the text below the line, and make sure you follow the checklist.]

Pull request checklist
Read the Contribution Guidelines for detailed information.

[ ]  Changes are described in the pull request, or an existing issue is referenced.
[ ]  The test suite compiles and runs without error.
[ ]  Code coverage is 100%. Test cases can be added by editing the test suite.
[ ]  The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header files single_include/nlohmann/json.hpp and single_include/nlohmann/json_fwd.hpp. The whole process is described here.

Please don't

The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
Specifically, I am aware of compilation problems with Microsoft Visual Studio (there even is an issue label for this kind of bug). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
Please refrain from proposing changes that would break JSON conformance. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
Please do not open pull requests that address multiple issues.

Aimed at fixing compilation error #4197. It was a school project, asking me to make contributions. Sorry for the inconvenience I made. My work might be completely useless. Sorry for the trouble and inconvenience I made. Feel free to close it.


text:
to/from_json: add a MSVC-specific static_assert to force a stacktrace

Hi,
This PR add a static_assert inside from_json_fn/to_json_fn to help users understand the following message:

could not find to_json in T's namespace

Sometimes Visual Studio does not show the stacktrace, thus making it tricky to know which type is T.
Pull request checklist

[x]  Changes are described in the pull request, or an existing issue is referenced.
[x]  The test suite compiles and runs without error.
[x]  Code coverage is 100%. Test cases can be added by editing the test suite.

Can one of the admins verify this patch?

Can one of the admins kill this bot?

I already reported it at GitHub twice. :-(

Coverage remained the same at 100.0% when pulling c9a02cbc59e9e0bc9bdab96c5ef2e030c79a21a1 on theodelrieu:fix/force_msvc_stacktrace into f4c01601faea6157341481734c6711716dd1c1e8 on nlohmann:develop.

Thanks!

authors: coveralls nlohmann theodelrieu trilogy-service-ro


text:
Github action for authomatically generate a conda package

Hi,
I built a simple automatic pipeline for generating (and uploading) a conda package for the chinese_whispers repository.
The action is activated whenever a new GitHub release is created.
The only step required to set up the script is to create a repository secret (settings->Secrets) named ANACONDA_TOKEN whose value can be obtained at the following URL https://anaconda.org/USERNAME/settings/access (where username is the repository owner username on anaconda.org).
A testing distribution is available here.
Best,
Giulio

Hi, I am happy to see our package available in Anaconda! Unfortunately, we do not have the capacity for maintaining a specific build for it as it requires many third-party actions. I recommend using pip install or deploying to Anaconda from a separate repository that depends on our repository as a submodule updated via Dependabot. Please take my apologies for not accepting your PR.

authors: GiulioRossetti dustalov

repo: nlpub/chinese-whispers-python


text:
status 404 Sorry, this request could not be processed. Please try again later

After run kubectl apply -f deploy\test-claim.yaml, pvc is in pending status.
Log message from pvc shows following
failed to provision volume with StorageClass "freenas-nfs": Error getting dataset "tank" - message: {"error_message":"Sorry, this request could not be processed. Please try again later."}, status: 404

This project is in maintenance mode. If you're just getting started I suggest you head over here: https://github.com/democratic-csi/charts/tree/master/stable/democratic-csi/examples
It's not been fully documented yet but if you want to open an issue over there I'm happy to help out and make sure we get you going.

@nmaupu ok, sorry my friend. DIdn't realize you intended to carry forward with this trying to convert it to csi (it's nearly impossible to implement a 'migration' path FYI without some major headache). I'd recommend starting a new project if you don't want to use democratic-csi.
I can share some gory details sometime if you want to get an idea what you're up against.

It would be possible to create an HTTP only adapter to the other project in theory as well if you wanted to discuss that.
I'd be interested in knowing/understanding the aversion to ssh.

authors: lzhengqc travisghansen

repo: nmaupu/freenas-provisioner


text:
Migrate Record to ValueCastable, from UserValue

This PR migrates Record from being based on UserValue to being based on ValueCastable, clearing the way to deprecate UserValue.
Would close #528 .

Oh, a good addition to this PR would be to rip out every place where Record is treated somehow differently in the middle end and back end. (I don't think we have any in the front end.)

I don't actually see any of those? A grep -R Record nmigen/ shows Record being used in a few places but I only see things of the form isinstance(x, Record) or similar in the RPC server and the compat layer, both of which I'd consider to be special cases.

I don't actually see any of those?

Oh right! We already ripped those out after we migrated it to UserValue.

authors: awygle whitequark

repo: nmigen/nmigen


text:
This should not happen. For some reason the elements is already added

Hi,
Only see it when running nmslib in k8s pod. The same data set(can be shuffled) runs ok locally.
Could you elaborate about the error?

Hi @sh1ng what's exactly the problem? Could you elaborate?

Sorry, looks like multiple threads were adding duplicated.
May be it's worth to make the message more explicit about it.

repo: nmslib/nmslib


text:
nm bond: Support switch between miimon and arp_interval

The linux kernel document suggest no to use miimon with ARP monitoring:
ARP monitoring should not be used in conjunction with miimon.

Hence nmstate will raise NmstateValueError when both miimon and
arp_interval is bigger than zero.
Fix the NM bug on setting 'arp_internal=0' with 'miimon>0':
https://bugzilla.redhat.com/show_bug.cgi?id=1806549

Coverage remained the same at ?% when pulling 5bf61f56952d29d1052be59c747e36f9603e74b9 on cathay4t:miimon into 6a79a8ff0402e8102e231ecb90654f716b5b8a2b on nmstate:master.

@cathay4t this failed the black lint check

@cathay4t this failed the black lint check

Fixed. Thanks.

@cathay4t this failed the black lint check

Fixed. Thanks.

There seems to be still an error.

@cathay4t this failed the black lint check

Fixed. Thanks.

There seems to be still an error.

Forgot to push. Should be OK now.

authors: cathay4t coveralls tyll

repo: nmstate/nmstate


text:
[Util] macro to check string

Add macro to check valid string.
Signed-off-by: Jaeyun jy1210.jung@samsung.com

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #28. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

authors: jaeyun-jung taos-ci

repo: nnstreamer/nnstreamer-edge


text:
Implement get input dimension get output dimension in layernode

implement getInputDimension, getOutputDimension in layer_node

Self evaluation:

Build test: [X]Passed [ ]Failed [ ]Skipped
Run test: [ ]Passed [X]Failed [ ]Skipped

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #1291. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnstreamer.mooo.com/.

:octocat: cibot: @lhs8928, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnstreamer.mooo.com/nntrainer/ci/repo-workers/pr-checker/1291-202106161620280.93528604507446-310a49aa4131078bfe8b81dcdc061283b0599211/.

repo: nnstreamer/nntrainer


text:
[Wait for #1405] [DataSet] Refactor to use properties

[Pending commit: #1405]

[DataSet] Refactor to use properties

This patch enables properties in dataset while changing signature of
dataset

**Self evaluation:**
1. Build test: [X]Passed [ ]Failed [ ]Skipped
2. Run test: [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: Jihoon Lee <jhoon.it.lee@samsung.com>

:octocat: cibot: @zhoonit, nntrainer/dataset/databuffer.cpp does not include Doxygen tags such as @file @brief @author @bug. You must include the Doxygen tags in the source code. Please refer to a Doxygen manual at http://github.com/nnstreamer/TAOS-CI/blob/main/ci/doc/doxygen-documentation.md

authors: taos-ci zhoonit


text:
[wait for #667] [backbone] Support for external backbone

Added support for external backbone with nnstreamer
This is enabled for both ubuntu and Tizen
This patch creates a nnstreamer layer to support running different kind of model files
with nnstreamer single c-api

Commit - 2
Added support for external backbone
Also added a small add.tflite file for unittests
trainable is not supported with external backbones for now
Commit - 3
Update transfer learning application to use backbone
Now feature extractor has been removed from the application
and dependency on tflite is also removed
However, the caching of features from feature extractor is not yet supported.
This results in the application to be slow to run full 1000 epochs on gbs
Till caching is supported, application test from gbs build is removed

Signed-off-by: Parichay Kapoor <pk.kapoor@samsung.com

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #683. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

:octocat: cibot: @kparichay, One of the module of prebuild group is failed. If you want to get a hint to fix this issue, please go to https://github.com/nnstreamer/nntrainer/wiki/.

:octocat: cibot: @kparichay, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/683-202010291546460.79170703887939-f781a05c0e55273ca562c048adcb7ca03d37edbe/.

:octocat: cibot: @kparichay, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/683-202011031031170.090723037719727-7de13fb8e72c4a3d8d1fb1601a662e52c1c1401c/.

:octocat: cibot: @kparichay, One of the module of prebuild group is failed. If you want to get a hint to fix this issue, please go to https://github.com/nnstreamer/nntrainer/wiki/.

:octocat: cibot: @kparichay, One of the module of prebuild group is failed. If you want to get a hint to fix this issue, please go to https://github.com/nnstreamer/nntrainer/wiki/.

authors: kparichay taos-ci


text:
Error running tests....

Have you been able to successfully run the tests using this repo?  I have seen this error a myriad number of times and eventually moved to vue-cli v3 to get around it.  Just curious if you have seen this on your repo
(node:24222) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
webpack: wait until bundle finished:

ERROR in ./src/tests/HelloWebpack.spec.js
Module not found: Error: Can't resolve '../../pages/HelloWebpack.vue' in '/Users/mikee/Documents/code/js/vue/webpack4vue/src/tests'
 @ ./src/tests/HelloWebpack.spec.js 12:20-59
webpack: Failed to compile.

I didn't face any issues when I ran it, but honestly the project was for testing the new webpack version and I didn't give much time to testing. I haven't used this code in a while now, but I'll take a look at it as soon as I get free, and make changes. Most probably it's some module that is old, and needs changes in the test plugins i'd have used.

@mikeerickson Found this issue https://github.com/webpack/webpack/issues/6568
I think upgrading extract-text-webpack-plugin to v4.0.0-beta.0 should fix it. If you have time, I'll be happy to merge a PR.

Hey, @mikeerickson , the path for the module was incorrect. I have pushed the correct one. Check if you have time and let me know.

authors: mikeerickson nnupoor


text:
Create Header

Header
As a user I want to see a relevant heading to the website so that I know where I am.
Description
The Header should be visually clear, maybe not even separated from the rest.
The design can include several options for a slim menu:

Title (including Icon)
Blog
About

TODO

[x] Simple Design (leave as comment)
[ ] Implementation
[ ] Stylesheets

Current Header Design:

repo: noahlehmann/portfolio


text:
关于数据预处理问题

您好！在readme.txt中说是数据集预处理可以参考“Monodepth2"这篇文章的预处理方式，但是我看Monodepth2使用的是Zhou的分割，您使用的是Eigen的分割，请问是需要在数据预处理的时候将"wget -i splits/kitti_archives_to_download.txt -P kitti_data/"中的路径换成这篇文章中的“test_files.txt”吗？

你好，训练使用的是eigen_zhou，测试使用的是eigen， 和Monodepth2一样的。

你好，训练使用的是eigen_zhou，测试使用的是eigen， 和Monodepth2一样的。

好的，谢谢！

authors: noahzn qiaoyaodan

repo: noahzn/Lite-Mono


text:
Refactored getCurrentUser.js and setCookie

Made the export function easier  to read

Matter of fact I just reviewed and pushed the changes @Neztore requested to @nikos467 branch and waiting his approval to merge

No activity and fixed elsewhere


text:
Cannot find v8 debug node-v44-win32-x64\debug.node

Hello I have:
node 0.12.7
node-inspector 0.11.2
npm 2.11.3
i try to debug the boiler plate of electron
I launch $node-inspector, and go on the page localhost:8080?ws=localhost:8080?port=5858
Then i get this error message (before to start electron):
Error: Cannot find module 'c:\Users\adrien\AppData\Roaming\npm\node_modules\node-inspector\node_modules\v8-debug\build\debug\v0.5.0\node-v44-win32-x64\debug.node'
thanks for your help

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/25014149-cannot-find-v8-debug-node-v44-win32-x64-debug-node?utm_campaign=plugin&utm_content=tracker%2F195817&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F195817&utm_medium=issues&utm_source=github).

Please read #649
You can try npm i node-inspector --target=1.6.3
Where 1.6.3 is current version of io.js which used in electron.
But I think this will not be helpful, because there exists unresolved bug in electron or in node.
Anyway keep in mind what each time when you change node major version you need to reinstall node-inspector, because there are some native dependencies (v8-debug, v8-profiler) which needs to be rebuilded.
There is a partially hack to avoid this situation - before each reinstallation, you can save build dir of v8-debud in other place and paste it after reinstallation. This way you'll collect in build folder sources for all expected versions. So, if you'll change node version like 0.10.* -> 0.12.* -> 0.10.* you need to reinstall node-inspector only once.

npm i node-inspector --target=1.6.3 install v43 instead of v44.

repo: node-inspector/node-inspector


text:
Was bitten by "ERROR: CFF: Failed validating charstring set 0"

I updated the opentype.js that powers plumin.js (and prototypo.js, and Prototypo), and then all fonts that we generated couldn't be loaded in the browser.
It took me quite some time to realize that glyphToOps was tweaked some time ago and that an advanceWidth property was now required for every glyph, including .notdef.
I was wondering if opentype.js should throw an error in such case, which would make debugging problematic fonts much easier (the errors reported by the browser, FontForge and even OTS are rather cryptic).

You're absolutely right: we should validate the input data, since there is no useful output data we could generate.
I'll update the bug title to reflect that we want a validation step.

authors: fdb louisremi


text:
Option to omit space between array elements

We like to encode objects and arrays to query parameters using YAML. The parser is able to parse this correctly:

But unfortunately, the dumper always adds unneeded spaces between array elements:

We don't encode [] for prettiness and browsers can handle them fine (PHP has used them forever), but spaces of course do need to be encoded, which is not very pretty.
Here are the options I am currently using to output single line YAML:
yaml.safeDump(value, { flowLevel: 0, indent: 0, lineWidth: Infinity, noCompatMode: true, sortKeys: true })

It would be great to have an option for omitting these non-required spaces / emitting "minimized" YAML.

IMHO that's a madness to use yaml parser/dumper such way :). It's not intended for URL encoding. Goal of dumper is to create pretty human-readable result. May be it creates something close to your wishes... by accident... but that's not enougth to add as official option.
I tend to reject as "out of project scope", but if i miss something important, please explain.

Well, what is the project scope? According to the readme:

This is an implementation of YAML, a human-friendly data serialization language.

Good applications should have readable, human friendly URLs, at the same time complicated applications have complicated data to serialize in the URL. A clear use case for a human-friendly data serialization language.
Basic key=value encoding doesn't fill that need, the data model is too basic. Some applications use styles like array[]=1&array[]=2 to encode nested structures but that bloats quickly and doesn't achieve the goal of good readability.
JSON can encode nested data, but results in bloated output and lots of reserved characters because of the required quotes everywhere.
YAML sits perfectly in-between, supporting all data structures of JSON with the simplicity of basic, unquoted key=value pairs.
It fits directly into the project scope imo. It doesn't create something close to what I want by accident, it creates something close to what I want because what I want (a human friendly yet powerful data serialisation) is exactly what this project offers (a human friendly yet powerful data serialisation) 🙂 .
I understand that you don't want to commit to maintaining a lot of code for rare use cases, but I imagine the implementation and maintenance cost of this to be minimal. There are already great options to control the line breaking behaviour, I don't think an option to omit the added space in this single case (array elements) would hurt.

Ok, PR with condensed flow mode support will be accepted.

Closing to keep tracker clear. But if anyone decide to create PR - that will be accepted.

authors: felixfbecker puzrin

repo: nodeca/js-yaml


text:
Staticman support

Hi,
Thank you for the amazing theme! It is well-designed and equipped with useful features 👏
The theme now only supports Disqus, I wonder if there's any possibilities to use staticman as comment-system in the future?
I tried to modify the current theme following https://gohugohq.com/howto/staticman-hugo-comment-system/ and the repo provided by staticman.
Unfortunately, I cannot make it work...😢
I found that Beautiful Hugo supports staticman, so it may be possible to integrate staticman with Hugo theme.
Disqus is easy-to-use, but I think staticman would be a good alternative for static websites!

I sent a pull request #52 about it. Please have a look if interested.
Thanks!

I can't agree more with the last point you raised.  Staticman is much better than Disqus in terms of SEO.  The search engine finds the whole page with the comments, without the need to ask for a third-party service for the comments.
Storing site comments as YML data allows one to load it in whatever way they want.  This gives the possibility to write math in Markdown in comments.  (for example, my recent PR halogenica/staticman#222)

authors: VincentTam yh-luo

repo: nodejh/hugo-theme-cactus-plus


text:
Release proposal: v5.0.4

This is the same as the #1892 but without the lone apparent semver-major: #1818. See thread in https://github.com/nodejs/node-gyp/issues/1791#issuecomment-535169433 for more discussion on this approach.
Will take advice on what else this needs, I don't have any strong opinions other than "let's get this stuff out".

[f753c167c5] - gyp: decode stdout on Python 3 (cclauss) #1890
[60a4083523] - doc: update xcode install instructions to match Node's BUILDING (Nhan Khong) #1884
[19dbc9ac32] - deps: update tar to 4.4.12 (Matheus Marchini) #1889
[5f3ed92181] - bin: fix the usage instructions (Halit Ogunc) #1888
[aab118edf1] - lib: adding keep-alive header to download requests (Milad Farazmand) #1863
[1186e89326] - lib: ignore non-critical os.userInfo() failures (Rod Vagg) #1835
[785e527c3d] - doc: fix missing argument for setting python path (lagorsse) #1802
[a97615196c] - gyp: rm semicolons (Python != JavaScript) (MattIPv4) #1858
[06019bac24] - gyp: assorted typo fixes (XhmikosR) #1853
[3f4972c1ca] - gyp: use "is" when comparing to None (Vladyslav Burzakovskyy) #1860
[1cb4708073] - src,win: improve unmanaged handling (Peter Sabath) #1852
[5553cd910e] - gyp: improve Windows+Cygwin compatibility (Jose Quijada) #1817
[8bcb1fbb43] - gyp: Python 3 Windows fixes (João Reis) #1843
[2e24d0a326] - test: accept Python 3 in test-find-python.js (João Reis) #1843
[1267b4dc1c] - build: add test run Python 3.7 on macOS (Christian Clauss) #1843
[da1b031aa3] - build: import StringIO on Python 2 and Python 3 (Christian Clauss) #1836
[fa0ed4aa42] - build: more Python 3 compat, replace compile with ast (cclauss) #1820
[18d5c7c9d0] - win,src: update win_delay_load_hook.cc to work with /clr (Ivan Petrovic) #1819

This PR isn't meant to be merged into master, it will establish a v5.x branch that we'll maintain like we do in nodejs/node for as long as we need a v5.x release line to live (as yet undetermined).

hm, I'm not sure why this isn't showing properly, I've only removed that one commit which makes this the only meaningful diff when doing a git diff v5.x master locally:
diff --git a/lib/find-python.js b/lib/find-python.js
index 30bb25f..1a4390d 100644
--- a/lib/find-python.js
+++ b/lib/find-python.js
@@ -19,7 +19,7 @@ PythonFinder.prototype = {
   argsExecutable: [ '-c', 'import sys; print(sys.executable);' ],
   argsVersion: [ '-c', 'import sys; print("%s.%s.%s" % sys.version_info[:3]);' ],
   semverRange: process.env.EXPERIMENTAL_NODE_GYP_PYTHON3 ? '2.7.x || >=3.5.0'
-    : '>=2.7.0 <3.0.0',
+    : '>=2.6.0 <3.0.0',

   // These can be overridden for testing:
   execFile: cp.execFile,

The "files changed" isn't correct, at least according to my diff. I suppose it's because this PR is adding one HEAD commit (changelog and version bump) but removing a commit way back in history, and for some reason it's getting confused?
@cclauss the changes you're commenting on are on master so maybe they need a PR to address them?

@rvagg This LGTM.  @cclauss's comments are addressed in https://github.com/nodejs/node-gyp/pull/1894 -- could you land that, and then cherry-pick it into 5.x? That will fix the known py3 issues (and as for unknown issues, we don't know :-).

done, I suppose I'll push this out then!

Included #1895 too and published as v5.0.4. Closing this PR but this branch, v5.x, will live on as our branch to maintain the v5.x series while we also move on to 6.0.0.

authors: rvagg sam-github

repo: nodejs/node-gyp


text:
N-Meta header added to Connection Manager

Add N-Meta into Connection Manager headers

Wrong branch :)

repo: nodes-ios/NStackSDK


text:
directly create a document from a type

Let's say I have UserTC.  I know i can do UserTC.find({ _id: id }).exec(...).  Can I create a document/record the same way.  Like UserTC.create(req.body).save() ?

Please spesify a little more what you want to do.
Modifications should be put as mutations and not query.
export const RootMutationTC = GQC.rootMutation()

RootMutationTC.addFields({
  createUser: UsersTC.get('$createOne'),
  updateUser: UsersTC.get('$updateById'),
})

const graphqlSchema = GQC.buildSchema()
export default graphqlSchema

@atalebagha if this answers your question, please close the issue 😉

Thanks @stoffern.
Sorry I didn't make myself clear, I wanted to directly create a document within the code, not using a graphql mutation api call.

Ah yes..
Users table
var UsersSchema = new mongoose.Schema({
  firstName: { type: String },
  lastName: { type: String },
  email: { type: String },
}, {collection: 'Users' }
)
export const Users = mongoose.model('Users', UsersSchema)
export const UsersTC = composeMongoose(Users)

where you want to execute code
import {Users} from './Users'

Users.find()
Users.findById()
Users.whatever()..

authors: atalebagha stoffern

repo: nodkz/graphql-compose


text:
app.flowhub.io is not working

Hello.
I was trying to learn noflo within flowhub. Found app.flowhub.io that looks like it's your IDE, hosted on web. That's cool but it's not working right now.
The point is; I'm followiing this link, a step by step guide for a creating "hello world" project on flowhub. I just stuck on the 2nd step under the "Search and add components" title: It says

Search for "alert," then tap prompts/Alert to add that component to your graph

Nope. It's not working. I've looked at console and saw this

The flowhub website is https and noflo website is http. While flowhub is trying to load javascript libraries (framework) from noflo website it encounters this error. Well, you can not use http inside https website. Sorry...
I want to ask "Can you please fix this?", but I won't: since I've checked that It is already hosted with https. Please have a look on this link. Yep, it's interesting that the SSL certificate for the website is created for "*.github.com" and issued by Digicert. You must be rich guys :).
The point is, when I changed the src attribute of iframe seen on the image above from http to https. It's still not working. So can you please have a look on this?

Sorry for that. I've just realized now that this topic is already opened with #543 .

Thanks for reporting! Lets track this it in #543. I've posted a link to the noflojs.org SSL issue there.

authors: jonnor rebulanyum

repo: noflo/noflo-ui


text:
Remove Truncate and OddRange directives

See: https://github.com/noir-lang/noir/pull/635/files
For the change that we want to upstream

Closed by #142

repo: noir-lang/acvm


text:
Next foundry

Description
Added a Next.js Template that uses Foundry instead of hardhat
Problem*
There was no option for a starter template that uses Next.js as a frontend framework and Foundry.
Summary*
This PR adds support and documentation for a noir starter repo that uses both Next.js and Foundry
PR Checklist*

[x] I have tested the changes locally.
[x] I have formatted the changes with Prettier and/or cargo fmt on default settings.

This PR implements https://github.com/noir-lang/noir-starter/pull/56

Sorry @crisgarner for some reason I lost track of this PR. Will merge it now, sorry for the delay (next time please reach out on discord!)

Sorry @crisgarner for some reason I lost track of this PR. Will merge it now, sorry for the delay (next time please reach out on discord!)

haha no worries, I thought it was on some kind of internal revision process🫡

authors: crisgarner signorecello

repo: noir-lang/noir-starter


text:
nargo fmt infinitely prepends plain:: to type name

Aim
Nargo fmt should be idemponent. Running it 2, 3, 4 times should produce the same results as running it once.
Expected Behavior
nargo fmt does not change it's own output
Bug
It infinitely prepends plain:: to type name in this code:
fn strict_if<T>(pred: bool, x: T, y: T) -> T {
    let pred_f = pred as plain::plain::plain::T;
    pred_f * x + (1 - pred_f) * y
}

To Reproduce

https://github.com/vlayer-xyz/plain-repro

Project Impact
Nice-to-have
Impact Context
Sometime we need to write code without generics to avoid this bug
Workaround
Yes
Workaround Description
Don't use generics when this happens
Additional Context
No response
Installation Method
None
Nargo Version
noirc version = 0.26.0+c46b164ce56e6a8f81255fb17eb6539bd040f336
NoirJS Version
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response

Hmm, that's odd. We can take a look but in the meantime you can use a // noir-fmt:ignore comment to disable the formatter on the next line.

authors: LogvinovLeon TomAFrench

repo: noir-lang/noir


text:
Support specifying generics on a type when calling an associated function

We currently do not allow applying a turbofish to a struct type, attempting to do so will result in a UnsupportedTurbofishUsage error
struct Foo<T> {
    x: T
}

impl <T> Foo<T> {
    fn new(x: T) -> Self {
        Foo { x }
    }
}

fn main() {
    let _ = Foo::<i32>::new(1);
}

We should implement support for the turbofish syntax in this situation.

I think this is a duplicate of #5584
I added support for parsing the turbofishes in the middle of paths but implementing this particular case is kind of tricky.

authors: TomAFrench asterite


text:
chore: Add back rebuild script

Description

Problem*

Resolves
Summary*

Documentation

[ ] This PR requires documentation updates when merged.

[ ] I will submit a noir-lang/docs PR.

[ ] I will request for and support Dev Rel's help in documenting this PR.

Additional Context

PR Checklist*

[ ] I have tested the changes locally.
[ ] I have formatted the changes with Prettier and/or cargo fmt on default settings.

I've updated the NOIR_REPO_TOKEN to have PR permissions

I've updated the NOIR_REPO_TOKEN to have PR permissions