Add New Default Workspace Avatars

Details

We are adding the new default workspace avatars (SVGs) as part of the new branding changes.

The default workspace avatar is dynamically created by determining the first appearing letter/number of the workspace title. If none, then the workspace defaults to the building icon. For example, Expensify would result in an E,  !Expensify would result in an E, and ! would result in a building.
Similarly, the title is used to randomly select a color pairing. Because default avatars are not currently stored in memory, this ensures that the default avatar colors remain consistent. The title is stripped from any trailing whitespace. Therefore, Expensify will have a different color than Expensify 1 and so on.
Whenever an avatar is used, we need to know three things in order to properly style it:

Is this a workspace avatar or a user avatar? (square, circle)
Who is this avatar for? (user/login, workspace/name)
What is the source URL of this avatar, if any? (user-uploaded, none)

I refactored <Avatar> to take in this information (type, name, source)
This will mean <Avatar> will be able to own the default avatar calculations. This also means that we can later support more types of avatars if needed (rooms, etc).
I will be following up this PR with another PR to clean up the default avatars for users.
Current Branch:
https://user-images.githubusercontent.com/38015950/219905837-503fa4a7-ffff-4398-b99f-c2c598d00b80.mov
Fixed Issues

$ https://github.com/Expensify/App/issues/12259
Tests

[x] Verify that no errors appear in the JS console

[x] Verified that A-Z/0-9 and building SVG all work by changing the title of the workspace

[x] Verified that changing the title (but not the first letter) of the workspace results in a color change

[x] Verified that using a user-uploaded workspace avatar works

[x] Completed QA steps below.

Offline tests

QA Steps

[ ] Verify that no errors appear in the JS console
[ ] Create 5 Workspaces
[ ] Add a user-uploaded avatar to two of them, and ensure that it looks correct (square border) on all pages.
[ ] Remove the user-uploaded avatar from one, and ensure that it now uses a default avatar.
[ ] For the other 4, name them with different first letters. Ensure that they get a correct SVG avatar on all pages.
[ ] Add a member to each workspace.

Repeat this with both the user-uploaded workspace and the normal workspace:

[ ] In a Workspace Chat (header, large icon)
[ ] In the LHN.
[ ] In the Search Bar http://localhost:8080/search
[ ] In the settings page - http://localhost:8080/settings
[ ] On the workspaces page - http://localhost:8080/settings/workspaces
[ ] On a single workspaces space - http://localhost:8080/workspace/{workspace ID}
[ ] On a single workspaces settings - http://localhost:8080/workspace/{workspace ID}/settings

Because this modified the Avatar Component, we will also check that user avatars look correct. Make sure you have at least 1 avatar that uses a user-uploaded avatar to reference before checking these pages:

[ ] In a Chat (header, large icon, message icon)
[ ] In the LHN.
[ ] In the Search Bar http://localhost:8080/search
[ ] In the settings page - http://localhost:8080/settings
[ ] On Profile page - http://localhost:8080/settings/profile
[ ] On Details Page http://localhost:8080/details?{login}
[ ] In attachment modal http://localhost:8080/details?{login} -> Click on Avatar
[ ] On a single workspaces space - http://localhost:8080/workspace/{workspace ID}
[ ] On a single workspaces settings - http://localhost:8080/workspace/{workspace ID}/settings
[ ] On IOU/Send - http://localhost:8080/iou/send
[ ] On IOU/Request - http://localhost:8080/iou/request
[ ] On IOU/Split -  http://localhost:8080/iou/split
[ ] On the IOU previews with a chat with IOUs
[ ] On IOU details page - http://localhost:8080/iou/details/{report ID}/{iou ID}
[ ] On New group page - http://localhost:8080/new/group
[ ] On New chat page - http://localhost:8080/new/chat
[ ] On workspace manage members page - http://localhost:8080/workspace/{workspace ID}/members

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://user-images.githubusercontent.com/38015950/220436310-5ec58fca-8cb6-43a7-99a7-a5b5881ffdd3.mov

Mobile Web - Chrome

https://user-images.githubusercontent.com/38015950/220436919-ac554020-1e9e-427e-b598-9cd1ba4fe3dc.mov

Mobile Web - Safari

https://user-images.githubusercontent.com/38015950/220436486-d038506b-0a40-4210-8e74-f0df42b55581.mov

Desktop

https://user-images.githubusercontent.com/38015950/220437518-029a04e4-c91e-4e03-a1d2-c2cd8afefa9b.mov

iOS

https://user-images.githubusercontent.com/38015950/220436757-b0a89ad6-adc0-4886-939f-aec868951b2b.mov

Android

https://user-images.githubusercontent.com/38015950/220437147-fa047246-8db7-473b-bd83-6627e3704b2d.mov

This might be my fault but looks like the default workspace avatar is missing one of the three lines to make it look like a building:

Let me know if you need a new svg for that.

Otherwise this is looking dope!

@mananjadhav @aldo-expensify One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

@grgia @shawnborton This how it shows when characters have an accent?  It skips the first char, and picks the second one for the Avatar.

Oh interesting. Maybe we should just use the non-accent version of the first character in this case? Technically we could support all of these cases but I think that's overkill to start with.

Maybe we should just use the non-accent version of the first character in this case?

This sounds like a good plan

Taking a look at these suggestions tonight

I addressed all the suggested changes, so this should be good for round #2!

This is feeling really nice!
One minor comment: I wonder if we want to generate a new random color each time a workspace name is saved? Or maybe a better approach is to only do that when a new first letter is chosen? I don't feel strongly there, but I could see where we only need it for changing of the first letter and not making subsequent adjustments.
Like if I had a workspace named "Expensify" and then later I changed it to "Expensify USA" - maybe I would want to keep the same icon color as before?

One minor comment: I wonder if we want to generate a new random color each time a workspace name is saved? Or maybe a better approach is to only do that when a new first letter is chosen? I don't feel strongly there, but I could see where we only need it for changing of the first letter and not making subsequent adjustments.
Like if I had a workspace named "Expensify" and then later I changed it to "Expensify USA" - maybe I would want to keep the same icon color as before?

Right now the way it works, we get the workspace colors from a hash based on the workspace name, so "Expensify" will be the same color everywhere. So it won't change on save unless you change the name of the workspace.
So we could definitely do that, but I think we could make that change in a second PR since that would require saving the desired color combination with the workspace data and accessing it from ONYX. Or saving a copy of the correct colored icon to the workspace data but I believe that might still be on hold for the SVG support.

Ah okay cool, thanks for explaining and I am cool with us doing that as a follow up!

This should be good for final review @mananjadhav @aldo-expensify  :)

Updated the fallback colors to green700, this is ready for another round!

@mananjadhav @aldo-expensify would you mind prioritizing the checklist for this PR? I can make any changes today if needed, but it tests really well on my end and I'd love to get this merged.

Everything seems to be working perfect except for this little detail:
If I invite an account that doesn't exist to a workspace, in the search I get a default icon, but after adding it the icon is the "error" icon?
https://user-images.githubusercontent.com/87341702/222571965-6475572e-c5ae-4c16-b2d2-4d45aae06e28.mov
There is no error in the console/network.
Is this intended?

Done with all those fixes! @aldo-expensify

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@grgia , when there are more than 4 WPs, you can still see the 4th workspace avatar plus the +count on top of it:

I other cases, you don't show the avatar anymore, just the +count which makes it more readable. For example:

Should we apply the same technique?
cc @shawnborton

I'm wondering if a trashed workspace should have a square icon preserving the shape of workspace icons:

I'm going to go ahead and merge this one to avoid conflicts!
I made two issues for the above comments that I'll fix in a follow up PR:
https://github.com/Expensify/App/issues/15635
https://github.com/Expensify/App/issues/15636

I tested on web and desktop. I’ll finish the checklist in an hour and raise if any issues. Can be picked as a follow up PR.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@grgia @shawnborton Here are different cases for the workspace title

If you notice *hello and ÆTest, the first characters are ignored and the workspace avatar picks from the second symbol. Is that the expected output? or does it needs to be fixed?

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://user-images.githubusercontent.com/3069065/222640377-6feddb4a-86cb-4164-9c51-230dc04ecd18.mov

Mobile Web - Chrome

Mobile Web - Safari

Desktop
https://user-images.githubusercontent.com/3069065/222640480-80d879d3-bfa1-4c49-a84d-719b49809646.mov

