docs: unify installation

Checklist
GitHub

[x] I've given this PR a concise, self-descriptive, and meaningful title
[x] I've linked relevant issues in the PR body
[x] I've applied the relevant labels to this PR
[x] I've assigned a reviewer

PR contents

[x] I've consulted ivadomed's internal developer documentation to ensure my contribution is in line with any relevant design decisions
[ ] I've added relevant tests for my contribution
[x] I've updated the relevant documentation for my changes, including argparse descriptions, docstrings, and ReadTheDocs tutorial pages

Description
This PR updates docs in reference to #1000 and addresses issues related to installation readability.
A preview to the docs - https://ivado-medical-imaging--1125.org.readthedocs.build/installation.html
Linked issues
Addresses #728 and Resolves #1019

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.037%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4709

Relevant Lines:
5958

💛  - Coveralls

Tagging @joshuacwnewton in reference to #861 as this would remove the dependency to install torch explicitly.

Tagging @joshuacwnewton in reference to #861 as this would remove the dependency for downstream packages to install torch explicitly

Thank you for the tag!
Looking this over quickly, this would be absolutely amazing for SCT, because it would unblock a longstanding issue we've been struggling with for years: https://github.com/spinalcordtoolbox/spinalcordtoolbox/issues/1526
Because we would be able to specify a requirements.txt file that contains:
ivadomed[cpu]

We would be able to install a CPU version of PyTorch by default without having to use a --find-links link.
(We had been trying to brainstorm ways to avoid --find-links for months/years, and we had similar ideas to you: https://github.com/spinalcordtoolbox/spinalcordtoolbox/issues/1526#issuecomment-812740662. But, it's much nicer to do ivadomed[cpu] than ask our users to do spinalcordtoolbox[cpu], so thank you.)

I can see some great work has been done here. For axondeepseg, this would potentially solve a problem we are encountering more and more: when we want to update the ivadomed version, since its installed with pip, using conda env update, pip install -e . or similar commands do not update the ivadomed package (or any other pip packages for that matter) and the user needs to reinstall the whole environment because conda can't deal with pip dependencies properly.
In https://github.com/axondeepseg/axondeepseg/pull/631, we tried parsing the environment.yml file to update ivadomed when there is a mismatch with the version currently installed in the environment, but the problem is that torch/torchvision also need to be updated if bumped, and we have to make sure internally that ivadomed and torch packages match.
This would make the whole process much simpler as we would only need to worry about ivadomed's version. Also, if the user wants to use GPUs, he would simply need to pip install ivadomed[gpu] in his ADS venv, bypassing the need for --find-links, as mentioned by @joshuacwnewton.

From https://github.com/ivadomed/ivadomed/pull/1129#issuecomment-1139730419, I'd like to suggest drastically culling the docs. We should get rid of most of the tabs (including the ComputeCanada tab) and the mentions of Windows vs macOS vs Linux, and just say

pip install ivadomed

(which downloads everything from PyPI) because that works out of the box for nearly everyone.
If needed, somewhere we can add two alternate instructions, which are hardware- but not OS-specific:

If you don't have a GPU, you can save some time and space with:
pip install --extra-index-url https://download.pytorch.org/whl/cpu ivadomed

(which, for Linux users, downloads a smaller build)
and

If you have a GPU and find it's not working with ivadomed, try
pip uninstall -y torch torchvision
pip install ivadomed \
   --extra-index-url https://download.pytorch.org/whl/cu110 \
   --extra-index-url https://download.pytorch.org/whl/cu111 \
   --extra-index-url https://download.pytorch.org/whl/cu112 \
   --extra-index-url https://download.pytorch.org/whl/cu113 \
   --extra-index-url https://download.pytorch.org/whl/cu114 \
   --extra-index-url https://download.pytorch.org/whl/cu115

(which, for Windows users, enables the GPU; and for Linux users; but does nothing for macOS users)
Trying to predict people's GPU problems should be out of scope for the install docs. If people are having problems we can try to help, but if we just hew close to (i.e. to what Facebook decided to publish as the default builds) I think there won't be that many problems in the first place.

As for ComputeCanada -- they have their own builds of torch pre-populated -- torch==1.10.0 for python 3.10, torch==1.10.0, torch==1.9.0 for python 3.9, and many more including torch==1.8.1 for python 3.8. So there's three strategies we can follow (in parallel!) that don't involve adding irrelevant info to our public docs:

Document internally that we need to remember to run ivadomed on python3.8 when using computecanada
Ask computecanada to make sure torch~=1.8.0 builds exist for all python versions -- it is the torch LTS release afterall, that's a reasonable request
Work to make ivadomed depend on torch>=1.8.1,<1.11 instead of torch==1.8.1

And idk maybe drop the pip install -e instruction from this? That can go into https://github.com/ivadomed/ivadomed/blob/master/CONTRIBUTING.rst instead.

jcohenadad says

testing GPU on windows is low priority

which to me means supporting Windows GPUs is also a low priority. If we can cover Linux CUDA11 people and Windows people in one instruction like I think we can I want to do that, but if it turns out we have to give separate Linux and Windows instructions then we should just not say anything about Windows. If someone really wants to use Windows and GPUs they can ask us for tips and we can send them to https://pytorch.org/get-started/locally/ or https://discuss.pytorch.org/.

While writing an exhaustive draft, I found this blog an interesting read.

This post is excellent! It really really clarifies the lower levels.

I agree with @kousu's recommendation to strip out the dev installation section entirely into contributing.md or the like. Much easier to keep the doc simpler and primary user case facing.
Can't we merge these two Package Installation tabs, if the installation are now pretty much the same across os?

Similarly for the Source Installation tabs,

Can't we merge these two Package Installation tabs, if the installation are now pretty much the same across os?

@dyt811 Notice the subtle difference for CUDA 10.2 in Linux & Windows tab. Anyway, we've moved the windows bit to developer section as suggested by Nick

Thanks @kousu for reviewing it extensively. I might have a slightly different take on starting the installation directly with pip install ivadomed. This is more or less my perspective in general -

My primary concern is missing the wood for the trees or perhaps creating a bit of confusion due to difference in behaviour on different OSes. More so, once M1 GPU acceleration performance is at par with NVIDIA GPUs (irrelevant as of now but soon to be).

You and me already know the default behaviour of pip & torch on Linux, but abstracting this info might be dangerous in case they run into some upstream issues (e.g.: performance), assuming related to CUDA & torch, then it might take them longer to figure it out.

People will get lost with jargon ("what's an Ampere?" "what's a CUDA?" "why do I care?"). We need some amount of that documented, but we shouldn't front-load it.
If we're going to mention CUDA, we need to explain enough that someone can figure out if they need to care about what that is and why its version matters to them.

I re-read the docs. CUDA runtime might be unclear, but it's sufficient to get an idea what CUDA runtime to choose. In case they're curious & want to dig in, they could always google it up.

My suggestion with regard to ditching Windows from months ago was handwaving at a shortcut: I was thinking maybe we could get away with saying "and if your GPUs don't work, take these CUDA 11 builds and call me in the morning (because I'm a doctor)". But I think if we're going to be explicit about Ampere, it makes more sense to be explicit about Windows too.

According to the past discussions, I'm in favour of ditching Windows completely. Windows scenario is a highly unlikely one to be encountered.
I'm yet to address other comments, and I believe it would be better if more people review this to get a perspective how are docs actually coming out to be.

There's also the pip.conf solution: instead of "please run this command" it could be "please create this file before installation"
# /etc/pip.conf or ~/.config/pip/pip.conf or C:\ProgramData\pip\pip.ini or %APPDATA%\pip\pip.ini
[install]
extra-index-url =
   https://download.pytorch.org/whl/cu111
   https://download.pytorch.org/whl/cu113
   https://download.pytorch.org/whl/cu115

That's essentially instructing people to set a global variable on their OS, but I think this is one of the rare cases where that's the right thing to do: a system has fixed hardware (usually), so every pretty much every package they use with their GPUs will need the same patch.

@kousu and to the reviewers, I'm uncomfortable with the above propositions to the user.
(Why?) According to the docs, "From CUDA 11 onwards, applications compiled with a CUDA Toolkit release from within a CUDA major release family can run, with limited feature-set, on systems having at least the minimum required driver version as indicated below. This minimum required driver can be different from the driver packaged with the CUDA Toolkit but should belong to the same major release."
Now, simplifying if I understood this correctly, the Linux x86_64 Minimum Required Driver Version for CUDA 11.x is >= 450.80.02 whereas the Linux x86_64 Minimum Required Driver Version for CUDA 11.3 is >=465.19.01 (reference to docs). This essentially boils down to - even if I have an NVIDIA Driver Version of 450.80.02 it is possible to install and run pytorch compiled with CUDA 11.3 runtime but with limited feature-set. And, it is possible to not figure out some optimizations made in CUDA 11.3 for certain algos but everything appearing almost fine.

I'm also concerned about missing the forest for the trees. But I think the forest in this case is pip install ivadomed and troubleshooting performance/hardware issues are the trees.
Another way to think of it is the 80%-20% rule: 80% of people are safe to just pip install ivadomed. The other 20% can use --extra-index-url https://download.pytorch.org/whl/cu102 (or whatever) -- even putting that in their pip.conf -- but they are not the people we should be prioritizing.

@kousu and to the reviewers, I'm uncomfortable with the above propositions to the user. [..]
even if I have an NVIDIA Driver Version of 450.80.02 it is possible to install and run pytorch compiled with CUDA 11.3 runtime but with limited feature-set.  [..]

I'm sorry, I don't really understand. I think maybe we actually agree? But I'm not sure.
Are you saying that recommending CUDA 11 is bad? My read of what you linked isn't saying that CUDA 11 is less efficient, just that it is less efficient if used with nvidia-driver 440 or nvidia-driver 450; which is different than with CUDA 10, which (I'm guessing at the exact numbers here) didn't work at all with nvidia-driver 330. But can't we just assume people will be running the latest driver? On our local systems I have us running nvidia-driver 510 and everything is stable and fine.
Taking a step back to look at the forest again: I know that debugging tricky CUDA issues is hard. I have done it a lot at this point. That's exactly why I think we should bury it in # Special Cases; it should be rare (i.e. <20%) that anyone actually uses --extra-index-url.
As of July 2022, the CUDA 11 builds should only be used for people with Ampere (Compute Capability >= 8.0) cards, which is what I meant by "too new" -- and those people, frankly, are rich and can afford to pay for their own tech support or losing a bit of performance. The default path, doing pip install ivadomed, will mean people on Linux will end up with the CUDA 10 builds which are

