Running only functionals

A good option to have would be running FMRIPREP without T1w images under two possible circumstances:

The dataset does not have T1w images
The user set a flag --dismiss-t1w to force dismissing the anatomical processing.

(comes from this discussion)

Which script would be the best place to start with this? I tried changing run.py and just take away the raise exception when "No T1w images found", but then the workflow messed up. Is there a good junction to insert a "skip this part"?

I think your target here would be writing an equivalent to init_single_subject_wf:
https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/base.py#L210-L462
where no anatomical workflows are instantiated and run. Without meaning to discourage you, I must note that this will have a steep learning curve :P. We'll try to help as much as we can, but we can't take this as a priority right now. I can see that in one month this would probably change.

In run.py, there's an --anat-only option, that you can imitate:
https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L87-L88
You could do --func-only or --bold-only or --dismiss-t1w (as @oesteban suggests). Any of these seems fine to me.
That will produce an opts.func_only (or bold_only or dismiss_t1w) that will need to be passed to init_fmriprep_wf:
https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L298-L327
This option will need to be added to the workflows in fmriprep/workflows/base.py, fmriprep/workflows/bold.py, and fmriprep/workflows/confounds.py.
The effects of --anat-only will be easy to mimic in base.py, and I think confounds.py should be pretty easy to pick out the confounds that require anatomical inputs and disable them.
bold.py is going to be the complicated one, as a bunch of subworkflows and connections should only be created if anatomicals are going to be used. You may want to look at how if freesurfer blocks work, as there are workflows that are based on whether or not the user wants to use FreeSurfer.

Cool. I'm trying to puzzle out the bold_reg_wf because i think this is the
place I want to say: "if dismiss_t1w, then do the bold_reg_wf with the mni
brain and not the t1w because it doesn't exist. My confusion comes from
where 't1_brain' is inputted to this workflow. Is there a master function
coordinating the 't1_brain', 'bold_mask', etc things inside the
workflow.connect function?
On Wed, Oct 11, 2017 at 12:50 PM, Chris Markiewicz<EMAIL_ADDRESS>
wrote:

In run.py, there's an --anat-only option, that you can imitate:
https://github.com/poldracklab/fmriprep/blob/
a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L87-L88
You could do --func-only or --bold-only or --dismiss-t1w (as @oesteban
https://github.com/oesteban suggests). Any of these seems fine to me.
That will produce an opts.func_only (or bold_only or dismiss_t1w) that
will need to be passed to init_fmriprep_wf:
https://github.com/poldracklab/fmriprep/blob/
a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L298-L327
This option will need to be added to the workflows in
fmriprep/workflows/base.py, fmriprep/workflows/bold.py, and
fmriprep/workflows/confounds.py.
The effects of --anat-only will be easy to mimic in base.py, and I think
confounds.py should be pretty easy to pick out the confounds that require
anatomical inputs and disable them.
bold.py is going to be the complicated one, as a bunch of subworkflows
and connections should only be created if anatomicals are going to be used.
You may want to look at how if freesurfer blocks work, as there are
workflows that are based on whether or not the user wants to use FreeSurfer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-335927482,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLdNBWQz-ZC3AFWpzyGhTW3MyLklYks5srRv2gaJpZM4P15YA
.

Or rather-- how are the input node fields (such as inputnode.t1_brain)
populated?
On Thu, Oct 12, 2017 at 11:42 AM, Madeleine Snyder <
<EMAIL_ADDRESS>wrote:

Cool. I'm trying to puzzle out the bold_reg_wf because i think this is the
place I want to say: "if dismiss_t1w, then do the bold_reg_wf with the mni
brain and not the t1w because it doesn't exist. My confusion comes from
where 't1_brain' is inputted to this workflow. Is there a master function
coordinating the 't1_brain', 'bold_mask', etc things inside the
workflow.connect function?
On Wed, Oct 11, 2017 at 12:50 PM, Chris Markiewicz <
<EMAIL_ADDRESS>wrote:

In run.py, there's an --anat-only option, that you can imitate:
https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49f
b57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L87-L88
You could do --func-only or --bold-only or --dismiss-t1w (as @oesteban
https://github.com/oesteban suggests). Any of these seems fine to me.
That will produce an opts.func_only (or bold_only or dismiss_t1w) that
will need to be passed to init_fmriprep_wf:
https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49f
b57dd6a4c98155be4a41570bd/fmriprep/cli/run.py#L298-L327
This option will need to be added to the workflows in
fmriprep/workflows/base.py, fmriprep/workflows/bold.py, and
fmriprep/workflows/confounds.py.
The effects of --anat-only will be easy to mimic in base.py, and I think
confounds.py should be pretty easy to pick out the confounds that
require anatomical inputs and disable them.
bold.py is going to be the complicated one, as a bunch of subworkflows
and connections should only be created if anatomicals are going to be used.
You may want to look at how if freesurfer blocks work, as there are
workflows that are based on whether or not the user wants to use FreeSurfer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-335927482,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLdNBWQz-ZC3AFWpzyGhTW3MyLklYks5srRv2gaJpZM4P15YA
.

They are set in by connecting this node:
https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/base.py#L363-L364
to those fields in the top-level workflow, eg.:
https://github.com/poldracklab/fmriprep/blob/a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/base.py#L407-L408
sets the anatomical inputs.

To narrowly answer your question, t1_brain is set in bold_reg_wf in this line:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L353
I will say that registering BOLD to MNI is probably going to be the most difficult thing to attempt in our current setup. bold_reg_wf attempts to find affine transforms using FLIRT or mri_coreg/bbregister, which is then concatenated with a T1-MNI transform found by ANTs (in bold_mni_trans_wf).
If you want to estimate a nonlinear transform directly from BOLD to a template T2w or EPI image, that would probably be best handled by a new sub-workflow that bypasses both bold_reg_wf and bold_mni_trans_wf entirely, rather than repurposing these.

Ok, my intuition is to insert:
if dismiss_t1w:
[new workflow code here]
return workflow
just before line 346 in bold.py
is this on the right track?
On Thu, Oct 12, 2017 at 11:51 AM, Oscar Esteban<EMAIL_ADDRESS>wrote:

They are set in by connecting this node:
https://github.com/poldracklab/fmriprep/blob/
a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/
base.py#L363-L364
to those fields in the top-level workflow, eg.:
https://github.com/poldracklab/fmriprep/blob/
a6fe5500ad2e49fb57dd6a4c98155be4a41570bd/fmriprep/workflows/
base.py#L407-L408
sets the anatomical inputs.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336231746,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLe6hcm7-5ZZkNosV0XqzdK9otguyks5srl_PgaJpZM4P15YA
.

Yes, that's the right direction. The problem, as Chris mentioned, resides on the fact that currently, BOLD workflows depend on anatomical inputs.
Since the anatomical workflows do not depend on BOLD workflows, it was relatively easy to use the approach you mentioned.
So the hard problem here is where you wrote: "[new workflow code here]" because you'll indeed need a new workflow (without dependencies on anatomical) here.

Ok, Really the problem I want to solve is that if there are no T1w images
available for a certain scan, the whole thing won't run at all. I wanted to
create a functional only workflow to solve this problem.
On Thu, Oct 12, 2017 at 12:11 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

Yes, that's the right direction. The problem, as Chris mentioned, resides
on the fact that currently, BOLD workflows depend on anatomical inputs.
Since the anatomical workflows do not depend on BOLD workflows, it was
relatively easy to use the approach you mentioned.
So the hard problem here is where you wrote: "[new workflow code here]"
because you'll indeed need a new workflow (without dependencies on
anatomical) here.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336236987,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLX5iggrHZr1Xxup6ZB_w8UMOzcp9ks5srmR5gaJpZM4P15YA
.

I'll try to pare this down to the minimum things you need to do just to get it running, and we can work from there to build out the remaining needed functionality, such as registration to MNI. Assuming you have a variable dismiss_t1w.
Split this chunk:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L346-L390
Into two bits, to be schematic as possible:
workflow.connect([
    # Only connect workflows that do not require T1w processing
    ])
if not dismiss_t1w:
    workflow.connect([
        # Connect up the rest
        ])

These lines take the following form:
(from_node, to_node, [('from_name', 'to_name')]),

Nodes that do not require T1w preprocessing are:

inputnode, outputnode
bold_reference_wf
bold_stc_wf
bold_hmc_wf
func_reports_wf
summary

For the moment, I would entirely disable fieldmaps by commenting out:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L413-L480
And replace with:
if True:

Comment these lines out, as well:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L487-L489
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L492-L579
Then pacify summary:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L280-L286
by adding the following lines:
if dismiss_t1w:
    summary.inputs.fallback = False
    summary.inputs.confounds_list = []

Finally, disable some reports by commenting out these lines:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L1605-L1612
I think that should technically run. You will get some minimal reports, but no derivatives. If you want BOLD series in their original BOLD space, that will need a new workflow, as will an MNI registration workflow.
Once you have this, start a PR, and we can comment directly on that, which should make things easier.

Wow this a lot to go on thank you so much! I'll start cracking
On Thu, Oct 12, 2017 at 12:35 PM, Chris Markiewicz<EMAIL_ADDRESS>
wrote:

I'll try to pare this down to the minimum things you need to do just to
get it running, and we can work from there to build out the remaining
needed functionality, such as registration to MNI. Assuming you have a
variable dismiss_t1w.
Split this chunk:
https://github.com/poldracklab/fmriprep/blob/
0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/
bold.py#L346-L390
Into two bits, to be schematic as possible:
workflow.connect([
# Only connect workflows that do not require T1w processing
])if not dismiss_t1w:
workflow.connect([
# Connect up the rest
])
These lines take the following form:
(from_node, to_node, [('from_name', 'to_name')]),
Nodes that do not require T1w preprocessing are:

inputnode, outputnode
bold_reference_wf
bold_stc_wf
bold_hmc_wf
func_reports_wf
summary

For the moment, I would entirely disable fieldmaps by commenting out:
https://github.com/poldracklab/fmriprep/blob/
0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/
bold.py#L413-L480
And replace with:
if True:
Comment these lines out, as well:
https://github.com/poldracklab/fmriprep/blob/
0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/
bold.py#L487-L489
https://github.com/poldracklab/fmriprep/blob/
0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/
bold.py#L492-L579
Then pacify summary:
https://github.com/poldracklab/fmriprep/blob/
0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/
bold.py#L280-L286
by adding the following lines:
if dismiss_t1w:
summary.inputs.fallback = False
summary.inputs.confounds_list = []
Finally, disable some reports by commenting out these lines:
https://github.com/poldracklab/fmriprep/blob/
0e2539e0cd472c6e225d73e0c62f91b798131544/fmriprep/workflows/
bold.py#L1605-L1612
I think that should technically run. You will get some minimal reports,
but no derivatives. If you want BOLD series in their original BOLD space,
that will need a new workflow, as will an MNI registration workflow.
Once you have this, start a PR, and we can comment directly on that, which
should make things easier.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336243011,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLfQWWMy2UYv9Fh0KJkkeSqhB_OqTks5srmoMgaJpZM4P15YA
.

I thought of another workaround that might be easier:
Would it be ok to use a dummy T1 dataset as a placeholder to get the
pipeline to run, and have the --output-space be template so that the dummy
T1 isn't used for coregistration? Or would the dummy be automatically used
in other parts of the pipeline even if the output space is "template"?
On Thu, Oct 12, 2017 at 12:41 PM, Madeleine Snyder <
<EMAIL_ADDRESS>wrote:

Wow this a lot to go on thank you so much! I'll start cracking
On Thu, Oct 12, 2017 at 12:35 PM, Chris Markiewicz <
<EMAIL_ADDRESS>wrote:

I'll try to pare this down to the minimum things you need to do just to
get it running, and we can work from there to build out the remaining
needed functionality, such as registration to MNI. Assuming you have a
variable dismiss_t1w.
Split this chunk:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6
e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L346-L390
Into two bits, to be schematic as possible:
workflow.connect([
# Only connect workflows that do not require T1w processing
])if not dismiss_t1w:
workflow.connect([
# Connect up the rest
])
These lines take the following form:
(from_node, to_node, [('from_name', 'to_name')]),
Nodes that do not require T1w preprocessing are:

inputnode, outputnode
bold_reference_wf
bold_stc_wf
bold_hmc_wf
func_reports_wf
summary

For the moment, I would entirely disable fieldmaps by commenting out:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6
e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L413-L480
And replace with:
if True:
Comment these lines out, as well:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6
e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L487-L489
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6
e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L492-L579
Then pacify summary:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6
e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L280-L286
by adding the following lines:
if dismiss_t1w:
summary.inputs.fallback = False
summary.inputs.confounds_list = []
Finally, disable some reports by commenting out these lines:
https://github.com/poldracklab/fmriprep/blob/0e2539e0cd472c6
e225d73e0c62f91b798131544/fmriprep/workflows/bold.py#L1605-L1612
I think that should technically run. You will get some minimal reports,
but no derivatives. If you want BOLD series in their original BOLD space,
that will need a new workflow, as will an MNI registration workflow.
Once you have this, start a PR, and we can comment directly on that,
which should make things easier.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336243011,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLfQWWMy2UYv9Fh0KJkkeSqhB_OqTks5srmoMgaJpZM4P15YA
.

Unfortunately, the BOLD is mapped to MNI through the T1w space :(. I'm afraid that would not work.

Rats ok I'll work on chagning the pipeline then
On Thu, Oct 12, 2017 at 2:52 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

Unfortunately, the BOLD is mapped to MNI through the T1w space :(. I'm
afraid that would not work.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336284129,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLRTS82xKi5m6ZBBQj62cvoIkgLNvks5srooJgaJpZM4P15YA
.

What about directly coregistering the BOLD images to an EPI MNI template?

Would that work? If I put in the EPI MNI template as the dummy?
On Thu, Oct 12, 2017 at 2:55 PM, Chris Filo Gorgolewski <
<EMAIL_ADDRESS>wrote:

What about directly coregistering the BOLD images to an EPI MNI template?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336285228,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLQgS2QCuO0WC29KxDKq5qwQiXoTrks5srorPgaJpZM4P15YA
.

@madeleinesnyder, @chrisfilo both statements from you are the shortest path to the goal.

Sorry, @madeleinesnyder that means that the BOLD is co-registered to some image in MNI space. Probably the T2w image is a good target.

An example of how that is done on mriqc:
https://github.com/poldracklab/mriqc/blob/master/mriqc/workflows/functional.py#L680-L749
However, in this case you will want to use the 'precise' settings set because you don't want a quick and dirty registration.

Ok, so on a broad level:
If no t1 data for a subject:
don't just abort; enter workflow that does epi_mni_align
Which are the parts of the current workflow that are analogs to where I
should insert the epi_mni_align node?
On Thu, Oct 12, 2017 at 3:00 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

An example of how that is done on mriqc:
https://github.com/poldracklab/mriqc/blob/master/
mriqc/workflows/functional.py#L680-L749
However, in this case you will want to use the 'precise' settings set
because you don't want a quick and dirty registration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336286661,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLUCJ3HRCckuIOVTvtaskUNx4FcVsks5srovrgaJpZM4P15YA
.

There are some other workflows you'll probably need. Chris pointed them out before:

bold_reference_wf - generates a reference image in BOLD space, this is probably the reference you will want to use in the registration to MNI space.
bold_stc_wf - slice timing correction
bold_hmc_wf - head motion estimation
func_reports_wf - arranges the reports so they are collated in the final big html file.
summary - creates that summary part for the big html file.

You'll need to use those, plus the epi_mni_align workflow. Finally, we'll point you to the last bit, where the transforms from bold_hmc_wf and epi_mni_align are combined to generate the final _preproc file.

Ok. Should I create a new python script or add all of this to bold.py?
On Thu, Oct 12, 2017 at 3:27 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

There are some other workflows you'll probably need. Chris pointed them
out before:

bold_reference_wf - generates a reference image in BOLD space, this
is probably the reference you will want to use in the registration to MNI
space.
bold_stc_wf - slice timing correction
bold_hmc_wf - head motion estimation
func_reports_wf - arranges the reports so they are collated in the
final big html file.
summary - creates that summary part for the big html file.

You'll need to use those, plus the epi_mni_align workflow. Finally, we'll
point you to the last bit, where the transforms from bold_hmc_wf and
epi_mni_align are combined to generate the final _preproc file.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336294524,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLS1SQijWH4tZpBmDdPXfUt-SCKLCks5srpI3gaJpZM4P15YA
.

Let's start in that bold.py and then we can help you if it grows too large

Ok this amount of change merits inserting the dismiss_t1w flag. Should I
include the following workflows in the dismiss_t1w workflow?:
bold_stc_wf
nonlinear_sdc_wf
bold_mni_trans_wf
bold_surf_wf
Thank you so much, for all of your help, I really appreciate it!
On Thu, Oct 12, 2017 at 3:35 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

Let's start in that bold.py and then we can help you if it grows too large
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336296804,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLcpGY9RwdQySqSSwzOLAuAo3iHthks5srpQWgaJpZM4P15YA
.

I think

bold_stc_wf
nonlinear_sdc_wf
bold_mni_trans_wf

The surf one does not make sense since the surfaces are reconstructed on the T1.

OK cool, and should bold_confounds be included?
On Thu, Oct 12, 2017 at 4:01 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

I think

bold_stc_wf
nonlinear_sdc_wf
bold_mni_trans_wf

The surf one does not make sense since the surfaces are reconstructed on
the T1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336303871,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLdSf-Z6OSf5gynccQJUDEyhWpcYkks5srppfgaJpZM4P15YA
.

Yes, but taking care of not including aCompCor (anatomical Comp Cor)
On Thu, Oct 12, 2017 at 4:09 PM, Maddie Snyder<EMAIL_ADDRESS>wrote:

OK cool, and should bold_confounds be included?
On Thu, Oct 12, 2017 at 4:01 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

I think

bold_stc_wf
nonlinear_sdc_wf
bold_mni_trans_wf

The surf one does not make sense since the surfaces are reconstructed on
the T1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/poldracklab/fmriprep/issues/
755#issuecomment-336303871>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJctLdSf-
Z6OSf5gynccQJUDEyhWpcYkks5srppfgaJpZM4P15YA>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336305649,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkhxv2Qc6jk972Ae23xbuHdMoJucCNLks5srpwxgaJpZM4P15YA
.

Ok I got it working. I'll do a few test data runs and then maybe post it.
On Thu, Oct 12, 2017 at 4:13 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

Yes, but taking care of not including aCompCor (anatomical Comp Cor)
On Thu, Oct 12, 2017 at 4:09 PM, Maddie Snyder<EMAIL_ADDRESS>wrote:

OK cool, and should bold_confounds be included?
On Thu, Oct 12, 2017 at 4:01 PM, Oscar Esteban<EMAIL_ADDRESS>wrote:

I think

bold_stc_wf
nonlinear_sdc_wf
bold_mni_trans_wf

The surf one does not make sense since the surfaces are reconstructed
on
the T1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/poldracklab/fmriprep/issues/
755#issuecomment-336303871>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJctLdSf-
Z6OSf5gynccQJUDEyhWpcYkks5srppfgaJpZM4P15YA>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/poldracklab/fmriprep/issues/
755#issuecomment-336305649>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAkhxv2Qc6jk972Ae23xbuHdMoJucCNLks5srpwxgaJpZM4P15YA>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336306545,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLctoj8IwW6W8k13eBGjYxO3yoe7Nks5srp0ogaJpZM4P15YA
.

I asked around for manage to get this ENIGMA EPI template which seems to be a good candidate for coregistration: https://neurovault.org/images/55594/
@oesteban should we add it to niworkflows?

Seems reasonable to me to add it. There is also just the SPM EPI template that Vince used in the EPInorm paper. Not sure what advantages one has over the other, though.
Also @oesteban nonlinear_sdc_wf depends on the T1 in some pretty unescapable ways. We can do fieldmap correction, but not SyN-SDC, without the T1w images.

Wouldn't constrained nonlinear coregistration to the EPI MNI template work
as a form of SDC?
On Oct 13, 2017 9:43 AM, "Chris Markiewicz"<EMAIL_ADDRESS>wrote:

Seems reasonable to me to add it. There is also just the SPM EPI template
that Vince used in the EPInorm paper. Not sure what advantages one has over
the other, though.
Also @oesteban https://github.com/oesteban nonlinear_sdc_wf depends on
the T1 in some pretty unescapable ways. We can do fieldmap correction, but
not SyN-SDC, without the T1w images.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336327205,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOkp8zRK00Bo2z8a3_qk4LQo4HFEJiIks5srsBQgaJpZM4P15YA
.

Depends on how you built the template and how well the images used were
corrected.
@effigies right, SDC uses the T1
Yes, good addition to niworkflows
On Oct 12, 2017 6:49 PM, "Chris Filo Gorgolewski"<EMAIL_ADDRESS>wrote:

Wouldn't constrained nonlinear coregistration to the EPI MNI template work
as a form of SDC?
On Oct 13, 2017 9:43 AM, "Chris Markiewicz"<EMAIL_ADDRESS>wrote:

Seems reasonable to me to add it. There is also just the SPM EPI template
that Vince used in the EPInorm paper. Not sure what advantages one has
over
the other, though.
Also @oesteban https://github.com/oesteban nonlinear_sdc_wf depends on
the T1 in some pretty unescapable ways. We can do fieldmap correction,
but
not SyN-SDC, without the T1w images.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/poldracklab/fmriprep/issues/
755#issuecomment-336327205>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOkp8zRK00Bo2z8a3_
qk4LQo4HFEJiIks5srsBQgaJpZM4P15YA>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336327881,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkhxib_pemFzeRLNkKji0JQQNogzb2Uks5srsGbgaJpZM4P15YA
.

Certainly if we believe the EPInorm paper, and can figure out the "right" constraints. I'm not worried about trying to combine them; was just responding to an earlier point.

One last bug to fix-- the dismiss-t1 pipeline option is generating the
bold_hmc, bold_reference, func derivatives and func reports, but it isn't
putting an actual preprocessed image under fmriprep/sub-X/func/; which
script is responsible for generating the actual preprocessed functional?
On Thu, Oct 12, 2017 at 6:52 PM, Chris Markiewicz<EMAIL_ADDRESS>wrote:

Certainly if we believe the EPInorm paper, and can figure out the "right"
constraints. I'm not worried about trying to combine them; was just
responding to an earlier point.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336328223,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLTIsxgi0rPjjzPxdEGnB-p3y4M-Hks5srsJIgaJpZM4P15YA
.

The preprocessed functionals are created by bold_reg_wf (registered to T1) and bold_mni_trans_wf (registered to MNI). We don't currently output anything in native BOLD space, and MNI registration right now requires T1.
So it sounds like you've gotten where you can without adding new features. I'd suggest opening a PR and we can see how things look and discuss how to get the outputs you need.

Ok, I just created a new repo (
https://github.com/StanfordCosyne/fmriprep_snyder.git) to compare with
yours. The issue is my code contains a file under cli called
BIDSgenerator.py, which takes the format our data is in and turns it into
BIDS format. It doesn't significantly interact with the pipeline internals
at all though, there are just a few steps added to the beginning of run.py
checking that everything BIDSgenerator was supposed to do is done.
On Mon, Oct 16, 2017 at 11:02 AM, Chris Markiewicz<EMAIL_ADDRESS>
wrote:

The preprocessed functionals are created by bold_reg_wf (registered to
T1) and bold_mni_trans_wf (registered to MNI). We don't currently output
anything in native BOLD space, and MNI registration right now requires T1.
So it sounds like you've gotten where you can without adding new features.
I'd suggest opening a PR and we can see how things look and discuss how to
get the outputs you need.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-336974174,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLZDko29HdfZZ_rSRMKKdGeHEno8Eks5ss5ovgaJpZM4P15YA
.

Hi Maddie; would it be possible for you to fork our repository and copy your relevant changes onto that fork? The advantage to forking is that it makes comparing and ultimately integrating new code much simpler, as the history embedded in git can help distinguish changes made on your end versus changes that we've made since you last checked out our code.
I'll try to walk you through this process, though I may make some wrong assumptions about how things look on your computer. From a quick-ish glance, it looks like you last checked out our code at 1.0.0-rc5. I'm going to assume you have two folders in the same base directory $BASE:

$BASE/fmriprep/ - A clone of a forked fmriprep (e.g. https://github.com/StanfordCosyne/fmriprep.git)
$BASE/fmriprep_synder/ - A clone of your repository (https://github.com/StanfordCosyne/fmriprep_snyder.git)

And I'll assume you're working in fmriprep/, given that's the one that shares history with this repository.
First we need to create an "upstream" remote, which will make sure you have all of the release tags, and help sync with our repository, when needed.
git remote add upstream https://github.com/poldracklab/fmriprep.git
git fetch upstream

You can now checkout the release tagged 1.0.0-rc5 into a new branch called dismiss_t1, and copy the relevant files in:
git checkout -b dismiss_t1 1.0.0-rc5
cp $BASE/fmriprep_snyder/fmriprep/workflows/bold.py fmriprep/workflows/
cp $BASE/fmriprep_snyder/fmriprep/workflows/base.py fmriprep/workflows/
cp $BASE/fmriprep_snyder/fmriprep/cli/run.py fmriprep/cli/

Here, I assumed that workflows/bold.py, workflows.base.py and cli/run.py are the only ones relevant to your PR. If there are others, copy those as well.
Now, if you use git add -p, you'll be able to look at each change that was made, and decide whether it's relevant. This will help you avoid changes related to BIDSgenerator and other lab-specific changes.
Once you've settled on the changes you'd like us to review, you can commit and push your working branch, e.g.:
git commit -m 'ENH: Add --dismiss-t1w option to skip anatomical processing'
git push -u origin dismiss_t1w

Then, if you browse to https://github.com/poldracklab/fmriprep/, then you'll see something like this:

You can then open a new pull request by clicking the "Compare & pull request" button. This will make it much easier for us to give you feedback.
Please let me know if this works for you, and feel free to ask any questions if anything is unclear.
(P.S. I've tried to give fairly specific advice here, which can sometimes leave the "why" context a bit unclear. You may find some more general guidelines useful for getting the hang of the Github workflow.)

ALright I did this but it created a branch on the StanfordCosyne github.
https://github.com/StanfordCosyne/fmriprep
On Mon, Oct 16, 2017 at 12:56 PM, Chris Markiewicz<EMAIL_ADDRESS>
wrote:

Hi Maddie; would it be possible for you to fork our repository and copy
your relevant changes onto that fork? The advantage to forking is that it
makes comparing and ultimately integrating new code much simpler, as the
history embedded in git can help distinguish changes made on your end
versus changes that we've made since you last checked out our code.
I'll try to walk you through this process, though I may make some wrong
assumptions about how things look on your computer. From a quick-ish
glance, it looks like you last checked out our code at 1.0.0-rc5. I'm going
to assume you have two folders in the same base directory $BASE:

$BASE/fmriprep/ - A clone of a forked fmriprep (e.g.
https://github.com/StanfordCosyne/fmriprep.git
https://github.com/StanfordCosyne/fmriprep.git)
$BASE/fmriprep_synder/ - A clone of your repository (
https://github.com/StanfordCosyne/fmriprep_snyder.git
https://github.com/StanfordCosyne/fmriprep_snyder.git)

And I'll assume you're working in fmriprep/, given that's the one that
shares history with this repository.
First we need to create an "upstream" remote, which will make sure you
have all of the release tags, and help sync with our repository, when
needed.
git remote add upstream https://github.com/poldracklab/fmriprep.git
git fetch upstream
You can now checkout the release tagged 1.0.0-rc5 into a new branch
called dismiss_t1, and copy the relevant files in:
git checkout -b dismiss_t1 1.0.0-rc5
cp $BASE/fmriprep_snyder/fmriprep/workflows/bold.py fmriprep/workflows/
cp $BASE/fmriprep_snyder/fmriprep/workflows/base.py fmriprep/workflows/
cp $BASE/fmriprep_snyder/fmriprep/cli/run.py fmriprep/cli/
Here, I assumed that workflows/bold.py, workflows.base.py and cli/run.py
are the only ones relevant to your PR. If there are others, copy those as
well.
Now, if you use git add -p, you'll be able to look at each change that
was made, and decide whether it's relevant. This will help you avoid
changes related to BIDSgenerator and other lab-specific changes.
Once you've settled on the changes you'd like us to review, you can commit
and push your working branch, e.g.:
git commit -m 'ENH: Add --dismiss-t1w option to skip anatomical processing'
git push -u origin dismiss_t1w
Then, if you browse to https://github.com/poldracklab/fmriprep/, then
you'll see something like this:
[image: new_pr]
https://user-images.githubusercontent.com/83442/31631889-2fa7f450-b289-11e7-9e4d-4eda5f592e15.png
You can then open a new pull request by clicking the "Compare & pull
request" button. This will make it much easier for us to give you feedback.
Please let me know if this works for you, and feel free to ask any
questions if anything is unclear.
(P.S. I've tried to give fairly specific advice here, which can sometimes
leave the "why" context a bit unclear. You may find some more general
guidelines
https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution
useful for getting the hang of the Github workflow.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-337018245,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLVOyf2RCpHaO8fptzjq3X6VmC3ztks5ss7UFgaJpZM4P15YA
.

Oh, wow, I'm sorry. I didn't realize there was another repository of that name that isn't a fork of fmriprep. It looks like there's one in StanfordCosyne/fmriprep-1, but you also have one at https://github.com/madeleinesnyder/fmriprep. That might be the easiest one to use.
What I'm about to suggest is going to cross lines between repositories, which may not be the cleanest thing in the long run. It might be best to just clone a new folder:
mkdir tmp/
cd tmp/
git clone git@github.com:madeleinesnyder/fmriprep.git
cd fmriprep/

Then add the StanfordCosyne/fmriprep repostiroy as a remote, which I'll call cosyne:
git remote add cosyne https://github.com/StanfordCosyne/fmriprep.git
git fetch cosyne

Now you'll have access to your dismiss_t1w branch, so we'll just check it out and push it to your fork of fmriprep:
git checkout -t cosyne/dismiss_t1w
git push -u origin dismiss_t1w

If you used a temporary directory, you can now remove it:
cd ../../
rm -r tmp/

Now you should be able to make a pull request.

cool, done.
On Mon, Oct 16, 2017 at 4:54 PM, Chris Markiewicz<EMAIL_ADDRESS>wrote:

Oh, wow, I'm sorry. I didn't realize there was another repository of that
name that isn't a fork of fmriprep. It looks like there's one in
StanfordCosyne/fmriprep-1, but you also have one at https://github.com/
madeleinesnyder/fmriprep. That might be the easiest one to use.
What I'm about to suggest is going to cross lines between repositories,
which may not be the cleanest thing in the long run. It might be best to
just clone a new folder:
mkdir tmp/cd tmp/
git clone git@github.com:madeleinesnyder/fmriprep.gitcd fmriprep/
Then add the StanfordCosyne/fmriprep repostiroy as a remote, which I'll
call cosyne:
git remote add cosyne https://github.com/StanfordCosyne/fmriprep.git
git fetch cosyne
Now you'll have access to your dismiss_t1w branch, so we'll just check it
out and push it to your fork of fmriprep:
git checkout -t cosyne/dismiss_t1w
git push -u origin dismiss_t1w
If you used a temporary directory, you can now remove it:
cd ../../
rm -r tmp/
Now you should be able to make a pull request.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-337077020,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLQ0Z84f3gimwRyYqHqQ88nSZnf-9ks5ss-y9gaJpZM4P15YA
.

Quick question about the new script: I updated all the packages and stuff
but it's still erroring out with:
from niworkflows.interfaces.base import SimpleInterface
even though there doesn't appear to be a base script in niworkflows. Am I
missing something silly?
On Mon, Oct 16, 2017 at 6:02 PM, Madeleine Snyder <
<EMAIL_ADDRESS>wrote:

cool, done.
On Mon, Oct 16, 2017 at 4:54 PM, Chris Markiewicz <
<EMAIL_ADDRESS>wrote:

Oh, wow, I'm sorry. I didn't realize there was another repository of that
name that isn't a fork of fmriprep. It looks like there's one in
StanfordCosyne/fmriprep-1, but you also have one at
https://github.com/madeleinesnyder/fmriprep. That might be the easiest
one to use.
What I'm about to suggest is going to cross lines between repositories,
which may not be the cleanest thing in the long run. It might be best to
just clone a new folder:
mkdir tmp/cd tmp/
git clone git@github.com:madeleinesnyder/fmriprep.gitcd fmriprep/
Then add the StanfordCosyne/fmriprep repostiroy as a remote, which I'll
call cosyne:
git remote add cosyne https://github.com/StanfordCosyne/fmriprep.git
git fetch cosyne
Now you'll have access to your dismiss_t1w branch, so we'll just check
it out and push it to your fork of fmriprep:
git checkout -t cosyne/dismiss_t1w
git push -u origin dismiss_t1w
If you used a temporary directory, you can now remove it:
cd ../../
rm -r tmp/
Now you should be able to make a pull request.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/755#issuecomment-337077020,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJctLQ0Z84f3gimwRyYqHqQ88nSZnf-9ks5ss-y9gaJpZM4P15YA
.

Hello,
Do you know if and when it will be possible to run fmriprep without anatomical scans? I have a dataset for which there are only functional scans for 4 of the participants and both anatomical and functional scans for the remaining participants.
Thanks,
Anthony

Hi Anthony,
This has been on our backlog for very very long. Although we are making progress toward making this possible, there's still a long way until fMRIPrep can run without anatomical data. Long story short, we haven't had the resources to push this forward.
I'm writing this issue in the discussion about the roadmap (https://github.com/orgs/nipreps/teams/fmriprep-contributors/discussions/3/comments/6). We will be having a community roundup over Zoom next July 14.
If you want to be kept updated, please join our fmriprep-contributors team - https://github.com/orgs/nipreps/teams/fmriprep-contributors

OK, thanks Oscar. I will wait for now and see what happens.
Thanks,
Anthony

On 3 Jun 2021, at 09:30, Oscar Esteban @.***> wrote:
[EXTERNAL EMAIL]
Hi Anthony,
This has been on our backlog for very very long. Although we are making progress toward making this possible, there's still a long way until fMRIPrep can run without anatomical data. Long story short, we haven't had the resources to push this forward.
I'm writing this issue in the discussion about the roadmap (https://github.com/orgs/nipreps/teams/fmriprep-contributors/discussions/3/comments/6 https://github.com/orgs/nipreps/teams/fmriprep-contributors/discussions/3/comments/6). We will be having a community roundup over Zoom next July 14 https://arewemeetingyet.com/Zurich/2021-07-14/17:00/NiPreps%2FfMRIPrep roundup.
If you want to be kept updated, please join our fmriprep-contributors team - https://github.com/orgs/nipreps/teams/fmriprep-contributors https://github.com/orgs/nipreps/teams/fmriprep-contributors
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/nipreps/fmriprep/issues/755#issuecomment-853688910, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKIYPIA7H2HN34NYIUZHUB3TQ44SRANCNFSM4D6XSYAA.

Hi!
I'm also curious to hear if there has been any progress on implementing the featrure to run fmriprep without anatomical scan. Has this been implemented now?
If not, is there a way to get confounds output only?
Thanks!
Simon

Hello,
I’m also eagerly awaiting this functionality (if it can be implemented).
Kind regards,
Anthony
Dr Anthony Atkinson
Department of Psychology
Durham University
Durham, UK
https://www.durham.ac.uk/staff/a-p-atkinson/
https://atkinsonap.github.io/
From: deschsimon @.>
Date: Monday, 7 February 2022 at 11:58
To: nipreps/fmriprep @.>
Cc: ATKINSON, ANTHONY P. @.>, Comment @.>
Subject: Re: [nipreps/fmriprep] Running only functionals (#755)
[EXTERNAL EMAIL]
Hi!
I'm also curious to hear if there has been any progress on implementing the featrure to run fmriprep without anatomical scan. Has this been implemented now?
If not, is there a way to get confounds output only?
Thanks!
Simon
—
Reply to this email directly, view it on GitHubhttps://github.com/nipreps/fmriprep/issues/755#issuecomment-1031387363, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKIYPIE6OOMSWPZECAFGPG3UZ6XVDANCNFSM4D6XSYAA.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>

We don't have any contributors with the bandwidth to take this on at the moment. We are, however, happy to help orient new contributors, if you would be interested in working on this feature.

Hi! Thanks for working on such an amazing pipeline!
In my dataset fmriprep crashes for two participants. One doesn't have the anatomical scan, and the other's got a T1 scan, but there's a ton of movement (and I think that's what's causing the fmriprep crash?).
Thus I am also interested in running fmriprep without the anatomical scan. Has this feature recently been implemented by any chance? Otherwise should I have to exclude this participants or is it a way to keep them?
Thanks a lot,
Anna

This has not been implemented. I think it will likely be simpler after the upcoming release (#3108), but I haven't thought this all the way through.
The main way to exclude participants is to run one per fMRIPrep instance, and just skip the subject you don't want. Alternately you can pass a big list of IDs to the --participant-label flag.


Upgrade dependency

Upgrade<EMAIL_ADDRESS>to version

Please ignore this PR and close it. Generated by TestIM


feat(DIA-556): remove collector settings ff dead code

This PR resolves DIA-556
Description
Removes legacy code from collector settings(before ff)
#nochangelog
PR Checklist

[ ] I have tested my changes on iOS and Android.
[ ] I hid my changes behind a feature flag, or they don't need one.
[ ] I have included screenshots or videos, or I have not changed the UI.
[ ] I have added tests, or my changes don't require any.
[ ] I added an app state migration, or my changes do not require one.
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

Warnings

:warning:

✅ No changelog changes

  Generated by :no_entry_sign: dangerJS against c0f614804ee8e3f8a7d49f0bc0574ec2dcf40f69


Bugfix: Ignore timeout callback from a successful connect (fixes #945)

If redisAsyncConnect is done with a connect_timeout, and subsequently a redisAsyncCommand() happens but with no command_timeout, the connect timeout can still arrive, since it is never cancelled.  This fix prevents such a belated timeout from cancelling a command.

fixes #945

Thanks for the fix, merged.

Great.  You'll find a regression test for this issue in PR #948  (those async tests depend on the "polling adapter" from pr #932

Sounds good.
I plan on merging the adapter too but wanted to run it locally a bit so I have a good enough understanding of it to answer questions about it.


NAVIGATION USES MORE THAN 32GB of RAM!?

when i tried the navigation sample and when i click on somewhere it spikes to 32GB of ram and then done. but thats bad

Good catch. I'm able to reproduce this and I'll look into it.


Index Carbon Web Components

I believe this issue is blocked until:

Dotcom squad moves library to carbon-for-ibm-dotcom repo
Dotcom squad does initial indexing (communicated by Linda)

Tasks

[x] Index Get started library page with this content: https://www.carbondesignsystem.com/developing/frameworks/web-components

Dotcom squad is looking to do this when they are ready 🎉

I think we can close this, right? @mattrosno @alisonjoseph

@francinelucca it looks like we need to index https://carbondesignsystem.com/developing/frameworks/web-components as a Get started page in https://next.carbondesignsystem.com/libraries/carbon-web-components still.
(Like https://next.carbondesignsystem.com/libraries/carbon-react/latest/pages/get-started.)

https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/10048

@mattrosno now? 😃 https://next.carbondesignsystem.com/libraries/carbon-web-components/latest/pages/get-started

@francinelucca looks great!


Rake dependence

Can't update mailcatcher
bundle update mailcatcher
Fetching gem metadata from https://gems.funbox.io/...
Fetching gem metadata from https://gems.kaos.st/..........
Fetching gem metadata from https://gems.funbox.io/..
Resolving dependencies....
Bundler could not find compatible versions for gem "rack":
  In Gemfile:
    mailcatcher (~> 0.7.1) was resolved to 0.7.1, which depends on
      rack (~> 1.5)

    sidekiq-influxdb was resolved to 1.4.1, which depends on
      sidekiq was resolved to 6.2.1, which depends on
        rack (~> 2.0)

https://github.com/sj26/mailcatcher#bundler


Unfollow following list

Hey Man,
Thanks for your great code, do you think is there a way to write the similar code for unfollow the following from this page: https://www.linkedin.com/feed/following/
Best

I will take a look at it and I will let you know. It will be better if you can send me an email on this, so that I can add that to my to-do list. (email address is available on my website home page)


Telecon, November 5th, 12:30 PM PST/3:30 PM EST

The link for the call is: https://washington.zoom.us/j/144327307

Unfortunately, I am not going to be able to make this telecon, because I will be on my way to Santa Fe at this time.


Implementing offline local usage

Need a way to prepare local computational resources to deploy the model and modify the application's code to communicate with the local model.

@copeelite can you say more, I don't understand what this issue is about.  Are you saying you want to work with local LLMs vs. remote?  If so, you use something that provides an OpenAI-compatible API and run it locally, and add it as a provider.

local LLMs

Dear Professor
Yes I want to use this with my local LLMs, which is llama 3.1 with fine-tuning, I am not sure if this one work, and when I run this project locally, it seems that the sign-in function is not working. I feel it's better to have an env.example file?

Run a chat completions endpoint with something like https://github.com/ollama/ollama/blob/main/docs/api.md

I'm going to close this, as I think we support this.  If there's something I'm missing, please file a new issue.


Clarification: INFO[0191] dialing sshd

Hello!
I'm running uptermd on a server and when I connect to it with upterm I see the dialing message above. When people try to connect to the session the get permission denied. I'm guessing this is because upterm is trying to do some pubkey authentication with my locally running sshd? I'm guessing that since if I run upterm on a computer that has no sshd running everything seems to work normally and clients connect with no permission problems. I was just wondering how the dialing sshd part works and how to set it up so that other clients can connect to my machine.
On uptermd node:
uptermd --debug --ssh-addr <ip>:<port> --node-addr <ip>:<port>

On upterm host
upterm host --server ssh://<ip>:<port> -- bash

On upterm client
<copied ssh command>
Connection closed by <ip> port <port>

uptdermd logs:
DEBU[0850] connection establishing failed                addr="ip:port" app=uptermd com=ssh-proxy error="error checking user cert: ssh: principal \"blahblahblabh" not in the set of valid principals for given certificate: [\"host\"]" network=mem network-opt="[]" node-addr="<ip>:<port>" ssh-addr="<ip>:<port>"

After some more investigation this occurs with versions 0.5.x but when I build 0.4.6 I can get access to the host without issues.

After some more investigation this occurs with versions 0.5.x but when I build 0.4.6 I can get access to the host without issues.

@thornycrackers There were some changes on how cert is issued. Please make sure both the server uptermd and client upterm are up to date and remove the trusted certs in ~/.ssh/known_hosts. Let me know if this works or not. Cheers.

@jamie-pate @owenthereal  I'm stumped on setting up my own host server with this error when I try to run upterm host --serve ssh://<host-ip>
FATA[0000] ssh dial error: dial tcp <some ip> connect: connection refused

I am using an EC2 box to host the uptermd server and I'm fairly confident I have the virtual firewall set up correctly since using an invalid port times out while using the correct port is instantly refused.
Perhaps there is a way to get more verbose logging to see why the connection is refused? I'm not getting anything interesting when I use the --debug flag on the server.

Okay I eventually got this working. I think I had to set the --hostname and then I had to update the service file to not block any ip addresses since I want the filtering done at the virtual firewall level.


Allow headless JS tasks to retry

Summary
setTimeout inside a headless JS task does not always works; the function does not get invoked until the user starts an Activity.
This was attempted to be used in the context of widgets. When the widget update or user interaction causes the process and React context to be created, the headless JS task may run before other app-specific JS initialisation logic has completed. If it's not possible to change the behaviour of the pre-requisites to be synchronous, then the headless JS task blocks such asynchronous JS work that it may depend on. A primitive solution is the use of setTimeout in order to wait for the pre-conditions to be met before continuing with the rest of the headless JS task. But as the function passed to setTimeout is not always called, the task will not run to completion.
This PR solves this scenario by allowing the task to be retried again with a delay. If the task returns a promise that resolves to a {'timeout': number} object, AppRegistry.js will not notify that the task has finished as per master, instead it will tell HeadlessJsContext to startTask again (cleaning up any posted Runnables beforehand) via a Handler within the HeadlessJsContext.
Documentation also updated here: https://github.com/facebook/react-native-website/pull/771
AppRegistry.js
If the task provider does not return any data, or if the data it returns does not contain timeout as a number, then it behaves as master; notifies that the task has finished. If the response does contain {timeout: number}, then it will attempt to queue a retry. If that fails, then it will behaves as if the task provider returned no response i.e. behaves as master again. If the retry was successfully queued, then there is nothing to do as we do not want the Service to stop itself.
HeadlessJsTaskSupportModule.java
Similar to notify start/finished, we simply check if the context is running, and if so, pass the request onto HeadlessJsTaskContext. The only difference here is that we return a Promise, so that AppRegistry, as above, knows whether the enqueuing failed and thus needs to perform the usual task clean-up.
HeadlessJsTaskContext.java
Before retrying, we need to clean-up any timeout Runnable's posted for the first attempt. Then we need to copy the task config so that if this retry (second attempt) also fails, then on the third attempt (second retry) we do not run into a consumed exception. This is also why in startTask we copy the config before putting it in the Map, so that the initial attempt does leave the config's in the map as consumed. Then we post a Runnable to call startTask on the main thread's Handler. We use the same taskId because the Service is keeping track of active task IDs in order to calculate whether it needs to stopSelf. This negates the need to inform the Service of a new task id and us having to remove the old one.
Changelog
[Android][added] - Allow headless JS tasks to return a promise that will cause the task to be retried again with the specified delay
Test Plan
A fork containing this fix has been integrated and tested in a project like below:
export const headlessJsTask = () => () =>
    async function updateWidget() {
        const isReady = ...;
        if (!isReady) {
            return new Promise(resolve => resolve({'timeout': 1000})); // 1000ms
        }

        // Do work that relies on pre-requisite
    };

@JoshuaJamesOng did you see @matthargett's comment and could you address it?

@JoshuaJamesOng ping?

@JoshuaJamesOng I think this makes sense, the only part that feels a little weird to me is returning the timeout from the JS task. What if we allow you to configure whether or not retries are enabled (along with the timeout in ms, # of retries, etc.) from the native side (in HeadlessJsTaskConfig) and then we just retry on any JS exception if so? Maybe something like:
export const headlessJsTask = () => () =>
    async function updateWidget() {
        const isReady = ...;
        if (!isReady) {
          throw new Error('Not ready');
        }
       // other stuff if it's ready
    };

and then something like this in getTaskConfig (not sure if this is an up-to-date example, pulled it from the docs):
  new HeadlessJsTaskConfig(
    "SomeTaskName",
    Arguments.fromBundle(extras),
    5000, // timeout
    false, // allowed in foreground
    5, // number of retries
    1000 // retry after ms
  );

What do you think? Would that do what you need?.

@JoshuaJamesOng I think this makes sense, the only part that feels a little weird to me is returning the timeout from the JS task. What if we allow you to configure whether or not retries are enabled (along with the timeout in ms, # of retries, etc.) from the native side (in HeadlessJsTaskConfig) and then we just retry on any JS exception if so? Maybe something like:
export const headlessJsTask = () => () =>
    async function updateWidget() {
        const isReady = ...;
        if (!isReady) {
          throw new Error('Not ready');
        }
       // other stuff if it's ready
    };

and then something like this in getTaskConfig (not sure if this is an up-to-date example, pulled it from the docs):
  new HeadlessJsTaskConfig(
    "SomeTaskName",
    Arguments.fromBundle(extras),
    5000, // timeout
    false, // allowed in foreground
    5, // number of retries
    1000 // retry after ms
  );

What do you think? Would that do what you need?.

@JoshuaJamesOng hey! Did you see @ejanzer's reply to your PR? Would you be able to make the changes she proposed so we can merge this?

Have made the changes suggested. Note however that this does change the behaviour. Previously the author of the could decide when to retry. The new implementation retries on all errors. I wonder if we should make it so that the user still has control over which errors are retried? I'm worried we get stuck in a loop. Thoughts?

@JoshuaJamesOng I think that's a good idea. Could you add it?

Hey @JoshuaJamesOng! Do you mind addressing @ejanzer's last small comments? Then I think we can land it finally :)


blender: 2.81a -> 2.82

Motivation for this change
Things done
Updated version + hash. Backport to stable would be nice as well!

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

Fixed in #80155. I will submit a backport shortly.


build: style updates (NFC)

Adjust the CMakeLists.txt to match the rest of the usage.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please test

@swift-ci please test Windows platform

Build failed
Swift Test OS X Platform
Git Sha - dc1624dee0e140e84ff23f48002d0f5cfd1748e4

@swift-ci please test Windows platform

@swift-ci please test macOS platform


bootstrap and foundation

Is it possible to choose between bootstrap and foundation? So if I don't specify anything with 'inline_forms create' I will get foundation and if I specify 'bootstrap' then it will install bootstrap?
Is this a lot of extra work? Or is it possible to switch branch on basis of the --bootstrap option?
I am not ready to have my new apps created with incomplete bootstrap, but I want to start experimenting with it. What is best solution?

@acesuares having both bootstrap and foundation is a lot of extra work. We have to choose one of them. My vote is for bootstrap and the current implementation is fully functional.  it is not incomplete. Have you tested it? what you find is missing? and if you find something is missing, just tell me what you find is missing to consider it complete and I'll work on it to get it complete.


SignalR client (js) does not receive messages from hub when running through Aspire app host

We have an application that has Vue 3 frontend, a BFF (.NET8) and a backend API (.NET8 WebApi). The API has a SignalR message hub and sends messages to the Vue client. We've used Project Tye to run this solution locally with great success, and now we wanted to migrate to Aspire. The migration went well, all the components runs fine and works together, except that the SignalR client stopped receiving messages.
The server (api) is set to send messages on certain events, and the client is set to receive these messages with connection.on("<messageType>", data)
It seems to connect to the hub. The "negotiate" call (https) gets a response, but the next call using wss never gets a response.
We've tried to change to both LongPolling and ServerSentEvent. Both seems ok, meaning that the network calls all gets 200, but the client never gets the messages from the server.
This was no problem prior to adding Aspire app host.
Does anyone have an idea of how this problem can be solved?

If possible could you put together a minimal repro and post it up to GitHub so we can clone it down and take a look.

Putting this in 8.1. There are several issues people have reported with SignalR that we need to investigate.

https://www.reddit.com/r/dotnet/comments/1dgn8a4/signalr_problem_with_net_aspire/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
https://github.com/dotnet/aspire/discussions/2266
https://github.com/dotnet/aspire/issues/1660

I'm working on a repro. The minimal one (without access token) worked fine, so I need to add auth and possibly more until I get the error. But this takes time I don't really have, so it could be a while to get it done.

Accidently closed.

Closing this issue. There must have been some other issue that was causing the problem. Works fine now.


tests: common: fixed pointer formatting

Make this test also build with newlib enabled.
Signed-off-by: Anas Nashif<EMAIL_ADDRESS>

Codecov Report

Merging #7620 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #7620   +/-   ##
=======================================
  Coverage   55.25%   55.25%
=======================================
  Files         468      468
  Lines       51792    51792
  Branches     9909     9909
=======================================
  Hits        28618    28618
  Misses      19261    19261
  Partials     3913     3913

Impacted Files
Coverage Δ

tests/kernel/common/src/timeout_order.c
100% <100%> (ø)
:arrow_up:

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 941007d...b24957c. Read the comment docs.


Replace all occurrences of var in line

func doWork of lib/helpers/variables/js assumes a single instance of any given variable per line in a task.


gitless: use python3

Motivation for this change
fixed while stabilizing #76059
felt like this is necessary outside of python package set bump
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

Notify maintainers
cc @
[1 built, 0.0 MiB DL]
https://github.com/NixOS/nixpkgs/pull/76687
1 package built:
gitless

@GrahamcOfBorg build gitless


Implement luacov.pause() and luacov.resume()

luacov.pause() and luacov.resume() functions allow updating stats file from several interleaved processes.
A paused luacov instance still collects line execution data, but does not update stats file. When resuming, stats file is loaded and merged with data collected during pause. Therefore, several processes can run luacov with a single stats file as long only one of them is not paused at any moment.
The main usecase is running unit tests and cli tests from the same process. E.g.
unittest(some_function)
unittest(other_function)
luacov.pause()
clitest("lua -lluacov "..some_command)
luacov.resume()
unittest(more_functions)

I'm currently using luacov with this patch to gather coverage for luacheck, using busted -c and luacov-coveralls, and it seems to work fine.

Thank you!


Stream Exceptions When Calling AmazonS3Client.GetObject(GetObjectRequest)

Description
We've been seeing some System.ArgumentException: Stream was not readable. and System.IO.InvalidDataException: HashStream does not support base streams that are not capable of reading or writing exceptions when calling AmazonS3Client.GetObject(GetObjectRequest) recently. They appear to be caused by internal SDK code.
Reproduction Steps

Logs
System.IO.InvalidDataException: HashStream does not support base streams that are not capable of reading or writing
   at Amazon.Runtime.Internal.Util.HashStream.ValidateBaseStream()
   at Amazon.Runtime.Internal.Util.HashStream`1..ctor(Stream baseStream, Byte[] expectedHash, Int64 expectedLength)
   at Amazon.Runtime.Internal.Util.MD5Stream..ctor(Stream baseStream, Byte[] expectedHash, Int64 expectedLength)
   at Amazon.S3.Internal.AmazonS3ResponseHandler.ProcessResponseHandlers(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.ErrorHandler.InvokeSync(IExecutionContext executionContext)

System.IO.InvalidDataException: HashStream does not support base streams that are not capable of reading or writing
   at Amazon.Runtime.Internal.Util.HashStream.ValidateBaseStream()
   at Amazon.Runtime.Internal.Util.HashStream`1..ctor(Stream baseStream, Byte[] expectedHash, Int64 expectedLength)
   at Amazon.Runtime.Internal.Util.MD5Stream..ctor(Stream baseStream, Byte[] expectedHash, Int64 expectedLength)
   at Amazon.S3.Internal.AmazonS3ResponseHandler.ProcessResponseHandlers(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.ErrorHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.CallbackHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.EndpointDiscoveryHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.RetryHandler.InvokeSync(IExecutionContext executionContext)

System.IO.InvalidDataException: HashStream does not support base streams that are not capable of reading or writing
   at Amazon.Runtime.Internal.Util.HashStream.ValidateBaseStream()
   at Amazon.Runtime.Internal.Util.HashStream`1..ctor(Stream baseStream, Byte[] expectedHash, Int64 expectedLength)
   at Amazon.Runtime.Internal.Util.MD5Stream..ctor(Stream baseStream, Byte[] expectedHash, Int64 expectedLength)
   at Amazon.S3.Internal.AmazonS3ResponseHandler.ProcessResponseHandlers(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.ErrorHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.CallbackHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.EndpointDiscoveryHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.RetryHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.CallbackHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.CallbackHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.S3.Internal.AmazonS3ExceptionHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.ErrorCallbackHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.MetricsHandler.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.Internal.RuntimePipeline.InvokeSync(IExecutionContext executionContext)
   at Amazon.Runtime.AmazonServiceClient.Invoke[TResponse](AmazonWebServiceRequest request, InvokeOptionsBase options)
   at [call from our code]

Environment

SDK Version: ?
Package Version: AWSSDK.S3 <IP_ADDRESS>
OS Info: Windows 10
Build Environment: Visual Studio
Targeted .NET Platform: .NET 4.8

Resolution

[ ] :wave: I can/would-like-to implement a fix for this problem myself

This is a :bug: bug-report

Hi @alexleen,
Good afternoon.
Thanks for reporting the issue. I will try to reproduce the issue. Also, it would be helpful if you could share some sample code to troubleshoot the issue.
Thanks,
Ashish

We're disposing the response inside a for loop (for retries):
var request = new GetObjectRequest
{
    BucketName = bucketName,
    Key = key
};

for (int i = 0; i <= 5; i++)
{
    try
    {
        using (var response = _client.GetObject(request))
        {
            // download code...
        }
    }
    catch (...)
    {
        // ...
    }
}

but we don't refer to the response outside of the using - or any of its members.

Hi @alexleen,
Thanks for your reply.
Please help me with the following information:

How frequently are you seeing this error in the log?
Is the error logged after upgrading to AWSSDK.S3 <IP_ADDRESS>?
Were you getting this error in previous version of AWSSDK.S3?

Hey @ashishdhingra,
I apologize - we were actually seeing this with 3.5.1. We've since upgraded to <IP_ADDRESS>. I'll update the issue above.
We saw the errors several times in quick succession one day last week, but haven't seen them since. I'll let you know if we see them again with <IP_ADDRESS>.

@alexleen Thanks for the update. We can keep this issue open for few days and see if you see the exceptions again.


Question

Linda,
This week I indicated that a space was missing. I doubted whether I should report this to you. I thought it a little exaggerated to report this. I foresee that I will only bother you with such things, which of course should never be the intention. On the other hand, I know that you want the texts to be correct. But if it's not really urgent...
I suggest that I only report in such cases if it is important (per case). If you want, I can also collect less important cases and report that to you in one message. Just let me know what you appreciate. I want to help you as good as possible. In addition, I would like to give something back to Microsoft.

@PeterVanLoosbroek Hi Peter, thanks so much. As long as you file it as an ISSUE (vs. a PR), nothing is too small. I work in VBA-Docs every day, so it's already open and I can easily make the fix. It's okay to collect several issues in one issue if you want as well, but not necessary. Only use PRs if you have many changes across several docs (and these can all be in the same PR). The main reason for this is the repo itself; because it's so big, it takes an hour to build updates, vs. smaller repos that take only a few minutes. Thanks for helping us!

OK, clear en thanks.


GEODE-2738: Corrected spelling of "occured" to occurred

Most occurrences are in comments and string constants, but there are a nontrivial number of variable name changes as well.
Initial testing returns green across the board.

Rebased and resoled conflicts.

Re-rebased and conflict resolved.


Argument 1 passed to \Admin\Actions\SaveConversation::handle() must be an instance of Illuminate\Database\Eloquent\Model, instance of Illuminate\Http\Request given

Laravel Version: 6.5.2
PHP Version: 7.3.7
Laravel-admin: 1.8.2

Description:
I have added custom action Popup Form as instructed here
I have implemented form and handle method in my action class SaveConversation. On submitting form, handle method is called but Model object is not being passed to it. Only Request is being passed which is throwing the Argument exception.
It works fine if we use only Request as parameter in handle method
Kindly let me know what am i missing here. Thanks

primary key was other than the id column.


"superset load_examples" fails on MySQL date fields

Make sure these boxes are checked before submitting your issue - thank you!

[x ] I have checked the superset logs for python stacktraces and included it here as text if any
[x ] I have reproduced the issue with at least the latest released version of superset
[x ] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
0.18.2
Expected results
Tables with date colums should import normally on MySql.
Actual results
"superset load_examples" fails to load tables with date columns in MySql (cannot recognize format).
Steps to reproduce
Create a config.py file setting your SQLALCHEMY_DATABASE_URI  to MySql.
export PYTHONPATH
start superset
run "superset load_examples"
error: cannot recognize date column format.

did you install mysql with pip install mysqlclient before running? and ur mysql connection string should be in mysql://username:password@host:port/dbname format.


Unable to set multiple client options

Operating System version: OSX 10.13.6
Firebase SDK version: Unable to determine
Firebase Product:  Auth

Note: Running in GAE Standard dev environment under dev_appserver.py
I am attempting to verify firebase tokens, but I am not able to set up my ClientOption to use urlfetch by calling WithHTTPClient  when I am already using WithCredentialsFile
See example:
gaeCtx := appengine.NewContext(r)

opt := option.WithCredentialsFile("/path/to/my-app-service-account-file.json")
// opt := option.WithHTTPClient(urlfetch.Client(gaeCtx)) <--- How do I set this as well as WithCredentialsFile?

app, err := firebase.NewApp(goStdCtx.Background(), nil, opt)
if err != nil {
  log.Errorf(gaeCtx, "unable to initialise firebase application")
}

client, err := app.Auth(gaeCtx)
if err != nil {
  log.Errorf(gaeCtx, "unable to initialise firebase authentication client")
}

...

I am aware that when I deploy to GAE I will not need WithCredentialsFile but I want to be able to set both WithCredentialsFile and WithHTTPClient when running in development

NewApp() function accepts varargs. So you can do this:
opt1 := option.WithCredentialsFile("/path/to/my-app-service-account-file.json")
opt2 := option.WithHTTPClient(urlfetch.Client(gaeCtx))

app, err := firebase.NewApp(goStdCtx.Background(), nil, opt1, opt2)
if err != nil {
  log.Errorf(gaeCtx, "unable to initialise firebase application")
}


ToLookup overloads for key-value pairs & tuples of 2 (#274)

PR for #274

[x] Implementation
[x] Unit tests
[x] Update operators list
[x] Update release notes
[x] Add quick description to README

@fsateler We good to merge this?

LGTM


Add note to configureRJ docs that multiplying by the indicator variable is optional

We consider it good form to multiply each coefficient by its indicator variable so that the graph really corresponds to the statistical model, but we could add a note to the documentation that the RJMCMC will work even if that is not the case.

I am closing this because after discussion it is either wrong and/or not what we want to be recommending.


refactor: reformating code with 2 spaces indendation

Fix for issue #139
Reformated code with the following configuration.

@bglamadrid The previous PR got deleted due to some issues. Can you please check this?
For now, I have done the changes only for test classes. If this is fine, we can proceed with the actual classes.

Hi @ashwinpadmakumar, appreciate the effort.
You had troubles in the previous PR because you touched too many files, and some of them were touched in other pending PRs as well.
This PR also has the same problem. See, issue #136 referred to 3 specific files, and yet, here you are modifying 71 files.
Could you please start over and only commit those three files? I'm closing this PR so you can try again. Thanks beforehand.

@bglamadrid No problem. I will raise another PR with just those file changes.


Add method to check AND raise if device is not connected to internet

This ensures consistency across workloads by allowing them to replace:
if not self.device.is_network_connected():
  # handle error here e.g. raise DeviceError

with a simple call to: self.device.check_network_connected()
The former approach can still be used by workloads that choose to do so

Do we really need a separate method for this two-liner?

Not entirely necessary, but we thought it useful to have a consistent message if anyone else will use it. At the moment it is used in 4 workloads - skype, books, youtube and gmail.

This shouldn't be a DeviceError -- that implies something has gone wrong on the device. Where as what you're actually trying to signal is that requirements for a specific workload are not met, so a WorkloadError should be raised.


Make IRGlobalValue::mangledName a Name*

This allows us to get rid of IRGlobalValue::dispose().

This looks good. I have a few notes for things we can do down the road:

We can eventually replace the various places that check is a mangled name has Length() == 0 with checks for a nullptr mangled name instead. That should be a little bit more clear about the intent.

We eventually need to think carefully about the lifetime of things in the NamePool, because there is technically a risk that it could fill up with lots of string data over multiple compiles (using the same session), and there is no way to free up that memory (whereas many other structures get released when the corresponding CompileRequest is done).

We should eventually consider having mangled names be stored on AST nodes or decl-refs (if/when we get serious and start unique-ing decl-refs with a cache), possibly lazily computed on-demand. This would save us from having to compute mangled names repeatedly like we do today.

Having written all that up, I find myself again wondering whether storing mangled names in the IR like this is really saving any trouble, compared to just storing a DeclRef for the same thing (since a mangled name and a decl-ref are isomorphic).


unit8-part1

I have an error with parser. Please let me know the solution for this.

Any suggestions please..........

The above one is corrected with the following code
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--repo-id", type=str, default="ThomasSimonini/ppo-CartPole-v1", help="id of the model repository from the Hugging Face Hub {username/repo_name}")
But got the  error in the next lines.

Suggestions please

Please suggest the corrections


RDS: can't change single az to multi az in certain conditions

Describe the bug
Can't change single az to multi az in certain conditions
Steps to reproduce

Run kubectl logs your_pod_rds_chart_name -f
Create somewhere file db.yaml with such contents

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: mysqldbcreds
data:
  password: some_password
---
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: rds-ack-db-test
  namespace: your_namespace
spec:
  allocatedStorage: 20
  dbInstanceClass: db.t3.micro
  dbInstanceIdentifier: rds-ack-db-test
  engine: mysql
  engineVersion: 8.0.23
  masterUsername: admin
  masterUserPassword:
    key: password
    name: mysqldbcreds
  multiAZ: true
  port: 3306
  publiclyAccessible: false
  storageType: gp2
  tags:
    - key: Name
      value: rds-ack-db-test
    - key: CreatedBy
      value: RDS ACK

Run kubectl apply -f db.yaml
Verify that database have been created and there are some output from rds-chart pod.
Change multiAZ from true to false
Run kubectl apply -f db.yaml
Verify that database become single az
Change multiAZ from false to true
Run kubectl apply -f db.yaml
Verify that nothing changed and there is no new output from rds-chart pod.

Conclusion:
singleAZ > multiAZ - work
multiAZ > singleAZ - work
multiAZ > singleAZ > multiAZ - not work
Expected outcome
Ability to change multiAZ option multiple times.
Environment

Kubernetes version 1.21
Using EKS (yes/no), if so version? eks.4
AWS service targeted (S3, RDS, etc.) RDS

I will make a new release of RDS controller tomorrow and will try to reproduce this problem.

I was able to reproduce the issue locally.
When the first update is made, i.e. multiAZ "true" -> "false", the update code path returns success, cluster goes into modifying state but the reconciler does not keep requeueing to sync the state.
When the parameter is changed again from "false" -> "true", which previous update is still being applied on RDS side, the Read API call still returns multiAZ as "true", which does not trigger for any update because the desired and latest state are same.
I will work on a solution for this problem and try to fix this update behavior in the next release of rds-controller.

The latest release v0.0.20 should have fix for this issue.


fix: blank page on localhost landing

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Fix: I got blank page on localhost

Did your issue had any of the "$" label on it?

[ ] My DOT address: Payout

Screenshot 📸

[ ] My fix has changed UI

Copilot Summary

🤖 Generated by Copilot at c5d2bc6
Fixed a Vue 3 warning and a potential error in the search components by using explicit v-model bindings and optional chaining. Moved some logic from SearchSuggestion.vue to Search.vue for better consistency and testability.

🤖 Generated by Copilot at c5d2bc6

v-model refined
avoiding warnings and errors
autumn of Vue 3

any idea why landing page show empty & load components afterward? even though LazyLoading

I still have not found the root cause, I think we don't need all components to be lazy on the landing page. especially component that on above the fold from screen area


fix: totals label on first col

The first if checks if it is a measure, meaning we only need to check if the column is the one furthest left, which is pageColIdx === 0

It does not cause any issues, right?


Unable to craft

This issue is happening to TEST5000 account
I am able to put items into the crafting grid and the result pops into the output box but I am unable to pull from the output box. I have tested even after the fix for the empty string aliases. The only workaround I have currently is to use an autocrafter

Also, I tried to use /clearinv and it was successful but I am still not able to craft

If you can provide to me my player metadata I may be able to find some issue with that. I haven't looked to see if Unified Inventory saves mod data but if it does, there may be something there as well. I haven't seen a way to DM on here but I have accounts with nearly everything: Facebook, Element, Signal, Discord, email...

Issue is resolved, I'm able to craft now :)


[typo][docs] change data-partitions.md

Proposed changes
add some page links for this docs

run buildall

run buildall

run buildall


[dart fix] inEnum does not apply transform

I want to rename a deprecated enum value in https://github.com/flutter/flutter/pull/139257
For example:
enum WidgetInspectorServiceExtensions {
  @Deprecated(use add instead)
  setPubRootDirectories,
  addPubRootDirectories,
  // ...
}

I wrote the following rule to try to rename uses of the deprecated enum:
  - title: "Use WidgetServiceExtensions.addPubRootDirectories"
    date: 2023-11-29
    element:
      uris: ['widgets.dart', 'material.dart', 'cupertino.dart']
      enum: 'setPubRootDirectories' # also tried constant?
      inEnum: 'WidgetInspectorServiceExtensions'
    changes:
    - kind: 'rename'
      newName: 'addPubRootDirectories'

The transformation I expected in the test was:
// Before
WidgetInspectorServiceExtensions.setPubRootDirectories;

// After
WidgetInspectorServiceExtensions.addPubRootDirectories;

But nothing happened.
This is the first inEnum fix for the framework, so there could be a bug?
The docs mention enum or constant for the element when using inEnum, neither of those worked. I tried field as well for good measure.

It sounds like it's either a bug or a missing bit of functionality.
It should definitely be constant, based on the docs, though if it isn't working we could just change it to field given that enum's can now have other fields, and it would be less syntax to document, implement, and remember. Using enum would mean the whole enum (WidgetInspectorServiceExtensions in your example).

@Piinks , if i use constant to specify the enum value, the transform works, at least as a test - https://dart-review.googlesource.com/c/sdk/+/341389.  Yet to try running dart fix, will check that out.

Ah fabulous! I just tried that at tip of tree and it worked! Thanks @keertip!


Prevent error when no third point is found

Else argmax([]) is called later, which doesn’t make sense. This happens because Dseg[tips[0]] + Dseg[tips[1]] are all inf for some datasets. Is that simply a consequence of my data or is that a bug?
This PR assumes the former and results in such segments being skipped. In case of my data, this means that I end up with a single DPT group instead of multiple ones.

Ok, makes sense. Things are infinite when you encounter disconnected clusters. Either increase n_neighbors, if it makes sense, or you can only meaningfully run DPT on subsets of the data.


chore(master): release 0.7.2

:robot: I have created a release beep boop
0.7.2 (2023-05-02)
Features

support specifying specific API version (#49) (059bd9c)
support using rustls and targeting musl (#43) (61aa88b)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/kade-robertson/ddragon/releases/tag/v0.7.2 :sunflower:


Allow more fine-grained selection of /var/log contents

Enhancement Proposal
Currently, and even more so after #35, we are slurping all of /var/log. In some case this can be A LOT, filling up storage too quickly, unnecessarily and unexpectedly, resulting in an outage.

Related to #46.


Ongoing Tasks when file copying reports too slow in chunks instead of realtime.

Describe the bug
A clear and concise description of what the bug is.
The Ongoing Tasks doesn't give real-time progress like the built in Windows File explorer does when copying files to network locations (SMB or UNC path). This becomes very obvious when copying a large amount of data (files and folders) around 10GB for example.
To Reproduce
Steps to reproduce the behavior:

Open 2 tabs, source and destination tabs
Select your files/folders that total a large amount e.g. 10GB (Video files are good example).
Watch as progress is reported in batches instead of realtime. e.g. shows 0% then 15or16%, the 35%, then 67% etc etc.

Expected behavior
Would expect streaming like continuous updates
Screenshots
Not possible or applicable based on the explanation above.
Desktop (please complete the following information):

OS Version: Window 10 20H2 build 19042.662
App version: [v<IP_ADDRESS>]

Additional context
Persistent in this version but never thought to look in early for comparison
Log file
N/A.

This issue should be resolved in main.


Need a simple example to use every primitive

Describe the annoyance

The existing examples are too complicated, core function of rerun are flooded with codes for data processing or algorithm. It's hard for me to find out usage of the primitives, especially for the rust language, for the lack of rust example.
Expected behavior

A simple example with very simple data, which shows basic usage of every primitives, in both rust and python.

Agreed. A nicely organized standalone version of each API, linked from the primitives docs is something we’ve been talking about for a while. Will try to get to that soon.
In the mean time the api_demo is probably the closest to what you might be looking for: https://github.com/rerun-io/rerun/blob/latest/examples/rust/api_demo/src/main.rs
Very little algorithm code in there and most of the sub-samples are focused on just one API surface. But not everything is covered or organized perfectly.

That could helps, thank you.
Also expect the one you metioned😁

Related to #1483

Let's expand on api_demo to include all primitives. Help wanted 🙏

Now that we have notebook support, I think we should take a stab at using it to document the python APIs.  We can maintain the doc- notebooks in the repository, and run them headless in CI using nbconvert. This both tests the APIs work and generates artifacts we can host.
For example
jupyter nbconvert --to=html --ExecutePreprocessor.enabled=True examples/python/notebook/cube.ipynb

Creates a standlone html document:

We can also push these same notebooks to colab and link as appropriate so that users can quickly play around with the API samples live if they want to experiment.

Agreed, this would be a huge boost for our documentation! One of the best parts of this is that it makes it so much easier for us to write literate-programming-like examples, making the doc maintenance itself easier on us code-focused folks

This is more user-facing, while we should also have a separate api_test that is completely exhaustive with all different tensor types, etc.


HTML

Hey!!
are you willing to accept new contributors? I am interested into contributing to this repository so, if you could explain a bit more this feature request, it would be great.
Thanks

Pink color is not looking much professional! If you are accepting new contributors, then I can change your css to look your portfolio more professional!


Broken in SteamOS update from May 7 2024

Trying to load the menu after this update completely breaks the Decky interface and forces a restart of Steam, or even a hard reboot.
Please fix it soon :)

Should be fixed in this submission
https://github.com/SteamDeckHomebrew/decky-plugin-database/pull/626
Will close the issue once its merged.


Refactor All Rego

🗣 Description

Move all shared rules/functions to the Utils.rego file
Make all Rego code v1 compliant
Make all Rego code conform to our Regal style checks

💭 Motivation and context
Closes #117.
Closes #69.
🧪 Testing
Tests I performed:

.\regal.exe lint --format github rego Testing passes (using the config file in the .regal folder)
.\opa_windows_amd64.exe check --rego-v1 rego Testing passes
Rego unit tests all pass
Ran ScubaGoggles for all products on both main and this branch, no diff observed

✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] If applicable, All future TODOs are captured in issues, which are referenced in the PR description.
[x] The relevant issues PR resolves are linked preferably via closing keywords.
[x] All relevant type-of-change labels have been added.
[x] I have read and agree to the CONTRIBUTING.md document.
[x] These code changes follow cisagov code standards.
[x] All relevant repo and/or project documentation has been updated to reflect the changes in this PR.
[x] Tests have been added and/or modified to cover the changes in this PR.
[x] All new and existing tests pass.

✅ Pre-merge Checklist

[x] This PR has been smoke tested to ensure main is in a functional state when this PR is merged.
[ ] Squash all commits into one PR level commit using the Squash and merge button.

✅ Post-merge Checklist

[ ] Delete the branch to clean up.
[ ] Close issues resolved by this PR if the closing keywords did not activate.

Is this for all or just calendar?

Is this for all or just calendar?

Sorry I should have made a note about that. It's for all. It started out as just calendar (hence the branch name) but I ended up doing it all.


Add documentation for features most frequently asked about

Now that I've closed #368, I've updated this issue to suggest a list of things that would be useful to document.
It would be nice to document the following things since they're features most often asked about. This list is neither definitive nor in ranked in order of importance; these are my own suggestions based on what I've observed on the issue tracker.

[ ] Running refile on a separate server, especially useful for those running their app on Heroku and suffer from performance issues.
[ ] Showing image previews in JavaScript
[ ] Manipulating images, like cropping and resizing.
[ ] Setting up a CDN
[ ] Removing attached files.
[ ] Testing uploads

@abitdodgy This is a good idea. I'm sure other people are trying to find a solution like me...what is the best practice for using Refile on Heroku? I have already set up Fastly as a CDN. Unfortunately, the performance is still really bad. I am already trying to "pre-cache" the images in the CDN by requesting the images in a background job. Unfortunately, this doesn't seem to help. What would you recommend to solve this issue?

@andrewhavens I'm in the same boat as you are. There's a discussion on this topic in #229. I get the same errors frequently, and a high response time warning on every request that goes through Refile. I think the best way to deal with this is to have the CDN retrieve the files from S3 isntead of through the Refile app, but I don't know if this is possible.
Perhaps storing the S3 url in the database, and hitting that instead of Refile might work... but again, I'm not familiar with the internals of Refile to know if this works. I'd be interested to hear about any progress you make on this issue.
I've had other things on my plate, and since we've been able to trudge along even with those limitations, I've not looked into solving this issue.

@andrewhavens another possiblity is to run Refile on a separate box with a bit more juice than a Heroku dyno... but I don't know how much extra plumbing we'd need for that to work.

Running an image server off a digitalocean box is good and cheap (and easy, if prepackaged as docker image). My own experience, albeit not refile, is that it can be a boot-up-and-forget thing.
However, refile rack app is currently too simplistic and will drown a small box when >1 request poke through the cdn/varnish/nginx layer

@choonkeat I think a simpler solution might be to somehow store the S3 url and have the CDN bypass Refile. I don't know if that's possible.

@abitdodgy that works if the file stored in s3 is all you need, but it also defeats one of the advantage of refile (and shrinerb, attache) which is the ability to use dynamically resized images in your app.

@choonkeat that's true, although in our case we are using it for document and file storage, and we don't care about resizing (in most cases we don't, but we do in one case: user avatars).


Support for annotations within nested objects

https://github.com/kaiso/relmongo/issues/60

The changes on
io.github.kaiso.relmongo.util.ObjectIdReaderCallback
io.github.kaiso.relmongo.mongo.DocumentUtils
from https://mvnrepository.com/artifact/io.github.kaiso.relmongo/relmongo/3.4.0-RC1
are already merged.

Pull Request Test Coverage Report for Build 1666

22 of 47 (46.81%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.06%) to 70.968%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/io/github/kaiso/relmongo/events/callback/PersistentPropertyConvertingCallback.java
1
5
20.0%

src/main/java/io/github/kaiso/relmongo/events/callback/PersistentPropertyPostSavingCallback.java
1
5
20.0%

src/main/java/io/github/kaiso/relmongo/events/callback/PersistentPropertyCascadingRemoveCallback.java
1
6
16.67%

src/main/java/io/github/kaiso/relmongo/events/callback/PersistentPropertyPostLoadingCallback.java
1
7
14.29%

src/main/java/io/github/kaiso/relmongo/events/callback/PersistentPropertySavingCallback.java
11
17
64.71%

Totals

Change from base Build 1483:
-2.06%

Covered Lines:
572

Relevant Lines:
806

💛  - Coveralls