iOS
https://user-images.githubusercontent.com/3069065/222640776-e7bcc08c-096a-4bfb-8716-6ee4eb298087.mov

Android

I other cases, you don't show the avatar anymore, just the +count which makes it more readable. For example: Should we apply the same technique?

I don't think so, no. If anything, we can bump down the opacity of the overlay. But this style matches what it looks like when you start a DM with multiple people:

(Also wow, I did not realize Concierge would send a message when I created that test group 😨 )
Anyways, thank you Georgia for pushing this through, it's beautiful!!

@mananjadhav for your comment here, I think this is okay for now. Let's just be diligent about this when the inevitable bug reports come in. But yeah, I don't think we're going to have actual real workspaces come in with these kinds of characters just yet, so let's make people aware that we are purposely choosing not to address this for the time being.

🚀 Deployed to staging by https://github.com/grgia in version: 1.2.79-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/roryabraham in version: 1.2.79-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

This PR introduced a regression here https://github.com/Expensify/App/issues/15697 due to missing offline tests.

Hey 👋🏾, it seems like we first implemented square workspace icons with this PR. However, the shape of the mask we use for cropping uploaded workspace avatars wasn't updated from a circle to a square as well which resulted in this bug.


Wrong url for external scaler KEDA HTTP && KEDA External Scaler for Azure Cosmos DB.

Links of external scalers (KEDA HTTP && KEDA External Scaler for Azure Cosmos DB) are not working on this page -https://keda.sh/docs/2.9/scalers/
Expected Behavior
The links should direct to -
for KEDA  HTTP - https://github.com/kedacore/external-scalers/tree/main/artifacthub
for KEDA External Scaler for Azure Cosmos DB - https://github.com/kedacore/external-scalers/tree/main/artifacthub
Actual Behavior
The links are directing here -
for KEDA HTTP - https://github.com/kedacore/external-scalers/artifacthub
for KEDA External Scaler for Azure Cosmos DB - https://github.com/kedacore/external-scalers/artifacthub

@tomkerkhove  @JorTurFer
Reason is that these external scalers's links are pulled the data form this url -https://artifacthub.io/api/v1/packages/search?offset=0&limit=20&facets=false&kind=8&deprecated=false&sort=relevance  and the output of this url is -

so first we need to change url in its output.

I have no idea about how artifact hub works, maybe @tomkerkhove knows it

@tegioz this might be a bug.
We are defining our external scalers in https://github.com/kedacore/external-scalers/tree/main which has a folder per official KEDA external scaler but the search results are not rendering valid URLs.
Can we configure these somewhere?

Hi @tomkerkhove 👋
The repository url you see in the search API output represents the url as it was added to AH. That url is correct and it uses the format expected by AH so that it can be processed periodically.
It looks like what you need is a URL for each of the packages. There are a few ways you could get this done:
Using AH packages urls
This is probably the easiest way, as you have everything you need from the search API output, but you'll need to build the urls on your end. The format would be:
https://artifacthub.io/packages/keda-scaler/{REPO_NAME}/{PKG_NORMALIZED_NAME}
And you can get both the repo name and the package normalized name from the output displayed above. The result would be a link like the one below:
https://artifacthub.io/packages/keda-scaler/keda-official-external-scalers/keda-add-ons-http
Using links provided by the package provider
Another alternative would be to get some extra information from AH for each of the packages, which will return all links provided by the package. If by convention you know all scalers will provide a source link, for example, you could rely on that and use that link.
This approach requires an extra API call per package, and it may not be as solid as in the end it will depend on something extra each package would need to provide, so I would recommend going with the first one.
Hope this helps 🙂

Definately helps, thanks! It looks like we should be using option 1 to avoid doing too many API calls.
Adding this to our doc improvement project for @chalin, @thisisobate and team.


Revert "Added LightVisual (#202)"

This reverts commit f9b58e643da57f60f6f568ca6e79984925539bf3.
Signed-off-by: Shane Loretz<EMAIL_ADDRESS>Fixes #226
@ahcorde @iche033 mind taking a look?

This PR should fix the problem https://github.com/ignitionrobotics/ign-rendering/pull/228. Let's wait the Windows CI

Closing in favor of #228. Thanks for staying on top of it, :man_farmer: @sloretz


Fix typed_swap for ZSTs

typed_swap needs to be a no-op on ZSTs as pointers to those have an arbitrary value in Kani.
Resolves: #3182
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

perf test failure is inet::checksum::tests::differential running out of memory (on this occasion).


Keyword-to-caption reproducibility

Hey authors,
Thank you for the effort you put in publishing the code and answering questions.
Following your answer in #58 I attempted to replicate the examples you showed in appendix F in your paper with the package you referenced gagan3012/keytotext.
I went through all the models they specify in the documentation ('k2t-base', 'k2t', 'k2t-new', 'k2t-tiny', 'mrm8488/t5-base-finetuned-common_gen'), but none gave the results given in the column T5_raw_sentence for the input given in the column Keywords.

Could you please elaborate on how you used the code for the K2C augmentation?

Thank you

Hi, thanks for your interest in our work. @tianyu-z could you please let debeiski know how we use the code? Many thanks!

Hi, after getting the generated sentences, we post-process them with some simple rules to avoid potential bias. e.g. replace all "woman", "man" with "person"; "her" and "his" to "their", etc. This might be the reason that you are not getting the exact same sentence.

Your paper mentions the use of k2t to process the Audioset dataset. I use the class corresponding to the positive_labels as the keyword, and the generated caption is not satisfactory.


add tableReferences in selectStatement

ref #4885 .
Changes proposed in this pull request:

add tableReferences in selectStatement
Keep tables and remove tables in the next subtask
only change for mysql ,Subtasks behind will be compatible with other db

Codecov Report

Merging #4916 into master will decrease coverage by 0.18%.
The diff coverage is 0.00%.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 806c231...0b41af1. Read the comment docs.

Pull Request Test Coverage Report for Build 10526

0 of 55 (0.0%)  changed or added relevant lines in 5 files are covered.
34 unchanged lines in 7 files lost coverage.
Overall coverage decreased (-0.1%) to 57.993%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

shardingsphere-sql-parser/shardingsphere-sql-parser-statement/src/main/java/org/apache/shardingsphere/sql/parser/sql/segment/dml/JoinedTableSegment.java
0
1
0.0%

shardingsphere-sql-parser/shardingsphere-sql-parser-statement/src/main/java/org/apache/shardingsphere/sql/parser/sql/statement/dml/SelectStatement.java
0
1
0.0%

shardingsphere-sql-parser/shardingsphere-sql-parser-statement/src/main/java/org/apache/shardingsphere/sql/parser/sql/segment/dml/JoinSpecificationSegment.java
0
2
0.0%

shardingsphere-sql-parser/shardingsphere-sql-parser-statement/src/main/java/org/apache/shardingsphere/sql/parser/sql/segment/dml/TableReferenceSegment.java
0
11
0.0%

shardingsphere-sql-parser/shardingsphere-sql-parser-dialect/shardingsphere-sql-parser-mysql/src/main/java/org/apache/shardingsphere/sql/parser/mysql/visitor/impl/MySQLDMLVisitor.java
0
40
0.0%

Files with Coverage Reduction
New Missed Lines
%

sharding-core/sharding-core-rewrite/src/main/java/org/apache/shardingsphere/sharding/rewrite/engine/ShardingSQLRewriteEngine.java
1
94.44%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/rule/TableRule.java
3
90.53%

sharding-orchestration/sharding-orchestration-core/sharding-orchestration-core-registrycenter/src/main/java/org/apache/shardingsphere/orchestration/core/registrycenter/util/IpUtils.java
3
76.0%

shardingsphere-sql-parser/shardingsphere-sql-parser-dialect/shardingsphere-sql-parser-mysql/src/main/java/org/apache/shardingsphere/sql/parser/mysql/visitor/impl/MySQLDMLVisitor.java
4
0%

sharding-scaling/sharding-scaling-core/src/main/java/org/apache/shardingsphere/shardingscaling/core/synctask/history/HistoryDataSyncTask.java
7
76.47%

sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/rule/ShardingRule.java
8
85.21%

sharding-scaling/sharding-scaling-core/src/main/java/org/apache/shardingsphere/shardingscaling/core/execute/executor/channel/MemoryChannel.java
8
51.85%

Totals

Change from base Build 1155:
-0.1%

Covered Lines:
11873

Relevant Lines:
20473

💛  - Coveralls

