Change some label colors

Feel free to close this pr or request change

user settings > organizations > new organization button -> black to blue

admin settings > organizations > new organization button -> black to blue

admin settings > users accounts > create user account button -> black to blue

repository > labels > count label -> set as basic

repository > milestone issues > issue number label (read) -> black to grey

repository > commit list > search button -> black to blue

Commit Search Button

Label Count Label

Milestone Issues > Issue Number Label

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@8f09aff). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master   #9051   +/-   ##
========================================
  Coverage          ?   41.1%
========================================
  Files             ?     549
  Lines             ?   71495
  Branches          ?       0
========================================
  Hits              ?   29386
  Misses            ?   38391
  Partials          ?    3718

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 8f09aff...0c33882. Read the comment docs.

How doe it look in dark theme?

@lafriks

repository > labels > count label -> set as basic
for the dark theme it looks to bright - for the normal theme it is good ...

What do you think what it should be? I can change any other color instead of basic class?

@jaqra I guess you could go override the matching basic style in the dark theme.

I wonder if you can also change the color of a merge pull requested, it is a very bad choice

what about #bbbbbb

@Perflyst what do you suggest?

@silverwind can you review please?
@Perflyst i am waiting for your answer

Sorry.. Yes #bbbbbb would be fine, same color as the "X labels" background has


fix: in case there is a port number other than 80 or 443

const strategy = new Strategy({
  config: myConfig, scope: myScope,
  callbackURL: 'https://localhost:8080/callback',
}, myVerifyFunc);

// serializeUser, deserializeUser, etc...

passport.use('my-strategy', strategy);

