Can't install with pip

$ pip install pyalgotrade-python-3
Collecting pyalgotrade-python-3
  Could not find a version that satisfies the requirement pyalgotrade-python-3 (from versions: )
No matching distribution found for pyalgotrade-python-3

Please do this to use this module:
pip install pyalgotrade
clone or download this pyalgotrade-python-3, copy all the files and folds under pyalgotrade-python-3 to override existing pyalgotrade.
I have updated in the readme as well.


documentation: QAT plugin documentation requires some revisions

Hello, we recently encountered the documentation for the QAT plugin and noticed that it requires some revisions. Within the Modes and Configuration Options section, there is still information present about deprecated parameters. Additionally, the resource allocation information includes details about the /generic resource but lacks information regarding /dc and /cy. Do you have any upcoming plans to update the documentation, or is there any revised documentation that we might not be aware of?

This is the latest we have. The top-level readme has the resources up-to-date. What are the deprecated parameters?

Thanks @mythi  can you point to the top-level readme with the resources information? for deprecated parameter, one for example the -mode parameter, since this is not in CRD, users cannot set it explicitly, so from the advanced config pov, its confusing for users on how to set it along with other params..

"Workload authors" section

for deprecated parameter, one for example the -mode parameter, since this is not in CRD, users cannot set it explicitly, so from the advanced config pov, its confusing for users on how to set it along with other params..

The basic rule for the "sample" CRDs released part of the operator is that it contains all fields so users would already see the available config parameters by looking at the sample. However, I can drop -mode from the table.


Redirect search pages to home when no search query is present

Fixes

Fixes #596 by @obulat
Description

Adds an anonymous middleware to the root /search route so that any search path without a search query paremeter is redirected to the homepage.
Testing Instructions

Visit /search/ and all child routes without a query param and observe homepage redirection. You should not be redirected if there is a search term.
Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

I've added a new e2e test file, @sarayourfriend


Warning message

Please describe the feature that you want to propose
Warning message
"It looks like you have created a new nodeTypes or edgeTypes object. If this wasn't on purpose please define the nodeTypes/edgeTypes outside of the component or memoize them."

you can find the answer in the docs: https://reactflow.dev/docs/guides/troubleshooting/#it-looks-like-you-have-created-a-new-nodetypes-or-edgetypes-object-if-this-wasnt-on-purpose-please-define-the-nodetypesedgetypes-outside-of-the-component-or-memoize-them


Use API-Extractor to document the public API

This PR https://github.com/microsoft/rushstack/pull/1537 might be the last blocker on getting the typescript compiler API working on the site

Seems resolved and look forward to the API 😉


Configure integration tests

This is from #68
It is needed to configure and implement integration tests between:

[ ] David components
[ ] David intern APIs
[ ] David external APIs (like Rasa, IBM Watson and so on)

After a quick research, I'm thinking in use python requests to implement APIs integration tests, like this tutorial:
automated-rest-api-testing-with-python


Weird mouseover behaviour

The video shows the behaviour.
This issue should also include fixing the icon color in dark mode.
https://user-images.githubusercontent.com/901466/186724906-9df6d83e-956e-4d75-b2f3-361abadb54de.mov

This issue should also include fixing the icon color in dark mode.

What does this mean exactly? What is it supposed to look like? Is this the main icon? Or just or hover? Or both?

The icon that is "</>" should be white in dark mode.


Provide a default country dropdown at top right

We may embed a service for identifying based on IP address what country a user is in, in the meantime it would be great to have a dropdown where we could at least select the country of origin and we can save that in a cookie.
For now, would like a selector (perhaps we can remove the Refresh button) which allows them to select their continent? country? @pr3d4t0r @jaryaman @jtdavies ?

@kinabalu Yeah, being able to store the user's country in a cookie would be awesome. Or just the final state the user leaves the selections...


[Bug]: Unable to get through start menu through bg3mm since patch 4

Operating System
Windows 10
BG3 Mod Manager Version
<IP_ADDRESS>
BG3 Game Version
Full Release Patch 4
Bug Summary
This only occurs if i try to run the game through bg3mm, I can run it through steam but i like using mods, I was told it was a bug but wasnt really given any info on how to fix it. Here is a photo if i try to run through bg3mm and if i click to start it crashes

Links
No response

Same! My press any key to continue is also loading strangely and I can’t progress to the second screen without it crashing. 😩

Helloo i got help, i had to check if DirectX 11 was checked. Open bg3mm > settings > preferences and check enable DirectX 11 Mode, Save then try running the game. It fixed the issue for me so i hope it does for yall too <3 if you can see this after i close the issue


System.BadImageFormatException (An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B))

Please see attached Exception details.
I have already did.

Already Exist "Microsoft.Data.Sqlite.dll" , "System.Data.SQLite.dll", "System.Data.SQLite.EF6.dll", "System.Data.SQLite.Linq.dll" in "Bin" folder.

Already Exist "SQLite.Interop.dll" and "sqlite3.dll" in "x64" and "x86" folder.

I am implementing Sqlite with EF in "WCF Application".

Look the attached
web_config.txt

web.config
Please help out. I am stuck in it from 2 days.

This is the EF Core issue tracker, pls use the EF  6 one here: https://github.com/aspnet/EntityFramework6/issues
Have you tried setting the platform target to x86?

Its amazing!!! I have tried so many times but get same exception. But i have tried now. Its get SUCCESS.
👍


Field with gorm:"-" is not set in query

Your issue may already be reported! Please search on the issue track before creating one.
To report a bug, your issue have to include an GORM playground pull request link, for general questions, please delete below line.
GORM Playground Link: https://github.com/go-gorm/playground/pull/6

Hello @efrengarcial
Please refer:
https://github.com/go-gorm/gorm/wiki/GORM-V2-Release-Note-Draft#field-permissions-support-readonly-writeonly-createonly-updateonly-ignored
We have introduced field permission support, supports: readonly, writeonly, createonly, updateonly, ignored
We should use readonly in this case.
type User struct {
  Name string `gorm:"<-:create"` // allow read and create
  Name string `gorm:"<-:update"` // allow read and update
  Name string `gorm:"<-"`        // allow read and write (create and update)
  Name string `gorm:"->:false;<-:create"` // createonly
  Name string `gorm:"->"` // readonly
  Name string `gorm:"-"`  // ignored
}

@jinzhu  The read only fields are created with the migration. Is there any way to use the fields in the queries for aggregated values but ignore them in the migrations without creating a duplicate struct for queries?


MapView.Maker Press Events Not Working

Marker click events are not working for marker press or callout press.
Not working: onPress + onCalloutPress
<MapView.Marker
    ref={ref => {
        this.selectedMarker = ref
    }}
    coordinate={{
        latitude: venue.latitude,
        longitude: venue.longitude,
    }}
    title={venue.name}
    pinColor={'blue'}
    onPress={
        () => console.log('onPress')
    }
    onCalloutPress={
        () => console.log('onCalloutPress')
    }
/>

Package.json
  "dependencies": {
    "react": "15.3.1",
    "react-native": "0.33.0",
    "react-native-maps": "^0.8.2"
  }

Can you supply the full mark up for the way you are rendering <MapView.Marker/>I have had no issues with either marker press or callout press in my project...

I had the same problem, there's a workaround if you create do custom callout  content that contains a <Touchable*> and detect clicks on that.

I had the same problem also. With <Touchable*> it works on iOS, but not on Android?

+1，"onPress" event is not working in my custom callout, when touch custom callout, it just disappeared without calling my "onPress" event.

It seems that in iOS with default pin (no custom marker view) the onPress event is not detected. As far as my test goes, in Android the onPress IS detected with default markers.

I'm having the same issue as described by tpisto.  The onPress event is not detected on iOS with default pin.

I am also having issues with not detecting presses on default pin.
IOS
RN 0.31
maps 0.11

+1
IOS
RN 0.36
maps 0.11

+1
IOS
RN 0.40
maps 0.13

+1
IOS ( default pin onPress does not work )
RN 0.38.1
maps 0.12.1

onCalloutPress works with custom pins on iOS...but the callouts sometimes render underneath other pins....so this is not a solution.
Default pins callout do not render under other pins....but the onCalloutPress doesn't get fired.
It's nice to have this package...be a lot nicer if it worked properly.

+1

In 0.18.3 can't rreproduce


Fresh checkout cannot resolve GameObj

I just made a fresh checkout, then ran:

