Zephyr does not define minimal C++ language standard requirement and does not track it

Describe the bug
Zephyr defines C11 as minimal supported standard for C language in C language support - language standards.
Similar documentation article: C++ language support does not have "language standard" section. Roadmap #31281 also does not say a word about minimal requirements. Thus, minimal C++ version supported is unknown. This is a serious problem since:

C++ language standards have much more changes between releases than C language.
Custom toolchains for embedded systems often concentrate on C language support (due to its popularity) leaving C++ language  with old standard (like dreadful C++98).

Concrete problem encountered:
SOF project uses Cadence Xtensa toolchain "xt-xcc" that is based on GNU 4.2.0 compiler for Intel Meteorlake audio firmware.
Meteorlake board has some C++ code that uses Zephyr #include <zephyr/sys/util.h> that provides C/C++ interropt helpers at the time of writing. "xt-xcc" is obsolete for some time and latest support language is C++98 standard.
Everything was working fine in our CI until PR #53405 , where author added constexpr keyword usage in commit deab09d7a6b0c51a52ffd8bd03f17e04cf39c25c .
Author @cfriedt in that PR claims (selective quote):

There should be a announcement for this and the code that suddenly requires new C++

As mentioned above, this is all in line with Zephyr's suggested ISO C and C++ standards (C11, C++11).

Proof of wrong:
Fuction template definition __z_log2_impl from include/zephyr/sys/util.h in some conditions returns value A and in other conditions value B. According to C++ standard ISO/IEC 14882:2011 §<IP_ADDRESS>:

The definition of a constexpr function shall satisfy the following constraints:

it shall not be virtual (10.3);
its return type shall be a literal type;
each of its parameter types shall be a literal type;
its function-body shall be = delete, = default, or a compound-statement that contains only

null statements,
static_assert-declarations
typedef declarations and alias-declarations that do not define classes or enumerations,
using-declarations,
using-directives,
and exactly one return statement;

every constructor call and implicit conversion used in initializing the return value (6.6.3, 8.5) shall be
one of those allowed in a constant expression (5.19).

Also, cppreference.com - constexpr confirms this:
Quote marked "(until C++14)":

the function body must be either deleted or defaulted or contain only the following:

null statements (plain semicolons)
static_assert declarations
typedef declarations and alias declarations that do not define classes or enumerations
using declarations
using directives
if the function is not a constructor, exactly one return statement

To Reproduce
Steps to reproduce the behavior:

Open my minimal reproduction project with Compiler Explorer:
https://godbolt.org/z/78sWY65v4
Play around with compiler version and C++ standard.
Note: compiler x86-64 gcc 12.2 compiles minimal example using C++11 without a warning!
Change compiler to: x86-64 gcc 11.3 to receive an error (related to multiple return statements in constexpr function):

header.h:17:1: error: body of 'constexpr' function 'constexpr int __z_log2_impl(T) [with T = int]' not a return-statement
17 | }
| ^

Change CMake line:
set_property(TARGET output.s PROPERTY CXX_STANDARD 11) to
set_property(TARGET output.s PROPERTY CXX_STANDARD 14)
and watch how everything compiles successfully.

Expected behavior

Zephyr defines minimal C++ language standard in the official documentation.
Right now it is C++14 if we do not roll back PR #53405 (probably - remaining C++ code needs verification too!)
Developers know, and check the C++ standard of the code they wright! Please note, that modern compilers GCC, Clang, MSVC tend to provide "backward compatibility" to old C++ standards what results in non-conforming code being compiled without an issue!
If the compiler supports C++17 or C++20 it is possible that it will compile the code marked -std=c++11 that should not compile with that standard due to compiler extensions they provide! We need to watch the conformance carefully, maybe some static analysis tools?

Impact
SOF project has to urgently upgrade toolchain to new Cadence Xtensa "xt-clang" based on clang, that allows to use up to C++17 standard. If we do not do this, we are unable upgrade Zephyr revisions since our code will not build!
Luckily, we had been preparing for toolchain change in https://github.com/thesofproject/sof/pull/7027 for some time and have only 2 .cpp source files at the time of writing.
Logs and console output
Compiling with xt-xcc:  xt-xcc.log
Compiling with xt-clang -std=c++11:  xt-clang C++11.log
Environment (please complete the following information):

OS: Windows, Linux

Additional context
N/A

@aborisovich - documentation only does so much. Why not contribute a PR? Perhaps a test so you are not inconvenienced the same way in the future. It will probably amount to only a few lines of code.

@aborisovich - documentation only goes so far.
Why not contribute a PR? Perhaps a test so you are not inconvenienced the same way in the future.
It will probably amount to only a few lines of code.

Subject is certainly not easy and we need some tool that would run as part of Zephyr CI. And it will certainly not be only a few lines of code. I'm looking for potential solutions. Maybe something like cppcheck added to Compliance Checks workflow would be good for checking standard conformance...

@aborisovich - can you extract just the relevant portion of your error from the log and put it into a markdown code block, so that the error is a bit more visible / searchable?

@cfriedt I never, ever meant to discredit anyone. I assume that as obvious thing, that we developers work with mutual respect.
Bugs, unspecified behaviors are constant part of our work. Moreover, I strongly approve what you do - C++ is a very needed language in Zephyr and I hope it will be replacing or complimenting C in future. When I wrote "you are doing something wrong" I meat it as a quote, not as an expression targeting you directly. By this quote I meant "Zephyr project systems providing API compatibility". I wanted to indicate importance of the problem I described above and potentially severe impact, so we can harden the processes in Zephyr.

@aborisovich - no harsh feelings. I'm glad that we can work together to make things better.
Please let me know if you need any help.

Using -std=c++11 -pedantic should get you similar earnings with GCC. I'm not sure which backwards compatibility extensions you're worried about, generally GCC and clang will warn if you use language features that are not supported by the standard dialect selected with -std

Zephyr docs don't explicitly say C11 or even C99 is required. C11 is still on the table as a pending requirement in RFC #30105
The docs simply state that C99 features are widely used but there is no requirement on it.