The approach you took is basically correct and a good start for this issue. However some comments and doubts need your feedback.
@jingshanglu

@tristaZero  I have changed base comment,please review.


Can't install PUMA -v 2.xx [WINDOWS]

Using Ruby 2.3 x86
Windows 10E
I can install any other version of PUMA, however, I need version 2.13.4
INPUTS:
C:\WINDOWS\system32>cd c:\devkit
c:\devkit>gem install puma -v 2.13.4
Temporarily enhancing PATH to include DevKit...
Building native extensions.  This could take a while...
ERROR:  Error installing puma:
ERROR: Failed to build gem native extension.
current directory: C:/Ruby23/lib/ruby/gems/2.3.0/gems/puma-2.13.4/ext/puma_http11

C:/Ruby23/bin/ruby.exe -r ./siteconf20170321-10940-153kts9.rb extconf.rb
checking for BIO_read() in -lcrypto... no
checking for BIO_read() in -llibeay32... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=C:/Ruby23/bin/$(RUBY_BASE_NAME)
--with-puma_http11-dir
--without-puma_http11-dir
--with-puma_http11-include
--without-puma_http11-include=${puma_http11-dir}/include
--with-puma_http11-lib
--without-puma_http11-lib=${puma_http11-dir}/lib
--with-cryptolib
--without-cryptolib
--with-libeay32lib
--without-libeay32lib
To see why this extension failed to compile, please check the mkmf.log which can be found here:
C:/Ruby23/lib/ruby/gems/2.3.0/extensions/x86-mingw32/2.3.0/puma-2.13.4/mkmf.log
extconf failed, exit code 1
Gem files will remain installed in C:/Ruby23/lib/ruby/gems/2.3.0/gems/puma-2.13.4 for inspection.
Results logged to C:/Ruby23/lib/ruby/gems/2.3.0/extensions/x86-mingw32/2.3.0/puma-2.13.4/gem_make.out
LOGFILE:
have_library: checking for BIO_read() in -lcrypto... -------------------- no
"gcc -o conftest.exe -IC:/Ruby23/include/ruby-2.3.0/i386-mingw32 -IC:/Ruby23/include/ruby-2.3.0/ruby/backward -IC:/Ruby23/include/ruby-2.3.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64   -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration -Wdeprecated-declarations -Wno-packed-bitfield-compat conftest.c  -L. -LC:/Ruby23/lib -L.      -lmsvcrt-ruby230  -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi  "
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <winsock2.h>
4: #include <windows.h>
5: int main(int argc, char *argv)
6: {
7:   return 0;
8: }
/ end */
"gcc -o conftest.exe -IC:/Ruby23/include/ruby-2.3.0/i386-mingw32 -IC:/Ruby23/include/ruby-2.3.0/ruby/backward -IC:/Ruby23/include/ruby-2.3.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64   -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration -Wdeprecated-declarations -Wno-packed-bitfield-compat conftest.c  -L. -LC:/Ruby23/lib -L.      -lmsvcrt-ruby230 -lcrypto  -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi  "
conftest.c: In function 't':
conftest.c:16:57: error: 'BIO_read' undeclared (first use in this function)
conftest.c:16:57: note: each undeclared identifier is reported only once for each function it appears in
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <winsock2.h>
4: #include <windows.h>
5:
6: /top/
7: extern int t(void);
8: int main(int argc, char *argv)
9: {
10:   if (argc > 1000000) {
11:     printf("%p", &t);
12:   }
13:
14:   return 0;
15: }
16: int t(void) { void ((volatile p)()); p = (void (()()))BIO_read; return !p; }
/ end */
"gcc -o conftest.exe -IC:/Ruby23/include/ruby-2.3.0/i386-mingw32 -IC:/Ruby23/include/ruby-2.3.0/ruby/backward -IC:/Ruby23/include/ruby-2.3.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64   -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration -Wdeprecated-declarations -Wno-packed-bitfield-compat conftest.c  -L. -LC:/Ruby23/lib -L.      -lmsvcrt-ruby230 -lcrypto  -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi  "
c:/devkit/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lcrypto
collect2.exe: error: ld returned 1 exit status
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <winsock2.h>
4: #include <windows.h>
5:
6: /top/
7: extern int t(void);
8: int main(int argc, char *argv)
9: {
10:   if (argc > 1000000) {
11:     printf("%p", &t);
12:   }
13:
14:   return 0;
15: }
16: extern void BIO_read();
17: int t(void) { BIO_read(); return 0; }
/ end */

have_library: checking for BIO_read() in -llibeay32... -------------------- no
"gcc -o conftest.exe -IC:/Ruby23/include/ruby-2.3.0/i386-mingw32 -IC:/Ruby23/include/ruby-2.3.0/ruby/backward -IC:/Ruby23/include/ruby-2.3.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64   -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration -Wdeprecated-declarations -Wno-packed-bitfield-compat conftest.c  -L. -LC:/Ruby23/lib -L.      -lmsvcrt-ruby230 -llibeay32  -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi  "
conftest.c: In function 't':
conftest.c:16:57: error: 'BIO_read' undeclared (first use in this function)
conftest.c:16:57: note: each undeclared identifier is reported only once for each function it appears in
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <winsock2.h>
4: #include <windows.h>
5:
6: /top/
7: extern int t(void);
8: int main(int argc, char *argv)
9: {
10:   if (argc > 1000000) {
11:     printf("%p", &t);
12:   }
13:
14:   return 0;
15: }
16: int t(void) { void ((volatile p)()); p = (void (()()))BIO_read; return !p; }
/ end */
"gcc -o conftest.exe -IC:/Ruby23/include/ruby-2.3.0/i386-mingw32 -IC:/Ruby23/include/ruby-2.3.0/ruby/backward -IC:/Ruby23/include/ruby-2.3.0 -I. -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0501 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64   -O3 -fno-omit-frame-pointer -fno-fast-math -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration -Wdeprecated-declarations -Wno-packed-bitfield-compat conftest.c  -L. -LC:/Ruby23/lib -L.      -lmsvcrt-ruby230 -llibeay32  -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi  "
c:/devkit/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -llibeay32
collect2.exe: error: ld returned 1 exit status
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <winsock2.h>
4: #include <windows.h>
5:
6: /top/
7: extern int t(void);
8: int main(int argc, char *argv)
9: {
10:   if (argc > 1000000) {
11:     printf("%p", &t);
12:   }
13:
14:   return 0;
15: }
16: extern void BIO_read();
17: int t(void) { BIO_read(); return 0; }
/ end */

You probably have older openssl installation, without BIO_read().
Check accepted answer on SO:
http://stackoverflow.com/questions/24183377/puma-installation-error-on-windows

@dmajkic  - Yup! that did it! Thanks.

@dmajkic @seanvree guys, once you manage to compile puma with SSL support, are you actually able to run the server bound to SSL? In my multiple previous attempts, puma starts, but making HTTPS requests to it fails, - puma does not show any errors in the console, HTTPS requests just hang. Any pointers if you have some experience running puma on Windows with SSL enabled? 🙏

You should probably ask (or raise issue) at Puma repository.

@vais  - Yes, it works.

@seanvree hmm, so it works for you with puma 2.13.4 then? I don't think I've tried with an older version... Have you by any chance had success with version 3.x? Sorry, I just don't know if I was "doing it wrong(tm)", or if it's because nobody's really using puma with SSL on Windows (chances puma core maintainers do are very slim) and it simply doesn't work, and nobody cares-kinda-thing.


add storage network docs

这个 PR 实现什么功能/修复什么问题:
add storage network docs
是否需要 backport 到之前的 release 分支:
NONE

/cc @swordqiu @ioito

/area docs

/area docs

Codecov Report

Merging #1423 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #1423      +/-   ##
=========================================
- Coverage    7.71%   7.71%   -0.01%
=========================================
  Files         408     408
  Lines       62368   62368
=========================================
- Hits         4813    4811       -2
- Misses      57152   57153       +1
- Partials      403     404       +1

Flag
Coverage Δ

