Activate sphinx-needs extension in doc config.

The docs have lots of sphinx needs directives in them, including implementation (.. impl::) and tests (.. test::). These are defined by the sphinx-needs extension, which is in our requirements but not actually activated in our docs config. This activates it in the docs. The net result is that hundreds of errors in the doc build process are resolved.

Checklist

[x] This PR has only one purpose or idea.
[x] Tests have been added/updated to verify that the new/changed code works.

[x] The code style follows good practices.
[x] The commit message(s) follow good practices.

[x] The release notes (location doc/release/0.X.rst) are up-to-date with any important changes.
[x] The documentation is still up-to-date in the doc folder.
[x] If any requirements were affected, mention it in the release notes.
[x] The dependencies are still up-to-date in pyproject.toml.

I explicitly removed this.
ARMI does not contain any "requirements", and thus the sphinx-needs tooling fails.
As ARMI can't move the requirements into this repo, it will never be possible to build a set of requirements into the ARMI docs. And this is by design.

I would like to close this PR.

and thus the sphinx-needs tooling fails.

Right now there are hundreds of errors when building the docs due to impl and test directives not found. So this is kind of a problem in either direction. We should at least suppress or otherwise handle the errors (perhaps by including 'dummy'/no-op definitions of these directives in our conf.py with detailed docs about why they're in there. Then we could also remove sphinx-needs from project requirements.
However, ...

ARMI can't move the requirements into this repo,

I don't think this has to be 100% true. I believe we can come up with a way to bring at least some framework-specific requirements into the repo. as a best practice and good example.   I haven't thought much about this but it's worth pondering.

As long as the docs still build, I'm sure this is fine.
I thought the docs didn't build with this dependency added. But maybe it was the conf.py links to sphinx-needs that were the problem.

This does not seem to change the error messages being thrown by the ARMI HTML docs build.
For instance, both log files have this error:
/home/runner/work/armi/armi/armi/__init__.py:docstring of armi:1: ERROR: Unknown directive type "impl".

.. impl:: Settings are used to define an ARMI run.
    :id: I_ARMI_SETTING1
    :implements: R_ARMI_SETTING

And there are ~260 such "ERROR"s.  None of them affect the build in either case.


Buffering / Loading Spinner

These changes should improve the visibility and behavior of the loading/buffering spinner, on 2D devices and in the 2D browser context on Oculus or Vision Pro.

The loading spinner should now work correctly for both full-screen (index.html) and embedded, even if multiple embedded players are loading at the same time.


Transformations using columns which themselves are a result of transformation

In https://github.com/apache/incubator-pinot/pull/5238 we added transform functions feature.
This issue has the design doc: https://github.com/apache/incubator-pinot/issues/5135.
This is one of the follow ups.
In the transform functions support so far, we have 1 limitation.
If destColumn = f(sourceColumn), then, destColumn cannot be used as an input to another transform function in the same schema.
Example:
source columns: foodExpenses=[100, 500, 200], totalExpense=4000
destination columns: totalFoodExpense = sumOfAll(foodExpenses)
So totalFoodExpense cannot be used as input to another transformFunction.
This is the behavior that we want to change.
Now we want to add support for using totalFoodExpense as input to another transform function
source columns: foodExpenses=[100, 500, 200], totalExpense=4000
destination columns: totalFoodExpense = sumOfAll(foodExpenses), percentFoodExpense = totalFoodExpense/totalExpense * 100

hi @npawar I'd like to work on this. I think we need to sort the columns in topological order before applying the transform function


RuntimeError: This event loop is already running.

Describe the bug
I don't know if this is related to platform or code.
I try to run Taskweaver in Azure Machine Learning Studio.
I get 'RuntimeError: This event loop is already running' when trying to run Taskweaver.
To Reproduce
I clone the code on Azure Machine Learning Studio and run it using Jupyterlab terminal.
Pip installed all the necessary packages.
Then I do a 'chmod 600 TaskWeaver'.
Then I start the taskweaver by doing: python -m taskweavr =p ./project/
The starting is fine.
When I ask it to do something, it runs into the error.
Screenshots

Environment Information (please complete the following information):

Azure Machine Learning Studio
Python Version 3.10
LLM that you're using: tried on both gpt35-16k and gpt-4

Hi @SingTeng, I also encountered the same issue in AML. The error message suggests that the kernel started by TaskWeaver runs inside another kernel (guess it is the Jupyter-lab terminal you mentioned).
Not sure how AML manages the Jupyter kernels, so it would be better to move to another compute platform.

@ShilinHe What would be your suggested compute platform on Azure?

ok. I am here to provide a solution.
In Azure Machine Learning Studio, you can start terminal to run Taskweaver.
The trick is to have the Taskweaver in localfiles, not cloudfiles.
Normally when we run things on AzureML, it is default to cloudfiles. But in this case you have to switch to localfiles.

Hi @SingTeng, so glad to see that you have resolved the issue!
Could you also add a detailed instruction of how to configure it in AML in this issue thread?  so that other people could learn and benefit from your experience. Thanks!

In Azure Machine Learning Studio, open up a terminal, you can do it directly in Notebooks or use the JupyterLab.
In the the terminal, do a 'cd ~' which will take you back to home directory.
Do a 'ls', you will now see 3 folders: cloudfiles localfiles readme
Go into localfiles, and git clone / copy your TaskWeaver into the directory.
Then set up as per normal instructions on TaskWeaver guide.


Default traits to empty array in useFlags

The typescript definitions for the useFlags mark the traits array as optional. However, if you omit the array when using the hook, you'll be faced with the following warning which comes from the flagsAsArray function.

'Flagsmith: please supply an array of strings or a single string of flag keys to useFlags'

Changing the traits to default to an empty array in the function signature would remove the error and still keep the types the same. We just have to change ?: to : otherwise TS will complain that you can't have a ? and a default value.

Awesome makes sense, thanks for this!

Published under 2.0.0-beta.2


this.context.listView.columns is an empty array

Category

[x] Bug

Describe the bug
this.context.listView.columns in a Command Set is always an empty array. This has been working fine until today.
Steps to reproduce
Create a new command set extension and log this.context.listView.columns.
Expected behavior
this.context.listView.columns in Command Set provides a list columns in the current view
Environment details (development & target environment)
Office 365
The issue occurs in target and standard release.

Hi,
I debug in my environment, I could get it in OnExecute while not in onListViewUpdated.

Lee
Microsoft SharePoint Community Support

Thanks Lee. OnExecute is too late for me. Until yesterday, this worked perfectly in OnListViewUpdated.
Hundreds of customers use this app and suddenly it stops working...

At our company we have the excact same issue in a commandbar extension.
In the  onInit  of the commandset class:
export default class KpiItemEditorCommandSet extends BaseListViewCommandSet<ICompanyCommandSetProperties>
[...]
@override
public async onInit(): Promise<void>
{
   const columns = this.context.listView.columns
}

This suddenly returns an emprty array, while functionality in our case depends on it, while it has worked just a couple of days ago.
Our company is plus-size, and more than a thousend people depend on this.
Also  onExcecute  is too late for us, we need to decide wheter to show the command or not, this is only possible in  onInit
Please let us know what the solution is to fix this.

@florianwachter have you constructed a workaround?

@69mustang302: I now use the viewId from this.context.pageContext.legacyPageContext.viewId to get the columns using the REST api instead. Hope this helps.

@florianwachter thank you, that helps! As a workaround i indeed intend to make a rest query to figure out wheter or not to show my commandbuttons. I hoped for another alternative though, since this is far from ideal because this code will run on any lists in your site, and this will lead to unnecessary traffic and performance impact on lists. So lets hope for a quick resolution by @andrewconnell

@69mustang302 why me?

@andrewconnell ha, because you added the labels, i assumed you could help ;)

@69mustang302 :) I help manage/triage the list. SPFx is my domain & I answer questions where I can, but I can't "fix" anything. I don't work for Microsoft... this is one of my community contributions and giving back to the SP dev community.

Thanks for helping, ofcourse it's greatly appreciated!

