GetParameterValues after each inform from CPE

FreeACS server send a GetParameterValues with "Device." or "InternetGatewayDevice." for whole unit when recieved the CPE inform.  It cause CPE become heavy to handle the query for each informs. I found that the "unitdiscovery" in quirk parapmeter, does it releted to this? Or where can I config not to get whole parameter values from the root top? Thanks.

I am in the process of redesigning the quirks administration. Right now it's a mess. You could take a peek inside the jar file for tr069 (it's a zip) and see the example there. That example can be copied into /etc/default/freeacs-tr069. But note that this will change.

Sorry for late reply. Because  I could not find the install-or-update-freeacs-ubuntu.sh mentiined in install.pdf  from current https://github.com/freeacs/ . So that I install freeacs by the files download from old.freeacs.com, is it correct?  I suppose the files are old, so that is the method from your suggestion still avaliable? Or how can I install freeacs from current source at https://github.com/freeacs?
Thanks

If deploying to same server as old stack you need to stop and disable tomcat. Or uninstall tomcat. If you have a database setup you can download .deb files from release page and install them with sudo dpkg -i *.deb. then go into each /etc/default/freeacs-[module] and make sure connection props matches your existing db. Save and close. Then restart each service with sudo systemctl restart freeacs-[module]. Replace [module] with the module name in question you are deciding to install.
If New install see instructions on wiki in this repo for a one liner install

May I know how to compile with the source of the old stack? Is it the same with "sbt" ?  How to do compile with the source checkout from old.freeacs.com? When I try the  latest release with dpkg -i *.deb checkout from github/freeacs , I suffered error  as "/var/lib/dpkg/ingo/freeacs-core.prerm systemctl not found". Not successfully to try the latest freeacs yet.

Ok. What OS you are using? I can instead create sytemv deb files in addition. Old source is way to much hassle. It has no build system and you will not get much support from on that code. I have done major changes to the codebase.
But even if you got error. I believe package is installed. Check /opt and /etc.  And you can symlink for eks /opt/freeacs-web/freeacs-web (i dont remember the exact path, since i am on train atm) to /etc/init.d/freeacs-web and then start it with /etc/init.d/freeacs-web start.
Right now the packages are prepared for systemd. If you have systemv you must have some really old Ubuntu or something completely different

I am working with Ubuntu14.04 and after dpkg -i .deb, the /opt/ exists the freeacs- folder and files but there's no  symlink to in /etc/  to /opt/freeacs-*.  And /etc/init.d/freeacs-web doesnot exist also.
What OS you suggest to use? Ubuntu16? Thanks.

ubuntu 16 or later yes. In ubuntu 16 they introduced systemd. I see that 14.04 still gets updates a little bit into 2019, but I strongly suggest to upgrade to ubuntu 16 now. In this project i needed to bump the requirements since 14.04 is so old.
You can see in link below that 16.04 will at least have updates into 2021:
https://www.ubuntu.com/info/release-end-of-life

When I use the clean Ubuntu16.04 and dpkg -i *.deb can successfully install without error and the symlink created. But I am confused by the installation doc of github/freeacs/installation.  What's the actual openjdk and mysql version should be? If I need to re-compile the source of github/freeacs/freeacs with sbt? And the actual steps to complete the installation?

dpkg -i *.deb (download from https://github.com/freeacs/freeacs/releases)
apt install mysql-server-5.7, openjdk-jre-7 and  tomcat7
how to install the freeacs and create tables that freeacs required?
how do some config as installation document mentioned? e.g xaps-tr069.properties

I am sorry for the lsck of good documentation. This is next on my list. Meanwhile take a look inside scripts/install.sh.

OK, thanks for your support. I am looking forward to our update then to try the latest FreeeACS.


3.9 beta release branching

3.9 beta branch info

Repo
Branch
Commit
g3 CL

flutter/flutter
flutter-3.9-candidate.1
https://github.com/flutter/flutter/commit/2311174e12a9b2b6723d269663ab648f42327cbe
cl/514477206

flutter/engine
flutter-3.9-candidate.1
https://github.com/flutter/engine/commit/a098c91e5e72769dfb03dcf166d1f31c6bdb57b7
N/A

dart-lang/sdk
3.0.0-290.0.dev
https://github.com/dart-lang/sdk/commit/b1016d8f293a723c83adb84e7839e7a4ad3bec22
cl/513784887

google/skia
as needed
https://github.com/google/skia/commit/04e32a9e56411e7fcdd894255323629ee6e7b103
N/A

@itsjustkevin @godofredoc @athomas @CaseyHillers

We'll also need to use https://flutter.googlesource.com/recipes/+/3d708a2aeda0b7924479e6ec7b6793b276110228 for the recipes branch point.

Recipes branch was created.

Closing as completed.


Nested question

I am trying to understand the nested routes and I have a example of what I am currently facing:
https://codesandbox.io/s/xvnrl7q5w
What I am trying to do is the following:

User clicks on Page One the routes updates and shows the content for that specific page. Check
Then the user clicks on Page One A or Page One B (The nested links) it goes to the page but page one content is still on the page. How can I get rid of that?
The error page doesn't come into affect when the url is not correct. What am I missing there?

Thanks,
Kevin

This is a bug tracker, not a support system. For usage questions, please use Stack Overflow or Reactiflux where there are a lot more people ready to help you out. Thanks!


Converting to use correct of ClientContext.createBatchWriter()

There are two createBatchWriter() methods in ClientContext.
public BatchWriter createBatchWriter(String tableName, BatchWriterConfig config)

and
public BatchWriter createBatchWriter(String tableName)

The latter just uses the former and creates a new BatchWriterConfig as its config param. This PR is to convert the cases where the simplified method can be used.
Additionally there were a few cases of createBatchDeleter that were converted for the same reason. I also moved a few cases into a try-with-resources block to make use of their autoclosable implementation.

Looks good.


New Contribution

Contributor: [zwancc]
SSH Public key: [ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINgDuY9NS4mO5DQUA0goS2VC2SclRRG3Mtva930sDSKI]
Attestation: [anythin...........]

I am ready

I am ready

I am ready


load_elf_to_flash() on esp32 hangs in FlashBegin command

esptool.py reports:
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz

I never successfully flashed my ESP32 boards with espflash /dev/ttyUSB0 image.elf, it always reports a timeout:
$ ./target/debug/espflash /dev/ttyUSB0 --board-info
Chip type: Esp32
Flash size: Flash4MB
$ ./target/debug/espflash /dev/ttyUSB0 ../esp32-hal/target/xtensa-esp32-none-elf/release/examples/serial
Error: IO error while using serial port: Operation timed out
caused by: Operation timed out

There is simply no response to begin_command(Command::FlashBegin,..) in flasher.rs:418 and it times out in connection.rs:117 in command() while waiting for a response.
I compared the behaviour with esptool.py and I think the issue is:

main() calls Flasher::connect() which calls start_connection to reset the chip and calls enable_flash()
main is now able to communicate with the flash
load_elf_to_flash() calls self.start_connection() which resets the chip and does not call enable_flash()
SPI communication with the flash is not possible (on ESP32)

I solved this for my boards both by either removing start_connection() or adding enable_flash() in load_elf_to_flash(), but I don't know if that breaks anything on esp8266 (calling enable_flash() would result in two FlashBegin Commands being issued, one in enable_flash and then one in load_elf_to_flash())

Fixed with 28af942448fc56511c38bf35e97b3d2fde48031b


reproduce leading whitespaces of prev line when adding new list items

in lists with more than one whitespace between list marker "add new list items" will inconveniently create list items with only one space. example, where _ marks cursor position after creating new item:
-   item1
-   item2
- _

this pr adds whitespaces in new item like so:
-   item1
-   item2
-   _

this may also fix #238

Thanks for the PR. Looks good.
Could you have a look whether it's reasonable to add some tests for this feature? The code that adds the new list items is currently implemented as an anonymous function in the activate method, and I intend to refactor this at some point. The tests would help a lot in preventing regressions, and for catching edge cases.

and here are the tests.
have fun :-)

Kudos for you! Will have a look soon


TypeError: this._positionInPanelComboBox is null

The settings of extension<EMAIL_ADDRESS>had an error:
TypeError: this._positionInPanelComboBox is null

Stack trace:
_updateGeneral@/home/pacs/.local/share/gnome-shell/extensions/hue-lights@chlumskyvaclav.gmail.com/prefs.js:1758:9
_init@/home/pacs/.local/share/gnome-shell/extensions/hue-lights@chlumskyvaclav.gmail.com/prefs.js:1126:14
buildPrefsWidget@/home/pacs/.local/share/gnome-shell/extensions/hue-lights@chlumskyvaclav.gmail.com/prefs.js:1944:12
_init@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:207:40
OpenExtensionPrefsAsync/<@resource:///org/gnome/Shell/Extensions/js/extensionsService.js:122:28
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:132:13
run@resource:///org/gnome/Shell/Extensions/js/dbusService.js:175:20
main@resource:///org/gnome/Shell/Extensions/js/main.js:19:13
run@resource:///org/gnome/gjs/modules/script/package.js:222:19
start@resource:///org/gnome/gjs/modules/script/package.js:206:5
@/usr/share/gnome-shell/org.gnome.Shell.Extensions:1:17