#aFlag
7.71% <ø> (-0.01%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/util/seclib2/seclib.go
91.48% <0%> (-4.26%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d5f4e5e...270e025. Read the comment docs.

/lgtm
/approve


Value binding not working(iOS)

I bind value of TextInputMask like this:
value={this.state.phone === ""             ? null             : this.state.phone}
However it doesn't work. Value property is updated, but old text is still showing. Any ideas how to fix? I guess problem is with value being set to undefined in index.js :
 value={undefined}
https://github.com/react-native-community/react-native-text-input-mask/blob/2b60c445574f1a5be22872888cc7c76eead76783/index.js#L52
UPD: No, it's not in index.js. I think it's not even in javascript part.
UPD: Issue relates only to iOS. Works fine on Android. Should be somewhere in iOS native part. Need further digging

It's not working on Android for me. Value binding works normally with TextInput React Native component, but not with TextInputMask component...

If you change line 52 (node_module/react-native-text-input-mask), it's may work.
Like This
value={this.props.value}
It's work for me, and I could set a value to my TextInputMask Component

Actually you could use this
value={this.props.mask ? this.props.masked : this.props.value}
This way you will have fewer bugs, if you want maintain the Components that haven't mask


Add requirements.txt

Added simple requirements.txt for easy pip installation of dependencies and added a note in the README.md.

haha, I totally forgot to remove torch from requirements.txt; fixed it for now. Let me know if there any other changes you'd like to see.

@suryabhupa
Thanks for the quick fix, and thanks for the contribution!

Not at all -- thank you for this implementation! It's really wonderfully done; maybe I'll add on to the list of VIN implementations now too haha. :)


Add geo commands

Geo still incomplete Redis's command.
Sample:
GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
Our's implement:
public List radius(double d, double d1, double d2, GeoUnit gu);
public Map<V, Double> radiusWithDistance(double d, double d1, double d2, GeoUnit gu);
public Map<V, GeoPosition> radiusWithPosition(double d, double d1, double d2, GeoUnit gu);
public List radius(V v, double d, GeoUnit gu);
public Map<V, Double> radiusWithDistance(V v, double d, GeoUnit gu);
public Map<V, GeoPosition> radiusWithPosition(V v, double d, GeoUnit gu);
=> not have COUNT, ASC
Please full support!

Haven't seen COUNT and ordering ASC/DESC before. Seems like command format has been updated.
I'll add COUNT and ordering commands (ASC/DESC )

https://github.com/redisson/redisson/issues/662


Unify/simplify pickles variable names

This PR renames certain pickles variables for uniformity. For justification see https://github.com/o1-labs/proof-systems/pull/2811
Concretely:

xi (also known as polyscale and u) becomes polyscale
r (also known as evalscale and v and randomness) becomes evalscale

This PR is a no-op except for potential serialization backwards compatibility, which I will look into.

!ci-build-me

!ci-build-me

!ci-nightly-me

coverage: 33.188% (-28.9%) from 62.1%
when pulling 37a4f1bb8d5dd39efe353b455189d800c690c895 on volhovm/rename-pickles-vars
into 422c6958d954c4970063fbd0fe0dd5fecf3aeefc on compatible.

!ci-nightly-me

!ci-build-me


add devcontainer for setting up a GO development env, run the make deps and install other dependencies

i created this devcontainer for setting up a GO development env, run the make deps and preload a mongodb in a container. do I need to add the .devcontainer folder to the .gitignore or is it something that would be helpful for other contributors?
my initial stab -> https://github.com/dgcaron/infracost/tree/feat/vscode_devcontainer/.devcontainer
details on dev containers -> https://code.visualstudio.com/docs/remote/containers

Originally posted by @dgcaron in https://github.com/infracost/infracost/issues/870#issuecomment-884878747

Yeah, no I think it is not a big thing right now.
On Fri, 11 Feb 2022, 22:40 Ali Khajeh-Hosseini, @.***>
wrote:

Is this still needed? Since the issue was created we revamped the contributing
guide https://github.com/infracost/infracost/blob/master/CONTRIBUTING.md
and have switched to using Postgres for the Cloud Pricing API. I think all
of our team run the services locally during dev and I've seen a few
contributors use the docker-compose version of the Cloud Pricing API.
—
Reply to this email directly, view it on GitHub
https://github.com/infracost/infracost/issues/872#issuecomment-1036647048,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACKP6IBRHRCHJ4BYOZVAN5DU2V65BANCNFSM5AZ7E7GQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Awesome - thanks @dgcaron! btw, if you used the azure devops extension, we'd appreciate a review/star rating :)


Request Client Features and Enhancements

Is this a bug report?
No, it's a feature idea.

I've been working off the Mediator section in the documentation and I'm seeing this for dispatching messages that will wait for resposnes:
var client = mediator.CreateRequestClient<GetOrderStatus>();

var response = await client.GetResponse<OrderStatus>(new { OrderId = orderId });

I'm wondering if it would be nicer to simply provide message object with no type information on the response expected, and without always needing a client instance:
var response = await mediator.Send(new Order());

switch (response)
{
    case OrderStatus:
        // ...
        break;
    // ...
}

Pattern matching would jam pretty well with this
It would eliminate the need for the client object in between
Shorten the amount of boilerplate necessary to make calls

I don't know the internals of MassTransit, but I'm assuming the types involved on its API surface area can always be inferred through generic parameters or left as dynamic?  It might even be better for decoupling to not have the caller so concerned about the type of the response until it actually has one.  In the example above, having to specify <OrderStatus> seems redundant if the handler matching is done based on IConsumer<GetOrderStatus>?

MassTransit is type-based, and degrading itself to an object-based pattern matching approach doesn't really support how the underlying systems operate.
For instance, consumers consume by Type, and the response types are used to wire up handlers within the request client so that those responses can be delivered to the request client, and ultimately the GetResponse caller. It isn't possible to consume "all types" or "object", because there is no way to represent that in a message broker topology.
Mediator was built as a transport-free way to use MassTransit in the style that other mediator projects were built (such as MediatR, etc.), but using the exact same consumers, middleware, etc. that one would use in a broker-based project. Different solutions built on the same framework, think of it as a gateway to message-based systems.
I have been working on a way to improve the experience (read: trying to use C# 7, and now 9's pattern matching enhancements) for the post GetResponse experience, and what I have at this point is a work in progress and not ready for merging into the develop branch. It's really only significant for multiple response types, and unfortunately at this time needs to be backwards compatible with the tuple-based approach that was first created.
What I have so far, is something like:
var response = await client.GetResponse<T1, T2>(request);

if(response.Is(out Response<T1> response1))
{
}
else if(response.Is(out Response<T2> response2))
{
}

Any timeout, cancellation, or failure by the request's consumer would be surfaced in the await client... portion as it does today. The enhancements would just make it cleaner to dispatch based upon the response type received. The current code uses a tuple of Task<Response<T1>>, Task<Response<T2>>, which requires a bunch of awaits and such that obfuscate the response handling.
Plus, it's close enough to the is style of pattern matching without the overhead of object being in the middle (if there is any, I'm not sure there is but the tasks have to be checked at some point, either up-front to get to a single object or at the point of is, which is the approach I've taken above).

Appreciating that MassTransit's implementation is made using MassTransit concepts, the issue is that front-loading knowledge of handling does challenge some of the ideas behind the mediator pattern itself.
The degraded option is still desirable though.
So if I have this right, responses - by extension of clients - are more about queue addresses than they are about the subject matter of the messages themselves.
Perhaps what I actually want in MassTransit terms then is to create my own non-generic response type that is a wrapper for object.  That would give me a way to DRY the creating of the client as well.  But then the problem emerges that every single handler will be fired on every single message and will need to sniff that object to see if it needs to act or not.
Speaking only for the mediator implementation, it would be nice if it offered some non-generic overloads which smoothed away client details to offer this functionality.  It could still offer the familiar MassTransit interfaces, but for people looking for a classic :sweat_smile: mediator experience, the option would be there?

I think perhaps you may be missing the entire value of the MassTransit pipeline. The whole point is to avoid object, and dispatch using type information. That way, middleware, consumers, etc. are already down to the message type being consumed. The whole "is of type" is wasteful, C# is a heavily generic enabled language (with full runtime support, unlike Java which has lame generics).
The reality is, you have to know the types anyway. It's a type-based language. Have you looked through how requests work in the documentation?
And I don't see how object is a classic mediator experience – every other implementation uses types as well.

No, I'm pretty sure I understand and I understand reified generics pretty well having had to work with java recently :cry:.  What I'm talking about here is that there's a requirement to manually provide type information that is already available.
It's fine to register handlers of a type of message, but then why do I have to specify my type of message and type of response when dispatching?  Providing the message is enough and you can use generics to infer the type of the message by simply having it in the signature of the dispatch method:
public interface IDispatcher
{
    Task<object> Dispatch<TMessage>(TMessage message);
}

// later...
{
    IHandler handlers = LocateHandlers<TMessage>();
    handlers.ToList().ForEach((handler) => handler.Handle(message));
}

Having signatures like this spares people from having to bake so much intimacy up front. Again, I'm not disavowing types. In fact, the limitation being imposed right now is like as if it was being done in Java. :wink:
Once you get the return of Dispatch above, it really doesn't matter what comes back, let that be up to the developers.  They can always manually feed in the response type (and MassTransit can offer validation of such) on a separate overload.
Believe me, I love generics, but I don't think the current implementation is actually using them except to ask for redundant information. :pray:

I'm trying to understand how having object (or dynamic, another evil imho, particularly the .NET 4 dynamic type) makes the code any different and/or better? For request/response (which is the ONLY reason to use the request client), the caller needs to know what their response options are and differentiate based upon them to proceed. Typically using the results to either complete another response, or to update a database, etc. Some work needs to be done with those responses.
I can't depict a scenario where a response would then be dispatched again to more handlers. An event, sure, and that is fully supported to where a consumer could produce events that would invoke those handlers, etc. In fact, you can totally screw yourself with sagas by using send to invoke a consumer, and that consumer publishes an event, which is consumed by the same (locked) saga instance. Because it's all within the same execution context (albeit an async one).
Helping me understand the why and the value, with a real example, is the next step because I still don't see it. Maybe it's a mental model of how I think about communication between objects, but contracts are explicit and well defined to build well established conversations and expectations between service components.

Sorry, I corrected the dynamic, my mistake :laughing: - but I would disagree over object being outright evil.  I'll grab your points and questions and quote them if that's okay, more to just make sure I'm not skipping anything.
By the way, thanks for going through this discussion with me. :heart:

I'll limit my points to the scope of mediator functionality for now, but this is definitely desirable: The most generic, agnostic implementation that really only deals in IConsumer<...> types, by way of knowing the types of messages.

the caller needs to know what their response options are and differentiate based upon them to proceed

This conflates the caller with the mediator.  The caller can certainly still know and work with types as I'll show below, but why should the mediator care about the response type?  It's just an intermediary :wink:

I can't depict a scenario where a response would then be dispatched again to more handlers.

Not something I'm doing or hoping for here.

...with a real example...

I find it helpful to remember that object variables still retain their initialized types, that's part of the appeal of the recent pattern matching in C#, seen in my switch above. It doesn't strip type information, it's simply to say that you'll accept any type.
I'm also not presenting it as mutually exclusive either, it's usually straightforward to build a generic signature on top of an object implementation.
        [HttpGet]
        public async void Index([FromBody] ProjectIndexRequest request)
        {
            var mediatorRequest = mediator.CreateRequest(request);

            // Currently, not possible...
            // var mediatorResponse = await mediatorRequest.GetResponse</* ??? */>();
            // Ideally...
            object mediatorResponse = await mediatorRequest.GetResponse();
            // ...you get the `mediatorResponse` that you get, its type doesn't matter (yet!).

            // Now the type matters!
            switch (mediatorResponse)
            {
                case HandledByThing1Response:
                    // do stuff...
                    break;
                case HandledByThing2Response:
                    // do stuff...
                    break;
                default:
                    throw new Exception("Wat du?");
            }
        }

Again, the beauty here is that I can still leverage typing for the responses, it hasn't been lost by way of being object.  You can see this with HandledByThing*Response. It's just that it's all being done outside of the responsibility of MassTransit which doesn't need to involve itself in predetermining the type of the responses it receives from IConsumer<...> instances to perform dispatch and accrue response(s).
TMessage :point_right: IHandler<TMessage> :point_right: object (or IEnumerable<object> in pubsub) :point_right: switch :point_right: No loss of strong typing
So yeah, you're still getting explicit contracts, but without having to know the specific one. As per my last comment, you can still look up handlers using something akin to the IDispatcher psuedo I shared.

_I'll mention that mediatr has something akin to this, although I am more curious about MassTransit because I planned on using this library anyway and because this implementation doesn't require marker interfaces for messages. :+1: _

And, based upon that example, I see this as equivalent:
[HttpGet]
public async void Index([FromBody] ProjectIndexRequest request)
{
    using var request = mediator.CreateRequest(request);

    var response = await request.GetResponse<HandledByThing1Response,HandledByThing2Response>();

    if(response.Is(out Response<HandledByThing1Response> thing1))
    {
    }
    else if(response.Is(out Response<HandledByThing2Response> thing2))
    {
    }
    else
        throw new Exception("Wat du?");
}

The underlying support in MassTransit is based upon type, so there really isn't a way to routing any type to the response, only the types that MassTransit knows about will be routed to the request. It's just the way it is built internally, I don't see how it could translate otherwise.
And again, it's a good discussion that might lead to something mediator-specific, but it would break in the situation where a project was moved to using a bus/transport instead. Which leads to an inconsistent experience. That isn't to say it's impossible (it's code, nothing is impossible), it's just to say I don't see a practical way to do it with the existing message routing under the hood.

await request.GetResponse<HandledByThing1Response,HandledByThing2Response>()
This signature doesn't appeal as it forces one to provide a * number of responses.  Really, what if I only care about a subset? It ends up being repetitive boilerplate.  We know it's boilerpalte because response.Is(out Response<HandledByThing1Response> thing1) repeats each type in the generic parameters of GetResponse.

The underlying support in MassTransit is based upon type, so there really isn't a way to routing any type to the response, only the types that MassTransit knows about will be routed to the request. It's just the way it is built internally, I don't see how it could translate otherwise.

Again, I think I really have to emphasise this: You're not losing type information, you can still route.  But the only typing information you actually are using when routing is the type of the message.  Not of the response.  How can it?  The signature of IConsumer doesn't include the type of the response, so it's just there for the ride on the call-side.

This signature doesn't appeal as it forces one to provide a * number of responses.

It does, in fact, matter. If you don't specify one of the types, and the consumer responds with that type, the client will continue to wait until the request times out or is canceled. Because the type was never routed to the client, and therefore will never satisfy the request.
The client also under the covers connects a handler for Fault<TRequest> in the event a fault is published (which doesn't happen with Mediator, since it's executed inline and actually throws the exception all the way back up to the caller).

Again, I think I really have to emphasise this: You're not losing type information, you can still route. But the only typing information you actually are using when routing is the type of the message. Not of the response. How can it? The signature of IConsumer doesn't include the type of the response, so it's just there for the ride on the call-side.

No, but the RespondAsync<T>(T message) call does include the type, which is used to serialize and send the message, as well as filter through any middleware, observers, etc. that may have been built into the pipeline.
What you're suggesting is possible, though it would require a new request client since the behavior is completely different from the current one (and I won't break backwards compatibility in this case). It would behave differently, for sure. And would need to be supported identically whether using mediator or a bus/transport.