Missed this due to some metadata hiccups.  This has been fixed (it was a duplicate of #867 )


karma-webpack 5.0 No longer notified of compilation starting

Operating System: windows
Node Version: 14
NPM Version: 6
webpack Version: 5
karma-webpack Version: 5

Expected Behavior
When watching tests and a change is made we should be notified that a new build is starting. This used to take the form:
[wdm] Compiling...

Actual Behavior
No notification is posted
This seems to be a side effect of removing Webpack Dev Middleware but it is a major pain for us. The webpack builds are up to a minute. This feels so much longer with no indication that a build has actually started.

You could re-implement this with
new webpack.ProgressPlugin((percent, message) => {
  if (percent <= 0) {
    console.info('webpack starting')
  }
})

@ryanclark is this something we should include by default?

As karma is now deprecated and coming up on EOL, we are no longer planning on any significant enhancements to this project and are instead going to focus on security updates, stability, and a migration path forward as karma's lifecycle comes to an end.
Thank you for supporting and using this project!


bump target sdk

Task/Issue URL: https://app.asana.com/0/488551667048375/1203133590036491/f
Description
PR bumps target sdk to 32
Steps to test this PR
Smoke tests

[ ] onboarding
[ ] visit a few sites
[ ] bookmark / favorite sites
[ ] add widget
[ ] download a site
[ ] fireproof / clear data
[ ] test site permissions (you can use webcamera.io)
...

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #2386   👈

This comment was auto-generated by Graphite.


C# 7.3: Expression variables in initializers

This would extend variable declarations and pattern matching syntax to three places where they are not allowed today:

Constructor initializers
Field initializers.
Query clauses

The spec defines the scoping rules and related language design elements.
dotnet/csharplang#32

The updated proposal is here

I reviewed all the existing docs, and we don't say that the new locations are disallowed for declaring out variables where they are used.  The only updates will be in the "What's new" topic.


first build

{package} {version} {:snowflake:}
Destination channel: {Snowflake | defaults}
Links

{ticket_number}
Upstream repository
Upstream changelog/diff
Relevant dependency PRs:

...

Explanation of changes:

...

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_aap4_of28g/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:16: avoid_noarch: noarch: python packages should be avoided
clone/recipe/meta.yaml:49: missing_description: The recipe is missing a description

===== ERRORS =====

clone/recipe/meta.yaml:49: missing_documentation: The recipe is missing a doc_url or doc_source_url
clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
clone/recipe/meta.yaml:43: missing_pip_check: For pypi packages, pip check should be present in the test commands
clone/recipe/meta.yaml:43: missing_imports_or_run_test_py: Python packages require imports or a python test file in tests.
clone/recipe/meta.yaml:49: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:49: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
6 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_24mem801h2/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:16: avoid_noarch: noarch: python packages should be avoided
clone/recipe/meta.yaml:51: missing_description: The recipe is missing a description

===== ERRORS =====

clone/recipe/meta.yaml:51: missing_dev_url: The recipe is missing a dev_url
clone/recipe/meta.yaml:51: missing_documentation: The recipe is missing a doc_url or doc_source_url
clone/recipe/meta.yaml:51: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:45: missing_imports_or_run_test_py: Python packages require imports or a python test file in tests.
===== Final Report: =====
4 Errors and 2 Warnings were found


[BUG] Documentation for Optimizer types has a typo.

Describe the bug
There seems to be a typo for Adagrad  optimizer type in documentation. The type should be listed as hugectr.Optimizer_t.AdaGrad instead of hugectr.Optimizer_t.Adagard.
To Reproduce
https://nvidia-merlin.github.io/HugeCTR/master/api/python_interface.html#createoptimizer-method
Screenshots
If applicable, add screenshots to help explain your problem.

@ashish007git Thank you  for your report! we will fix it in the next realease.

The issue is fixed


KAFKA-17077: The node.id is inconsistent to broker.id when "broker.id.generation.enable=true".

We directly change the broker.id in KafkaConfig when broker.id.generation.enable is set to true. However, this update is NOT synchronized with the node.id in KafkaConfig.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Hi @chia7712
I have add some comments to explain why we need to make nodeId synchronizeswithbrokerId`, PTAL 😄

Hi @chia7712
I have removed the comment and file a jira ticket, PTAL

Hi @chia7712
I have make a little changes based on your feedback, PTAL 😄

Hi @chia7712
I have changed the scope of brokerId, PTAL

Hi @chia7712
I have correct the field name, PTAL

java.lang.NullPointerException
at kafka.server.KafkaServerTest.testGeneratedBrokerIdSyncWithNodeId(KafkaServerTest.scala:205)
at java.lang.reflect.Method.invoke(Method.java:498)
at java.util.ArrayList.forEach(ArrayList.java:1259)
at java.util.ArrayList.forEach(ArrayList.java:1259)

Please fix the failed test

Hi @chia7712
I have refactored the test case with TestUtils, PTAL 🐧

Hi @chia7712
I have rearrange the code structure to avoid unnecessary null check, PTAL 🐧


WASM in CI

[x] Add wasm-pack and wasm32 target to lint and test in CI.
[x] Add caching to most actions to speed up CI builds.
[x] Add features needed for wasm-pack to compile to headless chrome.

This PR does not resolve #143, but it provides the tooling necessary to debug the issues.

Hm, this PR is actually not running my CI workflow, so I can't test it. Not sure what to do here. Maybe I have to added as a developer to the repo?

Codecov Report
Base: 73.3% // Head: 73.3% // No change to project coverage :thumbsup:

Coverage data is based on head (12afae0) compared to base (395eaf0).
Patch has no changes to coverable lines.

Additional details and impacted files
@@          Coverage Diff           @@
##           master    #144   +/-   ##
======================================
  Coverage    73.3%   73.3%
======================================
  Files          33      33
  Lines        5486    5486
======================================
  Hits         4021    4021
  Misses       1465    1465

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

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

@dr-orlovsky Please also see if this is okay:
https://github.com/cryptoquick/rust-amplify/pull/1
I did that because of the error in the linter test:
https://github.com/rust-amplify/rust-amplify/actions/runs/3190687266/jobs/5206524255#step:5:63

I see. Since we can't update edition (pls see rationale in that PR), we have to restrict the max one_cell version to the one before edition upgrade. In fact it is a failure of once_cell maintainers which introduced 2021 edition (which is a breaking change) without major version bump

This apparently blew up in a discussion in the once_cell crate, but I found this:
https://github.com/matklad/once_cell/issues/201#issuecomment-1258808649
Can you try re-running my CI actions again?

Thanks! Looks like the things I'd expect to fail on wasm to fail, except the desktop clippy lints, which I believe found legitimate issues... Can this be merged, then?

Awesome!


typeorm-typescript/enforce-relation-types, support "Relation"

Hello!
Can u add support for this case:
import { Column, Entity, OneToOne, OneToMany, Relation } from 'typeorm';

class Entity {
    // Should be Other | null
    @OneToOne(() => Other)
    @JoinColumn()
    other: Relation<Other>;

    @OneToMany(() => Other, ...)
    other2: Relation<Other>[];
}

https://github.com/typeorm/typeorm/issues/4526#issuecomment-1076462998
This is the correct description of the column, but the linter reports an error:
Type of other in Entity is not consistent with the TypeORM relation type OneToMany
(expected type: Other).eslint[typeorm-typescript/enforce-relation-types](https://github.com/daniel7grant/eslint-plugin-typeorm-typescript#typeorm-typescriptenforce-relation-types)

Thank you for your work!

Thank you for the issue, there is already an ongoing PR in the form of #16 about adding a relation wrapper. I didn't have time so far to look over the implementation but I will try to do it in the following days.

It turned out to be a smaller change than expected, I added this in #18. Feel free to test it and I'll put out a new patch version in the following days.

And, just so you know, the plugin does not work correctly if "strictNullChecks": false in project. I am sure that this is the problem of those who use it, but I think it would be right to write this to README.

Thanks for testing!
As for the order of the wrapper, I've chosen somewhat arbitrarily Relation<T[]> , mostly based on this Stack Overflow thread. I couldn't find anything in the TypeORM docs, so I just used this answer. If you can point me towards any official suggestion, I'll change it.
I tried with OneToMany, it seems to be working to me. Your problem might be that if you misspell the name, it won't be added to the suggestion either: d: Relation<Aaa> will suggest d: Relation<Aaa[]> correctly.
For strictNullChecks, I wasn't able to reproduce it. Can you send me a tsconfig or anything that makes it break with the example configuration? Assuming this is a real problem, I'm not sure how to deal with it. I'll probably follow your advice and add a note to the README... without strict null-checking, this is mostly a cosmetic library.

I merged the wrapper configuration in #18 with this setup. If you have any more issues feel free to reopen.


Update init.sh

Added Decloud Node Lab snapshot provider

Please make sure to update chart version each time you update anything in the chart.
I'm Chart.yaml file.

You mean https://github.com/akash-network/helm-charts/blob/main/charts%2Fakash-node%2Fvalues.yaml ?

Please make sure to update chart version each time you update anything in the chart. I'm Chart.yaml file.

done

Thank you @Dimokus88 , I've fixed up multiple commits into one, with small cosmetic fixes.


Dev

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[SPARK-18490][SQL]duplication nodename extrainfo for ShuffleExchange

What changes were proposed in this pull request?
In ShuffleExchange, the nodename's extraInfo are the same when exchangeCoordinator.isEstimated
is true or false.
Merge the two situation in the PR.

Test build #68770 has started for PR 15920 at commit 5e1396c.

Test build #68770 has finished for PR 15920 at commit 5e1396c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/68770/
Test PASSed.

merged to master/2.1


@PageTitle not working on vaadin-quarkus

Closing due to failure in transfer. Actual issue is ticket 67


Types of fields in ContainerConfiguration

In https://github.com/almoehi/reactive-docker/blob/master/src/main/scala/com/kolor/docker/api/entities/ContainerConfiguration.scala shouldn't image be a String instead of an Option[String], since it's a required value?
Also I think volumes should be just a Map[String, DockerVolume], same thing for exposedPorts, env and probably others.

I think wrapping everything in Option[X] happened unintentionally and probably is mostly related to json deserializers where readNullable returns an Option[X]. Of course this could be changed to to make volumes a Map.empty
Changing Option[X] for map-like properties would cause existing code to break and require some small refactorings for current users.
Any comments from someone else ?
Regarding the image property: This is true for docker containers. However, ContainerConfiguration is shared by ContainerInfo and DockerImageInfo where image(and lots of other properties) can be empty or missing. (at least this was the case during early development which used 0.x docker versions - maybe it changed in the meantime ?)

Not sure about ContainerInfo / DockerImageInfo (though I can't imagine any scenario where the image information wouldn't be present), but even so, if the image is required in one context and not required in another context, then there should be different types modeling each case.


dotnet core  on  arm-linux .  How to distinguish between armel and armhf.

dotnet publish -r linux-arm         The content of the publish is  about armel or about armhf ?
On command,  How to distinguish that ?

AND ,          When will arm64 be released ?

There are no concrete dates for arm64 although it is being worked on. linux-arm is armhf. I don't think there are armel builds available but I may be wrong. @RussKeldorph @jkotas in case they know more.

Samsung has been publishing armel packages for Tizen: https://www.nuget.org/packages/runtime.tizen.4.0.0-armel.Microsoft.NETCore.App/
cc @alpencolt @gbalykov

Looks like the answer then is to use linux-arm for armhf and tizen-arm for armel for now. I'm going to close this issue. Let us know if you have other questions.


HIVE-27956: Query based compactor implementation separation

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

Is the change a dependency upgrade?

How was this patch tested?

Since this PR is very far from the master now, it is easier to open a new PR.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/45447

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/45734

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/48584

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/76480

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/96836

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/106364


Broader Dashboards structure

Is your feature request related to a problem? Please describe.
Dashboards are usually more complexly nested that single page. In case of Superset and Qlik Sense, dashboards consist of pages and each page consist of charts (aka visualisations of the data), metrics and dimensions.  Currently, we can't reflect this in the Open Metadata.
Also, some BI instruments allows users to separate their dashboards using so-called Streams (very database like).  Each team might have up to 4 streams to publish their dashboards to.
Thus we get a hierarchical structure with several levels.
Describe the solution you'd like
A more complex dashboards structure to be reflected in the Open Metadata:

Dashboard Service -> (opt.Stream) -> Dashboard -> Page -> Chart/Metric.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

thanks for filling this issue @Tonilyn! Appreciate the effort!
We have been getting this input from the community about adding folder/page layer on the dashboards. Definitely, we will look into it.
cc @harshach

@pmbrull lets look into this for 0.13

let's add the page as a property for now. We will update the FQN for service.page.dashboard later on

project is already part of the dashboards and ingested
we'll add further details to all entities in here https://github.com/open-metadata/OpenMetadata/issues/11967


Move imports around to make raider-base cleaner

Refactor raider to make the raider-base lighter
Description

By cleaning up import statements and moving isolated imports to their calling functions, this PR provides for a more flexible RAiDER that may not need as many 3rd party package installs.
TBD:

clean up conda installs
add pre-processing functionality for nisar

I'll update this PR with these TBDs but wanted to post now to solicit feedback on the general idea

Motivation and Context

Addresses #533

How Has This Been Tested?

Not tested yet.

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] I have added an explanation of what your changes do and why you'd like us to include them.
[ ] I have written new tests for your core changes, as applicable.
[ ] I have successfully ran tests with your changes locally.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

This needs to be rebased I believe

David asked me to review. I can only say delaying import errors looks good.
try:
     import package
except ImportError
    package = None

def func():
   if not package:
      raise ImportError('Package not imported')


[3.6][Bug][Has Fix] Image Field on validation of another field

Bug report
What I did:
Submitted a form leaving a required field empty (not image field, but another field).
What I expected to happen:
Display values of all fields on validation failure and redirect.
What happened:
Image field URL got duplicate and broken. Broken value is stored as flashed value inside old().
What I've already tried to fix it:
Replaced this line (154):
$hiddenImage.val($mainImage.attr('src'));

With this fix:
@if (isset($field["value"]))
// Initialize hidden form input in case we submit with no change
$hiddenImage.val("{{ $field['value'] }}");
@endif

Backpack, Laravel, PHP, DB version:

Hello @dimitrisdnr ,
i really could not replicate your issue, at least the part where image name is duplicated, maybe i'm doing something different.
This is what i did:
1- Created an entity that has an image field (not required) and a name, that is required.
2- I pick an image and left the name empty so it breaks the validation.
As expected, i'm redirected to create page, with a image (correct one, displaying ok) and a validation error on the name field. I saved it to database.
I got to /entity/1/edit and everything is there as expected.
BR,
Pedro

It seems I provided you with confusing feedback. I'm sorry for that.
Here is the thing. My 'image' field stores an image in the filesystem, and also stores the path to use inside storage disk, in database as a string (e.g. avatars/t453dffd34.jpg). Later, while an image is already stored for that specific record, if I move to that record once more and set a required field as empty (e.g. an input text field) and validation fails, img element for displaying my image will try to display an image from invalid URL after redirect. I hope you manage to reproduce it.

Hello @dimitrisdnr
Thank you for taking time too clarify this issue.
I can confirm it's happening. I tried to stop the problem before it occurs
(The way you are doing is hacking into the value of the image, that might not be correct in every scenario)
I came up checking if value is a valid url before proceding with encoding in case it's not.
This is the complete php top at image.blade.php
    if (!isset($field['wrapperAttributes']) || !isset($field['wrapperAttributes']['class']))
    {
        $field['wrapperAttributes']['class'] = "form-group col-md-12 image";
    }

    $prefix = isset($field['prefix']) ? $field['prefix'] : '';
    $value = old(square_brackets_to_dots($field['name'])) ?? $field['value'] ?? $field['default'] ?? '';
    if (filter_var($value, FILTER_VALIDATE_URL)) {
        $image_url = $value;
    }else{
    $image_url = $value
        ? preg_match('/^data\:image\//', $value)
            ? $value
            : (isset($field['disk'])
                ? Storage::disk($field['disk'])->url($prefix.$value)
                : url($prefix.$value))
        :''; // if validation failed, tha value will be base64, so no need to create a URL for it
}

Could you apply this fixes and check if it's working now as expected ?
I'm a little concerned into pushing a PR to this without proper testing, working with urls is never easy, and from my research i will leave this here for future reference: idn_to_ascii

Yes, I admin that I shared a fast & dirty fix, and this solves the problem in a way, but let me express my dissagreement at one thing.
The reason that old() method returns a full URL as a flashed value is because this full URL was set as value to hidden field input element before form submission.
I honestly believe we should fix this from its root.
My new suggestion after taking a more cautious look is removing line 154 completely: $hiddenImage.val($mainImage.attr('src'));
and modify field element itself:

to get value stored on initialization:

which also gives the possibility of storing default field value upon submitting form (e.g. a link set by developers for a default image).
BR,
dimitrisdnr

This one had already been fixed in: https://github.com/Laravel-Backpack/CRUD/commit/a941d7939fe3763899509a0cae14b61a8c5e4021#diff-831905e64cecad2153bbcb0f931349cc
Best,
Pedro


roc build panic using roc-parser

Using MacOS 14.2.1 with Apple Silicon CPU, roc_nightly-macos_apple_silicon-2023-12-23-6710b371a43:
roc check passes this code:
app "bug"
    packages {
        pf: "https://github.com/roc-lang/basic-cli/releases/download/0.7.0/bkGby8jb0tmZYsy2hg1E_B2QrCgcSTxdUlHtETwm5m4.tar.br",
        parser: "https://github.com/lukewilliamboswell/roc-parser/releases/download/0.3.0/-e3ebWWmlFPfe9fYrr2z1urfslzygbtQQsl69iH1qzQ.tar.br",
    }
    imports [
        pf.Stdout,
        parser.Core.{ oneOf, map, Parser, const, chompWhile, chompUntil, skip, keep },
        parser.String.{ string, codeunit, strFromUtf8, parseStr },
    ]
    provides [main] to pf

Concept : [
    AtomicConcept Str,
    Conjunction { left : Concept, right : Concept },
]

iri =
    const (\d -> d)
    |> skip (codeunit '<')
    |> keep (chompUntil '>')
    |> skip (codeunit '>')
    |> map strFromUtf8

atomicConcept : Parser _ Concept
atomicConcept =
    const AtomicConcept
    |> skip (string "AtomicConcept(")
    |> keep iri
    |> skip (codeunit ')')

conjunction : Parser _ Concept
conjunction =
    const (\left -> \right -> Conjunction { left, right })
    |> skip (string "Conjunction(")
    |> keep concept
    |> skip (chompWhile \c -> c == ' ')
    |> keep concept
    |> skip (codeunit ')')

concept : Parser _ Concept
concept = oneOf [atomicConcept, conjunction]

main =
    Stdout.line (parseStr concept "AtomicConcept(<http://example.org/A>)" |> Inspect.toStr)

but roc build outputs:
An internal compiler expectation was broken.
This is definitely a compiler bug.
Please file an issue here: https://github.com/roc-lang/roc/issues/new/choose
thread '<unnamed>' panicked at 'no lambda set found for (`19.IdentId(57)`, [
    InLayout(
        132,
    ),
    InLayout(
        113,
    ),
]): LambdaSet {
    set: [
        ( 19.48, [InLayout(STR)]),
        ( 19.57, [InLayout(122), InLayout(114)]),
    ],
    args: [
        InLayout(LIST_U8),
    ],
    ret: InLayout(
        40,
    ),
    representation: InLayout(
        103,
    ),
    full_layout: InLayout(
        113,
    ),
}', crates/compiler/mono/src/layout.rs:1597:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@lukewilliamboswell have you run into this issue? (maybe something to do with parsing a recursive type) Do you know of any workaround? (thanks for the library, by the way!)

Yes, I think this is the same as https://github.com/roc-lang/roc/issues/5749 but unfortunately is not a quick fix.
I don't have a good workaround for you. Maybe if you remove the type annotations altogether if might help?

Yes, I think this is the same as https://github.com/roc-lang/roc/issues/5749 but unfortunately is not a quick fix.

Oh, that's too bad, looks like I may need to wait a while.

Maybe if you remove the type annotations altogether if might help?

Weirdly if I remove the type annotations it no longer type checks:
── TYPE MISMATCH ──────────────────────────────────────────────────── main.roc ─

This expression is used in an unexpected way:

43│  concept = oneOf [atomicConcept, conjunction]
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This Core.oneOf call produces:

    Parser (List U8) [
        AtomicConcept Str,
        Conjunction {
            left : Str,
            right : Str,
        },
    ]

But you are trying to use it as:

    Parser (List U8) Str

@lukewilliamboswell I did find a workaround; I noticed your lazy function. I redefined conjunction as:
conjunction = lazy \_ ->
    const (\left -> \right -> Conjunction { left, right })
    |> skip (string "Conjunction(")
    |> keep concept
    |> skip (chompWhile \c -> c == ' ')
    |> keep concept
    |> skip (codeunit ')')

This works! I guess there is still a compiler bug though.

Well... it works for two concept expression types but not for three.


Laravel quietly ignores Symfony's deprecations: @trigger_error()

Laravel Version: 8.73.2
PHP Version: 7.4.26

Description:
The Symfony ecosystem triggers deprecations like this:
@trigger_error("Some deprecation", E_USER_DEPRECATED);

with the @ to suppress error, to make deprecations opt-in. That's a decent idea, IF the app/framework's error handler CAN opt-in. The first thing Laravel's error handler does is:
if (error_reporting() & $level) {

which means all of Symfony's deprecation triggers are always completely ignored. No opt-in possible.
I think Laravel shouldn't check for error suppression if it's a deprecation, because that's how Symfony does deprecations on purpose. This could work beautifully with isDeprecation() and handleDeprecation(), but it doesn't, and it's too early for the app's Handler to do/catch anything.
Steps To Reproduce:
Trigger a deprecation error, anywhere in your app code, with any Laravel config:
@trigger_error("Some deprecation", E_USER_DEPRECATED);

Without the @ it's reported to my deprecations.log, but with the @ it's quietly ignored. Symfony's standard is to do it with the @, so I feel that should work.

Some opt-in details on https://github.com/twigphp/Twig/issues/2082

No, you can't, because they never ever get past Laravel's error handler:
if (error_reporting() & $level) {

That's the problem.....

I can confirm this issue.
My feature tests use $this->withoutDeprecationHandling(); and I use the Faker library which recently deprecated calling the property name in favour of the method itself -> https://github.com/FakerPHP/Faker/blob/v1.19.0/src/Faker/Generator.php#L942
Since Symfony silences those deprecations the test doesn't fail while my expectation is for it to fail.
So TLDR;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;

final class FooTest extends TestCase
{
    use WithFaker;

    public function testFoo(): void
    {
        $this->withoutDeprecationHandling();

        $this->faker->name;
    }
}

Expected result is for the test to fail as Faker emits Since fakerphp/faker 1.14: Accessing property "name" is deprecated, use "name()" instead. deprecation.
Actual result at the moment is that this deprecation is being completely ignored so the test passes.
If I go into vendor and change the Symfony trigger_deprecation method so that it calls trigger_error instead of @trigger_error then the test starts failing (as it should).

Laravel's handleError should do this IMO:
    if ($this->isDeprecation($level)) {
        return $this->handleDeprecation($message, $file, $line);
    }
    elseif (error_reporting() & $level) {
        throw new ErrorException($message, 0, $level, $file, $line);
    }

ALWAYS handle deprecations. The only reason they wouldn't get past error_reporting() & $level is if it's triggered with @trigger_error, and that's exactly the kinds we DO want. But maybe I'm too deprecation error focused now, I just wanna catch them all. Maybe it needs new config, or a way to override Laravel's handleError, or add more handlers, or whatever.

@nunomaduro

Maybe instead of checking for a deprecation error inside the first if
https://github.com/laravel/framework/blob/afeb58d019b203ecb1a1c4063a66a029ea6bea63/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php#L68-L77
We could check it before:
public function handleError($level, $message, $file = '', $line = 0, $context = [])
{
    if ($this->isDeprecation($level)) {
        return $this->handleDeprecation($message, $file, $line);
    }

    if (error_reporting() & $level) {
        throw new ErrorException($message, 0, $level, $file, $line);
    }
}

As the HandleExceptions@handleDeprecation seems handle it either by logging into the null driver or to a configured driver.
I tested locally with and without suppressing the trigger_error() and it works. Didn't want to send a PR, as this is a very sensitive part of the bootstrap phase and I might be missing something and also I am not sure how to write tests for it.


[go_router] throws when calling an unknown route in profile or release mode

Hello, I have an issue regarding GoRouter :
Steps to Reproduce

Create a new flutter app
Replace main.dart by this :

import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final GoRouter router = GoRouter(
      routes: <GoRoute>[
        GoRoute(
          path: '/',
          builder: (BuildContext context, GoRouterState state) =>
              const MyHomePage(title: 'Flutter Demo Home Page'),
        ),
      ],
    );
    return MaterialApp.router(
      title: 'Flutter Demo',
      routeInformationParser: router.routeInformationParser,
      routeInformationProvider: router.routeInformationProvider,
      routerDelegate: router.routerDelegate,
    );
  }
}

class MyHomePage extends StatelessWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);
  final String title;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(title),
      ),
      body: Center(
          child: ElevatedButton(
        onPressed: () => context.push('/unknown'),
        child: const Text('Navigate to unknown page'),
      )),
    );
  }
}

Build in release or profile mode flutter run --release
Clic on the button and the following error appears :

Logs

Logs
I/flutter (14066): LateInitializationError: Local 'initialMatches' has already been initialized.
I/flutter (14066): #0      LateError._throwLocalAlreadyInitialized (dart:_internal-patch/internal_patch.dart:204)
I/flutter (14066): #1      GoRouteInformationParser.parseRouteInformation (package:go_router/src/parser.dart:69)
I/flutter (14066): #2      GoRouter.push (package:go_router/src/router.dart:186)
I/flutter (14066): #3      GoRouterHelper.push (package:go_router/src/misc/extensions.dart:41)
I/flutter (14066): #4      MyHomePage.build.<anonymous closure> (package:go_router_error/main.dart:44)
I/flutter (14066): #5      _InkResponseState._handleTap (package:flutter/src/material/ink_well.dart:1005)
I/flutter (14066): #6      GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:198)
I/flutter (14066): #7      TapGestureRecognizer.handleTapUp (package:flutter/src/gestures/tap.dart:613)
I/flutter (14066): #8      BaseTapGestureRecognizer._checkUp (package:flutter/src/gestures/tap.dart:298)
I/flutter (14066): #9      BaseTapGestureRecognizer.handlePrimaryPointer (package:flutter/src/gestures/tap.dart:232)
I/flutter (14066): #10     PrimaryPointerGestureRecognizer.handleEvent (package:flutter/src/gestures/recognizer.dart:563)
I/flutter (14066): #11     PointerRouter._dispatch (package:flutter/src/gestures/pointer_router.dart:94)
I/flutter (14066): #12     PointerRouter._dispatchEventToRoutes.<anonymous closure> (package:flutter/src/gestures/pointer_router.dart:139)
I/flutter (14066): #13     _LinkedHashMapMixin.forEach (dart:collection-patch/compact_hash.dart:614)
I/flutter (14066): #14     PointerRouter._dispatchEventToRoutes (package:flutter/src/gestures/pointer_router.dart:137)
I/flutter (14066): #15     PointerRouter.route (package:flutter/src/gestures/pointer_router.dart:123)
I/flutter (14066): #16     GestureBinding.handleEvent (package:flutter/src/gestures/binding.dart:445)
I/flutter (14066): #17     GestureBinding.dispatchEvent (package:flutter/src/gestures/binding.dart:425)
I/flutter (14066): #18     RendererBinding.dispatchEvent (package:flutter/src/rendering/binding.dart:329)
I/flutter (14066): #19     GestureBinding._handlePointerEventImmediately (package:flutter/src/gestures/binding.dart:380)
I/flutter (14066): #20     GestureBinding.handlePointerEvent (package:flutter/src/gestures/binding.dart:344)
I/flutter (14066): #21     GestureBinding._flushPointerEventQueue (package:flutter/src/gestures/binding.dart:302)
I/flutter (14066): #22     GestureBinding._handlePointerDataPacket (package:flutter/src/gestures/binding.dart:285)
I/flutter (14066): #26     _invoke1 (dart:ui/hooks.dart:170)
I/flutter (14066): #27     PlatformDispatcher._dispatchPointerDataPacket (dart:ui/platform_dispatcher.dart:331)
I/flutter (14066): #28     _dispatchPointerDataPacket (dart:ui/hooks.dart:94)
I/flutter (14066): (elided 3 frames from dart:async)

[✓] Flutter (Channel stable, 3.0.5, on macOS 12.5 21G72 darwin-arm, locale fr-FR)
    • Flutter version 3.0.5 at /Users/louisdachet/Developer/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision f1875d570e (il y a 7 semaines), 2022-07-13 11:24:16 -0700
    • Engine revision e85ea0e79c
    • Dart version 2.17.6
    • DevTools version 2.12.2

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at /Users/louisdachet/Library/Android/sdk
    • Platform android-33, build-tools 33.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 13.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)

[✓] VS Code (version 1.70.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.46.0

[✓] Connected device (5 available)
    • sdk gphone64 arm64 (mobile) • emulator-5554                        • android-arm64  • Android 13 (API 33) (emulator)
    • iPhone 13 mini (mobile)     • 8D6A52D0-A181-4227-A9E7-33CAAF891258 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-15-5 (simulator)
    • iPhone 13 (mobile)          • D3C89832-C658-4ABD-8AE1-64451C94A5F3 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-15-5 (simulator)
    • macOS (desktop)             • macos                                • darwin-arm64   • macOS 12.5 21G72 darwin-arm
    • Chrome (web)                • chrome                               • web-javascript • Google Chrome 104.0.5112.101

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Expected behavior
The expected behavior is the behavior than in debug mode, ie. landing on the following default error page :

Thanks for your answers !

Hello @Cteq3132. This issue is reproducible on stable and beta but seems to work as expected in master. Therefore, I am closing this issue. If you disagree, please comment and I'll reopen it.


[TreeView] disabled-prop

Closes #19975
This PR adds a new disabled prop to TreeItem

[x] I have followed (at least) the PR section of the contributing guide.

@oliviertassinari Sure, you want to set this as the default behavior or create a new prop as it was done in #19967? I believe that in this second case, it should be done in a separated PR

You have not applied the aria-disabled attribute.

aria-disabled (state)§
Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. See related aria-hidden and aria-readonly.

For example, irrelevant options in a radio group may be disabled. Disabled elements might not receive focus from the tab order. For some disabled elements, applications might choose not to support navigation to descendants. In addition to setting the aria-disabled attribute, authors SHOULD change the appearance (grayed out, etc.) to indicate that the item has been disabled.
The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.
You can still select with the keyboard.
Perhaps use context to pass disabled through for when disabling a parent node ?

The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.

That's an important point that is currently not tested in this PR. @netochaves Would be nice if you could test behavior of child treeitems of a disabled treeitems.

You can still select with the keyboard.

This seems rather restrictive. Is this quoted from somewhere? We currently disable navigation in all our components. I think we can rethink this later similar to https://github.com/mui-org/material-ui/pull/19967/files

You can still select with the keyboard.

This seems rather restrictive. Is this quoted from somewhere? We currently disable navigation in all our components. I think we can rethink this later similar to https://github.com/mui-org/material-ui/pull/19967/files

I was referring to https://github.com/mui-org/material-ui/blob/f1a2ec4ebab84d1ffe7b71e9e31904a44efc26c1/packages/material-ui-lab/src/TreeItem/TreeItem.js#L403
<div
        className={classes.content}
        onClick={!disabled ? handleClick : null}

This is the only place where behaviour changes due to the disabled prop being true ( all other changes are styling).  This prevents focus by click, toggling expansion and selection.  Yet, with the keyboard, you can focus, toggle expansion and select.

That's an important point that is currently not tested in this PR. @netochaves Would be nice if you could test behavior of child treeitems of a disabled treeitems.

Should we disable the expansion of a parent treeItem when it is disabled?

Should we disable the expansion of a parent treeItem when it is disabled?

I think so. disabled usually disables interaction. Since expansion is triggered by interaction it should not be possible.

Hey guys, there's still work to be done here? please let me know.

@netochaves Thanks for the head start. I've updated the PR with some more use cases and added some tests. Still need to add a demo with some wording and make sure the styling is working.

Keeping disabled nodes focusable was easier (and more correct in my opinion)

@oliviertassinari I agree. I don’t think the first demo should be re-used either.

Keeping disabled nodes focusable was easier (and more correct in my opinion)

It's definitely an option but we never did this before. Just like selection follows focus we should make this configurable since you don't know if it makes more sense to keep a disabled item in tab order. The authoring practices encourage a consistent set of rules and this would go against it.

Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements.

-- https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_focus_activedescendant
We can definitely rethink our current set of rules but breaking them because it's easier for us is not really a helpful rationale.
If it's hard to get right in a first PR we should definitely add a warning for now. But if we don't have a viable plan to make it work later we should rethink this feature. It seems to me that the path of least resistance is chosen and justified after the fact.

NVDA logs for when you can focus disabled items.

Thanks for the headstart @netochaves


SMS Notifications

Adds a button enabling residents to subscribe to SMS alerts w/ notifications whenever the wind speed exceeds a predefined threshold.
[[NOT READY TO BE MERGED]]
Opening this PR early so we can have a conversation about how this feature should work.

@benwilhelm -
Here's what I'm thinking:

User clicks "Subscribe to wind speed notifications", they submit their phone number, and we store it in a (postgres?) database.
We poll forecast.io for the wind speed every N minutes. If the wind speed exceeds the threshold, we blast everyone on the mailing list (simple pub/sub model).

One thing we may need to worry about down the road is gusty weather causing residents to receive a barrage of notifications as the wind exceeds dangerous levels, subsides, and then picks up again. I can imagine that this would be really annoying for subscribers.

This roadmap looks good. Fleshing it out a little bit after having discussed some infrastructure options with Christopher:

We can store user info in WuFoo, rather than our own database, which will allow Olga to access the data for her own publicity and organizing purposes without our having to build out a GUI for it.  WuFoo has an API that we can use to pull the phone numbers out when we want to send an alert and to handle subscribe/unsubcribe requests.

I was thinking we'd set a limit of no more than once every 12 hours for the broadcasting alerts, to avoid the situation you describe where users receive repeated alerts on gusty days.  We're already using memcached to cache forecast.io results so that we don't poll their API more than once every 5 minutes. We could easily use it to store a "lastAlerted" timestamp.

Merged in to the feature/sms branch.


Fix typo in numerics/README.md

Fixed typo.
occured -> occurred

[x] CLA signed. If not, go over here and sign the CLA

Thanks for the contribution! It looks like this file came directly from the Chromium source code. We're somewhat hesitant to change upstream files as that makes it slightly harder to track other changes (including incoming ones).
I'll let the team override my opinion here of course 😄

Yea I agree with @DHowett on this. This should be fixed upstream, not here.


Review core-mobile registering some rpcs by default

          tangential; i find it weird we have default rpcs to register on Mobile but not on any other platform afaik

cc @itwin/mobilesdkadmins
Originally posted by @aruniverse in https://github.com/iTwin/itwinjs-core/pull/5103#discussion_r1131113523

@aruniverse: Regarding mobile vs other platforms, I wasn't aware that it wasn't required on other platforms. I wonder if it is actually required on mobile. Our sample app's backend calls MobileRpcManager.initializeImpl() with an array of supported RPCs. Does that happen automatically for the default set of RPCs? Our frontend doesn't call MobileRpcManager.initializeClient(), and yet the RPCs all work.
Having said that, PresentationRpcInterface is already in the list of RPCs that our sample app's backend passes to MobileRpcManager.initializeImpl(), so if mobile is required to initialize all RPCs, then the change to remove the Presentation dependency in iTwin won't affect us. If we're only supposed to register the RPCs that haven't already been registered, then we can update our sample app to do ath.


BatteryLevelConversion

Displays battery level percentage via conversion (and rounding errors), otherwise if battery status is unknown then set null; and some other small stuff.

Thank you! This is nice! But personally, I would separate these post-processing logics outside this repo. E.g., if users want to post-process battery levels, they can call log_manager (which is designed to extract things as-is from FindMy logs) and do post-processing using the output however they want. This would make the code structure more modular and cleaner than adding all possible post-processing logic (which could be different for different use cases) inside one class.

Understood

Do you mean arguments to the constructor of LogManager?
One simple way for users is to inherit from LogManager, and override the methods as needed.


Please add template for VisualStudio and .Net

Hi dear Radzen developers, Thanks for the perfect ecosystem and components.
Please add some templates for VisualStudio and .Net like this
dotnet new install Radzen.Templates
Your template is missing here.

Hi @zandiarash,
We don't plan adding such templates. We believe our product Radzen Blazor Studio and the upcoming Visual Studio extension cover that a lot better.


It seems that constants and enums are optimized，so cant jump to defined line

···
enum eEnumData
eData1
eData2
let man = 100
[export]
def main()
var bro = man + 100
var eData =  eEnumData eData1
···
the eData1 and  man  in main(),can't found  hover info and jump to definition,
May I change some config or compilation options to make it work ？ ):

Hi! answer is same, like in https://github.com/profelis/daScript-plugin/issues/14
You need usage of variable, or compiler can drop it fully. Immutable global variables (constants) can be inlined too.
Where is an option options no_optimizations = true, but it doesn't help here, because majority of this optimization are made in infer phase, before optimizer really works.

Hi! answer is same, like in #14 You need usage of variable, or compiler can drop it fully. Immutable global variables (constants) can be inlined too.
Where is an option options no_optimizations = true, but it doesn't help here, because majority of this optimization are made in infer phase, before optimizer really works.

I find a options optimize = false, this make the enum and const have code hover info showing ):

I find a options optimize = false, this make the enum and const have code hover info showing ):

Be careful, this option slows down your code


Update pylint configuration

Update the pylint configuration

Remove ruff duplicates
Fix some in the tests
Ignore some in the source

codespell will be replaced by cspell in a future PR

No runtime change, only linting


Error: Unauthorized  on .terraform/modules/eks/aws_auth.tf line 65, in resource "kubernetes_config_map" "aws_auth":

Description
Fails to create module.eks.kubernetes_config_map.aws_auth because of unauthorised error.
Versions

Terraform:
Terraform v0.14.8
Provider(s):

+ provider registry.terraform.io/hashicorp/aws v3.34.0
+ provider registry.terraform.io/hashicorp/kubernetes v2.0.3
+ provider registry.terraform.io/hashicorp/local v2.0.0
+ provider registry.terraform.io/hashicorp/null v3.0.0
+ provider registry.terraform.io/hashicorp/random v3.0.0
+ provider registry.terraform.io/hashicorp/template v2.2.0

Reproduction
Steps to reproduce the behavior:
Are you using workspaces?
yes
Have you cleared the local cache (see Notice section above)
yes
List steps in order that led up to the issue you encountered
terraform apply -var-file=prod.tfvars
Code Snippet to Reproduce
eks-cluster.ts
module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = local.k8s_name
  cluster_version = "1.18"
  subnets         = data.terraform_remote_state.networking.outputs.private_subnets

  tags = {
    Terraform = "true"
    Environment = local.workspace
    GithubRepo  = "terraform-aws-eks"
    GithubOrg   = "terraform-aws-modules"
  }

  vpc_id = data.terraform_remote_state.networking.outputs.vpc_id

  workers_group_defaults = {
    root_volume_type = "gp2"
  }

  worker_groups = [
    {
      name                          = "worker-group-1"
      instance_type                 = "t2.small"
      additional_userdata           = "echo foo bar"
      asg_desired_capacity          = 2
      additional_security_group_ids = [data.terraform_remote_state.networking.outputs.worker_group_mgmt_one_id]
    },
    {
      name                          = "worker-group-2"
      instance_type                 = "t2.medium"
      additional_userdata           = "echo foo bar"
      additional_security_group_ids = [data.terraform_remote_state.networking.outputs.worker_group_mgmt_two_id]
      asg_desired_capacity          = 1
    },
  ]
}

data "aws_eks_cluster" "cluster" {
  name = module.eks.cluster_id
}

data "aws_eks_cluster_auth" "cluster" {
  name = module.eks.cluster_id
}

kubernetes.tf
# Kubernetes provider
# https://learn.hashicorp.com/terraform/kubernetes/provision-eks-cluster#optional-configure-terraform-kubernetes-provider
# To learn how to schedule deployments and services using the provider, go here: https://learn.hashicorp.com/terraform/kubernetes/deploy-nginx-kubernetes

# The Kubernetes provider is included in this file so the EKS module can complete successfully. Otherwise, it throws an error when creating `kubernetes_config_map.aws_auth`.
# You should **not** schedule deployments and services in this workspace. This keeps workspaces modular (one for provision EKS, another for scheduling Kubernetes resources) as per best practices.

provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  exec {
    api_version = "client.authentication.k8s.io/v1alpha1"
    command     = "aws"
    args = [
      "eks",
      "get-token",
      "--cluster-name",
      data.aws_eks_cluster.cluster.name
    ]
  }
}

Expected behavior
Create module.eks.kubernetes_config_map.aws_auth[0]
Actual behavior
fails to create
Terminal Output Screenshot(s)
Error: Unauthorized

  on .terraform/modules/eks/aws_auth.tf line 65, in resource "kubernetes_config_map" "aws_auth":
  65: resource "kubernetes_config_map" "aws_auth" {

Additional context
aws provider is pointing to a profile that has  AdministratorAccess.
provider "aws" {
  region = var.region
  shared_credentials_file = "$HOME/.aws/credentials"
  profile                 = "terraform"
}

If you run the aws eks command from command line, what happens?

@schollii
I tried adding that token to the providers kubernetes { }
but i get the following error:
Error: Reference to undeclared resource

  on kubernetes.tf line 21, in provider "kubernetes":
  21:   token = data.aws_eks_cluster_auth.default.token

A data resource "aws_eks_cluster_auth" "default" has not been declared in the
root module.

Adding this to my kubernetes.tf provider file works. thank you
  token = data.aws_eks_cluster_auth.cluster.token

Hi. I am not having the same luck as@kaykhancheckpoint.    I just ran the same terraform in a different account: there it worked and in the second account it fails.   I even erased the contents of .kube/config in case there was something stale.  Tried enabling and disabling tokens.

you know what - i think it was a capacity issue with us-east-1 - sorry to bother y'all.

Same here
required_providers {
aws        = "3.64.2"
local      = ">= 1.4"
random     = ">= 2.1"
kubernetes = "1.13.4"
external   = "~> 2.1.0"
helm       = "~> 2.4.1"
null       = "~> 3.1.0"
tls        = "~> 3.1.0"
vault      = "~> 3.0.1"
}

I had this same issue with eu-west-2 (London)  - since last Thursday when i deployed the same code, which worked, When I tried it again today, it fails..
I didnt' change any code, but it seems to have been an issue with the terraform state file and resources 👍
When i looked at the AWS EKS console, i saw this

When i clicked the link - it  takes me to https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting_iam.html#security-iam-troubleshoot-cannot-view-nodes-or-workloads
so basically there was no role for the cluster -

I am most definitely new to AWS, EKS & terraform, but I do think I know what the problem is., I ran into the same issue.
Initially the kubernetes cluster I was trying to work on was created by a federated Administrator user.  I further tried to work on this cluster as another user who did have the "Administrator" role, but as per AWS snippet below, but to keep things simple, I have to basically destroy and re-create the cluster as the new user for things to work properly.

When you create an Amazon EKS cluster, the AWS Identity and Access Management (IAM) entity user or role, such as a federated user that creates the cluster, is automatically granted system:masters permissions in the cluster's role-based access control (RBAC) configuration in the Amazon EKS control plane. This IAM entity doesn't appear in any visible configuration, so make sure to keep track of which IAM entity originally created the cluster. To grant additional AWS users or roles the ability to interact with your cluster, you must edit the aws-auth ConfigMap within Kubernetes and create a Kubernetes rolebinding or clusterrolebinding with the name of a group that you specify in the aws-auth ConfigMap.


GQCNN - ROS python2 vs GQCNN python3 conflict

When I try to run the ROS inside a conda python3 environment or the GQCNN while the ROS setup.bash file I experience some problems.
Run GQCNN python package while ROS is sourced
When doing this the /opt/ros/kinetic/lib/python2.7/ interpreter is used instead of my conda interpreter.
Traceback (most recent call last):
  File "examples/policy.py", line 46, in <module>
    from perception import (BinaryImage, CameraIntrinsics, ColorImage, DepthImage,
  File "/opt/conda/envs/tf-gpu/lib/python3.7/site-packages/perception/__init__.py", line 8, in <module>
    from .camera_intrinsics import CameraIntrinsics
  File "/opt/conda/envs/tf-gpu/lib/python3.7/site-packages/perception/camera_intrinsics.py", line 14, in <module>
    from .image import DepthImage, PointCloudImage
  File "/opt/conda/envs/tf-gpu/lib/python3.7/site-packages/perception/image.py", line 11, in <module>
    import cv2
ImportError: /opt/ros/kinetic/lib/python2.7/dist-packages/cv2.so: undefined symbol: PyCObject_Type

Troubleshooting information
Without source
PATH: bash: /opt/conda/envs/tf-gpu/bin:/opt/conda/condabin:/opt/conda/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
PYTHONPATH: ``
With ROS source
PATH:echo $PATH /opt/ros/kinetic/bin:/opt/conda/envs/tf-gpu/bin:/opt/conda/condabin:/opt/conda/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PYTHONPATH:echo $PYTHONPATH /opt/ros/kinetic/lib/python2.7/dist-packages
Solutions

Not sourcing the ROS setup.bash file in the .bashrc. Or

Running unset PYTHONPATH.

Adding your python enviroment site-package folder to the PYTHONPATH enviroment variable.

Cannot import opencv after installing ros kinetic

Build ROS package inside python 3 environment
When trying to do this we get a big number of conflicts since ROS kinetic doesn't fully support python3. A number of posts are explaining the solutions to this issue.

Using ROS with conda
Conda and dealing with conflicting pythons in your system
Conflicts between anaconda and ros
How to run ROS in python3
How to setup ROS with python3
Install guide for ROS-kinetic with python 3.5

Solution
The easy straight forward solution is to remove the conda initiation and the conda environment activation from the .bashrc.
Running rospackage inside conda
Since the gqcnn/grasp_planner node imports python modules that are installed using a setup.py script and ROS is python2.7 I am forced to use the 2.7 version of the GQCNN package.

Closed since problem is not an issue anymore.


for..of on an array??

Here https://github.com/leoasis/redux-immutable-state-invariant/blob/master/src/trackForMutations.js#L45 you're using for..of on Object.keys, which is an array. Why not a normal for loop? The transpiled output would be much cleaner, and would work on browsers and node versions that don't have Symbol.iterator available.

Yeah, I believe you're right. I guess we just need a for .. in in the keys object and we'd get the same behavior.

Using for..in will iterate over the entire prototype, which is not what you want. You should use a for loop over Object.keys(keys), or wrap the for..in body in if (Object.prototype.hasOwnProperty.call(keys, key)) {

Yeah, you're right (again :stuck_out_tongue:), will make that change

That doesn't guard against someone adding enumerable properties to Object.prototype, however. for..in is never safe without a guard.

Ok, makes sense. Will change it to use a regular for with Object.keys(keys) to avoid weird bugs

Actually, a simpler fix would be to just make key = Object.create(null); so that we're sure that it doesn't have anything else besides its own properties

Object.create(null) isn't compatible with ES3 tho, so you'd be breaking anyone that still wants to be IE 8 compatible (like Airbnb). Object.keys is definitely the best way.

Object.keys is also ES5, so if you target ES3 you'll need a polyfill as well.

Totally! But at least that one is faithfully shimmable :-) You can also use the object-keys module if you want to obviate the need for users to polyfill.

Since this is just a dev only tool, I'm not so sure we really need to support ES3, since most development environments use modern browsers. Having said that, I'll use Object.keys since it's more understandable than Object.create(null).


Fixed #95

Running with the below Python and cfg script on aims4, we see that the diags will continue, even though THIS_IS_NOT_A_REAL_VAR isn't a valid variable.
# something.py
reference_data_path = '/p/cscratch/acme/data/obs_for_acme_diags/'
test_data_path = '/p/cscratch/acme/data/test_model_data_for_acme_diags/'
test_name = '20161118.beta0.FC5COSP.ne30_ne30.edison'

backend = 'mpl'

results_dir = 'bad_var_fix'

# something.cfg
[Diags 1]
sets= ["lat_lon"]
case_id= "GPCP_v2.2"
variables=["THIS_IS_NOT_A_REAL_VAR"]
ref_name= "GPCP_v2.2"
reference_name= "GPCP (yrs1979-2014)"
seasons= ["ANN", "DJF", "MAM", "JJA", "SON"]
regions= ["global"]
test_colormap= "WhiteBlueGreenYellowRed.rgb"
reference_colormap= "WhiteBlueGreenYellowRed.rgb"
diff_colormap = "BrBG"
contour_levels = [0.5, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16]
diff_levels = [-5, -4, -3, -2, -1, -0.5, 0.5, 1, 2, 3, 4, 5]

The output is:
(acme_diags_env_maybe_broken) shaheen2@aims4:~$ acme_diags_driver.py -p quickguide-badvar.py -d quickguide-badvar.cfg
Starting to run ACME Diagnostics.
test file: /p/cscratch/acme/data/test_model_data_for_acme_diags/20161118.beta0.FC5COSP.ne30_ne30.edison_ANN_climo.nc
reference file: /p/cscratch/acme/data/obs_for_acme_diags/GPCP_v2.2_ANN_climo.nc
Variable: THIS_IS_NOT_A_REAL_VAR
Error in acme_diags.driver.lat_lon_driver: The variable THIS_IS_NOT_A_REAL_VAR was not in the derived variables dictionary
There was not a single valid diagnostics run, no viewer created

#98 is also fixed. But this is a temporary fix and @chengzhuzhang and I will discuss a more permanent fix (#89) in-person later.
The results of the two parameter files is here
Try the following, but make sure to change the data paths to a path you have access to
# something.py

reference_data_path = '/p/cscratch/acme/data/obs_for_acme_diags/'
test_data_path = '/export/zhang40/temp-zeshawn/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil/climo/0001-0030/'

test_name = '20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil'

backend = 'mpl'

results_dir = 'issue98'  # name of folder where all results will be stored

# something.cfg
[Diags 1]
sets= ["lat_lon"]
case_id= "CERES-EBAF-TOA-v4.0"
variables= ["LWCF"]
ref_name= "ceres_ebaf_toa_v4.0"
reference_name= "CERES-EBAF Jan 2000-Dec 2015"
seasons= ["ANN", "DJF", "MAM", "JJA", "SON"]
contour_levels= [0, 10, 20, 30, 40, 50, 60, 70, 80]
diff_levels= [-35, -30, -25, -20, -15, -10, -5, -2, 2, 5, 10, 15, 20, 25, 30, 35]

Output, notice the line Exception 'PreparedGeometry' object has no attribute 'is_valid' while plotting lat_lon with backend mpl.
(acme_diags_env_maybe_broken) bash-4.1$ acme_diags_driver.py -p temp.py -d temp.cfg
Allow anonymous logging usage to help improve UV-CDAT(you can also set the environment variable UVCDAT_ANONYMOUS_LOG to yes or no)? [yes]/no: no
Starting to run ACME Diagnostics.
test file: /export/zhang40/temp-zeshawn/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil/climo/0001-0030/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil_ANN_000101_003012_climo.nc
reference file: /p/cscratch/acme/data/obs_for_acme_diags/ceres_ebaf_toa_v4.0_ANN_200101_201512_climo.nc
Variable: LWCF
Selected region: global
no domain selector
Plot saved in: /p/cscratch/acme/www/zhang40/issue98/lat_lon/CERES-EBAF-TOA-v4.0/ceres_ebaf_toa_v4.0-LWCF-ANN-global.png
test file: /export/zhang40/temp-zeshawn/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil/climo/0001-0030/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil_DJF_000101_003012_climo.nc
reference file: /p/cscratch/acme/data/obs_for_acme_diags/ceres_ebaf_toa_v4.0_DJF_200101_201512_climo.nc
Variable: LWCF
Selected region: global
no domain selector
Plot saved in: /p/cscratch/acme/www/zhang40/issue98/lat_lon/CERES-EBAF-TOA-v4.0/ceres_ebaf_toa_v4.0-LWCF-DJF-global.png
test file: /export/zhang40/temp-zeshawn/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil/climo/0001-0030/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil_MAM_000103_003005_climo.nc
reference file: /p/cscratch/acme/data/obs_for_acme_diags/ceres_ebaf_toa_v4.0_MAM_200103_201505_climo.nc
Variable: LWCF
Selected region: global
no domain selector
No handlers could be found for logger "shapely.geos"
Exception 'PreparedGeometry' object has no attribute 'is_valid' while plotting lat_lon with backend mpl
test file: /export/zhang40/temp-zeshawn/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil/climo/0001-0030/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil_JJA_000106_003008_climo.nc
reference file: /p/cscratch/acme/data/obs_for_acme_diags/ceres_ebaf_toa_v4.0_JJA_200106_201508_climo.nc
Variable: LWCF
Selected region: global
no domain selector
Plot saved in: /p/cscratch/acme/www/zhang40/issue98/lat_lon/CERES-EBAF-TOA-v4.0/ceres_ebaf_toa_v4.0-LWCF-JJA-global.png
test file: /export/zhang40/temp-zeshawn/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil/climo/0001-0030/20170926.FCT2.A_WCYCL1850S.ne30_oECv3.anvil_SON_000109_003011_climo.nc
reference file: /p/cscratch/acme/data/obs_for_acme_diags/ceres_ebaf_toa_v4.0_SON_200109_201511_climo.nc
Variable: LWCF
Selected region: global
no domain selector
Plot saved in: /p/cscratch/acme/www/zhang40/issue98/lat_lon/CERES-EBAF-TOA-v4.0/ceres_ebaf_toa_v4.0-LWCF-SON-global.png
Viewer HTML generated at /p/cscratch/acme/www/zhang40/issue98/viewer/index.html

@golaz Please let us know if the solution is reasonable. And we will try apply to new simulations (if any) to test.


Make jest runInBand

When pushing to circle, the tests will sometime fail because of running
out of memory. The option runInBand makes jest consume less memory

Closing this as @iksototh mentioned that it belongs in our circleci config, which I agree with.


Refactor the parsing of configuration and credentials files

As mentioned on Discord, I'm currently working on adding an AWS SSO provider for issue #1810. While working on it, I noticed that the way rusoto parses and validates the config and credentials file had a few issues:

We roll out our own INI parsing logic. While this cuts down on dependencies, it also means that we don't necessarily handle all edge cases of the format. It also makes it unnecessarily hard to parse new properties correctly. botocore uses Python's configparser module, so I think it makes sense for us to bring the ini crate for this purpose.
We had two different methods for parsing INI files (parse_config_file and parse_credentials_file), whose behaviors differed in subtle ways (e.g. regarding error handling)
It improperly parses profile names in the credentials file. [profile named_profile] is only valid in the config file, as noted on https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html.

There were a couple more issues with the tests:

I reworked the way we set/unset environment variables to use the guard pattern.
region_from_profile and region_from_profile_missing_profile used the wrong type of file (config instead of credentials) to initialize a ProfileProvider.

I asked this question on Discord, but I didn't get an answer, so I'm asking it again here: Are breaking changes frowned upon at this point in Rusoto's existence? I feel like the current ProfileProvider API isn't ideal and that there are a few method signatures that could be improved. For instance, I think ProfileProvider should be able to be parameterized both with the config and credentials files location (right now it can only be parameterized with the credentials file location). I also think that it should parse both credentials and config files on initialization so it may re-use the results in later method calls. However, this would alter some method's signature to remove a few error cases, and modify the arguments of a couple methods.
For now, I only slightly reworked the wording/messages of some errors. I don't know if that could be considered a breaking change, considering we only have one error type for all credentials-related issues.

Having read https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html and the botocore implementation in more details, it's become clear to me that there remains some large differences between our ProfileProvider implementation and the spec. For instance, we do not support the case when a profile's credentials are not defined in the ~/.aws/credentials file but in the ~/.aws/config file instead, unless the user manually specifies that the provider should look into the config file (something that this PR unintentionally broke!). As such, I think a complete overhaul of the ProfileProvider/credentials crate is necessary, perhaps to align more closely with what botocore is doing (separate "shared credentials" provider and "config" provider). In the meantime, I'll close this PR until I have some time to properly implement this.
Also, since we're already bringing serde in in the credential crate, I think we should use serde_ini instead of the rust-ini I pulled in.

Having read https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html and the botocore implementation in more details, it's become clear to me that there remains some large differences between our ProfileProvider implementation and the spec. For instance, we do not support the case when a profile's credentials are not defined in the ~/.aws/credentials file but in the ~/.aws/config file instead, unless the user manually specifies that the provider should look into the config file (something that this PR unintentionally broke!). As such, I think a complete overhaul of the ProfileProvider/credentials crate is necessary, perhaps to align more closely with what botocore is doing (separate "shared credentials" provider and "config" provider). In the meantime, I'll close this PR until I have some time to properly implement this.
Also, since we're already bringing serde in in the credential crate, I think we should use serde_ini instead of the rust-ini I pulled in.

Also, in order to properly implement an SsoProvider, it would depend on the rusoto_sso::SsoClient type, something that's impossible in the current setup since rusoto_core depends on the rusoto_credential crate, and rusoto_sso depends on rusoto_core, which causes the following cycle:
rusoto_core -> rusoto_credential -> rusoto_sso -> rusoto_core

A proper SsoProvider would either need to:

live in the rusoto_sso crate (simplest), which implies it could not be part of the rusoto_credential chain provider (which it should if it wants to match botocore's functionality)
require big changes to the way we currently generate services

Indeed, if rusoto_core needs to depend on rusoto_credential and rusoto_credential on specific services, the services themselves should not depend on rusoto_core. In the case of rusoto_sso (and I expect all other services), this could be fixed if we moved the following traits and associated data types from rusoto_core to another crate, e.g. rusoto_shared:

rusoto_credential::ProvideAwsCredentials
rusoto_core::region::Region
rusoto_core::request::{BufferedHttpResponse, DispatchSignedRequest}
rusoto_core::client::Client: this would require turning rusoto_core::Client into a trait and parameterize SsoClient with it. No more SsoClient::new() using rusoto_core::Client::shared under the hood, the best we could do is rusoto_sso::SsoClient::<rusoto_core::SharedClient>::new().
rusoto_core::RusotoError

We'd get the following dependency graph:
rusoto_core -> rusoto_shared
            -> rusoto_credential -> rusoto_shared
                                 -> rusoto_sso -> rusoto_shared

Also, in order to properly implement an SsoProvider, it would depend on the rusoto_sso::SsoClient type, something that's impossible in the current setup since rusoto_core depends on the rusoto_credential crate, and rusoto_sso depends on rusoto_core, which causes the following cycle:
rusoto_core -> rusoto_credential -> rusoto_sso -> rusoto_core

A proper SsoProvider would either need to:

live in the rusoto_sso crate (simplest), which implies it could not be part of the rusoto_credential chain provider (which it should if it wants to match botocore's functionality)
require big changes to the way we currently generate services

Indeed, if rusoto_core needs to depend on rusoto_credential and rusoto_credential on specific services, the services themselves should not depend on rusoto_core. In the case of rusoto_sso (and I expect all other services), this could be fixed if we moved the following traits and associated data types from rusoto_core to another crate, e.g. rusoto_shared:

rusoto_credential::ProvideAwsCredentials
rusoto_core::region::Region
rusoto_core::request::{BufferedHttpResponse, DispatchSignedRequest}
rusoto_core::client::Client: this would require turning rusoto_core::Client into a trait and parameterize SsoClient with it. No more SsoClient::new() using rusoto_core::Client::shared under the hood, the best we could do is rusoto_sso::SsoClient::<rusoto_core::SharedClient>::new().
rusoto_core::RusotoError

We'd get the following dependency graph:
rusoto_core -> rusoto_shared
            -> rusoto_credential -> rusoto_shared
                                 -> rusoto_sso -> rusoto_shared

Ah, it looks like we already do something similar to the first option I proposed in rusoto_sts::StsAssumeRoleSessionCredentialsProvider!

Ah, it looks like we already do something similar to the first option I proposed in rusoto_sts::StsAssumeRoleSessionCredentialsProvider!


[r] improve usability of SOMAAxisQuery coords

The following works:
expt <- tiledbsoma::SOMAExperimentOpen(
  "s3://cellxgene-data-public/cell-census/2023-03-16/soma/census_data/mus_musculus",
  tiledbsoma_ctx = tiledbsoma::SOMATileDBContext$new(c("vfs.s3.region" = "us-west-2"))
)
expt_query <- tiledbsoma::SOMAExperimentAxisQuery$new(
  expt, "RNA",
  obs_query = tiledbsoma::SOMAAxisQuery$new(coords = list(soma_joinid = bit64::as.integer64(0:1000)))
)
print(expt_query$n_obs)

But there are a couple pitfalls setting coords in the SOMAAxisQuery:

If we supply coords = list(soma_joinid = 0:1000) (without passing through bit64::as.integer64) then the query successfully returns 0 rows.
If we forget to put the list wrapper, coords = 0:1000 (with/without bit64) then we get a difficult-to-understand error message Error in eval(ei, envir) : Expecting a string vector: [type=NULL; required=STRSXP].  The error message here should be more helpful. (Should we accept a bare vector and interpret it as soma_joinid? Perhaps not, because making the developer write out soma_joinid serves as a reminder it's zero-based.)

A good milestone that it works.  That said:

point 1 is something @aaronwolen and I discussed. If and when we have the schema information and int comes in but int64 is needed then we should just upcast seamlessly.
the list wrapper is a bit of pain too. I presume at least when we only have one dim we can similarly "listify" for the user.  In cases where there are more than dim it is difficult to do without lists.

@eddelbuettel thanks for the quick feedback. Re the list wrapper on point 2 -- expanding on my final parenthetical comment -- indeed my first attempt at this query had simply coords = 1:1000, trying to use one-based indexing as seems natural in R. But then, being forced to write out soma_joinid =  reminded me that the SOMA spec defines that to be zero-based. So there's some small value in requiring the explicit field name. I'm sure the zero vs one-based indexing is going to come up again and lead to a larger discussion / audit. For now I think it suffices to continue erroring out, just with a more-helpful message.

@eddelbuettel On the second aspect, I think rejecting it is fine, but the clarity of the error message is currently an issue -- we should give some indication of what to do instead

I am currently noodling around where we (safely) upcast because I very much dislike how you got 0 points when submitting standard integer (which become nonsensic values when not properly treated).
The trouble is that we don't always have the schema info at hand to assert the column is in fact int64.

Didn't get very far and this seems fairly deep inside @mojaveazure 's territory so I may have to leave this for him.

I have something that works in all our SOMA cases.  It now descends into a possible coords argument, if needed recursively, and "upcasts" any integer arguments it finds from integer to integer64.
Only problem:  It breaks on unit test on data.frame use where we have a (legitimately) 32 bit int dim column, it too gets upcast and then the result breaks.  In this case we wanted to keep integer32.  :disappointed:
I got by that with another toggle: so when coming from SOMADataFrame we do not enforce this upcast, in other cases (which includes the SOMAExperimentQuery we do.   That passes tests.

@mlin I also got the other point -- this now works unnamed.
> library(tiledbsoma)
> uri <- "s3://cellxgene-data-public/cell-census/2023-03-16/soma/census_data/mus_musculus"
> ctx <- tiledbsoma::SOMATileDBContext$new(c("vfs.s3.region" = "us-west-2"))
> expt <- tiledbsoma::SOMAExperimentOpen(uri, tiledbsoma_ctx = ctx)
> qry <- tiledbsoma::SOMAAxisQuery$new(coords = 0:1000)
> expt_query <- tiledbsoma::SOMAExperimentAxisQuery$new(expt, "RNA", obs_query = qry)
> print(expt_query$n_obs)
[1] 1001
>

In essence, I had my life easier by specifying an interface contract of what is here coord coming in a named list, which got (presumably accidentally) relaxed in another code path.  So we now ensure it is a named list, and all is well.

This has been taken care of in #1209 and can be closed.


Add domain resource isolation and network isolation for endpoints

Describe your changes
Added domain resource isolation, by adding optional parameter to sagemaker studio, which if true adds a IAM policy to enforce domain resource isolation on that domain. Also added sagemaker-domain-arn as optional input to multiple modules, to allow the resources created in those modules to be properly tagged to support domain resource isolation.
Added enable_network_isolation as a parameter to sagemaker-endpoint module, defaults to true.
Added enable_network_isolation as a parameter to model-deploy template.
Checklist before requesting a review

[X] I updated CHANGELOG.MD with a description of my changes
[X] If the change was to a module, I ran the code validation script (scripts/validate.sh)
[X] If the change was to a module, I have added thorough tests
[X] If the change was to a module, I have added/updated the module's README.md
[X] If a module was added, I added a reference to the module to the repository's README.md
[X] I verified that my code deploys successfully using seedfarmer apply

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: 2c2cd71bd52ef30530b2b5f96236f5c3d0814ebe
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: 8984d1cfb664ef7c04989b58de2bf1f8ee619404
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: 3ab142a0b9b58725a12f417105cdfbad7cd12ae7
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: c2455a251a87c5adc29b5e9bfd97a492cd0283cd
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: c2455a251a87c5adc29b5e9bfd97a492cd0283cd
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Fix missing ABI when aliased type used in variant

Change Description
Fix #602.
When aliased type (typedef, using) is used as a template argument of variant, its typedef is excluded from json output unexpectedly.
API Changes

[ ] API Changes

Documentation Additions

[ ] Documentation Additions

Can you update this to PR into develop? This will help prevent regressions and then we can back port the fix to the appropriate release.


Page size needs to be passed by query param to get all items catalogue API

Page size needs to be passed by query param in fetching all catalog items API
Why: We need to give the flexibility to airflow to decide on how many records it can fetch from the catalog service
Priority : Low
cc: @NISH1001 @DImuthuUpe @smarru

Re:
This is a low priority.

Working on this to pass the required_number_of_records as a query parameter
PR: https://github.com/NASA-IMPACT/HLS-Transfer-Catalog/pull/28
cc: @DImuthuUpe @smarru

Closing this issue as we implemented this feature and its working as expected.
cc: @DImuthuUpe @freitagb @smarru


DEBUG node doesn't exist yet when the docs mention it's use.

The Docs mention adding a DEBUG node yet the I don't see its existence in my downloaded asset library.
Using Godot version v4.2.2
Also perhaps creating a discord might help or a discussions section.
 Noticed that the node is a node 2d not a debug node. -_-

Yes, you only need to set the name of the node as ”DEBUG”, and you can use a Node2D or any derived node (and Node3D for 3D). For 2D a Sprite2D node would work fine. The purpose of the debug node is to make the points visible so that you can see how your point grid is doing.


copyValueTo fails with numeric type

I need to enter a number and have another field populate with that value as default with the user able to override it, exactly what copyValueTo does for strings, but I need it to work for numeric types.
I would see this as most likely an change required in sfSelect which is not trying to parse into the appropriate format for the field type.
The annoying part is I can't start adding it to my forms in advance as at the moment it errors as below when it sets a numeric field to a string and then fails validation!

Bah, ah well. I'll look into this as soon as i have some time over. If you need it urgently, take a look at https://github.com/Textalk/angular-schema-form/blob/master/src/directives/schema-validate.js#L24 that's where the code it, see if you can see why it would fail.

Thank you so much @Dervisevic, desperate for this functionality, if I knew how to dev on this more than just doing add-ons I'd try to do it myself, but I haven't got time before my holiday next week to get up to speed :(

@Dervisevic I fixed it in my fork https://github.com/Anthropic/angular-schema-form/ I have to leave the office now so I will request the pull later when I am at home.

Awesome!

Hi @Dervisevic I created #253 pull request, I targeted develop branch as the contribution MD specifies.

Perfect @Anthropic, i'll merge it in the morning (or now if you make the changes below) when i get to work, and i'll see when we can get a release out. Thanks so much for reading Contributing.md and targeting development :)
One thing that would really help with the merging is if you could remove the changes to the generated files in dist/ as they can conflict with other contributions and they're generated when a new release is made. This is also in the file but i need to make it more prominent.
Thanks so much for finding a fix!

Damn it, I read that line and forgot, sorry my mother's in hospital so I'm a bit of a mess at the moment.
@Dervisevic I'm a bit new to this, can I change the current pull or do I have to create a new one?

Oh, I'm so sorry to hear about your mother, hope she recovers, once again thank you for the PR merging it now.


Is it somewhere original samples from voices in the webui app?

You can listen to samples from the WebUI, as well as the desktop app here: https://koe.ai/recast/samples/ Please note that we don't provide any of the weights for the models used to create the linked samples for download.


HelmRelease OpenAPI spec doesn't specify merge keys for valuesFrom

Wildly specific title, I know. Very closely related to an issue in Kustomize.
In my use case, I'm following similarly to the multi-tenant example. I have a base HelmRelease, and an overlay HelmRelease with a kustomize.yaml that's doing a strategicMerge on the HelmRelease objects.
Base HelmRelease has a valuesFrom:
kind: HelmRelease
metadata:
  name: mimir
spec:
  releaseName: mimir
  interval: 5m
  chart:
    spec:
      chart: mimir-distributed
      version: 5.0.0
      sourceRef:
        kind: HelmRepository
        namespace: flux-system
        name: mimir
  valuesFrom:
    - kind: ConfigMap
      name: mimir-values

Overlay HelmRelease has a values: and a different valuesFrom:
kind: HelmRelease
metadata:
  name: mimir
  namespace: mimir
spec:
  chart:
    spec:
      version: "5.0.0"
  valuesFrom:
    - kind: Secret
      name: mimir-slack-webhook
      valuesKey: values.yaml
  values:
    alertmanager:
      inhibitRules: []

Due to the Kustomize issue linked above, the end HelmRelease and kustomization.yaml to create it looks like:
namespace: mimir

resources:
  - ../../bases/grafana/mimir

patchesStrategicMerge:
  - flux-helm.yaml

kind: HelmRelease
metadata:
  labels:
    kustomize.toolkit.fluxcd.io/name: mimir
    kustomize.toolkit.fluxcd.io/namespace: flux-system
  name: mimir
  namespace: mimir
spec:
  chart:
    spec:
      chart: mimir-distributed
      sourceRef:
        kind: HelmRepository
        name: mimir
        namespace: flux-system
      version: 5.0.0
  interval: 5m
  releaseName: mimir
  values:
    alertmanager:
      inhibitRules: []
  valuesFrom:
  - kind: Secret
    name: mimir-slack-webhook
    valuesKey: values.yaml

And according to the Kustomize issues from above, the issue relies on having openAPI schemas to properly understand how to merge these values rather than doing a replacement.
Specifically, I believe the HelmRelease object needs some keys similar to:
"x-kubernetes-patch-merge-key": "name",, and "x-kubernetes-patch-strategy": "merge", but I haven't dug enough into the OpenAPI structures to understand what's required to actually merge these lists together.

You can use a json patch to add an item to the list e.g.:
patches:
  - patch: |
      - op: add
        path: '/spec/valuesFrom/-'
        value:
            kind: Secret
            name: mimir-slack-webhook
            valuesKey: values.yaml
    target:
      kind: HelmRelease
      name: mimir

I was trying to avoid multiple patches, I think having both the strategic merge and a json patch makes the whole thing a bit harder to read.
I think doing a strategic merge does introduce some undefined behavior, in where which list item becomes first vs second vs n.
Alright, I think I'll just add the patch and move on.

Strategic merge is problematic especially with HelmReleases because the order of the valuesFrom items matters https://fluxcd.io/flux/components/helm/helmreleases/#values-overrides.
I'm not dismissing the issue with our OpenAPI spec, but adding the merge strategy now would mean a major breaking change. We could cause major problems and even downtime to users that rely on the current replace behaviour. Depending on how the charts are written, merging the array could result in StatefulSets being deleted and who know what other things.

Yeah, and strategic merge doesn't really have a capacity to understand list ordering. Nor does the OpenAPI spec handle the idea of appending or prepending for list merges.
I see your point, and I'm not sure the spec should merge the lists. Ordering is important and I think the strategic merge isn't the path forward with this kind of situation.
I guess then I'll keep the issue open, maybe just to specify on the openAPI to do replace for a strategic merge so it's defined rather than relying on a default kustomize behavior.


can u make a phar pre release please

i need it.

Sorry for not seeing this until now. But you can download the ZIP then go over to http://pmt.mcpe.me and convert it into a PHAR.

@HyGlobalHD You can use the one I made awhile back, it doesn't need to be compiled to PHAR, just download and drop. https://github.com/NebulaLabs/PocketMine-Plugins/blob/master/Scripts/HelpTailor.php