Build time gzip + brotli compression

Describe the feature
Howdy,
Are there any plans to add gzip + brotli compression during build time? i.e CompressionWebpackPlugin.
Babel plugin or link to the feature description
No response
Additional context
No response

Bundler plugin is not directly relavant to swc's core. If someone wants those features they might build plugins.


Php cs fixer added and fixed SF6 deprecation notice

subj.
Plase adjuct .scrutinizer.yml config if necessary.

Can this be merged? the deprecation notice is really annoying on 8.2! :)


rustc: correct propagation of NIX_BUILD_CORES

Also attempted to override the BOOTSTRAP_ARGS via makeFlags but did not have any success.
Motivation for this change

compilation of rustc bootstrap will default to as many cores as available. This may exceed NIX_BUILD_CORES requested

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Failure on x86_64-darwin (full log)
Attempted: rustc
Partial log (click to expand)
   Compiling parking_lot v0.5.3
   Compiling env_logger v0.4.3
   Compiling flate2 v1.0.1
   Compiling rls-span v0.4.0
   Compiling rustc_data_structures v0.0.0 (file:///private/tmp/nix-build-rustc-1.25.0.drv-0/rustc-1.25.0-src/src/librustc_data_structures)
   Compiling rls-data v0.15.0
   Compiling syntax_pos v0.0.0 (file:///private/tmp/nix-build-rustc-1.25.0.drv-0/rustc-1.25.0-src/src/libsyntax_pos)
   Compiling rustc_errors v0.0.0 (file:///private/tmp/nix-build-rustc-1.25.0.drv-0/rustc-1.25.0-src/src/librustc_errors)
building of '/nix/store/0xbchrdwp5is09d5pbg1pnx9j1hwlqfb-rustc-1.25.0.drv' timed out after 1800 seconds
error: build of '/nix/store/0xbchrdwp5is09d5pbg1pnx9j1hwlqfb-rustc-1.25.0.drv' failed

Success on x86_64-linux (full log)
Attempted: rustc
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/yyaf8lp2mvqls2flyb8nspg5s1mlpam3-rustc-1.25.0-man
gzipping man pages under /nix/store/yyaf8lp2mvqls2flyb8nspg5s1mlpam3-rustc-1.25.0-man/share/man/
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/yyaf8lp2mvqls2flyb8nspg5s1mlpam3-rustc-1.25.0-man
checking for references to /build in /nix/store/yyaf8lp2mvqls2flyb8nspg5s1mlpam3-rustc-1.25.0-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/hyxpgwsibyaa3g81gfzk8mqpszcca0i9-rustc-1.25.0-doc
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/hyxpgwsibyaa3g81gfzk8mqpszcca0i9-rustc-1.25.0-doc
checking for references to /build in /nix/store/hyxpgwsibyaa3g81gfzk8mqpszcca0i9-rustc-1.25.0-doc...
/nix/store/s92vr5q33vry5caipwi2lsqz6zdf9g7c-rustc-1.25.0

Failure on aarch64-linux (full log)
Attempted: rustc
Partial log (click to expand)
   Compiling syntax_pos v0.0.0 (file:///build/rustc-1.25.0-src/src/libsyntax_pos)
   Compiling rls-span v0.4.0
   Compiling rls-data v0.15.0
   Compiling rustc_errors v0.0.0 (file:///build/rustc-1.25.0-src/src/librustc_errors)
   Compiling backtrace v0.3.5
   Compiling proc_macro v0.0.0 (file:///build/rustc-1.25.0-src/src/libproc_macro)
   Compiling rustc_const_math v0.0.0 (file:///build/rustc-1.25.0-src/src/librustc_const_math)
   Compiling syntax_ext v0.0.0 (file:///build/rustc-1.25.0-src/src/libsyntax_ext)
building of '/nix/store/faqa7mm1i55kf6yvi5xqy1lz4139sm23-rustc-1.25.0.drv' timed out after 3600 seconds
error: build of '/nix/store/faqa7mm1i55kf6yvi5xqy1lz4139sm23-rustc-1.25.0.drv' failed


Pauli to dense, matrix division and tests added.

From the #34 converting pauli to dense using full.
Matrix division support added for A*X == B where A & B areAbstractQuMatrix & AbstractQuMatrix and A & B are AbstractQuMatrix and AbstarctQuMatrix.
Tests added.

Looks good to me.

Looks good to me as well! Ready to merge?

Sure, go ahead.
Just as an info: we decided making sigma* dense, because the sparse format introduces quite some memory overhead for those small matrices and they are actually not really sparse (2 of 4 elements nonzero).

Makes sense! Hopefully fixed-size matrices will become a thing sometime soon...

That would be really awesome!

:+1 that was fast :)


Clean up the CSV file from disk after it is downloaded

They are taking up too much space on the server.

https://github.com/magpie-ea/magpie-backend/commit/c04612b57231611f5188305963d6b7a8aa4f8d12


[5.1] Add return statement to determine callback failures

When using chunk() method from query builder, you need to determine whether callback failed on some chunk or everything worked as expected, so I've added return statements for chunk() method

You forgot to update the other chunk methods.

I've done that now, but only on 5.2.


Update dataset and resource table ids

@turnerm Is 0.8.0 the right version here?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

4 of 4 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.03%) to 91.86%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
948

Relevant Lines:
1032

💛  - Coveralls

@mcarans here are some changes I made to let me start the refugees pipeline - feel free to pull in and we can delete the branch.


getInput on a picklist does not return the name of the option

During development of a new VSTS task  using Node I created a task.json file with an input of a picklist for the task parameters.
        {
            "name": "action",
            "type": "picklist",
            "label": "Action",
            "defaultValue": "Create Resource Group and Storage Account",
            "required": true,
            "groupName": "AzureStorageDetails",
            "helpMarkDown": "Action for this task to perform",
            "options": {
                "create": "Create Resource Group and Storage Account",
                "delete": "Remove Resource Group and Storage Account"
            }
        }

The dropdown displays correctly in the task parameters when the task is selected in the build tasks.
However when using getInput within the task the value returned is the friendly description and not the name of the option.
The following code:
value = tl.getInput('action', false)

Produces the following output in the debug log.
2018-05-21T11:04:00.2718888Z ##[debug]action=Create Resource Group and Storage Account
This happens on versions 2.131 and 2.133 of the VSTS agent.
The agent itself is an Ubuntu 16.04 box

should the defaultValue be "create"?


update kubebuilder

Signed-off-by: Will Kutler<EMAIL_ADDRESS>https://github.com/open-cluster-management/backlog/issues/15525

/cherry-pick release-2.3

/cherry-pick release-2.3


Incompatible with Desolation

Mod Name
Desolation
Mod Homepage
https://www.curseforge.com/minecraft/mc-mods/desolation
Minecraft version
1.20.1
Describe the bug
Game crash on startup with Desolation installed.
Steps to reproduce

Install Forgified Fabric API, Connector and Connector Extras
Install Trinkets
Install Desolation
Launch the game
...

Logs
https://pastebin.com/1mDaDVVa
Additional context
Crash Report: https://pastebin.com/R6x1SbSR

You'll need to use the Fabric version of Geckolib to make Desolation work. However, there might be incompatibility issues related to it if you're also running Forge mods that require Geckolib, as explained in #231.

I do have the forge version of Geckolib installed. Does this mean that I can't run both fabric and forge version together?

Unfortunately no, Geckolib Forge and Fabric are incompatible with each other due to both not having a multiloader system inside both mods.


[Hue] - CDPD-32891 - Cloud Break Template change for QP

Already merged the below PR in master branch: https://github.com/hortonworks/cloudbreak/pull/12735

We introduced a new service "QueryProcessor" in this PR.
Regarding testing, I have doe the testing for the below 8 cases and also got it verified by @lajosrodek.
AWS:

7.2.15 - Data Engineering for AWS      - RAZ
7.2.15 - Data Engineering HA for AWS   - RAZ
7.2.15 - Data Engineering for AWS      - Non-RAZ
7.2.15 - Data Engineering HA for AWS   - Non-RAZ

Azure:

7.2.15 - Data Engineering for Azure      - RAZ
7.2.15 - Data Engineering HA for Azure   - RAZ
7.2.15 - Data Engineering for Azure      - Non-RAZ
7.2.15 - Data Engineering HA for Azure   - Non-RAZ

@Amlesh1902 thx! Although I still do not see the urgency here and as I mentioned, only fixes for regressions should come into release branch.
We already have a build for promotion and validation is already started for that build.
cc @foldik @agov

Actually, the main reason is that we are sunsetting the DAS product completely as it is not fully stable and is having so many issues. After R30, we are planning to sunset the DAS from CDW and everywhere.
So currently we are incorporating all the DAS features in Hue along with some optimisation, and hence we create a new service Hue-QueryProcessor.
So, it’s a must go feature for 7.2.15. For that, the CSD changes have already been checked in to the 7.2.15 release, and only the CB changes (this PR) needs to be merged. Until and unless this template changes gets released, the customer have to install the QP service manually which is not good.
So, i checked with the CB team @lajosrodek, and my PR was already approved and it was supposed to land in 2.57. Only there were some issues in rebasing it. However, i was expecting it to get merged in 2.57.
Also as i already mentioned, i already have performed all the 8 cases of testing for both AWS and Azure and got it verified by @lajosrodek

2.57 reached prod.
We'll wait one approve from @hortonworks/cloudbreak-wolf team.
we might include and deploy this if there is a hotfix required for 2.57, but not going to do a release for just the sake of this change.

@Amlesh1902 I just noticed that this and the former master PR only targeted the 7.2.15 blueprints. We since have 7.2.16 ones as well, so I believe the Hue changes made here shall be also applied there to be consistent. I do not mind having a separate PR for that, up to you. In any case, 7.2.16 is already in CB-2.57.0 (even though the actual images may not get released to Stage & Prod), so ideally the 7.2.16 changes would have to also land in CB-2.57.0.
@horadla23 @lnardai Your opinion is most welcome in that regards. :smile:

Do we still need this? 2.57 is released and 2.58 is created so 2.58 will eventually contain this change.

No response,closing


LaunchPad Platform using Ink! Smart Contract

Project Abstract
ArtZero & InkWhale team is developing a decentralized LaunchPad using Ink! Smart Contract. All the work will be available for the public to reuse on Github. The project is being built and tested on Aleph Zero network but can be deployed on any parachains or Substrate-based blockchains that support Ink! such as Astar, Aleph Zero and 5ireChain.
After successful Grant Delivery of ArtZero and InkWhale as well as successful launch of NFT Marketplace ArtZero. We would like to create more useful dapps for the ecosystem, not only for us to use but for the public to see how powerfull Ink! Smart Contract is. This decentralized LaunchPad is the first LaunchPad developed using Ink!
Grant level

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $30,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied and aptly renamed (project_name.md).
[x] I have read the application guidelines.
[x] Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
[ ] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

I have read and hereby sign the Contributor License Agreement.

Hey team, thanks for the application. Could you explain the rationale behind storing Full Project Information on-chain via IPFS rather than other methods? How are you planning to address the potential regulatory challenges, especially concerning token sales and KYC?
Also In the design it says BNB, BUSD tokens. Those are not supported on substrate chains.

Thanks for the application. I have one quick initial question: Have you looked at https://www.polimec.org/? In general, there are a lot of regulatory problems that you might want to look into. Regarding the project information, I assume you plan to store only hashes on-chain and the data on IPFS, correct? How do you ensure that the data is available in this case? We had a couple of IPFS-related pallet projects in the past, but so far, I don't think any ink! focused projects that tried to overcome potential issues.

We packed all information to a json file then upload to IPFS server to get the HASH, this Hash is updated to the contract. This method reduces a lot of storage fee when saving data on-chain.
Regarding legal matters, There are 2 KYC processes in the platform and we use BlockPass as third-party KYC service.

Firstly, KYC is required for project creators. After submitting the project, the project is in disabled mode and our team will send a KYC link to the project owner via email. After KYC is completed, the project will be enabled by our admin.
Secondly, project owner can choose to KYC all participants or not by enabling Whitelist feature in the platform. It means the project will be in Private Mode, and Public Mode is disabled. Only users in whitelist can participate in the sale. Project owner has to add KYCed addresses via our Whitelist manager. This KYC process is optional for the project owner.

Hey team, thanks for the application. Could you explain the rationale behind storing Full Project Information on-chain via IPFS rather than other methods? How are you planning to address the potential regulatory challenges, especially concerning token sales and KYC?
Also In the design it says BNB, BUSD tokens. Those are not supported on substrate chains.

Please check the answer above.
For the design question, I will ask the designer to update the token symbol, but in our actual implementation, we already change the token symbol to AZERO

Thanks, i had some more queries:

Given that this is the first LaunchPad developed using Ink!, how do you plan to educate and onboard potential users and project owners?
How do you foresee the LaunchPad enhancing the adoption of Ink! Smart Contracts in the broader blockchain ecosystem?
While you mentioned that an external audit of the code is out of scope for this proposal, when do you anticipate having the code audited, and have you identified potential auditors?

Thanks, i had some more queries:

Given that this is the first LaunchPad developed using Ink!, how do you plan to educate and onboard potential users and project owners?
We are well known in Aleph Zero ecosystem and we already in contact with several projects to launch on our platform. Fyi: our engineers are also working on kyc integration which allow project owners to perform the checking and whitelist the kyced address. I think this feature will be one of our greatest usp as even pinksale doesnt have it yet. Our marketing team has planned a series of contents to educate users about all features of the platform and it will be on our social media such as X (twitter), medium, telegram and discord
How do you foresee the LaunchPad enhancing the adoption of Ink! Smart Contracts in the broader blockchain ecosystem?
We have queries from several project owners who are lack of technical skills and dev team and they want to launch projects such as meme coins. These kind of projects will be the ones which needs the launchpad the most at the beginning of the platform launch. However I believe the launchpad will reduce a lot of dev cost for other project owners so they can focus resources on their core product. We plan to deploy the platform on Aleph Zero and then 5ireChain and other Substrate based blockchains in the near future.
While you mentioned that an external audit of the code is out of scope for this proposal, when do you anticipate having the code audited, and have you identified potential auditors?
Brushfam did the audit for our nft marketplace contracts and we are already working closely with them to do contract audit for the launchpad

The figma design has been updated with new token symbol, our design team is working on adding kyc feature to the UI

our policy

Hi @keeganquigley
Thanks for your feedbacks. We are trying to keep the team going in this tough bear market by getting supported from multiple sources. We think that we have to keep building missing pieces with high quality for the ecosystem to be able to  get the support. The token sale from the public was not enough for the team of 12 people in the longer term and also this LaunchPad project is considered more like a different project from our initial idea of a staking platform.
To be honest, We are already part of EFP and got a grant from Aleph Zero but its for Marketing activities and Legal setup. Our marketing team is working hard to promote the platform as well as attracting more developers in Vietnam to use Ink! Smart Contract. We use the grant to sponsor the Polkadot hackathon in Vietnam for ink! smart contract track and do a lot of promotion and PR campaigns. The reason we applied for W3F grant because we think the technical development of this project will serve a broader range of users, not only from Aleph Zero but also Polkadot and all Substrate-based blockchains. From the beginning, we always keep all of our source code open for the public and I believe many have been using our code for their development. We can separate this project out of Ink Whale platform using different brand but we choose not to do so. ArtZero and Ink Whale already has trust in the ecosystem, our code will be more accessible for the dev.
Regarding the token question, we don't need token generator in the launchpad, we only create LaunchPad generator as factory contract, LaunchPad Core Contract and the token contract is for testing purposes. The token contract also requires a very small work to compare with other 2 contracts.

@nad128668 due to the issues already raised by other members of the W3F grants committee, namely regulatory concerns, overlaps with existing implementations, concerns related to data availability and your past token sale we concluded that this proposal might not be a good fit for our program. Therefore, I'm going to close this pull request. On behalf of the committee I'd like to thank you for the interest in our program and would like to add that you're welcome to apply for another grant again in the future. Thanks for your understanding, we wish you all the best for your project!


[BUG] Application panics when opening large page

General Information
Version: 0.9.1
Installation Method: cargo install --locked
Operating System: MacOS 15.0 Beta (24A5298h)
Used configuration (if available):
didn't touch the config

Describe the bug
On querying for "World War 2", so a long post, the application panics. On searching smaller articles such as "wort" it works well. It only panics on said page.
To Reproduce
Steps to reproduce the behavior:

Open wiki-tui
Query "World war 2"
Press enter
See error

Expected behavior
I would expect the program to work. Or at least not panic.
Crash report
The application panicked (crashed).
Message:  assertion failed: self.is_char_boundary(n)
Location: /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/string.rs:1908

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
Well, this is embarrassing.

wiki-tui had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "/var/folders/13/phqbdkfx4pq4y30h8rf66dhm0000gn/T/report-8a0420a1-824e-4790-9627-327dfa4a7a85.toml". Submit an issue or email with the subject of "wiki-tui Crash Report" and include the report as an attachment.

- Homepage: https://wiki-tui.net
- Authors: builditluc<EMAIL_ADDRESS>
We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.

Thank you kindly!

Checklist

[x] checked other issues for the same bug
[x] read CONTRIBUTING.md

Here the report file:
name = "wiki-tui"
operating_system = "Mac OS 15.0.0 [64-bit]"
crate_version = "0.9.1"
explanation = """
Panic occurred in file '/rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/string.rs' at line 1908
"""
cause = "assertion failed: self.is_char_boundary(n)"
method = "Panic"
backtrace = """

   0: 0x1053a5f48 - core::panicking::panic_fmt::h33e40d2a93cab78f
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72
   1: 0x1053a5fd0 - core::panicking::panic::h57fd475c037a9df3
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:144
   2: 0x10500c890 - alloc::string::String::replace_range::h840035fcf0033525
   3: 0x104f8b3bc - <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold::h233bd55775b1b881
   4: 0x104f7b090 - <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter::h3673a9f044b9e8c7
   5: 0x104fb3dec - wiki_tui::components::page::PageComponent::render_contents::h47b0d19a4dc67c72
   6: 0x104fb72d0 - <wiki_tui::components::page::PageComponent as wiki_tui::components::Component>::render::hf3c276c6895c1922
   7: 0x104ffb178 - <wiki_tui::app::AppComponent as wiki_tui::components::Component>::render::h259bbe9745e84800
   8: 0x104f4b52c - ratatui::terminal::terminal::Terminal<B>::draw::h6380525214404c66
   9: 0x104f34b44 - tokio::runtime::park::CachedParkThread::block_on::h30cfda1ecd5d2986
  10: 0x104f52e70 - wiki_tui::main::h0f7f8c0679eb86db
  11: 0x104f4abd0 - std::sys_common::backtrace::__rust_begin_short_backtrace::he7e163ba7145aef1
  12: 0x104f4bcb0 - std::rt::lang_start::{{closure}}::ha6e2eef459f832d7
  13: 0x105353814 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hde2a2ae1d756c37f
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:284
                 - std::panicking::try::do_call::h96b73f4da16ee7c5
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552
                 - std::panicking::try::h2cb0c14c1266f147
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516
                 - std::panic::catch_unwind::hb8cd2580f659030d
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142
                 - std::rt::lang_start_internal::{{closure}}::h00f9c2d0117ea0ef
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148
                 - std::panicking::try::do_call::h134dfd8876bcc105
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552
                 - std::panicking::try::h6595e056250d6043
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516
                 - std::panic::catch_unwind::haad85d5172c9b53a
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142
                 - std::rt::lang_start_internal::hf4f3eb1e51305b96
                at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148
  14: 0x104f53078 - _main"""

Thank you @d-rens for your bug report!
I've successfully reproduced the issue. The problem lies with our generation of the ... filler when the toc item is longer than the width of the toc.

Does this only happen if one does not have a config file? I don't see this?!?

@0323pin try increasing the fontsize and decreasing the window width to "take space in the TOC", that's how it should break, at least for me.


Ask about updating Bert baseline model

Hi, could you update these llm models(Bert, senBert and Roberta)? Now I only saw other chatgpt models instead of them.

Same question

Thank you for your friendly reminder! You can use gnn/st_embeddings.py to obtain the text embeddings, and use gnn/mlp.py to train a model as text classification task. We update README.md in commit 8fbc9370251baa16445020dbde44dc5da69ad960.


fix: compile error in musl target env

Reason for This PR
failed to compile in musl target env
Description of Changes
fix compile error for musl target env
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license.
PR Checklist
[Author TODO: Meet these criteria.]
[Reviewer TODO: Verify that these criteria are met. Request changes if not]

[ ] All commits in this PR are signed (git commit -s).
[ ] The reason for this PR is clearly provided (issue no. or explanation).
[ ] The description of changes is clear and encompassing.
[ ] Any required documentation changes (code and docs) are included in this PR.
[ ] Any newly added unsafe code is properly documented.
[ ] Any user-facing changes are mentioned in CHANGELOG.md.

Codecov Report

Merging #11 (75f5e39) into main (d2126ee) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #11   +/-   ##
=======================================
  Coverage   95.98%   95.98%
=======================================
  Files           9        9
  Lines        2542     2542
=======================================
  Hits         2440     2440
  Misses        102      102

Impacted Files
Coverage Δ

src/common/sock_ctrl_msg.rs
97.60% <100.00%> (ø)

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Focus state for hamburger is missing a side

Detailed description

Describe in detail the issue you're having.

The focus state for the hamburger X opened state is missing its right side.

What did you expect to happen? What happened instead? What would you like to see changed?

The whole icon button would have the focus.

What browser are you working in?
Chrome

Steps to reproduce the issue

Open the site in a narrow width so the left nav collapses into the hamburger
open the left nav by using the hamburger icon.

moving to theme repo


Add settings for changing the workbench font size and font

This PR fixes #519.
This does need to be refined a bit; I did this rather hastily.

This PR adds the settings necessary for setting a font size and font family for the workbench and applies it in themeing.ts. I'm not sure if anything else is necessary like watching for changes to the settings and applies them retroactively.

@sbatten, any word?

Same discussion starting from https://github.com/microsoft/vscode/pull/63602#issuecomment-472025321 applies here again.

Same discussion starting from #63602 (comment) applies here again.

Ah, okay, I see the issue. I will attempt to find as many instances as I can of certain pixel values being hardcoded and alter them.

I think I got all of the hardcoded values, but I'm not entirely sure.

👍💯✅

Tests should be green now.

The PR is very large. I wonder if maintainers are more likely to accept it if we split the PR:

A first PR that does the safe refactor-only changes (pass IConfigurationService around).
A 2nd PR that replaces the constants with the computed sizes.

If the first PR is merged and the 2nd PR is small enough, my team at Google can help test it and iterate on it.

I'm going to close this for now while @laurentlb and I work towards splitting this PR up and getting changes made through at a much slower and more deliberate pace.

@ElijahPepe @laurentlb thanks for doing that. Please ping me on any new PRs you open.


Fix README.md smush32 link

I have done this pr from the browser editor, hope it is correct 😅

Thank you, dear @nkint! 🙏

Thank you, dear @nkint! 🙏

@nkint btw. just a kind reminder to fix any readme issues not in README.md, but always in tpl.readme.md - otherwise those changes will be overwritten again when the readme files are being re-generated the next time... (The only exception to that is the main readme in the project root)
See here for reference :)

@nkint btw. just a kind reminder to fix any readme issues not in README.md, but always in tpl.readme.md - otherwise those changes will be overwritten again when the readme files are being re-generated the next time... (The only exception to that is the main readme in the project root)
See here for reference :)


fix bit shift runtime error

Stumbled upon an issue while using GLFW in a project:
src/x11_window.c:1274:72: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
Had a look inside the file. it seems that either the value (1 << 31) is a mere 'inf value', or, perhaps a check to make sure 'diff' itself wont overflow on its own. Proposed change is to simply lower the value a little (by half, for ease). If the value must be exactly (1 << 31), though, perhaps using some other datatype like a long value is better, or just change the condition to (diff <= (1 << 31) - 1) which is achievable without ever casting away from int, maybe use 'INT_MAX'.
I encountered the error after adding glfwCallbacks and then pressing the same keyboard key twice; to be exact, the first instance of pressing some key for the second time during runtime triggered the error, after that the error wouldn't reappear until relaunching the program.
EDIT: I am using Ubuntu 20.04

Sorry for the delay. This has been merged now as b54fb0af10bb0167df67fece984350e66bf569ce. Thank you for the fix!


fix: align chain id

Aligns chain IDs

my PR fixes this already

but we'll need to publish

my PR fixes this already

Where?


improve response time of invalid rename attempts

Fixes #45942
it seems work is done computing RenameLocation[] we're not going to use, as the rename attempt response body log includes:
{
   "info":{
      "canRename":false,
      "locs":[ // many !nodeIsEligibleForRename items here]
   }
}

on my machine returning an empty locs makes the response time fast and pretty constant, about 3ms compared to a few seconds. (in large projects)

TS repo, 3 runs each
before:
6359.3685ms
2650.6442ms
8156.8394ms
after:
2.8690ms
0.3090ms
0.3085ms

i've inlined some questions on the changes i did as i'm not sure about some stuff.

Thanks @orouz! This seems reasonable to me, but I’ll need to double check next week that these locations don’t get used by the editors in anyway when canRename is false. canRename can be false both for syntactic (nodeIsEligibleForRename) and semantic (the definition was in a library file) reasons, and in the latter case, locations can be computed. It may be the case that we still want to have those locations when they exist, but I’m not sure.

Confirmed that VS Code does not inspect locs if canRename is false. @amcasey, any concerns about this on the VS side?


Retrieve Latest - Recent posts

This should be a custom template tag rather than extension of  view queries

Check out C3 P52


Warning when starting up a controller and model not moving

I am currently using ROS2 Humble and I am trying to use this package. Everything seems to be working just fine except for the controllers.
Whenever I startup a controller, whether it is test_joint_trajectory_controller or test_scaled_joint_trajectory_controller I end up with the following warnings and the robot not moving.

$ ros2 launch ur_robot_driver test_joint_trajectory_controller.launch.py
[INFO] [launch]: All log files can be found below /home/hossam/.ros/log/2022-09-02-16-06-44-571462-hossam-83472
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [publisher_joint_trajectory_controller-1]: process started with pid [83474]
[publisher_joint_trajectory_controller-1] /opt/ros/humble/local/lib/python3.10/dist-packages/rclpy/node.py:441: UserWarning: when declaring parameter named 'joints', declaring a parameter only providing its name is deprecated. You have to either:
[publisher_joint_trajectory_controller-1] 	- Pass a name and a default value different to "PARAMETER NOT SET" (and optionally a descriptor).
[publisher_joint_trajectory_controller-1] 	- Pass a name and a parameter type.
[publisher_joint_trajectory_controller-1] 	- Pass a name and a descriptor with `dynamic_typing=True
[publisher_joint_trajectory_controller-1]   warnings.warn(
[publisher_joint_trajectory_controller-1] /opt/ros/humble/local/lib/python3.10/dist-packages/rclpy/node.py:441: UserWarning: when declaring parameter named 'starting_point_limits', declaring a parameter only providing its name is deprecated. You have to either:
[publisher_joint_trajectory_controller-1] 	- Pass a name and a default value different to "PARAMETER NOT SET" (and optionally a descriptor).
[publisher_joint_trajectory_controller-1] 	- Pass a name and a parameter type.
[publisher_joint_trajectory_controller-1] 	- Pass a name and a descriptor with `dynamic_typing=True
[publisher_joint_trajectory_controller-1]   warnings.warn(
[publisher_joint_trajectory_controller-1] /opt/ros/humble/local/lib/python3.10/dist-packages/rclpy/node.py:441: UserWarning: when declaring parameter named 'pos1', declaring a parameter only providing its name is deprecated. You have to either:
[publisher_joint_trajectory_controller-1] 	- Pass a name and a default value different to "PARAMETER NOT SET" (and optionally a descriptor).
[publisher_joint_trajectory_controller-1] 	- Pass a name and a parameter type.
[publisher_joint_trajectory_controller-1] 	- Pass a name and a descriptor with `dynamic_typing=True
[publisher_joint_trajectory_controller-1]   warnings.warn(
[publisher_joint_trajectory_controller-1] /opt/ros/humble/local/lib/python3.10/dist-packages/rclpy/node.py:441: UserWarning: when declaring parameter named 'pos2', declaring a parameter only providing its name is deprecated. You have to either:
[publisher_joint_trajectory_controller-1] 	- Pass a name and a default value different to "PARAMETER NOT SET" (and optionally a descriptor).
[publisher_joint_trajectory_controller-1] 	- Pass a name and a parameter type.
[publisher_joint_trajectory_controller-1] 	- Pass a name and a descriptor with `dynamic_typing=True
[publisher_joint_trajectory_controller-1]   warnings.warn(
[publisher_joint_trajectory_controller-1] /opt/ros/humble/local/lib/python3.10/dist-packages/rclpy/node.py:441: UserWarning: when declaring parameter named 'pos3', declaring a parameter only providing its name is deprecated. You have to either:
[publisher_joint_trajectory_controller-1] 	- Pass a name and a default value different to "PARAMETER NOT SET" (and optionally a descriptor).
[publisher_joint_trajectory_controller-1] 	- Pass a name and a parameter type.
[publisher_joint_trajectory_controller-1] 	- Pass a name and a descriptor with `dynamic_typing=True
[publisher_joint_trajectory_controller-1]   warnings.warn(
[publisher_joint_trajectory_controller-1] /opt/ros/humble/local/lib/python3.10/dist-packages/rclpy/node.py:441: UserWarning: when declaring parameter named 'pos4', declaring a parameter only providing its name is deprecated. You have to either:
[publisher_joint_trajectory_controller-1] 	- Pass a name and a default value different to "PARAMETER NOT SET" (and optionally a descriptor).
[publisher_joint_trajectory_controller-1] 	- Pass a name and a parameter type.
[publisher_joint_trajectory_controller-1] 	- Pass a name and a descriptor with `dynamic_typing=True
[publisher_joint_trajectory_controller-1]   warnings.warn(
[publisher_joint_trajectory_controller-1] [INFO] [1662127605.094305894] [publisher_joint_trajectory_controller]: Publishing 4 goals on topic "/joint_trajectory_controller/joint_trajectory" every 6 s`

I have been reading about the rclpy API but it seems like I am missing something.
I don't think it has to do with the YAML file and I tried adding allow_undeclared_parameters=True, automatically_declare_parameters_from_overrides=True to the Node in the launch file but I ended up with a different error so I guess this was not a potential solution.

Hi @7ossamamr, can you please provide more information about your setup? This warning should not change anything in the behavior. If you want, please check a new version of ros2_controllers, which has a new PR with updates on test nodes.
Are you running the real robot, ursim, Gazebo simulation or mock hardware simulation?

Hello @destogl, thank you for suggesting checking the new ros2_controllers. Now I am using the new version along with ros2_controls as well and the controller seems to be working fine. It is publishing the target joint states which was not the case before, it used to be stuck after the last info message as I posted earlier. However, the model is not moving in any of the cases, neither in the mock hardware nor in the ursim and of course I still haven't tried running the real robot before getting a running simulation.
Maybe I will state some points that might be useful.

Model is respawning properly in RViz
Model is connected properly to the ursim, as any joint configuration in the ursim is readable in ROS and reflected in the RViz model
Controllers are working fine. I checked the published topics and now they are normally updated with the new joint states rather than being blank as before.
Controllers are able to detect the robot's current state. As they would return an error if they were started when the robot is in a different position than what is defined in the joint limits yaml, in this case it is the default homing position.

But still nothing is moving. I will try to clone the UR repo and rebuild it again maybe it works, I will update you with whatever turns to be.


How to use it with Angular4

HI I am facing issue with Ng4 app that is generated with angular cli.
Nadeems-MacBook-Pro:buzzdir nadeemakhtar$ npm i ng2-select --save
<EMAIL_ADDRESS>/Applications/www/buzzdir
├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.

as i search from the web, it have a fork 'ng2-select-compat' for angular 4

ng2-select-compat is not working

@bymeftun have you found any solution???

ng2-select-compat is working for angular 4


better name for a test: threads -> sync

@bors r+

:pushpin: Commit e44d38e0511376b73e1a17588780b21c359789f6 has been approved by RalfJung

:hourglass: Testing commit e44d38e0511376b73e1a17588780b21c359789f6 with merge aeb658e8bd5ef344c9843545c6ab0cb8bd800c2b...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing aeb658e8bd5ef344c9843545c6ab0cb8bd800c2b to master...


Reformatting code cells to fit display width

A lot of the code cells are shown with their right side cut off due to the overly-narrow notebook display on readme.io.

This change is


Display does not work on bl5340_dvk

Describe the bug
PR #64587 unintentionally changed the SPI device used for the display on the bl5340_dvk to spi2 from spi4. This breaks the functionality of the display.
To Reproduce
Steps to reproduce the behavior:

west build -p always -b bl5340_dvk//cpuapp samples/drivers/display
west flash
display will not function

Expected behavior
Display should work
Additional Context
Issue reported (and fix suggested) by @dberlin here

Duplicate of https://github.com/zephyrproject-rtos/zephyr/issues/75967

lol... okay. Daniel reached out internally (he is traveling around the world) and asked for someone to submit...

No worries - i had suggested he do it originally, but discovered a clean zephyr client laying around so just built and tested it myself :)
Hopefully he's enjoying his travel.


Simplify argument parsing and processing in the plugin

Bug/issue #, if applicable:
Summary
This greatly simplifies the processing of command line arguments for the plugin itself, for what the plugin prepares for DocC, and for what there plugin prepares for symbol graph extraction.
Like #87, this PR is in preparation for another change. Whenever I've asked people about how they that I structure my PRs they've said that they prefer multiple smaller single-purpose PRs. I'm trying to do just that with this PR.
The purpose of this change is to prepare the code to make it easy to make a follow up PR that intercepts and customizes the --output-dir argument to allow using it when building documentation for more than one target. A secondary purpose of this change is to have a testable (and tested) foundation for parsing and processing the command line arguments in the plugin.
This is very close to a non-functional change, but there are a few minor improvements:

The updated help text separates symbol graph options/flags into its own group instead of mixing them with the plugin options.
The updated help text also documents the recently added --symbol-graph-minimum-access-level option.
The updated argument processing fixes a handful of minor bugs with parsing values like --some-option=someValue or correctly not parsing literal values after --.

Dependencies
None.
Testing
Nothing in particular. Run bin/tests.
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[x] Added tests
[x] Ran the ./bin/test script and it succeeded
~[ ] Updated documentation if necessary~ Not applicable.

@swift-ci please test

To make it easier to review this code, here are a handful of things that are worth calling out:

The separation of plugin and symbol graph arguments from the DocC arguments is all in one short file. This file also defines all the plugin and symbol graph arguments.
When someone needs to add a new flag they can easily find this file by going to the declaration of any of the other flags and add the new flag in the same file.

With this, simple construct for extracting arguments for a specific tool, the code that does separates the arguments per tool is easier to follow.

The help text documentation for all the plugin and symbol graph arguments with is in one short file.
When someone needs to add help text for new argument they can easily find this file by going to the declaration of any of the other documented flags and add the new help text in the same file. This was in issue in practice where flags adding help text for flags got deferred because of how complex and spread out it was to implement before.

The docc arguments, with default values, are constructed in a single method.
This code is very linear and easy to follow. For example, compare
- /// The command-line options required by the `docc` tool.
- private static let requiredOptions: [CommandLineOption] = [
-     .fallbackDisplayName,
-     .fallbackBundleIdentifier,
-     .additionalSymbolGraphDirectory,
-     .outputPath,
- ]
-
- // Build up an array of required command line options by iterating through
- // the options that are required by `docc` and setting their default
- // value based on the given context for this invocation.
- let requiredOptions = Self.requiredOptions.compactMap { option -> RequiredCommandLineOption? in
-     let optionValue: String
-     switch option {
-     case .fallbackDisplayName:
-         optionValue = targetName
-     case .fallbackBundleIdentifier:
-         optionValue = targetName
-     case .additionalSymbolGraphDirectory:
-         optionValue = symbolGraphDirectoryPath
-     case .outputPath:
-         optionValue = outputPath
-     default:
-         // This will throw an assertion when running in tests but allow us to fail
-         // gracefully when running in production.
-         assertionFailure("Unexpected required option: '\(option)'.")
-         return nil
-     }
-
-     return RequiredCommandLineOption(option, defaultValue: optionValue)
- }
-
- // Now that we've formed an array of required command line options, along with
- // their default values, insert them into the existing set of arguments if
- // they haven't already been specified.
- for requiredOption in requiredOptions {
-     doccArguments = requiredOption.insertIntoArgumentsIfMissing(doccArguments)
- }
+ arguments.insertIfMissing(.option(DocCArguments.fallbackDisplayName, value: targetName))
+ arguments.insertIfMissing(.option(DocCArguments.fallbackBundleIdentifier, value: targetName))
+ arguments.insertIfMissing(.option(DocCArguments.additionalSymbolGraphDirectory, value: symbolGraphDirectoryPath))
+ arguments.insertIfMissing(.option(DocCArguments.outputPath, value: outputPath))

(I'll also point out that it's misleading to call these "required" since DocC doesn't require of these flags—it requires either a catalog or a symbol graph directory, but not both and not the other two arguments).
or compare
- var requiredOptions: [RequiredCommandLineOption] {
-     switch self {
-     case .library:
-         return []
-     case .executable:
-         return [
-             RequiredCommandLineOption(
-                 .fallbackDefaultModuleKind,
-                 defaultValue: "Command-line Tool"
-             )
-         ]
-     }
- }

- /// Adds the options required for the target kind into the given set of arguments if
- /// they are not already specified.
- ///
- /// For example, ``executable`` target kinds require a fallback default module kind
- /// to be specified. So, if the given arguments do not already contain
- /// "`--fallback-default-module-kind`", that option will be added along with its default value.
- func addRequiredOptions(to arguments: Arguments) -> Arguments {
-     var arguments = arguments
-     for requiredOption in requiredOptions {
-         arguments = requiredOption.insertIntoArgumentsIfMissing(arguments)
-     }

-     return arguments
- }
-
- // Add any required options that are specific to the kind of target being built
- doccArguments = targetKind.addRequiredOptions(to: doccArguments)
+ switch targetKind {
+ case .library:
+     break
+ case .executable:
+     arguments.insertIfMissing(.option(DocCArguments.fallbackDefaultModuleKind, value: "Command-line Tool"))
+ }

Similarly, the code that prepares the symbol graph options is simpler and easier to follow. Compare
- for customSymbolGraphOption in customSymbolGraphOptions {
-     switch customSymbolGraphOption {
-     case .extendedTypes.positive:
- #if swift(>=5.8)
-         symbolGraphOptions.emitExtensionBlocks = true
- #else
-         print("warning: detected '--include-extended-types' option, which is incompatible with your swift version (required: 5.8)")
- #endif
-     case .extendedTypes.negative:
- #if swift(>=5.8)
-         symbolGraphOptions.emitExtensionBlocks = false
- #else
-         print("warning: detected '--exclude-extended-types' option, which is incompatible with your swift version (required: 5.8)")
- #endif
-     case .skipSynthesizedSymbols:
-         symbolGraphOptions.includeSynthesized = false
-     default:
-         fatalError("error: unknown PluginFlag (\(customSymbolGraphOption.parsedValues.joined(separator: ", "))) detected in symbol graph generation - please create an issue at https://github.com/swiftlang/swift-docc-plugin")
-     }
- }

+ if customSymbolGraphOptions.skipSynthesizedSymbols == true {
+     symbolGraphOptions.includeSynthesized = false
+ }
+ if let includeExtendedTypes = customSymbolGraphOptions.includeExtendedTypes {
+ #if swift(<5.8)
+     print("warning: detected '--\(includeExtendedTypes ? "include" : "exclude")-extended-types' option, which is incompatible with your swift version (required: 5.8)")
+ #else
+     symbolGraphOptions.emitExtensionBlocks = includeExtendedTypes
+ #endif
+ }

The core argument processing utility is well tested in this file.

Since all the argument processing uses this, there's no need to repeat the same tests for each flag.
This also fixes some bugs, for example, the old disableIndex flag didn't remove all spellings of the index flag and the old outputPath flag—and all of the other flags—didn't support the --option=value spelling.

@d-ronnqvist  - Why are we implementing our own command line parser instead of using swift argument parser?

@d-ronnqvist - Why are we implementing our own command line parser instead of using swift argument parser?

From what I've understood, the package plugin can't have any external dependencies.

@d-ronnqvist - Why are we implementing our own command line parser instead of using swift argument parser?

Swift Argument Parses doesn't solve what the DocC Plugin needs to accomplish;

separating different arguments for different tools (including forwarding any future unknown arguments) to one of the tools.
preparing command line invocations for other tools by inspecting, adding, and removing raw command line flags and options.

Would it be possible to consolidate all the information about a given argument, i.e. name, spelling, value, default value, help text in one place?

For the flags with documentation I moved everything except the default value into the DocumentedFlag definition in https://github.com/swiftlang/swift-docc-plugin/pull/88/commits/f14201a7fd5f78addde97c5c1830eeadb3f0bf90.
My reason for not moving the default values is that I find that it gets unnecessarily complicated doing so. There are mostly boolean flags but there are also a couple of non-boolean optional arguments (symbol-graph-access-level now and output-path in a follow up PR). I feel that this is an improvement that we can make in the future if we find a need for it then, but for now I prefer to keep the code simpler.

@swift-ci please test

@swift-ci please test

@swift-ci please test

@swift-ci please test macOS

It looks like somewhere between Swift 3e21fc6610cc917 and Swift<PHONE_NUMBER>8c8e8 caused all of the integration tests to fail with a non-zero exit from swift-symbolgraph-extract with these errors:
<unknown>:0: error: unknown argument: \'-Xlinker\'
<unknown>:0: error: unknown argument: \'-rpath\'
<unknown>:0: error: unknown argument: \'-Xlinker\'

@swift-ci please test macOS

I think this will be unblocked tomorrow when https://github.com/swiftlang/swift-package-manager/pull/7903 is available in a development toolchain. If not, we may consider merging https://github.com/swiftlang/swift-docc-plugin/pull/90 while we wait.

@swift-ci please test macOS

@swift-ci please test


Add -n observability so kubectl get deployment command works correctly

This change is

@jpkrohling Yes, that's the only place I needed it.

Thanks!


Fixed the container size by changing the width from 340px to 310px,used

Box sizing property.

Signed-off-by: Bisuz<EMAIL_ADDRESS>

#5

@Bisuz After reading hacktoberfest guidelines I came to know a small change in file cannot be hactoberfeast-accepted, can you find other good issue.


[Perf] Don't recreate ReadOptions when querying the database

Heap profiling indicates that plenty of allocations currently come from the use of rocksdb_readoptions_create, which is an FFI function called internally from get_pinned. This can easily be avoided by creating an instance of ReadOptions just once and reusing it via get_pinned_opt, which is the equivalent of get_pinned with a &ReadOptions parameter.
This change reduces (in a 15-minute run consisting of 4 --dev validators) the average number of allocations per second in a dev node that doesn't produce txs by roughly 30%, which is beneficial for the performance of any heap allocator.

under what conditions do you see the reduction? Is it just normal operation of a node minus any load?

The difference was measured for a --dev 2 node which doesn't produce txs, but participates in consensus.

Would it be possible to profile this under heavy read load?

I requested a devnet run to see the impact with more transactions.

Performed some memory profiling with ~2.5 hours of 25 TPS here.
After the test, snarkOS maximum memory usage was reduced by 8% and average memory usage was reduced by 4.4% through this PR.

A devnet test of this to profile has been kicked off

Observations based on devnet metrics:

memory use is a bit lower, but there is still growth
log frequency is up, suggesting higher average throughput
average block lag is down, and its spikes are much lower
number of threads appears to be a bit down
minor page faults are reduced slightly

Overall, this change results in some small performance wins, and its effects are more significant with workloads that involve many database reads.

I will await for approvals from reviewers prior to merging this one.

Update: the same can be done with WriteOptions; the win is smaller, as we write less frequently.

@joske can you also review this PR?


global toast style?

Need a place (maybe  component) to configure the global toast style.

Planned in next version. Thanks!


Add rule for disallowing .bind in JSX props

A bind call or arrow function in a JSX prop will create a brand new function on every single render. This is bad for performance, as it can result in the garbage collector being invoked way more than is necessary (especially on hot paths with components that have frequent updates). This rule disallows both bind calls and arrow functions, with options to re-enable them (allowBind and allowArrowFunctions respectively) in case you want to only disable one.
Fixes #184.

I like this rule, and the options are very helpful. I really like the ProTip section.
I personally would allowArrowFunctions, but not allowBind.
For non-hot code paths, using the arrow function leads to a more straightforward code, which is more comprehensible than the .bind() counterpart (even though it’s essentially the same). Only when performance impact becomes apparent, then I’ll bind the methods on the constructor.

Thanks! I'll review this asap.
Can you also add the new rule to the README.md file?

Can you also add the new rule to the README.md file?

Will do :) Just let me know if any other changes are required, and I'll do all the updates at the same time.

Currently I don't see any other changes to do, LGTM.

Thanks! I just added the rule to the readme.

Merged. Thank you very much!

Hello ES6 experts!
@Daniel15 mentioned above that:

A bind call or arrow function in a JSX prop will create a brand new function on every single render. This is bad for performance...

Looking at docs such as those from Mozilla, I can see that .bind() creates a new function, corroborating what @Daniel15 mentioned.  However, I am curious about the arrow function.   I have not been able to find something that says that the arrow function would do something similar as far as making a copy (and thus bad for performance in the render method).  Can someone provide a link to a source explaining how the arrow function is similar to bind() in this regard?
I also thought that maybe it had to do with how arrow functions get transpiled - perhaps that they would end up using bind() once transpiled.  But I have not been able to confirm that either.  For example, this test on Babel's online editor shows that this ES6:
function foo() {
  const bar = () => {
    console.log(this.id, arguments);
  }
  bar();
}
foo.call({id: 42}, 'lol');

transpiles to:
'use strict';

function foo() {
  var _this = this,
      _arguments = arguments;

  var bar = function bar() {
    console.log(_this.id, _arguments);
  }; // <----------- Notice .bind() was not added
  bar();
}
foo.call({ id: 42 }, 'lol');

In summary, can someone please show how the arrow function has the same performance problems that bind() suffers from in React's render method?

In general, a new function is created every time the "function" keyword is
encountered, regardless of if you use bind or not. In your example, the
"bar" function only exists inside the closure crested by the "foo"
function. Every call to "foo" results in a new closure, and thus a new
instance of "bar" too. There's nothing special about bar, it behaves like
any other variable.
Some smarter optimisations could be done (such as having just one copy of
"bar" with copy-on-write semantics in case you set properties on the
function itself, like bar.executedAt = Date.now()) but I don't think any
JavaScript engine does that today.
Sent from my phone.
On Mar 18, 2016 6:00 PM, "Jason K Frank"<EMAIL_ADDRESS>wrote:

Hello ES6 experts!
@Daniel15 https://github.com/Daniel15 mentioned above that:
A bind call or arrow function in a JSX prop will create a brand new
function on every single render. This is bad for performance...
Looking at docs such as those from Mozilla, I can see that .bind()
creates a new function, corroborating what @Daniel15
https://github.com/Daniel15 mentioned. However, I am curious about the
arrow function. I have not been able to find something that says that
the arrow function would do something similar as far as making a copy (and
thus bad for performance in the render method). Can someone provide a link
to a source explaining how the arrow function is similar to bind() in this
regard?
I also thought that maybe it had to do with how arrow functions get
transpiled - perhaps that they would end up using bind() once
transpiled. But I have not been able to confirm that either. For example, this
test
https://babeljs.io/repl/#?evaluate=true&presets=es2015%2Creact%2Cstage-2&experimental=true&loose=true&spec=false&code=function foo() {
  const bar %3D () %3D> {
    console.log(this.id%2C arguments)%3B
  }
  bar()%3B
}
foo.call({id%3A 42}%2C 'lol')%3B

on Babel's online editor shows that this ES6:
function foo() {
const bar = () => {
console.log(this.id, arguments);
}
bar();
}
foo.call({id: 42}, 'lol');
transpiles to:
'use strict';
function foo() {
var _this = this,
_arguments = arguments;
var bar = function bar() {
console.log(_this.id, _arguments);
}; // <----------- Notice .bind() was not added
bar();
}
foo.call({ id: 42 }, 'lol');
In summary, can someone please show how the arrow function has the same
performance problems that bind() suffers from in React's render method?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/yannickcr/eslint-plugin-react/pull/274#issuecomment-198596305

@Daniel15 Ok, so the issue with arrow functions is not that they create a new function in the same way that bind() does, but rather that the runtime has overhead involved in creating the closure necessary to execute them?  That makes sense.
I have 2 follow-up questions.

The suggested means to handle this problem (in the linter rule readme) is to create a separate React component to handle the callback situation.  There must additional overhead involved in initializing and rendering this extra React component (e.g., lifecycle methods, render(), etc.).  So how does that added overhead compare to the overhead that would be incurred if you used arrow functions instead?  I assume someone has tests comparing these 2 approaches right?  Does anyone have a link for one?

The React docs, on their "Communicate Between Components" page advocate using bind() to solve this passing-of-arguments problem.  Their example is a list example:

var handleClick = function(i, props) {
  console.log('You clicked: ' + props.items[i]);
}

function GroceryList(props) {
return (

    {props.items.map(function(item, i) {
      return (

{item}

      );
    })}

);
}

ReactDOM.render(
<GroceryList items={['Apple', 'Banana', 'Cranberry']} />, mountNode
);

Is their example different somehow (i.e., is bind() not a performance problem in their case)?
@Daniel15 You work at Facebook, right?  If that example has the same performance problem, is there any chance you'd have some pull to get the docs updated to show the "proper" way?  It would be a lot less confusing for us React noobs then!

@jasonkylefrank This is an interesting question, so I’ve done a quick comparison using Benchmark.js against the development build of React using example code from the rule documentation:
import React from 'react'

const List = React.createClass({
  render () {
    return (

        {this.props.items.map(item =>

            {item.text}

        )}

    )
  }
})

export default List

import React from 'react'

const List = React.createClass({
  render () {
    return (

        {this.props.items.map(item =>
          <ListItem key={item.id} item={item} onItemClick={this.props.onItemClick} />
        )}

    )
  }
})

var ListItem = React.createClass({
  render () {
    return (

        {this.props.item.text}

    )
  },
  _onClick () {
    this.props.onItemClick(this.props.item.id)
  }
})

export default List

This is the input data:
function onItemClick (id) {
  alert(id + ' has been clicked!!')
}

const items = [ ]

for (let i = 0; i < 100; i ++) {
  items.push({ id: i, text: 'Item ' + i })
}

Here’s the benchmark suite:
new Benchmark.Suite()
.add('Single component with bind()', function () {
  render(<Case1 items={items} onItemClick={onItemClick} />, div1)
})
.add('Two components without bind()', function () {
  render(<Case2 items={items} onItemClick={onItemClick} />, div2)
})

Note that div1 and div2 are divs with display: none CSS applied, so that it only tests raw DOM manipulation speed.

Test
Speed

Single component with bind()
x 589 ops/sec ±1.75% (55 runs sampled)

Two components without bind()
x 516 ops/sec ±1.17% (54 runs sampled)

In development, using single component takes 15% less time.
On Production
Now let’s try on production build of React:

Test
Speed

Single component with bind()
x 134,742 ops/sec ±2.91% (57 runs sampled)

Two components without bind()
x 134,721 ops/sec ±2.27% (58 runs sampled)

Even though the numbers are almost close to each other, Benchmark.js reports that Two components without bind() is faster. Maybe %error is taken into account?
But is it really because of whether I use bind or not? I added another test case: Two components but using bind().
import React from 'react'

const List = React.createClass({
  render () {
    return (

        {this.props.items.map(item =>
          <ListItem key={item.id} item={item} onItemClick={this.props.onItemClick} />
        )}

    )
  }
})

var ListItem = React.createClass({
  render () {
    return (

        {this.props.item.text}

    )
  }
})

export default List

Test
Speed

Two components with bind()
137,732 ops/sec ±1.94% (58 runs sampled)

Two components without bind()
137,218 ops/sec ±1.92% (57 runs sampled)

Benchmark.js reports that both ways are equally performant. In my opinion, the performance costs caused by .bind() is negligible. I’d still use .bind() (or arrow functions) in non-critical code paths.
Disclaimer: I just did a preliminary testing in late night. Would be great if someone do a more formalized replication of this test.

Btw, when you call React.createElement, you are creating a new Virtual DOM node every time — just like creating a function. So I think it might make sense to compare what is faster — between creating a new function, and creating a React element.
The tests:
const component = {
  props: {
    onClick (a, b) {
      return a + b
    }
  }
}

new Benchmark.Suite()
.add('Using Function.prototype.bind',
  new Function('return this.props.onClick.bind(null, 1, 2)').bind(component)
)
.add('Using closure',
  new Function('var that = this; return function () { return that.props.onClick(1, 2) }').bind(component)
)
.add('Creating an arrow function',
  new Function('return (() => this.props.onClick(1, 2))').bind(component)
)
.add('Creating a React element', function () {
  React.createElement('div')
})

Note: Function constructor is used to avoid code being transpiled by Babel.
The tests are performed on Chrome 49 on MacBook Pro (Retina, 13-inch, Late 2013)

Test
Speed

Using Function.prototype.bind
x 1,924,886 ops/sec ±2.01% (56 runs sampled)

Using closure
x 26,304,860 ops/sec ±3.26% (52 runs sampled)

Creating an arrow function
x 29,261,815 ops/sec ±1.50% (56 runs sampled)

Creating a React element
x 19,198,690 ops/sec ±3.81% (54 runs sampled)

You can see that Function.prototype.bind is 10 times slower than a function literal. On the other hand, creating a new function using the function literal or arrow function is faster than creating a single React element.

Note that Babel transpiles arrow functions without using .bind(), but by creating a _this variable:
function b () {
  return () => this.props.onClick()
}

function b() {
  var _this = this;

  return function () {
    return _this.props.onClick();
  };
}

Benchmark.js tests might not show the full story, as the main perf cost comes from garbage collection rather than the actual runtime performance of the code itself. It's possible that you're not hitting garbage collection while testing and thus not experiencing a GC pause. It's probably worth watching memory consumption while running the test.
Does your test mount a brand new component every time, or does it update the props on the existing component? I don't see the source code of the render function used in the benchmark suite, is that just the standard ReactDOM.render? A more realistic benchmark might just mount the component once and then do lots of setState calls to re-render the component. I'm not sure if that would affect the results though.

The React docs, on their "Communicate Between Components" page advocate using bind() to solve this passing-of-arguments problem.

Yeah, I'm not a fan of that part of the documentation. I may send a pull request to update it too.

@dtinth Those are great tests!  Thanks for running them!
Your second set of tests (where you compare using bind(), closures, arrow functions, and React.createElement) seem to indicate that arrow functions are significantly faster than using bind().  So what happens if you run your "Single component with bind()" vs "Two components without bind()" tests using arrow functions instead of bind()?

@Daniel15
The render() function comes directly from ReactDOM. What I’ve tried is using calling render() with the same DOM node, so it is the same as mounting once and call setState(). I’ve tried using Chrome’s timeline developer tools to capture the timeline. There are no difference in GC statistics.

From the picture above, you can see that the Minor GC runs on almost every render and Major GC is run several time throughout the tests.
Have you profiled the GC time when you reach the conclusion that the main perf comes from garbage collection? If so, can you share your research? By the way, I have no data to support this but I think Virtual DOM nodes as costly to garbage-collect as functions, so I really doubt that it’s GC…
@jasonkylefrank
I replaced the .bind() call with arrow functions. There are almost no differences.

Test
Speed

One component with arrow functions
x 147,453 ops/sec ±1.92% (57 runs sampled)

Two components without bind()
x 148,354 ops/sec ±1.86% (57 runs sampled)

I’d appreciate it if someone can perform a larger scale test that represents the real world performance issue.
Based on my experience tuning React performance, I’ve never found performance problems caused by creating new functions every render() call. Most of the performance problems come from wasted render — render calls which result in the same Virtual DOM nodes as previous render.
Mostly it is that creating a new object or function to pass as props to child component every time sometimes breaks PureRenderMixin (or shallowCompare), as this.props.onClick !== nextProps.onClick is always the case. This is the only case I’ve found where performance issue is noticeable. Creating arrow functions in render() can lead to wasted renders, but that has nothing to do with creating or garbage-collecting functions/objects.
So here goes my conjecture: If you create a new function every render() call, but it doesn’t lead to wasted renders, then performance difference will not be noticeable.

Thanks for your benchmarks @dtinth! Very useful :)

Mostly it is that creating a new object or function to pass as props to child component every time sometimes breaks PureRenderMixin (or shallowCompare), as this.props.onClick !== nextProps.onClick is always the case. This is the only case I’ve found where performance issue is noticeable.

Yeah, this is what I found too. I should have highlighted it more thoroughly in the docs. You could write your own shouldComponentUpdate but it's usually good to follow the "happy path" of allowing PureRenderMixin to work as-is.
Feel free to send a pull request to make this clearer in the docs :)

@dtinth Thanks for the follow up tests - very helpful!
Based on the tests that @dtinth has shown, I'm not seeing a benefit of using this linter rule, pending possible garbage-collection performance research from @Daniel15 or others.  I'd love to hear from anyone that has research on these issues.

The fact that creating a new function on render breaks PureRenderMixin is
still worth keeping in mind, especially for components that are high up in
a component tree.
Sent from my phone.
On Mar 19, 2016 7:26 PM, "Jason K Frank"<EMAIL_ADDRESS>wrote:

@dtinth https://github.com/dtinth Thanks for the follow up tests - very
helpful!
Based on the tests that @dtinth https://github.com/dtinth has shown,
I'm not seeing a benefit of using this linter rule, pending possible
garbage-collection performance research from @Daniel15
https://github.com/Daniel15 or others. I'd love to hear from anyone
that has research on these issues.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/yannickcr/eslint-plugin-react/pull/274#issuecomment-198833126

@dtinth Follow-up questions about your last test ("One component with arrow functions..."):

Was that with the production version of React?
Your "4 function tests" (where you compare using bind(), closures, arrow functions, and React.createElement) seemed to indicate that arrow functions are considerably faster than bind().  Why then do you think that these last tests did not show improved performance over the bind() version?

@jasonkylefrank

Yes, this is the production version of React.

The four tests only cover the time it takes to create functions or React elements, which take less than 1/2,000,000 seconds. Compared to the time it takes for React to render the Virtual DOM to DOM (which takes 1/150,000 seconds) this is extremely small. That’s why I think the performance issue here is negligible.

In my opinion, the real performance gains come from avoiding wasted renders, not by avoiding arrow functions or bound functions — but avoiding arrow functions or bound functions is one way to avoid wasted renders.
Note: I would not even avoid wasted renders until performance problems becomes noticeable; I don’t want to trade code readability and straightforwardness for it. But I do take measures to ensure that when I really need to optimize, I can do it pretty easily — e.g. by always using immutable data.


Update pywrap_mlir.py

Input Validation: Added validation for inputs such as graphdef, pass_pipeline, and input_names.
Improved Docstrings: Added detailed docstrings to explain the arguments, return values, and potential exceptions.
Pathlib Support: Replaced string-based file paths with Pathlib.Path for cross-platform compatibility.
Default Argument Handling: Updated default arguments for mutable lists (output_names).
Logging: Added logging functionality when show_debug_info is set to True.
Batch Processing: Added support for batch processing of multiple GraphDef objects using batch_import_graphdef.

Hi @Ame3yakatole , Can you please sign CLA , thank you

Someone from MLIR should review this


Support for calculating element visibility in relation to parent container defined with bind-scroll-to

When you define a bind-scroll-to element (container), element visibility will be evaluated on that container. Before, only viewPort height was used, so if you had scrollable elements in a div with limited height (and hidden overflow) their visibility was still evaluated on the whole viewPort.

Is it possible to add a test for the use case you mention?  Can you please rebase this with master as well?

Do you mean adding an example?

Sure an example would be good.


passing GITHUB_TOKEN to Octokit

Hi @garronej!
Thank you for the great product "denoify"! We always use it.
This PR enables passing GITHUB_TOKEN to Octokit to avoid API rate limit.

In the denoify package, it's enabled but, we need to set the env value also in this package.

Thank you for the kind word and the PR.
Let me fix the test cases.

Ok tout patch has been released!

@garronej
Thanks! Will you release a new version of "denoify"  with this fix?

Absolutly, it's done!

Thanks! But it fails? https://github.com/garronej/denoify/actions/runs/6501002466

Sorry,
Sometimes the network call limit is reached when running the test.
It's published now

Thanks again. We'll upgrade denoify now!


API changes with facebook new dashboard

Paths to reach activity and begin deletion has changed with the new facebook dashboard. Will need major overhaul/rewrite to continue to work for the future.
If you plan to maintain this/update it, lemme know and I'll hop on board and assist.

Does the most recent release work for you? I made a bunch of changes that force redirect you to the mobile.facebook.com site now, which makes things a lot easier. Pull requests/code are welcome if you find anything wrong of course!

@weskerfoot I have issue with -Y command, as mobile.facebook.com/userid/timeline?year=x is broken

I also have this issue using the -Y flag.

I also have this issue using the -Y flag. Any luck yet?
This chrome plugin reverts the layout to the old layout on the desktop version of the site, and then the /timeline?year=YYYY URL works again.

I'll take a look soon

I also have this issue using the -Y flag. Any luck yet?
This chrome plugin reverts the layout to the old layout on the desktop version of the site, and then the /timeline?year=YYYY URL works again.

try on this branch https://github.com/weskerfoot/DeleteFB/tree/fix-year
let me know if you need help debugging

hmm actually it seems like that won't work, I'll try to think of another way of doing this

Doing this via the activity log on mobile instead seems to work

Hoping to get this working soon

trying to delete my fb posts, found your tool. having trouble:
An exception occurred: Message: element click intercepted: Element <button value="1" class="_42ft _4jy0 _52e0 _4jy6 _4jy1 selected _51sy" id="loginbutton" name="login" tabindex="0" type="submit">...</button> is not clickable at point (916, 341). Other element would receive the click: <div>...</div>
  (Session info: chrome=91.0.4472.114)
'NoneType' object has no attribute 'get'

Using -Y argument...Is it the same bug?


Move mercator transforms to Projection.js.

The SphericalMercator mixin is not required for coordinate transforms.  Default transforms included whenever Projection.js is included.

Awesome. We may just want something in the release notes for this change. Thank you for making this real. Please merge.


improved documentation needed for sleep detection

The sleep detection in GGIR was originally designed based on the assumption that a sleep log (diary) is available as described in our 2015 paper.
However, in recent years GGIR has been expanded with several sleep detection options that do not rely on a sleeplog anymore. This makes that a lot of the terminology within GGIR has become confusing for those users without a sleeplog. In our recent Scientific Reports paper I fully focused on describing the HDCZA algorithm as a replacement for the sleeplog, and only expanded the documentation to describe how to use this approach. As that paper already had a lot of content, I did not have space (or time) to also provide a detailed description of all the options associated with the sleep algorithms within GGIR and how their impact varies with the different SPT detection algorithms. The link to the repository I used should hopefully clarify anything that the paper does not describe, but it is not ideal as a way to communicate how things work.
Proposed solution:

Try to improve variable names (as also discussed here).
Try to improve function documentation and vignette.
Provide clearer advise about what variables should be used: The acc_xxxx variables are prefered over the sleeplog_xxxx variables. They are both in the output to facilitate comparison, but for a new user it can be confusing.

@vincentvanhees
It is great to provide alternative to sleeplog.  In the sentence "The link to the repository I used should hopefully clarify...", the link is broken.
Thanks,

thanks - url now fixed


Fix services that have TimeoutStartSec=0

Issue description
TimeoutStartSec = 0 is likely wrong, it doesn't make much sense to expect that the service starts in 0 time. Perhaps infinite was meant?
Units we know we should investigate and fix:

osquery
consul

Previous versions of systemd used 0 to disable the timeout logic.
Ref: https://github.com/systemd/systemd/blob/4f7dc24f8bbb3c312a46dc8d8f25658d02d47bfe/NEWS#L2798
The correct new value is infinity


Export execInUVM to allow for access to the tool outside cmd

Intermediate PR for vpci assigned devices work.

This PR just exports the function execInUVM and moves around related files. Allows us to make calls to execute commands in the UVM from outside of the cmd/containerd-shim-runhcs-v1 package.

Signed-off-by: Kathryn Baldauf<EMAIL_ADDRESS>

LGTM assuming we're fine with exporting this

@katiewasnothere Would it make more sense to move this inside the uvm package than inside the hcsoci package? Since this function is specifically about executing something in UVM it might be better to add this as a method on uvm struct?

@ambarve I believe that was my first idea, but this function needs to be used in the hcsoci package, and since the uvm package already pulls in the hcsoci package as a dependency, we cannot add this to the uvm package as that would create a circular dependency when hcsoci tries to pull in uvm and go yells at me :)


BUG Update Twitter X-Icon

Title:
Replace old twitter icon to X-Twitter icon.
Issue No.:
Close #107

Screenshots

Checklist:

[X] I have mentioned the issue number in my Pull Request.

Additional context (Mandatory):
Are you contributing under any Open-source programme?

[X] I'm a GSSOC-EXT contributor
[X] I'm a HACKTOBERFEST contributor

@Anuj3553 Is this repository participate in gssoc-ext??

??

@Anuj3553 Is this repository participate in gssoc-ext??

Yes, this bitbox repo -> https://github.com/Bitbox-Connect/Bitbox listed in the gssoc-ext.


Add expression interpolation with #{expr}

One annoyance I frequently run into with the quote! macro is that I
need to lift out all variable bindings that are being interpolated. For
example I'll often do:
let name = &foo.name;
let abi = &foo.abi;

quote! {
    extern #abi fn #name() { /* ... */ }
}

but I've recently had the idea that in addition to lighteight #name
interpolation there's also available syntax (I believe) to support
expression interpolation as well, implemented in this PR. The above
snippet could now be rewritten as:
quote! {
    extern #{foo.abi} fn #{foo.name} { /* ... */ }
}

There were several attempts to solve this problem before: https://github.com/dtolnay/quote/pull/30, https://github.com/dtolnay/quote/pull/32 and https://github.com/dtolnay/quote/pull/83 but none were accepted. I think it's a good idea to explain how this PR is better (I can see that this is pretty minimalistic compared to previous ones) if you want to get this merged.

Ah thanks for the pointer, I was unaware of those!
Reading over those I personally feel like the main use case for this is what was outlined here, accessing fields. I do that so often in so many quote impls that being able to do that would be quite beneficial.
I will admit though that I haven't considered the repetition case at all here. I try to avoid using repetitions as they've always felt a little off to me running into issues like https://github.com/dtolnay/quote/issues/7 and such.
I would personally advocate for considering this. From my (likely naive) point of view this seems to be a simple enough addition that it is lightweight enough to add and is worth it. It sounds like @dtolnay like you're also worried about misuse causing hard-to-read code, and I definitely agree that's possible. I don't think that'd persuade me, though, to think this shouldn't be added on that basis.

ping @dtolnay, do you have thoughts on this perhaps?

I found impl ToTokens for ast::StructField as one seemingly typical instance of this pattern.

That's all spot on!

Keep in mind that complexity inside of a quote! invocation is far more expensive than a similar amount of complexity outside of an invocation.

This is an interesting point I think. I believe I was largely struct with inspiration from this when I saw the typed-html macro crop up recently and it used interpolation for Rust expressions, and I thought "oh right I would use that a lot for quoting!". I figured that many interpolation syntaxes support expression-based interpolation (like JS strings's "${foo}").
Thinking more, though, this point about expressivity I think is key. In a string or in something like HTML the surrounding "stuff" is entirely different from what you're interpolating. With quote!, however, it's the exact same stuff as what you're interpolating with. For strings this means it's pretty easy (especially with syntax highlighting) to find what's interpolated, and even with HTML/Rust it's pretty easy to visually distinguish the two. With quote! and interpolated code, it can be confusing to follow as because both are so visually similar.
That all makes sense to me, and as I was unaware of the rejected proposals before I'm gonna go ahead and close this. Rationale makes sense to me!


Add ability to make keyboard shortcut Global

Fixes #11844
Adds the ability to make a keyboard shortcut global using bind-mousetrap-global and adding a scope Stimulus value.

I had to do:
import 'mousetrap/plugins/global-bind/mousetrap-global-bind';

instead of :
import addGlobalBinds from 'bind-mousetrap-global'

addGlobalBinds(mousetrap)

because it kept giving this error:
client/src/controllers/KeyboardController.ts:63:17 - error TS2339: Property 'bindGlobal' does not exist on type 'MousetrapStatic'.

Also when I press the shortcut the second time immediately after the first, it also triggers the browser shortcut set (for example: if I press mod+P twice rapidly, it triggers Print). Wouldn't this be undesirable?

Thanks @NXPY123 I'll try to review this soon, I have flagged for 6.1 as I think this would be good to get in alongside the other keyboard shortcuts improvements.

This works great, incredible stuff here @NXPY123 - your unit tests added are great also.
I like your approach to use the built in plugin for the Mousetrap bind global, as such you do not need to install the package.json package at all. I will remove this when merging though.
The other change I have done is ensure the mod+p one is also global.
The nice thing about this is that if we adopt a different (non-mousetrap) library in the future we have a solid suite of tests to support up that migration.

Thank you so much! If there are more issues to work on I'll be glad to take them up!


Support for PropTypes.symbol

I am used to the react PropTypes and I used them for things other than components.
I am using proptypes but now I need to validate for Symbol. This is not in the ~14 code base that is your current implementation.
Do you have any guidance?

We'll need to diff against 15.3's proptypes implementation, shouldn't be too difficult.

I also need a symbol implementation

If anyone has time, the implementation just needs to be lifted from the react 15.x source. Big thanks if you can!


Benchmark for libpng-sys seems to be wrong.

Hi, I was looking for a fast way to encode .pngs in Rust, so I stumbled over your performance comparison.
Looking at the table it seems like libpng-sys just totally rocks for sRGBA images. For example sRGBA 4096x4096 took 0.039266 ms, which if true would be totally insane.
So I tried it. Turns out it is as fast as measured, but only because it does exactly nothing. Here is my test script, heavily inspired by your benchmark:
#[macro_use] extern crate const_cstr;

fn main() {
    let data = std::fs::read("noise.png").expect("Failed to open PNG");
    let data = std::io::Cursor::new(data);
    let decoder = png_pong::Decoder::new(data).expect("Not PNG").into_steps();
    let step = decoder
        .last()
        .expect("No frames in PNG")
        .expect("PNG parsing error");

    let raster = match step.raster {
        png_pong::PngRaster::Rgba8(ok) => ok,
        _ => unreachable!(),
    };

    let before = std::time::Instant::now();

    // 1. Declare png_image struct, 2. Set members to describe image
    let mut png_image = libpng_sys::ffi::png_image {
        opaque: std::ptr::null_mut(),
        version: 0,
        width: raster.width(),
        height: raster.height(),
        format: libpng_sys::ffi::PNG_FORMAT_RGBA as u32,
        flags: 0,
        colormap_entries: 0,
        warning_or_error: 0,
        message: [0; 64],
    };
    // 3. Call png_image_write...
    /* let memory: *mut std::ffi::c_void = std::ptr::null_mut();
    let mut memory_bytes = 0;
    unsafe{
        let _r = libpng_sys::ffi::png_image_write_to_memory(
            &mut png_image,
            memory,
            &mut memory_bytes,
            0,
            raster.as_u8_slice().as_ptr().cast(),
            raster.width() as i32,
            std::ptr::null(),
        );
    } */

    unsafe {
        let path = const_cstr!("output.png").as_cstr().as_ptr();
        libpng_sys::ffi::png_image_write_to_file(
            &mut png_image,
            path,
            0,
            raster.as_u8_slice().as_ptr().cast(),
            raster.width() as i32,
            std::ptr::null(),
        );
    }

    println!("Encoding took {:#?}.", before.elapsed());
}

I had to use const-cstr in my Cargo.toml:
[package]
name = "libpng_exporter"
version = "0.1.0"
authors = ["FrankenApps<EMAIL_ADDRESS>edition = "2018"

[dependencies]
libpng-sys = "1.1.8"
png_pong = "0.8.0"
const-cstr = "0.3.0"

As you can see by running the code, no file was ever created, which I suspect is also true for encoding in memory.
I have not tested, if  sRGB 4096x4096 works, but at 3.7263 ms that would still be insanely fast for .png encoding (I tried quite a bunch of stuff already ;-) ).
So it seems to me, that if have not missed anything libpng-sys should better be removed from the comparison, because it does not seem to work, or needs a fix to run properly...

Yeah, it's probably wrong - I am skeptical of the benchmark I made for libpng-sys, too.  I'd rather fix it than remove it, though.  If you have any ideas PRs are welcome, just don't include any I/O in the benchmark.


Mention or use .raku method instead of .perl

ref #3309

Actually I'm a bit confused.
It seems that Date had had a perl method since a long time.
See
https://github.com/rakudo/rakudo/commit/5ab1c03d4ded2bc90f5ccf3dec656fd8c4973449#diff-33f30fdc536b61e50d61fe6d55cf8630R112
or
https://gist.github.com/Whateverable/7ec244c0ed36fdd9c8741307268ad45d
So I wonder why this is mentioned as new in #2632 and even in
https://github.com/Raku/roast/blame/master/docs/announce/6.d.md#L173

Before the rename, all classes had a .perl method, either directly in the class, or inherited from Mu.perl.
After the rename, all of these got renamed to .raku, and a special Mu.perl method was created that would either make that calling .perl on any object would still work (by calling .raku internally).
A special Mu.raku method was also created to make sure that calling .raku on user classes that only had a .perl method, would also just work.
Hope this made sense: it was quite a puzzle to get all of this working correctly  :-)

Thanks @lizmat, it makes perfect sense!
Would you care to make the same comment in #3386 ;-)


update pre-requisite readme file

[ ] Breaking change?
Update the readme file for pre-requisite for kafka-ui. Add dependencies installation for ubuntu.

What changes did you make?
update dependency installation for ubuntu pre-requisite readme file.
Is there anything you'd like reviewers to focus on?
@Haarolean
Issue:  #3392
How Has This Been Tested?

[ ] No need to
[x] Manually
[ ] Unit checks
[ ] Integration checks
[x] Covered by existing automation

Checklist

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
[x] My changes generate no new warnings (e.g. Sonar is happy)
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged

Check out Contributing and Code of Conduct

Signed-off-by: Shubham Kumar<EMAIL_ADDRESS>

sorry to push this in the master branch but I won't be able to move it to the docs branch.
can u help btw!

@ShubhamKumar89 what's the reason behind creating a duplicate PR?

@ShubhamKumar89 what's the reason behind creating a duplicate PR?

sorry but I have tried to change in the previous PR but not able to do so.
basically I'm have made a couple of PRs so don't much about how to do that.

@ShubhamKumar89 what's the reason behind creating a duplicate PR?

sorry but I have tried to change the previous PR but am not able to do so. basically, I had made a couple of PRs so don't know much about how to do that.

Yes, you are able. You made a fork and you can edit the files within a branch of your own fork.
You can look up on google how to edit files multiple times within a PR.
Feel free to mark #3392 as ready for review once you're done.


Allow token and url to be set via plugin options

Description

Changes craftGqlUrl and craftGqlToken to be optionally set through plugin config options. Falls back to env variables.

Related issues
closes #13

I was not able to compile the ts file without it exploding into a mess of changed lines. 😬
I instead opted to limit changes to the js file to keep things concise. Please let me know if I can help further.

Thanks! We'll cut a release soon!

Thanks! We'll cut a release soon!


Fix a few infelicities in README.md

Gotcha :) Thanks for checking in! Loving the dev exp of Quarkus with
PicoCLI overall. The one thing I'm missing (out of your control though) is
simple CI on Arm, so we could publish binaries for that platform too. The
joys of native binaries ;)


Stuck in infinite loading state when doing a POST

Using postman after starting a docker container on 5001 and hitting with my access_key and keywords.  It just spins and spins.  Any ideas for troublshooting?

Apologies for the late reply, I'm assuming the container is on the same subnet as the tv? Do you get a prompt on the TV to allow the connection and is it showing under device list? You can find this under 'Settings' > 'General' > 'External Device Manager'.

Yes, the container is on the same subnet. I'll take a look at this later tonight to see if it's showing under the device manager. I don't think I got a prompt. I'll let you know. Thanks for the response.


refactoring into a distinct binary and library

I put everything in lib, and did some refactoring, mainly to remove every console.log.
Instead, a callback receives errors, and status code from the response.
I also modified the readme, and added a few tests.

:+1: this approach seems to be much cleaner to me.
Pretty wired that the codeclimate-test-reporter npm module is not consumable as a library in other node projects.

I guess that I'll resolve this merge conflict


Upload SHA-256 checksum of EKS-A admin image for validation

Fixes aws/eks-anywhere#5708.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Docker no connection

Hello,
I have Laravel running in a Docker environment with the packages mysql,nginx and php-fpm. I use this as an API.
I now want to add the websocket server, this also works, I can start the server via php artisan websocket:serve.
Via the statistic laravel-websockets I can connect to the websocket server, I can also see that in the console.
However, I can't connect from my VUE app or from a web socket test client, I can't get a connection.
What do I have to do? How do I get the connection from Docker to my client?
Thank you very much.

Does anyone have an idea for my problem?

Again as supplemental info, I have a Laravel backend and a separate Vue project. This Vue project is not in the Laravel directories!

This highly depends on how your Docker is setup. You'll want to set the PUSHER_ENDPOINT_HOST to the IP of the correct container, not just <IP_ADDRESS>.

Hi thanks for your replay.
Where does this variable belong?

By the way
is it possible to have the server in project A and the FrontEnd in another project, so a pure vue.js project?
I still find examples where Laravel and Vue are in one project.

This is actually my not working config:
   subscribe() {       const pusher = new Pusher(           'Tx1f8zribV',           {             cluster: 'mt1',             enabledTransports: ['ws'],             PUSHER_ENDPOINT_HOST: 'workspace',             host: 'workspace',           },           );       Pusher.log = (msg) => {         console.log(msg);       };       pusher.subscribe('GAUpdate');       pusher.bind('GAUpdate', (data) => {         console.log(data);       });     },   },

Hello,
I have Laravel running in a Docker environment with the packages mysql,nginx and php-fpm. I use this as an API.
I now want to add the websocket server, this also works, I can start the server via php artisan websocket:serve.
Via the statistic laravel-websockets I can connect to the websocket server, I can also see that in the console.
However, I can't connect from my VUE app or from a web socket test client, I can't get a connection.
What do I have to do? How do I get the connection from Docker to my client?
Thank you very much.

you can specify a port to execute the supervisor that runs the websocket

I also have Laravel running in a Docker environment with the packages mysql,nginx and php-fpm , but i am struggling in the config of ws in ngnix , can you help me ?
websocket is served and everything is running okay , but i can't connect via the statistic laravel-websockets


[ruff] Implicit class variable in dataclass (RUF045)

Summary
Resolves #12877.
Test Plan
cargo nextest run and cargo insta test.

I'm not saying we shouldn't do it, but requiring type annotations has been controversial in other instances; for example, there's a long thread for RUF012 that does something similar. @AlexWaygood I'd be interested on your take on this before I start reviewing the rule itself.


Seal more internal/private classes

This PR enables per CA1852 and CA1813 as suggestions. We can also alternatively enable entire performance category analyzers. I went through some of the internal and private types and sealed them, unsealing them later is easy as is it is not a breaking change.
You can read more about potential benefits by sealing internal/private classes by default here: https://github.com/dotnet/runtime/issues/49944
note: skimming through usage of the classes I sealed, the benefits sealing are negligible at best as very few is stored in arrays (we would avoid covariance checks) or having virtual call dispatches.. However the concrete attributes should benefit from sealing and I think it's good pratice to seal any private or internal class with no-derived types by default as unsealing it later is free.

Amazing stuff!


Cache Python strings, especially when converting GameEvents without their COMPACT flag set.

+rep really cool guy


bugfixRestrictions on creating a database

Proposed changes

Restrictions on creating a database.
Currently, only attributes of the hms type of database can be added.
Like:

create database db properties ('a'='b');

Unify the catalog name of iceberg and doris to be the same.

run buildall

run buildall


Add addresses in Carlsbad, NM

Status:

[ ] Research sources and propose best source (and it's data license)
[ ] Review proposed source
[ ] Approve source based on review comments
[ ] Add to OpenAddresses

NOTE: Proposed source notes should include basic column mapping to OpenAddress data model.

Looks good! Street number and street name both in one field and 2 separate fields (no city or zip).


docs: clarify replace operation

This PR updates docs and renames "modify" operation with "replace":

"update" and "modify" do not describe what is actually happening.
"replace" should make it easier to reason about the purpose of this operation.

Preview: https://ipfs.github.io/pinning-services-api-spec/#specUrl=https://raw.githubusercontent.com/ipfs/pinning-services-api-spec/docs/replace-call/ipfs-pinning-service.yaml

@andrew good point!
Added notes about protecting against undersired garbage collection of data common to both old and new pin in a3db8e1

This is also a docs-only change, so merging


Quick hit: limit publish form to 5 tags max

This will discourage people from slapping every single tag onto the things they publish and should help with mistagged content.

As a user I'd want to know why certain content (i.e. YouTube sync) gets to apply more tags. I also dont think this will fully solve the tag abuse, but it's a good step towards trying to curb it. Part of the problem is that users just add the first tags they see on the list...
We should also:
Don't show the first few default tags?
Make it clearer you can add your own tags if they don't show up on the list.
Auto suggest mature tag based on title / file name (i.e. porn hot XXX etc in name)

Mainly repeating Tom above:

Find way to be smarter about default tags (possibly read tags from content they've published or watched)
Make sure mature is always shown prominently. Possibly add set of words to auto-match/apply mature.
Always show the exact term typed as a possible tag to apply (2 character minimum)