If you did have something akin to:
Response response = await client.GetResponse();
You could, in theory, then do something like
return response switch
{
    Response<Thing1> => blah,
    Response<Thing2> => blah,
    _ => throw new InvalidOperationException("well, boo.")
};

That would work pretty well - I think :laughing: -  I think I was forgetting about the Response<...> type that MassTransit uses, which I have no objection towards.  In fact, it's one thing I like as it gives me a context.
The syntax you have above, adapted a little and cheaply contextualized:
        [HttpGet]
        public async void Index([FromBody] ProjectIndexRequest request)
        {
            var mediatorRequest = mediator.CreateRequest(request);
            var mediatorResponse = await mediatorRequest.GetResponse();

            switch (mediatorResponse)
            {
                case Response<ProjectIndexResponse>:
                    break;
            }
        }

Maybe?

I think it would work that way, you could even do the:
case Response<ProjectIndexResponse> projectIndex when projectIndex.Length > 100
I think - any of the pattern matching solutions since Response<ProjectIndex> : Response would be a thing. and since Task is a future, it would be completed with the actual received type instead of an arbitrary type.

Yeah, always!  You'll always get a type, it's just that it's not codified explicitly through the mediator interfaces and has to be sniffed out to be handled. Let developers worry about what they get back, MassTransit's mediator APIs only need to do the ferrying around.
Just so I have it right, the Response in this case is a MassTransit.Response<...>?

Well, it would be something like:
public interface Response
{
}

public interface Response<T> :
    Response
{
}

Would Response not be MassTransit.Response<...>?  Or is this to facilitate a totally "pure" setup (my original suggestion).

