Pluaralize ComputePolicies operation group

This was missed during initial swagger review. This new group should by
pluralized since it also contains an object called "ComputePolicy"
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@amarzavery I do not believe this has resulted in anything being published yet, so this should not be a breaking change. I have not triggered any publish jobs and the AutoRestCI PRs triggered from the original change (https://github.com/Azure/azure-rest-api-specs/pull/1182) are both still open, so we should be good to merge this and then publish from these changes.


Ledger Transaction module unit test

Description
Add unit tests and mock implementation for Ledger Transaction

Related Issue
N/A
Contains #62 #60 #59 #58

Testing
cargo test & make code-coverage

Breaking Change

[ ] Yes
[X] No

Screenshots (if applicable)
Checklist:

[X] I have read and followed the CONTRIBUTING guidelines for this project.
[X] I have added or updated tests and they pass.
[X] I have added or updated documentation and it is accurate.
[X] I have noted any breaking changes in this module or downstream modules.

Closing. See mockall version instead. See #70

Closing. See mockall version instead. See #72


parametrize CallbackLogic in CallbackController

For some reason org.pac4j.play.CallbackController has a hardcoded CallbackLogic:
private CallbackLogic<Result, PlayWebContext> callbackLogic = new DefaultCallbackLogic<>();

Callback logic can be set in org.pac4j.core.config.Config:
public void setCallbackLogic(final CallbackLogic callbackLogic)

but it is not used.
It would be great to be able to parametrize the callbackLogic, parhaps to read it from config after it is injected.

probably related with https://github.com/pac4j/play-pac4j/issues/242 because config is injected

Generally, you only have one CallbackController and thus one CallbackLogic. This is a bit strange to be able to set the CallbackLogic at the Config logic, I honestly don't remember the reason behind this design.
Do you really have a use case for that?

@leleuj The only reason we have only one CallbackController is just that it delegates the real work to CallbackLogic. There is no need for extra abstraction interface CallbackLogic while we do not allow user to change it. The main purpose of Strategy Pattern is to be able to change the logic at a runtime.
In my current prod project, I've created a custom MyCallbackLogic extends DefaultCallbackLogic[Result, PlayWebContext] that a bit modifies redirectToOriginallyRequestedUrl (to support redirection to SinglePageApplications that are deployed on a separate domain). And just because CallbackController has a hardcoded logic I had to create my custom MyCallbackController. So I create 2 classes instead of 1. More of that I have to extend Java-based play.mvc.Controller in my Scala code just because PlayWebContext requires Java-based play.mvc.Context
Actually the same logic for LogoutController and DefaultLogoutLogic
If you agree that we should be able to change the default logic I could prepare a pull-request.


Is this a situation that need to use getDerivedStateFromProps

Read the docs https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html and I want to clarify if my situation falls outside the recommended solutions.
Goal: Display a list of filter options ('group 1', 'group 2', 'group 3', etc...) with checkboxes, and when the selections are changed, refresh the list of items displayed to only include the items that belong to the selected groups.
The list of groups is not static and varies by logged on user and is retrieved thru an API.
Current Implementation:
I have a container component that interacts with redux middleware and gets the list of groups (as props) from an api call.
I have in my local state a list of groups set to an empty array - 'groupFilters'.
API call is being made (type - REQUEST) in componentDidMount() and when the response is received, the state change is handled in componentWillReceiveProps(). When the nextProps are not same as current props, I am updating the state by pushing all the groups that I got back from API response to the groups array in my local state. **Reason for local state is that, API response is [{id: 1, group: 'abc'}, {id: 2, group: 'xyz'}, etc ]. But what is displayed as filter options is just group name.
When user changes the filter options, I am handling the change by updating 'selectedGroups' list which is also in my local state. I am using selectedGroups and groupFilters to reconcile and display the checkboxes as checked or unchecked.
Code:
`
export class MyContainerComponent extends Component {
state ={
selectedGroups: [],
groupFilters: [],
}
componentDidMount () {

    const { getGroups } = this.props;

    getGroups(**someparams**); //API call - Redux Action Creator
}

componentWillReceiveProps (nextProps) {

    if (nextProps === this.props) return;

    const { data } = nextProps;

    // filter options should only display group names
    filter(data, (item) => options.push(item.groupName));

    this.setState({
        groupFilters: options,
        selectedGroups: options
    });
}

handleGroupSelect = groupName => (event, checked) => {
    let selectedGroups = [...this.state.selectedGroups];

    if (checked) {
        selectedGroups = groupName === 'All Groups' ? this.state.groupFilters : selectedGroups.concat(groupName);
    } else {
        if (groupName === 'All Groups') {
            selectedGroups = [];
        } else {
            if(indexOf(selectedGroups, 'All Groups') > -1) {
                selectedGroups.splice(indexOf(selectedGroups, 'All Groups'), 1);
            }

            if (indexOf(selectedGroups, groupName > -1)) {
                selectedGroups.splice(indexOf(selectedGroups, groupName), 1);
            }
        }
    }

    this.setState({ selectedGroups });
}

render () {
    const { isFetching } = this.props;

    return (
        <div>
            { !isFetching &&
            <MyDisplayComponent
                groupFilters={ this.state.groupFilters }
                onGroupSelect={ this.handleGroupSelect }
                selectedGroups={ this.state.selectedGroups }
            /> }
        </div>
    );
}

}
const mapStateToProps = ({ api: { userGroups = [] } }) => {
const { data = [], isFetching = true } = userGroups;
return { data, isFetching };
};
export default connect(mapStateToProps, Actions)(MyContainerComponent);
`
Question about Proposed Change: Can I change this implementation to use getDerivedStateFromProps and componentDidUpdate methods instead? I maybe missing some things here, but memoization and controlled/uncontrolled component options doesn't seem to solve the cases where the props are not being passed from a parent component and are instead received thru redux mapDispatchToProps calls.
Please let me know your thoughts.

A good rule of thumb is that if the derived state is a pure function of props and not a mix of the previous state and props, you probably don't need derived state. Instead you can:

Compute derived values (like transforming data from one shape to another) in render. If this is expensive and you need to store old values you might consider using a memoization library like lodash.memoize or memoizeOne instead of using React state.
Do the work in the parent component or Redux store. Libraries like reselect help with this.

I maybe missing some things here, but memoization and controlled/uncontrolled component options doesn't seem to solve the cases where the props are not being passed from a parent component and are instead received thru redux mapDispatchToProps calls.

In your case the "parent component" is the component created by the Redux connect function which transforms Redux state into props for your component. You can use the mapStateToProps option to transform the Redux state shape into something else if you need to.: https://redux.js.org/basics/usagewithreact#implementing-container-components


Installing yaml help

Hi Mark, please as some help in the Readme.md about installing yaml, since its required by some of your scripts, and is not installed by default in all computers.
I tried to install it, but was unsure which one to pick, since there are 3 option available:

PyYAML        # YAML 1.1, pure python and libyaml binding
ruamel.yaml   # YAML 1.2, update of PyYAML with round-tripping of comments
PySyck        # YAML 1.0, syck binding

It's pip install pyyaml.

pip: command not found :)

haha!
Either sudo easy_install pip or, probably more straight forward sudo easy_install pyyaml.
I think the easy_install is going in your mac root and pip is installing just for your user. Also, I never tried the latter easy_install command.

Thanks Lase!
sudo easy_install => error: No urls, filenames, or requirements specified (see --help)
sudo easy_install pyyaml => Installed!

Hey folks,
Oh jeez, there I was thinking pyaml was 'batteries included'. This raises and interesting point. The majority of people who will use this tool will not understand Python dependencies such as easy_install or pip. It will make everyone's lives easier if we only use the Python standard library. I also don't like polluting my system Python etc... or this happens ;)
I will think of something but this is a very good issue. Thanks Pablo

just use json?

Right commit 08ebb23 now uses json.


On Windows with Cygwin, owltools doesn't work in the combination "Cygwin shell, Windows java"

From<EMAIL_ADDRESS>on October 11, 2014 08:33:45
<b>What steps will reproduce the problem?

I have the following shell:

GNU bash, version 4.1.17(9)-release-(x86_64-unknown-cygwin)

I have the following Java:

java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)

I downloaded the owltools script and owltools-runner-all.jar.

Java, when started from the script, doesn't find the JAR because of path syntax confusion.

The following fixes helped.  Note that I also deleted the setting of java.library.path, as ../lib didn't exist in my environment with the above downloads.

--- owltools.orig	2014-10-11 17:23:24.929368900 +0200
+++ owltools	2014-10-11 17:22:59.057509400 +0200
@@ -18,7 +18,12 @@
# failure message will make a little more sense.
# JAVAPATH="java"

-PATH_SEP=":"
+if [ "uname -o" = "Cygwin" ]
+then

PATH_SEP=";"
+else
PATH_SEP=":"
+fi

JAVAARGS=" "
CMDARGS=" "
@@ -27,6 +32,14 @@
PATH_TO_ME=which $0;
PATH_TO_ME=echo $PATH_TO_ME | sed -e "s/\(.*\)\/.*/\1/g"

+if [ "uname -o" = "Cygwin" ]
+then
LAUNCHER_DIR="$PATH_TO_ME"
+else
LAUNCHER_DIR="cygpath --mixed $PATH_TO_ME"
+fi
+
+
# Just the name of the script.
SCRIPTNAME=echo $PATH_TO_ME | sed -e "s/.*\/\(.*\)/\1/g"

@@ -63,6 +76,10 @@
DEREFERENCED_CLASSPATH=ls -1 -L $PATH_TO_ME/$ARG | grep -v ontologyrelease
for CP_ENTRY in $DEREFERENCED_CLASSPATH
do

   if [ "`uname -o`" = "Cygwin" ]

   then

       CP_ENTRY="`cygpath --mixed \"$CP_ENTRY\"`"

   fi

if [ -z "$CLASSPATH" ]
then
CLASSPATH="$CP_ENTRY"
@@ -102,7 +119,7 @@
fi