(and having said that it's clear I should just put that text in the docs and mark it as fixing this bug)

Zephyr defines C11 as minimal supported standard for C language in C language support - language standards.

That is not necessarily true. The documentation says that most parts of Zephyr only make use of the features available in C99 with some additional components requiring C11 -- i.e. the "minimum" compiler C standard support requirement varies depending on which component(s) you require.
The documentation does not designate a specific "minimum supported" (or "maximum allowed" for that matter) C standard version because some components may benefit from the features available in a more recent version of the standard; nevertheless, the recommendation is to stick with C99 in general and C11 at most.

Expected behavior

Zephyr defines minimal C++ language standard in the official documentation.

For the same reason described above, I would refrain from defining a hard limit; especially for C++ because newer C++ standards have many appealing features.
The documentation should only provide the general recommendation (and the de facto requirement for the core components of Zephyr) for the C++ standard conformance, which would be to stick with C++11 in general. It would be preferable to allow a more recent version of the C++ standard for specific components and modules.

I reopen this issue because it looks to me that you may missed the key point I am trying to show here.
This statement:

For the same reason described above, I would refrain from defining a hard limit; especially for C++ because newer C++ standards have many appealing features.

Is not a resolution to problem with using C++. I agree that new language feature are appealing, but please note what I wrote in the issue description:

Custom toolchains for embedded systems often concentrate on C language support (due to its popularity) leaving C++ language with old standard (like dreadful C++98).

@andyross, filling up documentation with "We support C++ standard whatever found in the give file you compile" is not a solution either. I would rather call it "discrediting a problem" than solving it.
This problem is not related to C, because Zephyr does great job of hiding C language features under #ifdef macros.
Example: What would happen to all zephyr applications if you suddenly add to very commonly used header (like some util header) alignof keyword (supported since C11).
All zephyr applications using C99 would stop to work and would be forced to use C11 compiler right?
You basically do the same for C++ right now, and cover the issue with a blanked - do not do this.

Hm... as of right now we guarantee that all the OS headers build correctly with C++98 compilers (specifically gcc and clang with -std=c++98), and we're testing this along with all the other .  It's true it was a hole, but I'm pretty sure it's been plugged.  Obviously the discussion as to when to deprecate C++98 will be contentious, but for now at least that's the requirement.
Which is to say: if you push a PR right now using alignof or rvalue references or whatever inside an #ifdef __cplusplus, it will fail in CI.  I think that's what you want, no?
(Note that there are other issues with C++ support at the toolchain level, like "how to link in the standard library" that are quite a bit farther behind.  So while the OS has support lots of platforms won't quite build C++98 correctly even if their compilers technically support it; xcc and xt-clang are both in this category for now.)

Maybe I need to make it simple and more concise:
Commit https://github.com/zephyrproject-rtos/zephyr/commit/deab09d7a6b0c51a52ffd8bd03f17e04cf39c25c should not every compile without setting Kconfig option CONFIG_STD_CPP14=y but it does (using CONFIG_STD_CPP11=y) because the compilers you use does not check standard conformity correctly.

Yeah, those problems are fixed as of #55290
Please open a new bug if you find a way to add non-C++98 code to an OS header without doing proper version detection.

Thanks @andyross . Did not notice a whole PR just a single commit modifying docs. Sorry for the hussle.

Using -std=c++11 -pedantic should get you similar warnings with GCC. I'm not sure which backwards compatibility extensions you're worried about, generally GCC and clang will warn (or error) if you use language features that are not supported by the standard dialect selected with -std. You just need to use the option to ask for warnings about extensions, which is -pedantic.

Indeed adding a -pedantic flag to newest gcc also resolves the issue.


Update cabot-alert-hipchat to 2.0.0 (hipchat api v2)

Codecov Report

Merging #481 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #481   +/-   ##
=======================================
  Coverage   80.07%   80.07%
=======================================
  Files          37       37
  Lines        2510     2510
  Branches      156      156
=======================================
  Hits         2010     2010
  Misses        453      453
  Partials       47       47

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 023f283...d77087e. Read the comment docs.

I want to make this properly backwards compatible first


Remove Third-party.txt file

Description
The Security plugin is one of only two plugins (alongside the SQL plugin) which has its own THIRD-PARTY.txt file. This file is not automatically generated and serves no obvious use. This changes follows the suggestions on the linked issue (below) and removes the file.
I requested a legal review for this change just in case and will update this PR with a comment once I have confirmation it is fine to merge.
Issues Resolved

resolves https://github.com/opensearch-project/security/issues/1833

Check List

[ ] ~New functionality includes testing~
[ ] ~New functionality has been documented~
[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@scrawfor99 wdyt about enabling the dependencyLicenses check?

Hi @cwperks, do you mean in general or instead of removing the 3rd party audit file?
This is the search for the existing use of dependencyLicenses across the project. To be honest, I am not positive how it is being used everwhere but it does not look to me that it is actually related to the 3rd party audit file. For instance opensearch-hadoop uses it (https://github.com/opensearch-project/opensearch-hadoop/blob/73b0745d2c247139d4073146cecb3503196a2c08/buildSrc/src/main/java/org/opensearch/hadoop/gradle/buildtools/UpdateShasTask.java#L59) but they do not have the third-party file.
Anyways, I think more checks is better than fewer but am not sure if that is related to the third-party file.

iirc dependencyLicenses enforces that whenever a repo adds dependencies, that they also keep track of the LICENSE and NOTICE for the dependency. With the check enabled, the security plugin would need to keep track of a licenses/ directory that collects the licenses of the dependencies. I believe it can be used in place of Third-party.txt and is the standard for how OpenSearch tracks dependency licenses.

@cwperks Can you create an issue for enabling that task?

Update 1/12/2024:
After legal consult I was told:
"The goal of a THIRD-PARTY.txt file like that is to provide appropriate attribution of third-party software packages from which portions, in source code or binary form, have been copied or otherwise integrated into the project. This is a compliance requirement of most Open Source software licenses.
Importantly, any third-party dependencies that are declared as required to build, test or run the project, but which have not been copied into the project and should instead be supplied by users, do not need to be listed in a THIRD-PARTY.txt file — except maybe as a courtesy to project users who want a quick summary of project dependencies."
This would mean we have to keep the file but I did point out:
"The THIRD-PARTY.txt (https://github.com/opensearch-project/security/blob/main/THIRD-PARTY.txt) file does contain dependencies incorporated in the Security plugin. These are the same Version 2 Apache Licensed dependencies used across OpenSearch as a whole and come from various outside projects such as Apache or Hamcrest.
The fact that we import their libraries does not seem to me like it would require us to keep the file however. Looking at the central OpenSearch, here is an example of where Hamcrest is used (https://github.com/opensearch-project/OpenSearch/blob/a90b6b64d5fbde8c13b6acca076584e8060c599a/server/src/internalClusterTest/java/org/opensearch/action/RejectionActionIT.java#L51). There is no THIRD-PARTY.txt file however.
OpenSearch does make use of license files which I imagine cover the same type of documentation as a THIRD-PARTY listing file would. However, other plugins such as the KNN plugin (https://github.com/opensearch-project/k-NN/blob/45282e056a9eb875aa53b08f7ee5865b277e651b/src/test/java/org/opensearch/knn/KNNTestCase.java#L27C2-L27C2) has neither a THIRD-PARTY.txt file or license files despite also using third party libraries. "
I am of the opinion that we should be safe to remove the file but I am also in no way qualified to know what is/is not okay.
I wanted to share this update while I wait for further input from a legal perspective.

@scrawfor99 @DarshitChanpura Is there something we are waiting on to merge this change?

I wanted to share this update while I wait for further input from a legal perspective.

From what I understand we are waiting for more inputs from legal. I'm okay with removing third party text files if we are sure that any portion of code has not been copied into, and legal gives green light.

Hi @peternied and @DarshitChanpura, thanks for checking in.
So with the last update, I had pushed back that we needed to keep the file. I did not get a response though which is why I did not confirm/deny. I am of the opinion it should be fine but I did not get any further input which is why this is still here...

@scrawfor99 Feel free to take a judgement call here and merge it.

@scrawfor99 I don't think this needs to be backported, up to you.


Deployment to Azure app service fails

Does this occur consistently?
Repro steps:

Action: appService.Deploy
Error type: EPIPE
Error Message: request to https://gileaditdev.scm.azurewebsites.net/api/zipdeploy?isAsync=true&author=VS Code failed, reason: write EPIPE
Version: 0.20.0
OS: darwin
OS Release: 20.1.0
Product: Visual Studio Code
Product Version: 1.51.1
Language: en

Call Stack
ClientRequest.<anonymous> extension.js:236:264795
ClientRequest.emit events.js:228:7
TLSSocket.socketErrorListener _http_client.js:406:9
TLSSocket.emit events.js:223:5
errorOrDestroy destroy.js:108:12
onwriteError _stream_writable.js:456:5
onwrite _stream_writable.js:477:5
destroy.js:50:7destroy.js:50:7
TLSSocket.Socket._destroy net.js:669:5
TLSSocket.destroy destroy.js:38:8
WriteWrap.onWriteComplete [as oncomplete] stream_base_commons.js:88:12

Please provide detailed repro steps.


DISJOINT GRAPHS BATCH TRAINING

❓ Questions & Help
I am working on TV station political advertising disclosure forms data where I am constructing each form(document) as a graph where nodes represent words similarly for each node(word in this case) I created some features. I have multiple documents and each document has different nodes. So for example assuming I has 5 documents and for each node we have 10 features. We need to classify each node into one of the available classes. (Assume we have 5 classes)
This is how it looks:

Document No
Adjacency matrix shape
Features shape
Labels

Document 1
(110X100)
(110X10)
(110X5)

Document 2
(117X117)
(117X10)
(117X5)

Document3
(125X125)
(125X10)
(125X5)

Lets say we have around 1000 documents in similar fashion. Now to train any GCN on this type of data how to batch the data and how to train any GCN

This is quite similar to the PPI dataset, which contains multiple graphs on which you want to label each node (see here for an example).
In general, all you need to do is pass your dataset into a torch_geometric.data.DataLoader and iterate over your dataset in batches:
loader = torch_geometric.data.DataLoader(dataset, batch_size=..., shuffle=True)

for batch in loader:
     # Train just as you would do on a normal node classification task

I am getting this error:

           size[dim] = int(index.max()) + 1
           out = torch.zeros(size, dtype=src.dtype, device=src.device)
           return out.scatter_add_(dim, index, src)
                    ~~~~~~~~~~~~~~~~ <--- HERE
           else:
                 return out.scatter_add_(dim, index, src)
           RuntimeError: index 221 is out of bounds for dimension 0 with size 201

This is the sample data object for your reference:

 Data(edge_index=[2, 346], x=[201, 16], y=[201, 5])

That was my mistake while preparing data. I resolved it. Thanks for the pointers.


Adding duplicate checking and expiration date on generated enrollment codes

Pre-Flight checklist

[X] Testing

[X] Code is tested
[X] Changes have been manually tested

What are the relevant tickets?
none but was mentioned in https://github.com/mitodl/hq/discussions/281
What's this PR do?
Adds two features to the generate_legacy_enrollment_codes management command:

It will now check to see if a code exists for the given user (matching on discount type, redemption type, and amount; product; and user) - if it does, it will skip code creation and emit a message saying as much
You can now specify the expiration date by passing --expires <date> to the command. Dates should be in ISO format (YYYY-MM-DD) though this uses the dateutil package so there is some flexibility here. Passed dates are converted to the default timezone (UTC usually).

How should this be manually tested?

Generate some codes in the normal fashion.
Re-run the same input file. No new codes should be generated.
Delete the generated codes (either directly through the DB or through Django Admin).
Run the input file again, but add --expires <date> to the command. The generated codes should now have an expiration date.

Codecov Report

Merging #1080 (731789c) into main (591754b) will decrease coverage by 0.11%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #1080      +/-   ##
==========================================
- Coverage   85.30%   85.19%   -0.12%
==========================================
  Files         287      287
  Lines       10953    10969      +16
  Branches      719      722       +3
==========================================
+ Hits         9344     9345       +1
- Misses       1399     1415      +16
+ Partials      210      209       -1

Impacted Files
Coverage Δ

...ement/commands/generate_legacy_enrollment_codes.py
0.00% <0.00%> (ø)

ecommerce/models.py
88.79% <0.00%> (ø)

ecommerce/views/v0/__init__.py
90.08% <0.00%> (+0.43%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

merging this - I don't know what the odlbot failure is but I don't think it means anything quite yet


"pip install readme" fails on Windows + Miniconda

I'm trying to install the restview library and it depends on the readme library.
I'm getting this error though:
C:\
λ pip install readme
Collecting readme
  Using cached readme-0.5.1-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): docutils in c:\miniconda\lib\site-packages (from readme)
Requirement already satisfied (use --upgrade to upgrade): Pygments in c:\miniconda\lib\site-packages (from readme)
Requirement already satisfied (use --upgrade to upgrade): six in c:\miniconda\lib\site-packages (from readme)
Requirement already satisfied (use --upgrade to upgrade): bleach in c:\miniconda\lib\site-packages (from readme)
Requirement already satisfied (use --upgrade to upgrade): html5lib>=0.999 in c:\miniconda\lib\site-packages (from bleach->readme)
Installing collected packages: readme
Exception:
Traceback (most recent call last):
  File "C:\Miniconda\lib\site-packages\pip\basecommand.py", line 223, in main
    status = self.run(options, args)
  File "C:\Miniconda\lib\site-packages\pip\commands\install.py", line 297, in run
    root=options.root_path,
  File "C:\Miniconda\lib\site-packages\pip\req\req_set.py", line 622, in install
    **kwargs
  File "C:\Miniconda\lib\site-packages\pip\req\req_install.py", line 808, in install
    self.move_wheel_files(self.source_dir, root=root)
  File "C:\Miniconda\lib\site-packages\pip\req\req_install.py", line 1003, in move_wheel_files
    isolated=self.isolated,
  File "C:\Miniconda\lib\site-packages\pip\wheel.py", line 339, in move_wheel_files
    clobber(source, lib_dir, True)
  File "C:\Miniconda\lib\site-packages\pip\wheel.py", line 317, in clobber
    shutil.copyfile(srcfile, destfile)
  File "C:\Miniconda\lib\shutil.py", line 83, in copyfile
    with open(dst, 'wb') as fdst:
IOError: [Errno 2] No such file or directory: 'C:\\Miniconda\\Lib\\site-packages\\readme\\clean.py'

These are the versions of conda and pip that I'm using:
C:\
λ conda -V
conda 3.11.0-dirty

C:\
λ pip --version
pip 7.0.3 from C:\Miniconda\lib\site-packages (python 2.7)

I'm using Windows 7 64 bits

This seems like a duplicate of #26. The fix here would probably require a renaming.

see mgedmin/restview#30
also pypa/pip#2821
and https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/AGHXzB1sN0I

http://bugs.python.org/issue24633

Will the package stay available as readme, too, on pypi? I'd hate to see (for instance) zest.releaser installs fail ;-)

@reinout I've released readme 0.7.0 that raises an exception on install. If you pin to readme<0.7.0 you should be good.

"Should be good" means "this just broke every package that has 'readme' as a dependency". A warning would have been much better.
I mean, the original readme package works fine in most places. At least, I haven't had any bug reports for zest.releaser because it wouldn't install. I'll of course issue a new release that depends on the new package name.
But existing zest.releaser versions would have worked just fine with 'readme', but now their install is terminated because of the error that is raised.
Could you release a 0.7.1 that only prints a warning? (Loud warning is fine, of course :-) )

@reinout This is tracked in #40 now.


Question regarding .Builder()

Awesome work, I was trying to implement the FAB and got an error regarding .Builder says it "cannot resolve symbol 'Builder' which threw me off. I check build.gradle and it is current and project is synced. Any possible suggestions. Minimum API is set to 21, thanks.

Delete the import and import the correct class into the activity


Back-merge v<IP_ADDRESS> release branch to main

Codecov Report

Merging #17 (4b4e356) into main (58b9af6) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines           73        73
=========================================
  Hits            73        73

Impacted Files
Coverage Δ

src/flake8_absolute_import/__init__.py
100.00% <ø> (ø)

src/flake8_absolute_import/core.py
100.00% <ø> (ø)

src/flake8_absolute_import/version.py
100.00% <ø> (ø)

tests/test_plugin.py
100.00% <ø> (ø)

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 58b9af6...4b4e356. Read the comment docs.


Update query-parquet-files.md

Fix link to page on querying CSV files - currently links to the same page on Parquet files

@azaricstefan - can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Approved


how to use after training model?

can you give a demo of usage after training model and inferer, or a more detailed document?

sorry we don't have a document now. You can see the usage from here https://github.com/Microsoft/lightlda/blob/master/src/common.cpp#L94

If there is a new document, how to output the theme distribution of the new document?


Cannot use more than one diagnosis for posteriors/prevalences

As of now, only one diagnostic modality may be provided to compute the posteriors or prevalences. Obviously, we want to allow using multiple ones. And I think my original thought of not allowing that to make the computation more efficient was stupid anyways, because I did not take advantage of that.


Encryption algorithms other than RSA

Description
My docker registry gives me a key encrypted with the ECDSA algoritm. At least, that's what I think when I read the key.pem
PEMParser pemParser = new PEMParser(new BufferedReader(new FileReader("key.pem")));
Object object = pemParser.readObject();
JcaPEMKeyConverter converter = new JcaPEMKeyConverter().setProvider("BC");
if (object instanceof PEMKeyPair) {
  PEMKeyPair pair = (PEMKeyPair) object;
  converter.getPrivateKey(pair.getPrivateKeyInfo()).getAlgorithm()
}

Then DockerCertificates throws exception maybe because of line 97.
How to reproduce
Don't know. If your docker registry gives you ECDSA-encrypted key, then you can try.
What do you expect
Maybe bouncycastle can be used to find the encryption algorithm.
What happened instead
exception java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: Invalid RSA private key: Version must be 0
[Describe the actual results]
Software:
docker-maven-plugin:0.4.13
Full backtrace
[Paste full backtrace here]

Hi @dxxvi ,
Since this project went on mature status, please re-open this issue (if it still stands) to https://github.com/dmandalidis/docker-client. Thanks


Fetching maven relocation issues is flaky, leading to missing relocations

See, for example,  https://quarkus.io/extensions/io.quarkus/quarkus-webjars-locator/ which should be a relocation but today is not. Similarly, https://quarkus.io/extensions/io.quarkus/quarkus-rest/.
We cache to reduce flakiness of the maven API but I think one side effect of this is that errors and missing data persist for longer.

For io.quarkus:quarkus-webjars-locator there is a relocation information in quarkus-webjars-locator-3.14.2.pom
For io.quarkus:quarkus-rest I do not see it in quarkus-rest-3.14.2.pom

For me the maven API way to check if there is a newer version since 3.10.2 is to fetch the maven-metadata.xml file.

Yes, that's the bit that fails intermittently in the CI. We just can't fetch the files from maven reliably. We cache to reduce our dependence on the flaky maven APIs, but that also means once we decide a relocation doesn't exist, we cache that incorrect answer. (Fixing that so we only cache correct answers, not incorrect answers, is the intention of this work item.)

For io.quarkus:quarkus-rest I do not see a relocated information in quarkus-rest-3.14.2.pom.

The quarkus-rest artifact is the newer one, so for that pair of artifacts, the relocation information is in https://central.sonatype.com/artifact/io.quarkus/quarkus-resteasy-reactive.
As an example of it working/not-working intermittently, last Wednesday, https://quarkus.io/extensions/io.quarkiverse.reactivemessaging.nats-jetstream/quarkus-reactive-messsaging-nats-jetstream/ gave this:

On Thursday and Friday the relocation information wasn't visible on the live site. I went to take a screencap showing the missing of relocation information today, but the relocation information is back, so I can't screencap the failure case. There's been no code changes in that time, just flaky download endpoints for the information we need, and cache expiries making everything even more non-deterministic.

I see you are doing already a lot and mostly I can't follow what is going on.

We just can't fetch the files from maven reliably.

I don't know what you are doing, but I can't imagine that fetching the latest version of quarkus-webjars-locator:
<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-webjars-locator</artifactId>
  <version>RELEASE</version>
</dependency>

can return the 3.10.2 version…
Sometimes you can have some caching delay, but not more than 3 months (3.11.0 was released on May 22, 2024)

I did some more investigations that might be interesting…
I think the major issue is that maven already "resolves" the relocation information. I found online that a [warn] line might be in the build logs.
As a convinced gradle user, I tried it there as well, and
I am really more used to the way gradle works (which corresponds in most the the cases to my expectations).
1) getting the effective POM
With the command:
mvn org.apache.maven.plugins:maven-help-plugin:3.5.0:effective-pom -Dartifact=io.quarkus:quarkus-webjars-locator:RELEASE

in a project where you have a dummy pom.xml file:
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>g</groupId>
    <artifactId>a</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>
</project>

returns a very long effective pom, but already pointing to the new location:
<?xml version="1.0" encoding="UTF-8"?>
<!-- ====================================================================== -->
<!--                                                                        -->
<!-- Generated by Maven Help Plugin                                         -->
<!-- See: https://maven.apache.org/plugins/maven-help-plugin/               -->
<!--                                                                        -->
<!-- ====================================================================== -->
<!-- ====================================================================== -->
<!--                                                                        -->
<!-- Effective POM for project                                              -->
<!-- 'io.quarkus:quarkus-web-dependency-locator:jar:3.14.2'                 -->
<!--                                                                        -->
<!-- ====================================================================== -->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" child.project.url.inherit.append.path="false">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-web-dependency-locator-parent</artifactId>
    <version>3.14.2</version>
  </parent>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-web-dependency-locator</artifactId>
  <version>3.14.2</version>
  <name>Quarkus - Web Dependency Locator - Runtime</name>
  <description>Simplify paths and importmap support for Web dependencies</description>
  <url>https://github.com/quarkusio/quarkus</url>
  <inceptionYear>2020</inceptionYear>
  ...

2) jbang info tools
Mimimal jbang script:
Content of X.java
class X {}

Call:
jbang info tools --deps artifact=io.quarkus:quarkus-webjars-locator:RELEASE

contains in the first line of resolvedDependencies a reference to quarkus-web-dependency-locator-3.14.2.jar
complete output

{
  "originalResource": "X.java",
  "backingResource": "/___user-home___/tmp/tmp-pom/output/X.java",
  "applicationJar": "/___user-home___/.jbang/cache/jars/X.java.5ffc598c82aff782fe8bf6d2d11081c5cce8d44d6c77d020e95a9a23aa56d7ac/X.jar",
  "dependencies": [
    "io.quarkus:quarkus-webjars-locator:RELEASE"
  ],
  "resolvedDependencies": [
    "/___user-home___/.m2/repository/io/quarkus/quarkus-web-dependency-locator/3.14.2/quarkus-web-dependency-locator-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-core/3.14.2/quarkus-core-3.14.2.jar",
    "/___user-home___/.m2/repository/jakarta/annotation/jakarta.annotation-api/3.0.0/jakarta.annotation-api-3.0.0.jar",
    "/___user-home___/.m2/repository/jakarta/enterprise/jakarta.enterprise.cdi-api/4.1.0/jakarta.enterprise.cdi-api-4.1.0.jar",
    "/___user-home___/.m2/repository/jakarta/enterprise/jakarta.enterprise.lang-model/4.1.0/jakarta.enterprise.lang-model-4.1.0.jar",
    "/___user-home___/.m2/repository/jakarta/el/jakarta.el-api/6.0.0/jakarta.el-api-6.0.0.jar",
    "/___user-home___/.m2/repository/jakarta/interceptor/jakarta.interceptor-api/2.2.0/jakarta.interceptor-api-2.2.0.jar",
    "/___user-home___/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1/jakarta.inject-api-2.0.1.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-os/2.6.0/smallrye-common-os-2.6.0.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-ide-launcher/3.14.2/quarkus-ide-launcher-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-development-mode-spi/3.14.2/quarkus-development-mode-spi-3.14.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/config/smallrye-config/3.9.1/smallrye-config-3.9.1.jar",
    "/___user-home___/.m2/repository/io/smallrye/config/smallrye-config-core/3.9.1/smallrye-config-core-3.9.1.jar",
    "/___user-home___/.m2/repository/org/eclipse/microprofile/config/microprofile-config-api/3.1/microprofile-config-api-3.1.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-classloader/2.4.0/smallrye-common-classloader-2.4.0.jar",
    "/___user-home___/.m2/repository/org/ow2/asm/asm/9.7/asm-9.7.jar",
    "/___user-home___/.m2/repository/io/smallrye/config/smallrye-config-common/3.9.1/smallrye-config-common-3.9.1.jar",
    "/___user-home___/.m2/repository/org/jboss/logging/jboss-logging/3.6.0.Final/jboss-logging-3.6.0.Final.jar",
    "/___user-home___/.m2/repository/org/jboss/logmanager/jboss-logmanager/3.0.6.Final/jboss-logmanager-3.0.6.Final.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-constraint/2.2.0/smallrye-common-constraint-2.2.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-cpu/2.2.0/smallrye-common-cpu-2.2.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-expression/2.2.0/smallrye-common-expression-2.2.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-function/2.2.0/smallrye-common-function-2.2.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-net/2.2.0/smallrye-common-net-2.2.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-ref/2.2.0/smallrye-common-ref-2.2.0.jar",
    "/___user-home___/.m2/repository/jakarta/json/jakarta.json-api/2.1.3/jakarta.json-api-2.1.3.jar",
    "/___user-home___/.m2/repository/org/eclipse/parsson/parsson/1.1.6/parsson-1.1.6.jar",
    "/___user-home___/.m2/repository/org/jboss/logging/jboss-logging-annotations/3.0.1.Final/jboss-logging-annotations-3.0.1.Final.jar",
    "/___user-home___/.m2/repository/org/jboss/threads/jboss-threads/3.6.1.Final/jboss-threads-3.6.1.Final.jar",
    "/___user-home___/.m2/repository/org/slf4j/slf4j-api/2.0.6/slf4j-api-2.0.6.jar",
    "/___user-home___/.m2/repository/org/jboss/slf4j/slf4j-jboss-logmanager/2.0.0.Final/slf4j-jboss-logmanager-2.0.0.Final.jar",
    "/___user-home___/.m2/repository/org/wildfly/common/wildfly-common/1.7.0.Final/wildfly-common-1.7.0.Final.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-bootstrap-runner/3.14.2/quarkus-bootstrap-runner-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-classloader-commons/3.14.2/quarkus-classloader-commons-3.14.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-io/2.6.0/smallrye-common-io-2.6.0.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-fs-util/0.0.10/quarkus-fs-util-0.0.10.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-vertx-http/3.14.2/quarkus-vertx-http-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-security-runtime-spi/3.14.2/quarkus-security-runtime-spi-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-tls-registry/3.14.2/quarkus-tls-registry-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-arc/3.14.2/quarkus-arc-3.14.2.jar",
    "/___user-home___/.m2/repository/org/eclipse/microprofile/context-propagation/microprofile-context-propagation-api/1.3/microprofile-context-propagation-api-1.3.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-credentials/3.14.2/quarkus-credentials-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/arc/arc/3.14.2/arc-3.14.2.jar",
    "/___user-home___/.m2/repository/jakarta/transaction/jakarta.transaction-api/2.0.1/jakarta.transaction-api-2.0.1.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-mutiny/3.14.2/quarkus-mutiny-3.14.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/mutiny/2.6.2/mutiny-2.6.2.jar",
    "/___user-home___/.m2/repository/org/jctools/jctools-core/4.0.5/jctools-core-4.0.5.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-smallrye-context-propagation/3.14.2/quarkus-smallrye-context-propagation-3.14.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/smallrye-context-propagation/2.1.2/smallrye-context-propagation-2.1.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/smallrye-context-propagation-api/2.1.2/smallrye-context-propagation-api-2.1.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/smallrye-context-propagation-storage/2.1.2/smallrye-context-propagation-storage-2.1.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/mutiny-smallrye-context-propagation/2.6.2/mutiny-smallrye-context-propagation-2.6.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-vertx-context/2.6.0/smallrye-common-vertx-context-2.6.0.jar",
    "/___user-home___/.m2/repository/io/vertx/vertx-core/4.5.9/vertx-core-4.5.9.jar",
    "/___user-home___/.m2/repository/io/netty/netty-common/4.1.111.Final/netty-common-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-buffer/4.1.111.Final/netty-buffer-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-transport/4.1.111.Final/netty-transport-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-handler/4.1.111.Final/netty-handler-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-transport-native-unix-common/4.1.111.Final/netty-transport-native-unix-common-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-handler-proxy/4.1.111.Final/netty-handler-proxy-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-codec-socks/4.1.111.Final/netty-codec-socks-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-codec-http/4.1.111.Final/netty-codec-http-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-codec-http2/4.1.111.Final/netty-codec-http2-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-resolver/4.1.111.Final/netty-resolver-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-resolver-dns/4.1.111.Final/netty-resolver-dns-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/netty/netty-codec-dns/4.1.111.Final/netty-codec-dns-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.16.1/jackson-core-2.16.1.jar",
    "/___user-home___/.m2/repository/io/quarkus/security/quarkus-security/2.1.0/quarkus-security-2.1.0.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-vertx/3.14.2/quarkus-vertx-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-netty/3.14.2/quarkus-netty-3.14.2.jar",
    "/___user-home___/.m2/repository/io/netty/netty-codec/4.1.111.Final/netty-codec-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/com/aayushatharva/brotli4j/brotli4j/1.16.0/brotli4j-1.16.0.jar",
    "/___user-home___/.m2/repository/com/aayushatharva/brotli4j/service/1.16.0/service-1.16.0.jar",
    "/___user-home___/.m2/repository/com/aayushatharva/brotli4j/native-osx-x86_64/1.16.0/native-osx-x86_64-1.16.0.jar",
    "/___user-home___/.m2/repository/io/netty/netty-codec-haproxy/4.1.111.Final/netty-codec-haproxy-4.1.111.Final.jar",
    "/___user-home___/.m2/repository/io/smallrye/common/smallrye-common-annotation/2.6.0/smallrye-common-annotation-2.6.0.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-virtual-threads/3.14.2/quarkus-virtual-threads-3.14.2.jar",
    "/___user-home___/.m2/repository/io/quarkus/quarkus-vertx-latebound-mdc-provider/3.14.2/quarkus-vertx-latebound-mdc-provider-3.14.2.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/smallrye-mutiny-vertx-core/3.14.0/smallrye-mutiny-vertx-core-3.14.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/smallrye-mutiny-vertx-runtime/3.14.0/smallrye-mutiny-vertx-runtime-3.14.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/vertx-mutiny-generator/3.14.0/vertx-mutiny-generator-3.14.0.jar",
    "/___user-home___/.m2/repository/io/vertx/vertx-codegen/4.5.9/vertx-codegen-4.5.9.jar",
    "/___user-home___/.m2/repository/io/smallrye/smallrye-fault-tolerance-vertx/6.4.0/smallrye-fault-tolerance-vertx-6.4.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/smallrye-mutiny-vertx-web/3.14.0/smallrye-mutiny-vertx-web-3.14.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/smallrye-mutiny-vertx-web-common/3.14.0/smallrye-mutiny-vertx-web-common-3.14.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/smallrye-mutiny-vertx-auth-common/3.14.0/smallrye-mutiny-vertx-auth-common-3.14.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/smallrye-mutiny-vertx-bridge-common/3.14.0/smallrye-mutiny-vertx-bridge-common-3.14.0.jar",
    "/___user-home___/.m2/repository/io/smallrye/reactive/smallrye-mutiny-vertx-uri-template/3.14.0/smallrye-mutiny-vertx-uri-template-3.14.0.jar",
    "/___user-home___/.m2/repository/io/vertx/vertx-uri-template/4.5.9/vertx-uri-template-4.5.9.jar",
    "/___user-home___/.m2/repository/io/vertx/vertx-web/4.5.9/vertx-web-4.5.9.jar",
    "/___user-home___/.m2/repository/io/vertx/vertx-web-common/4.5.9/vertx-web-common-4.5.9.jar",
    "/___user-home___/.m2/repository/io/vertx/vertx-auth-common/4.5.9/vertx-auth-common-4.5.9.jar",
    "/___user-home___/.m2/repository/io/vertx/vertx-bridge-common/4.5.9/vertx-bridge-common-4.5.9.jar",
    "/___user-home___/.m2/repository/io/github/crac/org-crac/0.1.3/org-crac-0.1.3.jar"
  ],
  "availableJdkPath": "/___user-home___/.sdkman/candidates/java/21.0.2-tem",
  "compileOptions": [
    "-g"
  ],
  "sources": [
    {
      "originalResource": "X.java",
      "backingResource": "/___user-home___/tmp/tmp-pom/output/X.java"
    }
  ]
}

3) Using Gradle to download the pom
At the end the way I managed to look at the pom the way it is hosted on maven central is to use gradle:
build.gradle file:
configurations {
    conf
}

repositories {
    mavenCentral()
}

dependencies {
    conf("io.quarkus:quarkus-webjars-locator:latest.release@pom")
}

//simple task to download the content of the "conf" configuration into the "output" folder
task copyDependencies(type: Copy) {
   from configurations.conf
   into 'output'
}

And then calling gradle copyDependencies copies the expected POM file into the output folder:
output
└── quarkus-webjars-locator-3.14.2.pom

3.b) trying to download the relocated jar with gradle
I then tried to changed the line to indicate to gradle to fetch the jar:
    conf("io.quarkus:quarkus-webjars-locator:latest.release")

And it is failing with:
* What went wrong:
Execution failed for task ':copyDependencies'.
> Could not resolve all files for configuration ':conf'.
   > Could not find io.quarkus:quarkus-web-dependency-locator:${project.version}.
     Required by:
         project : > io.quarkus:quarkus-webjars-locator:3.14.2

This might bug in Gradle, because I think they do not fully honor the resolution of ${project.variable} (see "Project Interpolation and Variables") in this case.
Nobody is perfect 😉
I also saw this open issue about not telling that the relocated jar was loaded: https://github.com/gradle/gradle/issues/26436

I see you are doing already a lot and mostly I can't follow what is going on.

We just can't fetch the files from maven reliably.

I don't know what you are doing, but I can't imagine that fetching the latest version of quarkus-webjars-locator:
<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-webjars-locator</artifactId>
  <version>RELEASE</version>
</dependency>

can return the 3.10.2 version…
Sometimes you can have some caching delay, but not more than 3 months (3.11.0 was released on May 22, 2024)

The longest we have our cache set to hold information for is about 10 days, and that's only for data that we expect not to change at all. The reason the version number is old is that you're looking at the pre-relocation version of the page (you can tell from the URL, which is io.quarkus/quarkus-webjars-locator/, the previous coordinates). The last version released with the old maven coordinates is 3.10.2, which is why you're seeing that version. If you want to see the more recent releases, you should use the url with the updated coordinates, https://quarkus.io/extensions/io.quarkus/quarkus-web-dependency-locator/.
The "old" page should have a little banner at the top saying 'there's a new version of this jar', and the "new" version should say "this used to have a different name." That's not happening, because the maven endpoint is flaky and was having a bad day when we populated the cache, so we weren't able to get the relevant xml out of maven central. At some point, in a non-deterministic way (or if I improve the caching logic to propagate errors around so it never caches 'error' results), both pages will show what they're supposed to.

The last version released with the old maven coordinates is 3.10.2, which is why you're seeing that version

This is where I think I disagree with this analysis.
This is the latest version that has a jar extension.
If you would do a pom extension lookup (artifact with coordinates io.quarkus:quarkus-webjars-locator:latest.release@pom in gradle) that you can also lookup manually based on [maven-metadata.xml](https://repo1.maven.org/maven2/io/quarkus/quarkus-webjars-locator/maven-metadata.xml) and then for each entry in that file to the correspond file with a pom extension (see here for the string concatenation logic) you will find the data you need.
And because you are doing a good job in the quarkus project, you even have a message pointing to the release note or blog post. But you need the pom file to know this.


added dependencyManagement section for better versioning management

Usually it's better idea to use dependencyManagement section in maven project for better library management although it doesn't look simple & clean for single module maven project.

We will make such change once we end up moving to a multi-module project. I don't see the benefit of doing this for a single-module project.


Remove staterefs from ref cache on unmount

Goal
Eliminate a (slight) memory leak caused by the indefinite retention of StateRefs by the REF_CACHE when the time-to-live is 0 by removing a StateRef from the REF_CACHE when its component is unmounted (reported in #230).
How Can This Be Tested?

Checkout the source branch at commit 856002c
yarn
yarn test
Observe the test failures.
Checkout the source branch at commit 2b4a1bc
yarn test
Verify the tests succeed.

EDIT: Corrected commit order.

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

hey @jefrailey thanks for this patch! I've approved the build to run which is now failing. Can you fix the lint issues? Can approve afterwards. Thanks for the tests!

@darrenjennings Will do. It looks like it's all formatting issues--looks like I forgot to run yarn lint. I'm busy for the rest of the evening, but will fix this first thing tomorrow.

hi guys could be great also for the beta ;)


ci: fix storybook deploy

Note: This branch is just for testing. Let's make updates and merge @jpandersen87's PR (https://github.com/trussworks/react-uswds/pull/2843) instead so they get the credit.

This works. Will recommend to @jpandersen87 to update on the original branch.


Added support for a JSON health endpoint

I need machine parseable health reports for our monitoring infrastructure, so I added a JSON endpoint.

Also merged in a few prior PRs that look seemed useful.

@clearclaw that is a great idea! Can you rebase to the latest master please? Thanks!

A JSON endpoint is available now in version 2.2.0


Add stack example

Codecov Report

Merging #1 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #1   +/-   ##
=======================================
  Coverage   55.84%   55.84%
=======================================
  Files         124      124
  Lines        1762     1762
=======================================
  Hits          984      984
  Misses        719      719
  Partials       59       59

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 bf963a5...b940fce. Read the comment docs.


New version: ShareX.ShareX version 16.1.0

Pull request has been created with komac v2.2.1 :rocket:
Microsoft Reviewers: Open in CodeFlow

Please add Resolves: https://github.com/microsoft/winget-pkgs/issues/153315 to your description to auto close this


cdkVirtualFor don't binding the content of my list in unit tests

I am using the visrtual scroll strategy in my project, but in my unit tests I use this structure for research all tags  on my html list
let elements: DebugElement[] = fixture.debugElement.queryAll(By.css('span'));
expect('Today').toBe(elements[0].nativeElement.textContent);
this is my html structure:
<cdk-virtual-scroll-viewport [itemSize]="50" [minBufferPx]="buffer" [maxBufferPx]="buffer * 1.5" cass="fullHeight" >     <div #firstChild class="content">             <div *cdkVirtualFor="let demandaAgrupada of demandasAgrupadas; templateCacheSize: 1000" >                 <span *ngIf="demandaAgrupada.exibeCabecalho">{demandaAgrupada.grupoPeriodo}}/span>                 <pd-demanda-agrupada [demandaAgrupada]="demandaAgrupada" ></pd-demanda-grupada>             </div>     </div> </cdk-virtual-scroll-viewport>
When i use *ngFor instead of  *cdkVirtualFor, my test works.
But if I use *cdkVirtualFor, all content of my list isen't binding
and the div of *cdkVirtualFor, isen't binding too
this is my last element binding
<!--bindings={↵  "ng-reflect-cdk-virtual-for-of": "[object Object],[object Object",↵  "ng-reflect-cdk-virtual-for-template-cache-size": "1000"↵}-->
there is a bug on unit tests with *cdkVirtualFor ?
sorry about my english, is not my first language

Please keep GitHub issues for bug reports / feature requests. Better avenues for troubleshooting / questions are stack overflow, gitter, mailing list, etc.

@Jonas-Ceolin-Alberton Were you able to fix the issue?

Hi @acutexyz , not yet.

@Jonas-Ceolin-Alberton I managed to make my case work, see this: https://stackoverflow.com/questions/53726484/angular-material-virtual-scroll-not-rendering-items-in-unit-tests/53748915#53748915

Maybe a bit late, but @acutexyz  solution was not working for me i solved this with:
    it("should render data from hypercube", fakeAsync(() => {
        ...
        fixture.autoDetectChanges();
        flush();  /* thats make it work */

        const listElements = fixture.debugElement.queryAll(By.css("div.lui-list__item"));
        expect(listElements.length).toBe(2);
    }));

Workss for me!, thanks @r-hannuschka


Verify your Status contacts' identity

Hi @earakel,
While working on the on screen help project and analyzing the Figma files, I noticed that this article was not written yet. I would like to point out that there are Figma files that need to be observed when writing this article. The Figma files are the most updated to the present time (desktop version). My goal here is just to make things simple by  listing the Figma files that I found that relate to this issue.
Figma files:

Request identity verification

Mark as identity verified

Mark as untrusted

The Figma file says that only a contact can be marked as untrusted or trusted. Communities and group chats cannot be marked as untrusted or trusted. You can also mark a contact as trusted or untrusted before or during ID request verification process.

Admonition


Fixes #1539. Use the most common X-RateLimit-* instead of X-Rate-Limit-*

This PR

just replace X-Rate-Limit-* with X-RateLimit

Because

the X-RateLimit is more common (see #1539)
this avoid confusion when copy-paste part of the specs to create new services.

The @OAI/tsc has performed a search and it looks like you can easily find examples of both forms exist out there in different public popular APIs. Since there's no standard, we don't feel there's a compelling reason to make the change. Thanks for taking the time to bring it up though.


Not stopping on breakpoint

Hello,
Under following configuration I'm not able to stop xdebug on breakpoints:
Q: What operation system(s) and version of Sublime Text are you using?
A: Windows 7 Professional 64-bit and SublimeText 3 Build 3065
Q: How did you install SublimeTextXdebug, Package Control, git clone or download?
A: Via download
Q: Are you trying to debug the script remotely or locally, through browser or command line?
A: Through browser
Q: Which version of Xdebug extension do you have?
A: Xdebug version php_xdebug-2.2.5-5.5-vc11-x86_64
Q: Can you post your project/settings file and Xdebug configuration from the *.ini located on your server.
A: Yes
; XDEBUG configuration
zend_extension = "g:/wamp/bin/php/php5.5.12/zend_ext/php_xdebug-2.2.5-5.5-vc11-x86_64.dll"
;
[xdebug]
xdebug.remote_enable = 1
xdebug.remote_host = "<IP_ADDRESS>"
xdebug.remote_port = 9000
xdebug.remote_handler = "dbgp"
xdebug.remote_mode = req
;xdebug.remote_connect_back = 1
xdebug.remote_log="g:/wamp/tmp/xdebug.log"
//project/settings file
{
"folders":
[
{
"follow_symlinks": true,
"path": "H:\lokal\mikrobakery-rep\local"
}
],
"settings":
{
"xdebug": {
"url": "http://mare-pc:81/",
"super_globals": true,
"close_on_stop": true
}
}
}
Q: Does the console window (Ctrl+`) show any more information regarding the error?
A: Console window does not show any errors
Thank you for your time.
Sincerely,
Marko

Also here is xdebug log:
Log opened at 2015-03-23 17:53:20
I: Connecting to configured address/port: <IP_ADDRESS>:9000.
I: Connected to client. :-)
-> XdebugDerick Rethanshttp://xdebug.orgCopyright (c) 2002-2014 by Derick Rethans
<- feature_set -i 1 -n show_hidden -v 1
->
<- feature_set -i 2 -n max_children -v 32
->
<- feature_set -i 3 -n max_data -v 1024
->
<- feature_set -i 4 -n max_depth -v 1
->
<- breakpoint_set -i 5 -t line -f file%3A//H%3A%5Clokal%5Cmikrobakery-rep%5Clocal%5Capp%5Ccontrollers%5Ccarts_controller.php -n 4460
->
<- run -i 6
->
Log closed at 2015-03-23 17:53:22
Log opened at 2015-03-23 17:53:23
I: Connecting to configured address/port: <IP_ADDRESS>:9000.
I: Connected to client. :-)
-> XdebugDerick Rethanshttp://xdebug.orgCopyright (c) 2002-2014 by Derick Rethans
<- feature_set -i 1 -n show_hidden -v 1
->
<- feature_set -i 2 -n max_children -v 32
->
<- feature_set -i 3 -n max_data -v 1024
->
<- feature_set -i 4 -n max_depth -v 1
->
<- breakpoint_set -i 5 -t line -f file%3A//H%3A%5Clokal%5Cmikrobakery-rep%5Clocal%5Capp%5Ccontrollers%5Ccarts_controller.php -n 4460
->
<- run -i 6
->
Log closed at 2015-03-23 17:53:23


YARD documentation for dry-matcher

I am continuing my effort on document dry-* gems (see dry-rb/dry-types#166, dry-rb/dry-struct#25).

Wonderful! Thanks @alsemyonov. The CI failure is unrelated (it's a Travis/Rubinius config issue), so I'll pull this in now.


[Bug] Application Usage increases based on Pulse requests

Pulse Version
v1.2.5
Laravel Version
11.25.0
PHP Version
PHP 8.3.12 (cli) (built: Sep 27 2024 00:18:43) (NTS)
Livewire Version
v3.5.8
Database Driver & Version
SQLite
Description
I'll be honest in saying that I don't know if this is a bug, but at least it seems confusing.
I've had Pulse in production for 4 days, and I noticed a significant increase in the numbers for Application Usage -> Top 10 users: making requests. Only today I discovered the reason: we're using Pulse in production and performing browser refreshes to follow some data in real-time.
The first Pulse card is Application Usage, where the term "Application", IMHO, means that it refers to the application, but the requests made to Pulse are counted as requests of the application. Today we've 32 people in the project and daily we've approximately 15 devs (the entire dev team) viewing Pulse all the time.
If this IS NOT A BUG, wouldn't it be correct to rename this board? When we say "application", we might think that it is just really the application, and Pulse is not exactly the application, or part of it.
Demo (locally):

Steps To Reproduce

Install Pulse
Access the Pulse dashboard
Refresh the browser a lot of times, you'll be able to see what I'm saying

There is an option in the config file to ignore certain route patterns. This is set to ignore the pulse route by default. Can you check whether the pulse route is still listed in the ignored routes?

I'm unable to replicate this on a fresh application installation.
We will need some more information on how to replicate the issue, a replication repository, or to see your config/pulse.php configuration file.
The only way I could replicate this behaviour is by commenting out the ignore configuration in config/pulse.php.
        Recorders\UserRequests::class => [
            'enabled' => env('PULSE_USER_REQUESTS_ENABLED', true),
            'sample_rate' => env('PULSE_USER_REQUESTS_SAMPLE_RATE', 1),
            'ignore' => [
-               '#^/'.env('PULSE_PATH', 'pulse').'$#', // Pulse dashboard...
                '#^/telescope#', // Telescope dashboard...
            ],
        ],

You could use Pulse to debug this. If you set the slow outgoing requests threshold to zero and make sure the ignores for Recorders\SlowRequests match Recorders\UserRequests. The requests it is counting should then show up as slow requests.

I'm unable to replicate this on a fresh application installation.
We will need some more information on how to replicate the issue, a replication repository, or to see your config/pulse.php configuration file.
The only way I could replicate this behaviour is by commenting out the ignore configuration in config/pulse.php.
        Recorders\UserRequests::class => [
            'enabled' => env('PULSE_USER_REQUESTS_ENABLED', true),
            'sample_rate' => env('PULSE_USER_REQUESTS_SAMPLE_RATE', 1),
            'ignore' => [
-               '#^/'.env('PULSE_PATH', 'pulse').'$#', // Pulse dashboard...
                '#^/telescope#', // Telescope dashboard...
            ],
        ],

You could use Pulse to debug this. If you set the slow outgoing requests threshold to zero and make sure the ignores for Recorders\SlowRequests match Recorders\UserRequests. The requests it is counting should then show up as slow requests.

I'll close this for now. If it happens again I'll get all the necessary data. I couldn't reproduce it anymore, but I'm sure I didn't mess with the config file.

No worries. Yell out if you see it again.


RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation

I'm getting this error when running v1-finetune.yaml
Variable._execution_engine.run_backward(                                                                            RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation: [torch.cuda.FloatTensor [4, 1024, 77]], which is output 0 of AsStridedBackward0, is at version 2; expected version 1 instead. Hint: enable anomaly detection to find the operation that failed to compute its gradient, with torch.autograd.set_detect_anomaly(True).
Here's the full stack:

Traceback (most recent call last):                                                                                File "main.py", line 796, in                                                                                trainer.fit(model, data)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 740, in fit                    self._call_and_handle_interrupt(                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 685, in _call_and_handle_interrupt                                                                                return trainer_fn(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 777, in _fit_impl              self._run(model, ckpt_path=ckpt_path)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1199, in _run                  self._dispatch()                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1279, in _dispatch             self.training_type_plugin.start_training(self)                                                                        File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\plugins\training_type\training_type_plugin.py", line 202, in start_training                                                                                self._results = trainer.run_stage()                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1289, in run_stage             return self._run_train()                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\trainer\trainer.py", line 1319, in _run_train            self.fit_loop.run()                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\base.py", line 145, in run                         self.advance(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\fit_loop.py", line 234, in advance                 self.epoch_loop.run(data_fetcher)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\base.py", line 145, in run                         self.advance(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\epoch\training_epoch_loop.py", line 193, in advance                                                                                batch_output = self.batch_loop.run(batch, batch_idx)                                                                  File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\base.py", line 145, in run                         self.advance(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\batch\training_batch_loop.py", line 88, in advance                                                                                outputs = self.optimizer_loop.run(split_batch, optimizers, batch_idx)                                                 File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\base.py", line 145, in run                         self.advance(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\optimization\optimizer_loop.py", line 215, in advance                                                                                result = self._run_optimization(                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\optimization\optimizer_loop.py", line 266, in _run_optimization                                                                                self._optimizer_step(optimizer, opt_idx, batch_idx, closure)                                                          File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\optimization\optimizer_loop.py", line 378, in _optimizer_step                                                                                lightning_module.optimizer_step(                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\core\lightning.py", line 1652, in optimizer_step         optimizer.step(closure=optimizer_closure)                                                                             File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\core\optimizer.py", line 164, in step                    trainer.accelerator.optimizer_step(self._optimizer, self._optimizer_idx, closure, **kwargs)                           File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\accelerators\accelerator.py", line 336, in optimizer_step                                                                                self.precision_plugin.optimizer_step(model, optimizer, opt_idx, closure, **kwargs)                                    File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\plugins\precision\precision_plugin.py", line 163, in optimizer_step                                                                                optimizer.step(closure=closure, **kwargs)                                                                             File "D:\miniconda3\envs\ldm\lib\site-packages\torch\optim\optimizer.py", line 88, in wrapper                             return func(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\torch\autograd\grad_mode.py", line 28, in decorate_context                 return func(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\torch\optim\adamw.py", line 92, in step                                    loss = closure()                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\plugins\precision\precision_plugin.py", line 148, in _wrap_closure                                                                                closure_result = closure()                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\optimization\optimizer_loop.py", line 160, in call                                                                                self._result = self.closure(*args, **kwargs)                                                                          File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\optimization\optimizer_loop.py", line 155, in closure                                                                                self.backward_fn(step_output.closure_loss)                                                                           File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\loops\optimization\optimizer_loop.py", line 327, in backward_fn                                                                                self.trainer.accelerator.backward(loss, optimizer, opt_idx)                                                           File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\accelerators\accelerator.py", line 311, in backward      self.precision_plugin.backward(self.lightning_module, closure_loss, *args, **kwargs)                                  File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\plugins\precision\precision_plugin.py", line 91, in backward                                                                                model.backward(closure_loss, optimizer, *args, **kwargs)                                                              File "D:\miniconda3\envs\ldm\lib\site-packages\pytorch_lightning\core\lightning.py", line 1434, in backward               loss.backward(*args, **kwargs)                                                                                File "D:\miniconda3\envs\ldm\lib\site-packages\torch_tensor.py", line 307, in backward                                   torch.autograd.backward(self, gradient, retain_graph, create_graph, inputs=inputs)                                    File "D:\miniconda3\envs\ldm\lib\site-packages\torch\autograd_init.py", line 154, in backward                         Variable._execution_engine.run_backward(                                                                            RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation: [torch.cuda.FloatTensor [4, 1024, 77]], which is output 0 of AsStridedBackward0, is at version 2; expected version 1 instead. Hint: enable anomaly detection to find the operation that failed to compute its gradient, with torch.autograd.set_detect_anomaly(True).

Wrong model checkpoint used, the fix is to use the right model text2img-large/model.ckpt

Attempting to run it with https://ommer-lab.com/files/latent-diffusion/nitro/txt2img-f8-large/model.ckpt just causes a different set of errors:

RuntimeError: Error(s) in loading state_dict for LatentDiffusion:                                                               size mismatch for model.diffusion_model.input_blocks.1.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                      size mismatch for model.diffusion_model.input_blocks.1.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                      size mismatch for model.diffusion_model.input_blocks.2.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                      size mismatch for model.diffusion_model.input_blocks.2.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                      size mismatch for model.diffusion_model.input_blocks.4.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                      size mismatch for model.diffusion_model.input_blocks.4.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                      size mismatch for model.diffusion_model.input_blocks.5.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                      size mismatch for model.diffusion_model.input_blocks.5.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                      size mismatch for model.diffusion_model.input_blocks.7.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                    size mismatch for model.diffusion_model.input_blocks.7.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                    size mismatch for model.diffusion_model.input_blocks.8.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                    size mismatch for model.diffusion_model.input_blocks.8.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                    size mismatch for model.diffusion_model.middle_block.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                      size mismatch for model.diffusion_model.middle_block.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                      size mismatch for model.diffusion_model.output_blocks.3.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                   size mismatch for model.diffusion_model.output_blocks.3.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                   size mismatch for model.diffusion_model.output_blocks.4.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                   size mismatch for model.diffusion_model.output_blocks.4.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                   size mismatch for model.diffusion_model.output_blocks.5.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                   size mismatch for model.diffusion_model.output_blocks.5.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([1280, 1280]) from checkpoint, the shape in current model is torch.Size([1280, 768]).                   size mismatch for model.diffusion_model.output_blocks.6.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                     size mismatch for model.diffusion_model.output_blocks.6.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                     size mismatch for model.diffusion_model.output_blocks.7.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                     size mismatch for model.diffusion_model.output_blocks.7.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                     size mismatch for model.diffusion_model.output_blocks.8.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                     size mismatch for model.diffusion_model.output_blocks.8.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([640, 1280]) from checkpoint, the shape in current model is torch.Size([640, 768]).                     size mismatch for model.diffusion_model.output_blocks.9.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                     size mismatch for model.diffusion_model.output_blocks.9.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                     size mismatch for model.diffusion_model.output_blocks.10.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                    size mismatch for model.diffusion_model.output_blocks.10.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                    size mismatch for model.diffusion_model.output_blocks.11.1.transformer_blocks.0.attn2.to_k.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).                    size mismatch for model.diffusion_model.output_blocks.11.1.transformer_blocks.0.attn2.to_v.weight: copying a param with shape torch.Size([320, 1280]) from checkpoint, the shape in current model is torch.Size([320, 768]).

Okay so I spent the better part of the day trying to get this to work and I got it working on an Nvidia 10GB 3080 Size 448x448 images. Required a completely fresh clone of the files and a simple drop-in of Stable Diffusion 1.4. Everything else was making sure the conda environment was sane, I had to make sure to delete tensorflow as I was getting Keras errors not related to this project or its files as well.
The error above indicates user error.


Added husky precommit hook

Hello there,
I've seen the issue #331 and since it's Hacktoberfest I've decided to jump in :) I've added lint-staged and husky precommit hook, it seems to be working as intended. It "prettier-ed" the package.json file immediately.
I hope this solves your problem. Please let me know if something needs to be changed, or else.

Looks awesome! Thanks! 👍

No prob :-)


GH-41407: [C++] Use static method to fill scalar scratch space to prevent ub

Rationale for this change
In #40237, I introduced scalar scratch space filling in concrete scalar sub-class constructor, in which there is a static down-casting of this to sub-class pointer. Though this is common in CRTP, it happens in base cast constructor. And this is reported in #41407 to be UB by UBSAN's "vptr" sanitizing.
I'm not a language lawyer to tell if this is a true/false-positive. So I proposed two approaches:

The easy way: add suppression in [1], like we already did for shared_ptr. But apparently this won't be feasible if this is a true-positive (need some language lawyer's help to confirm).
The hard way: totally avoid this so-to-speak UB but may introduce more boilerplate code. This PR is the hard way.

[1] https://github.com/apache/arrow/blob/main/r/tools/ubsan.supp

What changes are included in this PR?
Make FillScratchSpace static.

Are these changes tested?
The existing UT should cover it well.

Are there any user-facing changes?
None.

GitHub Issue: #41407

@github-actions crossbow submit test-fedore-r-clang-sanitizer test-ubuntu-r-sanitizer

@github-actions crossbow submit test-fedora-r-clang-sanitizer test-ubuntu-r-sanitizer

@github-actions crossbow submit test-ubuntu-22.04-cpp-emscripten

(ignore my crossbow trigger, this PR is not going to fix that)

Comments addressed. PTAL @bkietz . And would you please help to trigger test-fedora-r-clang-sanitizer and test-ubuntu-r-sanitizer CI tasks? I want to make sure the updated change still pass them. Thank you!

@github-actions crossbow submit test-fedora-r-clang-sanitizer test-ubuntu-r-sanitizer

I've triggered the sanitizer jobs.
IIUC, I think you can trigger them on your own with a comment like the one I sent @zanmato1984 I don't believe there are restrictions on who is allowed to send that comment (and our CI here looks for the comment and then does the rest)

I've triggered the sanitizer jobs.
IIUC, I think you can trigger them on your own with a comment like the one I sent @zanmato1984 I don't believe there are restrictions on who is allowed to send that comment (and our CI here looks for the comment and then does the rest)

Wow, thank you for the tips. I'll try myself next time :)


feat: Datasets with loaders

Try to add tests to that

Note:
*change HFDataset to HuggingFaceDataset

Better export the datasets so no ".dataset" is needed


Cody stripe

Description
Implemented Stripe, styled it a bit.  Also changed over to .env files.
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[X] Hit Stripe API with success.

Checklist:

[X] My code follows the style guidelines of this project
[X]  I have performed a self-review of my own code
[X]  My code has been reviewed by at least one peer
[X]  I have commented my code, particularly in hard-to-understand areas
[X]  I have made corresponding changes to the documentation
[X] My changes generate no new warnings
[X]  I have added tests that prove my fix is effective or that my feature works
[X]  New and existing unit tests pass locally with my changes

Lol, I just called the branch that in case anyone else wanted their own Stripe branch.


fix: typo ip_adress to ip_address

It may have been intentional, but it was typo'd and has been corrected.

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


update aws_instance_types file

Codecov Report
Patch and project coverage have no change.

Comparison is base (29d355c) 72.21% compared to head (ac661ce) 72.21%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #332   +/-   ##
=======================================
  Coverage   72.21%   72.21%
=======================================
  Files          27       27
  Lines        1346     1346
=======================================
  Hits          972      972
  Misses        374      374

Flag
Coverage Δ

unittests
72.21% <ø> (ø)

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

Impacted Files
Coverage Δ

ros/lib/aws_instance_types.py
100.00% <ø> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Avoid auto compile and build TS on saving file changes for editors like VIM, Atom, etc.

When using Atom or VIM, every time a .ts file is changed it triggers auto compile and build. This causes generating .js and .js.map of the modified .ts file, which is very counter productive.

:shipit:

@sumitarora I've updated this branch and it no longer has conflicts.


[Refactor] Split up inheritance structure of TransformerEncoder and BERTEncoder

Description
Split up inheritance structure of TransformerEncoder and BERTEncoder
Checklist
Essentials

[X] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
[x] Changes are complete (i.e. I finished coding on this PR)
[X] All changes have test coverage
[x] Code is well-documented

Changes

[ ] Split up inheritance structure of TransformerEncoder and BERTEncoder

Comments

Removes BERTLayerNorm and BERTPositionwiseFFN
Changes the layer_norm_eps=None default to layer_norm_eps=1e-5 for Transformer models and layer_norm_eps=1e-12 for BERT models. The distinction was previously done by using BERTLayerNorm vs nn.LayerNorm.

cc @dmlc/gluon-nlp-team @fierceX

Job PR-988/4 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/4/index.html

Job PR-988/5 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/5/index.html

Job PR-988/6 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/6/index.html

Job PR-988/7 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/7/index.html

I saw that you removed some inheritance from the BERT code. I wonder if it is necessary to rewrite the BERT with almost the same code as Transformer. @leezu

@fierceX I think there is a trade-off between the amount of code shared and the complexity / readability of the code. I added two more parameters two the TransformerEncoderCell and dropped BERTEncoderCell now. (Thanks for starting this discussion.)
I tend towards keeping BERTEncoder and TransformerEncoder separate.
The reason is that as the number of models published increases, it's likely that many differ in small ways and the TransformerEncoder as single shared implementation could become complex and hard to understand.
However, keeping BERTEncoder, TransformerEncoder and potential others separate, may make each of the implementations easier to understand. What do you think?

I agree with you that BERT and derived models use separate code, separated from TransformerEncoder. But this is best done separately with Transformer.py. @leezu

Ok, thank you. So I suggest to merge this PR first. Potential further improvements can be done in a separate PR.

Job PR-988/11 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/11/index.html

Job PR-988/12 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/12/index.html

Job PR-988/14 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/14/index.html

Job PR-988/15 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/15/index.html

Job PR-988/17 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/17/index.html

@leezu @eric-haibin-lin @szha
I'd like to discuss it here. I've been watching TinyBERT lately.
It is mentioned that an unnormalized Attention weight matrix is used.

In this work, the (unnormalized) attention matrix Ai is used as the fitting target instead of its softmax output softmax(Ai), since our experiments show that the former setting has a faster convergence rate and better performances.

Is it necessary to add an option to the Attention function to return to normalized / unnormalized Attention weights

Job PR-988/19 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/19/index.html

@fierceX good suggestion. Since this PR is on the critical path for the EMNLP tutorial on Sunday, let's proceed on that separately.

Job PR-988/20 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/20/index.html

Job PR-988/21 is complete.
Docs are uploaded to http://gluon-nlp-staging.s3-accelerate.dualstack.amazonaws.com/PR-988/21/index.html


recordset update and delete endpoints should allow requests from members of the ownergroup

Is your feature request related to a problem? Please describe.
If a member is in the owner group of a recordset then update and delete operations should go through. The scope of this does not include the batch endpoints
Additional context
Thinking adding the owner group check to access validations. Could be in record set validations possibly. Will need to hit groups db to get members of the owner group and check if the user is in it

Is this still an issue?

This feature has been implemented, record update and delete validation methods have been updated most recently here:
https://github.com/vinyldns/vinyldns/pull/830
https://github.com/vinyldns/vinyldns/pull/904


Zero-length I2c transfers

Hi,
I am having a bit of a fight here with the I2c trait in embedded-hal 1.0.0.
Let's suppose I have an I2C EEPROM that I just sent some data for writing to. The EEPROM needs some time after the STOP condition on the I2C bus to actually write the data into the memory page. During that time, it stops ACKing its address on the I2C bus.
Now in order to poll when the chip is done writing, I thought I would be smart and perform a read transaction to its address with an empty buffer, just to see if it ACKs its address. I assumed that the code I wrote which implements the transaction trait method would put the address on the bus, wait for an ACK or NACK, either return a NACK-Error in case the chip is still busy or try to read 0 bytes followed by putting a STOP condition on the bus in case the chip is idle again.
Now comes the roadblock: I do this on an ATtiny817 and its I2C hardware state machine is relatively clever and it tries to perform as much bus stuff in hardware as it can. As it stands, I can not get it to NOT read at least one byte from the bus after a successful ACK and my code gets stuck with an occupied bus, because I never ACK or NACK that byte. I tried handling a special case when the passed slice in the Read operation has a length of 0 where I just read one byte, discard it, NACK the transfer and issue a STOP condition, but even that doesn't work for some weird reason.
Long story short, before I debug this further: Are zero-length reads or writes on an I2C bus even a thing? Does it even make sense to support this? Should we support something like this as I2c trait implementers or should we just error out early or even ignore such a transaction when we encounter it? This edge case isn't specified in the trait description so I thought I'd ask here.
Also, I think even the i2cdetect utility in i2c-utils performs actual read or write transfers of at least one byte to detect devices on an I2C bus.

Okay, so after actually understanding how that peripheral works and how to trigger certain state changes in the state machine and what transitions happen automatically as a side-effect on a read or write of certain registers, like for example the I2C data shift register or address register, I made it work.
Turns out, yes, zero-length transactions are a thing and they can be used for exactly what I wanted them to be used for.
Should still be clarified in the docs that this should be supported?

Should still be clarified in the docs that this should be supported?

Yes! Can you send a PR?


_1password: modernize; 2.29.0 -> 2.30.0

Things done
https://releases.1password.com/developers/cli/#1password-cli-2.30.0
Saw old nixpkgs-update was hung since june on an old version, modernized derivation and bumped version.

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 350504

x86_64-linux

:x: 1 package failed to build:

_1password

aarch64-linux

:x: 1 package failed to build:

_1password

x86_64-darwin

:x: 1 package failed to build:

_1password

aarch64-darwin

:x: 1 package failed to build:

_1password

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 350504

x86_64-linux

:white_check_mark: 1 package built:

_1password

aarch64-linux

:white_check_mark: 1 package built:

_1password

x86_64-darwin

:white_check_mark: 1 package built:

_1password

aarch64-darwin

:white_check_mark: 1 package built:

_1password

Packaging changes seems ok for me. I'm not a NixPkgs expert though

@Scrumplex looks like the checks have finished

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 350504

x86_64-linux

:white_check_mark: 1 package built:

_1password

Thanks for reviewing and merging this, @Scrumplex, very helpful 😃 Was this part of NixCon's Commiter Date?

Was this part of NixCon's Commiter Date?

I did this one when I was done debugging one of the Committer Date PRs for 3h ^^