Would Response not be MassTransit.Response<...>? Or is this to facilitate a totally "pure" setup (my original suggestion).

I don't know what Response<...> means, that's a generic type and the goal of this idea is to not get the type until pattern matching.

Specifically this one.

You'd only have that once you matched it to a Response<T>, the actual object type would be some internal class that implements that interface (as well as Response, which is the future return type).

I'm not sure I follow.  Doesn't MassTransit already have its own MassTransit.Response type?  Why can't that be used?

I'm not sure I follow. Doesn't MassTransit already have its own MassTransit.Response type? Why can't that be used?

No, it doesn't. A non-generic version does not currently exist.

Sorry, I meant the generic version.

I'm not sure I follow. Doesn't MassTransit already have its own MassTransit.Response<...> type? Why can't that be used?

It does, and it is used. Refer to the interface definition above, it would just add an additional non-generic version for the return from GetResponse.

(thanks for cleaning that up :wink: )
Aaaahhhh...  I see!  To facilitate the signature, gotcha.

Yes, it would be inserted between the two so that pattern matching would work (since it only matches based upon reference as it's a single object). There is no way to deconstruct to a single result (obviously).

So, following up, is this something that can be easily done?
(Cautiously: I'm open to contributing, but I wanna make sure I don't get into a situation where someone more familiar could do it faster, properly and with less hand-holding than me.)

The core changes are actually under the hood in the type-based message router, which I doubt many beyond myself have a full understanding as to how it works. The developer surface area is minimal, based upon the method signatures discussed earlier in the thread. As I've already been looking at moving the multiple response type support from a raw tuple to a specific type (with proper deconstruct methods to avoid breaking existing code), this is something I may look at in the same undertaking.

That sounds great, I really appreciate it.

I also noticed that there's a missing object signature for mediator.CreateRequest for using anonymous objects during dispatch.  Maybe that's something that can be added along the way too?

So one snag that I haven't figured out how to make work yet, is the way the type-based router dispatches messages.
The consume pipe on the mediator (and bus endpoint) is used by the request client. Before the request is sent, it connects handlers to the consume pipe, correlated by the RequestId, for each response type. The consume pipe dispatches messages to those handlers by type (ConsumeContext -> ConsumeContext -> handler).
This supports the full suite of MassTransit capabilities including filters (Middleware), observers, etc. And supports things like MessageData (claim check for large messages), etc. This needs to remain consistent.
The challenge with late binding the response type is that there is no ConsumeContext pipe coming out of the dynamic type router. Which means the response is not handled. Which in the case of a Respond from the consumer for a type that is not consumed will throw an exception and the entire call stack falls down.
So basically, the complexity goes up significantly for a very subtle syntax concern on the request client side. And given that complexity, I'm not likely to spend a lot of immediate brain power trying to figure out how to make it work at this point.

FWIW, I wouldn't describe this as a subtle syntax concern. Particularly if it's making this issue seem less valid. Forcing callers to know the type of the response ahead of time is equivalent to writing a service class from a coupling standpoint. It obviates the mediating aspect of the mediator pattern.
But yes, I'm sure there are underlying limitations in how MassTransit has worked up until now, but it sounds like a worthwhile improvement to support responses where the type won't need to be known.

I won't argue how important this is to you, I only know how important it is to me.
A contract between a service and a client is and should be explicit, which includes not only the request type, but the expected/allowed response types. It's a conversation, which includes messages in both directions.

That's a recipe for bidirectional coupling all the time.  But more importantly, that is not the philosophy behind the mediator pattern.

Philosophy? I'm sorry, but the mediator pattern has a very simple description.
It's a behavioral pattern, related to how objects interact. It doesn't change the fact that there are well defined contracts between the client and the mediated service that ultimately handles the request.
Unless you can provide an explicit, concrete definition of why eliminating the response types from GetResponse is critical, I will continue to "not see it." Every mediator framework I've seen includes the response type as part of the request definition, many don't even support multiple response types.

https://github.com/jbogard/MediatR/wiki#requestresponse
public class Ping : IRequest<string> { }

public class PingHandler : IRequestHandler<Ping, string>
{
    public Task<string> Handle(Ping request, CancellationToken cancellationToken)
    {
        return Task.FromResult("Pong");
    }
}

var response = await mediator.Send(new Ping());

Debug.WriteLine(response);

Well, it was a good conversation to explore the idea, and I did get a few ideas on how to better support pattern matching on the response, so that's a good outcome.

Haha, that's good!  :smile:
I'll still continue using MassTransit as well FWIW, I prefer not having to put markers on my message types.  And if something has to assert the response type, I'd rather it be at the call point.

I'm so deeply ingrained into MediatR.    Everything about specifying the response feels incredibly redundant to me as well.  If there was some kind of wrapper that mimiced MediatR's send pattern where the response type is known would be nice.  Not for a long term "correct philosphy" implementation, but simply as a starting point to migrating from that MediatR's pattern to masstransits pattern.
If this was there i could easily swap out the implementation with my other code, and slowly migrate my 50+ projects over to a defined response i suppose.
var result = await Mediator.Send(new MyRequest());  No reason why generics can't solve both issues if you have a typed request like mediatr's IRequest.

I'm so deeply ingrained into MediatR.

So, from re-reading this year+ old thread, the premise originally was the ability to not specify types. And that is something MassTransit doesn't support at all. Type-based routing is a core concept in MassTransit.
To clarify your comment, are you looking for an interface that has both the request type, and the response type combined into a single interface? Or what specifically? I have never used MediatR, so I'm not sure I completely understand the challenge in moving from it to MassTransit (others have stated it was an easy lift, others have expressed various concerns, but I have never understood them entirely).
Can you maybe post some code that explains what you mean, or something to help me understand?

Seems like IRequest<T> (in MediatR) is like Task<T>, in that it ultimately resolves to the response type without know the request type. And in that regard, you're pushing out a request of any time, with the ultimate goal of getting a response type of T back.

There is some differences in premise after re-reading ( i skimmed the first time).  For me its more of a syntax sugar.  To add basically a small extra layer above your "class" constraint.  Probably could be an extension method.
This does the trick for me.
    public interface IRequest<out T>
    {

    }
    public static class MassTransitMediatorExtensions
    {
        public static async Task<TResponse> Send<TResponse>(this IMediator mediator, IRequest<TResponse> request, CancellationToken cancellationToken = new CancellationToken()) where TResponse : class
        {
            var response = await mediator.CreateRequest(request).GetResponse<TResponse>();
            return response.Message;
        }
    }

And my test looks like this

        var result = await  _massTransitMediator.Send(new MyQueryRequest() // Implements IRequest<QueryResponse<BLABLA>>
        {
            Navigation = new Navigation()
            {
                Take = 10
            }
        });

I was able to do this myself.  But my be a nice addition for those moving from mediatR just to get it done a bit faster.  I have IRequest on all of my "Contracts".  So this simple extension method removes ALOT of work.  But it took me a second to work out how it would work with mass transit.
Thanks, Sorry for digging up an old post.

Oh, interesting, so you're actually sending IRequest<TacoOrder>, and getting back Tacos. And your consumer would then be:
public class Consumer :
    IConsumer<IRequest<TacoOrder>>

?

I'm using
public class Consumer : IConsumer<MyQueryRequest> {

}

Which may not work depending on how mass transit's CreateRequest(request) works.  Does this seem valid to you?  I'm working on a test for it, but haven't got it working just yet.

That won't work unless you change out the consumer type since it's type-based.

Weird, my test is working though :p

FR? post the code you're using that works.

Here is the full Unit test i use xUnit
using System.Collections.Generic;
using System.Threading.Tasks;
using MassTransit;
using MediatR;
using Microsoft.Extensions.DependencyInjection;
using Newtonsoft.Json;
using Xunit;
using Xunit.Abstractions;
using IMediator = MassTransit.Mediator.IMediator;

namespace MassTransit.Tests;

public partial class MassTransitTest
{
    private readonly ITestOutputHelper _testOutputHelper;

    public MassTransitTest(ITestOutputHelper testOutputHelper)
    {
        _testOutputHelper = testOutputHelper;
    }

    [Fact]
    public async Task TestExtensionMethod()
    {
        var services = new ServiceCollection();
        services.AddMediator(cfg =>
        {
            cfg.AddConsumer<QueryConsumer<MyQueryRequest>>();
        });
        var provider = services.BuildServiceProvider();
        var mediator = provider.GetRequiredService<IMediator>();

        var result = await mediator.SendRequest(new MyQueryRequest());
        _testOutputHelper.WriteLine(JsonConvert.SerializeObject(result));
    }
}

public class MyQueryResponse<T>
{
    public List<T> Items { get; set; }
}
public class MyQueryRequest : IRequest<MyQueryResponse<string>>
{

}
public interface IRequest<out TResponse> : IBaseRequest { }
public class QueryConsumer<TQueryRequest> : IConsumer<TQueryRequest> where TQueryRequest : class
{
    public async Task Consume(ConsumeContext<TQueryRequest> context)
    {
        await context.RespondAsync(new MyQueryResponse<string>()
        {
            Items = new List<string>()
            {
                "A", "B"
            }
        });
    }
}
public static class MassTransitMediatorExtensions
{
    public static async Task<TResponse> SendRequest<TResponse>(this MassTransit.Mediator.IMediator mediator, IRequest<TResponse> request) where TResponse : class
    {
        var response = await mediator.CreateRequest(request).GetResponse<TResponse>();
        return response.Message;
    }
}

Coming back to this quite some time later, but I ended up building my own lightweight mediator that is able to dispatch without requiring any base types.
To be honest, it's not that it's type-less, it still uses types internally.  I still don't see why MassTransit couldn't have a simplified .Dispatch(object) signature.  It's more than possible to pull the types out of an object at runtime using reflection.  That would satisfy whe MT needs for how it organizes queues?

Yes i agree atrauzzi. I'm now running into the problem where i'm trying to CreateRequest(object) and GetResponse<> with an object type.  Currently there is no way to do this without some nasty reflection.  I have access to request object type and response object type, but no overload to use them.  The types are there, but i can't call unless i explicitly state in code which is just annoying
My scenario is i'm using Blazor WASM.  I share contracts between client and server.
I use Json Serializer to serialize the contract and send from the browser client, then it sends to a generic controller that reads the request body and deserializes into the actual type.  From here I can't do anything without nasty reflection.  There are 100 CreateRequest overloads which makes it even more complicated to find in reflection.  I just want to send the request object and let mass transit discover the type via.  requestObject.GetType()

A GetResponse(Type responseType) should do the trick as well.

Yes i agree atrauzzi. I'm now running into the problem where i'm trying to CreateRequest(object) and GetResponse<> with an object type. Currently there is no way to do this without some nasty reflection. I have access to request object type and response object type, but no overload to use them. The types are there, but i can't call unless i explicitly state in code which is just annoying
My scenario is i'm using Blazor WASM. I share contracts between client and server.
I use Json Serializer to serialize the contract and send from the browser client, then it sends to a generic controller that reads the request body and deserializes into the actual type. From here I can't do anything without nasty reflection. There are 100 CreateRequest overloads which makes it even more complicated to find in reflection. I just want to send the request object and let mass transit discover the type via. requestObject.GetType()

Just as nasty, but using dynamic as the type instead of object for the request works!


✨ Spike - Investigate AI quiz assessment

[Content from email - subj: SSW Rewards (at first) - AI Quiz assessment]
[Note: Successful completion of this spike would be Proof of Concept - Phase 1]
to: @adamcogan
cc: @tkapa @lukecookssw @zacharykeeping
Hi Adam
As per our conversation on Teams, you have approved a tech spike to evaluate the viability of this idea, with a view to having a v1 in SSW Rewards by NDC.
Tylah is already allocated to SSW Rewards so will work on this (Zach and I will continue to focus on the new UI). You have also approved Cookie to work on this with him (note that he has a booking coming up but could work on this in the meantime).

Do you approve any additional resources

Looking at booked in days to consider options:
a.	⚠ Calum – booked but we would consult with him and potentially get him to help on the days he is available
b.	❌ Brady – worked on RulesGPT but is on leave
c.	⚠ Dan M – available but don’t know if he has any experience or interest (does not have Keen to Learn for AI)
d.	⚠ Gordon - available but don’t know if he has any experience or interest (does not have Keen to Learn for AI)
e.	❌ Harry – worked on RulesGPT but is on leave
f.	✅ Isabel – has availability and I understand has worked with AI already
As you can see from the timeline below, this is ambitious so ideally we can use the right people on this. We will need to rapidly prototype and build – after the proof-of-concept phase we can review the architecture and build as a long-term solution.
I tried to catch you on Teams to approve this email but you were unavailable. Once you have approved other people to work on this I will loop them in.
Hi Luke and Tylah

Please start working on this tomorrow

To myself

Create an architecture diagram.
Make a video explaining the concept.

The concept
•	We currently have quizzes in SSW Rewards with multiple choice questions.
•	We want to replace this with question only – and a natural language freeform text field for the reply.
•	An AI will evaluate the provided question and answer, and provide a response indicating whether the given answer is correct or incorrect.
•	Ideally the response would look something like this:
{
    question: “the given question”
    answer: “the given answer”
    isCorrect: [true/false]
    explanation: [Markdown reply from AI explaining why the answer is correct or incorrect]
    confidence: [0 – 1]
}

•	If the answer is correct – award the point for the question.
•	If the answer is incorrect, don’t award a point for the question.
•	Within the app, for any incorrect answer, we will display a Dispute button.
•	When a user disputes a question, if the confidence is below a prescribed threshold (e.g. 70%) we will award them the point.
•	If the confidence is above that threshold, we will notify someone (TBD) who will review the question and answer and decide whether or not to award the user the point.
=== Tomorrow ===
Proof of concept – phase 0
•	No code
•	Use ChatGPT – give it a series of given questions and answers and ask it to determine whether the provided answer is correct or incorrect, and give an explanation.
Proof of concept – phase 1
•	Build a command line tool to evaluate the questions and answers.
•	Use Azure services.
o	TBD – I don’t know what the right service is here.
•	Build the data model.
•	Demonstrate that it works.
Proof of concept – phase 2
•	Integrate into SSW Rewards.
•	Run it as its own service rather than built-in; have SSW Rewards query it over an API.
⬇            ⬇            ⬇            ⬇
=== NDC SYDNEY 2024 ===
The future
•	Integrate into SugarLearning.
•	Use natural language assessments to determine whether someone has understood an item and/or module.

Closing
As per @lukecookssw conversation with @adamcogan,  he has approved us to work on this for NDC.
See the email;  RE: SSW Rewards (at first) - AI Quiz assessment


Enable resource pack loading in Dragonfly

This should be a fairly trivial task: Some configuration in the config.toml, loading resource packs probably from some designated new folder. Gophertunnel already has the API necessary for loading and sending resource packs.

PR open! let me know if there's anything to fix!!!


Coalesce develop

Per-lang translation loader and file coalescer
link react-scripts in in a frontier react app to test

Note:
cra template gitignore contains /dist and not dist, so most apps that haven't deviated will see these generated locale files in their src and unstaged diffs if they run build locally
https://github.com/fs-webdev/cra-template/blob/master/template/gitignore#L15

closing this PR in favor of the "real-deal" PR as per Tyler's instructions.


stack: add dhcrelay giaddr control behaviour

Description
Introduce presentGIAddr to control the handling of incoming DHCPv4 packets which already contain relay agent options.
Why is this needed
When there are more relay agents - having append would result in multiple Agent-Information.

I put more information as a comment in the values file. My experience was with Broadcom that I had a relay agent there and the agent expected the DHCP reply to have the same option (82) as it was sent. So I needed to change this to forward to keep this working otherwise the DHCP reply would not be accepted.


Upgrade Lodash to avoid npm update security issue

npm update reports a security vulnerability tied to this Lodash issue. Upgrading Lodash to >=4.17.5 would solve this problem.

We don’t use any of the vulnerable methods mentioned in that issue, so npm audit is wrong to report it - it’s a false positive.
Since we use a semver range on lodash, a fresh install should give you the latest version already, with no action needed here.

Sorry about this, you're right. I'm having some hard time wrapping my head around npm audit. This seems like there are some issues. If I only install eslint-plugin-import as sole dependency, it gives no warnings, but if other dependencies install the wrong version of Lodash, then it seems to complain about eslint-plugin-import as well. Sorry!


How does nuttx link its own static libraries

How does nuttx link its own static libraries？

Hi @zhutouwangzha currently the build system doesn't implement the idea of its own static or share library for each library. So, the .o files from a library are used directly the programs that need it.
There are many examples in the nuttx-apps/, please take a look at apps/examples/gps sample, it uses minmea as "library"


Render camel case in responses

REDMINE-17304

Coverage remained the same at 98.99% when pulling 4a658f9cac92c38e0f40b35ca333e12647d3ee86 on DanielKuhn:render-camel-case-in-responses into b792b9dec77078c9f4c7caa2534851360eac7831 on codevise:master.

changes will be included in #1288


feat: add crossorigin for normal ssr

Types of changes

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

Description

Resolve https://github.com/nuxt/nuxt.js/pull/6635
Resolve https://github.com/nuxt/nuxt.js/issues/6634
Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly. (PR: #)
[ ] I have added tests to cover my changes (if not applicable, please state why)
[ ] All new and existing tests are passing.

Vue PR https://github.com/vuejs/vue/pull/11094

Codecov Report

Merging #6950 into dev will decrease coverage by 0.07%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##              dev    #6950      +/-   ##
==========================================
- Coverage   62.66%   62.59%   -0.08%
==========================================
  Files          82       82
  Lines        3300     3304       +4
  Branches      898      896       -2
==========================================
  Hits         2068     2068
- Misses        989      993       +4
  Partials      243      243

Flag
Coverage Δ

#unittests
62.59% <0%> (-0.08%)
:arrow_down:

Impacted Files
Coverage Δ

packages/vue-renderer/src/renderers/modern.js
0% <0%> (ø)
:arrow_up:

packages/vue-renderer/src/renderers/ssr.js
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 59f128a...ed02616. Read the comment docs.


Fix alloca on FreeBSD

Fix compile errors on FreeBSD.

alloca is defined in stdlib.h on freeBSD
Issue in godot

@mundusnine thanks!


Refactor get_diagnostics

This PR refactors get_diagnostics:

remove return statements from map (it's a bit confusing because return doesn't return from the function)
Moves the writers @info statement  intoget_diagnostics

This is a baby-step from #2643.


Building Snap fails on the release pipeline

What's up?
The build-and-publish-snap job fails on the release pipeline.
https://github.com/PRQL/prql/actions/runs/6863024094/job/18661935807#logs
I don't know why.
By the way @max-sixty can you look when you're logged in on the Snapcraft website if it is possible to set some metadata such as the license and add some links the PRQL website and GitHub?

Good spot — it looks like the snap is being built in a context with an older version of rust. Do you know what that is? Can we install a newer version of rust in that context?
Our general tests are built in a plain GHA image, and update automatically. So maybe that's in a docker container?

By the way @max-sixty can you look when you're logged in on the Snapcraft website if it is possible to set some metadata such as the license and add some links the PRQL website and GitHub?

I added the website (though it won't let me add two websites, so I'm not sure I can add the GH)
But if I add the license, it will stop using the metadata we supply programmatically. Could we instead update our snap definition?

Good spot — it looks like the snap is being built in a context with an older version of rust. Do you know what that is? Can we install a newer version of rust in that context?
Our general tests are built in a plain GHA image, and update automatically. So maybe that's in a docker container?

I think Snapcraft doesn't use Docker, I think it uses a container manager called LXD which manages LXC containers which is a Linux technology for containers, and unlike Docker the containers are always Ubuntu.
I found:
https://github.com/qarmin/szyszka/blob/master/snap/snapcraft.yaml
Which ran into the same problem and solved it by having declaring in the Snapcraft YAML file to use Rustup to install the latest version of Rust.

But if I add the license, it will stop using the metadata we supply programmatically. Could we instead update our snap definition?

Our Snapcraft YAML file:
https://github.com/PRQL/prql/blob/main/prqlc/packages/snap/snapcraft.yaml
Declares the license and other metadata, but I don't know why it doesn't get picked up on the Snapcraft website.

I don't know why it doesn't get picked up on the Snapcraft website.

I don't think it's successfully published for a while — let's reassess after the next successful publish?


Create a printable/downloadable report for a census tract

See #1606 for what was tried on the FE on this already

duplicate of #1606


GEM uses memory data in active training set and updates memory twice

The GEM implementation here inherits from Naive_Rehearsal and calls super(GEM, self).learn_batch(train_loader, val_loader). It therefore uses the learn_batch method of Naive_Rehearsal which uses memory data together with the new data to compute the original gradients before checking conflicts with any memory gradients. From my understanding that is not the intent of the original paper and might affect the training results.
Additionally, Naive_Rehearal's learn_batch method already updates the memory and task_count, but GEM does this a second time once the call returns.

Thanks for pointing out the differences! You are right that the GEM class should not inherit the Naive_Rehearsal class. I will fix this and check how it impacts the performance.

hi I wanted to know if this issue is still fixed?

As far as I can tell neither the code nor the results were updated.

I see. So I made a simple change - added a boolean argument to NaiveRehearsal using it by passing correction=True: This also prevents repeated update of the memory. Is this implementation correct or have I missed something?
def learn_batch(self, train_loader, val_loader=None, correction=False):
        if correction:
            super(Naive_Rehearsal, self).learn_batch(train_loader, val_loader)

Sorry for the late update. The duplicated memory operation in GEM has been removed. Its performance is the same. In the case of split-MNIST-incremental-class, the average accuracy is 92.07+-0.32 (new) versus 92.20+-0.12 (previous result).
I also added the GEM_orig to match the process in the original GEM paper, which does not include the memory data to calculate the new gradients. The GEM_orig is slightly lower than our implementation (91.32+-0.11 versus 92.07+-0.32).

Great. Thanks for the update!


Ncurses backend outputs a black screen in tty

Platform: Linux, tty (no display server)
Helllo! It's my first time trying out this library. While testing, i found out that the default backend outputs a black screen.
Setting Application.UseSystemConsole = true; fixes it, but the CPU isage spikes up to 100%, which is not something i'd want.
After testing with ssh in gnome-terminal on my desktop, i can observe that the default backend is MUCH faster than the System.Console backend (as expected)
I don't think it's an ncurses issue as other tools that use it work just fine (alsamixer)
Is this a known issue?

Hi, thanks for reporting this.  It should be fixed with the next nuget release ( https://github.com/migueldeicaza/gui.cs/pull/1549 ) which was merged 24 hours ago and should (I think) go live on NuGet soon.

yes, the high CPU usage is gone. I guess this issue is also not really that useful to fix as you aren't going to use mouse in tty anyway...

Glad that the CPU problem was resolved.
Usually odd colors (or all black) is an issue with $TERM not being set correctly.  See this thread for example:
https://github.com/migueldeicaza/gui.cs/discussions/1455#discussioncomment-1373575


Refactoring

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (ee67273) 70.53% compared to head (ad1efe0) 70.53%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #468   +/-   ##
=======================================
  Coverage   70.53%   70.53%
=======================================
  Files          72       72
  Lines       15297    15297
  Branches     1920     1920
=======================================
  Hits        10790    10790
  Misses       2614     2614
  Partials     1893     1893

Impacted Files
Coverage Δ

src/renderer/players/usi.ts
47.59% <100.00%> (ø)

src/renderer/store/mate.ts
42.05% <100.00%> (ø)

src/renderer/store/record.ts
66.80% <100.00%> (ø)

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 in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


upgdate cert-manager.io/v1alpha2 to cert-manager.io/v1

Motivation
cert-manager v1.6.0 was recently released.  And this version removed many alpha/beta API versions which had been deprecated for a long time.
What The PR Change
The PR updates cert-mangager related API versions in the manifests from cert-manager.io/v1alpha2 to cert-manager.io/v1
Compatibility
cert-manager.io/v1 was introduced at cert-manager v1.0.0 released on September, 2020.  Thus, I believe most users can apply the manifests.
Test
I confirmed the manifests works on kind cluster (kubernetes v1.21) because kubernetes v1.22 includes API removal of admissionregistration.k8s.io/v1beta1 (#17 can cover this).
See the gist for detail.

Will test this along with other PR and post the results.

/lgtm


Specify the plugin id in package.json

The plugin ID should be specified under the "id" key of your package.json. The manifest.json file is generated on-demand, and any changes made to the file will get overridden by the build-figma-plugin CLI.

Thanks so much for flagging this!


CRUD function to Check if value exists in a MySQL database

Hello ,
can you add an CRUD function  to Check if value exists in a MySQL database
?Thank you in advance

A very generic check can be very complex due to the different data types (string, boolean, int, float etc.). I think it would be easier to implement an individual query yourself that is perfectly customized to your individual needs.