Anyway, I'll defer to the opinion of someone actually on the ivadomed team. My main blocker is that in this version, the basic pip install ivadomed command is buried and I think it needs to be way more prominent. @dyt811, @lifetheater57, can you give a read over our two versions of the docs and give us a tie-breaker vote? Or help us decide what to merge from each?

https://ivado-medical-imaging--1125.org.readthedocs.build/installation.html

https://ivado-medical-imaging--1125.org.readthedocs.build/contributing.html

https://ivado-medical-imaging--1184.org.readthedocs.build/installation.html

https://ivado-medical-imaging--1184.org.readthedocs.build/contributing.html

Maybe I'll understand why it would be required to have CUDA >= 11.0 when I compare your docs. However, in the meantime, I think requiring to have compute capability >= 8.0 is too early.

Maybe I'll understand why it would be required to have CUDA >= 11.0 when I compare your docs. However, in the meantime, I think requiring to have compute capability >= 8.0 is too early.

It's not. We used to be confused: romane.neuro.polymtl.ca has compute capability == 8.0 so ivadomed ended up with a requirement for CUDA >= 11. #1000, which became #1129 , loosened that requirement. It was artificial and unneccessary. This PR is the followup to #1129 to make the docs reflect the code. So, almost the opposite, even.
I was the one who initially put in the CUDA 11 requirement as a temporary workaround for romane, so now I'm trying to clean up the mess 😬

I read the Ivadomed Installation Document in both PR1184 and PR1125. I feel it is better if we can combine these two versions.
In PR1125, I like the way of organize the content, and separate into Step1, Step2…..
Also the part of ‘ setup virtual environment for Ivadomed’ is very good to a new pyhton user (like me). So I think, for sure, we should keep this part. But this part is missing in PR1184.
In PR1184, I like the detail explanation for GPU support. Also includes the command for checking GPU and NVIDIA versions.
By merging these two version of installation documents, here is my proposal:
Dependencies:
OS Support: ivadomed officially supports GPU acceleration only on Linux and CPU on Linux, Windows and MacOS.
Python: ivadomed support python 3.5-3.10
Checking python version:
Linux, windows, macOS
GPU support (optional): To verify GPU hardware is detected, use:
Linux, window, macOS
To verify NVIDIA driver, use:
Linux, window, macOS
Ivadomed support CUDA10, CUDA 11 …….
Installation
Step 1. Setup Virtual Environment
Step 2. Install Ivadomed
For CPU-only Support
Linux, window, macOS
For GPU support (Linux Only)
pip install ivadomed
Troubleshoot Problems:
Q1: I have CUDA 11.x, can I still use Ivadomed?
Answer: *******
Q1: I have GPU support, but after running ‘pip install ivadomed’, my ‘torch.cuda.is available’ is still ‘False’ why?
Answer: *****

Here is my review for PRs #1125 and #1184.
Note that I am commenting without checking most of the previous discussions to have a cold take on it. Also, it occurs to be quite aligned with @LuluSzutu suggestion which I didn't see before writing my own review.
I first begin with general comments that apply to both PRs and that my target issues present before these. Then, I give PR-specific comments for each PR like if we were to keep each of them as a whole. Finally, I propose how I would combine the PRs together.
In both cases:

NeuroPoly Contributing Guidelines link is broken.
Why not use ivadomed[cpu] for the cpu version?
The Copyrights got stuck in 2020.

PR #1125:

Technically, the instruction should be to check whether a compatible Python version is installed on the system and not whether the default Python has the right version (i.e. check if python3.7, python3.8 or python3.9 is available rather than checking if the version of python is in {3.7, 3.8, 3.9}).
I guess it doesn't ship with both CUDA 10.2 and CUDA 11.1.

PR #1184:

The main installation instructions are nice, but we need to be sure to test it very well since the steps to chose the right version regarding the GPU are abstracted.
Also, do we aim to people that don't know how and why to setup a venv, if yes, then we should bring back the instructions about the venv. Also, if python needs to have a specific range of versions, then might as well give the instruction how to create the venv with one of these versions.
Instead of saying "This should work with most combinations of OSes and pythons.", we should have a list of the tested/supported configurations.

Overall:
Each bullet is a section I would see on the installation page.

Supported OS:

I feel like we should keep that section. However, I would suggest to have a list of what configuration we tested, what configuration we expect to work and what configuration we know don't work.
If there is too much content, then I would go for a summary of what is supported or not and a complete section in a by-default collapsed section.

Virtual environment:

We should still encourage the user to create a virtual environment since it is a great practice that prevents a lot of headaches.
I would write something like "You are strongly recommended to setup a virtual environment for ivadomed using Python>=3.7,<3.10", then have the specific instructions collapse by default.

Installation:

I would by-default install the best version of PyTorch (to be defined) given the system configuration (if we can know it, i.e. like in PR #1184)
A (collapsed?) subsection "Alternative installations" explaining how to install a specific version if desired (cpu-only or a specific CUDA version) and why we could want to do so.

Troubleshooting:

This section addresses the installation/runtime issues
I would put PR #1184 "GPU support" section here under something like "ivadomed doesn't train using GPU".

This item would have to include some of the information under the "CUDA 11" subsection but may have to be changed depending on the way the "Installation" section is written (i.e. if there is some automation or not).
This item should also include a description of the limitations pertaining to compute capabilities 8.x (i.e. CUDA >= 11.1) found in PR #1125.
It would also be great to include the information related to the CUDA driver version required given the different CUDA version used by PyTorch.


Firewall: Problems handling square brackets in rule name

Details of the scenario you tried and the problem that is occurring:
Using the latest DscNetworking from the PowershellGallery (plain Install-Module NetworkingDsc). The Firewall property will not handle square brackets in firewall rule names correctly. First run it will rightfully detect and create the rules. Second run the configuration Test fails and it tries to recreate the rule for an exception due to duplicate rules.
The DSC configuration that is using the resource (as detailed as possible):
The following configuration run locally towards the node localhost
Firewall FirewallRuleWithSquareBrackets
        {
            Name = "Square [Brackets]"
            Ensure = "Present"
            Group = "Debug"
            LocalPort = 65000
            Protocol = "TCP"
        }

Version of the Operating System and PowerShell the DSC Target Node is running:
Windows 10 Pro, 1803, Build: 17134.165
Name                           Value
----                           -----
PSVersion                      5.1.17134.165
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17134.165
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

Debug output:
Output from Test-DscCounfiguration (after intitial run)
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ Start  Resource ]  [[Firewall]FirewallRuleWithSquareBrackets]
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ Start  Test     ]  [[Firewall]FirewallRuleWithSquareBrackets]
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Checking settings for firewall rule with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Find firewall rule with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Get-FirewallRule: No Firewall Rule found with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Firewall rule with Name 'Square [Brackets]' does not exist.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Check Firewall rule with Name 'Square [Brackets]' returning False.
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ End    Test     ]  [[Firewall]FirewallRuleWithSquareBrackets] False in 0.1360 seconds.
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ End    Resource ]  [[Firewall]FirewallRuleWithSquareBrackets]
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ End    Compare  ]     Completed processing compare operation. The operation returned False.
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ End    Compare  ]    in  14.2710 seconds.

Output from Start-DscConfiguration 2nd run:
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ Start  Resource ]  [[Firewall]FirewallRuleWithSquareBrackets]
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ Start  Test     ]  [[Firewall]FirewallRuleWithSquareBrackets]
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Checking settings for firewall rule with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Find firewall rule with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Get-FirewallRule: No Firewall Rule found with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Firewall rule with Name 'Square [Brackets]' does not exist.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Test-TargetResource: Check Firewall rule with Name 'Square [Brackets]' returning False.
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ End    Test     ]  [[Firewall]FirewallRuleWithSquareBrackets]  in 0.1360 seconds.
VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ Start  Set      ]  [[Firewall]FirewallRuleWithSquareBrackets]
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Set-TargetResource: Applying settings for firewall rule with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Set-TargetResource: Find firewall rule with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Get-FirewallRule: No Firewall Rule found with Name 'Square [Brackets]'.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Set-TargetResource: We want the firewall rule with Name 'Square [Brackets]' to exist since Ensure is set to Present.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] Set-TargetResource: We want the firewall rule with Name 'Square [Brackets]' to exist, but it does not.
VERBOSE: [DESKTOP-S1LGPAL]:                            [[Firewall]FirewallRuleWithSquareBrackets] New-NetFirewallRule DisplayName: Square [Brackets]
Cannot create a file when that file already exists.
    + CategoryInfo          : ResourceExists: (MSFT_NetFirewallRule:) [], CimException
    + FullyQualifiedErrorId : Windows System Error 183,New-NetFirewallRule
    + PSComputerName        : localhost

VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ End    Set      ]  [[Firewall]FirewallRuleWithSquareBrackets]  in 0.2050 seconds.
The PowerShell DSC resource '[Firewall]FirewallRuleWithSquareBrackets' with SourceInfo 'C:\Git\automation-windows-htpc\HTPC.ps1::79::9::Firewall' threw one or more non-terminating errors while running the Set-TargetResource functionality. These errors are logged
to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider
    + PSComputerName        : localhost

VERBOSE: [DESKTOP-S1LGPAL]: LCM:  [ End    Set      ]
The SendConfigurationApply function did not succeed.
    + CategoryInfo          : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : MI RESULT 1
    + PSComputerName        : localhost

Good catch @vidarw and thanks for raising this. Looks like the -Name parameter needs to be escaped when calling Get-NetFirewallRule, Remove-NetFirewallRule and Set-NetFirewallRule because they support wildcards.

This should be a fairly simple fix.


PrisonerRoster Syncronization

Implement and verify PrisonerRoster is synchronized.

Make sure Hero is "saved" when capturing party is defeated. Essentially, the player hero is removed from the prisoner state of that party.


Type Custom with DefaultToastLayoutRenderer

I implemented the DefaultToastLayoutRenderer with type ToastNotificationType.Custom passing an url (small profile image from web) and a color.
The problem is it takes a little time to load the image the first time (I cache it for reuse) and while retrieving the image, the default image ("Resource.Drawable.error") is shown.
Could this be changed so that there is no default image when using the Action<object, ImageView> imageSetterForCustomType = null.
Thanks in advance and keep up the good work.

Not longer applicable as Toasts Plugin has been rewritten.
Please file a new issue if you experience an problem with the new version.
More Info: https://xamarinhelp.com/toast-notifications-xamarin-forms/


SimGromacs tutorial - APACHE use case