Hi @moxo26 thank you for reporting. this._positionInPanelComboBox should be autogenerated by the GTK builder. Could you please share what version of gnome you use? Also, what is your Linux distribution?

My GNOME version is 3.36.8
My linux distribution is Ubuntu 20.04.5 LTS

I am sorry but as you can read in #58 the support for gnome < 40 was dropped. The last version of this extension supporting your system is 24. You can either check out tag 24 on the main branch or download it here https://extensions.gnome.org/extension/3737/hue-lights/ There will be no more new versions for old gnome versions.


Please invite me to the Recode-Hive GitHub Community Organization

Name
Vysavya
Discord Username (if applicable)
No response
Additional Context
No response

Invitation sent to join the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see. You can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/recodehive/people


Doesn't work

Hi, I configured the bot properly and after creating the game it says "fetching map data...." and then koolo shuts down. No other logs...

It might be related to this https://github.com/hectorgimenez/koolo/issues/11#issuecomment-1637122780

Hi, yes it's the same error, but I have the path properly confiugred:
D2LoDPath: 'C:/Program Files (x86)/Diablo II Resurrected' (the slash is a backslash)
I unistalled the game and re-installed again and keeps giving the same error.

You need to target to the old game, the Diablo II: LOD 1.13c. Not the Resurrected version. The map tool is using old game data to fetch the map information.

HI, there is no D2 LOD foler. Only the resurrected one.

Yes, you need to get a copy of LoD 1.13c and install it


Replace default Variable Font Names with a space

Currently, variable fonts generate their own individual font-family name as something such as RobotoVariable or Open SansVariable.
The lack of a space in between is a huge oversight and I can understand why it can be somewhat confusing. The newly generated names, for example, would be Roboto Variable or Open Sans Variable.

FYI; this already works that way (space between name and suffix) in the proposal.

FYI; this already works that way (space between name and suffix) in the proposal.

Only for Sass. This is a project-wide change.