bin/setup
rake spec

and receive a bunch of errors in the following fashion:
An error occurred while loading ./spec/game/game_spec.rb.
Failure/Error:
  class Hand < GameObj
    Empty   = Hand.new(:empty, :empty, :empty)
    @@store = MemoryStore.new

    def self.fetch(*args)
      @@store.fetch *args
    end

    def self.put(*args)
      @@store.put *args

NameError:
  uninitialized constant GameObj
# ./lib/norn/world/hand.rb:4:in `<top (required)>'
# ./lib/norn/parser/parser.rb:4:in `require'
# ./lib/norn/parser/parser.rb:4:in `block in <top (required)>'
# ./lib/norn/parser/parser.rb:4:in `each'
# ./lib/norn/parser/parser.rb:4:in `<top (required)>'
# ./lib/norn/world/gameobj.rb:1:in `require'
# ./lib/norn/world/gameobj.rb:1:in `<top (required)>'
# ./lib/norn/script/script.rb:3:in `require'
# ./lib/norn/script/script.rb:3:in `block in <top (required)>'
# ./lib/norn/script/script.rb:3:in `each'
# ./lib/norn/script/script.rb:3:in `<top (required)>'
# ./lib/norn/script/exec.rb:2:in `require'
# ./lib/norn/script/exec.rb:2:in `<top (required)>'
# ./lib/norn/game/game.rb:4:in `require'
# ./lib/norn/game/game.rb:4:in `<top (required)>'
# ./lib/norn.rb:5:in `require'
# ./lib/norn.rb:5:in `block in <top (required)>'
# ./lib/norn.rb:5:in `each'
# ./lib/norn.rb:5:in `<top (required)>'
# ./spec/spec_helper.rb:4:in `require'
# ./spec/spec_helper.rb:4:in `<top (required)>'
# ./spec/game/game_spec.rb:3:in `<top (required)>'

from what I can tell, it looks like there's a circular sequence of dependencies, in that GameObj requires the parser, and the parser requires GameObj, but I'm not 100% certain that's the actual issue. I can report that nothing can be loaded safely - even attempting to execute require "norn/world/gameobj" produces errors about GameObj` being uninitialized.

thanks.  this should be fixed now.  though there are likely still failing tests currently.  the Parser is still a bit of a WIP with all the edge cases.

I'm still getting this error with the latest version, even after re-running bin/setup - is there something else I need to do to resolve this? I've also tried running bin/console to test things working without the tests

hmm, travis & appveyor still seem to have issues with it.  Cannot reproduce locally however.

Could there be some earlier version tucked away elsewhere providing these classes? Or some alteration to the ruby path that needs to be done?

ok, try with the newest commit? seems to be fixed on CI.

Works for me now


Limited usage of stories.md file

Rasa Core version:
Python version:
Operating system (windows, osx, ...):
Issue: I am thinking about changing the pattern of rasa. My suggestion is why we have to define all story in stories.md. I mention every action in domain file and based on intent if action is related to template it fill execute utter_intent if action for that intent is customized action it will execute action_intent by itself without defining for which intent which action should be performed in stories.md file but if we need more than one action we will define that only in stories.md file like if previous action is this and then intent is this then next action should be this we don't have to define all the story. Is this possible or there is some corner case?
P.S. action_listen can be define in domain file like utter_intent->action_listen or action_intent-> action_listen or in custom_action(Followup Action) or by any other method to recognize after this action action_listen should be called so it may not create problem.
Content of domain file (if used & relevant):

i'm slightly confused by your suggestion, do you mean that you should be able to assign an intent to a specific action without having to write a story? If this is what you mean, then we actually have a PR open for this: https://github.com/RasaHQ/rasa_core/pull/1701

Yeah, I mean something like this. Didn't see that coming. 😂


No information is given for 2.8.1 hotfix - the "Hotfixes to the Stable Channel" page has nothing

Hi thanks for the lib! When I want to know what is hotfixed for 2.8.1, I follow instruction of https://docs.flutter.dev/development/tools/sdk/releases and https://docs.flutter.dev/development/tools/sdk/release-notes:

Note: For information about bug-fix releases, see Hotfixes to the Stable Channel on the Flutter wiki.

But https://github.com/flutter/flutter/wiki/Hotfixes-to-the-Stable-Channel says nothing about 2.8.1...
I guess someone just forgets to update the wiki ;)

I did the same this morning when I wanted to see what's new :)

Hotfix release notes for stable 2.8.1 are now available at https://github.com/flutter/flutter/wiki/Hotfixes-to-the-Stable-Channel

:tada:

Closing as the wiki is already updated.


match the ts types as IPublicTypeAssetsJson

add version、componentName to match the TS types: IPublicTypeAssetsJson
import { injectAssets } from '@alilc/lowcode-plugin-inject';
import { IPublicTypeAssetsJson } from '@alilc/lowcode-types';
import assets from './assets.json';

await injectAssets(assets as IPublicTypeAssetsJson);

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

CLA麻烦签一下

CLA麻烦签一下

时间有点久了，先关闭，欢迎再次提交


[SIP-58] Proposal to move superset-ui to this repo

