Only produce new gradle-wrapper.jar when classes changed

It'd be helpful if upgrading the gradle wrapper through the recommended approach only resulted in a new gradle-wrapper.jar if its classes had changed.
From the Upgrading the Gradle Wrapper docs:

The better and recommended option is to run the wrapper task and provide the target Gradle version as described in Adding the Gradle Wrapper.

Running ./gradlew wrapper --gradle-version <new-version> always results in a new gradle/wrapper/gradle-wrapper.jar, which results in source control repositories growing faster than necessary.
Expected Behavior

If there haven't been any changes to the classes included in gradle/wrapper/gradle-wrapper.jar, the jar should not be different.
Current Behavior

The embedded build-receipt.properties is always different between versions, requiring a new binary to be checked in to source control with each version update.
Here is a diff of the unzipped jar contents from a 4.9 and 4.10 gradle-wrapper.jar:
$ diff 49/gradle/wrapper/jar-contents/ 410/gradle/wrapper/jar-contents/
Common subdirectories: 49/gradle/wrapper/jar-contents/META-INF and 410/gradle/wrapper/jar-contents/META-INF
diff 49/gradle/wrapper/jar-contents/build-receipt.properties 410/gradle/wrapper/jar-contents/build-receipt.properties
1c1
< versionNumber=4.9
\ No newline at end of file
---
> versionNumber=4.10
\ No newline at end of file
Common subdirectories: 49/gradle/wrapper/jar-contents/org and 410/gradle/wrapper/jar-contents/org

Context

Attempting to stay up-to-date with the latest wrapper through the recommended approach leads to unnecessary repository growth. See also https://github.com/gretty-gradle-plugin/gretty/pull/74.
Steps to Reproduce (for bugs)

Run ./gradlew wrapper --gradle-version <new-version> && git diff from an existing git repository with an older version of the gradle wrapper checked in.
Your Environment

Build scan URL:
N/A

The build-receipt.properties file is currently being read from the gradle-wrapper.jar:
https://github.com/gradle/gradle/blob/3ccc368a2684a34cd01ed58e0b1798e4f50de5c6/subprojects/wrapper/src/main/java/org/gradle/wrapper/GradleWrapperMain.java#L93-L113
However, it looks like it's only used in the HTTP User-Agent when downloading the distribution:
https://github.com/gradle/gradle/blob/0e5d6e9eddbcd9614b99937b93c02fb9547c3c37/subprojects/wrapper/src/main/java/org/gradle/wrapper/Download.java#L157-L165
Thus, I think it would be feasible to exclude build-receipt.properties from the wrapper JAR. I'm not sure, however, if that would already be sufficient to produce the exact same JAR. File order and timestamps seem to be already taken care of:
https://github.com/gradle/gradle/blob/1e4bb4edaaa74cde83ef0063e0b40f34dda1ae2f/subprojects/wrapper/wrapper.gradle#L56-L63

Just as a data point and some perspective, the gradle/gradle build updates the wrapper more than any other project would (over 270 times) to various RC's, nightlies and final releases.  The wrapper jar is ~50KB, so assuming that git can never compress or dedup the wrapper jar, that's 14MB of a 200MB repository.  Not insignificant, but it's a slower growth than some may think.
If your project only updates on final releases and has been since 1.0, you would have only changed the wrapper jar ~50 times.

I suppose I sort of trigged this issue in the linked issue by questioning a new gradle-wrapper.jar with each (or some) Gradle release rev in a project.  This can easily happen if you run the wrapper task as a matter of course when upgrading your build to a new Gradle version, and generates the binary churn in the repo.  So I thought I might add a few additional data-points on gradle-wrapper.jar as it applies to the gradle repo itself, following @big-guy :

This will vary a little by filesystem etc., but the rough full-repo-on-disk size for a bare clone direct from GitHub is about 300388kb on my machine.
This can be reduced quite a bit with an aggressive git gc (run in order to make a fair comparison): 203392kb.  This increase delta compression quite a bit.
There are 316 commits on all branches which touch a file named gradle-wrapper.jar.
There are 291 unique blobs containing gradle-wrapper.jar in their path in the repo.
There are two gradle-wrapper.jar files in master head.  Interestingly they differ - gradle/wrapper/gradle-wrapper.jar is versionNumber=4.10-rc-3, whereas subprojects/docs/src/samples/userguide/wrapper/sha256-verification/gradle/wrapper/gradle-wrapper.jar is versionNumber=4.3.1.
With all but the two current copies removed from all repo history (via BFG), and the repo repacked, the new size is 202536kb, so only 856kb is recovered.  So not the 14mb odd possible without repacked delta compression.