## Assemble and run the final command.
-CMD="$JAVAPATH -Xms2048M -DentityExpansionLimit=2048000 -Djava.awt.headless=true -Djava.library.path=$PATH_TO_ME/../lib -classpath $CLASSPATH -DlauncherDir=$PATH_TO_ME $JAVAARGS owltools.cli.CommandLineInterface $CMDARGS"
+CMD=""$JAVAPATH" -Xms2048M -DentityExpansionLimit=2048000 -Djava.awt.headless=true -classpath "$CLASSPATH" -DlauncherDir="$LAUNCHER_DIR" $JAVAARGS owltools.cli.CommandLineInterface $CMDARGS"

## DEBUG
## Let's see a little of the environment if we declare DEBUG=1.

Original issue: http://code.google.com/p/owltools/issues/detail?id=104

From<EMAIL_ADDRESS>on October 11, 2014 09:06:18
This issue was closed by revision r2384 .
Status: Fixed

From<EMAIL_ADDRESS>on October 11, 2014 09:09:00
This issue was closed by revision r2385 .

From<EMAIL_ADDRESS>on October 11, 2014 09:11:55
Thanks! Unfortunately uname doesn't accept -o on OS X
{{{
DESCRIPTION
The uname utility writes symbols representing one or more system characteristics to the standard output.
 The following options are available:

 -a      Behave as though all of the options -mnrsv were specified.

 -m      print the machine hardware name.

 -n      print the nodename (the nodename may be a name that the system is known by to a communications network).

 -p      print the machine processor architecture name.

 -r      print the operating system release.

 -s      print the operating system name.

 -v      print the operating system version.

 If no options are specified, uname prints the operating system name as if the -s option had been specified.

}}}
I switched this for plain "uname", which yields "Darwin" on OS X and "Linux" on Linux, hopefully works for cygwin

From<EMAIL_ADDRESS>on October 11, 2014 09:12:24
I also inverted the second test, as I think you made a typo there