[SIP] Proposal to move superset-ui to this repo
Motivation
At the moment, working with superset-ui in order to develop plugins or packages to superset comes with a very bad developer experience.
In case you want to edit or add a plugin, you need to manually link it using npm link, this causes a higher barrier for new developers to the project. Working on multiple packages in superset-ui will need a developer to manually link all the packages.
It's important to note that not all packages and plugins will move back to this repo so we'll still need to use npm link from time to time.
Using lerna in our new monorepo will also ensure that a superset-frontend version will also have the latest versions of all the plugins and packages.
This will also let us align the tech stack between superset-frontend and the packages and plugins used in it.
Proposed Change
The whole superset-ui repo will be transferred to superset-frontend and superset-ui's repo will be archived.
The stack will be the same as the one used in superset-ui, using lerna and yarn workspaces  to manage the monorepo.
The release flow will also be from this repo using github actions as superset-ui works.
superest-frontend will become a package within the new monorepo with "private": true flag, this means that no package will be deployed to npm for that package and the docker image build process will remain as is.
The whole monorepo will have one storybook, it will include all the plugins.
Testing the plugins and packages will remain as it is in superset-ui, using jest. Support for RTL will be added (since it's used in superset-frontend and not in superset-ui.
Regarding storybook, we can take two approaches:

We can keep the superset-ui-demo package where we define all the stories.
We can create a main storybook folder and write each story in it's own plugin. The main storybook will collect all stories from every plugin/package.
We should rethink later on if we want to rename the scope from @superset-ui to @superset or keep it that way.

New folders structure (WIP):

New or Changed Public Interfaces
None. We will use the same package names.
New dependencies
lerna - To manage the monorepo.
This is already being used in superset-ui so I believe licensing isn't an issue here.
Migration Plan and Compatibility
No database migrations.
Rejected Alternatives
The current solution where these packages that are tightly related sit under different repositories create a bad developer experience.
Open issues
At the moment, superset-ui's lerna configuration sets the same version for all packages, this means that the superset-frontend version will be aligned with the plugins and packages versions.
There's also the option to set the versioning as independent but we need to define what's the behavior we'd like to see here :)
Todo List:

[ ] Move the core packages from superset-ui
[ ] Align all tooling between core ui and plugins/packages (ts, babel, jest configs etc.)
[ ] Verify build and publish process works with commands
[ ] Integrate build and publish process to github actions
[ ] Storybook locally should work
[ ] All workflows (Chromatic, storybook) preview deployments should work.
[ ] Move all other plugins, one by one

CC: @amitmiran137 @ktmud @rusackas

Adding some historical context to make sure we made a conscious decision after considering all pros and cons:

The initial discussion on moving packages out of the main repo: https://github.com/apache/superset/issues/5667#issuecomment-415511861
My question about the developer experience on working across multiple repos: https://github.com/apache/superset/pull/8638#issuecomment-587734238
A couple of historical PRs to address the pain raised from npm link and diverging build scripts, etc: #8638 #9326
When we merge superset-ui-plugins to superset-ui: https://github.com/apache-superset/superset-ui/pull/333
When we merge all core superset-ui packages: https://github.com/apache-superset/superset-ui/pull/768

Note in the original proposal to move superset-ui to npm packages, we did consider keeping packages under one monorepo, but the decision at the time was that pros outweighs cons for separate repos.
A question to be answered in this SIP: What has changed? The biggest arguments I can see are that after migrating to separate repos, and starting to use TypeScript, we realized:

Maintaining diverging build configs between repos is not easy.
npm link is often problematic, especially with TypeScript.
The two PRs + waiting for npm release workflow severely hinders developer velocity and it turned out to be larger problem than we thought it to be as number of Superset contributors grow.
There may be other solutions to the cons or the cons were not that important than we original thought.

Ultimately, moving to either direction (monorepo vs separate rpos) is a big tradeoff. By moving to monorepo, we will immediately lose these current benefits (unless more work is spent on making sure relevant tools are properly configured ):

PR preview Storybook via Zeit and Chromatic UI (it's more difficult to request new Github Apps under the apache org, which hosts all other Apache projects, than in apache-superset, which most Superset PMC members have direct admin access).
Reduced build time from smaller codebase and not having to share the GitHub Action runner pool with other Apache projects (Can be mitigated by conditionally triggered workflows)
Automatic NPM release (need to configure NPM_SECRET and the required Workflow)
100% test coverage guarantee for core packages (need to update codecov config)

When we moved to the separated repos, the goal was also to raise code quality bar, increase development velocity, and produce components that can be natively embedded in other applications (therefore the npm packages).
However, as @ktmud mentioned, it has been 2 years since then and many things were changed.

History-1: The quality of the code in apache/(incubator-)superset was not great. Some parts were well tested. Some not. Lints were enabled only for certain parts. superset-ui was created to be stricter: requiring 100% test coverage and TypeScript. We rewrote many core parts including massive clean up of all charts, then replaced legacy code in the main repo with these newer components.
Current: 🟢  Main repo has more TypeScript + lints and overall code quality has improved.

History-2: CI jobs in apache/(incubator-)superset took long time to run and was not stable (flaky tests and master often had issues at that time).
Current: 🟢  CI and master are more stable these days. 🟡 The jobs still take time to run. Probably can mitigate by skipping the unnecessary ones.

History-3: Better tooling and flexibility. We experimented and adopted bots, conventional commits, PR previews (Netlify then later Zeit/Vercel), semi-automatic npm packages release via github actions. These are difficult to experiment and configure on repos under apache org which we don't have admin rights.
Current: 🔴  We still don't have admin rights on apache/superset and some apps are not allowed.

History-4: There were needs to embedding charts in other apps. Plugins system and publishing the packages on npm was for this.
Current: 🟢  Embeddable chart is less of a focus now.

History-5: Some legacy chart plugins were added by community and caused maintenance problems for committers over time. The plugins system and publishing the packages on npm hoped to decentralize this a bit. Each org/person can have repo of their custom plugins with repo structure forked from superset-ui-plugins.
Current: 🟡  Can still have boilerplate of standalone plugin repo for 3rd party who wants to create plugin, but it will still have issues: keep build config in sync and npm link. If the main developers are no longer dogfooding this approach, it is likely to be broken after a while.
Or we could change the process for creating custom plugins to (1) fork apache/superset (2) dev on that and (3) only publish the flagged plugins. However, the forked repo can be heavy and need to keep all parts to be able to rebase from upstream.

So it seems things have changed in favorable direction.
I agree with the observations @ktmud 's 1-4 above that the workflow has caused new issues with more contributors joining the project. The key questions to be addressed before merging back are also good and I want to add a bit more on top of that.

Topic
Things to consider before proceeding

Repo tools: PR preview Storybook via Zeit and Chromatic UI (it's more difficult to request new Github Apps under the apache org, which hosts all other Apache projects, than in apache-superset, which most Superset PMC members have direct admin access).
Do some feasibility study. Check with Apache admin to know what are allowed. Are there workaround and are we OK losing some if not allowed? Better avoid surprises.

Reduced build time from smaller codebase and not having to share the GitHub Action runner pool with other Apache projects (Can be mitigated by conditionally triggered workflows)
Make sure we won't save time from npm link (fix cost) only to spend more time staring at CI instead (recurring).

Revise automatic NPM release
Should be able to set NPM_SECRET via JIRA to Apache admins, but have to change publishing flow. Currently, releases are triggered by committers committing a PR that bumps version in package.json and CI took care of the rest. Direct git push to master is not allowed in apache/superset

Figure out npm packages release cadence: How often will the plugins be published?
Currently it is being forced because the main app refer to plugins via package and version in package.json. (1) If the npm publishing is still a requirement, you still need 2-3 PRs in apache/superset. One PR up to the point where plugin is completed. Potentially another PR to bump version and force npm publishing. Another PR is to update package version in superset-frontend after new packages have been published. (2) The 2-3 PRs process sounds tedious. After moving to the same repo, one might be interested in pointing to plugin src directly and bypass the npm publishing at all. This could leave the npm packages outdated and someone has to publish at one point, when will that be? This is not a problem for the main app, but 3rd party chart plugin dev may be using outdated @superset-ui/xxx. For apps wanting to embed charts, I am less concern on that front due to decreased interest.

Maintain quality bar: 100% test coverage guarantee for core packages (need to update codecov config)
Sounds straightforward.

3rd party chart plugins: How would someone develop chart plugins that are only useful for his/her org (without dropping code in apache/superset)?
Worth spend sometimes thinking how to provide flexibility while avoid accumulating maintenance cost for apache/superset. Refers to the comment above about History-5.

A few additional points building on all the helpful background/issues from @ktmud and @kristw:

SIP-57, in favor of Semantic Versioning, is still in the VOTE process. This should be considered here. The current NPM publishing scripts bump ALL touched packages in parallel. We may need to pay more attention to semantically bumping the version numbers of individual plugins, or establishing some process to make sure that ALL plugins are bumped to the highest/safest level (i.e. a breaking change on one package means they all get a major number bump).
I really prefer the idea of using the src path for packages, rather than having to jump through the hoops of publishing/bumping packages internally in Superset. Removal of this overhead is the main motivation for the homecoming, in my opinion. We should indeed address the cadence of when we publish new plugin versions. My off-the-cuff suggestion would be to make it part of the Superset OSS release procedure, so they're in tighter lock-step. We could even consider aligning version numbers between Superset and the internal packages.
Regarding the viz plugins, we would still need to keep some of them external, on superset-ui. One motivation to externalize them was around the licensing of dependencies being incompatible with Apache. I believe this is likely to remain the case, so only the "safe" ones can come home. We'll need to support npm link, Storybook, release actions, etc on superset-ui to support those remaining packages.

I think it would be nice if the superset-ui npm packages would be synced with the official release versions; when a new Superset version is released, the all superset-ui packages would be released with the same version on npm. If we stay true to semantic versioning (the SIP has now passed), people would know that if their external applications is using e.g. v. 1.1.0 of superset-ui, it will be compatible with a backend running 1.5.0.

SIP-57, in favor of Semantic Versioning, is still in the VOTE process. This should be considered here. The current NPM publishing scripts bump ALL touched packages in parallel. We may need to pay more attention to semantically bumping the version numbers of individual plugins, or establishing some process to make sure that ALL plugins are bumped to the highest/safest level (i.e. a breaking change on one package means they all get a major number bump).
I really prefer the idea of using the src path for packages, rather than having to jump through the hoops of publishing/bumping packages internally in Superset. Removal of this overhead is the main motivation for the homecoming, in my opinion. We should indeed address the cadence of when we publish new plugin versions. My off-the-cuff suggestion would be to make it part of the Superset OSS release procedure, so they're in tighter lock-step. We could even consider aligning version numbers between Superset and the internal packages.
Regarding the viz plugins, we would still need to keep some of them external, on superset-ui. One motivation to externalize them was around the licensing of dependencies being incompatible with Apache. I believe this is likely to remain the case, so only the "safe" ones can come home. We'll need to support npm link, Storybook, release actions, etc on superset-ui to support those remaining packages.

Thanks everyone for all the helpful inputs!
@rusackas

IMO we should use lerna independent versioning, I don't think that a breaking change in one plugin should cause a major version bump in another version.
If we decide to align the version numbers we'll get a problem with semantic versioning and major version bumps you raised on the first point wouldn't we?
That's a good point. Is there a list of the plugins/packages we can move based on the license? Since I couldn't find any licensing on the plugins, just on the whole superset-ui repo.

I think it would be nice if the superset-ui npm packages would be synced with the official release versions; when a new Superset version is released, the all superset-ui packages would be released with the same version on npm. If we stay true to semantic versioning (the SIP has now passed), people would know that if their external applications is using e.g. v. 1.1.0 of superset-ui, it will be compatible with a backend running 1.5.0.

@villebro I do agree that it can be nice, but I'm not sure it is really helpful. This means that whenever you want to release a patch to a plugin you'll also bump all the packages and the superset-ui core module, sounds redundant to me but I'm not familiar with the whole release mechanism so I might be missing some stuff.
@kristw thanks for the helpful inputs!

History-1: The quality of the code in apache/(incubator-)superset was not great. Some parts were well tested. Some not. Lints were enabled only for certain parts. superset-ui was created to be stricter: requiring 100% test coverage and TypeScript. We rewrote many core parts including massive clean up of all charts, then replaced legacy code in the main repo with these newer components.
Current: 🟢 Main repo has more TypeScript + lints and overall code quality has improved.

I believe the issue we have now is the opposite one.. superset-ui doesn't have tests almost at all. The coverage configs are all on 0.

History-3: Better tooling and flexibility. We experimented and adopted bots, conventional commits, PR previews (Netlify then later Zeit/Vercel), semi-automatic npm packages release via github actions. These are difficult to experiment and configure on repos under apache org which we don't have admin rights.
Current: 🔴 We still don't have admin rights on apache/superset and some apps are not allowed.

That's an important one, the question is, is that a blocker?

History-5: Some legacy chart plugins were added by community and caused maintenance problems for committers over time. The plugins system and publishing the packages on npm hoped to decentralize this a bit. Each org/person can have repo of their custom plugins with repo structure forked from superset-ui-plugins.
Current: 🟡 Can still have boilerplate of standalone plugin repo for 3rd party who wants to create plugin, but it will still have issues: keep build config in sync and npm link. If the main developers are no longer dogfooding this approach, it will likely be broken after a while.

I think we should still maintain that approach, having developers create PR's on the main repo might be a serious bottleneck.
As long as there are still plugins left outside on superset-ui due to licensing I guess we'll keep maintaining it, but even after, we need to maintain a doc page explaining how to do it and also not to break that mechanism.
Regrading the open issues:

Repo tools: PR preview Storybook via Zeit and Chromatic UI - Who can check with Apache admins what are we allowed to do?
Reduced build time from smaller codebase and not having to share the GitHub Action runner pool with other Apache projects - I'll work on this one as part of this SIP.
Revise automatic NPM release - We need to talk about this one since IMO we need to define a way to publish plugins which is unrelated to the main repo. Also, since the FE will be a part of the lerna monorepo, we should know that a new version will be released once it has changes (though we might not rebuild the docker image of-course).
Figure out npm packages release cadence: How often will the plugins be published? - IMO this should be automatic even if we decide to use the src folder instead of the npm package. Every change will be released using lerna and github actions.
Maintain quality bar e.g. 100% test coverage guarantee for core packages - As I stated before, the current status of superset-ui isn't as good as we thought it is..
3rd party chart plugins: How would someone develop chart plugins that are only useful for his/her org (without dropping code in apache/superset)? - This doesn't sound like something which should be coupled to this SIP but I do agree that we need to think about it. At the moment, one already needs to edit code in superset to add plugins. We might need to figure out a way to extend the plugins without editing any code.

Thanks everyone for the valuable inputs! I'm starting to work on this one but I think we should setup some milestones we want to see. I'll try to update the PR and SIP with specific milestones.

I believe the issue we have now is the opposite one.. superset-ui doesn't have tests almost at all. The coverage configs are all on 0.

This is not true. superset-ui core packages (@superset-ui/core and @superset-ui/chart-controls) do enforce 100% test coverage at least on non TSX/JSX files (the goal for TSX/JSX  is 50%).

I believe the issue we have now is the opposite one.. superset-ui doesn't have tests almost at all. The coverage configs are all on 0.

This is not true. superset-ui core packages (@superset-ui/core and @superset-ui/chart-controls) do enforce 100% test coverage at least on non TSX/JSX files (the goal for TSX/JSX is 50%).

That's my bad, sorry. I was looking at this inside the jest configs.

Thanks so much for the comprehensive post and keeping this SIP alive!

I think it would be nice if the superset-ui npm packages would be synced with the official release versions; when a new Superset version is released, the all superset-ui packages would be released with the same version on npm. If we stay true to semantic versioning (the SIP has now passed), people would know that if their external applications is using e.g. v. 1.1.0 of superset-ui, it will be compatible with a backend running 1.5.0.

@villebro I do agree that it can be nice, but I'm not sure it is really helpful. This means that whenever you want to release a patch to a plugin you'll also bump all the packages and the superset-ui core module, sounds redundant to me but I'm not familiar with the whole release mechanism so I might be missing some stuff.

One consequence of moving superset-ui to the apache/superset repo is we're going to be effectively changing the ownership of the code to the Apache Software Foundation (ASF). That in itself isn't a problem, but the ASF is very strict about the protocol surrounding releases and publishing code from an ASF repo. In practice we won't be able to do non-ASF sanctioned releases of the superset-ui packages without going through the full ASF voting process, which requires 72 h voting time and sign-off from a minimum of 3 PMC members (there's some lenience wrt to latest builds from master). In practice this means that anything we release to npm will need to go through the normal voting process. There's no problem with doing different product releases under the Superset umbrella, even following different version numbers (=we could do superset-ui releases separately from apache/superset), but they'll still need to go through the regular voting flow before being published.

Shall we put this up for a VOTE @MatanBobi ?

Just updating here as I'll probably start working on it this week.
After consulting with @amitmiran137 and @rusackas, we'll probably start with building the monorepo approach and only move the core package. Then, we'll start moving the plugins one by one.

Hi all,
after carefully considering all points brought up in this discussion, we have done some prerequisite work required by the monorepo effort to more closely align the superset-ui repo with the main Superset repo. Some notable PRs:

Add license headers to all files on superset-ui: https://github.com/apache-superset/superset-ui/pull/1444
Migrate superset-ui from yarn to npm as per SIP-14: https://github.com/apache-superset/superset-ui/pull/1405
Upgrade superset-ui Storybook to version 6 to match the version used on apache/superset: https://github.com/apache-superset/superset-ui/pull/1409

Based on initial testing, both repos should now be in a state that should make the monorepo transition possible. In the following doc we summarize some of the key motivations for migrating the superset-ui code to the main Superset repo, consider pros/cons of the various alternatives proposed in this SIP and present a proposed solution for performing the migration:
Spike_-_Superset_Monorepo.pdf
A vote for the SIP will be initiated shortly.

Out of interest @villebro what are the plans for the other repos in the https://github.com/apache-superset organization?

@john-bodley that's a good question, and TBH I haven't thought that far ahead yet. IMO apache-superset can be thought of as a kind of incubator org for stuff that's loosely related to the main repo, but not necessarily ready for inclusion in the main repo just yet/ever. For instance, the cherrytree repo is used to make the release process easier, but doesn't necessarily need to be a part of the main repo as it can just as easily be used to bake releases for any other GitHub project. So I think the org may well be good to have around even in the future, but we should probably consider at least archiving the ones that are no longer relevant, as many of them don't appear to be relevant anymore.

With the majority of this work done, this SIP can now be considered done, hence closing.


Mouse cursor

Provide a way of changing the mouse counter

http://stackoverflow.com/questions/4564251/change-the-mouse-pointer-using-javascript
http://stackoverflow.com/questions/17414034/change-mouse-cursor-in-javascript-or-jquery

cursor :: Text -> Canvas ()

Added in e1f48414bbf2b72edfe31eb3b508cdf6fde4bf9a.


Updating azure-communication-common version to 1.2.1 for new release.

Updating the azure-communication-common release to 1.2.1.

API change check
API changes are not detected in this pull request.

Looks like this PR will no longer be required after an offline discussion between the ACS and the Azure SDK for Java teams. Instead, we will release a beta version (1.3.0-beta.1) that includes the ACS Room library in its module-info.java file. ACS Rooms will then take care on said version of the library.


bug in discrete-bezier-curve

There is a bug in defun discrete-bezier-curve.
Sometimes it calls (atan 0.0 0.0), spec [1] specifies that:

If both are supplied, number2 can be zero provided number1 is not zero.
The problem is fixed using a safe version of atan:

 (safe-atan (x y)
	     (if (and (= x 0) (= y 0))
		 0
		 (atan x y)))

I'm not sure if "0" is the correct answer.
Regards,
Alessandro
[1] http://clhs.lisp.se/Body/f_asin_.htm

The problem is that two consecutive points must be disjoint.
Actually there should be no attempt to compute atan in the first place for these points.
The correct solution, I think, is to either filter out these points (either at the user responsibility, and maybe here in the code as a first pass before subdividing) or simply to reject such paths.
However, this could also happen because of the subdivision itself, but it would surprise me in this case.
(Sorry for the late reply.)


Please add a TriviaPiece.commentValue property

Description
There are four kinds of comment tracked by TriviaPiece. It'd be a nice convenience to be able to extract the string values of those comments. May I suggest something like:
extension TriviaPiece {
  public var commentValue: String? { get }
}

Tracked in Apple’s issue tracker as rdar://111922531

Well, the latter case gets hard for multi-line comments. What's the content of:
/**
 * Hello, folks!
 * I am a banana!
 */

I think just returning the string verbatim is fine—anybody who cares about processing it can do so. Or, if it is easy enough, you could provide rawCommentValue and commentValue, the latter doing the processing?

I think stripping off the /// makes sense because if you wanted to get the entire text of the TriviaPiece you could do Trivia(pieces: [piece]).description (and we could even add description to TriviaPiece but I’m not sure if that’s super useful).
Now the question is: What should we do with the space after ///? My proposal is the following: We implement commentValue on Trivia instead of TriviaPiece. What it will do is the following: Check if all line comments have a space right after // or ///. If that’s the case, also remove that space from the commentValue. If not, we only remove the // or ///.
We could do the same for block comments and use the same logic whether to remove a space after /* or before */.

I think stripping off the /// makes sense because if you wanted to get the entire text of the TriviaPiece you could do Trivia(pieces: [piece]).description (and we could even add description to TriviaPiece but I’m not sure if that’s super useful).
Now the question is: What should we do with the space after ///? My proposal is the following: We implement commentValue on Trivia instead of TriviaPiece. What it will do is the following: Check if all line comments have a space right after // or ///. If that’s the case, also remove that space from the commentValue. If not, we only remove the // or ///.
We could do the same for block comments and use the same logic whether to remove a space after /* or before */.

Sounds good to me. I had the same idea in mind.
I can try implement it 🤗

I think stripping off the /// makes sense because if you wanted to get the entire text of the TriviaPiece you could do Trivia(pieces: [piece]).description (and we could even add description to TriviaPiece but I’m not sure if that’s super useful).
Now the question is: What should we do with the space after ///? My proposal is the following: We implement commentValue on Trivia instead of TriviaPiece. What it will do is the following: Check if all line comments have a space right after // or ///. If that’s the case, also remove that space from the commentValue. If not, we only remove the // or ///.
We could do the same for block comments and use the same logic whether to remove a space after /* or before */.

One more edge case jumped into my mind. Do we care about multi comments in one Trivia?
What do wanna achieve for such a case:
SwiftSyntax.Trivia(
  pieces: [
    .docLineComment("/// docLineComment_1.1"),
    .docLineComment("/// docLineComment_1.2"),
    .newlines(2),
    .docBlockComment("""
    /**
      docBlockComment_1.1
      docBlockComment_1.2
    /*
    """),
    .docLineComment("/// docLineComment_2.1"),
    .docLineComment("/// docLineComment_2.2"),
  ]
)

Well, I expect these properties to be on TriviaPiece, not Trivia, so each piece has its own comment value. I'm explicitly asking for a convenience on TriviaPiece here because it has four cases that carry equivalent data. I don't think it's necessary to overdesign a solution.

We could have the convenience property on TriviaPiece, and then something "smarter" on Trivia that does the sort of work you're describing.

FWIW, I just implemented logic in swift-format that tries to mimic what the compiler's Markup component does to extract doc comments from Trivia, which includes handling multiple adjacent pieces and stripping leading * off block comment lines: https://github.com/apple/swift-format/blob/main/Sources/SwiftFormatCore/DocumentationCommentText.swift
swift-syntax would be a better home for this, especially since I imagine it'll happen eventually anyway as more of the compiler gets moved from C++ to Swift.

Hi all, is this issue still up for grabs? 👨🏻💻
@allevato sounds like you’ve done some great work with Swift format related to this. Do you have plans to bring it in to this issue? Or am I good to look at this?

Hi all, is this issue still up for grabs? 👨🏻💻

Yes, it is.

@allevato sounds like you’ve done some great work with Swift format related to this. Do you have plans to bring it in to this issue? Or am I good to look at this?

I personally don't have the cycles right now, but if you are interested in using the DocumentationCommentText logic in swift-format as a starting point to provide this in swift-syntax, I'd be supportive of it.

Thanks both!
@ahoppen Are you able to assign me please?

Hi all, I'm looking at this issue now and got a nice basic implementation working but would love some input on a particular use case.
For the source code below, what would you expect the output to be of trivia.commentValues?
/*
 * Hello, folks!
 * // Apples and oranges
 * I am a banana!
 */

I have an idea of what I'd expect (and have implemented it that way at the moment) but would be good to get other's opinions before I move further.
(Equally this would apply for doc comment blocks containing a doc comment line too or a variant of the two)
Option A 🍎
["Hello, folks! Apples and oranges I am a banana!"]

Option B 🍌
["Hello, folks! // Apples and oranges I am a banana!"]

Option C 🥕
["Hello, folks!", "Apples and oranges", "I am a banana!"]

Option D 🍊
["Hello, folks! I am a banana!", "Apples and oranges"]

Option E 🤔
Or something else entirely?

I would expect either ["Hello, folks!", "// Apples and oranges", "I am a banana!"] or "Hello, folks!\n// Apples and oranges\nI am a banana!", depending on whether you're returning an array of lines or a newline-delimited string. The prefix that gets stripped off the comment would be determined solely by the opening delimited of the comment and you wouldn't attempt to process other things that look like comments inside of one.

you wouldn't attempt to process other things that look like comments inside of one

Agreed! I'd expect option B from the examples above if I were to access that value so I'll go down that path. Thanks!


[Hub Generated] Review request for Microsoft.ResourceHealth to add version stable/2022-10-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM API Information (Control Plane)
Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

/azp run unifiedPipeline

SigningOff from ARM side as checked that comments from previous ARM API Reviewer are resolved. There is one Linter issue which needs to be resolved (fixed/suppressed).

@abhayohri, the config for dotnet sdk is not correct, could you please update it by following https://github.com/Azure/azure-rest-api-specs/blob/main/documentation/samplefiles/readme.csharp.md
@MaryGao  @tadelesh,  could you take a look at the SDK breaking in this PR, thanks

Please follow on Renhe's comment.
I will skip LintDiff on this single error, as suppression seems not able to work, before merge.

The suppression doesn't seem to work but it should not be a blocker for this PR.

Approved JS breaking since it is not introduced by this pr.


ObjectTranslations do not add the Object file when fields are changed

Describe the bug
When changing ObjectTranslations for a specific field, the object xml is also required to be added in order to deploy. After creating a Diff using sfdx sfpowerkit:project:diff the output folder has the modified field but not the object.
To Reproduce
Modify ObjectTranslation Field value
Commit changes
Run sfdx sfpowerkit:project:diff  with relevant commit ids
Review extracted files

sfdx sfpowerkit::

Expected behavior
When extracting a delta with an ObjectTranslation field, the object xml should come with it.
Screenshots
`2021-01-14T14:51:28.6645088Z ##[section]Starting: Validate and Test
2021-01-14T14:51:28.6651618Z ==============================================================================
2021-01-14T14:51:28.6652021Z Task         : Deploy a Source Directory (Source Format) to an Org
2021-01-14T14:51:28.6652397Z Description  : Deploy a directory in source format to any org using metadata api, This task is part of sfpowerscripts
2021-01-14T14:51:28.6652714Z Version      : 10.0.8
2021-01-14T14:51:28.6652924Z Author<EMAIL_ADDRESS>2021-01-14T14:51:28.6653285Z Help         : Deploy a  directory or a subdirectory (the root should be  mentioned in sfdx-project.json to an org using metadata api
2021-01-14T14:51:28.6653897Z ==============================================================================
2021-01-14T14:51:28.8943850Z sfpowerscripts... Deploy Source to Org
2021-01-14T14:51:28.9087055Z Converting source to mdapi
2021-01-14T14:51:28.9093700Z Converting to MDAPI Format force-app in project directory src_delta
2021-01-14T14:51:31.0588472Z ERROR running force:source:convert:  Expected metadata file with '-meta.xml' extension at path: /home/vsts/work/1/s/src_delta/force-app/main/default/objectTranslations/Activity-cs/Activity-cs.objectTranslation-meta.xml
2021-01-14T14:51:31.0593138Z Unable to convert source for directory force-app
2021-01-14T14:51:31.0640007Z ##[error]Command failed: npx sfdx force:source:convert -r force-app  -d nqjOn_mdapi
ERROR running force:source:convert:  Expected metadata file with '-meta.xml' extension at path: /home/vsts/work/1/s/src_delta/force-app/main/default/objectTranslations/Activity-cs/Activity-cs.objectTranslation-meta.xml
2021-01-14T14:51:31.0706085Z ##[section]Finishing: Validate and Test`
Desktop (please complete the following information):

OS: Ubuntu 18 & Windows 10
Node Version: Unsure of server, but locally 14
Version of sfpowerkit: Latest
Salesforce Org Version Spring 21, but was present in previous release also.

Additional context
Add any other context about the problem here.

@manisfdcsfdx can you have a look into this one?

@manisfdcsfdx can you have a look into this one?

I believe i found the issue here - https://github.com/Accenture/sfpowerkit/blob/5841be24f3e9c8ecbc8b9f4ebdc7a5cef04b47fc/src/impl/project/diff/diffUtil.ts#L97
changing  to
if (file.path === filePath || file.path.endsWith(objectTranslation)) {
seems to work. objectTranslation is not the whole path just the end, while file.path is the whole path.

I believe i found the issue here - https://github.com/Accenture/sfpowerkit/blob/5841be24f3e9c8ecbc8b9f4ebdc7a5cef04b47fc/src/impl/project/diff/diffUtil.ts#L97
changing  to
if (file.path === filePath || file.path.endsWith(objectTranslation)) {
seems to work. objectTranslation is not the whole path just the end, while file.path is the whole path.

Sure am looking at it.

Sure am looking at it.


Module version maintenance

Motivation
Regular maintenance of module versions should be carried out.
Acceptance criteria
To ensure that there are no conflicts, the following tasks must be carried out for each module:

Check the latest official version and possible conflicting changes in the changelog.
Check the good functioning of the module with the updated version.
Merge the PR of each module by triggering the release-please workflow with feat!

Review & update

[ ] aws-eks
[ ] aws-oidc
[ ] aws-parameter-store
[ ] aws-sso
[ ] azuread-group
[ ] azure-aks
[ ] azure-flexible-server-postgresql
[ ] azure-kv
[ ] azure-oidc
[ ] azure-resource-group
[ ] azure-vnet-and-subnet
[ ] azure-vnet-peering

For update aws-eks:

https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/docs/UPGRADE-19.0.md
https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/docs/UPGRADE-20.0.md


[R1] Add login page features

Summary of PR
Implemented the R1 Login features that were not already in boilerplate code from CI-Python Template
Created methods that ensure that:

Email field or password field cannot be empty
Email must follow RFC 5322 format
Password must meet minimum complexity (at least 6 letters, one special char, one uppercase, one lowercase)

Looks like the build is failing on the regex on that one line of code. Let me look into that. Lmk if you have any ideas how to resolve it!

Regex isn't my strong suit, but you could probably use this one I found online:
([!#-'*+/-9=?A-Z^-~-]+(\.[!#-'*+/-9=?A-Z^-~-]+)*|"([]!#-[^-~ \t]|(\\[\t -~]))+")@([!#-'*+/-9=?A-Z^-~-]+(\.[!#-'*+/-9=?A-Z^-~-]+)*|\[[\t -Z^-~]*])
It seems to be the 'official' one.

The test case which is failing is due to the introduction of the check on e-mail formatting that you've introduced. There's a default test case that uses a wrongly formatted e-mail in the integration registration tests, which is why this is happening.
I have already solved this issue in my PR, both in the test case as well as in the register and login, with the correct expression. Just remove these changes from your PR and we should be good to merge without conflicts.

Okay thank you. I've removed the email format checks (email is empty or email format does not meet RFC 5322) since @Chumingsun already did it in his PR. The new summary of this PR is that I added features ensuring:

Password meets complexity requirements
Password field is not empty

Build now passes! Looks good to merge now to me.

Just did a quick fix on the check_valid_password function. Added a check for char.isalnum() before seeing if it's char.isupper() or char.islower()
This avoids a situation where we check for upper/lowercase on a special character, and getting an error
The rest of the file is the same as last commit


data display

Hi @oeway,
it seems that some data are again not showing up on the platform, like images of mitochondria. Only two pages of data can be seen, when just yesterday we had four. It looks like there have been some issues again with the CI script, no ?
Ch

please ignore the above comment - the issue seems to be resolved now. Ch


trainable doesn't work correctly

x = Input(shape=(32,))
layer1 = Dense(32)
layer2 = Dense(32)
y = layer2(layer1(x))
model_1 = Model(x, y)
layer1.trainable = True
layer2.trainable = False
model_1.compile(optimizer='rmsprop', loss='mse')
model_2 = Model(x, y)
layer1.trainable = False
layer2.trainable = True
model_2.compile(optimizer='rmsprop', loss='mse')
model_3 = Model(x,y)
layer1.trainable = True
layer2.trainable = True
model_3.compile(optimizer='rmsprop', loss='mse')

model_1.summary()
model_2.summary()
model_3.summary()

After compiling model_3, model_1 and model_2 get wrong total number of parameters:
model 1 summary:
_________________________________________________________________
Layer (type)                 Output Shape              Param #
=================================================================
input_15 (InputLayer)        (None, 32)                0
_________________________________________________________________
dense_26 (Dense)             (None, 32)                1056
_________________________________________________________________
dense_27 (Dense)             (None, 32)                1056
=================================================================
Total params: 1,056
Trainable params: 1,056
Non-trainable params: 0
_________________________________________________________________
model 2 summary:
_________________________________________________________________
Layer (type)                 Output Shape              Param #
=================================================================
input_15 (InputLayer)        (None, 32)                0
_________________________________________________________________
dense_26 (Dense)             (None, 32)                1056
_________________________________________________________________
dense_27 (Dense)             (None, 32)                1056
=================================================================
Total params: 1,056
Trainable params: 1,056
Non-trainable params: 0
_________________________________________________________________
model 3 summary:
_________________________________________________________________
Layer (type)                 Output Shape              Param #
/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/keras/engine/training.py:478: UserWarning: Discrepancy between trainable weights and collected trainable weights, did you set `model.trainable` without calling `model.compile` after ?
  'Discrepancy between trainable weights and collected trainable'
=================================================================
input_15 (InputLayer)        (None, 32)                0
_________________________________________________________________
dense_26 (Dense)             (None, 32)                1056
_________________________________________________________________
dense_27 (Dense)             (None, 32)                1056
=================================================================
Total params: 2,112
Trainable params: 2,112
Non-trainable params: 0
_________________________________________________________________

@rnorm When you modify layer.trainable, you should call model.compile again to make it take effect, and then it should work well.

@yanboliang thanks.
I want to build up 3 models with shared layers.
In model 1, layer 1 is trainable and layer 2 is not.
In model 2, layer 2 is trainable and layer 1 is not.
In model 3, both are trainable.
That is why after modifying the trainable property I only compile one model.
So if I understand your suggestion correctly, the shared layer in different models have to have the same trainable property, i.e., all true or all false?

Yep.

@yanboliang if so, could you recommend some solution for what I'm trying to do?

I don't understand you scenarios very clearly. In model 1, layer 2 is non-trainable(never be updated), and in model 2, layer 2 is trainable(will be updated), then how they can share variables/parameters?
Usually we freeze(set layer as non-trainable) a layers in the context of fine-tuning a model, or using fixed embeddings for a text input. Then you should finished training a model, and then change some layers to non-trainable in the model, and train the updated model on new dataset.

@yanboliang Here is a hypothetical example:
I have one network with two layers, but for some reasons, I don't want to optimize the entire model directly. Instead, I want to train the two layers separately. Specifically, in a for loop - train layer 1 while fixing layer 2, and then train layer 2 while fixing layer 1. To do that, I build up two models - model 1 and model 2 sharing the same architecture and the same weights. Then in a for loop, I want to train model 1 while freezing its second layer and then train model 2 while freezing its first layer.

@yanboliang but I need to put that into a for loop and train with batch. As a result, in each iteration each model is recompiled.

If you don't recompile model, the modification for layer.trainable will not take effect.

I think the summary produced is wrong. For the first two models, it should be
Total params: 2,112
Trainable params: 1,056
Non-trainable params: 1,056
Could you confirm that this is bug?

I also have the same problem. Is there any way to do it? I've seen this is solved when I am freezing a whole model, and then combining it (like GANS). But is it possible to do the same with only a couple of layers?

I have the same problem than rnorm https://github.com/keras-team/keras/issues/8259


Generate docker-compose file

Remove docker-launch from base image and instead use docker-launch to generate entry-point scripts for the image's collator binary (which can be assumed to exist at the fixed path /app/bin/pendulum-collator).  The base image will expose 4 generic ports, which will be mapped to ports from the collator nodes in the launcher configuration.  This issue deprecates issue #16.

added as_command methods to validator and collator nodes

working on a trait implementation that splits as_command into internal and external command.  This will be used to for internal consumption into Tasks as apposed to external imports as raw string literals, which can be executed in external environments.  The idea being that an external command can be placed in a docker configuration.


Greater control over variable substitution

Brief Issue Summary
Perhaps this is already possible, but I have been unable to figure it out.
I would like to be able to have finer grained control over variable substitution
Expected:
Unfortunately some external tools expect ${buildType} to be lower case debug/release, whereas the variable substituted is Debug/Release.
Configuration:
My .vscode/settings.json file:
{
    "cmake.buildDirectory": "${workspaceRoot}/.build/${buildType}",
}

My .vscode/cmake-variants.yaml file:
 buildType:
  default: debug
  choices:
    debug:
      short: Debug
      long: Emit debug information
      buildType: Debug
    release:
      short: Release
      long: Optimize generated code
      buildType: Release

Is there a way to substitute debug instead of Debug in my cmake.buildDirectory value?
Platform and Versions

Operating System: Ubuntu
CMake Version: 3.10.2
VSCode Version: 1.39.2
CMake Tools Extension Version: 1.1.3
Compiler/Toolchain: gcc-7.4

I tried using ${variant:SHORT} and ${variant:short} in my cmake.buildDirectory, but that expanded to an empty string

Aha! Figured it out!
By using ${variant:buildType}, and changing cmake-variants.yaml to have lower case in the short options, I managed to get my desired lower case build variant.
So to add the specifics:
My .vscode/settings.json file:
{
    "cmake.buildDirectory": "${workspaceRoot}/.build/${variant:buildType}",
}

My .vscode/cmake-variants.yaml file:
 buildType:
  default: debug
  choices:
    debug:
      short: debug
      long: Emit debug information
      buildType: Debug
    release:
      short: release
      long: Optimize generated code
      buildType: Release

For other users I have added a copy of default CLion settings.
cmake-variants.yaml:
 buildType:
  default: debug
  choices:
    debug:
      short: debug
      long: Add debug information.
      buildType: Debug
    release:
      short: release
      long: Optimize generated code.
      buildType: Release
    relwithdebinfo:
      short: relwithdebinfo
      long: Optimize generated code and add debug information.
      buildType: RelWithDebInfo
    minsizerel:
      short: minsizerel
      long: Optimize generated code and minimize the size.
      buildType: MinSizeRel


New container mrsiproc 0.0.1

There is a new container, use this command to test:
bash /neurocommand/local/fetch_and_run.sh mrsiproc 0.0.1 20230928

and then add to apps.json to release:
https://github.com/NeuroDesk/neurocommand/edit/main/neurodesk/apps.json

@korbinian90


Tests

This PR adds tests to Husky. Yes, this should have been done long ago but better late than never.

Going to merge this into master. Will add more tests along the way.


Created _ readme.md

Created readme.md which has list of all the awesome ai tools!

Hi @DhruviThakkar210 can you please sign the DCO ?

I have signed the DCO . I have also made  the required changes .


Extracted circular buffer logic into dedicated types

In its current state ArrayDeque<A> contains three utterly long methods …

fn insert(&mut self, …)
fn remove(&mut self, …)
fn wrap_copy(&mut self, …)

… which consist of each a huge match.
I removed the matchs, moved it into their own dedicated types and split them up some more.
With this change one can –in future– easily add finely-grained test cases for each match case, while in its current form each match is a huge blackbox.
Over time ArrayDeque<A> will grow some more.
I managed to reduce lib.rs from 2633 to 2299 loc for now.

Context:
I'm working on a PR for issue https://github.com/andylokandy/arraydeque/issues/6 according to:

Add a type parameter on ArrayDeuqe, determining whether to enable wrapping behavior, which would look like ArrayDeque<[usize; 64], Wrapping>, and disable as default.

Before changing anything I figure it would be a good time to clean up some of the less intuitive code.

Wow, lots of changes here.
Thank for this PR. I've looked through your codes, I can see the major point is to split the clumsy functions into small pieces and group them with new files. This PR is well coded and, obviously, you've done it with professional qualities and great patient. But I may reject it currently because of some reasons below:

Essentially, those clumsy functions are completely copy-and-pasted from standard library's Deque. Not only Standard library provides plenty of tests for it but also Deque was battle-tested since released with rust 1.0. Moreover, arraydeque has over 500 lines of tests to double check the correctness of those functions. So, it's ok with me that they remain black-box.

Since we have codes inherit from standard library, it's better to keep close to its original shape, so that we can easily follow the changes from standard library.

Ah, I see. Fair point.
Fortunately my WIP PR does not depend on the changes made here.
I will rebase it back onto current master then.


Speed improvement on CV creation for large datasets or small windows

I removed the creation of the Pandas DataFrame and the expensive np.isin operation, and replaced it with a much faster alternative with no changes in the outcome. The speed effect becomes visible for large datasets or small windows.

Hello,
Thank you for this improvement and I have merged your pull request.
Best,


Loading state disappears too fast

Our loading state is beautiful, so it'd be cool to show it at least for 3 seconds at the first start.

Thought about it once more - seems unnecessary.


Add Vaccinations per Million to States Page

Is your feature request related to a problem? Please describe.
Just like the

it might be useful to have vaccinations per million
Describe the solution you'd like
Simply another tab on the state page without any required change to API.
Describe alternatives you've considered
None
Additional context

You can click on 10L button to view Total Doses Administered(Vaccination) per million at the Home Page not only for Statewise but also for DistrictWise


Provide a option to preserve percent-encoding in the request path.

Armeria automatically decodes percent-encoded characters if they are not in the preserved chars.
https://github.com/line/armeria/blob/eb36d93f0a197019a5c790650c3f556b86b22973/core/src/main/java/com/linecorp/armeria/internal/common/DefaultRequestTarget.java#L60-L68
If a service proxies incoming requests, users may want to see the original percent-encoding as is.
An option to preserve percent-encoding would be useful for that case.
WebClient
  .builder("https://my-proxy.com")
  .preservePercentEncoding(true)
  ...
  build();

Server
  .builder()
  .preservePercentEncoding(true)
  ...
  build();

Discord thread: https://discord.com/channels/1087271586832318494/1087272728177942629/1157388108032118886

Would be awesome if we could opt-in for original percent encoding on per route basis on a server. Most routes/endpoints don't care for path but, as mentioned in the ticket, a proxy-type of endpoints do.

Hi, I'm student interested in Armenia.
I think I can make this feature. Can you assign me?

Sorry for the late reply. @HongGeonUi are you still interested in implementing this feature?

@ikhoon Sorry, I'm still interested in this feature. but I didn't care about this.
I make PR #5374.
Happy belated New Year!

Would be awesome if we could opt-in for original percent encoding on per route basis on a server

While looking at this comment, it seems at the moment there seems to be a circular dependency:

In order to know whether to preserve percent encoding, we need to find the ServiceConfig
In order to find the ServiceConfig, we need to first normalize the path (using percent encoding?)

We may need to consider either

Updating the HttpRequest.header after routing completed and we know whether to preserve percent encoding

Just exposing the original path (this may be a breaking change though)

HttpHeaders.path() // the path that is used for routing
HttpHeaders.rawPath() // the raw path that was received with no normalization

Talked with the others, I propose the following:
Server side
A new method is added such that the original path of the request can be retrieved to ServiceRequestContext.
DecodedHttpRequest.originalPath() <- internally carries the raw path across the netty pipeline
ServiceRequestContext.originalPath() <- public api exposed to users

Client-side
A new option is added per-client which preserves percent-encoding like mentioned in the original proposal.
WebClient
  .builder("https://my-proxy.com")
  .preservePercentEncoding(true)
  ...
  build();

In conjunction, the two methods can be used like the following:
val client = WebClient
  .builder("https://my-proxy.com")
  .preservePercentEncoding(true)
  ...
Server.builder().service("/proxy", (ctx, req) -> {
  return client.execute(req.withHeaders(req.headers().toBuilder().path(ctx.originalPath()).build()));
})

Note that it might be difficult to determine the prefix path with this approach.
For instance, the normalized path strips consecutive slashes, so the following scenario is possible:
originalPath: //%70roxy//a
path (normalized): /proxy/a

The user may choose to reject unnormalized paths and strip the prefix path depending on his/her requirements

Hi @ikhoon , Can you please assign this issue to me??

Sure, did it.


Support Rich Authorization Requests in the jwt_auth plugin

Title: Support Rich Authorization Requests in the jwt_auth plugin
Description:
Alright, ready for some deep dives into authorization theory? Great!
The current behavior of the jwt_authn plugin includes a check for an exact string match between the JWT's aud claim, and a string in the audience field for the filter configuration. This audience claim, in authorization parlance, is the list of destinations for whom the token is intended. In other words, I could sign a token for resource server A, and if presented to resource server B that token would be rejected because "hey, that's not meant for me".
This is all well and good, however from the view of us authorization nerds it's a fraught authorization check. The reason is that an audience claim can state "where" a token may be used, but not "what" resource it may be used for or "how" that resource may be modified. The scopes claim has historically been used to provide this information, but there is no way to correlate: Assuming two audiences and two scope values, how do we know which scope value is intended for which audience?
{
   ....,
   aud: [
      "audience_one",
      "audience_two",
   ],
   scope: "ambiguous_scope_1 ambiguous_scope_2",
}

Due to this lack of specificity, the OAuth2 community has (mostly) converged on a new RFC called "Rich Authorization Requests". The intent here is to provide a more detailed authorization statement on in a JWT, which can answer the how, what, and where of any inbound request. In essence it replaces the aud claim with a list of authorization statements, with the aud claim being replaced by locations. This example is taken directly from the RFC:
{
   ...,
  authorization_details:  [
      {
         "type": "account_information",
         "actions": [
            "list_accounts",
            "read_balances",
            "read_transactions"
         ],
         "locations": [
            "https://example.com/accounts"
         ]
      },
      {
         "type": "payment_initiation",
         "actions": [
            "initiate",
            "status",
            "cancel"
         ],
         "locations": [
            "https://example.com/payments"
         ],
         "instructedAmount": {
            "currency": "EUR",
            "amount": "123.50"
         },
         "creditorName": "Merchant A",
         "creditorAccount": {
            "iban": "DE02100100109307118603"
         },
         "remittanceInformationUnstructured": "Ref Number Merchant"
      }
   ]
}

There are some concerns with the specification, of course, because it is unnecessarily broad: Most of the Common Data Fields are optional, and exactly how a token's assembled is largely left to the implementor. Furthermore, the RFC itself only lightly touches on how this should be represented in a JWT:
If the access token is a JWT [[RFC7519](https://datatracker.ietf.org/doc/html/rfc7519)], the AS is RECOMMENDED to add
the authorization_details object, filtered to the specific audience,
as a top-level claim.

If that wasn't enough, there's already a new specification that builds on OAuth2.1 under draft called Grant Negotiation and Authorization Protocol (GNAP) which has its own view of what this specificity should look like. In this case, the data structure for an authorization statement is similar to the above, however the top level field is called access instead of authorization_details.
So what exactly is this request all about? Adding a locations field to the http filter configuration, which will trigger a check of either authorization_details[].locations or access[].locations.
I hope I didn't bore you!
Relevant Links:

Rich Authorization Requests (Draft 12)
RFC 7519, JSON Web Token
GNAP
envoy jwt_authn filter configuration

Tagging @qiwzhang and @lizan at @alyssawilk's direction :)

This seems to be a case that should be done via RBAC or other authz filter happens after jwt_authn? The validated JWT can be extracted to metadata then authorized by them.

Depends! If you want to allow all validated traffic into your cluster, then yes you can do that. However, if you want to allow an audience-style filter by envoy that throws out any traffic not explicitly intended for this resource server, and the token uses authorization_details instead of the audience claim, then you'd want to check the location claim instead of the audience claim.
I'm simply asking for feature parity given that the common JWT structure is evolving.

Using another filter doesn't allow all validated traffic into the cluster, they just do another check before the traffic hit clusters.
I'm saying that even today this is doable when you store the JWT payload in a metadata and matches them in RBAC filter, you should be able to match any structured fields including authorization_details[].locations or access[].locations. Isn't this the feature request is for?

Huhn- ok, so, that may work. I've forwarded your suggestion to the relevant team.
Given that what I'm asking for can be done with existing filters, that still leaves the question on whether or not jwt_auth should support it natively. I can see an argument either way - on one side, the name of the filter itself clearly references JWT, and should therefore adhere to what's in the JWT claims RFC. Given that JWT's may not be issued by an OAuth2 system (although I'd argue that 99.99% of them are) you can make an argument for purity that the filter should remain restricted to this RFC.
The counter argument is that of general usage: JWT's are canonically issued by OAuth2 systems, which continue to evolve at the pace of RFC's. Updating the filter makes a decent amount of sense, but by that argument we could also build a filter explicitly for Rich Authorization Requests.
What's your take?

(although I'd argue that 99.99% of them are)

There are JWT specs that doesn't necessarily to be issued by an OAuth2 system like the JWT-SVID in service-to-service context. :)
I'm not against to add support of the rich authorization to JWT filter itself, but just I want to see how mature this RFC draft is and how the adoption goes. Given that the authorization itself should be already doable within what we have today so it doesn't block prototyping or experimenting.


Added escaping for columns in the MSSQLDialect, MySQLDialect, Postgre…

…SQLDisalect

@jclarkk looks like there is a lot of copy/paste in  your code. Additionally, the project is completely broken with 351 test failures. Have you tried to build it?

You are right.
I'll open up a proper pull request with the required changes.


Flattened nested structs throw deserialize error "invalid type: map, expected f64" when inner type contains a float

~Update: this example works on other people's systems, but fails on mine.~
~My specs:~
~- M1 Max Macbook Pro running macOS Sonoma 14.5~
~- rustc 1.76.0~
~Already tried after running cargo clean, same result.~
Minimal reproducible example:
use serde::{Serialize, Deserialize};

fn main() {
    #[derive(Serialize, Deserialize, Debug)]
    pub struct Outer {
        #[serde(flatten)]
        inner: Inner,
    }
    #[derive(Serialize, Deserialize, Debug)]
    pub struct Inner {
        foo: f64,
    }

    let constructed = Outer {
        inner: Inner {
            foo: 1.0,
        },
    };

    let serialized = serde_json::to_string(&constructed).unwrap();
    println!("serialized: {serialized:?}");

    let deserialized: Outer = serde_json::from_str(&serialized).unwrap();
    println!("deserialized: {deserialized:?}");
}

Expected output
The struct correctly serializes and deserializes back into the original, with no errors
Observed output
serialized: "{\"foo\":1.0}"
thread 'main' panicked at temp.rs:25:65:
called `Result::unwrap()` on an `Err` value: Error("invalid type: map, expected f64", line: 1, column: 11)
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1649:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1073:23
   4: temp::main
             at ./astra-server/examples/temp.rs:25:31
   5: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Notes
This only happens when the inner type contains a f64 or f32. String and integer types seem to ser/deser without an error. The error also goes away when I remove #[serde(flatten)]

See here for related issue: https://github.com/serde-rs/serde/issues/2623

Update: my issue seems to controlled by the presence of a transitive dependency on the ethers and ethers-contract crates: https://github.com/serde-rs/serde/issues/2623#issuecomment-2133242549
Removing these dependencies results in correct behavior.
Still unclear what the underlying cause is though.

The issue is caused by the serde_json arbitrary_precision feature being turned on. It passes when this feature is off and fails when it is on.

that is the bug in the serde_json library