So basically, Git delta-compression can do amazingly well even with binaries, especially if the binary is created in some ordered fashion, and is something fairly predictable like a jar of bytecode from source that hasn't changed.  So the net repo growth is limited as observed by @big-guy , and it is even less than that.  But partly that relies on Git maintance tasks such as repacking, which don't always distribute well.
So maybe my hesitance to wrapper-churn is unfounded, but it always feels icky checking-in binary updates to Git, so I was looking for a strategy to make it easy to avoid that.
Per the linked issue, my habit has been to 1) Check-in a gradle-wrapper.jar, it so tiny there's no need for a wrapper-wrapper and 2) Update the wrapper jar much less frequently than the Gradle it points to, since it hardly ever changes ... only update it should it become ancient, or to pick-up a bug or security fix.
I guess what would be ideal would be a) an easy way to tell when there had been any material change to the Wrapper, b) when there's been an important fix to the Wrapper.  I suppose checking source or grepping the release notes might answer those.  Short of versioning and releasing the Wrapper separately, which is probably not worth it, that might be best available.
It would be a shame to remove the manifest information from the wrapper jar which identifies the build version, being necessary if the same binary were to be produced.
I also don't think it is sustainable for a build-chain to be expected to produce an identical binary from identical source in the long-term - even a JDK rev could change that, so it would require locked toolchains.
One solution could be a back-reference mechanism from Gradle to the wrapper, but it would require passing the wrapper version to Gradle - if Gradle were called with a wrapper that was significantly behind and missing important changes, Gradle could prompt the developer to maybe upgrade the wrapper.
Or having run ./gradlew wrapper --gradle-version=4.10 we can just remember to git checkout -- gradle/wrapper/gradle-wrapper.jar before committing :).

@eriwen Do we parse the User-Agent for download statistics? Could we remove the version from it?

We do, but I imagine we don't strictly need the Gradle version in the User-Agent since that is part of the filename.

@eriwen @marcphilipp I am not 100% which version we are talking about. When the wrapper jar is generated the build-receipt.properties of the Gradle version creating the wrapper jar is included.
This is not the Gradle version runnning the build.
While it is interesting to know which versions of the Gradle were used to produce wrapper jars which are used out there, it is probably not very interesting. The interesting information we want to obtain is which Gradle versions are used, independent of which wrapper jar is used.
Is this correct?

That's my understanding as well.

I noticed something interesting today which I probably should have been cognisant of but wasn't: the wrapper task is not idempotent when upgrading:

Run ./gradlew wrapper --gradle-version 4.10.2 --gradle-distribution-sha256-sum b7aedd369a26b177147bcb715f8b1fc4fe32b0a6ade0d7fd8ee5ed0c6f731f2c in a project with an older wrapper, and your gradle/wrapper/gradle-wrapper.properties gets the version bump - nothing else.
Run ./gradlew wrapper --gradle-version 4.10.2 --gradle-distribution-sha256-sum b7aedd369a26b177147bcb715f8b1fc4fe32b0a6ade0d7fd8ee5ed0c6f731f2c again and additionally gradle/wrapper/gradle-wrapper.jar is now touched.

This is perhaps unsurprising, since the first wrapper task runs under the older Gradle runtime supplied by the existing wrapper config, whereas the second execution runs under the newer 4.10.2 Gradle runtime.  Since the local/downloaded/unwrapped Gradle runtime is the supplier of gradle-wrapper.jar, assuming the pre-existing Wrapper jar is up-to-date, it doesn't change for the first command, but does for the second - per the above discussion, mainly because it contains a version-stamp file (although it could have real code-changes).
Although unsurprising, the behaviour is a little odd.
Presumably if you fail to check-in gradle-wrapper.jar, this behaviour won't repeat itself on the next Gradle upgrade-via-wrapper cycle, since gradle-wrapper.jar will already be out-of-date with the version in the current Gradle runtime, so will be touched immediately.
What if the wrapper task had a --properties-only option or similar ... if you remembered to add that, you wouldn't dirty your wrapper jar.