From<EMAIL_ADDRESS>on October 11, 2014 09:52:11
Thanks for your quick response!
You are right about my second test.
Plain "uname" returns CYGWIN_NT-6.3 for me, i.e. it includes the Windows version.
With bash it would be easy to test for this, using [[ "uname" == CYGWIN* ]].
BTW I made further modification.  I like to use a ~/tools/bin directory containing symlinks to all kinds of tools, including /path/to/owltools/owltools.  Therefore I enabled the owltools script to find its own path in such a situation (using readlink).  (BTW in the presence of the DIRNAME variable it's not necessary to once more determine PATH_TO_ME.)
Please find attached my latest version; hope it works for you.
Attachment: owltools


Unable to export drawio diagram using the CLI

Describe the bug
It is impossible to export diagrams via the drawio CLI.
When running the export command it ends up with the following message:
Error: input file/directory not found
Steps To Reproduce
Steps to reproduce the behavior:

create a drawio diagram
run drawio  -x -f svg -o /tmp/foo.svg ./foo.drawio

Expected behavior
A svg file is output.
Screenshots
N/A
Additional context
Installed from stable channel. Running wayland. The graphical version is working correctly
Notify maintainers
@alyssais @DarkOnion0
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 system: `"x86_64-linux"`
 - host os: `Linux 6.4.8-xanmod1, NixOS, 23.05 (Stoat), 23.05.20230822.a16f7eb`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.5`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Can't reproduce, I'm afraid.  I ran:
nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/tarball/a16f7eb -p drawio --run 'drawio -x -f svg -o /tmp/foo.svg ./stack.drawio'
And it worked fine.

Are you running wayland?

Yes, sway 1.8.1.  Do you think that would make a difference to whether it finds the input file?

Can't reproduce, I'm afraid. I ran: nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/tarball/a16f7eb -p drawio --run 'drawio -x -f svg -o /tmp/foo.svg ./stack.drawio' And it worked fine.

Me neither (I just took your command and changed the input file path). I'm also running sway 🤷.

Found the problem.
I suppose you are running using xwayland.
Try setting NIXOS_OZONE_WL to use the native wayland electron version. The parameters is not added correctly by wrapper so we have an issue.

Yep, I can reproduce with NIXOS_OZONE_WL.

Indeed, I'm running XWayland and when I launched the app with NIXOS_OZONE_WL=1 the app failed to convert to svg. This issue could be linked to the one you already open for drawio crashing under Wayland and more globally the whole mess around electron breaking.
I will push the last update soon, let me know if it resolves the problem.

for now as a work around, we can run it as a xwayland client right?
env -u WAYLAND_DISPLAY drawio ./hello.drawio.png

this is working for me... though it's blurry because it's using xwayland..


Reduce the height on the cookie notification for mobile screens

Noticed by @moraru.
The height of the cookie notification needs to be constrained, such as maxHeight: min(900px, calc(100vh - 2rem)) so that it can't be larger than the size of the screen.
This needs to be added at https://github.com/biosimulations/biosimulations/blob/0c1c222ee63a0e36857b93085f027c7f12fd41f7/libs/analytics/angular-analytics/src/lib/consent.service.ts#L51

:tada: This issue has been resolved in version 9.1.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Two-digit number labels cut-off

Some wider two-digit numerical labels get cut-off slightly along their right edge. Observed this issue on the web version. Let me know if you need to a screenshot to clarify.

Please tell me on which numbers you observed this behavior. You can paste a SGF file here directly.

This is a duplicate of #78.

This is what I am talking about. I'm not too sure it's a duplicate of #78

Even some "4"s get cut off (the extended is shortened), but it's less obvious than the curved edges getting flattened.

I see, could you open dev tools and see at what font size they look fine to you? I can't really do much since I don't know/have the font you're using.


Set submission test to DRAFT

This PR sets the submissions CLI test to DRAFT as it fails when running in staging and production due to not obtaining the correct credentials.
Test Steps:

Run the smoke test and verify the submission test does not run by default.

Changes

set the submissions CLI test to DRAFT

Checklist
Testing

[x] Tested locally?
[x] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?
[ ] (For Changes to /frontend-react/...) Ran npm run lint:write?
[ ] Added tests?

Process

[ ] Are there licensing issues with any new dependencies introduced?
[ ] Includes a summary of what a code reviewer should test/verify?
[ ] Updated the release notes?
[ ] Database changes are submitted as a separate PR?
[ ] DevOps team has been notified if PR requires ops support?

Fixes

#issue - List GitHub issues this PR fixes

To Be Done
Create GitHub issues to track the work remaining, if any

#issue

Specific Security-related subjects a reviewer should pay specific attention to

Does this PR introduce new endpoints?

new endpoint A
new endpoint B

Does this PR include changes in authentication and/or authorization of existing endpoints?
Does this change introduce new dependencies that need vetting?
Does this change require changes to our infrastructure?
Does logging contain sensitive data?
Does this PR include or remove any sensitive information itself?

If you answered 'yes' to any of the questions above, conduct a detailed Review that addresses at least:

What are the potential security threats and mitigations? Please list the STRIDE threats and how they are mitigated

Spoofing (faking authenticity)

Threat T, which could be achieved by A, is mitigated by M

Tampering (influence or sabotage the integrity of information, data, or system)
Repudiation (the ability to dispute the origin or originator of an action)
Information disclosure (data made available to entities who should not have it)
Denial of service (make a resource unavailable)
Elevation of Privilege (reduce restrictions that apply or gain privileges one should not have)

Have you ensured logging does not contain sensitive data?
Have you received any additional approvals needed for this change?

Pull reviewers stats
Stats for the last 30 days:

User
Total reviews
Median time to review
Total comments

MauriceReeves-usds
42
21m
9

cwinters-usds
24
16h 36m
20

sean-usds
24
1h 12m
8

jimduff-usds
21
1d 3h 16m
23

kevinhaube
13
13h 49m
11

carlosfelix2
12
3h 19m
31

TomNUSDS
10
2h 22m
13

RickHawesUSDS
9
3h 31m
1

whytheplatypus
7
1d 2h 35m
14

jbiskie
5
1h 26m
1

brick-green-agile6
5
1h 41m
5

jorg3lopez
4
1h 22m
0

ahay-agile6
3
10h 22m
6

clediggins-usds
3
1h 16m
10

oslynn
2
2h 5m
0

JosiahSiegel
1
4m
2

MikeC-A6
1
7h 7m
3

rhood23699
1
14h 10m
0

sethdarragile6
1
1d 3h 8m
0

FYI, this PR may no longer be necessary.   I fixed the test in PR #3628

OBE.  This test was deleted


Shipping: no need to base64 if ImageFormat is *PL

[\r\n] => null
^\s+|\s+$ => null
& new variable-name ?!
btw/ not always hints to (smaller size) PNG @ Shipping API

Hi, would you mind providing a bit more context behind this inquiry?

remove the line-breaks and emtpy lines in start & end if the *PL - there will be no need to base64encode anymore
will result in less cpu-cycles (on both sides) and less trafic/better gzip

Hi, we appreciate the suggestion, but at this time, we will not be able to update this due to the large number of customer integrations we currently have and the potential for issues to arise.


⚠ Bofrost.de has degraded performance

In 0574885, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1472 ms

Resolved: Bofrost.de performance has improved in f0f5320.


Depresolve doesn't resolve to correct revspec

Depresolve doesn't resolve to the correct version -- but instead picks a version returned by npm listings.  There reverse also happens, where it also tries to resolve npm packages package@version into giturl@head, ignoring the corresponding rev.
There's not really a way to correspond an npm release version with a git rev id without parsing previous commits and diffs of the package.json, and even then you won't get a real answer without comparing files from the published release to the rev.
I think this encompasses a greater problem that srclib tries to resolve everything to a git url, which is inconsistent in at least 10% of cases.
Instead i think the model should be:

srcunit
fetcher (i.e. git, npm)
fetcher spec (i.e. revspec, semver)

We're restarting development on this, so closing outstanding issues for now since they are likely out of date. Please re-open if still relevant.


fix(ui): use width passed by ReactResizeDetector instead of body width

Trying to fix #721.

Not so easy to test for me without the same alerts firing


Redundant code warnings need to be resolved

The code under some modules is not referenced. There is a warning during compilation and should be handled.

Fixed, code warning canceled


Simple JWT refresh token endpoint

There is no refresh endpoint that works for simple jwt to return and set the new access token cookie.  I created my own by extending the simple jwt refresh endpoint. If I have time I'll make a PR but wanted to bring it up to the maintainers here that its needed.

Thanks. PRs are welcome 👍 .

Hello, I am sorry if my question is somehow weird as I am not knowledgeable with git. the issue about the token endpoints not being available. with these changes, does this mean it has been fixed? how or when can I access the changes or see them in my project?


Sometimes the number 'waiting-room-size' does not decrease and token(jwt) is not issued.

I would like to inquire about two issues.

If you click the 'reserve' button on the waiting-room-site and close the browser on the 'check out now!' screen, the number does not decrease and remains in the 'waiting-room-size', which prevents other waiting people from entering.

After clicking the 'check out now!' button on the waiting-room-site, the token is often not issued when '/generate_token' is called.

How do I solve 2 issues?

Hello @milestonekr, apologies for delay in response from our end.

This is because once you enter the waiting room you can still use public apis to generate token for the corresponding request_id. So, even though you close the browser, you are still in the waiting room and it will respond with valid jwt token if you make POST request for /generate_token with the request body

{
"event_id": "Sample",
"request_id": "MY_REQUEST_ID"
}

See Public REST APIs for more details

This is due to queue position expiry. Once you enter the waiting room, your position is valid for 15 minutes (by default). If you try to generate token after that, it will wail.

Please feel free to reopen the thread, if you have more questions.


build casues uninitialized constant FileUtils

I follow the quick example.
and then after commanding ruby-wasm build hello.rb
throw error messages below
Checking for Emscripten tools
  emcc...found
  emar...found

/Users/jamieyun/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/wasm-0.0.2/bin/ruby-wasm:22:in `build': uninitialized constant FileUtils (NameError)
Did you mean?  FileTest
	from /Users/jamieyun/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/wasm-0.0.2/bin/ruby-wasm:136:in `<top (required)>'
	from /Users/jamieyun/.rbenv/versions/2.4.2/bin/ruby-wasm:23:in `load'
	from /Users/jamieyun/.rbenv/versions/2.4.2/bin/ruby-wasm:23:in `<main>'

isn't it support ruby 2.4.2?

Could be. In Ubuntu, with ruby 2.3.3 I had the same error message. On Arch, with ruby 2.5 it works:
This is the Dockerfile:
# docker build . -t ruby_wasm && docker run --rm -it -p 8000:8000 ruby_wasm
FROM greyltc/archlinux-aur

RUN pacman -Syu --noconfirm && \
    pacman -S --noconfirm \
      emscripten \
      jdk9-openjdk \
      ruby \
      ruby-rdoc
RUN su docker -c 'pacaur -S --noprogressbar --noedit --noconfirm mruby binaryen'
RUN gem install wasm

ENV PATH="/usr/lib/emscripten:/root/.gem/ruby/2.5.0/bin:${PATH}"
# run twice:
# - first run gets rid of the confirmation
# - second run makes sure that all caches are ready
RUN ruby-wasm build /dev/null && ruby-wasm build /dev/null && rm -rf build

RUN echo 'puts "Hallo world"' > hallo_world.rb
RUN ruby-wasm build hallo_world.rb && \
    echo "Generated the following files:" && \
    find build

CMD ["ruby-wasm", "serve", "hallo_world.rb"]
EXPOSE 8000


Added guards for gnu_source definition in storage CMakeLists

Background: We use mmap to allocate memory whenever it is available. There is a check in storage module's CMakeLists to further check if mmap can support HugePage allocation.
Issue: The check for HugePage allocation used the definition for GNU_SOURCE macro. Some compilers by default have this macro defined, which causes the compiler to throw a warning "macro already defined". As warnings are treated as errors, this check fails, therefore CMake declares that HugePage support is not available.
Fix: Guard the definition by #ifndef directive.

LGTM.


Add missing data file and release

Add missing data file and release

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 82.36%. Comparing base (02b4d6c) to head (58299fe).
Report is 2 commits behind head on next.

Additional details and impacted files
@@           Coverage Diff           @@
##             next      #45   +/-   ##
=======================================
  Coverage   82.36%   82.36%
=======================================
  Files          20       20
  Lines        2404     2404
=======================================
  Hits         1980     1980
  Misses        424      424

Flag
Coverage Δ

82.36% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


slightly better readme

Just slightly better looking header

No need to check Travis, only readme.md is modified.


NOT A BUG/ISSUE [a gen qs]

hey bud, the gif u hav in ur readme, what is that? like in the lualine, in the 'X' column, u have a 🦊 lua which changes what is that?
thanks for the answer anyway...

It's better to ask questions in the discussion section rather then creating a new issue.  Although, your question belongs in the lualine repo to begin with.
As for how that emoji is setup? It's seems to me it's just using the "symbol" key in the config to setup emoji based on file/ buffer type. Similar to this:
ins_right {
        'diff',
        symbols = { added = ' ', modified = '柳 ', removed = ' ' },
        diff_color = {
                added = { fg = colors.green },
                modified = { fg = colors.orange },
                removed = { fg = colors.red },
        },
        cond = conditions.hide_in_width,
}

ah sorry for coming here thats why i added a disclaimer in my issue title...


[perl syntax highlighting] comments inside /x regexes not highlighted as such

(Original issue 256 created by None on 2007-06-17T01:53:00+00:00)
=== sample code ===
http://pygments.org/demo/361/
=== bug ===
{{{
my $dependency  = qr{
(?=[plb])(?:port|(?:path|lib|bin):[^:]+)  # kind
:                                         # separator
(?i:$port)(\s|\n|$)                       # name
}xo;
}}}

'''# kind''' is not recognized as a comment, although comments are allowed inside this regex, because of the /x modifier.
'''# separator''': see above
'''# name''': see above

Reported by guest

(Original issue was assigned to gbrandl)
(Original issue 256 last updated on 2009-01-03T16:26:35+00:00)
(Issue automaticaly closed due to status in Bitbucket: resolved)

(Original comment by thatch on 2009-01-03T16:26:35+00:00)
Clearing milestone.

(Original comment by gbrandl on 2009-01-01T13:33:17+00:00)
I agree with you, Tim. The attached patch doesn't result in a net improvement, because there are at least as many cases where it falsely highlights the "comment".
Finding the "x" modifier and correctly applying comment highlighting in hindsight is tricky to get right, and impossible with current "standard" features.

(Original comment by thatch on 2008-12-31T03:32:32+00:00)
Georg, thoughts?
I'd rather keep the existing behavior, such that comments remain the same color as the rest of the regex.  Correctly identifying comments is a problem I think too difficult for a quick syntax highlighter.  I checked and Vim has the same behavior as we currently do.

(Original comment by thatch on 2008-07-26T16:39:46+00:00)
Hmm.  Pondering required.


[Istio v100.0.2+up1.10.4] Install fails with "no matches for kind "ServiceMonitor""

Rancher Server Setup

Rancher version: 2.6.2
Installation option (Docker install/Helm Chart): Helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE2

Proxy/Cert Details:

Information about the Cluster

Kubernetes version: v1.21.6+rke2r1

Cluster Type (Local/Downstream): Downstream

If downstream, what type of cluster? : vSphere

Describe the bug
Installing Istio via "Cluster Tools" fails with:
Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"

To Reproduce
Install Istio via "Cluster Tools"
Result
The error from the description occurs and only rancher-kiali-server-crd App is listed as installed

Expected Result
Working Istio installation

not stale

please reopen @rohitsakala

please reopen @rohitsakala


Tidy up Sentry deployment

Most of the sentry.conf.py was just copied and pasted from the onprem
deployment
The majority of it wasn't needed so delete stuff that isn't relevant
Also make the Redis client that Django uses access Redis over TLS
since it can - only Kombu uses HAProxy now
Rename env vars for Redis to make it clearer which is which
Tweak README to make it come up cleaner

Nice, thanks for cleaning this up.
I wonder if we could get this working with the s3 broker: https://docs.sentry.io/server/filestore/#amazon-s3-backend


[🐞] Importing an image with vite-imagetools vars causes an error

Which component is affected?
Qwik Runtime
Describe the bug
When  importing an image into the app and using vite-imagetools i.e
import TestImage from '/images/image.jpg?w=400&h=300&webp';
Qwik throws an "Input file is missing error"
It works without the params import TestImage from '/images/image.jpg';

It seems it's looking for the params as part of the image name instead of parsing via imagetools
Reproduction
https://github.com/jimmyjamieson/qwik-starter/blob/vite-imagetools/src/routes/[...locale]/index.tsx
Steps to reproduce
Update your vite config with vite-imagetools
export default defineConfig(() => {
  return {
    plugins: [
      qwikCity(),
      qwikVite(),
      tsconfigPaths(),
      imagetools(),
    ],
  };
});

Import an image somewhere
import TestImage from '/images/image.jpg?w=400&h=300&webp';

See the error.
System Info
System:
    OS: Windows 10 10.0.22621
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
    Memory: 2.76 GB / 15.70 GB
  Binaries:
    Node: 16.15.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.15 - C:\Program Files\nodejs\yarn.CMD
    npm: 8.5.5 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22621.1105.0), Chromium (108.0.1462.76)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    @builder.io/partytown: ^0.7.4 => 0.7.4
    @builder.io/qwik: ^0.16.2 => 0.16.2
    @builder.io/qwik-city: ^0.1.0-beta9 => 0.1.0-beta9
    undici: ^5.15.0 => 5.15.0
    vite: ^4.0.4 => 4.0.4

Additional Information
No response

New image optimization in 1.2.0 is the way to go!


Add channels: SupeRails and Deanin

Add new Rails channels

How could I forget those Ruby on Rails channels? They are awesome 🔥
Thanks for the contribution!


Allowing remote direct actions to be executed without spawning a task

With this patch, direct actions are now always executed directly on the
receiving side. This means that they might get executed in a non-HPX thread.
This is a breaking change in behavior as it doesn't require direct_actions to run on HPX threads.

Note : This partially addresses #2284

The review comments have been addressed.


Publish an official OpenTelemetry image

Is your feature request related to a problem? Please describe.
I am looking for an official OpenTelemetry image to use instead of keyval/otel-go-agent:latest but none exists yet.
Describe the solution you'd like
This repository publishes an image via Github/Dockerhub like other OpenTelemetry owned images.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
I feel a Community-owned image is required for https://github.com/open-telemetry/opentelemetry-operator/issues/908

This is something I am invested in and can help as needed.

Opened: https://github.com/open-telemetry/community/issues/1377


Read full body from downstream before proxying to upstream

What is the problem your feature solves, or the need it fulfills?
When building a API gateway sometimes we need to modify the body - for example request to gateway is sent as JSON, but service accepts it as protobuf hence the need to fully read the body, deserialize json, build proto message and send it upstream.
Describe the solution you'd like
Provide an implementation that allows to fully read request from downstream and apply a body filter.
Describe alternatives you've considered
Using reqwest or hyper
Additional context
None

For an API gateway, it is generally recommended to not read request body unless there is a peculiar requirement to support usecases. API Gateways are typically designed to handle routing, authentication, authorization, rate limiting, and other cross-cutting concerns at the entry point. Also modifying the request body at the gateway could introduce security risk.

seems like this issue can be closed with #246?

Hey :)
thank you for this awsome work.
i tried a simmilar usecase. But I get an error based on Content Length.
My body from downstream ist for example 1024 bytes. The header contains "content-length: 1024". After body modification in request_body_filter is  the length of the body 980 bytes. Obviously upstream throws an error, because of missing bytes. But when I update the header in connected_to_upstream to the new content-length, I get from down only 980 bytes and not all 1024.
Where and when should I update the content length header?

If you know the body size ahead of the time (before you send the request header), you can change the header length in the upstream_request_filter. If not, you should change the content-encoding to chunked and remove the content-length header.
See a similar example here https://github.com/cloudflare/pingora/blob/main/pingora-proxy/examples/modify_response.rs


[Bug]:  Exception while Contacting RemoteAPI Host

All of the following criteria must be met

[X] All Requirements must be installed.
[X] Full Latest.log file included. If no file exists then leave this unchecked and state so.

All of the following are optional to answer

[X] Tried reinstalling the Game.
[X] Tried reinstalling MelonLoader.
[x] Tried restarting PC.
[ ] Was able to see the Start Screen.

Describe the issue.
exception thrown on startup
latest.log :https://pastebin.com/He3drkFT
thats all i know
Did you attach your log file?

[X] Yes, I attached my log file to the text box above.
[ ] No, I could not find a log file at {Game_Directory}\MelonLoader\Latest.log

2 recent version releases were recently removed for an unknown reason and you're running an older version of MelonLoader. Please install MelonLoader manually from https://github.com/LavaGang/MelonLoader/releases/tag/v0.5.4

Update: The latest release is back. You can simply reinstall MelonLoader using the official installer to fix your issue

now i got it to work. but i had to do it manually by downloading all the github files manually by getting the urls and the locations from the logs. it seems  like all my webclient requests are all aborted(?) for some reason


unit-test crashloopbackoff_rescheduler

@grosser

have a look at ginko, the tests usually end up much more readable http://onsi.github.io/ginkgo/#adding-specs-to-a-suite (as in not having long class names and readable descriptions instead of "testRemidiator"


ModelSummary ignores nn.Parameter

🐛 Bug
I don't know if this is a bug of a feature, but currently ModelSummary only reports member nn.Modules and ignores nn.Parameters that are directly created. I believe these parameters are an important part (and sometimes, a big part in terms of the number of weights) of the model so that they should be reported.
cc @borda @kaushikb11 @awaelchli @rohitgr7

Hey @ZhaofengWu
Happy to see you find the model summary useful!
I looked at this very briefly now. With the following code I get:
import torch

from pytorch_lightning import LightningModule
from pytorch_lightning.utilities.model_summary import ModelSummary

class BoringModel(LightningModule):
    def __init__(self):
        super().__init__()
        self.param = torch.nn.Parameter(torch.rand(2, 2))  # 2 * 2 = 4
        self.layer = torch.nn.Linear(2, 2)  # 2 * 2 + 2 = 6

if __name__ == "__main__":
    model = BoringModel()
    summary = ModelSummary(model)
    print(summary)

  | Name  | Type   | Params
---------------------------------
0 | layer | Linear | 6
---------------------------------
10        Trainable params
0         Non-trainable params
10        Total params
0.000     Total estimated model params size (MB)

We can see that the correct amount of parameters are getting reported (10 trainable parameters). Perhaps the size in MB is wrong.
Are you suggesting to include the nn.Parameter as a separate row in the table?

Perhaps the size in MB is wrong.

That's probably just a rounding thing?

Are you suggesting to include the nn.Parameter as a separate row in the table?

Yes. It's a bit confusing that the individual param counts don't add up to the total number as well.

But definitely not a huge issue and probably has low priority.

Commenting for activity

I believe this problem still exists in pl version 1.6.4
`import torch
import torch.nn as nn
import pytorch_lightning as pl
from pytorch_lightning.utilities.model_summary import ModelSummary
class Example(pl.LightningModule):
def init(self):
super().init()
self.lin1 = nn.Linear(32,64)
self.lin2 = nn.Parameter(torch.rand([32,64]))
model = Example()
print(ModelSummary(model,max_depth=-1))
print(pl.version)
`
shows only lin1 but not lin2
`
| Name | Type   | Params
0 | lin1 | Linear | 2.1 K
4.2 K     Trainable params
0         Non-trainable params
4.2 K     Total params
0.017     Total estimated model params size (MB)
1.6.4
`

Commenting for activity

Hi! @ZhaofengWu ZhaofengWu
I want to be assigned to this issue. It will be my first contribution.
And to make sure, I have a question.
When the code is below, is it the proper result?
import torch

from pytorch_lightning import LightningModule
from pytorch_lightning.utilities.model_summary import ModelSummary

class BoringModel(LightningModule):
    def __init__(self):
        super().__init__()
        self.param = torch.nn.Parameter(torch.rand(2, 2))  # 2 * 2 = 4
        self.layer = torch.nn.Linear(2, 2)  # 2 * 2 + 2 = 6

if __name__ == "__main__":
    model = BoringModel()
    summary = ModelSummary(model)
    print(summary)

  | Name  | Type   | Params
---------------------------------
0 | param | Parameter | 4
1 | layer   | Linear        | 6
---------------------------------
10        Trainable params
0         Non-trainable params
10        Total params
0.000     Total estimated model params size (MB)

Yes, I consider this behavior to be expected.

@yeonju7kim Feel free to give it a try.
I still have some doubts on the definition of when exactly such a parameter gets displayed. It's not clear to me how we can differentiate between a parameter that you the user created vs. one that is e.g. in the nn.Linear layer (weight, bias). Usually models are deeply nested and not flat like the one above.
One could of course only collect the top-level parameter definitions, but then someone might ask why their super important parameter defined in their nested module is not showing up, but the top-level one is.

@awaelchli So, first of all, the default ModelSummary has max_depth=1, so a user shouldn't expect their super important yet nested parameter to show up by default. When they do set a larger max_depth, the question is if we want to show, as in your example, nn.Linear's weight and bias. The simplest answer is yes -- the summary will be more verbose, but when users set a larger max_depth they should expect a more verbose output. Another option is that we hide all parameters of modules under torch.nn.

I think we can do what you are proposing.

Another option is that we hide all parameters of modules under torch.nn.
I wouldn't do this, as torch.nn is just a special case.

I'll assign yeonju7kim
Thank you for your interest.

If the concern is that the layer params reported does not add to the total number of params could we just display the difference under an other category or would this not work?

Sounds good to me!

I could look at this issue

I could look at this issue

Perfect!

What's the story on this? This behavior persists despite the issue being closed and the PR being merged.
trying @yeonju7kim's code we don't see "param" listed, we just see:
  | Name         | Type   | Params
----------------------------------------
0 | layer        | Linear | 6
  | other params | n/a    | 4
----------------------------------------
10        Trainable params
0         Non-trainable params
10        Total params
0.000     Total estimated model params size (MB)

In my code, I define         self.cb = nn.Parameter(torch.Tensor(cb_len, latent_dim))
but "cb" doesn't appear on the summary list.
(It's also not getting updated, despite requires_grad=True and  is_leaf=True)


MINOR: Add upgrade documentation for 3.6.0

This change adds the upgrade documentation for 3.6.0 and fix the notable changes position in 3.5.0. In previous releases, notable changes always come after the upgrade instructions.

Thanks for the review. Should be fine now.

@fvaleri , please open a PR against kafka-site repo for these changes. Thanks.

@showuon https://github.com/apache/kafka-site/pull/559

We included Zookeeper 3.8.2 as part of the 3.6.0 release. As such, I believe this point (https://github.com/apache/kafka/pull/13260/files#diff-5bd8e4998bd3e620df8990625bbc20e0136c20e91a956ea917358c2b9832b21bR28-R39) should be included in the upgrading Kafka documentation (for visibility). Otherwise we risk people upgrading from a Kafka cluster < 2.4 to 3.6 directly. What are your thoughts?

We included Zookeeper 3.8.2 as part of the 3.6.0 release. As such, I believe this point (https://github.com/apache/kafka/pull/13260/files#diff-5bd8e4998bd3e620df8990625bbc20e0136c20e91a956ea917358c2b9832b21bR28-R39) should be included in the upgrading Kafka documentation (for visibility). Otherwise we risk people upgrading from a Kafka cluster < 2.4 to 3.6 directly. What are your thoughts?

@clolov Good point! Please feel free to raise a PR with the intended upgrade documentation on ZK related update.


perf: Faster decimal precision overflow checks

Which issue does this PR close?

N/A
Rationale for this change

Small performance optimization.
null_if_overflow_precision_128
                        time:   [14.371 µs 14.403 µs 14.436 µs]
                        change: [-80.547% -80.475% -80.399%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  1 (1.00%) low mild
  3 (3.00%) high mild

null_if_overflow_precision_256
                        time:   [26.421 µs 26.531 µs 26.642 µs]
                        change: [-87.653% -87.587% -87.522%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

validate_decimal_precision_128
                        time:   [74.056 ns 74.401 ns 74.752 ns]
                        change: [-11.615% -10.563% -9.4441%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) low mild

validate_decimal_precision_256
                        time:   [215.61 ns 216.62 ns 217.68 ns]
                        change: [-0.8629% -0.3349% +0.1701%] (p = 0.22 > 0.05)
                        No change in performance detected.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high severe

What changes are included in this PR?

I noticed two areas of overhead in the current approach to verifying decimal precision.

In the event of an overflow, we are building a formatted string for an error message, which is then discarded in some cases, so we should avoid that cost
The range check code introduces a memcpy which can be avoided

I tested the following variations of the decimal precision check in Rust playground.
fn validate_decimal_precision1(value: i128, precision: u8) -> bool {
    if precision > DECIMAL128_MAX_PRECISION {
        return false;
    }
    let idx = usize::from(precision) - 1;
    value >= MIN_DECIMAL_FOR_EACH_PRECISION[idx] && value <= MAX_DECIMAL_FOR_EACH_PRECISION[idx]
}

// based on arrow-rs version
fn validate_decimal_precision2(value: i128, precision: u8) -> bool {
    if precision > DECIMAL128_MAX_PRECISION {
        return false;
    }

    let max = MAX_DECIMAL_FOR_EACH_PRECISION[usize::from(precision) - 1];
    let min = MIN_DECIMAL_FOR_EACH_PRECISION[usize::from(precision) - 1];

    if value > max {
        false
    } else if value < min {
        false
    } else {
        true
    }
}

validate_decimal_precision1 avoids a memcpy that appears in validate_decimal_precision2:
playground::validate_decimal_precision1:
	subq	$1304, %rsp
	movb	%dl, %al
	movb	%al, 23(%rsp)
	movq	%rsi, 24(%rsp)
	movq	%rdi, 32(%rsp)
	movq	%rdi, 1264(%rsp)
	movq	%rsi, 1272(%rsp)
	movb	%al, 1287(%rsp)
	cmpb	$38, %al
	ja	.LBB9_2
	movb	23(%rsp), %al
	movb	%al, 1303(%rsp)
	movzbl	%al, %eax
	movq	%rax, %rcx
	subq	$1, %rcx
	movq	%rcx, 8(%rsp)
	cmpq	$1, %rax
	jb	.LBB9_4
	jmp	.LBB9_3

playground::validate_decimal_precision2:
	subq	$1368, %rsp
	movb	%dl, %al
	movb	%al, 55(%rsp)
	movq	%rsi, 56(%rsp)
	movq	%rdi, 64(%rsp)
	movq	%rdi, 1296(%rsp)
	movq	%rsi, 1304(%rsp)
	movb	%al, 1327(%rsp)
	cmpb	$38, %al
	ja	.LBB10_2
	leaq	80(%rsp), %rdi
	leaq	.L__unnamed_5(%rip), %rsi
	movl	$608, %edx
	callq	memcpy@PLT   <----- MEMCPY HERE
	movb	55(%rsp), %al
	movb	%al, 1367(%rsp)
	movzbl	%al, %eax
	movq	%rax, %rcx
	subq	$1, %rcx
	movq	%rcx, 40(%rsp)
	cmpq	$1, %rax
	jb	.LBB10_4
	jmp	.LBB10_3

Are there any user-facing changes?
Technically, this is an API change because I made two consts pub(crate) instead of pub. However, if anyone wants access to the original consts they could just copy them into their code base.

thanks @andygrove probably a nit: I can see usize::from(precision) - 1 a lot which require new allocation of usize. My feeling the precision is static? may we can precompute idx and pass it by reference?

What if we just insert an extra element in the start of each of the lookup arrays and then just use precision as usize directly as the index?

Updated benchmark results after removing the idx allocation:
null_if_overflow_precision_128
                        time:   [12.555 µs 12.591 µs 12.628 µs]
                        change: [-85.358% -85.314% -85.275%] (p = 0.00 < 0.05)
                        Performance has improved.

null_if_overflow_precision_256
                        time:   [25.614 µs 25.755 µs 25.903 µs]
                        change: [-87.983% -87.827% -87.620%] (p = 0.00 < 0.05)
                        Performance has improved.

validate_decimal_precision_128
                        time:   [74.290 ns 74.703 ns 75.109 ns]
                        change: [-7.7409% -7.2664% -6.8248%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  5 (5.00%) low mild

validate_decimal_precision_256
                        time:   [215.27 ns 216.01 ns 216.75 ns]
                        change: [-4.4231% -3.7018% -2.9993%] (p = 0.00 < 0.05)
                        Performance has improved.

I reverted the API change

@viirya @comphead There have been changes since this PR was approved. Please take another look when you can.

I'm okay with the PR, although the array that changed moved to crate visibility and doesn't seem to affect others, however I'm not sure if anyone else other than arrow-rs actually used it

I'm okay with the PR, although the array that changed moved to crate visibility and doesn't seem to affect others, however I'm not sure if anyone else other than arrow-rs actually used it

I reverted the change to the original array and added a copy with the extra element so as not to break the current API. The new array is pub(crate)


"prose" default styles are not applied with attributify

When using attributify mode, default prose styles are listened to in the uno inspector but are not actually applied.
Playground

UPD:
Sometimes it apply successful after changes:

Try setting the config option strict to true

playground

@chris-zhu Thank you
But this work only with class, u:prose still not working:

Playground


Update ajax.ts

Incorrect this is referred in the overridden anonymous function handler of XMLHttpRequest prototype.
Fixes for the issue #848

Good catch and thanks for the PR! Will get this published with rc5

Thanks @markwolff


Post-processing entries in the version catalog

It would be nice to have some API for post-processing items in a version catalog, e.g. modifying module names or versions on the fly before they are actually used in the build.
Expected Behavior
Gradle provides some API to process versions, aliases and bundles, maybe in the form of configuration actions which are run for all new definitions in the catalog when they are added to the catalog.
Current Behavior
No such API exists.
Context
One use case I have is to provide an ability to simplify building projects against different versions of a dependency, for example, Scala. Something which would allow defining a dependency in a catalog like
[libraries]
cats-effect = { group = "org.typelevel", name = "cats-effect_%", version = "3.2.9" }

and then post-processing it to insert the Scala binary version instead of % programmatically based on the build properties.
This can be extended to other parts of the catalog definitions, e.g. choosing a version of a dependency based on some condition, etc.
Right now this can be done by applying some logic if a catalog is defined entirely in the settings.gradle.kts script, directly inside various alias() and version() declarations, but it is not possible with a TOML file-based catalog.

This is not something we aim at adding for the version catalog.
However improving the Scala use case makes sense and we would need to figure out the right model for this.

@ljacomet Scala was just an example, even though it is prominent. We do have use cases when we need to build against different versions of other dependencies, and not just in the artifact names but versions too. So I wouldn't say this is limited to Scala only.


Avoid get lock from synchronized in every shuffle

1.get lock to init UcxNode only in the first shuffle
2.fix typo

cc @petro-rudenko Could you please have a look

retest this please

@wenxuanguan please rebase on master. I've merged fixes for CI.

@petro-rudenko Thanks for your review and guidance.


ES6 refactor

The app works with no error, but why does it fail the mocha test?

Reviewing it right now.

I just refactored api.js myself, before I saw this PR.
There's one problem I spotted right away, that I encountered in my own refactoring.
In the web scraping API, this code will not work as you expect.
$('.title a[href^="http"], a[href^="https"]').each(() => {
      links.push($(this));
    });

If you try logging this, you'll see that it now refers to the global this.
Previously, cheerio's each function sets this in the regular callback function to the current element.
However, with arrow functions, this is bound lexically so that has no effect.
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Invoked_through_call_or_apply
You'll need to change this to:
$('.title a[href^="http"], a[href^="https"]').each((i, elem) => {
      links.push($(elem));
    });

@vanshady Nice, looks good for the most part. Thanks @prashcr for your feedback as well. I merged this PR into es6 branch. I will give it another look and if I don't find any issues I will merge it into master.

Found a similar issue with Mongoose middleware where this refers to the global scope:
/**
 * Password hash middleware.
 */
userSchema.pre('save', (next) => {
  const user = this;

After looking through Mongoose issues, it doesn't looks like it passes model as a callback parameter, so the only way to access it is via this.

Unfortunately, I think there's no way around it then. Will have to revert that to using function.
http://stackoverflow.com/questions/33774472/mongoose-pre-save-is-using-incorrect-this-context
https://github.com/mochajs/mocha/issues/1856


Pin the operator to the namespace knative-operator for helm

As we change to use knative-operator as the namespace and the default namespace to install knative operator, helm chart will pin to use this namespace as well.

/cherry-pick release-1.14

/lgtm


Clean up pre-existing DevFS during creation

When connecting to a flaky device, or a device with a flaky network stack, flutter_tool can exit without any opportunity to clean up the DevFS on the device. However, users are expecting reconnections to work. Currently they fail when flutter_tool notices that the target VM already has a DevFS set up.
In this case, this CL cleans up the existing DevFS, and sets up a new one. This CL also avoids trying to connect to a bogus port on a Fuchsia devices.

Done

Friendly ping.

Thanks!


Particles with explosiveness == 1.0 does not emits trails

Godot version:
3.2 beta2
Issue description:
Particles do not generate trails at that condition (well obviously it generates but its invisible for the end-user cuz they are emitted simultaneously):

On the left side the example with explosiveness set to 0.0, at the right duplicate of first (with the same ParticlesMaterial) but with 1.0.
Minimal reproduction project:
ParticlesBug.zip

Ah.. duplicate of https://github.com/godotengine/godot/issues/12133


[Style] : Responsive issue

There is responsive issue at https://pop-shop-github.vercel.app/home/shop

@pooranjoyb  Please assign me this issue under GSSOC24

Hii @Sid-80 you can start with the responsiveness of Home, Shop, Cart, Product Details and Auth page.
Finish up all the screen and make sure they are responsive :))) All the best!
Take the pull from dev branch and create the PR to dev branch. Happy Coding :)

Sure!

#20 I have created PR to dev branch. Please review it and let me know if any changes required!😊

Build not failed from my side?


[Bug]: [BE] - "Log in or Sign up" button is still not active during Get SORA Card

Preconditions
Fresh install
Steps to reproduce

Go to the wallet tab
Get SORA Card

Actual behavior
"Log in or Sign up" button is still not active during Get SORA Card.

Expected behavior
"Log in or Sign up"  and "I already have a card" buttons should be active to continue Get SORA Card flow.
NOTE: I'm worried when the bug will be fixed when the buttons are still unavailable, we know for sure this problem is related to the backend or only to the PV side or is it related to credentials, we need to find out
Environment
{"label"=>"Development"}
OS version
Android 13
Additional context
Soralution version

fixed

Verified on <IP_ADDRESS> version.


Highlight color on revision comparison lacks color contrast

Issue Summary
In dark mode, the highlight color on revisions for deletions/additions are rather poor and unreadable. I think it's 1.22:1 and 1.35:1 respectively.
Steps to Reproduce

Edit something. Compare the revision in dark mode.

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: (yes)

Technical details

Python version: 3.11
Django version: 3.2.29
Wagtail version: 5.0.1
Browser version: Chrome 113
Mac OS X: 12.6.1 Monterey with dark mode set to default

Confirming this issue.

Thanks for the report @jessemenn! I thought this was on our list for dark theme tweaks but apparently not. Will work on a fix for the next 5.0 patch release.


Files with inconsistent image slice sizes break loading

Currently TIFF images with embedded reduced resolution images cause problems since TiffImages assumes the images aren't ragged.
Take DAPI Myog Pax7_CH1.zip for example, which fails to load:
julia> TiffImages.load("DAPI Myog Pax7_CH1.tif")
ERROR: EOFError: read end of file
Stacktrace:
  [1] unsafe_read(s::IOStream, p::Ptr{UInt8}, nb::UInt64)
    @ Base ./iostream.jl:428
  [2] unsafe_read
    @ ./io.jl:761 [inlined]
  [3] read!
    @ ./io.jl:779 [inlined]
  [4] read!(file::TiffFile{UInt32, FileIO.Stream{FileIO.DataFormat{:TIFF}, IOStream, String}}, arr::Matrix{ColorTypes.RGB{FixedPointNumbers.N0f8}})

However, loading the image planes separately works:
tf = read(open("DAPI Myog Pax7_CH1.tif"), TiffFile)
ifds = collect(tf)
TiffImages.load!.(Ref(tf), ifds)
size(TiffImages.load(tf, ifds[1:1], nothing))

(720, 960)
and
size(TiffImages.load(tf, ifds[2:2], nothing))

(120, 160).
It appears as though we are handling everything just fine, it's just that we should detect when images are "ragged", i.e. don't have the same XY sizes and load those images as the currently unimplemented StridedTaggedImage

I've come across GeoTIFFs with ragged data, so this is a must for 1.0 IMHO

Thoughts on how to handle LazyBufferedTIFF, which assumes slices are homogeneous in size and color type?

LazyBufferedTIFF is currently a subtype of DenseTIFF so it should just error and not support ragged TIFFs. We could discuss whether that subtyping is the best, but just erroring could be fine for now.


Document/Test Workspace Support

Corrosion should offer the possibility to import crates using a Cargo.toml from a workspace. If that is already possible, it should be mentioned in the documentation. If not, a ToDo should be added.

Yeah, it's supported by design. I should probably add a test for it.

Hi

Yeah, it's supported by design. I should probably add a test for it.

Great, please add a note to the README. Thanks!

I've actually tried to use corrosion with a repository that is having lots of crate in its workspace. But for the C++ build, i'm only interested in a single crate in this workspace (and its dependencies).
However, even if i do
corrosion_import_crate(MANIFEST_PATH "${CMAKE_SOURCE_DIR}/sub_dir/to/specific/Cargo.toml")

every  crate of the workspace (and even the one not in default-members) gets imported and build by default
I would like to only import the specific crate i'm interested in.
Not only because it recompile many crates i don't need, but also because it uses some name which i cannot use as target name as well.

Just filed https://github.com/AndrewGaspar/corrosion/issues/57

The current Readme documents the ability to import a workspace and we also have a test, so I'm closing this issue.


fix bug in localhost

Add library react
npm install @tiptap/react
npm install @blocknote/react
npm install @emotion/react
npm install @mantine
npx convex deploy --cmd='npm run build'
To fix bug of react by delete cache force
npm cache clean --force
npm install -g npm@latest --force
npm cache clean --force
px convex deploy --cmd='npm run build

I've decided to change how config files are handled by using environment variables in env.local
Now convex/auth.config.js will be filled using env var AUTH_DOMAIN and APPLICATION_ID in .env.local
for more info read my latest commit
export default {
  providers: [
    {
      domain: process.env.AUTH_DOMAIN,
      applicationID: process.env.APPLICATION_ID,
    }
  ]
}

Please update to the latest commit from dev branch and reopen another pull request


Awaiting Script's Issue witn no other Script Loading

Hello, again there is the client Logs:
https://pastebin.com/fQ6CgsKm
And there is the server logs:
https://pastebin.com/fzFtFdXv
My Server.cfg

Only change the IP if you're using a server with multiple network interfaces, otherwise change the port only.
endpoint_add_tcp "<IP_ADDRESS>:30120"
endpoint_add_udp "<IP_ADDRESS>:30120"
ensure spawnmanager
ensure baseevents
ensure chat
ensure ghmattimysql
ensure cnrobbers
ensure cnr_blips
ensure cnr_cash
ensure cnr_charcreate
ensure cnr_chat
ensure cnr_clans
ensure cnr_death
ensure cnr_police
ensure cnr_robberies
ensure cnr_scoreboard
ensure cnr_wanted
This allows players to use scripthook-based plugins such as the legacy Lambda Menu.
Set this to 1 to allow scripthook. Do note that this does not guarantee players won't be able to use external plugins.
sv_scriptHookAllowed 0
Uncomment this and set a password to enable RCON. Make sure to change the password - it should look like rcon_password "YOURPASSWORD"
rcon_password "xxx"
A comma-separated list of tags for your server.
For example:
- sets tags "drifting, cars, racing"
Or:
- sets tags "roleplay, military, tanks"
sets tags "default"
A valid locale identifier for your server's primary language.
For example "en-US", "fr-CA", "nl-NL", "de-DE", "en-GB", "pt-BR"
sets locale "root-AQ"
please DO replace root-AQ on the line ABOVE with a real language! :)
Set an optional server info and connecting banner image url.
Size doesn't matter, any banner sized image will be fine.
#sets banner_detail "https://url.to/image.png"
#sets banner_connecting "https://url.to/image.png"
Set your server's hostname
sv_hostname "Testing Server"
Nested configs!
#exec server_internal.cfg
Loading a server icon (96x96 PNG file)
#load_server_icon myLogo.png
convars which can be used in scripts
set temp_convar "hey world!"
Uncomment this line if you do not want your server to be listed in the server browser.
Do not edit it if you do want your server listed.
#sv_master1 ""
Add system admins
add_ace group.admin command allow # allow all commands
add_ace group.admin command.quit deny # but don't allow quit
add_principal identifier.steam:110000100000000 group.admin # add the admin to the group
Hide player endpoints in external log output.
sv_endpointprivacy true
Server player slot limit (must be between 1 and 32, unless using OneSync)
sv_maxclients 32
License key for your server (https://keymaster.fivem.net)
sv_licenseKey xxxx

Hope you can find something wrong because i don't see nothing wrong

There are no errors or gamemode issues in the logs that I can see. Try adding mapmanager to your loadout, and ensure you have a default map loaded (such as fivem-map-hipster) and see if it loads then.

Be sure to report back what you find by adding mapmanager and let me know if it works or not. If it solves the issue, I'll be sure to add mapmanager as a dependency on the next push. Otherwise, if I do not hear back I'll assume this issue is resolved.

Sorry for the late answers now works fine i'm so new with fiveM forgot to add the other mode
Thanks for you awsome help.
Have a nice Day!!


ALF Automation

Brackets: Please merge this pull request created by ALF. @ArturOledzki @pantkowiak @rajjain FYI

I am merging this inspite of Travis tests failing because of daily RATE limitation as this is just a string change.


test(atomic): Add cypress test for numeric facet v1

https://coveord.atlassian.net/browse/KIT-752

Add test for numeric facet v1
I also split all the 'common' functions shared by 'facets' to a separate file, but I haven't committed the clean up version for facetv1 tst, will do it on another PR after I have this PR approved (otherwise it will be very big PR)
Test UA for "Apply" button for numeric input form is not able to be performed, as after we click the Apply button, all the page is refreshed, so we lost all the scripts atm, so that test I will check it out later

Small detail, usually we wrote verify analytics and not verify analytic 😛


Set tagLimit after init

Hello,
Can I set/update the tagLimit setting after the init ?

I found, just with :
amsifySuggestags._settings({
tagLimit: 6
})

Hello,
Yes you can update settings even after _init has been called
amsifySuggestags = new AmsifySuggestags($('input[name="country"]'));
amsifySuggestags._init();

amsifySuggestags._settings({
	tagLimit: 6
});

I am closing this issue now. You can reopen it if you think the solution is not found.


feat: add a "new" badge for week old pools

Description
Adds a "new" badge for new pools (less than a week old)

Also added on the pool page:

Type of change

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

How should this be tested?
Please provide instructions so we can test. Please also list any relevant details for your test configuration.

[ ] Should work on both pools / liquidity mining pages.

Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code where relevant, particularly in hard-to-understand areas
[ ] My changes generate no new console warnings
[ ] The base of this PR is master if hotfix, develop if not

Alrighty, ready for review (refactored to use BalChip) and also made it SFC


Eslint fixes

Fixed eslint errors, refactored some fors, got rid of useless promises, handled uncaught promises,  handled fatal error when JDK is not installed.

@mihaiblaga89 this one has quite few conflicts with master. can you resolve them first

@pavjacko fixed the conflicts but don't merge it just yet. Please add the don't merge to it.


Write an article "The Essentials of IM System"

Motivation
If developers can know the essentials of the IM system, it would be easier for them to grasp the essence of different kinds of IM features from the perspective of architects and developers, which will help them choose various technical solutions and develop their own features in an easy way.

Won't do. The current docs should be clear enough.


InitContainers - Handle builtin kernel modules

Describe the bug
Some components, by default, use init containers to check for nvme kernel modules.
The problem is these modules might actually get compiled builtin, and these checks are failing in this case.
To Reproduce
Install on nodes with builtin nvme-tcp kernel modules.
Expected behavior
InitContainer should not fail.
** OS info (please complete the following information):**

Distro: Talos
Example: https://discuss.kubernetes.io/t/talos-linux-cluster-missing-module/27519

Thanks for all your hard work on this!   I just ran into this one. The link suggests disabling init_containers.    While this is being worked on, how can I disable init_containers?

Hey, I think you need to disable like so for example, if you use mayastor chart directly:
helm upgrade mayastor mayastor/mayastor -n mayastor --reuse-values --set "csi.node.initContainers.enabled=false"

@CloudFocused I work with @tiagolobocastro on the futures for Mayastor. If you're open to talking about your experiences, and what you're doing, let me know (you can reply here or DM me). Ed

You are right @tiagolobocastro -  That did it. Thanks!

Is there a solution for this using the openebs helm chart?

Scoping this for v4.2


Support show tag values

Describe This Problem
Currently, count(distinct(x)) is the only choice to fetch all the values of a tag, which requires scanning all the ssts and takes lots of time. However, this should be a very light-weight query for time series database, e.g. grafana shows suggestions about a specific label.
Proposal

Record all the values for a tag if possible;
Do fast query when count(distinct(x)) is performed on a tag column, that is to say, x column a tag column.

Additional Context
No response

This is a huge task, I'll split it into these sub-tasks:

[ ] Table options for supporting configure value index on specific column
[ ] Query optimize rule for count(distinct(x)) where x has the values' index
[ ] Support separate index file for the column values
[ ] Compaction support create index file for multiple ssts


Add black and mypy to linting group

Hi, would u consider adding black and mypy. And also allowing ruff to run complete set of rules and then just to ignore ones based on needs?

Yea, I am cool with adding black & mypy linting.
Which ruff linting rules do you think should be ignored?  My first thought is to just make the project compliant with all the ruff default checks, but I am open.

Also, I'm still suggesting to add spell checks for README file.

Well currently only F(Pyflake) and E(Pycode) are enabled(by default).
Best would be to enable=[ALL], and ignore ones that we dont want.
@SemyonSinchenko , yep yep, will add with these lints.
I will enable other ruff rules and let u know for some very specific rules that we may ignore or allow.


Add OpenBB as a Data Source to Superagent

⚠ Please check that this feature request hasn't been suggested before.

[X] I searched previous Ideas in Discussions didn't find any similar feature requests.
[X] I searched previous Issues didn't find any similar feature requests.

🔖 Feature description
Requesting to integrate OpenBB's SDK into Superagent to provide real-time financial data as a data source. This would enable agents to access a wealth of financial data including equity, options, crypto, forex, and more.
📝 Additional Context
The addition of OpenBB as a data source can significantly enhance the capabilities of agents by folding in real-time data and insights. OpenBB's SDK is Python-friendly and its implementation can open new possibilities for analytics, reporting, and decision-making within Superagent.
Acknowledgements

[X] My issue title is concise and descriptive.
[X] I have searched the existing issues to make sure this feature has not been requested yet.
[X] I have provided enough information for the maintainers to understand and evaluate this request.

@BirchGlobal I researched this and unfortunately OpenBB doesn't support Python 3.11 for some reason. Adding this would unfortunately break other dependencies. I will keep an eye out after their updates and implement this then.

OpenBB can now be run with custom functions on your local machine.


ERR_INVALID_ARG_TYPE(name, 'string', value);     ^  TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined     at validateString (internal/validators.js:125:11)     at Object.join (path.js:1147:7)

I just run
$ react-native init AwesomeProject

Package are installed but I have an error
info Setting up new React Native app in /Users/xx/Sites/AwesomeProject
info Adding required dependencies
internal/validators.js:125
    throw new ERR_INVALID_ARG_TYPE(name, 'string', value);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
    at validateString (internal/validators.js:125:11)
    at Object.join (path.js:1147:7)
    at isProjectUsingYarn (/Users/xx/Sites/AwesomeProject/node_modules/@react-native-community/cli/build/tools/yarn.js:101:51)
    at shouldUseYarn (/Users/xx/Sites/AwesomeProject/node_modules/@react-native-community/cli/build/tools/PackageManager.js:36:39)
    at Object.install (/Users/xx/Sites/AwesomeProject/node_modules/@react-native-community/cli/build/tools/PackageManager.js:44:10)
    at generateProject (/Users/xx/Sites/AwesomeProject/node_modules/@react-native-community/cli/build/commands/init/init.js:111:18)
    at Object.init (/Users/xx/Sites/AwesomeProject/node_modules/@react-native-community/cli/build/commands/init/init.js:94:3)
    at run (/Users/xx/.config/yarn/global/node_modules/react-native-cli/index.js:302:7)
    at createProject (/Users/xx/.config/yarn/global/node_modules/react-native-cli/index.js:249:3)
    at init (/Users/xx/.config/yarn/global/node_modules/react-native-cli/index.js:200:5)

https://github.com/facebook/react-native/issues/24107

https://github.com/facebook/react-native/issues/24103

i am having the same problem

I'm facing the same issue

same problem happens with node 10 and 11 here

ceci est un duplicata de #24103.

metoo……

I have the same issue

its work on previous version, you can try
react-native init AwesomeProject --version "0.58.6"

I hava this problem too
info Setting up new React Native app in D:\ReactNative\MyApp
info Adding required dependencies
path.js:39
throw new ERR_INVALID_ARG_TYPE('path', 'string', path);
^
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
at assertPath (path.js:39:11)
at Object.join (path.js:432:7)
at isProjectUsingYarn (D:\ReactNative\MyApp\node_modules@react-native-community\cli\build\tools\yarn.js:101:51)
at shouldUseYarn (D:\ReactNative\MyApp\node_modules@react-native-community\cli\build\tools\PackageManager.js:36:39)
at Object.install (D:\ReactNative\MyApp\node_modules@react-native-community\cli\build\tools\PackageManager.js:44:10)
at generateProject (D:\ReactNative\MyApp\node_modules@react-native-community\cli\build\commands\init\init.js:111:18)
at Object.init (D:\ReactNative\MyApp\node_modules@react-native-community\cli\build\commands\init\init.js:94:3)
at run (C:\Users\user\AppData\Roaming\npm\node_modules\react-native-cli\index.js:302:7)
at createProject (C:\Users\user\AppData\Roaming\npm\node_modules\react-native-cli\index.js:249:3)
at init (C:\Users\user\AppData\Roaming\npm\node_modules\react-native-cli\index.js:200:5)
D:\ReactNative>node -v
v10.15.0
D:\ReactNative>npm -v
6.4.1

Duplicate of https://github.com/facebook/react-native/issues/24103 (already fixed)

I have the same issue


added react icons

Related Issue
Closes #1016

Description
Successfully added react icons shortcut to the website.
Screenshots

Checklist

[x] My code adheres to the established style guidelines of the project.
[x] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

The PR title format you are using is causing an error in the workflow. Please follow the instructions in the README.md and change it accordingly.


Test Redis with Kubernetes and docker installation

In address to the new sentinel update  https://github.com/GluuFederation/oxCore/issues/144#issue-491536723

Test with Amazon ElastiCache for Redis, and Google Cloud Memorystore


Handle comments inside &&&-bulleted blocks better

The interaction of comments and bulleted blocks previously caused surprising number of newlines to show up. This PR fixes this.
In particular, the following code is now considered correctly-formatted
fn foo() {
    // these should stay together
    &&& x
    &&& y
    // xy
    &&& xy
    // zzz
    &&& z
}

Previously, there would be unnecessary newlines added after every comment. This would happen because comments have a forced-hardline after them, while &&& (and |||) bullets have a forced hardline before them, causing the number of hardlines to double-up, leading to surprising looking code.
Example sub-optimal code with the old surprising behavior (issue reported by Johanna):

Note: this particular change causes a single-line change to the Verus vstd snapshot, but still requires a tiny amount of coordination to prevent spurious CI failures there before releasing (should not block merging, just blocks release, and should likely bump the minor version, rather than just patch version).

Yeah given that the comment is at a non-local nesting, I was worried it'd be a fairly complex fix, but once I realized I could flatten things, the diff became a lot smaller than the previous prototype of this that I was working with :)

This is actually beautifull. I love it. Thanks :)


Add descriptions of the solver field outputs

The documentation should explain what the solver output fields are, e.g. D, sigma, epsilon, etc.
This issue was inspired by https://www.cfd-online.com/Forums/openfoam/246657-some-problems-bi-material-computation-using-solids4foam.html#post841286.

Hi Philip,
I want to run bimaterial FSI simulation using solids4Foam but I am getting some error while running. The error I am getting is attached here. How to resolve this?

Hi Philip,
I want to run bimaterial FSI simulation using solids4Foam but I am getting some error while running. The error I am getting is attached here. How to resolve this?

I have moved your comment to a new issue as it is unrelated to the current issue.


Postgraphile Middleware

Postgraphile middleware is what we will use to interact with our db.

[x] Install postgraphile
[x] connect to DB
[ ] test that information is saved in the DB locally

Closing this since I set up Postgraphile middleware to get Relay going.


Scope tasks from takeLatest and takeLeading by ID

I opened PR https://github.com/redux-saga/redux-saga/pull/1744 to address this idea and to couple that PR to an active issue.
This is somewhat of a bump of https://github.com/redux-saga/redux-saga/issues/694 - but it's been a couple of years since then and I still think there is a good case to be made for an out-of-the-box solution here.
Let's say you have a saga whose primary function is fetching a single user based on an ID - and let's say that you want to fetch multiple users around the same time.
If you want to ensure that a maximum of one fetching task is running per ID, you might want something like takeLatest and takeLeading but scoped by something that we select from the action that spawns the saga (like an ID).
Examples:
function* fetchUser(action) {
  const { payload: { id } } = action
  const response = yield call(getUser, id)
  // ...
}

function* rootSaga() {
  yield takeLatestPerKey('FETCH_USER', fetchUser, action => {
    const { payload: { id } } = action
    return id
  })
}

function* fetchUser(action) {
  const { payload: { id } } = action
  const response = yield call(getUser, id)
  // ...
}

function* rootSaga() {
  yield takeLeadingPerKey('FETCH_USER', fetchUser, action => {
    const { payload: { id } } = action
    return id
  })
}

I'd love to hear your thoughts on this issue.
Thank you for this amazing library and all the hard work that goes into maintaining it.

Is there any interest in this or the PR it references?

Hi - sorry for not responding back earlier.
I'm unsure if this is in scope of the core library. Would love to see community-maintained addons package and maybe this would fit such perfectly?

I definitely would like to see this in either this package or an add-on, as I've come across the need for this exact use case where I need only one saga per ACTION_TYPE/key combo to be running at any time.

I would like to spin up a redux-saga-addons repository that is at the level of quality that redux-saga is in terms of documentation and the like, but I haven't found the time. If someone beats me to it, I'd like to put this code in a PR to that.

@therealparmesh I wish I could help, but I don't have either the time or the expertise to create/maintain such a library.
In the meantime, is there a way to modify your PR to work in my app? I took a look at your PR and saw you're using some functions that are not (to my knowledge) publicly exposed by redux-saga, so a straight copy of takeLeadingPerKey() wouldn't work. Is there anything I can do in the meantime to integrate such functionality into my app?

Yes - take a look at the PR I opened in reference to this issue: https://github.com/redux-saga/redux-saga/pull/1744. The CodeSandbox examples have the function generator version of these helpers that you can copy-paste for your own use. Credit to @Andarist for coming up with the basis of these solutions here: https://github.com/redux-saga/redux-saga/issues/694.

From what I've gathered, what blocks this from being readily available to people like me is the following: @Andarist understandably wants to keep the main project small and thinks this belongs in a separate, larger "addons" package. @therealparmesh agrees, but isn't ready to take on the responsibilities associated with maintaining such a package.
I probably don't have the same experience as you, @therealparmesh and @Andarist, so my reasoning here may be wrong, but is the only way forward for redux-saga addons to be put in one (large) addons project?
Wouldn't it be less taxing for both users and maintainers to split separate addons into separate packages? I think eslint plugins serve as a good example of how this could work for redux-saga: Their names all start with eslint-plugin and most of them adhere to the single responsibility principle. Couldn't the same be done for redux-saga-addons? I agree with you in that such addons should be as well documented as the main redux-saga library. I think that a reasonable quality level can be achieved by providing package creators with a good template for readmes and by setting a good example with the first few packages, perhaps nurturing them with PRs and feedback. As a reward, good addons could be included in some curated list in the official documentation.
Couldn't we give it a try with this code and see how it goes? Although I've never made a package before, I could give it a shot if you allow me to, @therealparmesh. It could be named something like redux-saga-addon-scoped-take-helpers. Do you like the idea?

@therealparmesh I recently needed a similar behavior (basically the same but with topics), In my opinion, such behavior shouldn't belong the built-in library.
This behavior can already be achieved, relatively easily with present apis.
Here is an example to fetching users by id:
import {
	  takeEvery,
	  takeLatest,
	  put,
	  select,
	  delay,
	  fork,
	  cancelled,
	} from 'redux-saga/effects';

	export const FETCH_USER_FLOW = 'FETCH_USER_FLOW';

	export const fetchUserActionFlow = (id) => ({
		type: FETCH_USER_FLOW,
		payload: { id },
	})

	export const fetchUserApiAction = (id) => (/* Complex Redux action for api dispatching */);

	export const selectUserById = id => state => _.get(state, `users[${id}]`, undefined);

	function* fetchUserById(action) {
		try {
			const { id } = action.payload;
			const user = yield select(selectUserById(id));
			if (!user) {
				// Only needed if using takeLatest, give a 50ms delay to allow saga to cancel event
				// Can be commented out if using takeLeading
				yield delay(50);
				// dispatch api action
				yield put(fetchUserApiAction(id));
			}

		} finally {
			if (yield cancelled()) {
				console.log(`fetchUserById got cancelled: ${action.type}`);
			}
		}
	}

	function* fetchFlowFork(actionType) {
		// here you can use either takeLeading or takeLatest depending on your needs
		yield takeLatest(actionType, fetchUserById);
	}

	function* fetchUserFlow(action) {
		// intercept main action with flow action
		const { id } = action.payload;
		// create "specific" dynamic id action type
		const idBasedActionType = `${action.type}:userId:${id}`;
		// fork to listen to new action (event is non blocking)
		yield fork(fetchFlowFork, idBasedActionType);
		// dispatch or "put" new action with the exact payload
		yield put({
			type: idBasedActionType,
			payload: { id },
		})
	}

	export default [
		takeEvery(FETCH_USER, fetchUserFlow),
	];

This could, technically be made more dynamic and packed in a generator function that maybe gets a keyToDynamicValue and extract said key using lodash or something, but the logic is a real no brainer, I don't know if the effort is worth it ¯_(ツ)_/¯

@samermurad Personally when I see things like delays and such, I tend to think they're not so simple.
This issue and the accompanying PR (https://github.com/redux-saga/redux-saga/pull/1744) is over 1.5 years old. They've been bumped a few times, and there seems to be a general consensus that this sort of helper doesn't belong in the library because it's one level of abstraction too high and there's room for opinions as to the implementations. Perhaps it's best suited to documentation or an addons library like mentioned above.

I have been looking around for a canonical/best practice solution, eventually settled on just using takeEvery, fork and cancel turns out to be a simple solution:
function* getUserById({payload}) {
  //...logic
}

const pendingTasks = {}
function* getLatestUserById({payload: {id}}) {
  if(id in pendingTasks) {
    cancel(pendingTasks[id])
  }
  pendingTasks[id] = fork(getUserById
}

function* rootSagas() {
  takeEvery(pattern, getLatestUserById);
}

Hope this helps and is a good way of doing things.

Closing due to inactivity.  If someone finds this discussion useful we can convert it into a GH discussion and continue the conversation there.

It is very strange that saga can't handle such a common and simple thing like take latest by key.
This all proves me that saga is a very limited technology, classical over-engineering, that shouldn't be used anywhere.

Hi @gentlee thanks for your interest in redux-saga.
takeLatest can be re-implemented in 10 lines of code.  The original intent was to be a simple abstraction on top of an infinite loop that listens for actions.
https://redux-saga.js.org/docs/api#notes-4
const takeLatest = (patternOrChannel, saga, ...args) => fork(function*() {
  let lastTask
  while (true) {
    const action = yield take(patternOrChannel)
    if (lastTask) {
      yield cancel(lastTask) // cancel is no-op if the task has already terminated
    }
    lastTask = yield fork(saga, ...args.concat(action))
  }
})

From here it is trivial to take actions based on a function instead of an action type, which would provide the functionality requested in this issue.
Could we patch takeLatest or build some other helper and mainline it into redux-saga?  Yes and very simply at that.  But to me, that further obfuscates the real paradigm of redux-saga, which is flow control.  Users will invariably need to leverage an infinite loop with custom take logic and continuing to build "helpers" that embed that paradigm will get users further away from the real strength of this library.
I'd be more than happy to keep chatting about this issue or any others in subsequent GH issues, discussions, or discord.  Thanks!


Add recipe AddLiteralMethodArgument

This recipe finds a method and adds a literal argument at the specified index.
What's changed?
Recipe was added
What's your motivation?
In stead of only adding a null argument we can now also specify a literal. This means when adding an argument and fixing the calls with a recipe we no longer need to require the field to be boxed and nullable for primitives.
Anything in particular you'd like reviewers to focus on?

Anyone you would like to review specifically?
@timtebeek
Have you considered any alternatives or workarounds?
No
Any additional context
It's very similar to the AddNullMethodArgument recipe added last week.
Checklist

[x] I've added unit tests to cover both positive and negative cases
[x] I've read and applied the recipe conventions and best practices
[x] I've used the IntelliJ IDEA auto-formatter on affected files

Thanks, I didn't know valid existed, nice!


Fix devtools imports in preparation to Bug 912121

This PR is related to firebug/rdp-inspector#68 and introduce the new imports urls as described in https://github.com/jryans/devtools-migrate/blob/master/README.md
The idea is to concentrate all the imports in a new firebug.sdk/core/devtools module and use it to import the required components (and be retrocompatible to the previous paths)
It's still untested but I'm opening it just to keep track of it.
I need to build a recent version of firefox from mozilla-central and fix the remaining imports in the rdp-inspector itself to be able to fully test it.
TODO:

[ ] test the patch on a recent mozilla-central build

I am merging this, so I can continue fix other extensions.
Honza


Added python3 support

Added python3 support mantaining backward compatibility. Tests all succeed. Please note test_fuzzy_string_typing is useless in python3. Hope you will merge, please let me know if something doesn't add up, so I can fix. Thank you.

This is awesome. Everything looks good to me. I'll get this merged and push a new release to PyPI when I have time.


Feature: Global configmaps and secrets

This might be a little bit crazier than the last one, but I keep getting asked why it's not possible to have a global/default configmap or secret.  It seems that with RBAC enabled, and control over what gets written to the default namespace this is reasonable.
It would be awesome if something like konfd would enable this with an annotation on a resource in the default namespace, something like:
konfd.io/is-global: "true"
I can see the case being made that it should only behave as a default (given the namespace name) and should not overwrite existing resources in other namespaces if they already exist.

I wrote this to solve similar problems with our clusters https://github.com/verloop/nsync

This is pretty interesting, but I think it will make things super hard to reason about. How to handle errors when data is not available in all namespaces to resolve the template?


Migrate off @azrue/ms-rest-js

It looks that old version of autorest typescript generator was used to generate code that depends on @azure/ms-rest-js? Please consider moving to use latest autorest.typescript code generator as @azure/ms-rest-js is no longer actively maintained.
Free free to reach out if you have any questions.

The "kudu" package in this repository is dead and just awaiting removal. The "dev" package still depends on @azure/ms-rest-js and some other Track 1 packages, but they are treated as dev-only packages in what is released, so @azure/ms-rest-js will no longer be in bundles shipped to customers. However, we should proceed with removing it entirely from these two remaining places.