When the callback request reach to the callback URL, it says:
CSIAQ0167E The redirection URI that is provided in the request [https://localhost/callback] is either invalid, or does not meet the matching criteria for the registered redirection URI.

Apparently the port number is missing...

Are you using passport@5?

Are you using express@5? Because AFAICT req.host is fixed in express 5 and properly returns port.
If you don't use the latest express version where this is fixed or use some other non-standard setup - you can just overload the currentUrl method so that it works for your conditions, that's the whole reason why this method is public and typed - so that you can control it.


[autotitle] not rendered on page

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/get-started/accessibility/github-command-palette
What part(s) of the article would you like to see updated?
The header shows unrendered info:
The GitHub Command Palette is deactivated by default. You can enable the GitHub Command Palette with feature preview. See "[AUTOTITLE](/get-started/using-github/exploring-early-access-releases-with-feature-preview)."
```

### Additional information

It's not directly on the page itself, seems to be an embed and I do not have a clue how those are rendered :-D

Seems like the AUTOTITLE keyword does not get rendered from here: https://github.dev/github/docs/blob/main/data/reusables/command-palette/default.md, either because of the use in a subpage or the link, but links in other locations do work, like here in the markdown leads to this page here.

Batch Installation ID: DDB1A24E-9B13-48FC-B301-FE8C4ACC592D

@rajbos Great catch! ✨ I've added the help wanted label so that you, or anyone else, can help assess the issue and submit a PR with a fix 💛


Pretrained Inception V4 to Keras Application Folder

Repilca of this issue created by @amangalampalli
Would it be possible to add Inception V4 to the Keras Applications folder?
System/User Specifics: Tensorflow 2.0 with tf.keras module
Due to recent discoveries made in neural networks and also according to many benchmarking standards, Inception V4 is one of the best networks available with very high accuracies in both Top 5 and Top 1.
Inception V4 should be included because it has been consistently proven to be one of the most accurate networks for Image Recognition. It will benefit many users who want a network with very high accuracy and also have the resources to run it.

@divyashreepathihalli
This ticket should be moved to keras-cv.


Allow deserializing the base response object

Made the keyPath optional on line 86 so a base object can be deserialized into an object.

This can already be done with the following function:
public func responseObject<T: Mappable>(completionHandler: Response<T, NSError> -> Void) -> Self


Support k and filter_criterion simultaneously on NumPy(Minimum)Eigensolver

What should we add?
The Problem
When prototyping or debugging non-quantum parts of the stack I often find myself getting back to the NumPy(Minimum)Eigensolver classes. However, in less trivial chemistry applications, the naive lowest eigenvalue is oftentimes not a physical one, so I need to rely on adding a filter_criterion to find a physically meaningful eigenvalue.
Unfortunately, the code currently hard-codes k when a filter_criterion is supplied:
https://github.com/Qiskit/qiskit-terra/blob/332bd9fe0bea82c0fdf7329cea3da115d86e3fc2/qiskit/algorithms/eigensolvers/numpy_eigensolver.py#L257-L259
This means that ALL eigenvalues will be computed, which can take a VERY long time.
The reason for doing this is well motivated though, because one cannot know a priori what value to pick for k.
My proposed solution
I would like to propose that we support setting k and filter_criterion simultaneously.
Since as an end-user I have written the filter_criterion myself, I do have more knowledge about the problem that I am trying to solve. Thus, I may also be able to make an educated guess for k.
And even if that fails, I may be willing to try setting k to 100, then 200, then 300 and so on , rather than having to wait for say 2**10=1024 eigenvalues to be computed regardless of whether my value of interest might have been in the first 10% or so.
I think the prototyping and debugging speed that could be gained here is quite significant.
So in summary:

the defaults should remain as they are right now
but it should be possible for an end-user to manually set k while also setting a filter_criterion

I would work on this myself, but in the recent months where I thought of doing this I have not found the time to come up with a clean code solution. Thus, I am opening this issue to see if someone else might find this interesting and has the time to do this.
I will gladly review a PR once time has come. Otherwise I might get back to this once I have a bit more time on my hands in the (potentially far) future.

k was supposed to mean the number you were interested in being given back. I wonder if it would be better to have a new parameter say filter_limit (or whatever it was called) that defaults to None and internally controls how many eigenvalues it will get to filter, defaulting to all (as it is at present). Then if you have a better idea that your k desired values are within some range (limit) of eigenvalues you could set this. It already states you may get less than the k you ask for due to filtering - this limit would just bound the set of eigenvalues it was looking at to start with.

Interesting. I guess k is then being misused in the context when a filter is applied because you do not get back that number of eigenvalues... But you're suggestion for splitting the responsibility here sounds like a good approach! :+1:

When a filter is applied it states you might get back less than k - if there are at least k eigenvalues in the entire set that match the filter you should get k or them. At least that was the intent - it saves k internally as k_orig before it gets all of them and then returns what matches limited by k_orig - maybe there is some issue there.

Transferred to new repo: https://github.com/qiskit-community/qiskit-algorithms/issues/61


Regarding the issue of setup(model, optimizer) in fabric FSDP

When I follow your code guidance, the environment configuration is consistent with yours, but fabric.setup(model, optimizer) reports an error. I see that your code is also written like this. Have you ever encountered this problem? Looking forward to your reply!
The source code is as follows：
`import torch
import torchvision as tv
import lightning as L
def main():
fabric = L.Fabric(accelerator='cuda', precision='bf16-mixed', devices=torch.cuda.device_count(), strategy='fsdp')
fabric.launch()
model = tv.models.resnet18()
optimizer = torch.optim.SGD(model.parameters(), lr=0.001)
model, optimizer = fabric.setup(model, optimizer)
# model = fabric.setup_module(model)
# optimizer = fabric.setup_optimizers(optimizer)
dataset = tv.datasets.CIFAR10("data", download=True, transform=tv.transforms.ToTensor())
dataloader = torch.utils.data.DataLoader(dataset, batch_size=8)
dataloader = fabric.setup_dataloaders(dataloader)

if name == 'main':
main()`
The error is reported as follows:
Traceback (most recent call last):   File "/project/Code/Skin/aa.py", line 23, in <module>     model, optimizer = fabric.setup(model, optimizer)   File "/opt/conda/envs/wsk-py310/lib/python3.10/site-packages/lightning/fabric/fabric.py", line 198, in setup     self._validate_setup(module, optimizers)   File "/opt/conda/envs/wsk-py310/lib/python3.10/site-packages/lightning/fabric/fabric.py", line 856, in _validate_setup     main()   File "/project/Code/Skin/aa.py", line 14, in main     model, optimizer = fabric.setup(model, optimizer)   File "/opt/conda/envs/wsk-py310/lib/python3.10/site-packages/lightning/fabric/fabric.py", line 198, in setup     raise RuntimeError( RuntimeError: The Fabricrequires the model and optimizer(s) to be set up separately. Create and set up the model first throughmodel = self.setup_model(model). Then create the optimizer and set it up: optimizer = self.setup_optimizer(optimizer).     self._validate_setup(module, optimizers)   File "/opt/conda/envs/wsk-py310/lib/python3.10/site-packages/lightning/fabric/fabric.py", line 856, in _validate_setup     raise RuntimeError( RuntimeError: The Fabricrequires the model and optimizer(s) to be set up separately. Create and set up the model first throughmodel = self.setup_model(model). Then create the optimizer and set it up: optimizer = self.setup_optimizer(optimizer).

Thanks for the note and sorry about the hassle. I think that's because I had the current dev version installed, which has not been released yet. The new version allows you to combine the two lines
    model = fabric.setup_module(model)
    optimizer = fabric.setup_optimizers(optimizer)

into a single line
    model, optimizer = fabric.setup(model, optimizer)

But for the latest stable release, the 2 separate lines are necessary. I updated the code accordingly.

Thanks for the note and sorry about the hassle. I think that's because I had the current dev version installed, which has not been released yet. The new version allows you to combine the two lines
    model = fabric.setup_module(model)
    optimizer = fabric.setup_optimizers(optimizer)

into a single line
    model, optimizer = fabric.setup(model, optimizer)

But for the latest stable release, the 2 separate lines are necessary. I updated the code accordingly.

I tried the modification method you mentioned, but the optimizer still reported an error:
ValueError: The optimizer does not seem to reference any FSDP parameters. HINT: Make sure to create the optimizer after setting up the model.


Fix core-command configuration for secrets

Update core-commands' TOML files to use core-metadata's secrets since
core-command uses core-metadata's database for persistence.
Revert changes to security-secretstore-setup which included creating
secrets for core-command. These are not needed since core-command uses
core-metadata's database.
Signed-off-by: Anthony M. Bonafide<EMAIL_ADDRESS>

https://github.com/edgexfoundry/blackbox-testing/issues/282

recheck

recheck

Codecov Report

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

@@           Coverage Diff           @@
##           master    #1993   +/-   ##
=======================================
  Coverage   44.07%   44.07%
=======================================
  Files         186      186
  Lines       11655    11655
=======================================
  Hits         5137     5137
  Misses       6222     6222
  Partials      296      296

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 6d5015b...ca3e788. Read the comment docs.


Added  a Basic webpage for Testimonials.

sir your repository is excluded from the hacktober fest stating that it does not follow the values of the event.
please do something about it.


Update README.md - Firmware

prometeo to Pyrrha wording

@krook @upkarlidder review needed, also can't seem to add my own reviewer


Could we have a better line editor?

While I was using git-cm, I noticed that the line editor which gets our information in each question is very limited. Could we try to find another one which has more features?
Some Limitations

We can't use the arrow keys to go back in the text position and delete a typo in the middle or something like that.
We can't use CTRL + left/right arrow to navigate around the words.
...

I did a little digging on the code and dependencies and there's no line editor. Basically git-cm calls dialoguer, which calls console, which calls stdin().read_line()...

I guess I found a way to fix the first limitation. There's a way to make dialoguer work with arrow key navigation.

That PR was an easy win, but if we want better line editor I think we would have to move to something like rustyline.
The best solution would be to have dialoguer adding it in itself, as requested in this issue on their repo.

I have a library lying around that I worked on early this year based on crossterm (I actually don't really like console). It manually implements the most basic readline shortcuts on top of it (like ctrl-w).
The problem with rustyline is that lists have to be implemented manually again, as it really only supports a single line. Not a huge deal, but given that I just opted to use crossterm and do it myself, as I really like their queueing API and I feel that the project is "more" actively maintained, i.e. PRs and issues get resolved faster. I also find the codebase to work with easier. And I already have some PRs in backlog that I'll open once I get time to look over them a last time :)
My library isn't public right now IIRC, it's similarly structured to inquirer-js though, with each prompt type being available as a single crate as well. Makes my potato laptop compile less, which makes me in turn happy haha.
Now thinking about it, I could also just use rusty line for the input prompt and drop the custom code for that prompt :thinking:

That looks nice! It would be great to see a better prompt library.
It would be good to "cut the tree" in the dependencies. Compilation times look too big for the project. At least it is a motivation to take a break :laughing:
I think the only think that would be "hard" to replace would be the Select prompt. The others are pretty straight-forward to change to rustyline.


AR world launches before device support check.

Ionicitrude is a great solution which will make all the ionic dev's lives simpler.
I have noticed a slight problem which causes the app to crash due to unsupported feature error. The AR world launches before the device check is confirmed to be supported.
Please address this issue.
Thank you.

As the complement, it should be noted that this problem occurs only when trying to launch an AR World right when the app starts.
In any case, the commit 49a6862b82a6e1a336cc3cb8710dfad492bfc903 should solve the problem.
It adds a new method to Ionicitude, the ready() method, which works very much like the $ionicPlatform.ready() method. You just need to encapsulate the code that you want to execute in an anonymous function, passed as the method parameter. This ensures that the code is executed only when Ionicitude has finished initializing itself.
Ionicitude.ready(function() {
    Ionicitude
        .launchAR('myAR')
        .then(function(success) {
            // React to successful launching
        }
        .catch(function(error) {
            // React to unsuccessful launching
        }
});

It also changes a little bit the init() function in that this method doesn't return the service, but act as a promise to which you can react (this was needed for implementing the ready() function). This shouldn't impact your code, though.
To test that this solution is convenient, please download the latest version on the dev branch. If this solves the problem, please report it here so that I can close the issue, update the doc and push these modifications to the master.
Thanks for your support :wink:

Fantastic, it’s working great. Thank you so much.


Upgrading from 1.5.2 to 1.5.4

I am trying to upgrade from fmriprep 1.5.2 to 1.5.4.
If I run fmrprep 1.5.4 with the same command line argument that worked for 1.5.2, the 1.5.4 now complains that I am missing an option.
    Running fMRIPREP version 1.5.4:
      * BIDS dataset path: /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripinput.
      * Participant list: ['TTTEMPSUB'].
      * Run identifier: 20200102-042619_5fdc5d07-5cca-4785-9028-ad271e9d524f.

Process Process-2:
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/run.py", line 687, in build_workflow
    work_dir=str(work_dir),
TypeError: init_fmriprep_wf() missing 1 required positional argument: 'fs_subjects_dir'

So I've added the following command line option (fs_subjects_dir) to point to where my freesurfer output is.

--fs-subjects-dir="$outdir/freesurfer/$bidsSub" \

However, now fmrprep is complaining that there is no such option.

fmriprep: error: unrecognized arguments: --fs-subjects-dir=fmripout/freesurfer/sub-TTTEMPSUB

I've tried without "=" and with fs_subjects_dir instead of fs-subjects-dir, but none of that seems to fix the problem. Could you help me troubleshoot?

hi @soichih - can you share the full command?

@mgxd
I was able to find the cause of the fs-subjects-dir issue (I think), but now I am seeing a different error message that I didn't see when I was running 1.5.2 version.
200106-17:19:07,412 nipype.workflow WARNING:
	 Storing result file without outputs
200106-17:19:07,413 nipype.workflow WARNING:
	 [Node] Error on "fmriprep_wf.single_subject_TTTEMPSUB_wf.func_preproc_ses_SSSES_task_facerecognition_run_1_wf.func_derivatives_wf.ds_bold_aparc_std" (/mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripworkdir/fmriprep_wf/single_subject_TTTEMPSUB_wf/func_preproc_ses_SSSES_task_facerecognition_run_1_wf/func_derivatives_wf/ds_bold_aparc_std)
200106-17:19:07,414 nipype.workflow ERROR:
	 Node ds_bold_aparc_std failed to run on host dev1.soichi.us.
200106-17:19:07,415 nipype.workflow ERROR:
	 Saving crash info to /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripout/fmriprep/sub-TTTEMPSUB/log/20200106-171837_3e4cb4e9-ee73-4f26-9172-d087bb31b223/crash-20200106-171907-hayashis-ds_bold_aparc_std-93acf1c8-0b0c-4a73-bcb9-08a12e2675b7.txt
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/legacymultiproc.py", line 381, in _send_procs_to_workers
    self.procs[jobid].run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 479, in run
    result = self._run_interface(execute=True)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 585, in _run_interface
    return self._run_command(execute)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 678, in _run_command
    result = self._interface.run(cwd=outdir)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 340, in run
    self._check_mandatory_inputs()
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 249, in _check_mandatory_inputs
    raise ValueError(msg)
ValueError: DerivativesDataSink requires a value for input 'in_file'. For a list of required inputs, see DerivativesDataSink.help()

Sorry for the moving target. Here is the command line I am executing.

singularity exec docker://poldracklab/fmriprep:1.5.4 /usr/local/miniconda/bin/fmriprep --notrack --resource-monitor --skip-bids-validation --md-only-boilerplate --stop-on-first-crash --use-plugin=multi_proc.yml --output-space T1w --force-bbr --use-syn-sdc --fs-license-file=license.txt --fs-subjects-dir=fmripout/freesurfer/sub-TTTEMPSUB --skull-strip-template=NKI --work-dir=fmripworkdir --participant_label=sub-TTTEMPSUB fmripinput fmripout participant

Here is the file structure inside my fmripinput
fmripinput
├── dataset_description.json
└── sub-TTTEMPSUB
    └── ses-SSSES
        ├── anat
        │   ├── sub-TTTEMPSUB_ses-SSSES_acq-mprage_run-1_T1w.json
        │   └── sub-TTTEMPSUB_ses-SSSES_acq-mprage_run-1_T1w.nii.gz
        ├── fmap
        │   ├── sub-TTTEMPSUB_ses-SSSES_acq-_run-_magnitude1.nii.gz
        │   ├── sub-TTTEMPSUB_ses-SSSES_acq-_run-_magnitude2.nii.gz
        │   ├── sub-TTTEMPSUB_ses-SSSES_acq-_run-_phase1.json
        │   ├── sub-TTTEMPSUB_ses-SSSES_acq-_run-_phase1.nii.gz
        │   ├── sub-TTTEMPSUB_ses-SSSES_acq-_run-_phase2.json
        │   └── sub-TTTEMPSUB_ses-SSSES_acq-_run-_phase2.nii.gz
        └── func
            ├── sub-TTTEMPSUB_ses-SSSES_task-facerecognition_run-1_bold.json
            └── sub-TTTEMPSUB_ses-SSSES_task-facerecognition_run-1_bold.nii.gz

5 directories, 11 files

@mgxd
singularity exec -e -B /home/hayashis/git/app-fmriprep/run.py:/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/run.py docker://poldracklab/fmriprep:1.5.4 /usr/local/miniconda/bin/fmriprep --notrack --resource-monitor --skip-bids-validation --md-only-boilerplate --stop-on-first-crash --use-plugin=multi_proc.yml --output-space T1w --force-bbr --use-syn-sdc --fs-license-file=license.txt --fs-subjects-dir=fmripout/freesurfer/sub-TTTEMPSUB --skull-strip-template=NKI --work-dir=fmripworkdir --participant_label=sub-TTTEMPSUB fmripinput fmripout participant

Can you share /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripout/fmriprep/sub-TTTEMPSUB/log/20200106-171837_3e4cb4e9-ee73-4f26-9172-d087bb31b223/crash-20200106-171907-hayashis-ds_bold_aparc_std-93acf1c8-0b0c-4a73-bcb9-08a12e2675b7.txt?

@effigies Here is the content of the log.
hayashis@dev1:~/git/app-fmriprep/fmripout/fmriprep/sub-TTTEMPSUB/log/20200106-171837_3e4cb4e9-ee73-4f26-9172-d087bb31b223(master*) $ cat crash-20200106-171907-hayashis-ds_bold_aparc_std-93acf1c8-0b0c-4a73-bcb9-08a12e2675b7.txt
Node: fmriprep_wf.single_subject_TTTEMPSUB_wf.func_preproc_ses_SSSES_task_facerecognition_run_1_wf.func_derivatives_wf.ds_bold_aparc_std
Working directory: /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripworkdir/fmriprep_wf/single_subject_TTTEMPSUB_wf/func_preproc_ses_SSSES_task_facerecognition_run_1_wf/func_derivatives_wf/ds_bold_aparc_std

Node inputs:

base_directory = /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripout
check_hdr = True
compress = <undefined>
desc = aparcaseg
extra_values = <undefined>
in_file = <undefined>
keep_dtype = False
meta_dict = <undefined>
source_file = /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripinput/sub-TTTEMPSUB/ses-SSSES/func/sub-TTTEMPSUB_ses-SSSES_task-facerecognition_run-1_bold.nii.gz
space = <undefined>
suffix = dseg

Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/legacymultiproc.py", line 381, in _send_procs_to_workers
    self.procs[jobid].run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 479, in run
    result = self._run_interface(execute=True)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 585, in _run_interface
    return self._run_command(execute)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 678, in _run_command
    result = self._interface.run(cwd=outdir)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 340, in run
    self._check_mandatory_inputs()
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 249, in _check_mandatory_inputs
    raise ValueError(msg)
ValueError: DerivativesDataSink requires a value for input 'in_file'. For a list of required inputs, see DerivativesDataSink.help()

Okay. I see the issue, but I haven't quite tracked down the bug.

--output-space T1w means no standard spaces are being specified. This is fine.
Somehow standard_spaces is non-empty here:

https://github.com/poldracklab/fmriprep/blob/63a661b20ec68e1aa08949d5dd6fd17381ea1d52/fmriprep/workflows/bold/outputs.py#L152
Leading to this section getting run:
https://github.com/poldracklab/fmriprep/blob/63a661b20ec68e1aa08949d5dd6fd17381ea1d52/fmriprep/workflows/bold/outputs.py#L183-L199
So ds_bold_aparc_std shouldn't even be getting created, but it is, with no input file. Note that space is also undefined, so the workflow is consistent, in that it doesn't think there's a template to be provided.
So the problem lies somewhere around here:
https://github.com/poldracklab/fmriprep/blob/63a661b20ec68e1aa08949d5dd6fd17381ea1d52/fmriprep/workflows/bold/base.py#L278-L280
https://github.com/poldracklab/fmriprep/blob/63a661b20ec68e1aa08949d5dd6fd17381ea1d52/fmriprep/workflows/bold/base.py#L437-L447
My guess is that std_spaces is the internal variable for all spaces that need to be resampled to, and we need to update this to be the intersection with the output spaces.
@mgxd WDYT?

I think @effigies is right - @mgxd we should push priority of #1892 up. IMHO, that issue should resolve this bug.

@soichih In the short term, using --output-space T1w MNI152Nlin2009c will almost certainly resolve the problem, if you just need to get moving again.

@effigies @oesteban @mgxd Thanks for the help!
I tried adding MNI152Nlin2009c / MNI152Nlin2009cAsym to the list of spaces, but I can't seem to get around this error message.
  File "/usr/local/miniconda/lib/python3.7/site-packages/smriprep/cli/utils.py", line 53, in output_space
    correctly installed and contains the given template identifiers.""".format(template))
ValueError: Template identifier "MNI152Nlin2009cAsym" not found. Please, make sure TemplateFlow is correctly installed and contains the given template identifiers.

I am setting it like this..
singularity exec docker://poldracklab/fmriprep:1.5.4 /usr/local/miniconda/bin/fmriprep --notrack --resource-monitor --skip-bids-validation --md-only-boilerplate --stop-on-first-crash --use-plugin=multi_proc.yml --output-spaces T1w MNI152Nlin2009cAsym --force-bbr --use-syn-sdc --fs-license-file=license.txt --fs-subjects-dir=fmripout/freesurfer/sub-TTTEMPSUB --skull-strip-template=NKI --work-dir=fmripworkdir --participant_label=sub-TTTEMPSUB fmripinput fmripout participant

I tried both --output-space and --output-spaces but neither one worked.. unfortunately.
By the way, we've been having to use both --output-space to set T1w/fsaverage and --output-spaces to set other spaces. Is this expected?

MNI152Nlin2009cAsym -> MNI152NLin2009cAsym
On Mon, Jan 6, 2020, 12:38 Soichi Hayashi<EMAIL_ADDRESS>wrote:

@effigies https://github.com/effigies @oesteban
https://github.com/oesteban @mgxd https://github.com/mgxd Thanks for
the help!
I tried adding MNI152Nlin2009c / MNI152Nlin2009cAsym to the list of
spaces, but I can't seem to get around this error message.
File "/usr/local/miniconda/lib/python3.7/site-packages/smriprep/cli/utils.py", line 53, in output_space
correctly installed and contains the given template identifiers.""".format(template))
ValueError: Template identifier "MNI152Nlin2009cAsym" not found. Please, make sure TemplateFlow is correctly installed and contains the given template identifiers.
I am setting it like this..
singularity exec docker://poldracklab/fmriprep:1.5.4 /usr/local/miniconda/bin/fmriprep --notrack --resource-monitor --skip-bids-validation --md-only-boilerplate --stop-on-first-crash --use-plugin=multi_proc.yml --output-spaces T1w MNI152Nlin2009cAsym --force-bbr --use-syn-sdc --fs-license-file=license.txt --fs-subjects-dir=fmripout/freesurfer/sub-TTTEMPSUB --skull-strip-template=NKI --work-dir=fmripworkdir --participant_label=sub-TTTEMPSUB fmripinput fmripout participant
I tried both --output-space and --output-spaces but neither one worked..
unfortunately.
By the way, we've been having to use both --output-space to set
T1w/fsaverage and --output-spaces to set other spaces. Is this expected?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/1921?email_source=notifications&email_token=AAESDRWEPUF6GX5QDXMD2WLQ4OJDBA5CNFSM4KB6OOJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIGWTWA#issuecomment-571304408,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAESDRVNSIZMB75L3Q3VVSDQ4OJDBANCNFSM4KB6OOJQ
.

@effigies you are right, I encountered this same issue when debugging #1915
@oesteban and I were just discussing the reworking of output spaces and ensuring the proper "internal" normalizations are included so that the workflow always runs regardless of outputs.

By the way, we've been having to use both --output-space to set T1w/fsaverage and --output-spaces to set other spaces. Is this expected?

I think actually you need --output-spaces for everything now. --output-space and other deprecated arguments were removed in 476e1b2cbb46342386113d96168a7d19c3406c6c.

@effigies I tried --output-spaces for all template and it seems to work now with 1.5.4 container. We were having some problems before. As far as volume output goes, everything seems to work now.
I then tested with surface output (--output-spaces fsaverage:den-10k MNI152NLin2009cAsym)

singularity exec docker://poldracklab/fmriprep:1.5.4 /usr/local/miniconda/bin/fmriprep --notrack --resource-monitor --skip-bids-validation --md-only-boilerplate --stop-on-first-crash --use-plugin=multi_proc.yml --output-spaces fsaverage:den-10k MNI152NLin2009cAsym --force-bbr --use-syn-sdc --fs-no-reconall --fs-license-file=license.txt --fs-subjects-dir=fmripout/freesurfer/sub-TTTEMPSUB --skull-strip-template=NKI --work-dir=fmripworkdir --participant_label=sub-TTTEMPSUB fmripinput fmripout participant

After running for a few hours, it eventually crashed with this error message.
Node: fmriprep_wf.single_subject_TTTEMPSUB_wf.func_preproc_ses_SSSES_task_rest_run_1_wf.carpetplot_wf.select_std
Working directory: /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripworkdir/fmriprep_wf/single_subject_TTTEMPSUB_wf/func_preproc_ses_SSSES_task_rest_run_1_wf/carpetplot_wf/select_std

Node inputs:

key = MNI152NLin2009cAsym
keys = ['fsaverage', 'MNI152NLin2009cAsym']
std2anat_xfm = ['/mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripworkdir/fmriprep_wf/single_subject_TTTEMPSUB_wf/anat_preproc_wf/anat_norm_wf/_template_MNI152NLin2009cAsym./registration/ants_t1_to_mniInverseComposite.h5']

Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/legacymultiproc.py", line 381, in _send_procs_to_workers
    self.procs[jobid].run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 479, in run
    result = self._run_interface(execute=True)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 585, in _run_interface
    return self._run_command(execute)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 678, in _run_command
    result = self._interface.run(cwd=outdir)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 384, in run
    outputs = self.aggregate_outputs(runtime)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 461, in aggregate_outputs
    predicted_outputs = self._list_outputs()  # Predictions from _list_outputs
  File "/usr/local/miniconda/lib/python3.7/site-packages/niworkflows/interfaces/utility.py", line 147, in _list_outputs
    for k in self._fields}
  File "/usr/local/miniconda/lib/python3.7/site-packages/niworkflows/interfaces/utility.py", line 147, in <dictcomp>
    for k in self._fields}
IndexError: list index out of range

Okay. That's https://github.com/poldracklab/fmriprep/blob/7e5b2f1288f53ed54413d997a615a91a999a3597/fmriprep/workflows/bold/confounds.py#L476-L479
which uses KeySelect.
It looks like it's expecting std2anat_xfm to be a two-element list, with a value for each fsaverage and MNI152NLin2009cAsym, and it's instead a one-element list.
This looks like a bug where fsaverage should have been filtered out.
@mgxd @oesteban Will this be covered in an existing issue/PR or should I open a new one?

this falls under the reworking of output spaces (#1920) and should be covered there.

I think that may be a misfired reference. But anyway, let me know if I can help push on that fix.

@soichih We determined that the full fix to your issue may take a while, so I'm going to be working on a short-term fix while Mathias works toward the long-term solution in #1915. Working now to replicate on a small dataset. I'll aim to have a fix by Monday.

@effigies Thanks for the update, and thank you all for working on this issue.

@soichih Proposed #1932. It turned out to be ridiculously easy. If you're able to patch in a branch (not as easy in Singularity), then you can try that branch, to see if anything else comes up.
I am seeing the problem, though, that no fsaverage outputs are being generated.
While I'm here, I'd just note that there's an issue with two of your options:

--fs-no-reconall will not attempt to use FreeSurfer surfaces at all.
--fs-subjects-dir=fmripout/freesurfer/sub-TTTEMPSUB should point to the subjects directory, not the individual subject within the subjects directory.

It seems that there's some ambiguity here and it would be good to figure out the set of behaviors we want to support and an intuitive way to access them with flags. See #1930.

I will try overriding base.py with the PR version by ..
singularity exec -e \
    docker://poldracklab/fmriprep:1.5.4 \
    -e -B $(pwd)/base.py:/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/bold/base.py \
    /usr/local/miniconda/bin/fmriprep ...

I think I had to add --fs-no--reconall to workaround some problem, but maybe it was caused by setting --fs-subjects-dir to a incorrect path? I just removed --fs-no-reconall and updated --fs-subjects path - along with the patched version of base.py. I will test it and report back to you.

I think you can just drop the --fs-subjects-dir, anyway, as it will default to <OUTPUT_DIR>/freesurfer.

OK. I've droped both --fs-no-reconall and --fs-subjects-dir options.
I've fed --output-spaces fsaverage:den-10k to the container and it's failing with this error message.
/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/run.py:547: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  plugin_settings = loadyml(f)
200113-19:35:13,947 nipype.workflow IMPORTANT:

    Running fMRIPREP version 1.5.4:
      * BIDS dataset path: /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripinput.
      * Participant list: ['TTTEMPSUB'].
      * Run identifier: 20200113-193513_1bfa4140-f059-4c32-b6ea-9163db2f05e5.

200113-19:35:14,585 nipype.utils INFO:
	 Running nipype version 1.3.1 (latest: 1.4.0)
200113-19:35:17,32 nipype.workflow IMPORTANT:
	 Creating bold processing workflow for "/mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripinput/sub-TTTEMPSUB/ses-SSSES/func/sub-TTTEMPSUB_ses-SSSES_task-rest_run-1_bold.nii.gz" (0.11 GB / 193 TRs). Memory resampled/largemem=0.44/0.65 GB.
200113-19:35:17,52 nipype.workflow IMPORTANT:
	 No single-band-reference found for sub-TTTEMPSUB_ses-SSSES_task-rest_run-1_bold.nii.gz
Process Process-2:
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/cli/run.py", line 669, in build_workflow
    work_dir=str(work_dir),
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/base.py", line 265, in init_fmriprep_wf
    use_syn=use_syn,
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/base.py", line 622, in init_single_subject_wf
    use_syn=use_syn,
  File "/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/bold/base.py", line 454, in init_func_preproc_wf
    fslr_density=fslr_density,
TypeError: init_func_derivatives_wf() got an unexpected keyword argument 'fslr_density'

I will try without specifying density attribute.

Try re-fetching the branch. I realized I'd based it off the master branch, not maint/1.5.x, and this is going to aim to be a bug-fix release.

Yup, support for density labels of the fsaverage template are not fully implemented yet - that will change in the output spaces rework.

Ok. I 've re-fetched the bold.py from the PR, and updated the space to --output-spaces fsaverage5
Now it's saying ds_bold_aparc_std failed to run
singularity exec -e -B /home/hayashis/git/app-fmriprep/base.py:/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/bold/base.py docker://poldracklab/fmriprep:1.5.4 /usr/local/miniconda/bin/fmriprep --notrack --resource-monitor --skip-bids-validation --md-only-boilerplate --stop-on-first-crash --use-plugin=multi_proc.yml --output-spaces fsaverage5 --force-bbr --use-syn-sdc --fs-license-file=license.txt --skull-strip-template=NKI --work-dir=fmripworkdir --participant_label=sub-TTTEMPSUB fmripinput fmripout participant
Docker image path: index.docker.io/poldracklab/fmriprep:1.5.4
Cache folder set to /mnt/scratch/hayashis/singularity/cache/docker
...
200113-19:55:20,34 nipype.workflow WARNING:
	 Storing result file without outputs
200113-19:55:20,35 nipype.workflow WARNING:
	 [Node] Error on "fmriprep_wf.single_subject_TTTEMPSUB_wf.func_preproc_ses_SSSES_task_rest_run_1_wf.func_derivatives_wf.ds_bold_aparc_std" (/mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripworkdir/fmriprep_wf/single_subject_TTTEMPSUB_wf/func_preproc_ses_SSSES_task_rest_run_1_wf/func_derivatives_wf/ds_bold_aparc_std)
200113-19:55:20,37 nipype.workflow ERROR:
	 Node ds_bold_aparc_std failed to run on host dev1.soichi.us.
200113-19:55:20,87 nipype.workflow ERROR:
	 Saving crash info to /mnt/scratch/hayashis/syncthing/git/app-fmriprep/fmripout/fmriprep/sub-TTTEMPSUB/log/20200113-195451_5d481ed8-f7f5-4a3c-ab13-b1dc4cda1e94/crash-20200113-195520-hayashis-ds_bold_aparc_std-3b2e6e3c-f696-4b1a-b94a-7063de078ae1.txt
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/legacymultiproc.py", line 381, in _send_procs_to_workers
    self.procs[jobid].run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 479, in run
    result = self._run_interface(execute=True)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 585, in _run_interface
    return self._run_command(execute)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 678, in _run_command
    result = self._interface.run(cwd=outdir)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 340, in run
    self._check_mandatory_inputs()
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 249, in _check_mandatory_inputs
    raise ValueError(msg)
ValueError: DerivativesDataSink requires a value for input 'in_file'. For a list of required inputs, see DerivativesDataSink.help()

It looks like you dropped the MNI output space. Can you re-add it and verify that this works? I'll look into fixing the above crash as well.
singularity exec -e \
    -B /home/hayashis/git/app-fmriprep/base.py:/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/bold/base.py \
    docker://poldracklab/fmriprep:1.5.4 /usr/local/miniconda/bin/fmriprep \
    --notrack --resource-monitor --skip-bids-validation --md-only-boilerplate \
    --stop-on-first-crash --use-plugin=multi_proc.yml \
    --output-spaces fsaverage5 MNI152NLin2009cAsym \
    --force-bbr --use-syn-sdc --fs-license-file=license.txt \
    --skull-strip-template=NKI --work-dir=fmripworkdir \
    --participant_label=sub-TTTEMPSUB fmripinput fmripout participant

Thanks. I've put it back. I am not sure why I removed it. The process seems to be progressing now. I will let you know if it finishes this time.
@mgxd So I should stay away from setting the density modifier? What are the spaces that are currerntly supported other than fsaverage5?

@oesteban @mgxd I don't really remember. What happened to auto-inserting MNI into output spaces? Because failing to explicitly list it now has several failures, such as the aparc/aseg outputs (easy to fix) such as SyN-SDC not being able to run (no template from sMRIPrep to query).

I believe the MNI template is auto inserted only if no --output-spaces are provided, or CIFTI/ICA flags are provided.

@soichih I've pushed 1.5.5. You'll still need to include MNI152NLin2009c in your output spaces.
Let's see how that goes, and open a new issue with any bugs you encounter going forward.

Thanks. I will switch to container v1.5.5 and test it.


On going project development & support

Hi there,
My organisation are moving towards Docker and want to use ECS Fargate. Whilst we would use CloudFormation to manage the setting up of the infrastructure & ECS services etc. this CLI looks fantastic for developers to use, to get info on what is running, view logs, run one off tasks etc.
However, I recently came across the ECS CLI v2.
I would like to know where this fargatecli project stands in terms of future development & support?
Is it going to be sidelined in favour of the ECS CLI v2? Or can I safely start to invest in adoption of this tool?
Many thanks.

fwiw, our fork is actively maintained.  This approach has worked well for us, however, we use terraform instead of cloud formation.
https://github.com/turnerlabs/fargate-create

Hi, AWS employee and one of the Fargate CLI maintainers here. We are putting a lot of investment into the AWS CLI v2 and I think that is probably the better route to take.

@PaulMaddox perhaps it would be advisable to place a notice that this particular repo is no longer under active development and will be maintained only on a continuity of service level?

Added a clarification notice to the README - aa1c09cd404ecdee91a83b4f59171f790d6b480b
AWS Copilot is the better option these days, and is actively maintained by the AWS Containers team.
Thanks all.

Thanks @PaulMaddox for the fast response!


Error due to default value of manifest_config

If manifest_config is not specified when pushing by oras-py, the implementation currently treats manifest_config as a completely empty string.
https://github.com/oras-project/oras-py/blob/02c5bdacb54b5d7d6c152fcdbc0e11cf69b4900f/oras/oci.py#L130-L136
I was using google artifact registry and confirmed that push fails if manifest_config is an empty string.
The current workaround (or maybe this is the right way) is to create a file with only "{}" and read that file to successfully execute the push.
If manifest_config was not specified, why not change it so that the contents of manifest_config are treated as "{}"?
code
import oras.client
import oras.logger
from pathlib import Path
from tempfile import TemporaryDirectory
import os
import json

oras.logger.setup_logger(debug=True, quiet=False)

pwd = Path(__file__).parent.resolve()

client = oras.client.OrasClient()
client.login(username="oauth2accesstoken", password="password")

with TemporaryDirectory() as tmp:
    config_path = os.path.join(tmp, "config.json")
    with open(config_path, "w") as f:
        json.dump({}, f)
    res = client.push(files=[str(pwd / "hoge.txt")], target="asia-northeast1-docker.pkg.dev/example-repository/tmp/oras-test:v2", manifest_config=config_path)
print("sucess push with config file")

res = client.push(files=[str(pwd / "hoge.txt")], target="asia-northeast1-docker.pkg.dev/example-repository/tmp/oras-test:v2")
print("success push")

log
Preparing layer {'mediaType': 'application/vnd.oci.image.layer.v1.tar', 'size': 13, 'digest': 'sha256:8f8ad85c91228f6b241b95ecca626a4e9701d7c072ca0c6c001677d797a4af02', 'annotations': {'org.opencontainers.image.title': 'hoge.txt'}}
Service: asia-northeast1-docker.pkg.dev
Scope: repository:example-repository/tmp/oras-test:pull,push
Preparing config {'mediaType': 'application/vnd.unknown.config.v1+json', 'size': 2, 'digest': 'sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a'}
Service: asia-northeast1-docker.pkg.dev
Scope: repository:example-repository/tmp/oras-test:pull,push
Service: asia-northeast1-docker.pkg.dev
Scope: repository:example-repository/tmp/oras-test:pull,push
Successfully pushed asia-northeast1-docker.pkg.dev/example-repository/tmp/oras-test:v2
sucess push with config file
Preparing layer {'mediaType': 'application/vnd.oci.image.layer.v1.tar', 'size': 13, 'digest': 'sha256:8f8ad85c91228f6b241b95ecca626a4e9701d7c072ca0c6c001677d797a4af02', 'annotations': {'org.opencontainers.image.title': 'hoge.txt'}}
Service: asia-northeast1-docker.pkg.dev
Scope: repository:example-repository/tmp/oras-test:pull,push
Preparing config {'mediaType': 'application/vnd.unknown.config.v1+json', 'size': 0, 'digest': 'sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'}
Service: asia-northeast1-docker.pkg.dev
Scope: repository:example-repository/tmp/oras-test:pull,push
Service: asia-northeast1-docker.pkg.dev
Scope: repository:example-repository/tmp/oras-test:pull,push
Trying with provided Basic Authorization...
failed to read config blob: sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Traceback (most recent call last):
  File "/Users/linsho/repos/oras-py/tmp/./tmp_log.py", line 22, in <module>
    res = client.push(files=[str(pwd / "hoge.txt")], target="asia-northeast1-docker.pkg.dev/example-repository/tmp/oras-test:v2")
  File "/Users/linsho/repos/oras-py/tmp/venv/lib/python3.10/site-packages/oras/client.py", line 132, in push
    return self.remote.push(*args, **kwargs)
  File "/Users/linsho/repos/oras-py/tmp/venv/lib/python3.10/site-packages/oras/provider.py", line 755, in push
    self._check_200_response(self.upload_manifest(manifest, container))
  File "/Users/linsho/repos/oras-py/tmp/venv/lib/python3.10/site-packages/oras/provider.py", line 593, in _check_200_response
    raise ValueError(f"Issue with {response.request.url}: {response.reason}")
ValueError: Issue with https://asia-northeast1-docker.pkg.dev/v2/example-repository/tmp/oras-test/manifests/v2: Not Found

environment
attrs==23.1.0
certifi==2023.7.22
charset-normalizer==3.3.1
idna==3.4
jsonschema==4.19.1
jsonschema-specifications==2023.7.1
oras==0.1.25
referencing==0.30.2
requests==2.31.0
rpds-py==0.10.6
urllib3==2.0.7

That would be a good solution. Would you care to open a PR to fix this?


Make Scope property on AuthorizeResponse settable

In the OAuth2 authorization_code flow (no OIDC) the Scope property is always included in the AuthorizeResponse. We would like to exclude it on this response so we can create the following response:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
(without including the granted scopes).
This would conform the following section:
http://tools.ietf.org/html/rfc6749#section-4.1.2
It's readonly and defaults to: Request?.ValidatedScopes?.GrantedResources?.ToScopeNames()?.ToSpaceSeparatedString();
Would it be possible to create a (private) set so we can override it and construct a response on the Authorize endpoint? We could probably change this in de override of the CreateCodeAsync in the AuthorizeResponseGenerator.

why?

Data minimalization, the (external) client breaks because there is more information in the response. I realize that they don't comply the spec (don't ask..).
On the other hand, I think it should nice to construct a response that matches the spec exactly without additional parameters.
I can probably do a PR if you're open to it.

We need to discuss this first.

Sure -- keep me posted about the progress.

Have you got a chance to look at this? Is there anything I can do to help?

Sorry, we don't plan on doing this. Sorry.


Add distroless containers

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[ ] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[ ] All package sources are available
[ ] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[ ] All source files have up-to-date hashes in the *.signatures.json files
[ ] sudo make go-tidy-all and sudo make go-test-coverage pass
[ ] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary

This PR enables creation of "distroless" mariner containers, a lightweight minimal containers suitable for static apps.
Change Log

Change
Change
Change

Does this affect the toolchain?

YES
Test Methodology

Pipeline build id: xxxx

Remove tarballs


[Bug] Potential Logic Error in Memory Capacity Check for Distributed Setup

https://github.com/sgl-project/sglang/blob/62757db6f0f09a6dff15b1ee1ac3029602951509/python/sglang/srt/model_executor/model_runner.py#L115-L124
There seems to be a logic error in the code that checks for unbalanced GPU memory capacity in a distributed setup. The current implementation compares the available memory on a specific GPU to 90% of the minimum available memory across all GPUs, which may not correctly identify situations where GPU memory is unbalanced.
Proposed Solution:
- if total_local_gpu_memory < total_gpu_memory * 0.9:
+ if total_gpu_memory < total_local_gpu_memory * 0.9:

Good catch! Could you submit a PR to fix this?

Good catch! Could you submit a PR to fix this?

Sure, I will fixed this with XVERSE models support PR in this week.

Fixed by https://github.com/sgl-project/sglang/pull/1194


I am only getting google.sent_time, from, google.message_id, collapse_key with firbasePlugin.on

When the app is in foreground, everything working properly. I am getting a notification plus the data message inside the onMessageReceived method.
But when app is in background, I am getting notification in system tray. And when I click on the control, it goes to the main activity. And When I parse intent.getExtras();, I am getting only this key data - google.sent_time, from, google.message_id, collapse_key.

@abmnukmr : I had the same problem and after 2hrs looking on Google, finally I found the problem:
The message to send to Firebase API should be something like this:
const content = {     data: {         title: title,         body: message     },     notification: {         title: title,         body: message     },     token: token.value };
The data property will be acted as data payload when user tap on the notification and the notification is for displaying data when app in foreground.
Hope this help!

closing as resolved


How to random crop in imgaug?

In pytorch, I used
transforms.Resize((300,300)),
transforms.RandomCrop((224, 224)),

How should I do with imgaug to obtain the same result as above? Thanks

I guess you could use CropAndPad or Crop, but I'm not sure. I usually use the RandomResizedCrop from PyTorch. Maybe it's better to ask in the imgaug repository.


iframe allowFullScreen

using 1.6.4, iframe does not allow for fullscreen view. To fix the issue I added the setAttribute methods as follows:
jquery.colorbox.js
iframe.allowFullScreen = true; iframe.setAttribute("allowFullScreen", true);
jquery.colorbox-min.js
i.allowFullScreen=!0,i.setAttribute("allowFullScreen", !0),
Tested before and after in firefox 48.0.2 and chrome 49.0.2623.112

As of 1.6.2, the attribute has been renamed allowFullscreen as opposed to allowFullScreen.

@tklawsuc Can you explain to me how to reproduce the problem you were experiencing? I need to be able to verify that adding setAttribute resolves some issue over directly access of the attribute.  Thanks.

@matrefeytontias is correct, you just need to use version 1.6.2 or newer.  You say you are using 1.6.4, but the code you posted has to have been from something older than 1.6.2.  Changing the property name from 'allowFullScreen' to 'allowFullscreen' did fix the issue you are describing.


[bug report] cascade selector multiple choice, select any level option props.checkStrictly  =True sets the parent-child node. It has no effect to deselect the association

Element UI version
2.15.0
OS/Browsers version
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36"
Vue version
2.6.11
Reproduction Link
https://codepen.io/pen/
Steps to reproduce
点击一级二级展开选中第三级的节点
What is Expected?
多选任意一项选中哪一项，拿到哪一项的值，不包含父级节点
What is actually happening?
多选任意一项选中一项，拿到该项整个一列的值，含父级节点

https://codepen.io/hassan-bai/pen/eYBzOOx


The trailCursorEffect feature is not functioning correctly in the latest version of VSCode.

This has been automatically resolved in the latest vscode.

is this still working? I tested on Version: 1.92.0 (Universal) but it seems that nothing happened after I followed the instruction...

is this still working? I tested on Version: 1.92.0 (Universal) but it seems that nothing happened after I followed the instruction...

https://github.com/user-attachments/assets/2008059d-ba2b-4b69-b124-979605fee3ef
Yes works fine


[BUG] Can't deploy from aarch64-darwin to x86_64-linux

Field
Description

Plugin
N/A

Nixpkgs
24.05

Home Manager
24.05

[x] I have read the FAQ and my bug is not listed there.

Description
Trying to deploy a flake which includex nix-community/nixvim from an M1 Mac to an x86-64 NixOS machine using deploy-rs produces the following error:
error: a 'x86_64-linux' with features {} is required to build '/nix/store/dknd53ikkkjvk5jgw0hcwmby9ddpj9v1-init.lua.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}

#1637  seemed to fix a similar error in the file nixpkgs-nixvim-doc.drv, but the issue with init.lua.drv remains.
It seems to be related to the IFDs mentioned in this issue:  #1154
Minimal, Reproducible Example (MRE)

Include the nix-community/nixvim flake in flake.nix inputs
Run nix flake update
Attempt to deploy your flake from an aarch64 Mac to a x86-64 NixOS machine using deploy-rs, for instance:

deploy -s --remote-build ".?submodules=1#spencer"

Additionally, same error happens when deploying with plain nixos-rebuild:
nixos-rebuild switch --fast -j auto --use-remote-sudo --impure --flake .\?submodules=1#emily --target-host emily --build-host emily
building the system configuration...
error:
       … while calling the 'head' builtin

         at /nix/store/l9ghpp1wk6hyng0g56vqzc923mdmwrsn-source/lib/attrsets.nix:1575:11:

         1574|         || pred here (elemAt values 1) (head values) then
         1575|           head values
             |           ^
         1576|         else

       … while evaluating the attribute 'value'

         at /nix/store/l9ghpp1wk6hyng0g56vqzc923mdmwrsn-source/lib/modules.nix:809:9:

          808|     in warnDeprecation opt //
          809|       { value = builtins.addErrorContext "while evaluating the option `${showOption loc}':" value;
             |         ^
          810|         inherit (res.defsFinal') highestPrio;

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: a 'x86_64-linux' with features {} is required to build '/nix/store/dknd53ikkkjvk5jgw0hcwmby9ddpj9v1-init.lua.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}

Just to confirm: removing nixvim from your config resolves the issue?
I have a feeling this is related to how flakes have one "system" variable, while nixpkgs actually needs a distinct host and target system. See https://nix.dev/tutorials/cross-compilation.html and https://nixos.wiki/wiki/Cross_Compiling
Flakes usually just assume system is the same for both host & target.

Yes, removing nixvim from the config resolves the issue:
Without nixvim:
deploy --dry-activate  -s --remote-build ".?submodules=1#emily"                                                                                ~~~
🚀 ℹ [deploy] [INFO] Building profile `system` for node `emily` on remote host
would activate the configuration...
would restart systemd
would reload the following units: dbus.service
would restart the following units: home-manager-notthebee.service
🚀 ℹ [deploy] [INFO] Completed dry-activate!

With nixvim:
deploy --dry-activate  -s --remote-build ".?submodules=1#emily"
🚀 ℹ [deploy] [INFO] Evaluating flake in .?submodules=1
error:
       … while evaluating attribute 'nodes'

         at «string»:4:25:

            3|                       (deploy // {
            4|                         nodes = {
             |                         ^
            5|                           inherit (deploy.nodes) "emily";

       … while evaluating attribute 'emily'

         at «string»:5:49:

            4|                         nodes = {
            5|                           inherit (deploy.nodes) "emily";
             |                                                 ^
            6|                         };

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: a 'x86_64-linux' with features {} is required to build '/nix/store/dknd53ikkkjvk5jgw0hcwmby9ddpj9v1-init.lua.drv', but I am a 'aarch64-darwin' with features {apple-virt, benchmark, big-parallel, nixos-test}

I came up with a simple workaround. This shell script runs nix flake update, rsyncs the current folder to the machine's /etc/nixos, and runs nixos-rebuild switch --upgrade. It takes the machine's hostname as an argument
#!/usr/bin/env zsh

nix flake update
rsync -q -avx --delete ./ $1:/etc/nixos/
ssh -t $1 'cd /etc/nixos && sudo nixos-rebuild switch --impure --upgrade --flake .\?submodules=1#$1'

Thank you @notthebee for sharing this workaround.
I am having trouble seeing if nixvim really is the problem here...
I have never tried doing cross-architecture deployment.
The only thing I know is that our entire test suite succeeds on all four main architectures.

Does this commit help at all?
nix flake lock --override-input nixvim github:MattSturgeon/nixvim/d6e4c98fa767fd1eb6032ca1b0e8d2552590e014

Unfortunately it doesn't
error: attribute 'pkgs' missing

       at /nix/store/6p95y71c4baahvhf13pj7nyjdn0q9g1z-source/lib/modules.nix:508:28:

          507|         builtins.addErrorContext (context name)
          508|           (args.${name} or config._module.args.${name})
             |                            ^
          509|       ) (lib.functionArgs f);

This might be fixed by #1818

This may have been fixed by #1818.

I can confirm that 367380b seems to fix this problem for me (very similar situation to the original issue). Furthermore, using the parent (8fbcfcb) fails. I would love to see this backported to 24.05; is there anything I can do to help this process along? I haven't contributed to this project before but would happily do so.

I can confirm that 367380b seems to fix this problem for me

Thanks for confirming!
I'll mark this as closed, but it can be reopened if others find they can still reproduce the issue.

I would love to see this backported to 24.05

Realistically, I think you'll have to wait for 24.11.
We would have to remove all instances of IFD (#1818 was the last IFD in main, but there were others before).
We'd have to be careful backporting to 24.05 to ensure there are no breaking changes, too. E.g. we removed the (internal) option initContent in another PR.

Realistically, I think you'll have to wait for 24.11.
We would have to remove all instances of IFD (#1818 was the last IFD in main, but there were others before).

Ah, makes sense. I'll switch to unstable/main in the interim. Thanks!


Trivial test improvements

This fixes one spurious failure on macOS, and replaces some panics with an ordinary test failure.
(This is by no means everything necessary to build with unit tests on macOS; that needs also https://github.com/mtrmac/libpod/tree/tests-WIP .)

LGTM, but be warned that our test suite is having a bad week, so I doubt you'll get reasonable results out of our CI.
The current errors do seem halfway reasonable, though - you might have a missing vendor?

LGTM
@rh-atomic-bot r+

Tests are green - @rhatdan @umohnani8 @TomSweeneyRedHat PTAL

@rh-atomic-bot r+

@rh-atomic-bot retry


Etacuts

eta jet cut for all processes with jets, eta lepton cut and pt lepton cut for VH leptonic

ttH/tqH missing cuts on W decay products. Current cut on top is ok only if it is stable.

I know, this is exactly the same as before except that there are now eta cuts too.
ZZ->4l doesn't have any cuts either.  We can add them later if we want.  I don't want to or have time to right now.


refactor(tikv/pd, tikv/tikv): change the prow configuration for the pd and tikv repository

What's Changed:

replace "ti-community-lgtm" and "ti-community-merge" plugin with "lgtm" and "approve" plugins.
update the auto response message for migration tips.
update the branch protection rules for pd and tikv for migration.

Fixes #1064
Fixes #1063
Signed-off-by: wuhuizuo<EMAIL_ADDRESS>

/hold
it should un-hold by @wuhuizuo  to merge it.

[ ] auto sync OWNERS for hotfix branches.
[ ] cherry-pick OWNERS files to LTS release branches.

/unhold

/hold

/unhold


Explore cross compilation

Helge does cross compilation for AWS lamba using swift build -destination (see http://www.alwaysrightinstitute.com/macrolambda/)
If this is reliable, this would probably be a less resource intensive way to test linux builds.
Recording it here for reference mainly. Unless the gains are massive or our resources constrained it's better to build the same way users would.

Some more info in this twitter exchange: https://twitter.com/helje5/status/1293477974512107521

Close for now, reopen when needed.


chore: inverting symlink origin and destination

The <rootDir>/CONTRIBUTING.md is the actual Markdown file.
The <rootDir>/docs/CONTRIBUTING.md is the symlink, pointing to the former.
This should guarantee that:

Users are presented with the original rendered Markdown when clicking on it (on <rootDir>/)
The documentation can still follow the symlink at build time (from <rootDir>/docs/)

Close #693

This is a re-fix on top of #694

@camsjams Thank you. I've reopened the issue.


Restructured examples

I added linting on examples and automated it in the tox file + added example using streamlit.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@bb923c5). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #9   +/-   ##
=========================================
  Coverage          ?   81.73%
=========================================
  Files             ?       10
  Lines             ?      416
  Branches          ?        0
=========================================
  Hits              ?      340
  Misses            ?       76
  Partials          ?        0

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 bb923c5...4dbca30. Read the comment docs.


Firebase UI storage 1.2.0 is not loading images

  `final StorageReference islandRef = ...;
    ImageView imageView = ...;

    // Load the image using Glide
    Glide.with(context.getApplicationContext())
            .using(new FirebaseImageLoader())
            .load(islandRef)
            .placeholder(R.drawable.profile_image_place_holder)
            .into(imageView);`

Gradle version :- compile 'com.google.firebase:firebase-storage:10.2.6'
&& compile 'com.firebaseui:firebase-ui-storage:1.2.0'
Images are not loading after updating to this version of firebase SDK.

@mark922 what happens if you use com.google.firebase:firebase-storage:10.2.1?

Use version minor than 10.2.1 will make conflict with Firebase performance tools

Same problem here guys. Need to fallback to version 10.2.1

Using version com.google.firebase:firebase-storage:10.2.1 and com.google.firebase:firebase-storage:10.2.0 and Glide version compile com.github.bumptech.glide:glide:3.7.0 is working fine but if updrage the version com.google.firebase:firebase-storage:10.2.6 Images are not loading.
Please help.

@samtstern falling back to 'com.google.firebase:firebase-storage:10.2.1' resolve the issue but 10.2.6 doesn't load & nothing is there in logs as well to point to.
Currently I changed to below configs in my gradle:
compile 'com.google.firebase:firebase-auth:10.2.6'
compile 'com.google.firebase:firebase-storage:10.2.1'
compile 'com.google.firebase:firebase-database:10.2.6'
compile 'com.google.firebase:firebase-core:10.2.6'
compile 'com.google.firebase:firebase-messaging:10.2.6'
compile 'com.google.android.gms:play-services-auth:10.2.6'
So is it ok to just have storage @ 10.2.1 & other dependencies @ 10.2.6 ?

Does this problem still occur with 2.0.0 or higher?

@samtstern didn't face the issue with compile 'com.google.firebase:firebase-storage:11.0.0'

@samtstern It works fine with 10.2.1.

@mailtoabhi15 that's good to know, firebase-ui-storage:2.0.1 depends on firebase-storage:11.0.1 so you should be able to use this library again.

11.0.1 + 2.0.1 works here too

I've heard multiple reports that this issue is fixed in 11.0.x so I am going to close this.  If someone can still reproduce this on the newest SDK please let me know.


PatchItemAsync is ignoring CosmosClientOptions.SerializerOptions.PropertyNamingPolicy when set to CamelCase

Describe the bug
When using the PatchItem operation and I've configured the serialization to CamelCase, my results that show up in Cosmos DB for the patched item are in standard C# case (not CamelCase). When I use the CreateItem or UpsertItem, the data shows up in Cosmos DB using the desired serialization of CamelCase.
To Reproduce

I have a .NET 8 Azure Function in Isolated worker with an HTTP trigger which has a PATCH endpoint.
in my Program.cs I've configured my CosmosClient:

services.AddSingleton((s) =>
{
    CosmosClientBuilder configurationBuilder = new CosmosClientBuilder(accountEndpoint: cosmosEndpoint, tokenCredential: tokenCredential)
        .WithSerializerOptions(new CosmosSerializationOptions
        {
            PropertyNamingPolicy = CosmosPropertyNamingPolicy.CamelCase
        })
        .WithConnectionModeDirect(openTcpConnectionTimeout: TimeSpan.FromSeconds(10))
        .WithApplicationRegion(regionName)
        .WithRequestTimeout(TimeSpan.FromMinutes(1))
        .WithThrottlingRetryOptions(new TimeSpan(0, 0, 0, 0, 500), 3);

    return configurationBuilder.Build();
});

My method for patching the item:

    public async Task<OrderModel> PatchOrderAsync(string orderId, List<PatchOperationModel> items, CancellationTokenSource? cancellationTokenSource = default)
    {
        List<PatchOperation> patchOperations = new List<PatchOperation>
        {
            PatchOperation.Replace("/modifiedTimeUtc", DateTime.UtcNow)
        };

        foreach (var operation in items)
        {
            if (operation.OperationType == Patch.Add)
            {
                patchOperations.Add(PatchOperation.Add(operation.Path, operation.Value));
            }
            else if (operation.OperationType == Patch.Remove)
            {
                patchOperations.Add(PatchOperation.Remove(operation.Path));
            }
            else if (operation.OperationType == Patch.Replace)
            {
                patchOperations.Add(PatchOperation.Replace(operation.Path, operation.Value));
            }
            else
            {
                _logger.LogWarning("Unsupported operation type: {0}", operation.OperationType);
                throw new Exception($"Unsupported operation type: {operation.OperationType}");
            }
        }

        var response = await _container.PatchItemAsync<OrderModel>(
            id: orderId,
            partitionKey: new PartitionKey(universalCallId),
            patchOperations: patchOperations,
            cancellationToken: cancellationTokenSource?.Token ?? CancellationToken.None);

        if (response.Diagnostics != null)
        {
            _logger.LogInformation("\nCosmos DB query diagnostics for PatchCallLogAsync: {Diagnostics}", response.Diagnostics);
        }

        _logger.LogInformation("Successfully patched Order for OrderId {0} ({1} RUs)",
            orderId,
            response.RequestCharge);

        return response.Resource;
    }

Sample:
PATCH http://localhost:7188/api/orders/c4a50add-52a4-417b-990f-6f3259335f36
Content-Type: application/json-patch+json

[
    {
        "op": "replace",
        "path": "/orderDetails",
        "value": {
            "OrderId":<PHONE_NUMBER>,
            "OrderName": "Mini Wheats",
            "OrderDescription": "",
            "OrderType": "Renewal"
        }
    }
]

Expected behavior
When patching items, I expect it to work similarly to Create and Upsert where it uses the PropertyNamingPolicy which in my case has a value of CamelCase.
Actual behavior
Data is patched in Cosmos container using the Default PropertyNamingPolicy.
Expected result in cosmos
{
    "id": "c4a50add-52a4-417b-990f-6f3259335f36",
    "orderDate": "2024-09-27T20:38:41",
    "orderDetails": {
        "orderId":<PHONE_NUMBER>,
        "orderName": "Mini Wheats",
        "orderDescription": "",
        "orderType": "Renewal"
    }
}

Actual result in cosmos
{
    "id": "c4a50add-52a4-417b-990f-6f3259335f36",
    "orderDate": "2024-09-27T20:38:41",
    "orderDetails": {
        "OrderId":<PHONE_NUMBER>,
        "OrderName": "Mini Wheats",
        "OrderDescription": "",
        "OrderType": "Renewal"
    }
}

Environment summary
Environment:
Azure Functions v4 - .NET 8 - Isolated worker
VS2022 17.11.4
Nuget Pakcges:

Microsoft.AspNetCore.App
AspNetCore.HealthChecks.CosmosDb Version="8.0.1"
Azure.Identity Version="1.12.1"
Microsoft.Azure.Cosmos Version="3.43.1"
Microsoft.Azure.Functions.Worker Version="1.23.0"
Microsoft.Azure.Functions.Worker.Extensions.Http Version="3.2.0"
Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore Version="1.3.2"
Microsoft.Azure.Functions.Worker.Extensions.OpenApi Version="1.5.1"
Microsoft.Azure.Functions.Worker.Extensions.Warmup Version="4.0.2"
Microsoft.Azure.Functions.Worker.Sdk Version="1.18.0"
Microsoft.ApplicationInsights.WorkerService Version="2.22.0"
Microsoft.Azure.Functions.Worker.ApplicationInsights Version="1.4.0"
Microsoft.Azure.WebJobs.Extensions Version="5.0.0"
Microsoft.Azure.AppConfiguration.Functions.Worker Version="7.3.0"
Microsoft.Extensions.Configuration.AzureAppConfiguration Version="7.3.0"
Microsoft.Extensions.Configuration.UserSecrets Version="8.0.0"

Additional context
Happy to provide additional code if needed.

@philipthomas-MSFT can you please look into it?

NamingPolicy is a pure SDK concept not service concept.
Patch API's all take string as path argument and application is expected to provide with the right cased value.

I got this work by reading the Object in the patch and then reserializing back as a camelCase object. This works, but it would be great if the Cosmos DB SDK would do this using the same CosmosPropertyNamingPolicy which is what the Create and Upsert use.

I got this working by reading the Object in the patch and then reserializing back as a camelCase object. This works, but it would be great if the Cosmos DB SDK would do this using the same CosmosPropertyNamingPolicy which is what the Create and Upsert use.

@calloncampbell Do you mind sharing your final solution. Also, agree with @kirankumarkolli on path being a string. We can consider a typed solution in the future.

@calloncampbell it's an interesting idea to explore. Your solution will definitely help us learn and improve this API.
The API can take Field/Property, but it will be scoped to a single name only, where the data model might be more nested.
May be LINQ expression might be an alternative?

I think I am leaning toward a PatchOperationBuilder that gets passed into an overloaded PatchItemAsync
Current Container.PatchItemAsync
public abstract Task<ItemResponse<T>> PatchItemAsync<T>(
    string id,
    PartitionKey partitionKey,
    IReadOnlyList<PatchOperation> patchOperations,
    PatchItemRequestOptions requestOptions = null,
    CancellationToken cancellationToken = default);

Future Container.PatchItemAsync overloaded with PatchOperationBuilder
public abstract Task<ItemResponse<T>> PatchItemAsync<T>(
    string id,
    PartitionKey partitionKey,
    PatchOperationBuilder<T> patchOperationBuilder,
    PatchItemRequestOptions requestOptions = null,
    CancellationToken cancellationToken = default);

Since and all Container's operations have access to the CosmosSerializer, can use deferred execution to do the serialization after you create the builder and pass it into the overloaded PatchItemAsync.
Maybe implementation could look like this
ToDoActivity toDoActivity = new ToDoActivity { Address = new Address1 { City = "Seattle" } };

PatchOperationBuilder<ToDoActivity> builder = new PatchOperationBuilder<ToDoActivity>(
    toDoActivity,
    op => op.SetOperationType(PatchOperationType.Add)
            .Property(p => p.Address.City)
);

CosmosJsonDotNetSerializer serializer = new CosmosJsonDotNetSerializer(new CosmosSerializationOptions
{
    PropertyNamingPolicy = CosmosPropertyNamingPolicy.CamelCase,
});

List<PatchOperation> patchOperations = builder.Build(serializer);

Now the builder.Build(serializer); is something you would not have to execute unless you wanted to, but really the overloaded PatchItemAsync would handle that by using the serializer that is configured in the CosmosClientBuilder.WithSerializerOptions. Just a thought. If we wanted to just pass the serializer into builder.Build(serializer), then there is no need to overload PatchItemAsync and we can just use the existing one, but you would have to pass it in twice.
Also, I would obviously need to spend more on ensuring that all variations of the supported operations are supported and tested (Add, Replace, etc.).
I think this would be a good addition to the SDK.

Thanks for your investigation and efforts.


Clarify pool vs. project on retirement trends page

Right now we just have a "Pool" column that either shows a pool name or a TCO2 address
Instead, we should have a separate "Project" column that links directly to the Verra project page (or maybe the project page on Carbonmark?) and then Pool would be blank or N/A for retirements made directly via TCO2

Hey @0xAurelius @jabby09 I've looked into this and have a solution worked out. In summary as below...
For the project column:

on the klimaDAO graph get the projectID from the offset object within klimaretires
paste the project number on the end of a standard link to the verra registry e.g.  https://registry.verra.org/app/projectDetail/VCS/1188
this link is displayed in the project column.

For the existing pools column:

Set any TC02 strings to N/A

Only questions I have are:

Some retirements have a blank project id in the graph. Shall we display N/A in the project column here?
Some pools values are 0x0000000000000000000000000000000000000000. These seem out of sync with the standard TC02 string formats, although do come back with results in klimaretires, but with missing projectIDs as well. Any ideas what they relate to?

This image provides some context to my two questions:

In terms of time my estimate is:

2 hours thinking through above solution (already done)
1 hr implementing solution in code
30 mins task admin (making commits, PR, formatting code etc)

Great, sounds reasonable
There are some minor issues with the subgraph data that @cujowolf has been working through, so some of these inconsistencies may be a result of those
They should be fixed soon, I think displaying N/A if the pool ID is not populated is fine but let's just ignore the 0x0 thing for now since I think it's an issue with the way MCO2 retirements are handled
In terms of formatting the project link, we should use markdown to format the link like this: [VCS-1234]( https://registry.verra.org/app/projectDetail/VCS/1188)]
Make sense?

Great, makes sense thanks! I'll leave the 0x0 as are, put any missing project IDs as N/A and format the links with markdown.

Hey @0xAurelius see PR 135 above


Fix make install with busybox ln

Hello,
it appears that Busybox doesn't offer the -r switch like GNU ln does. This is similiar to #951, maybe a more generic approach could be taken instead of just checking for OSX?

I don't have busybox to test any fixes but if someone wants to do some legwork on this, I'd be happy to help test the solution on other platforms that I have access to in order to assure that it works.

Anyone have thoughts on "a more generic approach"?

Well, I guess it'd be a matter of checking if ln -r works in the Makefile and if not don't use it. Sadly I'm pretty bad with Makefiles.

That's not really something you'd normally do in a Makefile. In general, that is what configure scripts and their ilk are for. I think it would make sense to come up with a solution that doesn't need -r that works "everywhere".

Ah, alright.

We no longer use ln -r in the Makefile.


Bugged initiative roll

Having fixed https://github.com/KaiEkkrin/ThirteenIsh/issues/31 and packed all combatants into the one Encounter row in the database, this might be sorted out too, because it could have been an undetected conflict due to inserts being present in a SQL operation.
I don't see how to make sure without making an integration test...

Hopefully fixed now


Emojis - "Frequently Used" header is missing in emojis categories

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Launch the app
Log in with expensifail account
Go to Setting and change language to Spanish
Tap on user you want to chat
Tap on emoji button and select couple emojis
Send couple emoji to user
Tap on emoji button

Expected Result:
Frequently Used header is showing in emojis section after sent emoji
Actual Result:
Missing header Frequently Used in emojis section after sent emoji
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Expensify/Expensify Issue URL:
Issue reported by: Applause
Slack conversation:
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

Triggered auto assignment to @madmax330 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Fixed in this PR: https://github.com/Expensify/App/pull/7255

@kavimuru, looks like the issue was addressed and its on staging now. Can you re-test and confirm the issue is resolved?

Looks like this was resolved in https://github.com/Expensify/App/pull/7255, and since it was a regression reported by Applause there's no other action to take here.


rsdp: add the validate_checksum to rsdp

Add the validate_checksum method to the implementation of the RsdpV1Tag
and RsdpV2Tag.
CC: @phil-opp @IsaacWoods
Fixes: #63

Published as multiboot2 v0.9.0


Global English Report Back Transactional

When a user reports back on a campaign that is translated in Global English, s/he should receive a report back transactional email in Global English. This is needed because content could potentially be different in |campaign_title|.
Also note that we need to make sure we're pulling in the proper fields for this since technically the Global English content are in different fiends than the US English fields.
And same as my comment on #4955 we need to make /campaigns will take the user to the correct version of that URL depending on their location, but I think this should be fine.
related to #4957

if we can confirm GL users receive US reportback transactional when we test then we can move to 1.1
cc: @namimody

confirmed that I'm getting transactionals still as a GL user so this can be 1.1.

@DeeZone @sergii-tkachenko @blisteringherb @marahml Just updated the description to include 4 new global templates! Please let me know if I can clarify. Thanks!

@mikefantini @marahml @ArielSD @sergii-tkachenko
Issue to default to default to Global templates rather than the current US defaults: https://github.com/DoSomething/mbc-transactional-email/issues/25
US users will continue to be sent US templates but unsupported countries will default to the global templates.


make conduit handle the leading '1'

connect shouldn't have to worry about the leading 1. So we will strip it from responses from peerless and pad any requests we send to peerless.

This looks great.


@payloadcms/db-postgres Cannot Remove Blocks

Link to reproduction

Describe the Bug
Inside a collecrion, removing a block and then saving the document, brings back the block.
The Patch request's payload excludes the to-be-deleted block, as should be,
but the response includes it once again.
No errors in the terminal or console.
This happens to all my blocks (not specifically nested like #3635).
To Reproduce

Create a new Page
Add a block.
Save the Page.
Remove the block.
Save the Page.
The block reappears

P.s. I'm a noob and couldn't follow along with the reproduction guide (e.g. how do I reproduce using specific package versions, where do I add env variables...)
Payload Version
2.0.13
Adapters and Plugins
"@payloadcms/bundler-vite": "^0.1.3", "@payloadcms/db-postgres": "^0.1.10", "@payloadcms/plugin-form-builder": "^1.0.15", "@payloadcms/plugin-nested-docs": "^1.0.8", "@payloadcms/richtext-lexical": "^0.1.15",

Encountered the same issue.
Some more details:
It only happens with the postgres adapter, deleting blocks with mongodb works fine.
It can be reproduced, by setting up the website-template with npx create-payload-app.

@JarrodMFlesch I'm still having this issue after updating to 2.0.15, I can add blocks but not remove them.

@ficeco did you update @payloadcms/db-postgres to 0.1.12 as well?

@ficeco can you update the @payloadcms/db-postgres adapter and try again?

@JarrodMFlesch That did the trick, thank you!


docs(): uncomment broken links for microsoft-playwright-testing

Packages impacted by this PR
@azure/microsoft-playwright-testing
Issues associated with this PR
Uncomment links to other README files in the microsoft-playwright-testing SDK.
Describe the problem that is addressed by this PR
As per https://github.com/Azure/azure-sdk/blob/main/docs/policies/README-TEMPLATE.md#link-guidelines, any relative link to a file which does not exist in main, will require the initial PR to go in with link commented out, followed by a PR to uncomment those links.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
N/A
Are there test cases added in this PR? (If not, why?)
Not pplicable
Provide a list of related PRs (if any)
Initial PR - https://github.com/Azure/azure-sdk-for-js/pull/30433
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

/azp run prepare-pipelines


Add support for new official Lightstreamer client lib

See discussion #253
https://pypi.org/project/lightstreamer-client-lib/

version 1.0.3

done, closing


The link for an example isn't highlighted

I missed this Click here for an example table to copy. in the app as the highlight isn't working for this link (but does for the others). I noticed you gave a table to copy when I looked at the code 😄

For my own reference, might need to do this: https://github.com/rstudio/rmarkdown/issues/1483
summary {
  display: list-item
}


PENV-258 import spec from https://github.com/insolar/spec-insolar-blo…

…ck-explorer-api

- What I did
imported specification v1
- How I did it
- How to verify it
- Description for the changelog

Codecov Report

Merging #52 into master will increase coverage by 0.19%.
The diff coverage is 52.17%.

@@            Coverage Diff             @@
##           master      #52      +/-   ##
==========================================
+ Coverage   68.01%   68.20%   +0.19%
==========================================
  Files          38       38
  Lines        1810     1821      +11
==========================================
+ Hits         1231     1242      +11
- Misses        480      486       +6
+ Partials       99       93       -6

Impacted Files
Coverage Δ

api/handlers.go
70.65% <50.00%> (-21.42%)
:arrow_down:

api/mappers.go
100.00% <100.00%> (ø)

etl/extractor/platform_pulse.go
100.00% <0.00%> (ø)

etl/extractor/platform_impl.go
79.46% <0.00%> (+5.35%)
: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 1a7ecce...ef3eaae. Read the comment docs.


Upgrade to latest sbt/librarymanagement

Brings in among other things:

sbt/librarymanagement#17 FPORT: Make JCenter opt in
sbt/librarymanagement#18 FPORT: Make sbt aware of Dotty
sbt/librarymanagement#19 FPORT: Maven compatibility changes (intransitive warnings and "configuration not public")
sbt/librarymanagement#20 FPORT: Refix snapshots

Can one of the admins verify this patch?

This happened in #2478


new API Method-Limits are enforced by RiotGames

ref: https://developer.riotgames.com/rate-limiting.html

leagues-v3 endpoints (EUW1)	>>300 requests / 1 minute
leagues-v3 endpoints (NA1)	 >>270 requests / 1 minute
leagues-v3 endpoints (EUN1)	 >>165 requests / 1 minute
leagues-v3 endpoints (BR1/KR)	 >>90 requests / 1 minute
leagues-v3 endpoints (LA1/LA2)	 >>80 requests / 1 minute
leagues-v3 endpoints (TR1)	 >>60 requests / 1 minute
leagues-v3 endpoints (OC1)	 >>55 requests / 1 minute
leagues-v3 endpoints (JP1/RU)	 >>35 requests / 1 minute

needs special properties for this issue and it can be fully re-configurable

possible quick fix
set method leaguesv3Limits(euw1,na1,eun1,br1,k1,la1,la2,tr1,oc1,jp1,ru); >into rate-limit scopes

added: https://github.com/msx752/RiotGamesAPI/commit/3b0dab7920f608f09841cf573ee4ba9f653153be


Added support for truecolor Neovim and for the Neovim terminal

I replaced several calls to has('gui_running') with a function to check if we're running in Neovim and, if so, check if it can use truecolor.
The colors for Neovim's :terminal were matched up to the ones for gnome-terminal

This should be merged.

This absolutely should be merged!


Show leaderboard place in level select screen

might be a good place to show top 3 people too, but maybe too spammy to server stuff?

DONE 5beb823356f1c55f5200bc210096e248bba39c12


[KOGITO-9315] - Remove Kogito Kubernetes Addon from SW Extension

In this PR, we remove the direct dependency from Kogito Kubernetes Addon.
Depends on this PR:

[x] - Examples - https://issues.redhat.com/browse/KOGITO-9315
[ ] - Images
[ ] - Documentation

See https://issues.redhat.com/browse/KOGITO-9315

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.
build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

for pull request checks
Please add comment: Jenkins retest this

for a specific pull request check
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] tests

for quarkus branch checks
Run checks against Quarkus current used branch
Please add comment: Jenkins run quarkus-branch

for a quarkus branch specific check
Run checks against Quarkus current used branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-branch

for quarkus main checks
Run checks against Quarkus main branch
Please add comment: Jenkins run quarkus-main

for a specific quarkus main check
Run checks against Quarkus main branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-main

for quarkus lts checks
Run checks against Quarkus lts branch
Please add comment: Jenkins run quarkus-lts

for a specific quarkus lts check
Run checks against Quarkus lts branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-lts

for native checks
Run native checks
Please add comment: Jenkins run native

for a specific native check
Run native checks
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] native

for native lts checks
Run native checks against quarkus lts branch
Please add comment: Jenkins run native-lts

for a specific native lts check
Run native checks against quarkus lts branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] native-lts

Full Kogito testing (with cloud images and operator BDD testing)
Please add comment: Jenkins run BDD
This check should be used only if a big change is done as it takes time to run, need resources and one full BDD tests check can be done at a time ...

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

Quarkus-3 PR check is failing ... what to do ?

The Quarkus 3 check is applying patches from the `.ci/environments/quarkus-3/patches`.
The first patch, called 0001_before_sh.patch, is generated from Openrewrite .ci/environments/quarkus-3/quarkus3.yml recipe. The patch is created to speed up the check. But it may be that some changes in the PR broke this patch.
No panic, there is an easy way to regenerate it. You just need to comment on the PR:
jenkins rewrite quarkus-3

and it should, after some minutes (~20/30min) apply a commit on the PR with the patch regenerated.
Other patches were generated manually. If any of it fails, you will need to manually update it... and push your changes.

(tests) - kogito-runtimes job #2737 was: UNSTABLE
Possible explanation: This should be test failures

Reproducer
export BUILD_MVN_OPTS_CURRENT=-T 1C -Dvalidate-formatting -Prun-code-coverage
build-chain build cross_pr -f 'https://raw.githubusercontent.com/kiegroup/kogito-pipelines/main/.ci/pull-request-config.yaml' -o 'bc' -p kiegroup/kogito-runtimes -u https://github.com/kiegroup/kogito-runtimes/pull/3056 --skipParallelCheckout
NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/main/job/pullrequest/job/kogito-runtimes.tests.kogito-runtimes/2737/display/redirect
Test results:

PASSED: 3339
FAILED: 1

Those are the test failures:

org.kie.kogito.integrationtests.quarkus.source.files.SourceFilesAddOnIT.testGetSourceFileByProcessId
java.lang.RuntimeException: java.lang.IllegalStateException: Unable to determine the status of the running process. See the above logs for detailsCaused by: java.lang.IllegalStateException: Unable to determine the status of the running process. See the above logs for details

Jenkins rerun kogito-runtimes tests


array_intersect: Presto and Velox return arrays with different orders of elements

Description
Query: select array_intersect(c0, c1) from (values (array[null, 31, 10, 4, 31], array[108, 19, 26, 4, 53, 49, null])) t(c0, c1);
Presto-0.289 result: [4, null]
Velox result: [null, 4]
Error Reproduction
No response
Relevant logs
No response

A mismatch of Presto vs. Prestissimo caused by this issue (internal link): https://www.internalfb.com/intern/presto/verifier/result/?event_uuid=830a8cbc-b863-4fe2-a5c5-4198735b3bcb#Main Queries , https://github.com/facebookincubator/velox/issues/10561.

array_duplicates() function has the same issue.
Query: select array_duplicates(c0) from (values array['1223', '4%%$', '1223', '##59', '4%%$', '4$$', '11', null, '4%%$', null]) t(c0);
Presto-0.289: Returns [null,"4%%$","1223"]
Velox: Returns [null,"1223","4%%$"]

For array_intersect and array_except, Velox has an optimization where if one of the arrays is constant it will create a set out of the constant array and reuse that set for lifetime of the UDF.  Presto simply makes a set out of whichever array is shorter for each row.
Given the expected output order isn't specified in the documentation, and these are functionally set operations, it seems a shame to sacrifice that optimization simply to match Presto's otherwise unspecified behavior.
https://github.com/facebookincubator/velox/pull/10624 is changing Velox to make the set out of the smaller array in the case where neither array is constant, this will match Presto's behavior in this case (and should improve performance).


Duplicate send for ButtonPress on v5+

Bug Report
For ButtonPress Requests on v5 and newer, the request is sent twice. See https://github.com/smartdevicelink/sdl_android/blob/master/sdl_android/src/main/java/com/smartdevicelink/proxy/SdlProxyBase.java#L4055-L4060
Expected Behavior
The method returns after the first send
Observed Behavior
The method executes the send twice
OS & Version Information

SDL Android Version: Observed in 4.7 and develop

Closed with #1010


Problems with roller shutters and F411

Good evening,
Sorry for my English, but I am french.
First, congratulations for your plugin, it is great.
But, I can not use it with my roller shutters.
I have modules F411 to manage them and the management of the estimated position does not work.
My shutter takes 14s to go up or down completely. The configuration of the accessory is as follows:
{ "accessory": "MHBlind", "name": "Arrière", "address": "0/8/4", "time": 14 },
Thank you for your work, continue, it's great.

Hi @Reyna1d, thank you for your feedback.
The estimated position is calculated starting a known position (fully closed at the startup); to keep this information affordable you need to:

start the homebridge daemon with the shutter fully closed OR
start the homebridge daemon and after that fully open (or fully close) so the plugin can start from a known position

This information is lost at restart. Remember that it is a (linear) estimate, so it doesn't care about the start delay (eg. if you have a shutter with tilt bar) and the estimate gets worse if you make many small movements. You can compensate the error with the additional property:

"startDelayMs": , that means that the shutter takes  milliseconds to start to move
"timeAdjust":  a (signed) percent adjustment of the movement, that is proportional to the movement, eg. with a value of 5 you say that the traveled time in x seconds is +5%.