@javabrett What you are describing is https://github.com/gradle/gradle/issues/884.


LeafHashMismatch when replicating files from documents

Reported by @ppodolsky on discord.
I am not quite sure if this is a bug, but I would love to get to the bottom of it.

@ppodolsky have you seen this since you moved to the batch branch?


Add getStickerSet

[ ] All tests pass
[x] I have run npm run gen-doc

Description
Implements getStickerSet (part of the Bot API 3.2: #407).
References
The original PR was #389. Seeing that it was abandoned, I fixed it.

Huh?

Hold on. Just messed up things. :smile:

Crap! Just restore your master branch. Seems this situation can not be salvaged.

Uh, what happened? Was it me that messed up something in the PR? I can't quite figure out what happened.

Oh wait, I see now. I'll restore master right away.

Done!

Codecov Report

Merging #429 into master will increase coverage by 0.25%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #429      +/-   ##
==========================================
+ Coverage   85.51%   85.76%   +0.25%
==========================================
  Files           5        5
  Lines        1539     1545       +6
  Branches      309      310       +1
==========================================
+ Hits         1316     1325       +9
+ Misses        223      220       -3

Impacted Files
Coverage Δ

src/telegram.js
82.56% <100%> (+0.35%)
:arrow_up:

Continue to review full report at Codecov.

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

Merged in commit https://github.com/yagop/node-telegram-bot-api/commit/a2d85b889ad2f58879590b9f65f1fc130c2575bc.
Thanks @CapacitorSet and @LibertyLocked for the PR! Thanks! :+1:


MyFirebaseSettings ?

I can't find the MyFirebaseSettings file and the application can't run

I can't find the MyFirebaseSettings file and the application can't run


pull request for e2e test at 01/04/2017 20:45:08

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


"C" shortcut in diffs does not work anymore

Pressing "C" to add a comment to a selection in a patch no longer works:

Context menu still works.

Duplicate of #410. Unfortunately that one is open for quite some time :(


Trojan:Script/Wacatac.B!ml found in windows installer

Apologies, I am unsure of the conventions for contributing to vim. However, this was reported today on my Windows 11 machine while installing v9.0.0040 via winget.

Well, either that install.exe has actually be poisoned, or it's a false alarm.  Virus scanners work with signatures which can trigger false positives once in a while.
Compare the file (byte by byte) with the one you can download from here: http://ftp.vim.org/pub/vim/pc/vim90w32.zip
it is 190976 bytes long.  If yours has a different size it's likely been tampared with.

this is most likely a false positive.
I got the download URLs from wingets Vim 9.0.0040 release and tested them using virustotal:

gvim_9.0.0040_x64.exe
gvim_9.0.0040_x86.exe
vim90w32.zip

All clean. Please complain to your AV vendor.
See also https://github.com/vim/vim-win32-installer/issues/275


Implement Repr

Fixes issue #79 .
Welcome to the magnificent Rust Python 0.0.1 interpreter
>>>>> ["a", "b", "can't"]
['a', 'b', 'can\'t']

Aw snap, looks like this branch conflicts with the removal of bool kind :sob:

I feared it might. Should be easy to resolve.


Client Allocation Request for: 北京远超敬邦科技发展有限公司

Client Allocation Questions
Core Information

Name: 北京远超敬邦科技发展有限公司
Website / Social Media: http://ycjb.fadonghui.com
Region: Greater China
DataCap Requested: 1TiB
Addresses to be Notarized: f3qiyu5tcfb5qbpynz36mzr7y5p72opqjzstctq65f7wpysk57ifre6hvizk2drfui74fs5xchlk42kxhhrekq
Notary Requested: neogeweb3

@egwgrgreggrhhe Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Hey @egwgrgreggrhhe, thanks for the request. I have some questions regarding your request. Please describe answers as much specificity as you can.

Can you introduce yourself? Where can I find you online? (Github, Twitter, Linkedin handle, Wechat, etc.)
If you represent an organization, what is the name, nature, registration country, time since inception, and named officers of your organization?
In which region(s) do you intend to use the DataCap?
What is your use case for the DataCap being requested?
Do you plan to specify advanced features when utilizing a DataCap in your storage deal? If so, please specify the feature.
How many miners do you plan on allocating the DataCap? If you have a specific miner(s) you would like to allocate a DataCap, please specify.
Do you agree on providing transparency of DataCap allocation decisions & execution details in public to prevent excessive/unfair (20% of DataCap allocation) self-dealing?

Moreover, I encourage you to take a look of my allocation strategy  and flow which shows how I utilize the assessment. Thanks.

Hello, Neo.
I am Chen Qiulin, the operation director of Beijing Yuanchao Jingbang Technology Development Co., LTD.  You can contact me by email at<EMAIL_ADDRESS>Beijing Yuanchao Jingbang Technology Development Co., LTD.  is located in Beijing, China, is engaged in gas separation, industrial tail gas purification application research and technology transformation of science and technology company, the main direction is prepared by pressure swing adsorption method of industrial gas through a gas detection technology, preparation and collect data to monitor early warning of carbon dioxide and other greenhouse gases emissions,  So as to achieve carbon neutrality plan, early warning, plan.  The company is rooted in the field of industrial gas purification monitoring, focusing on energy conservation and environmental protection, carbon neutral supervision. In order to closely link with the forefront of industry technology, the company attaches importance to the application and development of new technology, and strives to build continuous listening products and services for the majority of industrial users.
We plan to use these datacap in western China.
These data are Internet open data, enterprise docking data and independent analysis data
There is no advanced feature.
More than 10 miners are working for us.  Right now it's randomly allocated to different miners.
I'd love to.

Hey @egwgrgreggrhhe, thanks for the information. My allocation strategy is to build trust progressively. So I could allocate 100 GiB to you for the first time. Feel free to request more DataCap when you use up the allocation.

Allocation went through successfully: https://filfox.info/en/message/bafy2bzacedhpnqapvw7ronqzr3nrv6uuvith4t5w7yjknfspj5e55z3rhezjs


Issue building on Mac OS: failed to run custom build command for openssl-sys v0.9.101

Issue type
Build/Install
Have you reproduced the bug with the latest dev version?
Yes
Version
v0.1.0
Custom code
No
OS platform and distribution
macOS Sonoma
Describe the issue
When running the main build task with
cargo build --release

build fails with
error: failed to run custom build command for `openssl-sys v0.9.101`

Repro steps
Following the instructions on https://docs.ipc.space/quickstarts/deploy-a-subnet

git clone https://github.com/consensus-shipyard/ipc.git
cd ipc/contracts
make gen
cd ..
cargo build --release

Relevant log output
See above

This can be resolved by running:
brew install openssl@3
and then running the build command with:
OPENSSL_DIR=$(brew --prefix openssl) cargo build --release


Add previous opendap example

Revert back to the previous example + configuration
Closes #34
Sorry @r-ford - this reverts things back from what I changed...

No problem!


u+23f5 missing

It would be good if u+23f5 (Play) were included in noto-emoji, for consistency with other media control symbols like u+23f8 (pause) and u+23f9 (stop). There's already a suitable image, used for u+25b6 (black right-pointing triangle).

25b6 is the play button emoji, by spec.

So it is. That's frustrating given that unicode already had a different code point for the "play" symbol specifically, but I suppose there's nothing to be done about that on the Noto side. Thanks!


[Go Live][Nov 30]

Push to live

Docs Build status updates of commit a2eb4c8:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/toolkit/TeamsFx-CLI.md
:white_check_mark:Succeeded
View

msteams-platform/toolkit/TeamsFx-multi-env.md
:white_check_mark:Succeeded
View

msteams-platform/toolkit/provision.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


hotfixing z4c amr and remove most warnings at compile time

Z4c with AMR is broken in current master due to incorrect size of the T_\mu\nu array when AMR is invoked. This merge request fixes this. Also removes most of the warnings during compile.

I see a lot of changes other than in tmunu.cpp. I assume these are mostly for fixing warnings and removing dead code?


Capitalize only first letter of each word. Leave the rest of letters …

Hello.
I’ve added a new method to capitalize only first letter of each word like CSS rule text-transform: capitalize do.
I found this was a reason of my automated tests failed sometimes.

Isn't this what capitalize.words() does?

Isn't this what capitalize.words() does?

There is a small difference exist which I cought in my automated tests.
Let assume we have such input string: canDoItRight

With CSS rule applied we've got: CanDoItRight

With capitalize.words() we'll have: Candoitright

That's the difference

thanks @sergejkaravajnij ! I think this is a useful addition, but I’ve slightly refactored the proposed API.


How to find which topic attribute has been updated.

Hi,
I am trying to find (without sucess) some way to recognize which attribute was updated in an instance, I am doing research between interoperability standards and in the case of DDS I missed this feature. To receive updates of a Keyed Topic, I am using a listener. The problem occurs when I need to know which attributes of the topic have been updated. I'm not sure if the DDS architecture works that way and makes it possible. I would be very grateful if someone could help.
The follow code ilustrate what i have:
virtual void on_data_available(dds::sub::DataReader<T>& dr) // called when the keyed topic is created, updated and deleted
{
        dds::sub::status::DataState new_data; // Mask to get created instances
        new_data << dds::sub::status::SampleState::not_read()
                 << dds::sub::status::ViewState::new_view()
                 << dds::sub::status::InstanceState::alive();

        dds::sub::status::DataState old_data; // Mask to get data that suferred updates, but already exist
        old_data << dds::sub::status::ViewState::not_new_view()
                 << dds::sub::status::InstanceState::alive();

        dds::sub::status::DataState deleted_data; // Instance deleted
        deleted_data << dds::sub::status::InstanceState::not_alive_no_writers();

       dds::sub::LoanedSamples<T> updated_samples = dr.select().state(old_data).read(); // Send to OnCreateInstance() callback
       dds::sub::LoanedSamples<T> new_samples = dr.select().state(new_data).read(); // Send To OnUpdateInstance() callback
       dds::sub::LoanedSamples<T> deleted_samples = dr.select().state(deleted_data).read(); // Send to OnDeleteInstance() ballcak
}

So i have 3 callbacks, but in the callback OnUpdateInstance() (called from the callback above) i can not figure out what is the attribute of that keyed topic that suffers update. This is very important because i want to use the DDS as a DLL (plugin) for a research application, and if i dont know which attribute suffer update, i will need to send the entire topic.
Thank you.

You need to distinguish between 'instances' (represented by unique key-values) and 'samples' of such an instance (that apart from that key-value also have sample-attributes that are non-key-values, like in regular databases).
Now in the DDS-standard, 'instances' have a lifecycle that can either be 'driven' by the publisher-side (an instance might be 'new' if that unique key-value wasn't there before) or by the subscriber side (an instance might be read or not-read).
Now to your question about individual sample-attributes: all attributes of a sample have the same validity i.e. when writing such a sample, all attributes must be filled and when reading a sample, you'll get all samples. Of course you get around this by smart usage of unions (to model optional fields) or exploiting sequences of name-value-pairs which allow you to 'emulate' sparse sample-updates.
There's a set of related patterns that apply to this 'you can't write a half sample' rule: if there are high- and low- update-frequences for certain attributes, you could exploit the relational-database-pattern of creating different topics for those that share the same keys so that the samples can be (natural-)joined on the reader side.
Of course there's another rule that you shouldn't include 'stuff' in a sample that a publisher doesn't understand (also related to that fact that you only publish 'complete' samples).
Note that OpenSplice also allows to model a sample's payload using Google Protocol Buffers (GPB) which does have the concept of optional fields and checking if/what fields have been updated .. but then you'd introduce a dependency on (yet)another standard ..
Hope this helps


Affirm that correct event is fired for invalid SBOM

Related to #7
This is a tricky one, because we don't validate the content of the SBOM on the upload. To mitigate the risk of a DoS attack, we avoid loading the entire SBOM into memory -- we stream chunks directly to S3, and the indexer serially loads (and validates, eventually) them once notified that all the chunks have been streamed successfully.
I guess we have to decide if this test is worth the additional code complexity to "peek" at the payload to see if it's small enough to validate. Any thoughts @lulf?
Originally posted by @jcrossley3 in https://github.com/trustification/trustification/pull/356#discussion_r1287388376

I think avoiding loading the SBOM into memory is important, though maybe less so assuming we trust any authenticated user. Perhaps an option would be to rely on the indexer posting 'failed to parse' events, which it currently does, to the sbom-failed topic?
The test could then consume from that topic to verify that the invalid document gets the correct treatment.

Relevant JIRA ticket: https://issues.redhat.com/browse/TC-385