Hello,
As suggested by @pablo-de-andres I would like to kindly ask you to create a branch that w ecan use to develop the SimGromacs tutorial based on the APACHE user case.
Many thanks!

Closing in favor of pre-existing #9


public: Add Dialog.doOperation

This factors out the necessary calls to cl.flashResult() and Dialog.close() after both successful and unsuccessful API calls.

Coverage increased (+0.02%) to 97.948% when pulling 8d0bce890aad858e2246da7d1db237a11b3c6c33 on do-operation into 324765f21403591aadf67f13f35740f45b870274 on master.

Coverage increased (+0.02%) to 97.948% when pulling 8d0bce890aad858e2246da7d1db237a11b3c6c33 on do-operation into 324765f21403591aadf67f13f35740f45b870274 on master.


cupy.ndarray cannot be compared with ellipsis

Not sure if it's due to #4198. The __richcmp__ method does not handle trivial comparison with Python objects correctly:
>>> np.empty(3) == ...
array([False, False, False])
>>>
>>> cp.empty(3) == ...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "cupy/_core/core.pyx", line 1094, in cupy._core.core.ndarray.__richcmp__
    return numpy.equal(self, other)
TypeError: operand type(s) all returned NotImplemented from __array_ufunc__(<ufunc 'equal'>, '__call__', array([0., 0., 0.]), Ellipsis): 'ndarray', 'ellipsis'

It seems NumPy internally calls PyObject_RichCompare to handle this. Perhaps before delegating to numpy.equal() (and friends) we should handle this edge case first?

Note: this relates to the test_indexing.py failure seen in https://github.com/cupy/cupy/pull/5698#issuecomment-913406882.

#1989 discusses comparison with None.

Can you post the traceback from the test failure? We should probably make the array API tests not use == for comparing arrays and use is to compare against Ellipsis.

This line brings the error, where key is a tuple that contains array indices and they are compared to an ellipsis. When an index is a ndarray, the error above occurs. I think we should count using is here.
https://github.com/cupy/cupy/blob/0955ad9082b103d6b8a05a63009d69001504c61d/cupy/array_api/_array_object.py#L330

n_ellipsis = key.count(...)

To be precise, each array index in key must have _.size <= 1, or key.count(...) will raise ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all().  The line works fine because indexing with integer arrays is unspecified in Array API. https://data-apis.org/array-api/latest/API_specification/indexing.html
https://github.com/cupy/cupy/blob/0955ad9082b103d6b8a05a63009d69001504c61d/cupy/array_api/_array_object.py#L346-L351

Do you know if this code leads to a problem in the NumPY implementation? I think something like this would be more robust.
diff --git a/numpy/array_api/_array_object.py b/numpy/array_api/_array_object.py
index ead061882d..e7ddcf033b 100644
--- a/numpy/array_api/_array_object.py
+++ b/numpy/array_api/_array_object.py
@@ -325,10 +325,13 @@ def _validate_index(key, shape):

             if shape is None:
                 return key
-            n_ellipsis = key.count(...)
+            # Use 'is' to compare against ellipsis to avoid performing == on
+            # an array.
+            ellipses = [i for i, k in enumerate(key) if k is ...]
+            n_ellipsis = len(ellipses)
             if n_ellipsis > 1:
                 return key