Based on how huge the browser support for variable fonts is, I would like it even more if the variable fonts just use the same name as the non variable fonts.
We already make the decision on what kind of font we use, by importing the variable.css file.. But also having to replace all the font-family: some-font with font-family: some-fontVariable is unnecessary work :(

@LasseRosenow, I'm not very opposed to that actually.
However, the original reason why the additional suffix was included was to help differentiate the font files to fit this recommendation from MDN.
Google Fonts doesn't need to differentiate its font name since it will serve the compatible font based on the user agent.

@DecliningLotus
Okay then what about using this @supports stuff inside the default import. like when you just import import "@fontsource/open-sans" it could be somwhat like this

@supports (font-variation-settings: 'wdth' 115) {
  @font-face {
    font-family: "open-sans";
    src: url(open-sans-variable.woff2);
  }
}

@supports not (font-variation-settings: 'wdth' 115) {
  @font-face {
    font-family: "open-sans";
    src: url(open-sans-400.woff2);
  }
}

This way we could use the default import, which is nice and we would get variable fonts for modern browsers and non variable fonts for older browsers.
And if we want to force what we want to have, we can still import the variable font via variable.css etc.

It sounds like a reasonable idea, although I feel fairly uneasy to make it a default setting since I'm unsure how it will affect the tens of thousands of projects downstream in niche unexpected ways. That's why it's always been an "opt-in" solution for developers, rather than "opt-out".
I think there will be a time where variable fonts becoming a default option happens, but I'd rather wait for Google Fonts to become more aggressive with that idea themselves before following suit.
Generating these automatically in #234 behind a flag is also something very doable.

It sounds like a reasonable idea, although I feel fairly uneasy to make it a default setting since I'm unsure how it will affect the tens of thousands of projects downstream in niche unexpected ways. That's why it's always been an "opt-in" solution for developers, rather than "opt-out".

I mean it would be a breaking change of course, but we could increase the major version number of all packages, this way none of those thousands projects would be affected

I think there will be a time where variable fonts becoming a default option happens, but I'd rather wait for Google Fonts to become more aggressive with that idea themselves before following suit.

I'm not sure what you mean with "Google Fonts to become more aggressive" I think they are somewhat too aggressive as they just updated hundreds of fonts to variable fonts without asking anyone and shipping them by default. Right now you always get variable fonts if the font you are using has a variable version and your system is not opted out for some reasons like I think Firefox on Windows right now, even though they are reevaluating this right now I think ^^
So what I mean is, what is your idea on how Google could be pushing variable fonts more aggressively?
#234 sounds very interesting btw.!! :)

I actually agree with your points now that you mention those details. But now I recall why this is a very messy problem.
We actually did previously serve VFs as a default import (unintentionally), which was discovered when one user experienced an issue discussed in #142. Google Fonts does serve VFs by default which got passed on. I "fixed" that since users were importing duplicate font files as a result of that unintended behaviour described in #142 (comment).
We could make a breaking change and make VFs a default import stating you only need to make one import to access all weights. But then what about non-VFs? The last thing I want to do is have two sets of default installation instructions across the entire project since that'll cause confusion. I'd rather have one default installation method, with opt-in variations rather than two defaults that differ per package. Sure it's not hard to make differing packages distinguishable... but I can guarantee people will get confused regardless.
It's possible to merge all weights into one CSS file for non-VFs to make the installation method uniform repo-wide. But I've shot that down multiple times due to CSS file size concerns. e.g. #289 (comment) I didn't mention it in that comment, but even for simpler fonts like Roboto (assuming it was non-VF), they'd still have unnecessarily large CSS files due to them having 6 different weights for 7 different subsets. Let's not also forget that VFs will have to include these large blocks of code regardless if we were to include the @supports fallback.
#234 is something that could account for all these edge cases. Perhaps it would make sense to prioritise that issue...

Based on how huge the browser support for variable fonts is, I would like it even more if the variable fonts just use the same name as the non variable fonts.

Since we’re moving regular and variable fonts into separate packages (#589), I think all my previous concerns for your proposals are resolved. I’m happy to name each font the same!

In the end, I went back to using different names as we needed a reliable way to write fallbacks. Released in v5 🎉

Could there be an alternative css file that doesn't have the "Variable" suffix?
We're currently developing a rich text editor that supports fonts. By copying the content, HTML containing the "font-family: Some Font Variable" can be pasted elsewhere and this may not be cross-editor compatible - because other editors are more likely to support "Some Font" since it's the universal name, but not "Some Font Variable".

Could there be an alternative css file that doesn't have the "Variable" suffix?

We can't generate more CSS files and pack it into the package. That would end up cluttering package directories even more.
Instead, you can rewrite the @font-face files yourself e.g.
@font-face {
  font-family: 'Abel';
  font-style: normal;
  font-display: optional;
  font-weight: 400;
  src<EMAIL_ADDRESS>format('woff2'<EMAIL_ADDRESS>format('woff');
}

Or the prefix may be<EMAIL_ADDRESS>or ~@fontsource. I don't recall exactly what works, but I've seen it in the wild before so you may need to experiment a little.
However, for an RTE that supports many fonts, I wouldn't suggest self-hosting the fonts since your end package will have to bundle them in. You might be better off rewriting the src with a CDN link such as using Google Fonts or https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>if you would prefer an alternative CDN.

Will give that a try. Thanks!
As for the bundling part, it's fine as we're using vite that emits woff2 files to dist/assets which would eventually be served by cloudflare. We also use CSS Font Loading api to eager-load based on fonts used in content.


Basic implementation of storage

Codecov Report

Merging #108 (716dbcf) into main (95382c9) will increase coverage by 0.36%.
The diff coverage is 76.38%.

@@            Coverage Diff             @@
##             main     #108      +/-   ##
==========================================
+ Coverage   85.00%   85.36%   +0.36%
==========================================
  Files          80       80
  Lines       13551    13894     +343
==========================================
+ Hits        11519    11861     +342
- Misses       2032     2033       +1

Impacted Files
Coverage Δ

xngin-common/src/sma.rs
9.43% <0.00%> (-1.93%)
:arrow_down:

xngin-storage/src/error.rs
0.00% <0.00%> (ø)

xngin-common/src/bitmap.rs
72.42% <50.00%> (+0.03%)
:arrow_up:

xngin-storage/src/attr.rs
75.92% <72.99%> (+14.63%)
:arrow_up:

xngin-storage/src/codec/mod.rs
83.33% <75.00%> (-2.39%)
:arrow_down:

xngin-datatype/src/lib.rs
75.10% <94.11%> (+1.48%)
:arrow_up:

xngin-storage/src/block.rs
92.50% <96.19%> (+85.18%)
:arrow_up:

xngin-common/src/alloc.rs
92.42% <100.00%> (+3.03%)
:arrow_up:

xngin-common/src/array.rs
80.00% <100.00%> (+0.91%)
:arrow_up:

xngin-compute/src/eval.rs
97.02% <100.00%> (ø)

... and 11 more

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 95382c9...716dbcf. Read the comment docs.


Persisting an iterable of headers or beacon blocks fails

py-evm Version: current master

What is wrong?
HeaderDB.persist_header_chain iterates twice over the headers which fails if they are given in the form of an iterator.
First loop: https://github.com/ethereum/py-evm/blob/master/eth/db/header.py#L219-L227
Second loop: https://github.com/ethereum/py-evm/blob/master/eth/db/header.py#L240-L251
It also extracts the first element: https://github.com/ethereum/py-evm/blob/master/eth/db/header.py#L214
The same is bug is present in eth.beacon.db.chain._persist_block_chain where I originally encountered it.
How can it be fixed
I can see three simple fixes:

Handle everything in a single loop
Convert the iterable to a tuple in the beginning
Change the type hint to only accept sequences

Restricting that to Sequence[BlockHeader] to me feels like the best choice here.

Well, if we can handle everything in a single loop without sacrificing readability than maybe that would be the best choice as it would also be a slight performance improvement but I haven't given that much thought. I'm not a fan of converting it to a tuple in the beginning because then we are effectively looping over the data three times (converting to tuple + two existing loops)

My preference:

look into handling things in a single loop.  If can be cleanly done, do the change and  add a test that uses a generator and ensure that it works as expected
if single loop isn't viable for whatever reason, use Sequence approach.


Fails to connect or open

the extension seems to be installed correctly. it's up to date, the files and json are set up properly, but it's not working. running Linux Mint and trying to flash my flipper zero on Flipper Lab. it's not opening the extension when i click connect.
i'm unsure how to further debug but any help would be greatly appreciated

additionally here's the logs. attempted to connect twice and got those. on first click the extension seemed to respond and had me select the proper serial port, but now it's not working

This seems to be an issue with the website. Because of the way WebSerial needs to inject its JavaScript code (in <head> before anything else starts) it can't always be the first to run on the website.
This website seems to be using a Service Worker. It is a separate script running in an isolated environment. This is not yet supported in this addon.

damn, alright. if there's any way i can contribute, please lemme know. i'm still learning to code but i'd love to help any way i can.


i18n(es) update configuration-reference.mdx

Description (required)
Update configuration-reference.mdx file.
Hope this update fix the error on this PR
Greetings!

Related issues & labels (optional)

Closes #8742
Suggested label: docs-i18n

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

es
reference/configuration-reference.mdx
Localization changed, will be marked as complete.

es
reference/errors/rewrite-encountered-an-error.mdx
Localization added, will be marked as complete.

es
reference/errors/rewrite-with-body-used.mdx
Localization added, will be marked as complete.

es
reference/errors/server-only-module.mdx
Localization added, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Muchas gracias @dreyfus92 por la revisión de la PR!
Es la primera vez que hago una PR de esta forma y se me han escapado esos archivos, no me había dado cuenta!
Ahora mismo lo modifico y lo subo 😄.
Una vez más, muchas gracias por el apoyo y la revisión, lo agradezco mucho ❤!
LGTM💯!


Fix: add utility to check whether a string is a filepath

I didn't follow the isint / isstr convention: I think we should rename those in a subsequent PR

This might fix #1084

There's an ak._util.iswin to check to see if you're on Windows and we know that the bikeroutes JSON is too long to be a Windows path. Such a test would require an HTTP connection, which should probably skip if the attempt to download with
import urllib.request

url = "https://raw.githubusercontent.com/Chicago/osd-bike-routes/master/data/Bikeroutes.geojson"
bikeroutes_json = urllib.request.urlopen(url).read()

fails.

Let's use that instead — it's a more direct test.

I didn't merge this because (as I understand it), it's waiting for a test. If I should add it to 1.5.0, let me know. Otherwise, there will probably be only one release candidate before the final release (but technically two "rc" releases in GitHub because it looks like the first one didn't trigger).

Nope; that's because Azure isn't configured to deploy anymore—it's handled by GitHub Actions now, and I had forgotten.

Oh, I was thinking that this could just be a test that attempts to download through HTTP, and skips if it fails. I don't think it would be the only test that requires network access.
That way, we don't need to add a copyright message for Chicago's data. We're really just wanting it for its size (which could also be an auto-generated JSON, if we really want to avoid network access).

I've added a test, but I can't test the previous behaviour against this test unless I poke around with the CI. Do you happen to have a Windows machine to hand?

I've added a test, but I can't test the previous behaviour against this test unless I poke around with the CI. Do you happen to have a Windows machine to hand?

Oh, I was thinking that this could just be a test that attempts to download through HTTP, and skips if it fails. I don't think it would be the only test that requires network access.
That way, we don't need to add a copyright message for Chicago's data. We're really just wanting it for its size (which could also be an auto-generated JSON, if we really want to avoid network access).

Right, I forgot to motivate why I downloaded a sample; the data are quite large. It's not a slow download, but it's enough that I don't think we want to add it to the test suite unless required. Are you not comfortable with including the license file? It's not infectious, and it's only in the test suite.

Do you happen to have a Windows machine to hand?

The CI is our only access (both of us).

Right, I forgot to motivate why I downloaded a sample; the data are quite large. It's not a slow download, but it's enough that I don't think we want to add it to the test suite unless required.

I considered it small enough to use in a classroom setting, and the downloads in CI are a lot faster than they are at home. (The CI machines are well-connected!) I just downloaded it in 0.3 seconds at home.
Generating simple JSON that is as large as the bikeroutes file would be sufficient. The bikeroutes sample is 2.3 MB, and a list of numbers up to 1 million is 7.8 MB:
json.dumps(np.arange(1000000).tolist())

Generating it and interpreting it as an Awkward Array takes 0.2 seconds:
ak.Array(json.dumps(np.arange(1000000).tolist()))

Without your fix, the above line should fail in Windows (CI).

If we want to test the Windows case, then we only need 260 chars of JSON, although I can see the merit in re-using a "large" dataset. I will update with your suggestions.

Oh yeah, and although the license is not infectious, simplifying things to the extent that no one has to evaluate whether that is the case is beneficial. I have a bias against including anything that requires a license, which can be overcome by a good enough reason: Lark has a good enough reason, as does pybind11, as well as RapidJSON... I just want to keep the list short, and this one test is doable without having to add the dataset.

260 chars of JSON

I didn't know the threshold, but I did know that the bikeroutes exceeded it. That's the thinking behind the 7 MB of JSON.

Oh, I ignored py2 here because I was thinking about v2. However, it makes sense to merge this now - thanks for backporting it


Bonfire: Where do I belong? Second example in instructions is incorrect.

Challenge Bonfire: Where do I belong has an issue.
User Agent is: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.
In the instructions for this exercise the second example reads, "Likewise, where([20,3,5], 19) should return 2 because it is less than 20 (index 2) and greater than 5 (index 1)." Based on the example result given, the example array should be [3,5,20].

After completing this exercise, I realized that the second example may not be a typo as the exercise requires the use of the sort() method to sort the given arrays in a numerically ascending order. So, rather than a typo, this example may just be confusing to those who have not completed the exercise.

It might make sense to add a clarifying statement like:

Likewise, where([20,3,5], 19) should return 2 because (once the array has been sorted) it is less than 20 (index 2) and greater than 5 (index 1).


BUG: u.startsWith is not a function

➜ npx nolyfill install
Found 58 redundant packages:
 array-buffer-byte-length 1.0.1
 array-includes 3.1.8
 array.prototype.flat 1.3.2
 array.prototype.flatmap 1.3.2
 arraybuffer.prototype.slice 1.0.3
 assert 2.1.0
 available-typed-arrays 1.0.7
 deep-equal 2.2.3
 define-properties 1.2.1
 es-set-tostringtag 2.0.3
 function-bind 1.1.2
 function.prototype.name 1.1.6
 get-symbol-description 1.0.2
 globalthis 1.0.4
 gopd 1.0.1
 has-property-descriptors 1.0.2
 has-proto 1.0.3
 has-symbols 1.0.3
 hasown 2.0.2
 internal-slot 1.0.7
 is-arguments 1.1.1
 is-array-buffer 3.0.4
 is-core-module 2.14.0
 is-date-object 1.0.5
 is-generator-function 1.0.10
 is-regex 1.1.4
 is-shared-array-buffer 1.0.3
 is-string 1.0.7
 is-symbol 1.0.4
 is-typed-array 1.1.13
 is-weakref 1.0.2
 isarray 0.0.1
 object-keys 1.1.1
 object.assign 4.1.5
 object.entries 1.1.8
 object.fromentries 2.0.8
 object.getownpropertydescriptors 2.1.8
 object.values 1.2.0
 promise.allsettled 1.0.7
 regexp.prototype.flags 1.5.2
 safe-array-concat 1.1.2
 safe-regex-test 1.0.3
 set-function-length 1.2.2
 side-channel 1.0.6
 string.prototype.codepointat 0.2.1
 string.prototype.matchall 4.0.11
 string.prototype.padend 3.1.6
 string.prototype.padstart 3.1.6
 string.prototype.trim 1.2.9
 string.prototype.trimend 1.0.8
 string.prototype.trimstart 1.0.8
 typed-array-buffer 1.0.2
 typed-array-byte-length 1.0.1
 typed-array-byte-offset 1.0.2
 typed-array-length 1.0.6
 typedarray 0.0.6
 unbox-primitive 1.0.2
 which-typed-array 1.1.15

u.startsWith is not a function

I got this error? doesn't explain anything else :/

Can you share your local env?

@nonzzz what would you like to see specifically? What local environment?

Like Nodejs version and which package manager and etc.

Same issue here:
Node v20.13.1
Npm 10.8.1
Found 19 redundant packages:
 array-includes 3.1.8
 array.prototype.findlastindex 1.2.5
 array.prototype.flat 1.3.2
 array.prototype.flatmap 1.3.2
 deep-equal 1.1.2
 function-bind 1.1.2
 gopd 1.0.1
 has-proto 1.0.3
 has-symbols 1.0.3
 hasown 2.0.2
 is-core-module 2.13.1
 isarray 1.0.0
 object.fromentries 2.0.8
 object.groupby 1.0.3
 object.values 1.2.0
 set-function-length 1.2.2
 side-channel 1.0.6
 typedarray.prototype.slice 1.0.3
 which-typed-array 1.1.15

Trace: TypeError: u.startsWith is not a function
    at <local path>npm-cache\_npx\11dfa4defc9aa6e3\node_modules\nolyfill\dist\package-manager-B5oEznic.js:90:95
    at Array.reduce (<anonymous>)
    at transformOldOverrides (<local path>npm-cache\_npx\11dfa4defc9aa6e3\node_modules\nolyfill\dist\package-manager-B5oEznic.js:90:74)
    at Object.overridesPackageJson (<local path>npm-cache\_npx\11dfa4defc9aa6e3\node_modules\nolyfill\dist\package-manager-B5oEznic.js:90:668)
    at async t.<anonymous> (<local path>npm-cache\_npx\11dfa4defc9aa6e3\node_modules\nolyfill\dist\cli.js:28:156)
    at async t.parseAsync (<local path>npm-cache\_npx\11dfa4defc9aa6e3\node_modules\nolyfill\dist\cli.js:6:4119)
    at async <local path>npm-cache\_npx\11dfa4defc9aa6e3\node_modules\nolyfill\dist\cli.js:28:225
    at <local path>npm-cache\_npx\11dfa4defc9aa6e3\node_modules\nolyfill\dist\cli.js:28:292

Ok, let me check what's happened.

Does your package.json already have an overrides field defined? I just tried running it on a project and also got the u.startsWith error (running the latest Node LTS), but after cutting my overrides field out, the nolyfill install worked correctly.

Does your package.json already have an overrides field defined? I just tried running it on a project and also got the u.startsWith error (running the latest Node LTS), but after cutting my overrides field out, the nolyfill install worked correctly.

Ah yes, indeed, if I remove the overrides, it works. So it seems it has trouble merging them?

Fixed in master branch.

Fixed in master branch.

Yeah. It was fixed by #64 and #65 by @NamesMT. I am closing the issue now.


[Feature] Enable HttpClientModule

Angular introduced the HttpClientModule (https://github.com/angular/angular/commit/37797e2). It is recommended to slowly migrate from HttpModule to this new API.
Would it be possible to extend the localize-router so it supports either of the modules?

Hi @Chuvisco88,
It is already supported by extending the LocalizeParser. The plan is to completely extract ngx-translate and HttpModule from parser and have them as optional plugins/loaders to localize-router.
Stay tuned for these changes.

This will be closed with next version of localize-router-http-loader. At the moment localize-router no longer depends on HttpModule


sunlight

My POV doesn't change for my chosen player, and it doesn't work. It says I'm controlling the player, but nothing happens, and all this happened after I installed Sunlight and Vulcan anti-cheat

only shifting works i found out

I tried to recreate this bug as you stated with the two following plugins on my spigot 1.20.1 server.
Sunlight: https://www.spigotmc.org/resources/sunlight-best-essentials-cmi-alternative.67733/
and Vulcan: https://www.spigotmc.org/resources/vulcan-anti-cheat-advanced-cheat-detection-1-7-1-20-4.83626/
And it seems to work on my server just fine. Are there any console errors or are you using a server-jar I'm not aware of that might cause this error?
Here's the video of the test:
https://www.youtube.com/watch?v=Dx2vJX8TOvA
I'm afraid that this is all I can do for you so far. I can only tell you what might cause this error:
My plugins works by teleporting the player each time and it seems that another plugin on your server might cancel that teleportation-process which leads to that bug. I can also be caused by your server-jar for some kind of "performance-regulation". But i can not tell for certain.
Please let me know if you have any further information about this bug.

well these are all the plugins I use

Why using GrimAC and Vulcan at the same time? Both of AntiCheats.
Btw what Server-Jar/Spigot are u using and please tell me since what plugin exactly you have installed, CP isn't working anymore. Is it since you've installed Vulcan, or Sunlight?

I heard that Grimac and Vulcan are a good combo. That's why I'm using them

Are there any console errors?

let me check real quick

Umm, it's working for me, but when I tried using it on another player, it didn't work.

Can you make a video how it looks like and send it to me?

I can't. I don't have any online rn

Now it started working on the players, too???
Fantastic plugin, btw :D

Weird that it is working now but atleast it does ^^
Would you say this issue is solved?

For now, it is
thank you for your quick help :D

If that's the case. ^^
Feel free to open a new ticket if the same problem happens more frequently than before. That way it's easier to find out what causes it.
If you like, it would help me alot if you could share your experience with my plugin by leaving a review on the spigot ressource page of ControlPlayer. ^^

sure thing

Much appreciated ^^


FVTT Version 10 Build 284 Compatibility

Upon loading FVTT with Moulinette-Core enabled, the following exception is thrown.
[Detected 1 package: moulinette-core]
    at new MoulinetteLayer (moulinette-layer.js:7:17)
    at #createLayers (foundry.js:28388:38)
    at new BaseCanvasMixin (foundry.js:28362:39)
    at new PrimaryCanvasGroup (foundry.js:38810:5)
    at #createGroups (foundry.js:23236:21)
    at #createGroups (foundry.js:23240:25)
    at #createGroups (foundry.js:23240:25)
    at Canvas.initialize (foundry.js:23064:23)
    at Game.initializeCanvas (foundry.js:7908:19)
    at async Game.setupGame (foundry.js:7747:5)
    at async Game._initializeGameView (foundry.js:8820:5)
    at async Game.initialize (foundry.js:7630:5)```

Thank you for reporting it.
I'm planning to release v10 compatible version this week-end (September 3-4)

Moulinette modules are now officially supported for FoundryVTT v10.
I also updated the versioning to match FVTT. New versions are now 10.0.0.
Be careful when upgrading. I tested as much as I could but I probably missed some edge use cases. Feel free to report the issues on : https://github.com/SvenWerlen/moulinette-core/issues


A problem with typescript version 4

Hi,
objection.js is a great tool.
I am using latest version of knex and typescript, so want to use objection@next but it is throwing error:
           throw e;
                ^
RangeError: Maximum call stack size exceeded
    at compareSignaturesRelated (\node_modules\typescript\lib\tsc.js:50982:27)
    at signatureRelatedTo (\node_modules\typescript\lib\tsc.js:52833:24)
    at signaturesRelatedTo (\node_modules\typescript\lib\tsc.js:52776:39)
    at structuredTypeRelatedToWorker (\node_modules\typescript\lib\tsc.js:52309:39)
    at structuredTypeRelatedTo (\node_modules\typescript\lib\tsc.js:51954:30)
    at recursiveTypeRelatedTo (\node_modules\typescript\lib\tsc.js:51930:53)
    at isRelatedTo (\node_modules\typescript\lib\tsc.js:51527:34)
    at isPropertySymbolTypeRelated (\node_modules\typescript\lib\tsc.js:52488:24)
    at propertyRelatedTo (\node_modules\typescript\lib\tsc.js:52520:31)
    at propertiesRelatedTo (\node_modules\typescript\lib\tsc.js:52708:43)

package.json:
        "objection": "^3.0.0-alpha.5",
        "typescript": "^4.4.4"

Which version of objection.js and typescript should I use?

Objection v3 is still alpha version meaning that it is still not complete, you can use version 2.2.15 which is stable and I use typescript version 4.3.5

Objection v3 is still alpha version meaning that it is still not complete, you can use version 2.2.15 which is stable and I use typescript version 4.3.5

It still does not work, it throws error:
node_modules/objection/typings/objection/index.d.ts:1839:12 - error TS2709: Cannot use namespace 'Knex' as a type.

1839     (knex: Knex, modelClasses: AnyModelConstructor[]): Promise<void>;
                ~~~~

I fixed by adding skipLibCheck in tsconfig.json but it is not a good solution:
// tsconfig.js
	"compilerOptions": {
		"skipLibCheck": true
         }

@vh-dao Please check upgrading guide for Knex, I think you are using latest version in a wring way.

Can you try objection next, knex 0.95, ts 4.4 and share code which is throwing an error?

I'm having this issue with circular dependencies in relationMappings. Because I am using ESM the require loop solution does not work.
import { Model } from 'objection'
import { AuthenticationMethod } from './AuthenticationMethod';

export class Account extends Model {
  id: string
  email: string

  static get tableName() {
    return 'accounts';
  }

  static relationMappings() {
    return {
      authenticationMethods: {
        relation: Model.HasManyRelation,
        modelClass: AuthenticationMethod,
        join: {
          from: 'accounts.id',
          to: 'authentication_methods.account_id'
        }
      }
    }
  }
}

import { Model}  from 'objection'
import { Account}  from './Account'

export class AuthenticationMethod extends Model {
  static get tableName() {
    return 'authentication_methods'
  }

  static get relationMappings() {
    return {
      account: {
        relation: Model.BelongsToOneRelation,
        modelClass: Account,
        join: {
          from: 'authentication_methods.account_id',
          to: 'accounts.id'
        }
      }
    }
  }
}

➜  dev-server git:(master) ✗ tsc
/usr/lib/node_modules/typescript/lib/tsc.js:92656
                throw e;
                ^

RangeError: Maximum call stack size exceeded
    at String.replace (<anonymous>)
    at /usr/lib/node_modules/typescript/lib/tsc.js:51887:90
    at Array.map (<anonymous>)
    at recursiveTypeRelatedTo (/usr/lib/node_modules/typescript/lib/tsc.js:51887:62)
    at isRelatedTo (/usr/lib/node_modules/typescript/lib/tsc.js:51527:34)
    at typeArgumentsRelatedTo (/usr/lib/node_modules/typescript/lib/tsc.js:51834:39)
    at relateVariances (/usr/lib/node_modules/typescript/lib/tsc.js:52341:34)
    at structuredTypeRelatedToWorker (/usr/lib/node_modules/typescript/lib/tsc.js:52289:46)
    at structuredTypeRelatedTo (/usr/lib/node_modules/typescript/lib/tsc.js:51954:30)
    at recursiveTypeRelatedTo (/usr/lib/node_modules/typescript/lib/tsc.js:51930:53)
➜  dev-server git:(master) ✗ tsc -v
Version 4.4.4

  "dependencies": {
    "knex": "^0.95.12",
    "objection": "^3.0.0-rc.2"
  },

Can you try objection next, knex 0.95, ts 4.4 and share code which is throwing an error?

The error I reported are object@next and typescript v4.4
package.json:
        "objection": "^3.0.0-alpha.5",
        "typescript": "^4.4.4"

I can't reproduce this. I really need a working reproduction or there's nothing I can do.

Reproduction:
https://github.com/stefanvanherwijnen/objection-repro-2132

You are not running typescript in strict mode. Add strict: true to tsconfig.

I'm running into this issue with the released version of 3.0.0
@koskimas are you saying that objection 3 requires strict: true to work properly with typescript? Is that documented anywhere? It seems like a pretty significant limitation.

I don't think strict is required, but it will point out any errors in your model files. In my case the solution was to properly define the properties with the ! operator, e.g. id!: string

strict:true seems a bit severe. I was pulling my hair out trying to figure out why I has having issues with Nest and objection... https://stackoverflow.com/questions/70024609/injecting-objectionjs-model-using-nestjs-throws-exception/70025348#70025348

@stefanvanherwijnen is it documented anywhere that strict: true must be specified in the tsconfig? I'm not currently using strict mode with versions prior to V3 and didn't have any issues.

No I don't think so. But in my case without strict: true I get the error which this issue is about, with it I don't. It might be introduced in V3 but I think @koskimas should clear this up or document it.

This issue should be reopened. The culprit is this typing:
type PartialModelGraph<M, T = M & GraphParameters> = {
  [K in NonFunctionPropertyNames<T>]?: Defined<T[K]> extends Model
    ? PartialModelGraph<Defined<T[K]>>
    : Defined<T[K]> extends Array<infer I>
    ? I extends Model
      ? PartialModelGraph<I>[]
      : Expression<T[K]>
    : Expression<T[K]>;
};

when I change this type to any the project compiles fine. But I couldn't figure out which code line triggers it yet.
INFO:
node: 16.13.0
knex: 0.95.14
objection: 3.0.0
typescript: 4.5.4

@koskimas I think the issue is caused by NonFunctionPropertyNames including QueryBuilderType. It goes away by excluding QueryBuilderType in PartialModelObject and PartialModelGraph:
 type PartialModelGraph<M, T = M & GraphParameters> = {
    [K in Exclude<NonFunctionPropertyNames<T>, 'QueryBuilderType'>]?: Defined<T[K]> extends Model
      ? PartialModelGraph<Defined<T[K]>>
      : Defined<T[K]> extends Array<infer I>
      ? I extends Model
        ? PartialModelGraph<I>[]
        : Expression<T[K]>
      : Expression<T[K]>;
  };

Thank you @Linksku! Great work! I'll try this soon and release a new version if it works!

@Linksku may have found the fix here. Their fix is implemented in 3.0.1. Please try it out and report if it fixes all your issues.

That fix is now implemented in 3.0.1. Please try it out and report back to me if the issue is gone

That fix is now implemented in 3.0.1. Please try it out and report back to me if the issue is gone

Thanks! I still need T extends any to avoid Maximum call stack size exceeded. Maybe my types are just weird and it works for other people without that

Hmm... That's weird. Could you create a reproduction for me? For some reason I'm unable to reproduce any of these typescript problems. Probably due to my tsconfig being different.

Hi! Same as @Linksku, I also need to wrap the declaration of PartialModelGraph with T extends any ? ... : never. If I don't do this, the types of "nested" models in a model graph are not inferred by TypeScript. However, I am not facing a Maximum call stack size exceeded error when compiling my project if I don't apply this fix.
@koskimas: Cloud you release a new version with the T extends any ? ... : never fix? I would be very grateful! :-)
FYI: It does not matter if I set strict: true or strict: false in my tsconfig.json file - in both cases, I still need the T extends any ? ... : never fix.
Package versions:
typescript: 4.5.4
objection: 3.0.1
knex: 0.95.15

I was getting the same maximum stack error with typescript 4.5.5, no direct errors were showing until i reduced the project to one model i'm getting
permission.model.ts:6:22 - error TS2321: Excessive stack depth comparing types 'UpsertGraphMethod<?>' and 'UpsertGraphMethod<?>'.

i also can no longer chain .throwIfNotFound() and manually have to check:
await Activity
        .query(trx)
        .findById(req.params.id)
        // .throwIfNotFound({message: 'Activity not found.'})  no longer works
        .then(async (activity: Activity | undefined) => {

            if (!activity)
              throw new NotFoundError({message: 'Activity not found.'})

Hi, I have the same issue.  Also fixed with the T extends any ? ... : never fix.  Please can you release a new version with this included?

Hey,
Can we please implement the fix from @Linksku ? It works for me and stops all my projects breaking...

I managed to reproduce the endless recursion on v3.0.2 on the test-case provided by @stefanvanherwijnen here. I can confirm that the fix from @Linksku as summarized here does indeed fix it.
I am going to add this fix.


Suppress --list-undoc warning

If I create my documentation I get a warning that a given method is undocumented and there seems
to be no way to actually document it.
I have created a small dummy class that show the problem:
# Dummy comment
class Example

  # Create new instance of Example
  def initialize
  end

  class << self
     private :new

     # Return global instance
     def instance
       @@instance ||= new
     end
  end
end

The output I get from the command yard --protected --list-undoc --private is:
[warn]: Unrecognized/invalid option: --list-undoc
Files:           2
Modules:         0 (    0 undocumented)
Classes:         1 (    0 undocumented)
Constants:       0 (    0 undocumented)
Methods:         3 (    1 undocumented)
 75.00% documented

Undocumented Objects:
Example.new

For clarity my question is not about the warning (which I also don't understand) but on how to get rid of the undocumented Object. The message is caused by the line that states private :new. If I add a comment to the line it does not resolve the issue.
Is this a bug or am I missing something?
Regards,
Fred

It looks like private :foo is creating an instance of the method object in the YARD registry, thereby making it "exist" in YARD. This should probably not happen. I would accept a pull request to fix this.
That said, there are ways to document this, and there are workarounds to avoid the problem. The easiest is just to use Ruby's Singleton module-- Ruby already provides the above functionality out of the box:
require 'singleton'

class Foo
  include Singleton
end

The next workaround, albeit more awkward, would be to undef :new instead of marking it private and use a combination of allocate and initialize instead. Given that your initializer does nothing, you just need allocate. Yes, it's more awkward, but it would work until the above PR was submitted. Of course, you should just use the Singleton module here.
As for the question, --list-undoc is not part of the yardoc command. See #844 for more, or yard doc --help for valid options.

Thanks for getting back to me. The --list-undoc is fully clear.
I simplified the example to make the point. Using Singleton implies certain limitations, i.e. I cannot pass arguments to the initialize(). So I prefer to keep it as is. I agree that using allocate and initialze() would be possible but I would prefer if this would be fixed.
Can you elaborate what "accepting a pull request" means? I am not familiar enough with Github I guess.

@fappelman,

I simplified the example to make the point. Using Singleton implies certain limitations, i.e. I cannot pass arguments to the initialize().

You should never need to pass arguments to #initialize if it's a singleton. The only user ever calling #initialize on the class should be that class itself, at which point you don't actually need to call it (nor should you ever be calling new).I don't see why this limitation should affect your case.

Can you elaborate what "accepting a pull request" means? I am not familiar enough with Github I guess.

Basically, I would accept a patch that fixed the behavior described in my original comment. See GitHub docs for submitting pull requests. I don't have any plans (or time) to address this myself without a patch, since at the end of the day this is an aesthetic issue with coverage statistics of a fairly uncommon scenario (namely counting private methods in your documentation), and this specific case has plenty of easy workarounds (many of which I didn't even get a chance to mention).
If you end up taking a stab at a fix I'd be happy to review it!

@lsegal
Figuring  out how your code works is challenging and I'm not sure that I fully grasped how to fix this properly. This simple fix does the job
It does not break any of existing rspec testcases.
diff --git a/lib/yard/handlers/ruby/visibility_handler.rb b/lib/yard/handlers/ruby/visibility_handler.rb
index d6c3e4c..46b0db0 100644
--- a/lib/yard/handlers/ruby/visibility_handler.rb
+++ b/lib/yard/handlers/ruby/visibility_handler.rb
@@ -17,7 +17,7 @@ class YARD::Handlers::Ruby::VisibilityHandler < YARD::Handlers::Ruby::Base
         when :string_content; source = node.source
         else next
         end
-        MethodObject.new(namespace, source, scope) {|o| o.visibility = ident.first }
+        MethodObject.new(namespace, source, scope) {|o| o.visibility = ident.first } unless source == "new"
       end
     end
   end

new is a bit of special case so maybe this simple fix is sufficient. Please let me know if this is sufficient or that I should do something different.

That seems like a hack to me. As mentioned above, basically YARD should not be creating the object if it does not exist. Use ensure_loaded! to parse the rest of the source for this method. If it hasn't been loaded, the MethodObject.new operation should be skipped.

I was already afraid it wasn't properly. I will look into this. Thanks for the hint where to look.


SWP-95814 Add 10 to 20 second rates

Previous PR #2 was merged to incorrect branch.


Provide URL for FreeBSD amd64 binary

Provide a compiled binary for the FreeBSD amd64 platform so that elm-json may be installed via npm using binwrap.
The attached binary was built on FreeBSD amd64 12.2-RELEASE-p1 using rustc v1.49.0 with the command:
cargo build --release
elm-json-v0.2.10-x86_64-freebsd.tar.gz

Hi, sorry for the late response!
I'd prefer if we managed to handle compilation as part of CI.
To that end, I'm working on having GitHub actions do cross compilation, but currently can't quite make that work for FreeBSD. I'm keeping an eye on https://github.com/sagebind/isahc/issues/199 - once that's resolved, we can have elm-json depend on rusttls (at least for FreeBSD) which will make cross-compilation a bunch easier!


propose assert_ne

this is an rfc to add a assert_ne macro to compliment assert_eq. it exists as a crate: https://crates.io/crates/assert_ne.

@ashleygwilliams How often do you need assert_ne? I didn't want it once

i found that when writing tests i wanted it pretty often and on tweeting that i made the crate i got feedback that people were excited and wanted me to try to get it into the language. hence this rfc.

I personally have found it annoying sometimes fall back on assert!(x != y), since it yeilds a much less helpful error message on failure. :+1:

I have often come across cases where I would prefer to use assert_ne.

Yes, to this.  assert_ne! is easier to read, less error prone, and more ergonomic.  I usually wind up writing some form of this in a lot of my projects.

Bikeshed alert:
I have a slight preference for a more informative suffix than _ne. I would be happy with e.g. assert_neq!

(I would also be happy with assert_not_eq!, but that is a bit more difficult to type especially with the second underscore.)

I think that assert_neq! is more likely to be immediately comprehensible than assert_ne!, at least for newcomers.

I understand where ne comes from, and ne makes a lot of sense in the context of e.g. bash test conditions, or assembly programming (e.g. repne in x86, bne in mips and alpha, etc).
But in either of those cases, there tends to be an emphasis on both:

brevity and
regularity (thus encouraging all predicates have same length in characters).

In Rust we have certainly de-emphasized 1 in favor of familiarity (e.g. the shift from next to continue). I'm not sure how much emphasis we place on 2, but I don't think it trumps familiarity.

@pnkfelix totally hear this and mostly agree! i chose assert_ne based on the overwhelming preponderance of ne in the source (https://github.com/rust-lang/rust/search?utf8=✓&q=ne&type=Code).
would be totally open to changing it if others agreed.

I agree with your sentiments, but also think about other things in the API, like PartialEq::ne - I would favor consistency in this case.

@bjz One rarely types or reads ne for PartialEq though, instead using !=. (Of course, this doesn't necessarily rebuke your consistency argument, but maybe dulls it slightly.)

There are many other operations that would make sense like all the Ord ops etc. If one new macro is added, it would make sense to add the others, too. But there's also an alternative:
If assert! were rewritten as a syntax extension instead of as a macro as it is now, then it would be possible to automatically detect assert!(x < y), assert!(x == y), assert!(x != y), ...
This has the major advantage of not needing textual identifiers, but using the actual operation and still producing a nice error message. It would probably be possible to improve the errors produced by these macros, since the syntax extension can produce better spans than macros.

I think making assert! a syntax extension that inspects the condition is the way to go.
Pytest does the same thing (demo) and I've found that extremely helpful.

assert_eq!(x, y) requires x: Debug and y: Debug while assert!(x == y) does not.
An assert! syntax extension could not require x: Debug and y: Debug for compatibility so it wouldn't do much.

A syntax extension could convert assert!(x == y) into a function call assert_eq(&x, &y), and that function can then use specialization to act differently depending on the types of x and y.

Given that we already have an assert_eq! macro, would it not make more sense to plug that gap in the interim before embarking on a more ambitious change to the semantics of the assert! macro?

@ashleygwilliams Thanks so much for this. I have wanted this occasionally, and falling back to bare assert is annoying as you said. It's encouraging that your crate is already getting use, and that people on this thread have expressed demand for the feature.
I agree that a more ambitious refactor of assert! is a good thing to expore, but as @bjz said, given that we already have an assert_eq!, adding this functionality seems like a good medium-term approach to adding the necessary functionality, without adding too much avoidable cruft.
I'm for this :smile:

Why not include assert_{gt|lt|ge|le}! as well?

I rolled my own assert_neq! by copy-pasting assert_eq out of the standard library, so I would have liked to have this:
https://github.com/luser/sccache2/blob/fd5da79fe896fbdc39a711e257dd370644b0d526/src/test/utils.rs#L37
(I can't remember why I chose neq instead of ne.)

I don't think we need this in the standard library, this should be fine to live in a crate. You could use this: more-asserts.

I specifically wished for this a few days ago when writing test code.
I'd love to see a smarter assert!, too, but I'd like to have assert_ne! available for consistency in the interim.

Like @kennytm I'd prever having all comparison operators represented by assert macros, i.e.:
assert_eq!, assert_ne!, assert_ge!, assert_gt!, assert_le!, and assert_lt!, plus their debug siblings. So, in a way, I propose making the crate [more_asserts`](http://www.thomcc.io/rust-more-asserts/more_asserts/index.html) standard stuff.
Having only assert_eq! and nothing else does not just feel lazy, but I, too, also use various comparing assertions besides equality testing in my tests. And having not just assert! but also assert_eq! is more than enough justification for me to import all the others.

i'm happy to write the rest of these as per @Evrey , i actually have a crate called asserts where i'm collecting this functionality. (looks like this was published the exact same day i wrote that crate and opened this rfc? by a mozilla employee no less- were we in the same room?)
in other news, i've updated my assert_ne crate to reflect the recent addition of custom messages to assert_eq https://github.com/rust-lang/rust/pull/33976/files

i would propose that using a crate is not ideal, if only because when updates like the one i just mentioned happen the behavior is out of sync. it'd be great to just be able to edit and improve them all at once.

I have also found a need for assert_ne! in the past. The other comparison operators I don't think would come up as often, but would also be helpful.
Another that I ran into a need for recently is assert_match!(err, SomeErrorVariant(_)). I originally tried assert_eq!, but then I would need to implement PartialEq for my error type, and I couldn't do that conveniently with #[derive(PartialEq)] since one variant contained std::io::Error, so I'd have to do it by hand. What I wound up with was assert!(match err { SomeErrorVariant(_) => true, _ => false }), but that's kind of cumbersome and doesn't give good error reporting if the assertion fails. After implementing it myself, I discovered there already was an assert_matches crate that provides that macro.
I haven't encountered it in Rust yet, but in Python I've found it useful to have assertIn/assertNotIn, and assertRaises (which would be assert_panic!() in Rust), and assertItemsEqual (tests that two collections have the same elements even if in different order).
Of course, there are two reasons for wanting all of these different types of asserts; one is just code reuse, of commonly used predicates, but you could also just use write the predicates as operators, method calls, or function calls inside an assert! macro. The main reason for needing macros is to be able to also get at and print the value of the subexpressions, to make it easier to determine why a particular assertion failed.
As mentioned earlier in the thread, instead of introducing a number of special purpose assert macros, the existing assert! macro could be extended to print out subexpressions. In fact, there is already the power-assert crate that does just this.
So, it would probably be a good idea to figure out the approach that we want to take; the power-assert approach, of just making assert! give better diagnostics, or the approach of having one assert_<pred>! per predicate, and with the latter approach, whether to integrate it into the standard library or leave it to external crates. If we do leave it as an external crate, it would be nice to at least propose it for rust-lang-nursery/rust-lang, so that there's a single central crate of nice assert macros that can be updated together and has consistent contribution guidelines. Right now, I'd have to pull in two tiny crates for assert_ne!, assert_matches!, and write my own assert_panic!, which just makes finding all of these things harder.

@lambda I think there's no particular need for the community to standardize on one assert crate, these don't affect downstream users of your library.
Making assert! print out subexpressions would unfortunately also lead to code bloat when asserts are just used to signal runtime invariants.
[Asserting a panic can be done using #[should_fail="unique part of message"] or #[should_fail].]

@tbu- Consolidating them in one crate would address one of the concerns that @ashleygwilliams brought up, of making it easy to apply enhancements consistently, such as formatting improvements or consistently expanding them to add extra arguments.
It would also make them more discoverable; when I searched for "assert" on crates.io to see if there was already a comprehensive assertion crate that provided assert_ne! or assert_match!, I see 289 results, the first one named assert just provides an approximate floating point assertion, and I have to trawl through things like more-asserts, power-assert, assert_matches, static_assert, static_assert_macro, assert_ng, assert_ne, assert_approx_eq, asserts, bassert, passert, etc to see which, if any, I actually want to use.
Also, I recently got burned when I went on crates.io, found a crate that looked like it did exactly what I needed, tried it out and it seemed to work at first, I was only using it for tests so I figured I didn't need to audit it too deeply, and then later on some of my tests started failing and I spent a long time debugging my code until I discovered that the crate I was depending on for testing was completely buggy. So I'm a lot more wary now of quick little hack crates from people I don't know, even for tests.
So rather than dig through all of the above mentioned crates, I just went ahead and implemented what I needed myself and moved on. Which kind of defeats the purpose of libraries. That's the big issue with an ecosystem of lots of little tiny libraries that each implement a very small piece of functionality; the work to find, validate, and trust each one individually can outweigh the benefit of using a library in the first place.

Making assert! print out subexpressions would unfortunately also lead to code bloat when asserts are just used to signal runtime invariants.

This could be dealt with by making that functionality conditional on #[cfg(test)] or #[cfg(debug)]. I agree, however, that this is a good concern for a fancy assert! macro, rather than just having a library of assert_<pred>!; I don't really have a preference either way, but would find it helpful to have one or the other readily available.

[Asserting a panic can be done using #[should_fail="unique part of message"] or #[should_fail].]

Looks like you mean #[should_panic]/#[should_panic(expected="message")]. Which is also not easily discoverable, and more limited than an assert_panic!, in case you're testing something where you want some piece of code to panic, and continue to assert that some invariant holds after the panic, such as a lock held by code that panicked being poisoned.

I'm not sure assert_eq! would be accepted into the standard library if it was proposed today, but since it is there I think it should be paired with its twin. I don't think assert ord relations are comparably analogous - eq / ne are defined by the same trait, whereas gt/lt etc are defined by a different trait which is implemented for far fewer types.
Basically, I think the reasons against this being in std all apply to assert_eq as well, and assert_eq is there.

I believe it's far more common (by at least one order of magnitude) to compare for equality in tests: it just provides more guarantees. In that way, I don't think that assert_ne! is really warranted by the existence of assert_eq!.

I would suggest that this seems like an eminently bikesheddable proposal.  Rather than continuing to bikeshed it, I would suggest narrowing the question: is assert_ne! useful enough to go into the library alongside assert_eq!?
If people want to see variants for lt/le/gt/ge, they could propose them.  And I'd love to see someone propose a version of assert! that gives details about the components of the asserted expression.  But this particular pull request proposes assert_ne!, and I think that's worth evaluating for inclusion, rather than blocking it because a half-dozen other things might also be useful above and beyond it.
I would also argue that a family of assert macros makes sense to have in the core, because they go along with #[test]. Having to pull in a separate crate for those seems like overkill. And these do not take up any code size at all unless used.

If people want to see variants for lt/le/gt/ge, they could propose them. And I'd love to see someone propose a version of assert! that gives details about the components of the asserted expression. But this particular pull request proposes assert_ne!, and I think that's worth evaluating for inclusion, rather than blocking it because a half-dozen other things might also be useful above and beyond it.

I agree. I'd find assert_ne useful regardless of whether we end up adding other members of the family of assertions.
I would also love to see a follow-up proposal to this that added the most obvious remaining members of the family, and agree with you that given that #[test] is built-in, a handful of assertions that are connected to Rust's operators feels like a good fit for the standard library.

hey! as this is my first rfc, i'm interested in how we decide to resolve this and move forward- should i make a PR?

The RFC will get into the final comment period (FCP) for one week at some point, afterwards it'll either get accepted or not. If it gets accepted, then it can be implemented.

thanks @tbu- !
@wycats: rfc submitted, https://github.com/rust-lang/rfcs/pull/1662

🔔 This RFC is now entering its week-long final comment period 🔔
The libs team discussed this RFC today (along with #1662) and the overall feeling was that these are a very low maintenance burden, if any, and the road is already paved with assert_eq so it seems reasonable to add more.

Could we instead try to introduce a more integlligent macro, such as @nagisa's proposal in https://github.com/rust-lang/rfcs/pull/1662#issuecomment-229372157? I don't think introducing a new macro (which is then dropped into everyone's namespace because macro namespaces are global) to the standard library (which should have a high barrier to entry) is proper for something that is not used very much.
From the Rust compiler and standard library (i.e. the rust-lang/rust repo):
$ grep -r 'assert!.* < ' src/lib* src/test/  | wc -l
263
$ grep -r 'assert!.* > ' src/lib* src/test/  | wc -l
160
$ grep -r 'assert!.* >= ' src/lib* src/test/  | wc -l
174
$ grep -r 'assert!.* <= ' src/lib* src/test/  | wc -l
184
$ grep -r 'assert!.* != ' src/lib* src/test/  | wc -l
217

Compare that to equality:
$ grep -rE '(assert!.* == |assert_eq!)' src/lib* src/test/  | wc -l
10673

Equality is used two orders of magnitude more often than the others.

For all crates:
$ grep -rIE '(assert!.* == |assert_eq!)' * | wc -l
96910

vs
$ grep -rI 'assert!.* < ' *  | wc -l
4389
$ grep -rI 'assert!.* > ' *  | wc -l
3124
$ grep -rI 'assert!.* != ' *  | wc -l
1291
$ grep -rI 'assert!.* <= ' *  | wc -l
2276
$ grep -rI 'assert!.* >= ' *  | wc -l
1304

@tbu I'm not sure your grepping for various occurrences of assert actually proves anything about the actual utility of a specialized macro here.
In particular, if I want the error message on a failure to actually include descriptions of the values that were not equal, I cannot use assert in any form. I have to resort instead to something like
if (x != y) { panic!("Oops x != y for x: {:?} y: {:?}", x, y); }

Your data does not tell me how many times the above pattern occurs. (I certainly understand the difficulty in actually gathering such data; I am not trying to suggest that you attempt to gather it. I just want to warn against false inferences.)

@tbu In addition to @pnkfelix's comment (with which I agree) I would also suggest that a lot of programmers use what's available especially given that most tutorials and docs use nothing but the asserts.
I like that you tried to use real data but in this case I don't think past usage is a good indicator of what will be used.  The data is skewed.

@pnkfelix Is this just a generic counter argument or do you actually believe that this pattern exists in the wild?
I wouldn't have guessed that it does, can you point me to one instance of it? I'll try to gather data on that too when I understand how the pattern can look like.
@ereichert The data isn't the only argument. I made the argument in this thread that inequality is rarely useful to test for; you want to check for exact results in tests. The data I provided just underlines that fact.

@pnkfelix Also, I would probably have written that as assert!(x != y, "{} != {}", x, y).

@tbu- ah I forgot that the alternative format of assert! allows for arbitrary format inputs after the string literal.
In a quick search over the rustc code base, I didn't see too many instances of that particular pattern; there were variations of it, like this: https://github.com/rust-lang/rust/blob/master/src/librustc_back/dynamic_lib.rs#L133 but even that includes a little bit more context (the argument to cos), and as you say, even it could be written with assert! instead.

One good way to look at this is to look at examples from a language that has a richer set of assertions built in, and has for a long time so people have had a chance to use them.
Python has a fairly rich set available for unit tests. If I grep the Django codebase for anything that looks like a call to one of the unit test assertions, I see the following top 20. Note that several of these are custom assertions, not the built in ones:
$ git grep -E 'self.assert[a-zA-Z0-9_]+\(' | grep -Eo 'self.assert[a-zA-Z0-9]+' | sort | uniq -c | sort -nr | head -20
12279 self.assertEqual
1375 self.assertQuerysetEqual
1192 self.assertRaises
1050 self.assertTrue
 842 self.assertIn
 727 self.assertRaisesMessage
 672 self.assertFalse
 664 self.assertContains
 445 self.assertHTMLEqual
 443 self.assertIsNone
 431 self.assertIs
 380 self.assertNumQueries
 356 self.assertIsInstance
 298 self.assertNotIn
 180 self.assertRedirects
 152 self.assertOutput
 144 self.assertNoOutput
 137 self.assertNotContains
 135 self.assertNotEqual
 133 self.assertTableNotExists

assertEqual is by far the most common, with an order of magnitude more uses than the next. The next appears to be a Django specific equality assertion. After that comes assertRaises for testing that some thunk raises an exception, followed by the generic assertTrue, and then assertIn for testing for membership in a collection. There are a variety of uses of both built in and custom methods after that.
assertNotEqual is down at number 19. In total, if I replace the head -20 with wc -l, there are 122 different assertions used, most of them custom. Python itself comes with 30 different assertions; assertNotEqual is 11 out of the assertions that Python provides (or 12 if Django used the built-in but newer assertRaisesRegexp rather than its custom assertRaisesMessage).
I'll also note that I first tried this on Flask, but only found one use of the above assertions. It turns out that Flask uses Pytest, which instead provides support for printing values of subexpressions directly from the assert statement.
I've also run these same search on my dayjob codebases, and see similar results; more than an order of magnitude more use of assertEqual than anything else, followed by assertRaises (and assertFailure, the async Twisted version of assertRaises), then a mix of build in ones like assertIn, assertTrue, assertFalse, assertNotIn and assertNotEqual along with a few custom ones, then a long tail of handfuls of uses of more obscure built in ones and custom ones.
Given the large proliferation of both built-in assertions, and custom assertions, in Python codebases using the standard unittest framework, I'd probably be more in favor of moving towards a pytest/power-assert style assert! macro that prints subexpressions (probably conditionally based on #[debug] or #[test] to avoid bloat in production code) and possibly adds some kind of custom diff display, as defining these endless custom assertions mostly for the sake of just displaying the values of the subexpressions seems like a lot of wasted time and effort.

I may have sounded a little too negative in the previous comment, so want to clarify.
I support either adding richer assertions, or making assert! smarter; I find it frustrating when I have to reinvent the wheel, just use assert! and deal with adding extra code to print out the subexpressions every time, or add more dependencies on external crates for trivial things like this. I don't think that adding assert_ne! should be blocked by bikeshedding or slippery-slope arguments on proliferation of assertions; it is a demonstrably useful assertion to have, I have needed it recently, so I would like to see it included, unless there is a more immediate plan to go with a more powerful assert!.
If we're not going with a more powerful assert!, then I'd probably want to propose more custom assert_<predicate>! macros for the same reason, but that can go in a separate RFC. I would have a slight preference for improving assert! over adding more individual assert_<predicate>!, but I find them both acceptable ways of solving the problem.

I don't think it matters that assert_ne is needed less frequently than asset_eq. Its my expectation that when I have an "eq" form of an action, its paired with an "ne" form as well. For the occasion when "ne" is what I need, it is frustrating and disruptive to my work that the macro isn't at hand.

I think the key here is that the majority of not-equal assertions have the form assert!(x != CONSTANT). This means that if the assertion fails, you immediately know that x == CONSTANT, so there is no need to print the values being compared.

@Amanieu ...unless you're testing a PartialEq implementation that defines "semantic equivalence" for values that aren't structurally equal.  In which case you'd like to know what actual values you had on both sides.

@Amanieu Where are you getting your "majority" from? When I look at one of my (Python) codebases, I find out of 20 assertNotEqual uses, only 6 of them have a constant on one side. Knowing what the values are, when the discrepancy in what you're expecting could come from either side of the comparison, can be useful.
When I look at Django, I see a higher percentage of comparing against a primitive constant, but I also see a good number in which neither side is a constant, and a number of tests which are testing a custom equality predicate to ensure that particular different objects don't compare as equal, while other ones do compare as equal, like @joshtriplett mentions.

@lambda In one of my C codebases I have 27 asserts which contain !=. Of these, 24 involve comparing against a constant.

The libs team got a chance to discuss this RFC during triage yesterday, and the decision was to merge. This macro helps reduce the "surprise factor" when looking at the standard library's macros and also isn't much of a maintenance burden, so it seems like an all-around win. We have also decided to not merge https://github.com/rust-lang/rfcs/pull/1662 for now (the other family of assertion macros), but I'll write more over there in a second.
@ashleygwilliams could you also update this to include the debug_assert_ne macro akin to the debug_assert_eq macro as well? After that I'll merge.

@alexcrichton
@ashleygwilliams asked me to watch out for this decision, because she's in a few meetings today. As it turns out, she's in one literally right now. She says she'll update it later today, once she's out of said meeting.

@alexcrichton Could the response by the libs team acknowledge that inequality assertions are used less frequently? I'm fine with the decision, but I think it's not nice to only mention the arguments in favor of the decision of the libs team, rather it should state relevant counter-arguments and say that the benefits outweigh them.
Sorry to ask for this in a thread that I have participated in as well, but I think the proclaimed "all-around win" is maybe a bit disingenuous.

(Unless the libs team doesn't think that frequency of use is a relevant argument.)

@tbu- ah yes I forgot to mention that we discussed that although this seems to be used not as often as the equality macro, for example, it's still a surprise that it doesn't exist. That, when coupled with the fact that the maintenance overhead is basically zero, convinced us that it'd be fine to merge.

@alexcrichton updated. lemme know if you'd like me to squash/rebase etc.

also: is the next step that i make a PR on the language repo?

@ashleygwilliams Yup.

Awesome, thanks again @ashleygwilliams! We actually prefer to avoid squashes on RFCs to preserve history, so as-is was fine. Also yeah the next step is to make a PR against rust-lang/rust, referencing the...
Tracking issue

:tada: i'm on it!


istioctl workload: put proxyConfig.proxyMetadata in cluster.env

fixes #29125
Setting the environment via istioctl via the proxyConfig annotation or any values we generate in the proxy config.
This will work to properly use meshConfig/proxyConfig for VMs but only when using istioctl.
I do think agent should be capable of using proxyConfig directly, or should emit warnings for all values specified in proxyMetadata via the proxyConfig file that aren't also in the environment. It seems confusing that we ignore so much of this file.
cc @howardjohn @christian-posta

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-telemetry-mc-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-mc-k8s-tests_istio

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

Test failure looks real

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-mc-k8s-tests_istio

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-telemetry-mc-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

The new test doesn't really cover everything, especially flags, but it does bring us from 25% to 75% coverage.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

unit-tests_istio
e8d5a33cc172472e579fc9018e65fe90ed246b29
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-distroless-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-multicluster-tests_istio

integ-security-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-multicluster-tests_istio

integ-security-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-k8s-tests_istio

integ-pilot-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-k8s-tests_istio
17b08c1a6215eea94ec19fc714763e021ae1c472
link
/test integ-telemetry-k8s-tests_istio

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-multicluster-tests_istio

integ-security-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-k8s-tests_istio

integ-pilot-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-k8s-tests_istio

integ-security-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-multicluster-tests_istio

integ-security-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-k8s-tests_istio

integ-pilot-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-k8s-tests_istio

integ-security-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-multicluster-tests_istio

integ-telemetry-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-ipv6-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-ipv6-k8s-tests_istio

integ-distroless-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-distroless-k8s-tests_istio

integ-pilot-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-multicluster-tests_istio

integ-security-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-k8s-tests_istio

integ-pilot-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-pilot-k8s-tests_istio

integ-security-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-multicluster-tests_istio

integ-telemetry-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-telemetry-k8s-tests_istio

integ-telemetry-mc-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-multicluster-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-security-multicluster-tests_istio

integ-telemetry-mc-k8s-tests_istio
f2836a19f5408327328fbfb58138292981608b59
link
/test integ-telemetry-mc-k8s-tests_istio

integ-telemetry-k8s-tests_istio
ba77593706d07f0ee535e4d84bd636c430b20abd
link
/test integ-telemetry-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio
abf3276d3bca40dfdf02bc7a0fdaf7557cce5aeb
link
/test integ-pilot-multicluster-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-pilot-multicluster-tests_istio

In response to a cherrypick label: #29393 failed to apply on top of branch "release-1.8":
Applying: istioctl workload: put proxyConfig.proxyMetadata in cluster.env
Applying: add unit testing
Applying: remove hack from echo vms
Applying: cluster.env has trailing newline
Applying: newline
Applying: respect echoCfg.VMEnvironment
Using index info to reconstruct a base tree...
M	pkg/test/framework/components/echo/kube/deployment.go
M	pkg/test/framework/components/echo/kube/instance.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/test/framework/components/echo/kube/instance.go
Auto-merging pkg/test/framework/components/echo/kube/deployment.go
CONFLICT (content): Merge conflict in pkg/test/framework/components/echo/kube/deployment.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0006 respect echoCfg.VMEnvironment
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to a cherrypick label: new issue created for failed cherrypick: #29447


Raspberry Pi Config Not Working (Black Screen)

Hello, I've added the the contents of the file in folder 016 to my config.txt and the screen is not working (blank, light blinking on the HDMI to MIPI board). Any guidance on where to go from here?

Ok, I have finally figured this out, if anyone else has issues here's some places to get started with config.txt:
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=87
hdmi_force_mode=1
#dtoverlay=vc4-kms-v3d

hdmi_timings=1440 0 50 8 15 1440 0 8 2 6 0 0 0 60 0 132180000 0
hdmi_drive=2
disable_overscan=1

MAKE SURE to have vc4-kms-v3d commented out anywhere in the config file. There's something about KMS that just absolutely does not work with this monitor. This conflict should really be in the documentation as it's caused me endless trouble. More details on all the commands is on this nice adafruit writeup and th raspberry pi documentation
Also, force_turbo is misspelled in every file on here as force_trubo which means it is ignored and therefore not needed.


chore: add json to codebus

not sure why we excluded all .json, maybe because of the .jsons in the root?

not sure why we excluded all .json, maybe because of the .jsons in the root?

yes. I added an exclusion for them


Partial Translation for translation-tl.json file.

Hi. This is my Partial Tagalog Translation for translation-tl.json file.
I translated 299 strings (44.2 %) out of 676 strings.
I translated 1122 words out of 2508 words.

Thank you @wetneb