-            ellipsis_i = key.index(...) if n_ellipsis else len(key)
+            ellipsis_i = ellipses[0] if ellipses else len(key)

             for idx, size in list(zip(key[:ellipsis_i], shape)) + list(
                 zip(key[:ellipsis_i:-1], shape[:ellipsis_i:-1])

As @toslunar mentioned in https://github.com/cupy/cupy/issues/5715#issuecomment-985991356, I think NumPy's current code works without any problem. But, yes, your diff would be exactly what we want to do there.


feat: Add option to delete a application snapshot

Description
This PR adds the option to delete an application snapshot in the following cases:

A DELETE API that'll delete an application snapshot
The restore API should delete the underlying application snapshot if the restore is successful

Fixes #21215
Media

A video or a GIF is preferred. when using Loom, don’t embed because it looks like it’s a GIF. instead, just link to the video

Type of change

Please delete options that are not relevant.

Chore (housekeeping or task changes that don't impact user perception)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions, so we can reproduce.
Please also list any relevant details for your test configuration.
Delete anything that is not important

Manual
JUnit tests

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=c404596b821f965a1b97c57e2d97886e9a0dc996

/ok-to-test sha=e268b9e862e2e66be0bf5840dc8cf97bbfcc1bfd

/ci-merge-check

/ci-merge-check


delete static route by uuid

allow client to delete static route by uuid

LGTM for me, @hzhou8 what you think?


sap_swpm: Error with argument reference in detect_variables.yml

Writing on behalf of a customer who has been working with community roles to install Suite on HANA using advanced templates mode.
In this case, detect_variables.yml references $3 in the detect software path task:
# Detect Software Path
- name: SAP SWPM - Detect Software Path
  ansible.builtin.shell: |
    set -o pipefail && cat {{ sap_swpm_tmpdir.path }}/inifile.params | grep archives.downloadBasket | awk '{ print $3 }'
  register: sap_swpm_inifile_software_path
  changed_when: false

But there appears to be no third argument passed and the download software item appears to actually be $2.
When he changes the code as follows, it corrects the problem:
# Detect Software Path
- name: SAP SWPM - Detect Software Path
  ansible.builtin.shell: |
    #set -o pipefail && cat {{ sap_swpm_tmpdir.path }}/inifile.params | grep archives.downloadBasket | awk '{ print $3 }'

 set -o pipefail && cat {{ sap_swpm_tmpdir.path }}/inifile.params | grep archives.downloadBasket | awk -F '=' '{ print $2 }'

  register: sap_swpm_inifile_software_path
  changed_when: false

Customer has moved past this issue with the above change but wanted to get it in front of the community in case others are impacted.

@jodonnel Can you please ask your customer to check if https://github.com/sap-linuxlab/community.sap_install/blob/5b920752aa818fcd9fe96ce740bffaa314baf99e/roles/sap_swpm/tasks/swpm/detect_variables.yml#L25 fixes the problem as well? It's already in the current main branch.
That code assumes that there is a space around the "equals" ("=") sign, causing the 3rd field of the output to contain the desired value.
If there is no space in this line in the customer's inifile.params file, can you please ask how this file had been created, and ask to test the following alternative code:
awk 'BEGIN{FS="="}!/^#/&&/archives.downloadBasket/{gsub (" ", "", $NF); print $NF}' inifile.params
?
Many thanks!


Get rid of some deprecated API usage warnings

Coverage decreased (-0.06%) to 82.636% when pulling 3d7729b0a101be90f9d3ef2e6f4f1ec47be3f24c on about into dee3d346c1e69db5d08ff598671dbfe21feff690 on 2.0.0-RC.


Add MapAssert#hasEntrySatisfying(K, Consumer)

Summary
I want to add methods to simplify check map values.
Similar to #70 and #205, but I have working code for PR.
Example
assertThat(map)
    .hasEntry("key1", v -> {
        assertThat(v)
            .isNotNull()
            .contains("value")
            .is(someCreatedCondition);
    });

Java 8 specific ?

YES

done


Fix caravan issue again.

fix #4 ,
after I forked this mod for a time, the simplest way to solve the problem shaped.
The issue only affect on trader. So just skip trader kind, then it's no problem

Nice, should be added in 54247c1


Reset password expiration failed and date converted to timestamp to add precision

Initially, I was investigating why the format of expiresAt is a date (format: YYYY-MM-DD). What seemed unusual was that while the expiration time is set to one hour later, the expiresAt field doesn't include any time information. To address this, I attempted to convert it to a timestamp (which I think, it's not the best approach, as it converts all dates to timestamps – feel free to contribute and improve this solution). However, I encountered another issue: when you call new Date(), it returns a date in your machine's local timezone rather than UTC. Therefore, I needed to convert it to UTC to ensure that both the timestamp and UTC time were in the same timezone.

#567

Hey thanks for the PR and opening the issue. Closing this in favor of #572


why here is comm.rank ?

In this line,
https://github.com/chainer/chainer/blob/d3da91cbd8c991854beda159dd465fcac9aa10a7/examples/chainermn/mnist/train_mnist_dual_parallel.py#L124
why use comm.rank == 1 rather than use data_axis == 1
Although in this case these two all stand for the same process,  I think data_axis == 1 is easier to understand.

Thank you!
I agree. I will fix it.


Uncaught ReferenceError: module is not defined

When I tried to use the library, error occurs

Uncaught ReferenceError: module is not defined
at lzw.js:60

this line

module.exports = new lzw();

after removing this line, I can use the library in this way

originalString = "10"
new lzw().encode(originalString) // must use "new lzw()"
.catch(error => console.log(error))
.then(compressed => console.log(compressed));

npm install lossless-text-compression

If I'm not wrong this occurs when you only work with one file.
If you want to separate the work and keep the compression/decompression logic in a separate .js file then you will need the line module.exports = new lzw(); in order to be able to call it from another file.


Adding N|Solid to Languages & Frameworks section?

Hello! 👋
Just saw this tweet and thought this was an awesome project. Looking at the chart, I realized that it's also applicable to my work and company. We offer N|Solid, which is a Node.js runtime built with the Enterprise in mind.
Similar to Node.js, it works in containerized and cloud environments by default. You can deploy N|Solid with Docker, Kubernetes, Cloud Foundry and others. You can also spin up N|Solid from the AWS, GCP, and Azure Marketplaces as you would with Node.js or any other application-level runtime 😊

Hi @bnb we appreciate your excitement about the Landscape! We already have Nodesource under Monitoring and Node.js under Languages & Frameworks and due to limited real estate, we'll have to leave Node.js in there instead. Thanks for reaching out and a very well composed request.


[Impeller] ToT Android/Vulkan build is broken due to invalid render target configuration.

E/flutter (30719): [ERROR:flutter/impeller/base/validation.cc(49)] Break on 'ImpellerValidationBreak' to inspect point of failure: The LoadAction cannot be Load when attaching a device transient texture.
THis is happening in wonderous during the blit pass/advanced blends while scrolling.

This is happening starting on the dl aiks canvas patch. Will look at cause tomorrow

From debugging, this is happening on the stencil configuration. The error isn't wrong, and changing the stencil configuration locally to be clear/dontcare causes rendering to still be broken. So I'm a bit perplexed, and my current theory is some changes in the DLAiksCanvas is tickling a bug in entity pass.

The validation stack points to a stencil texture:
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: '[FATAL:flutter/impeller/base/validation.cc(47)] Break on 'ImpellerValidationBreak' to inspect point of failure: The LoadAction cannot be Load when attaching a device transient texture.'
    x0<PHONE_NUMBER>000000  x1<PHONE_NUMBER>005094  x2<PHONE_NUMBER>000006  x3  0000006e5811dfa0
    x4  6b60752e64726061  x5  6b60752e64726061  x6  6b60752e64726061  x7  7f7f7f7f7f7f7f7f
    x8<PHONE_NUMBER>0000f0  x9<PHONE_NUMBER>88d9e0  x10<PHONE_NUMBER>000001  x11<PHONE_NUMBER>8cf370
    x12<PHONE_NUMBER>00e249  x13<PHONE_NUMBER>0000ba  x14 0000006e5811ce70  x15 00000dc429f13907
    x16<PHONE_NUMBER>93cd50  x17<PHONE_NUMBER>917eb0  x18 0000006e4b430000  x19<PHONE_NUMBER>00506a
    x20<PHONE_NUMBER>005094  x21 00000000ffffffff  x22<PHONE_NUMBER>000000  x23 0000006e5811f0a0
    x24 0000006e5811f238  x25 b400006f795f61f0  x26 b4000070995d4c58  x27 0000006e5811ec00
    x28 b400006f59619748  x29 0000006e5811e020
    lr<PHONE_NUMBER>8bf1c8  sp  0000006e5811df80  pc<PHONE_NUMBER>8bf1f4  pst<PHONE_NUMBER>001000
backtrace:
      #00 pc<PHONE_NUMBER>0531f4  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: dc4001c2ef2dfc23467040797a96840c)
      #01 pc<PHONE_NUMBER>b54ed0  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154cc000) (std::_LIBCPP_ABI_NAMESPACE::__throw_bad_optional_access[abi:v15000]()+4) (BuildId: 522f82a4d40fa20ef14eeeeac3f59b369051a0e8)
      #02 pc<PHONE_NUMBER>b7ebb0  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154cc000) (fml::LogMessage::~LogMessage()+196) (BuildId: 522f82a4d40fa20ef14eeeeac3f59b369051a0e8)
      #03 pc<PHONE_NUMBER>bf5afc  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154cc000) (impeller::ImpellerValidationBreak(char const*)+204) (BuildId: 522f82a4d40fa20ef14eeeeac3f59b369051a0e8)
      #04 pc<PHONE_NUMBER>bf5a0c  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154cc000) (impeller::ValidationLog::~ValidationLog()+72) (BuildId: 522f82a4d40fa20ef14eeeeac3f59b369051a0e8)
      #05 pc<PHONE_NUMBER>bf7408  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154cc000) (impeller::Attachment::IsValid() const+236) (BuildId: 522f82a4d40fa20ef14eeeeac3f59b369051a0e8)
      #06 pc<PHONE_NUMBER>ed9820  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154cc000) (impeller::RenderTarget::SetStencilAttachment(std::_LIBCPP_ABI_NAMESPACE::optional<impeller::StencilAttachment>)+20) (BuildId: 522f82a4d40fa20ef14eeeeac3f59b369051a0e8)
      #07 pc<PHONE_NUMBER>ecd7f4  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154cc000) (impeller::InlinePassContext::GetRenderPass(unsigned int)+588) (BuildId: 522f82a4d40fa20ef14eeeeac3f59b369051a0e8)
      #08 pc<PHONE_NUMBER>ec81c4  /data/app/~~sHPddXr8dGeuSZh_onAXzQ==/com.gskinner.flutter.wonders-KiETgveYaFyITOsg7nmfRw==/base.apk!libflutter.so (offset 0x154c
      ```

We should be determining in entity pass that we're reading from the backdrop and not using an MSAA stencil, but that isn't working.

FYI @dnfield . I think the issue is that while we add the backdrop_filter_reads_from_pass_texture_/ advanced_blend_reads_from_pass_texture_ of the entire pass when calling drawPicture, I don't think its completely wired up. In wonderous when the advanced blends are on screen we should be hitting 2 subpass reads, but its at 0.

Ahh I think its the clone.

This is probably the cause of the benchmark regressions - they're backdrop filter benchmarks that are now hitting validation errors.


[Initial implementation migration] Add clusterctl-settings and metadata file

What this PR does / why we need it:
Add clusterctl-settings and add metadata for cluster-api contract version
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged):
N/A
Special notes for your reviewer:
N/A
Release notes:

N/A

Looks like retest is not triggering the tide check.
You could push a new commit on top and then remove it to try to retrigger.
For help you can ask in #sig-testing on slack.

/test tide

/retest
Tide is the tool reponsible for merging lgtm/approve prs. It creates a merge commit for each pr.
The repo did not allow merge commits, so i allowed that in the settings. Clicking the merge button is generally discouraged unless necessary.

I would prefer the squash merging than merge so that we could keep a clean history.


Add cabal test to CI

This is probably causing the Hackage test failure

Codecov Report

Merging #21 (af168ec) into main (b0cfb75) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #21   +/-   ##
=======================================
  Coverage   78.08%   78.08%
=======================================
  Files           5        5
  Lines          73       73
  Branches        4        4
=======================================
  Hits           57       57
  Misses         15       15
  Partials        1        1

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 b0cfb75...af168ec. Read the comment docs.

This won't fix Hackage yet (see #22), but it's a start


Idea: Output number of dependencies in Gemfile.lock

Hi there,
I was wondering if you would be interested in a PR to output details about the dependencies that are associated with the Rails application you're analyzing.
It would be something like this:
$ rake stats

+----------------------|------------|----------------+
|                 Name | Total Deps | 1st Level Deps |
+----------------------|------------|----------------+
|  fastruby-styleguide | 58         | 6              |
|                rails | 42         | 14             |
|           sass-rails | 29         | 1              |
|          web-console | 25         | 4              |
|         dotenv-rails | 24         | 2              |
|    factory_bot_rails | 24         | 2              |
|        rubocop-rails | 18         | 3              |
| rails_best_practices | 13         | 7              |
|             standard | 11         | 2              |
|    rubocop-ombu_labs | 10         | 1              |
|             jbuilder | 7          | 1              |
|                 reek | 5          | 4              |
|               listen | 3          | 2              |
|           overcommit | 2          | 2              |
|            simplecov | 2          | 2              |
|            test-unit | 1          | 1              |
|          rails_stats | 1          | 1              |
|                 puma | 1          | 1              |
|             bootsnap | 1          | 1              |
|          tzinfo-data | 0          | 0              |
|                   pg | 0          | 0              |
|         high_voltage | 0          | 0              |
|               byebug | 0          | 0              |
+----------------------|------------|----------------+

      Declared Gems   23
         Total Gems   104
  Unpinned Versions   18
        Github Refs   2

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Models               |    34 |    28 |       2 |       3 |   1 |     7 |
| Jobs                 |     7 |     2 |       1 |       0 |   0 |     0 |
| Controllers          |    84 |    65 |       3 |       3 |   1 |    19 |
| Helpers              |    41 |    36 |       0 |       4 |   0 |     7 |
| Javascripts          |   532 |   512 |       0 |      82 |   0 |     4 |
| Configuration        |   397 |   106 |       1 |       0 |   0 |     0 |
| Integration Tests    |    21 |    18 |       1 |       1 |   1 |    16 |
| Test Support         |    10 |     6 |       1 |       0 |   0 |     0 |
| Controller Tests     |    88 |    71 |       1 |       0 |   0 |     0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  1214 |   844 |      10 |      93 |   9 |     7 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 749     Test LOC: 95     Code to Test Ratio: 1:0.1

I realize that you could do this with bundler-stats, but I thought it might come in handy to do everything in one place.
If you were to add this, you would have to add a new dependency to this gem: https://github.com/jmmastey/bundler-stats
What do you think?
Thanks!
Ernesto

I think it adds value, I imagine users interested in the app stats may already be using bundler-stats and it's nice to have all data with only one command.
Maybe we can do the dependency optional if it's a concern? Like:
if Bundler::Stats
  ...
end

And some comment about it in the README.
But only if the required dependency is a concern to you, I think it's ok to have that as a required dependency to simplify the code.


Doesnt work anymore

Hey, this bot was working some days ago, now not anymore.m, it cant connect. Can you take a look at it

Hey, this bot was working some days ago, now not anymore.m, it cant connect. Can you take a look at it

Hello, i'll try to find a solution.


style(mesh/layout): update root layout style

Notable Changes

Set background color in Body rather than Contnet.
Turn BG_WHITE_PAGE_PATHS into BG_GRAY_PAGE_PATHS since most pages have bg-white.
Remove content.tsx component and move the jsx back to layout.tsx, correct the double nested divs to extend the rest of the height of the screen.

For new page

Use main as the root elemnt of the page.tsx.
Set classname grow to main if the page has too little content to fill the main height. (check no-following.tsx)

這個 PR 因 layout 架構更改而關閉


Built wabs app doesn't name package.json file

I created a new app using wabs-starter, with the name "dsw88-test-wabs". I ran an npm install and then ran npm start to launch the app. I got this error:
><EMAIL_ADDRESS>start /Users/dsw88/projects/personal/wabs-test
> node $WABS_INSPECT index.js

ENV: development

Starting server app hot reload

Server listening on port 3000

Server app loading...

========================================
Server app loaded

Error: Multiple errors with properties in the object:
  Missing required value for property: consumerKey
  Missing required value for property: consumerSecret
  Missing required value for property: encryptSecret
    at Error (native)
    at Schema.validate (/Users/dsw88/projects/personal/wabs-test/node_modules/fully-typed/bin/schema.js:113:20)
    at Schema.normalize (/Users/dsw88/projects/personal/wabs-test/node_modules/fully-typed/bin/schema.js:97:10)
    at Middleware.getOptions.then.options (/Users/dsw88/projects/personal/wabs-test/node_modules/byu-wabs/bin/middleware.js:60:46)

I looked at the wabs middleware code and realized it was trying to load from the .wabs/config.json file using the name from my package.json, which was initialized to "wabs-starter-app".
I changed the name to my app name "dsw88-test-wabs", and the app started up successfully after doing that.
It would be great if the wabs-starter would set the name in package.json to be the name of the app we gave it in the wabs-starter configuration.

Sorry I never addressed this. Must have forgotten about it. There is a new version of WABS starter now that bypasses this error.


Rewards token transfer occurs on zero balance

Noticed that there were a lot of RewardTokenCollected events with a zero amount.  Looks like rewards token harvesting and ERC20 transfer appears to occur when it's unnecessary.  Haven't investigated them all, but my spot checks show it's probably from allocate() being called on mint(), which leads to harvest()
https://github.com/OriginProtocol/origin-dollar/blob/260ed61ab30c74cf55bb759480f3579d91d97bf4/contracts/contracts/vault/VaultAdmin.sol#L324
Which then tries to collect rewards and does a transfer regardless of balance.
https://github.com/OriginProtocol/origin-dollar/blob/260ed61ab30c74cf55bb759480f3579d91d97bf4/contracts/contracts/utils/InitializableAbstractStrategy.sol#L64-L69
Probably not a big deal, but could probably save some gas by checking a balance and only harvesting when it's worth it?  A zero transfer probably isn't worth an external contract call.  And dust probably isn't worth a uniswap swap.

@tomlinton is this necessary because of the unknowable CRV balance on the 3pool strategy? I assume that these events were a symptom of us having the threshold set at 0 on Compound. Or is this something else that should remain open?

Yes, we don't know the CRV balance so it attempts it every time. Now we will have the same issue with Compound since governance removed that auto collect COMP.

We could fix this by implementing methods on the strategies to determine there balance and changing the harvesting to call that.
In the case of CRV (from memory) it requires a write to get an accurate balance as it updates a snapshot. I think the same call occurs automatically on a harvest anyway, so i'm not sure what will be more gas optimal. Checking and then harvesting if some balance, or just harvesting every time.
I'm not sure what the situation for Compound.

Needs some further research.

This is just a plain ERC20 transfer no?  Why is it unknowable?

Neither are plain ERC20 transfers, they require extra logic.

3pool requires a call to the 3crv minter with the address of the 3pool gauge from the strategy
Compound requires claimComp on comptroller

After you do either of those they become plain ERC20 transfers.

From memory I think 3pool we can get a balance, it just might be a bit out of date, which might suffice for this.

Ah, fair enough.  Reported this on code before COMP claims was implemented.  Guess this might be old now?

@sparrowDom Is this issue still relevant now that we implemented the harvester?

I think we can close it for now. If people call harvest on Convex strategy with zero reward tokens available it is their loss. I assume this will not be happening anymore since there is no economic incentive.

Agree with closing for now.


Fix/spade

In this pull request we fixed a few issues in the spade.py module. We

fixed the calculation of the duration of a pattern, in the output of spade. Previously, in the function restructuring the output format and making it more 'human readable' (concept_output_to_patterns), the calculation of the pattern duration was not always correct, depending on the order of lags and neurons. We fixed the bug by accounting the duration independently from the order of neurons;
added raise ValueErrors in code when the output_format is not one of the two parameters allowed
fixed bug of undefined spectrum type when running spade without surrogates (only FIM)
In addition:
corrected typos in documentation and removed redundant calls to numpy

Hello @stellalessandra! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file elephant/spade.py:

Line 561:80: E501 line too long (80 > 79 characters)
Line 652:80: E501 line too long (80 > 79 characters)

Coverage decreased (-0.02%) to 75.502% when pulling 1c321a43dff2af7e117a0f9161427d908166b308 on INM-6:fix/spade into c78af7ea6cff3645bab306393349aa7d89f05a13 on NeuralEnsemble:master.

Hi Alessandra,
can you please edit your comment

fixed few bugs in spade.py module

and describe in a few words what exactly it fixes? I suppose, it relates much to elif spectrum == '3d#' but it's hard to guess why previous was wrong and now is right.

Hi Alessandra,
can you please edit your comment

fixed few bugs in spade.py module

and describe in a few words what exactly it fixes? I suppose, it relates much to elif spectrum == '3d#' but it's hard to guess why previous was wrong and now is right.

Just updated the description. Please tell me if something is still not clear!

Alessandra, you did it more than enough! :) I very liked your explanation. Consider being a documentation writer for Elephant :+1:


Swift sample app

Hello @brian-armstrong ,
I was creating a sample Swift app. https://github.com/winster/QuietShare
Getting an error while setting the ReceiveCallback. I could not find the definition of that. Can you please help?
Regards
Winster

this should help https://github.com/winster/QuietShare/pull/1

@carlosguedes I have facing same problem, receiveCallback method  not called, what I have to do for fixing this issue.

@brian-armstrong @winster @carlosguedes  Hello. Thanks for your nice hints on this chat.
I just cloned winster's repository and tried to test app.
I am able to hear some sounds when I click "transmit", but receivercallback never called.
I also tried Carlos 's "master-2.zip" which was discussed on above chat, but same issue.
May you explain a bit more? Please help me.
Thanks.

For anyone who faced the same issue as @carlosguedes, I believe the problem was caused by the device dismissing the recording session when accessing the speakers.
Anyway, with swift 5, iphone6s, and iOS 13.1 I was able to solve it by adding
try? AVAudioSession.sharedInstance().setCategory(AVAudioSession.Category.playAndRecord, mode: AVAudioSession.Mode.videoRecording, options: AVAudioSession.CategoryOptions.mixWithOthers)
to my app on startup
Cheers

@NAolERr
Would you be kind to show me your source code for receiving ultrasonic frequency? I could not get it working in my Swift 5 project (Swift UI)
Thanks!
Brandon

QuietShare-master.zip
I will send you whatever I have together, It is a bit of a mess as I have put this aside for now.
some pointers:
send date now button sends the data through sound.
the rotating wheel starts the continuous microphone access. (it cannot be turned off) use two phones to test it out.
if you feel you have the knowhow to do, there was one thing I was trying to figure out. I'm trying to save the sound that is being played so that i can use it agian without processing it through the library. maybe save it in a local variable as data and play it again.


Initial Conversion to GitHub Actions

High Level Task
Following the pattern of the other adapters, create an integration.yml that contains the logic to replace the current CircleCI pattern.
Acceptance Criteria

integration.yml exists on main in dbt-spark.
It follows the patterns of the integration.yml files in other adapter repositories.
It contains at least the stub of the functionality from CircleCI.
Replaces fishtownanalytics/test-container:latest with setup within workflow
It is not expected to be fully functional.  Commenting out anything broken is fine.  The workflow must exist in main to be able to fully test it.  This will also allow the team to spread testing each connections among members.

Details
Leverage the GitHub migration tool to get the initial migration done.   The goal of this tool is only to get you 80% of the way there.
You can do a dry run with the following command it stop it from automatically opening a PR that tells you to set up secrets:
gh actions-importer dry-run circle-ci --output-dir actions-importer/circle-ci-dry-run --circle-ci-project dbt-spark-release-test

The integration.yml in dbt-snowflake is a good reference point for what will need to be set up.

triggers
permissions
concurrency
metadata generation
more?

Unknowns

[ ] Can we create a test matrix for the various spark flavors?
[x] Do we need to test Databricks?  All connection flavors?

answer: No, Databricks testing can be removed

Additional Notes
The repos should be set up in the settings to not allow the CI to run without explicit approval for forks.  require-label-comment should no longer be necessary.  Confirm this is true for spark w/ someone with admin access.
main.yml runs unit tests so they can be removed from this workflow.

Resolved by https://github.com/dbt-labs/dbt-spark/pull/923


[Sandbox] OVN-Kubernetes

Application contact emails
<EMAIL_ADDRESS>,
<EMAIL_ADDRESS>,
<EMAIL_ADDRESS><EMAIL_ADDRESS>Project Summary
A robust Kubernetes networking platform powered by Open Virtual Network (OVN) and OpenvSwitch at its core
Project Description
OVN-Kubernetes is a robust Kubernetes Networking platform, built from the ground up by leveraging Open vSwitch (OVS) as the data plane, and Open Virtual Network (OVN) as the SDN Controller. The project focuses strictly on enhancing networking for the Kubernetes clusters and includes a wide variety of features that are critical to enterprise and telco users.
OVN-Kubernetes community members are active in upstream Kubernetes (particularly in SIG Network) to create new features and then realize them in OVN-Kubernetes. In addition to a feature rich platform, the project also aims to provide a highly scalable and performance CNI.
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/ovn-org/ovn-kubernetes
Additional repos in scope of the application
https://github.com/ovn-org/libovsdb
Projects used by OVN-Kubernetes at its core that are part of Linux Foundation:
https://github.com/ovn-org/ovn
https://github.com/openvswitch/ovs
Website URL
https://ovn-kubernetes.io/
Roadmap
https://github.com/orgs/ovn-org/projects/5/views/4
Roadmap context
We use GitHub Milestones to plan our roadmap - 6 months at a time.
This planning is done with input from the community during our bi-monthly meetings.
Version 1.0 was released on June 14, 2024 and our next release, 1.1 is planned for Q4 2024.
Contributing Guide
https://ovn-kubernetes.io/governance/CONTRIBUTING/
Code of Conduct (CoC)
https://ovn-kubernetes.io/governance/CODE_OF_CONDUCT/
Adopters
https://github.com/ovn-org/ovn-kubernetes/blob/master/ADOPTERS.md
Contributing or Sponsoring Org
Red Hat, NVIDIA
Maintainers file
https://ovn-kubernetes.io/governance/MAINTAINERS/
IP Policy

[X] If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

[X] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?
The main reason for joining CNCF is to increase participation and diversify the OVN-Kubernetes community. By raising awareness about the project, we hope to increase the interest in the project and bring in more outside contributors. This will help us to become more vendor neutral as well.
Benefit to the Landscape
Networking, especially in the context of SDN, is complicated. There are many networking projects out there that provide varying solutions for Kubernetes. OVN-Kubernetes is unique in that it provides feature differentiators that are leveraged in production to meet telco and enterprise use cases. We believe by being included in the CNCF landscape we can raise awareness about the OVN-Kubernetes networking platform, and provide users with features and solutions that are unavailable in the current solutions offered today. See here for more details on our project's value add.
Cloud Native 'Fit'
OVN-Kubernetes is designed specifically for Kubernetes and is running today on almost every cloud platform. It is built by Kubernetes contributors and follows the same design principles as other Kubernetes projects. It is fully compatible with the Kubernetes API and uses Custom Resource Definitions (CRDs) to expose its own APIs. It aims to tackle the challenges present in Kubernetes Cluster Networking Ecosystem: https://ovn-kubernetes.io/#challenges-for-cluster-networking-in-kubernetes-ecosystem.
Cloud Native 'Integration'
As a Networking project, we’d like to build this project in the CNCF, with collaboration from other networking CNI projects that are trying to solve similar problems:
Cilium
Project Calico
Antrea
KubeOVN
Cloud Native Overlap
Of the projects listed above that we could complement, you may also consider that we might overlap a little with Antrea which uses OVS and KubeOVN which uses OVN and OVS:
However we already work in close collaboration with KubeOVN as outlined in the next section. We also collaborate with the other CNIs like Antrea in upstream sig-network working groups and infact work together to solve common problems like designing AdminNetworkPolicy API.
We plan to continue to work more closely with other CNIs moving forward.
Similar projects
A Similar CNCF project is KubeOVN which was founded in 2019 while OVN-Kubernetes was founded in 2016. Both projects use OVN as their SDN controller but their architectures are different and KubeOVN community also works and contributes to the https://github.com/ovn-org/libovsdb that is hosted in our org.
Landscape
No
Business Product or Service to Project separation
Yes, Red Hat OpenShift Networking. Red Hat is known for its “upstream first” identity and with OVN-Kuberentes there is no exception. Any development done for the product is conducted upstream first, including working with and seeking approval of new features or patches from non Red Hat contributors in OVN-Kubernetes upstream community.
Project presentations
Presented to TAG-Network on June 6th 2024. Slides, MeetingNotes
Project champions
No response
Additional information
No response

@nicholasjackson @leecalcote @zachbutcher Does the TAG have a recommendation regarding this project? From the notes there were two outstanding questions that were not answered in the notes.

Apologies, I have been out with flu, will update the DTR as soon as I am back. Both of the questions have been satisfied, the questions were only notes during the meeting and were covered on the call.
TAGNetwork recommend that OVN Kubernetes should progress to a TOC vote for sandbox inclusion, the project is already providing cloud scale solutions for a huge industry member and the wider community have much to gain from its inclusion.

@tssurya please link to the public discussion of LF's OVN org approving the transfer of OVN Kubernetes from OVN to CNCF - if application is approved.

yup pasting the results of voting from OVN org's TSC committee: https://mail.openvswitch.org/pipermail/ovs-discuss/2024-July/053244.html

OVN and Open vSwitch are quite mature solutions. It is great to see the integration of them with K8S.

TAG Contributor strategy has reviewed this project and found the following:

The contributor guide is more complete than most Sandbox projects, including a Reviewer Guide as well
The governance is a Maintainer Council, based on the CNCF template.
The roadmap is a project board, which appears to only set priorities for the next release
There are five maintainers, four of whom work for Red Hat
This project has been under Linux Foundation OVN Project for several years, and is applying to move to CNCF.

This review is for the TOC’s information only.  Sandbox projects are not required to have full governance or contributor documentation.

Project has been given the okay to move to a vote in today's sandbox review
/vote

/check-vote

/check-vote

/check-vote

/check-vote

Congrats on being accepted into the CNCF Sandbox!
Here's a link to your onboarding checklist:
https://github.com/cncf/sandbox/issues/302
If you have any questions or concerns, please don't hesitate to reach out!

With the onboarding issue created, we can go ahead and close this out. :)
Congrats again!

Posting the results of libovsdb voting by OVN TSC: https://mail.openvswitch.org/pipermail/ovs-discuss/2024-November/053376.html for ensuring we have paper trail, sorry that project's vote was separate from the main voting we did.


fix(provisioner): Expand ANSIBLE_ variables with Ansible default locations

PR Type

Bugfix Pull Request

Changes

Expands the ANSIBLE_ environment variables with the Ansible default locations.

$ ansible-config dump

DEFAULT_FILTER_PLUGIN_PATH(default) = ['/c/Users/wilmaro/.ansible/plugins/filter', '/usr/share/ansible/plugins/filter']
DEFAULT_MODULE_PATH(default) = ['/c/Users/wilmaro/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
DEFAULT_ROLES_PATH(default) = ['/c/Users/wilmaro/.ansible/roles', '/usr/share/ansible/roles', '/etc/ansible/roles']

Moves the internal Molecule modules to a path more like upstream. Both filters and libraries are not like Ansible, filters should be singular. Libraries is singular valid for one playbook or one role but it feels more inline with Ansible to name it modules since library is only used in role or playbook context.

For more information about local modules and plugins see the Ansible documentation:
https://docs.ansible.com/ansible/latest/dev_guide/developing_locally.html#adding-a-module-locally
DEBUG: ANSIBLE ENVIRONMENT
---
ANSIBLE_CONFIG: /c/Users/wilmaro/.cache/molecule/win-cmdb-state-sync/gather-facts/ansible.cfg
ANSIBLE_FILTER_PLUGINS: /c/Users/wilmaro/Development/Intermax/roles/win-cmdb-state-sync/venv/lib/python3.6/site-packages/molecule/provisioner/ansible/plugins/filter:/c/Users/wilmaro/.cache/molecule/win-cmdb-state-sync/gather-facts/plugins/filter:/c/Users/wilmaro/Development/Intermax/roles/win-cmdb-state-sync/plugins/filter:/c/Users/wilmaro/.ansible/plugins/filter:/usr/share/ansible/plugins/filter
ANSIBLE_HOST_KEY_CHECKING: 'False'
ANSIBLE_LIBRARY: /c/Users/wilmaro/Development/Intermax/roles/win-cmdb-state-sync/venv/lib/python3.6/site-packages/molecule/provisioner/ansible/plugins/modules:/c/Users/wilmaro/.cache/molecule/win-cmdb-state-sync/gather-facts/library:/c/Users/wilmaro/Development/Intermax/roles/win-cmdb-state-sync/library:/c/Users/wilmaro/.ansible/plugins/modules:/usr/share/ansible/plugins/modules
ANSIBLE_ROLES_PATH: /c/Users/wilmaro/.cache/molecule/win-cmdb-state-sync/gather-facts/roles:/c/Users/wilmaro/Development/Intermax/roles:/c/Users/wilmaro/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles
ANSIBLE_SSH_CONTROL_PATH_DIR: /dev/shm
ANSIBLE_STDOUT_CALLBACK: yaml

First, be sure it passes CI, after this I will have a second look because this change has a lot of potential,.... of breaking stuff. I do understand reasoning behind and support them (to avoid diverging from ansible default behavior), but I need to be sure we do this right or we will all pay the costs of breaking things.

@ssbarnea Fixed formatting :)
@decentral1se Someone in mind? I could poke on of my colleagues to test this?

@decentral1se Someone in mind? I could poke on of my colleagues to test this?

That would be fantastic. If not, well, we can merge and rely on early Q&A testing too.

Will do tomorrow!


PaypalMobile class not found

Hi,
I am trying "MyCordovaShop", and runing my code in ripple emulator. And i am geting error.
This is not executing in android. I have created apk file, and installed in phone. and i am geting error.
03-05 16:16:51.665: D/PluginManager(13867): exec() call to unknown plugin: PayPalMobile
03-05 16:16:51.675: D/CordovaLog(13867): file:///android_asset/www/plugins/com.paypal.cordova.mobilesdk/www/cdv-plugin-paypal-mobile-sdk.js: Line 41 : Class not found
03-05 16:16:51.675: I/chromium(13867): [INFO:CONSOLE(41)] "Class not found", source: file:///android_asset/www/plugins/com.paypal.cordova.mobilesdk/www/cdv-plugin-paypal-mobile-sdk.js (41)

@kapil019 please check this issue and see if the same can be applied to your problem ? https://github.com/romk1n/MyCordovaShop/issues/1

This issue has been fixed, we were runing code on a ripple emulator, that was not working like a simulator. But now i am running app on android and ios. This is working fine for both.


Set Commissioner Data when becoming Leader

This PR fixes #1625

Codecov Report

Merging #1636 into master will increase coverage by 0.48%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master    #1636      +/-   ##
==========================================
+ Coverage   69.08%   69.57%   +0.48%
==========================================
  Files         160      160
  Lines       20317    20055     -262
  Branches     2489     2451      -38
==========================================
- Hits        14036    13953      -83
+ Misses       5382     5223     -159
+ Partials      899      879      -20

Impacted Files
Coverage Δ

src/core/meshcop/leader_ftd.hpp
100% <ø> (ø)
:arrow_up:

src/core/thread/mle_router.cpp
78.69% <ø> (+1.02%)
:arrow_up:

src/core/meshcop/leader.cpp
64.15% <66.66%> (+3.57%)
:arrow_up:

src/core/thread/lowpan.hpp
86.84% <0%> (-13.16%)
:arrow_down:

src/ncp/ncp_base.cpp
30% <0%> (-2.93%)
:arrow_down:

src/core/thread/data_poll_manager.cpp
64.49% <0%> (-2.9%)
:arrow_down:

src/core/thread/address_resolver.cpp
75.66% <0%> (-2.29%)
:arrow_down:

src/core/thread/lowpan.cpp
92.65% <0%> (-1.26%)
:arrow_down:

examples/platforms/posix/radio.c
78% <0%> (-0.42%)
:arrow_down:

src/core/thread/mesh_forwarder.cpp
78.82% <0%> (+0.12%)
:arrow_up:

... and 13 more

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 9428fff...c9ab10d. Read the comment docs.


BUG: 1.9.0rc1 fails to build on macOS when CXX="g++ -std=gnu++11"

Describe your issue.
The new build system of scipy 1.9.0rc1 breaks on macOS when the time-tested setting of CXX="g++ -std=gnu++11" is in use.
Reproducing Code Example
~ ➤ /usr/bin/python3 -m pip install --user build
Collecting build
  Using cached build-0.8.0-py3-none-any.whl (17 kB)
Collecting tomli>=1.0.0
  Using cached tomli-2.0.1-py3-none-any.whl (12 kB)
Collecting pep517>=0.9.1
  Using cached pep517-0.12.0-py2.py3-none-any.whl (19 kB)
Requirement already satisfied: packaging>=19.0 in ./Library/Python/3.8/lib/python/site-packages (from build) (20.9)
Requirement already satisfied: pyparsing>=2.0.2 in ./Library/Python/3.8/lib/python/site-packages (from packaging>=19.0->build) (2.4.7)
Installing collected packages: tomli, pep517, build
  WARNING: The script pyproject-build is installed in '/Users/mkoeppe/Library/Python/3.8/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
  NOTE: The current PATH contains path(s) starting with `~`, which may not be expanded by all applications.
Successfully installed build-0.8.0 pep517-0.12.0 tomli-2.0.1
WARNING: You are using pip version 21.3.1; however, version 22.1.2 is available.
You should consider upgrading via the '/Library/Developer/CommandLineTools/usr/bin/python3 -m pip install --upgrade pip' command.
~ ➤ cd s/sage/scipy
scipy ➤ git checkout v1.9.0rc1                                                            git:boostorg_math_729
warning: unable to rmdir 'doc/sphinxext': Directory not empty
M	scipy/_lib/boost
M	scipy/_lib/unuran
Note: switching to 'v1.9.0rc1'.
scipy ➤ CXX="g++ -std=gnu++11" /usr/bin/python3 -m build .                                                                                git:72a5f4697*
* Creating venv isolated environment...
* Installing packages in isolated environment... (Cython>=0.29.21,<3.0, meson-python>=0.5.0,<0.7.0, numpy; python_version>='3.11', numpy; python_version>='3.8' and platform_python_implementation=='PyPy', numpy==1.18.5; python_version=='3.8' and (platform_machine!='arm64' or platform_system!='Darwin') and platform_machine!='aarch64' and platform_machine!='loongarch64' and platform_python_implementation != 'PyPy', numpy==1.19.2; python_version=='3.8' and platform_machine=='aarch64' and platform_python_implementation != 'PyPy', numpy==1.19.3; python_version=='3.9' and (platform_machine!='arm64' or platform_system!='Darwin') and platform_machine!='loongarch64' and platform_python_implementation != 'PyPy', numpy==1.20.0; python_version=='3.8' and platform_machine=='arm64' and platform_system=='Darwin', numpy==1.20.0; python_version=='3.9' and platform_machine=='arm64' and platform_system=='Darwin', numpy==1.21.6; python_version=='3.10' and platform_machine!='loongarch64' and platform_python_implementation != 'PyPy', numpy==1.22.0; platform_machine=='loongarch64', pybind11>=2.4.3,<2.10.0, pythran>=0.9.12,<0.12.0, wheel<0.38.0)
* Getting dependencies for sdist...
* Building sdist...
+ meson setup --native-file=/Users/mkoeppe/s/sage/scipy/.mesonpy-native-file.ini -Ddebug=false -Dstrip=true -Doptimization=2 --prefix=/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8 /Users/mkoeppe/s/sage/scipy /Users/mkoeppe/s/sage/scipy/.mesonpy-029irg41/build
The Meson build system
Version: 0.63.0
Source dir: /Users/mkoeppe/s/sage/scipy
Build dir: /Users/mkoeppe/s/sage/scipy/.mesonpy-029irg41/build
Build type: native build
Project name: SciPy
Project version: 1.9.0rc1
C compiler for the host machine: ccache cc (clang 13.1.6 "Apple clang version 13.1.6 (clang-13<IP_ADDRESS>.5)")
C linker for the host machine: cc ld64 764

../../meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=gnu++11' not allowed with 'C'

A full log can be found at /Users/mkoeppe/s/sage/scipy/.mesonpy-029irg41/build/meson-logs/meson-log.txt
Traceback (most recent call last):
  File "/Users/mkoeppe/Library/Python/3.8/lib/python/site-packages/pep517/in_process/_in_process.py", line 363, in <module>
    main()
  File "/Users/mkoeppe/Library/Python/3.8/lib/python/site-packages/pep517/in_process/_in_process.py", line 345, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/Users/mkoeppe/Library/Python/3.8/lib/python/site-packages/pep517/in_process/_in_process.py", line 314, in build_sdist
    return backend.build_sdist(sdist_directory, config_settings)
  File "/private/var/folders/38/wnh4gf1552g_crsjnv2vmmww0000gp/T/build-env-xm1fjpkc/lib/python3.8/site-packages/mesonpy/__init__.py", line 811, in build_sdist
    with _project(config_settings) as project:
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/contextlib.py", line 113, in __enter__
    return next(self.gen)
  File "/private/var/folders/38/wnh4gf1552g_crsjnv2vmmww0000gp/T/build-env-xm1fjpkc/lib/python3.8/site-packages/mesonpy/__init__.py", line 798, in _project
    with Project.with_temp_working_dir(
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/contextlib.py", line 113, in __enter__
    return next(self.gen)
  File "/private/var/folders/38/wnh4gf1552g_crsjnv2vmmww0000gp/T/build-env-xm1fjpkc/lib/python3.8/site-packages/mesonpy/__init__.py", line 493, in with_temp_working_dir
    yield cls(source_dir, tmpdir, build_dir)
  File "/private/var/folders/38/wnh4gf1552g_crsjnv2vmmww0000gp/T/build-env-xm1fjpkc/lib/python3.8/site-packages/mesonpy/__init__.py", line 418, in __init__
    self._configure(reconfigure=bool(build_dir) and not native_file_mismatch)
  File "/private/var/folders/38/wnh4gf1552g_crsjnv2vmmww0000gp/T/build-env-xm1fjpkc/lib/python3.8/site-packages/mesonpy/__init__.py", line 442, in _configure
    self._meson(
  File "/private/var/folders/38/wnh4gf1552g_crsjnv2vmmww0000gp/T/build-env-xm1fjpkc/lib/python3.8/site-packages/mesonpy/__init__.py", line 430, in _meson
    return self._proc('meson', *args)
  File "/private/var/folders/38/wnh4gf1552g_crsjnv2vmmww0000gp/T/build-env-xm1fjpkc/lib/python3.8/site-packages/mesonpy/__init__.py", line 426, in _proc
    subprocess.check_call(list(args))
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['meson', 'setup', '--native-file=/Users/mkoeppe/s/sage/scipy/.mesonpy-native-file.ini', '-Ddebug=false', '-Dstrip=true', '-Doptimization=2', '--prefix=/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8', '/Users/mkoeppe/s/sage/scipy', '/Users/mkoeppe/s/sage/scipy/.mesonpy-029irg41/build']' returned non-zero exit status 1.

ERROR Backend subprocess exited when trying to invoke build_sdist

Error message
../../meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=gnu++11' not allowed with 'C'

SciPy/NumPy/Python version information
1.9.0rc1

The new build system of scipy 1.9.0rc1 breaks on macOS when the time-tested setting of CXX="g++ -std=gnu++11" is in use.

Thanks for the report @mkoeppe. This is surprising, and I agree that it'd be nice if this didn't break. That said, you should not have to pass -std=gnu++11, as (a) the SciPy build already does its own selection of C++ standard needed and we may need c++14 already, and (b) in case you would have to set this option, the correct and more reliable way for doing this with Meson is to pass a command-line option like -Dcpp_std=c++11 (see https://mesonbuild.com/Builtin-options.html#compiler-options)
I don't understand exactly how a C++ flag ends up in C flags though. I can't find anything in the docs or the issue tracker about this. My guess is this:

You need a matching set of C and C++ compilers,
If you only set CXX to g++ and don't set CC, then on macOS you could get a mix of clang and g++ - which is bad,
Meson tries to prevent this and tries to select a matching C compiler,
And because you added an unwanted flag, this ends up being gcc -std=gnu++11

That said, even if I add CC I can reproduce this:
% CC='clang' CXX='clang++ -std=c++11' python -m build --no-isolation --skip-dependency-check

* Building sdist...
+ meson setup --native-file=/Users/rgommers/code/scipy/.mesonpy-native-file.ini -Ddebug=false -Dstrip=true -Doptimization=2 --prefix=/Users/rgommers/mambaforge/envs/scipy-dev /Users/rgommers/code/scipy /Users/rgommers/code/scipy/.mesonpy-sj7ksjir/build
The Meson build system
Version: 0.63.0.rc2
Source dir: /Users/rgommers/code/scipy
Build dir: /Users/rgommers/code/scipy/.mesonpy-sj7ksjir/build
Build type: native build
Project name: SciPy
Project version: 1.10.0.dev0
C compiler for the host machine: clang (clang 11.1.0 "clang version 11.1.0")
C linker for the host machine: clang ld64 609

../../meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=c++11' not allowed with 'C'

@eli-schwartz can you perhaps enlighten us about what is going on here?

What is happening here can be boiled down to:
% clang++ -std=c++11 -E -dM - < /dev/null
error: invalid argument '-std=c++11' not allowed with 'C'

So the confusing message about C is coming from Clang itself. I threw this in the debugger, and within Meson:

this is actually coming from _get_clang_compiler_defines,
called on line 533 defines = _get_clang_compiler_defines(compiler),
called from detect_cpp_compiler.

Everything is in order there, the compiler variable contains ['clang++', '-std=c++11'] and we're inside the C++ compiler detection.
The remaining question to me is whether we can improve the error message. @eli-schwartz is compiler ever allowed to contain flags, so the variable compiler can have length >1? If not, checking that and explicitly erroring out is easy. If it is okay, then whether something works or not completely depends on whether <FLAG> happens to work in clang++ <FLAG> -E -dM - < /dev/null

Thanks for tracking this down. I think setting the CXX variable like this is quite common, for example autoconf sets it this way in https://github.com/autotools-mirror/autoconf/blob/master/lib/autoconf/c.m4#L2779; but I agree that with a clear error message users could just adjust their variable settings.

The remaining question to me is whether we can improve the error message. @eli-schwartz is compiler ever allowed to contain flags, so the variable compiler can have length >1? If not, checking that and explicitly erroring out is easy. If it is okay, then whether something works or not completely depends on whether <FLAG> happens to work in clang++ <FLAG> -E -dM - < /dev/null

The obvious, common one is CC='ccache clang'. Of course that's easily detected.
In fact, the question "is it allowed to have length >1" is a really good question, which leads into the question of "so what exactly is a compiler, anyway?" and turns out to have a fantastic answer. "It's complicated." :p
One less common "compiler" turns out to be CC='gcc -specs /usr/lib/musl/lib/musl-gcc.specs'; the -specs option is always accepted and actually modifies how the compiler driver itself works (you can also think of it as "gcc has a default specs file which you can override on the command line before passing any other options").
So... is CC='clang++ -std=c++11' something that should be called "a compiler"? Apparently clang itself disagrees, it says that -std=c++11 is a compiler option which is not necessarily valid at any given location. Perhaps -std is a CXXFLAGS then, rather than a CXX? :thinking:

I think setting the CXX variable like this is quite common, for example autoconf sets it this way

It's not clear to me that:

autoconf is the best place to be drawing examples from on general principle
something autoconf does deep inside its own compiler detection code is a good proof that end users do it too at parts of the compilation process that come before compiler detection

I did however discover that g++ issues a warning for the same command line (-std and all).
$ g++ -std=c++11 -E -dM - < /dev/null
cc1: warning: command-line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C
#define __SSP_STRONG__ 3
#define __DBL_MIN_EXP__ (-1021)
#define __UINT_LEAST16_MAX__ 0xffff
[...]

Of course, "-" is not a file detected as any particular language (it's stdin!) so it does make a certain amount of sense that it thinks it is trying to compile a C source instead of a C++ one. It's not supposed to matter.
Passing -xc++ here helps, but _get_clang_compiler_defines doesn't know which language it's looking for. It could be refactored and language-mapped to do so, I suppose...  I still think the proper answer is that this isn't really a compiler, and you might be able to get away with it for -std but I wouldn't want to more generically rely on it.

Thanks for that detailed answer @eli-schwartz. So I guess the outcome is "no, not easy to emit a better error message from within the bowels of Meson compiler detection machinery". So let's close this issue and leave it at that.

Well, I should say that currently it's basically as clear as mud what the compiler detection machinery does to produce the results it does.
After any failing setup, Meson always says "A full log can be found at <builddir>/meson-logs/meson-log.txt" and the expectation is that you want to actually look in there to figure out what happened. Which means in turn that we have a duty to, well, actually log useful stuff there.
We actually have a framework for stuff like compiler.compiles(), the sanity check code uses a similar logging approach.
The compiler detection code uses a bunch of Popen with no logging, which means doing forensics requires stepping into the Meson source code, and that much should be fixed. This has caused problems for me in the past at least once, I really should fix it and maybe now I actually will. ;)
... also unable to foo. \n <stderr> is not quite so explanatory as unable to foo.\n Stderr: <stderr>
What I don't think is practical is to analyze those flags and provide a targeted error message saying "oh yeah, these flags should be passed in CXXFLAGS instead of CXX".

The compiler detection code uses a bunch of Popen with no logging, which means doing forensics requires stepping into the Meson source code, and that much should be fixed.

+1


nixos/sysctl: allow merging identical option definitions

Description of changes
Use mergeUniqueOption instead of mergeOneOption for sysctl options, to allow multiple non-conflicting definitions to coexist.
Currently something like
{
  outputs = {nixpkgs, ...}: {
    nixosConfigurations.foo = nixpkgs.lib.nixosSystem {
      modules = [
        {
          boot.isContainer = true;
          system.stateVersion = "23.05";
          nixpkgs.hostPlatform = "x86_64-linux";
        }
        {boot.kernel.sysctl."net.ipv4.conf.default.forwarding" = 0;}
        {boot.kernel.sysctl."net.ipv4.conf.default.forwarding" = 0;}
      ];
    };
  };
}

followed by nix build .#nixosConfigurations.foo.config.system.build.toplevel will result in
       error: The option `boot.kernel.sysctl."net.ipv4.conf.default.forwarding"' is defined multiple times while it's expected to be unique.

       Definition values:
       - In `/nix/store/0zyfib4lvfzj8br8rnlz3bv29r9dnp8z-source/flake.nix': 0
       - In `/nix/store/0zyfib4lvfzj8br8rnlz3bv29r9dnp8z-source/flake.nix': 0
       Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.

I think it should not be an error to define sysctl options multiple times, as long as the values are always the same.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

any feedback on this? cc @happysalada

This is a good idea, but this appears to cause an ofborg eval failure. Maybe something is relying on the current behavior.


TextBuffer.setTextInRange is deprecated.

The undo option is deprecated. Call groupLastChanges() on the TextBuffer afterward instead.
TextBuffer.setTextInRange (<embedded>:33539:22)
TextEditor.setTextInBufferRange (<embedded>:3552:35)
AtomReact.autoCloseTag (C:\Users\Karo\.atom\packages\react\lib\atom-react.coffee:348:27)
<unknown> (C:\Users\Karo\.atom\packages\react\lib\atom-react.coffee:379:24)
Function.module.exports.Emitter.simpleDispatch (<embedded>:66751:20)
Emitter.emit (<embedded>:66880:34)

Thanks for contributing!
It appears that this is being caused by the react package, not Atom itself. It may be that there is still a bug in Atom. If so, we'll need the maintainer of the package that is causing the problem to help track that down. You should file this issue on their repository so they can either fix the problem or tell us where the problem is coming from. The Atom FAQ has information on how to contact the maintainers of any Atom community package or theme.


DAML-AL can't download modAL~=0.3.6

Describe the bug
https://github.com/vmware/data-annotator-for-machine-learning/actions/runs/5140728902/jobs/9252563026
Reproduction steps

git clone https://github.com/vmware/data-annotator-for-machine-learning.git
cd active-learning-service
pip install -r requirements.txt

Expected behavior
can download the dependences without any error
Additional context
No response

the author is aware of this, it is intentional, hi replied soon move modAL to a new package name and will fix the documentation.
https://github.com/modAL-python/modAL/issues/168

fix
https://github.com/vmware/data-annotator-for-machine-learning/actions/runs/5174276358


Lack of Input Validation in Note Creation

There is no input validation or sanitization when creating or updating a note (create_note, update_note). This opens up the application to potential injection attacks, such as Cross-Site Scripting (XSS) or even command injection in the future.
Use input validation and sanitization libraries to filter out or encode potentially harmful input. For Flask, libraries like bleach can be used to sanitize user input.

@CSGY-9223-Group3/engineering & @CSGY-9223-Group3/security
Bleach is deprecated, https://github.com/mozilla/bleach/issues/698. Please use a different HTML sanitization library such as https://github.com/matthiask/html-sanitizer/

Thank you @dr3394 for raising this important security concern, and @jjl9839 for the updated recommendation on the sanitization library.
We have addressed this issue by implementing input sanitization for both note creation and updates. Here are the changes we've made:

We've added the html-sanitizer library as recommended, which is actively maintained and suitable for our needs.

We've updated both the create_note and update_note functions to sanitize user input before storing or updating note content.

The sanitization process helps prevent potential XSS attacks and other injection vulnerabilities by removing potentially harmful HTML elements and attributes while preserving safe content.

Here's a snippet of the implemented changes:
from html_sanitizer import Sanitizer

sanitizer = Sanitizer()

def create_note(note_id, user, data, is_public):
    sanitized_data = sanitizer.sanitize(data)
    notes[note_id] = {"text": sanitized_data, "author": user, "isPublic": is_public}
    # ... rest of the function

def update_note(note_id, user, data):
    if can_user_modify(user, note_id):
        sanitized_data = sanitizer.sanitize(data)
        notes[note_id]["text"] = sanitized_data
        # ... rest of the function

Adjusted to make it a function:
def sanitize_input(data):
    """Sanitize user input to prevent XSS."""
    return sanitizer.sanitize(data)


JENKINS_UC env not effiect during run build

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?
ubuntu 22.04 server
Reproduction steps
create plugin lists
cat >plugins.txt<<EOF
blueocean
Configuration as Code
pipeline
git
EOF

create Dockerfile
cat >Dockerfile<<EOF
FROM jenkins/jenkins:2.346.3
ENV JENKINS_UC=https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
ENV JENKINS_UC_DOWNLOAD=https://mirrors.tuna.tsinghua.edu.cn/jenkins
COPY --chown=jenkins:jenkins plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt
RUN echo 2.0 > /usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state
EOF

run build
docker build -t registry.cn-shenzhen.aliyuncs.com/cnmirror/custom-jenkins:2.346.3 .

failed logs , why not use my ENV ENV JENKINS_UC=https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
root@ubuntu:/data/jenkins# docker build -t registry.cn-shenzhen.aliyuncs.com/cnmirror/custom-jenkins:2.346.3 .
Sending build context to Docker daemon  3.072kB
Step 1/6 : FROM jenkins/jenkins:2.346.3
 ---> ba3f3e7db66d
Step 2/6 : ENV JENKINS_UC https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
 ---> Using cache
 ---> fa17ec21f102
Step 3/6 : ENV JENKINS_UC_DOWNLOAD https://mirrors.tuna.tsinghua.edu.cn/jenkins
 ---> Using cache
 ---> 0e0b9d80014e
Step 4/6 : COPY --chown=jenkins:jenkins plugins.txt /usr/share/jenkins/ref/plugins.txt
 ---> 7ae61935e100
Step 5/6 : RUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt
 ---> Running in 6eec2f3653ad
Aug 12, 2022 8:52:50 AM org.apache.http.impl.execchain.RetryExec execute
INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://updates.jenkins.io:443: The target server failed to respond
Aug 12, 2022 8:52:50 AM org.apache.http.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://updates.jenkins.io:443
Aug 12, 2022 8:52:51 AM org.apache.http.impl.execchain.RetryExec execute
INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://updates.jenkins.io:443: The target server failed to respond
Aug 12, 2022 8:52:51 AM org.apache.http.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://updates.jenkins.io:443
Multiple plugin prerequisites not met:

mailer (438.v02c7f0a_12fa_4) requires a greater version of Jenkins (2.357) than 2.346.3,

instance-identity (116.vf8f487400980) requires a greater version of Jenkins (2.357) than 2.346.3,

cloudbees-folder (6.758.vfd75d09eea_a_1) requires a greater version of Jenkins (2.359) than 2.346.3,

workflow-job (1232.v5a_4c994312f1) requires a greater version of Jenkins (2.359) than 2.346.3,

sse-gateway (1.26) requires a greater version of Jenkins (2.361) than 2.346.3,

pubsub-light (1.17) requires a greater version of Jenkins (2.361) than 2.346.3
The command '/bin/sh -c jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt' returned a non-zero code: 1

Expected Results
download plugin from env ENV JENKINS_UC
Actual Results
download plugin still from  https://updates.jenkins.io:443
Anything else?
No response

Cf https://github.com/jenkinsci/docker/pull/1785, you have to set 3 environment variable for jenkins-plugin-cli to use your custom UC:

JENKINS_UC
JENKINS_UC_EXPERIMENTAL
JENKINS_PLUGIN_INFO

See https://github.com/jenkinsci/docker#setting-update-centers
Note that JENKINS_UC doesn't change the UC used by Jenkins runtime, it's only used by jenkins-plugin-cli tool.


Use directory (instead of single file) for configuration

This makes consul-template read its configuration files from a directory instead of just the config.json file. The only change in existing behavior is the exact path of the config file (which was moved to a subdirectory).
The use case for this is letting configuration be added independently of this module. Specifically it's useful to allow another process to provide the Vault address and token.

Hi, in respect of the Vault configuration, can you comment on the changes I made to master a month or so ago? https://github.com/gdhbashton/puppet-consul_template/issues/24
If there's no need to add more config, I'd prefer to keep things simple :)

Those options work well for many cases, but I'd like to use a separate (consul-template) process to configure Vault's address and token dynamically, which might change independently of Puppet running. Reading from a configuration directory makes this easier without complicating this module.

Thank you! :)


Log Graphite batch size and timeout

Make it crystal clear how Graphite batching has been configured.

Example output:
[graphite] 2015/08/20 11:22:50 Starting graphite service, batch size 1000, batch timeout 1s

Verbal +1 from @DanielMorsing