Upgrade to Python 11

Motivation / Current Behaviour
Python says version 11 is 10-60% faster, we should take that
Enhancement description

[x] Test if python 11 runs our programm
[x] quick test if 10-60% performance increase is really achieve
[ ] fix conflicts

Additional context
No response
Checklist

[X] Attached labels, especially loc:: or model:: labels.
[X] Linked to project

Epidata unittests and download files run without any warnings or errors. In terms of performance, I didn't notice a huge difference. I would say 15% increase max but I don't have data on that.

For using python 11 we need to upgrade pybind11 >= 2.10.1 (currently 2.5)


Using Ctrl + A or Shift + down arrow or Shift + End does not select all fields in SOQL builder

In using the SOQL builder inside Visual Studio Code, I noticed that the way to select fields is odd. The only way that it works is if fields are individually clicked on inside the multi-select UI element. In other words, the items selected in the multi-select are not in fact the ones that will be used. Rather, each field has to be individually clicked. This isn't scalable.
https://user-images.githubusercontent.com/6230719/106395104-4b63e380-63b5-11eb-806c-bdfea075b7fe.mp4

Hi @davidjbrossard - Thanks for trying SOQL Builder and giving us feedback!  (The video is helpful!)  This is a duplicate of #89, so I've linked this one there and am closing this issue.  Feel free to add more comments to #89 if you have further input on this.


classicube: add .desktop file

Description of changes
Adds a .desktop file for ClassiCube
Closes #207036
Things done
I use Sway which doesn't support .desktop files. I have not tested that the .desktop file actually works.

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

not exactly sure how to test this

not exactly sure how to test this

you could copy the files to your configuration directory and then add it to your package list. So, for example,

Create a directory called 'classicube' in your configuration directory
Go to the "files changed" tab
Click the three dots then "view file" to see the entire file
Copy the default.nix file and the three patch files to the previously made directory
add (pkgs.callPackage ./path/to/classicube {}) to your systemPackages (or home.packages for home-manager)
rebuild and switch (depending on what DE you are using, you may need to relog to refresh the application list)

not exactly sure how to test this

https://nixos.wiki/wiki/Nixpkgs/Reviewing_changes

it works


Reduce the frequency of Zebra performance logs

Motivation
As part of #4747, we added some info-level performance logs to Zebra.
But performance is good enough now, so we can reduce the frequency of those logs.
Tasks
We could downgrade all the logs to debug level, but it might still be useful to log them for very long tasks.
For example:

the state can take up to a minute to commit a block, so we want to log that at trace or debug level
rebuilding non-finalized note commitment trees can take 1-2 minutes, so we could log that at info level
blocks timeout after 10 minutes, so we might want to log a warning before 10 minutes

The performance logging is implemented in:
https://github.com/ZcashFoundation/zebra/blob/main/zebra-chain/src/diagnostic.rs

Fixed by #4997.


LayerNorm is extremely time consuming when computing gradient

Hi @lukaszkaiser   I use run_metadata to generate timeline for the transformer model, and check which block is time consuming. I have found that layer_norm is extremely cost in gradient computation, as showed in the figure:

The SymbolicGradient in red circle is the gradient computation of the layer norm for each encoder and decoder layer. It nearly cost most of the time. And in feed forward  stage, it's not that time consuming, but also heavy, showed in this figure:

I have check the layer norm implementation, and found that you define the "layer_norm_compute" and "layer_norm_compute_grad" function by yourself.
So I don't quite understand why the layer norm is so time consuming, do you have any ideas?

One thing to try: could you set allow_defun to False (https://github.com/tensorflow/tensor2tensor/blob/master/tensor2tensor/models/common_layers.py#L33)? That'll break layer norm into separate kernels, and it should be possible to see which one is taking the most time. Thanks for pointing it out!

@lukaszkaiser  Thanks, I have set allow_defun to False, and there are so many kernels in layer norm, each is not costly, but sum all up cost much.  I am wondering why layer norm have broke into so many ops and I am trying to figure it out, do you have any ideas?

Another question is there is a time gap between data feedforward and gradient backprop, as showed in the below figure.

The feedforward cost nearly 100ms, and backprop cost nearly 1000ms, and there is 400ms time gap between feedforward and backprop. And during the time gap, the cpu_pool and cuda_host_bfc increase as showed in the bottom of the figure. I am just use a single GPU. So what happened during the time gap, is it need to transmit data between CPU and GPU?

Probably, but it's all a bit strange. Could you try using noam_norm (a very simple op) rather than layer_norm? Is it faster?

@lukaszkaiser  Yes, When I change layer_norm to noam_norm, the speed change from global_step/sec: 0.845291 to global_step/sec: 0.912363 for transformer_base on a single gpu.

Ok, I think it's time we closed this. It'd be great to make layer_norm faster, but it looks more like a task for upstream TensorFlow -- for now, we have a faster noam_norm and it doesn't look like we can do much more. Except if someone sees a better way, in that case please reopen as tell!


nixos/influxdb2: do not load passwordFile and tokenFile when provisio…

…ning is disabled
Description of changes
Fixes https://github.com/NixOS/nixpkgs/pull/249211#issuecomment-1683841559

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Tested evaluation by deleting the provision section in nixos/tests/influxdb2.nix.


Implement letterSpacing on Android >= 5.0

Motivation
letterSpacing is completely missing from RN Android at the moment.
I've reviewed the letterSpacing implementations in #13199, #13877 and #16801 (that all seem to have stalled) and managed to put together an improved one based on #13199, updated to merge cleanly post https://github.com/facebook/react-native/commit/6114f863c3aed826355530bcf404ee5aed2f927b, that resolves the issues I've identified with that code.
I believe this is the closest PR yet to a correct implementation of this feature, with a few caveats:

As with the other PRs, this only works on Android >= 5.0 (silently falling back to no letter spacing on older versions). Is this acceptable for a RN feature, in general? Would a dev mode warning be desirable?
The other PRs seem to have explored the space of potential solutions to the layout issue (Android renders space around glyphs, iOS to the right of each one) and come up empty, so I've opted to merely document the difference.
I have neither updated nor tested the "Flat" UI implementation - everything compiles but I've taken this comment to mean there's no point in trying to wade through it on my own right now; I'm happy to tackle it if given some pointers.
The implementation in ReactEditText is only there to handle the placeholder text, as ReactBaseTextShadowNode already affects the input control's contents correctly.

I'm not sure whether <TextInput> is meant to respect allowFontScaling; I've taken my cue here from ReactTextInputManager.setFontSize(), and used the same units (SP) to interpret the value in ReactEditText.setLetterSpacingPt().
I'm not sure whether <TextInput> is even meant to support letterSpacing - it doesn't actually work on iOS. I'm not going to be able to handle the Objective-C side of this, not as part of this PR at least.

I have not added unit tests to ReactTextTest - is this desirable? I see that some other props such as lineHeight aren't covered there (unless I'm not looking in the right place).
Overall, I'm new to this codebase, so it's likely I've missed something not mentioned here.

Test Plan
Note comment re: unit tests above; RNTester screenshots follow.
RNTester - <Text>

iOS (existing functionality, amended test)
Android (new functionality & test)

RNTester - <TextInput placeholder>

iOS (not implemented, test not in this branch)
Android (new functionality & test)

RNTester - <TextInput value>

iOS (not implemented, test not in this branch)
Android (new functionality & test)

Related PRs
https://github.com/facebook/react-native-website/pull/105 - this docs PR is edited slightly from what's in TextStylePropTypes here; happy to align either one to the other after a review.
Release Notes
[ANDROID] [FEATURE] [Text] - Implemented letterSpacing

Sorry about the conflicting statements above - this still needs to be reviewed internally, but we'll need this to be rebased first in order to be able to import the PR cleanly.

@hramos I've rebased this on top of master as requested.

Agree this is something good to fix.

Any news on this? It seems a lot of effort was put into the PR, how else can we help this move forward?

The PR has already been imported, which is more than can be said for most PRs. It's now waiting for review from an employee. We'll sync back here if any changes are required.

Thanks @motiz88 @hramos @mdvacca !! 🎉

Any news on this ?

It's in 0.55:
https://github.com/react-native-community/react-native-releases/blob/master/CHANGELOG.md#055
On Tue, 15 May 2018, 09:31 Louis Lecocq<EMAIL_ADDRESS>wrote:

Any news on this ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/17398#issuecomment-389086707,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACJHpU7TcPcMrsNXFyp85FxIWaKUU6T9ks5typJQgaJpZM4RPv26
.


toward P3

Hi @gereleth!
Since a couple months after you released hexapipes, I've been wondering what it would be like to play this game on Penrose tiles.
In particular, it looks like P3 with two different sizes of rhombuses would be a good match for this game.

Weird things about P3:

Every tile has four neighbors, but it's not a grid.
It is rotationally 5-fold symmetric around exactly one point, and is aperiodic - it doesn't wrap.
The number of tiles that meet at a corner is between 3 - 7.

I am hoping that gameplay will also be weird but not broken. It should work, just different maze walls right?
I can only work on this on nights and weekends, so it may take me a while to build this. So I will share my progress in this ticket, rebase regularly, and publish the results from my fork at penrosepipes.vercel.app.
I will of course contribute back once something works, assuming it's still maintainable and makes sense to you. I think it will still be comprehensible. There may be something like a graph abstraction above the grid, the game using the graph instead of the grid.
I've published the first change, which is subtle but important. To handle P3 and other tiles that are not rotationally symmetric, we can imagine arms of different lengths and different angles going to points on the edge of the tile which are on a straight line to the center of the neighboring tile. [^1]
Now instead of rotating the <g> using transform:rotate(...), we can bitwise rotate the tile, obtain its directions, and return the corresponding deltas.
We restore animation by applying the CSS transition to the path instead of the transform.
	.pipe path {
		transition: d 100ms;
	}

If you look closely, the animation is not as good, and we might consider adding keyframes so that the arms don't get as short during the animation. But I think it maintains the illusion well enough.
The transition only works on Chrome and Firefox; on WebKit Safari/iOS it degrades to no transition. I am sure there are workarounds for WebKit but I haven't looked into it yet.
grid.getDirections(...) already has an optional rotate parameter, but there is a wrinkle: we need the arms to always be listed in the same order for the animation to make sense. So we also rotate grid.DIRECTIONS by the same amount before filtering.
At the current commit (ac09e1c72ca) I haven't yet implemented arm identity for the square grid, and you can see the bug that arises if arm directions are not returned in "original" order.
Here's a screen recording. Believe it or not, the tile is rotating clockwise, but the animation is deceptive: .
I'll publish the fix for this next week!
[^1]: I hope to find time to draw a diagram showing what arms will look like on P3. It will be weird, because the arms will rotate (and stretch) but the tile will not, but I think it will work.

Hi, Gordon! I'm really excited to see this.

It should work, just different maze walls right?

Absolutely! There's Penrose slitherlink, why not pipes)).

Regarding the rotations of rhombus tiles I thought of implementing them with some skew transform of a square tile. I made a REPL as a proof of concept that rotation transitions can look nice in this case. Of course the real difficulty is in figuring out correct transforms for different rhombus types and orientations. But maybe this is still less work than transitioning paths.
I also must confess that I changed a lot about grid implementations while working on "octagons + squares" grid. Basically I abstracted away a RegularPolygonTile that handles computing rotations, drawing tiles and pipes, detecting edgemark gestures - all the stuff that's local to the tile. So the grid delegates this local stuff to its polygon tile(s) and stays responsible for "global" questions like:

where is tile number i located (index_to_xy)
what's the number of tile located at x, y point (which_tile_at)
what's the neighbour of tile i in direction d (find_neighbour)

Maybe there could be a SkewedPolygonTile that "unskews" the coordinates it receives and then reuses regular polygon logic for all the local matters.
I've long wanted to have this "cubes" tiling - implementing this might be a way to try out rhombic tiles without the additional Penrose complications. Grid logic here can reuse the HexaGrid and further subdivide each hexagon into three parts.

I had the related thought of doing some kind of periodic rhombus tiles next week to test the variable length arms and different angles.
To make it easier I might do the simpler one-orientation rhombus first, even though it’s just squashed and rotated squares.
I had not considered a skew transform—will check out your REPL, thanks! That might be cleaner than the path transitions.
I have not looked at the octagon branch yet, but I will try to rebase on it before proceeding. It’s likely you will merge that before I finish this, and it sounds like you may have implemented some of the same abstractions I’ve been thinking about.

The disadvantage of skewing a square tile in order to make a rhombus tile is that the pipes will bend at tile boundaries, if the tiles are oriented in different directions. The advantage is that the pipes still land in the center of the tile boundaries.
Hard to say which looks better / clearer without trying.
The new abstractions look very helpful!

I am taking your advice and starting with cubes. This is... not working yet... but I think it's really close.
https://user-images.githubusercontent.com/1366709/230744040-06016e5b-d989-4d35-900c-f3cb495c8701.mov

I tried to solve one but my clicks land too unpredictably 😂. Individual tiles are looking great though 👍.

Display and gameplay mostly work for the cubes grid (demo).
There are many bugs, among them:

The generated puzzles are impossible. I haven't looked at the generation code very much, so I'm not sure if it needs to change or if the grid is improperly specified.
Clicking on the border between tiles can cause the wrong tile to rotate.
There is an off-by-one bug in find_neighbor where the rows wrap.
Smudges at tile boundaries are more visible because of the skew. I think the easiest thing to do is to clip each tile, although that may clutter the SVG with <defs>.
I haven't yet tried to get marks to work / looked into SkewedPolygonTile. It seemed simpler to start by defining the extra transforms in the grid without changing the polygons.
The naive non-wrapped grid might be too easy because the border is so bumpy.

Hope to continue this tomorrow.

It's really coming together!
Generation is currently messed up because opposite directions in the grid are inconsistent. The directions are defined like in this image (tile index in black, direction numbers in blue). See how the opposite of direction 2 is sometimes 4 and sometimes 8.

You could rotate your squares like this instead. Here directions 1 and 2 look inside the hexagon, and 4 and 8 look outside. This way the opposites are consistent and the generator should make something solvable =).

Or you could use the hexagonal directions... But then each of the three squares would have its own set of directions so I don't know if this idea is any good)).
Either way I'm also thinking that maybe we shouldn't rely on grid.OPPOSITE constant and instead return opposite direction as part of find_neighbour output. This seems like a good thing to hide away inside the grid but will require some slight changes to solver, generator and game logic.

For wrong tiles rotating and wrap errors I thought that maybe literally doing this.hexagrid = new HexaGrid(...) could be helpful. Then for example you can use this.hexagrid.which_tile_at(x, y) to find the hexagon index and only need to look at the angle to tell which rhombus it is. Same with finding neighbours - get neighbour hexagon index first and then figure out where we are inside it. I really don't wish the pain of debugging hexagonal wrapping on anyone =).

Boundary smudges may be fixed by setting stroke-linejoin="bevel"on pipe insides in Tile.svelte. I originally set it to round to avoid these small artifacts seen between connected pipes. But maybe this can be solved some other way.

Re bumpy borders we could always crank up the avoidObvious setting).

Excellent hints and feedback, thanks!
I agree it would be much better to reuse HexaGrid rather than duplicating all this code. I have been expedient to get things working, but I am glad to revise to make this maintainable.

With the rotation and direction numbering & opposites all consistent, it is now working perfectly in non-wrap mode. (It's playable but difficult to complete in wrap mode, because of the off-by-one bug.)

I think it's harder than squares but easier than hexagons. The false perspective is disorienting! 😱
Quite a lot still to fix and clean up - realistically probably won't do a PR until next week.

Wow, I just love solving buggy puzzles. Edge issues on wraps make things more challenging)).

Could you add a cubes option to the custom puzzle page? For experimenting with generator settings. I think that this puzzle would definitely benefit from bigger avoidObvious values. Maybe you can use the same generation settings as the square puzzles for now? Defined here.

It looks like P3 tiles have the same notion of "opposite sides". From the wikipedia page, with binary annotation:

stroke-linejoin: bevel looks terrible on iOS but it's fine everywhere else, including Safari.

No worries, have a good trip!

Cubes are now completely working, including wrap and edge marks, although connecting marks do not work reliably on touchscreens (walls do). I also need to apply the transform for Orient / Lock mode, which I just tried for the first time.
I got wrap working last week. I was on vacation, so I didn't mention it here. Reusing HexaGrid as you suggested removed 70 lines of duplicated code, and fixed wrap and other issues.
Since then I've played more than 100 of the 5 x 5 cube wrap puzzles (which has 75 tiles). I find it quite fun. I think the corners where 3 tiles come together make it slightly easier than square grid, so I'm usually able to prove and auto-lock almost till the end. Best time under 2 minutes but it often takes 10.
I think the non-wrap should use hexagon bounds so that there aren't exposed corners.
I'm using transformation-matrix to invert the tile transformation and detect edge marks in the original coordinate system of the polygon. Hope the extra dependency is okay.
Needless to say, the transformation matrix approach is very general and will apply nicely to P3 tiles.
So neat how the maze generation code works perfectly with no changes for this grid.  I think this only happens on the non-wrap.
I'll squash my commits and submit a PR tomorrow.
Happy to refactor further. I wasn't sure about the responsibility of controls vs grid for doing transformation - putting the code in the controls seemed less repetitive than adding the transformation matrix stuff to every grid, but maybe there's a better way.
Also the "grid tile" containing three actual tiles, each transformed its own way, is maybe not a good abstraction, just expedient.

I played some 5x5 wraps, they're nice! Quite refreshing after the confusing evilness of etrat grid that I've been working on).
It's neat how this grid has two distinct types of corners (with 3 and 6 squares meeting). All the others I've encountered so far have a constant number of tiles meeting in a corner (3 for hexagons and octagons, 4 for squares, 5 for etrat). Places where 3 tiles meet allow for some solver shortcuts but I don't yet know how to apply them to only some places in the grid.
And imagine if each rhombus were a 2x2 square grid, then we'd have 3, 4 or 6 tiles meeting in different corners :exploding_head:
Re connection marks I think it would be cool if they could bend at the tile border like the pipes do. I drew a rough example on the pinkish pipe here. But this might be tricky to implement. Like each of the two tiles should draw its own half using its own transforms? Or maybe let's end the mark at tile border at least. The part that's hanging off doesn't look good to me.

I think the non-wrap should use the hexagon playing field shape

There's a helper for that in hexagrid code, something like grid.useShape('hexagon'). It makes the corners empty to get a hexagonal field shape. I use that for dailies sometimes). You could iterate over empty hexagons and empty some rhombs in turn.

The only thing that "puzzles" me is that occasionally it draws a fully connected X

Fully connected tiles can happen during pregeneration if there is no other way to complete a puzzle. Imagine the red part here is already visited, and the upper left green corner is not. Both neighbouring red tiles are already T-shaped. And the only way to connect to the green corner is to turn one of them into an X. I don't want to introduce backtracking into pregeneration so I just allow this. A less bumpy field shape (like a hexagon) should make X tiles less likely to appear.

I haven't reviewed how the transformations work yet, I'll be able to do that once I finish with etrat branch. That grid is forcing me to learn about web workers because ensuring uniqueness takes too long to just leave it in the UI thread =).

Etrat is tricky! I look forward to hours of figuring out proof patterns there.
I agree that the connection edge marks sticking out are ugly. Wrapping around the edge would be great. I haven't figured out how to get both EdgeMark tiles to draw while only one should record.
As an experiment, I added a flag to get_edgemark_line to shorten the mark, but this affected the walls as well, making them short and displaced.

I've run out of time this week, so I'll leave it like that for now.
I also reverted changes to the controls and created gridutils.js - so the grid has exclusive responsibility of the transform. This is needed for whichEdge for Orient / Lock mode and makes sense IMO. However, Orient / Lock still doesn't work, so I'll have to dig into that next week.
I want to fix everything before submitting a PR, so it's another week if not two.

etrat-wrap is too difficult for me, and now I'm scared P3 is going to be too. 😭
Oh well, can't stop now...

Penrose tiles can't wrap by design so they can't be too bad. I expect something around square or cube difficulty.
I don't quite understand yet what makes etrat so bad. It must be the triangular tiles? With square tiles if you have a turn and know one connection then at least you can say that the opposite side is a wall. That's often handy. With triangular tiles a turn + one its connection gives... mostly nothing. It's kinda similar to low branching hexagonal wraps that are hard too.
One other thing is that etrat puzzles tend to have hundreds and thousands of solutions at even moderate sizes. So even when a puzzle has a unique solution it likely has an obscene number of "almost solutions" that look very very plausible until one last part just doesn't connect. And lookups till you find a contradiction tend to be very long.

Interesting that etrat has so many solutions!
Yes I get stuck on “almost” solutions, even with the 10x10 non-wrap. There will be one extra piece or two closed components. I have no idea how to fix it so I start over or give up.
I think you’re right that P3 should be like cubes only irregular, with 3-7 tiles meeting at a corner.

I tried out the cubes code today and I think the transforms logic is currently a bit wasteful. On every click we compose a transform matrix, then invert it too... That's running a lot of the same computations again and again because we only have three distinct cube faces and so three distinct transforms. It should be enough to compute them only once!
I think a better way to go about this would be to do
TOP_FACE = new TransformedPolygonTile(SQUARE, transform_top)
RIGHT_FACE = new TransformedPolygonTile(SQUARE, transform_right)
LEFT_FACE = new TransformedPolygonTile(SQUARE, transform_left)

polygonAt(index) {
  return [RIGHT_FACE, TOP_FACE, LEFT_FACE][index%3]
}

The TransformedPolygonTile computes transformation matrix, its inverse, and the transform style string in its constructor. And then it does pretty much the same stuff as regular polygon tiles taking care of its own coordinate conversions where necessary.
Then the cubegrid logic can look pretty much the same as other grids with this.polygonAt(index).doStuff...and forget that its polygons are weird =).
I would also remove the translate part of the transform and just give each rhombus its own center coordinates instead. This just seems easier to reason about. Not that it's easy! I tried to implement something along these lines but got bogged down trying to understand transform computations.
Can you think of any problems with this approach? I don't really know how many distinct transforms a P3 grid would have. Is there a sane number of them or infinite variety? =)

I agree the transform should only be computed once per tile “type”, and I like this TransformedPolygonTile idea. (I think you mentioned it before but I didn’t understand until now.)
Also transforms should not be computed or used for the grids that do not use this feature. I think I can revert those changes and only keep a few small changes to the grid interface.
As for removing the translate… Maybe? I have often wondered whether it is a good idea to have three tiles per grid position. It was the easiest way to reuse HexaGrid but it’s pretty messy.
For P3, each tile will need its own transform.  There are only two shapes, so the skew and scale will be the same for many tiles, but I doubt it’s worth it to count all the possible rotations of those two shapes. (I’ll check though.) Each tile’s transform and inverse could be computed once. These are 4x4 matrices so it’s not a lot of memory.

Based on my coloring experiment there are 5 kite types and 5 dart types in P3, so 10 distinct transforms in total.

Rhomb offsets should be easy to do, I'd precompute OFFSETS = [{dx, dy}, ...] for three rhomb types - deltas from hexagon center to rhomb center. And then in which_tile_at and getVisibleTiles add an offset to hexagon center based on rhomb index. I think it makes sense to keep the grid responsible for tile position and the polygon responsible for tile shape.

Okay, I think cubes is ready for review.

Next step for me is to implement the P3 tiling itself. I think I’ll use the substitution / drill-down method detailed here:
https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/aperiodic-tilings/
I’m more familiar with D3 for SVG, so I’ll probably implement the geometric algorithm standalone, and come back to the tiles in a couple weeks when I have a generator for coordinate and rotation data.

I have a demo of producing an approximate number of P3 tiles which intersect a polygon.
That Tatham paper says how to keep track of adjacency, and I've implemented coordinates for the Robinson triangles. (You can see them by adding ?coord - not sure if these are correct yet.) Tatham describes a simple recursive algorithm to find neighbors using the coordinates, and that will give us coalescing of the triangles into rhombuses and tile adjacency.
At that point the only challenge to Penrose pipes is the neighbours and opposites problem we talked about before. Your solution of the grid returning the opposite when returning a neighbour sounded good and I may give that a try in a couple of weeks.

I shouldn't jinx myself by talking as if I know what all the problems are. "Patching" the border will also be tricky.
Take this example:

We will prune any half-tiles when we coalesce triangles into rhombuses, but here that will cause such a jagged upper-left corner once the half-blue is removed that we should either drop the red or add in the other half-blue.

Implemented Tatham’s neighboring triangles in the demo above. Only a few more steps before I can integrate p3 tiles into hexapipes.

It now finds the rhombuses and their neighbours, and it repeatedly culls any tiles which only have one neighbour. The ending shape can be quite different from the original polygon.

It might be nicer to fill gaps around the border, but I haven't gotten that working, so it's hidden. I think the cull strategy works well enough to try this in hexapipes, maybe next week.

I had to debug the categorization of the ten rhombuses from coordinates, so I recreated your coloring experiment from the generated tile coordinates, binning the rhombuses by their tile-relative coordinates.

These numbers/colors are arbitrary - next to choose a consistent numbering.

What does it mean when some rhombs are white and without numbers? This usually happens when the area highlighted in the triangle on top is very small.

I like how the grid is different every time but I just realized we'll also need some way to save and restore the generated grid in addition to puzzle instance and the player's progress.

Thanks, that's a bug. I had set the precision to 11 digits but it doesn't work when the polygon radius is really small. It seems to be okay at 10.
There isn't any reason to use such high precision, I just wanted to be sure that rhombs generated with trig are the same as rhombs generated by triangle decomposition.
Technically the algorithm is deterministic and we could regenerate the same grid from the polygon shape, center and radius. You can see this by clicking the "fix" link. But it's probably safer to save the grid, which consists per tile of location, base rhombus [^1], tatham coordinates and optionally neighbours.
[^1]: which polygon out of 5 rotations and two shapes - I haven't found a good name for this, "face" was nice for cubes but doesn't make sense here. "base" is ok.

Implementing P3Grid was easy with the new AbstractGrid. Still much debugging to do, and grid storage, but I think we might see something next week or the week after.
I've been calling it P3 because there are other Penrose tilings and in theory you could play with kite & dart tiles, but what do you think? Is it better just to call it Penrose everywhere?

This is so exciting! I think darts and kites will not work with pipes because the shapes are not symmetric. So calling it penrose should be fine I guess?
I got them to display at least, they look so drunk :joy:

My clicks do nothing for some reason but I scribble-solved it to verify that the generator did something sensible))

Grid construction is currently non-deterministic, right? There is a problem that the generator component and the page create grids independently and they end up different, not even the number of tiles matches. I temporarily switched to using a generator directly on custom puzzle page to get to this result. Here's a patch with my changes if it helps.
debug_penrose.patch.txt

Wow you got it to work!! Amazing how quickly this fit together - I did some research but basically started the hexapipes integration 24h ago. Less than 200 lines woot.
It looks completely daft with the false perspective. I think we might need to try pipe arms at arbitrary angles instead of skew, but maybe we should keep this for the psychedelic (or as you say “drunk”) effect.
Yes I was “puzzled” why I was seeing different counts & figured it was because I hadn’t dealt with persistence. I didn’t realize there were two grid instances. It’s determinations but it chooses a random polygon to start, we’ll have to decide what state to copy
Thanks for your temporary workaround. So cool!!!
I think I know how I messed up click detection, maybe I can get it running later today.

I applied your workaround and used the correct coordinates, and it is almost playable, however it has a serious bug which would make it very difficult to complete.

It's live here.
I have run out of time for this week. If you want to work on it, you are welcome, otherwise I'll continue on Friday.
Although the puzzle is solvable, the display rotation is wrong. Side 1 of a rhombus could be in one of two places, green outline in the penrose-fill-polygon demo:

This suggests that there needs to be an offset on the original rotation based on the generated data.
But in playing with it, it looked like some tiles were off by 90º as well. I wouldn't be surprised if angles are reversed somewhere, since I didn't try to account for increasing y up or down, always the bane of trig on the web.
I don't know. There are probably multiple bugs.
I solved a tiny one:

I tried to understand what's going wrong with connections coloring by annotating tiles with index_base and clicking around. In the pic below there are two tiles with base 0, they both report the fat red dot as direction 1 and they both say that their neighbour in this direction is tile 6. Obviously one is correct and the other one is turned 180 deg. So the transformed polygon for tile 5 should have directions [4,8,1,2] instead of [1,2,4,8] I guess. I couldn't find what makes these two tiles different.

I overlaid my solution to one puzzle (in green) with solver solution (in half-transparent yellow) and we clearly agree on some tiles but disagree by 180 or 90 deg on others. I'm afraid it's up to you to figure out which rotation offsets to use on which tiles...

Thanks! Neat diagram and good analysis.
The orientation comes from the way tiles are generated - as triangles are split this introduces rotation. I couldn't find any pattern to it either, but I thought it made sense to use that side numbering, since neighborhood falls out of it.
I'll figure it out next week. Day job is pretty demanding, so unfortunately I can't completely wear myself out over the weekend.

I couldn't let it go :sweat_smile:  and made a hack for rotation offsets. It works like this:

draw an edgemark extending slightly out of the tile, use which_tile_at to find the neighbour we ended up in
find that neighbour in the rhomb's neighbours
compute an offset such that (edgemark direction index + offset)%4 = neighbour_index
remember the offset and use it in subsequent find_neighbour calls

This approach is kinda like using a walking stick to check the way forward. I'd much rather see the offsets generated along with the rest of the grid but at least the puzzle is solvable now with consistent connections coloring! See it here: https://hexapipes-git-p3-gereleth.vercel.app/custom

We'll definitely need a better implementation for which_tile_at because it's currently linear in the number of tiles and will be too slow in larger puzzles.
Generating a new puzzle hangs the tab pretty often, I haven't investigated why this happens. Edgemarks don't work.

Wow! It's just as weird as I hoped it would be. Thanks for getting it working!
Not terribly difficult - I was able to solve a "15x15" with proofs and assistant. I only paused to think once or twice, and didn't have to look for any patterns.
A "haunted" feel to it, because of sudden corners and distorted space.
Can't wait to fix all this stuff next week. Great fun!

Working on a "23x23" now.

Thoughts:

I want my edge marks.
Border is too easy, needs to be cleaned up more. Also I think it fits better in a pentagon than a square.
It's fun.

Wow cool!
So neat how the edge marks work just as you would expect, even at those topsy-turvy angles.
My conclusion was that there should be consistent opposite sides but just not in the same order for the two shapes.
That's what is shown in this diagram, which illustrates how rhombs are allowed to fit together:

I don't think there's any harm to doing it the way you describe. That's a tiny amount of space and calculation.
Maybe it will become more clear if we get the original sides 0-3 mapped correctly to 1, 2, 4, 8 without the "walking stick" and offsets/maps. But probably not. 🤪

I tried to paint these jigsaw-like marks on the edges of one puzzle. Here's what I found out:

at first it seemed like there could be 4 possible assignments (take one edge, give it an arbitrary mark, derive the rest from there). But only one of them actually worked - three others needed tiles different from the two pictured above.
it looks like there are not 10 but 20 base polygons - original 10 + the same ones turned 180 deg. See for example four light-green base 0 polygons and one dark-green that is rotated compared to them. Same with other light-dark color pairs.

So if we could somehow find this magic directions assignment and use 20 base polygons then we'd have consistent opposites and no need for edgemark hacks. Can we track these jigsaw edge types during grid construction?..
Polygons can use arbitrary directions - like [1,2,8,4] or [8,4,2,1]. But which to use where is the real question here.

Nice. I see what you are saying - yes it is 20 polygons if you consider the 180° turns.
The jigsaw edge types should be inherent to the way the triangles / rhombuses are generated. It’s all based on Tatham’s combinatorial coordinates. (Links in the readme.)
When producing the rhombuses from triangles, side 0 of the two triangles is pasted together. For the narrow rhombus, one triangle will be C and one D. For the thick rhombus, one triangle will be X and one will be Y - and the paste-edge is the long diagonal instead of the short.
Then I use the triangle sides in order X1, X2, Y1, Y2. Or C1, C2, D1, D2.
But I haven’t checked how this corresponds to the jigsaw edges in Wikipedia. I’m pretty sure there is a consistent mapping, but I simply haven’t looked.
The long-diagonal paste vs short-diagonal paste may explain a 90-degree turn. I.e. if the triangle-paste line is horizontal then the skinny rhombus will point up-down instead of left-right.
Hope this helps… gotta run for now. Thinking I may take Friday off to try to knock this out. I’m getting pulled into some demanding projects and I’m not sure if I’ll be able to spend weekends on this going forward. 😔

I looked into why the puzzle page hangs sometimes and the reason is likely that the grid creates detached tiles like this:

Disjoint grids have not come up before so the generator has no protections against them)). This looks like something best avoided during grid construction.

Aha, makes sense. I’m glad there is a simple answer to that. I’ve been playing quite a bit but I can’t get the page back when it hangs like that on my tablet.
Yes the generator absolutely should not allow disjoint tiles to get through. Wish it didn’t produce any tiles of degree 1 either…

I have implemented persistence of the grid, and the regular sizes work.
The generator produces the grid and sends it back. Then grid gets put alongside tiles in local storage, both in instance and progress.
This only happens if the grid supports getState() and initialize() - I implemented this in a non-typesafe way but I'm happy to revisit this.
There is one inefficiency - P3Grid still calculates a Penrose tiling when it is constructed. It would be better to call initialize() after createGrid but there are 8 places createGrid is called, so I held off on that.
As for the slowness of which_tile_at, I did some measurements, and it only gets into milliseconds once there are hundreds of tiles. With "100x100" which is implemented as "minimum of 10000" and producing 18000-24000 tiles, I was seeing which_tile_at take as much as 3-4 milliseconds.
This is fine for interactive on-click use, but it becomes a problem when multiplied by the walking stick poking around every tile. Might look at that next.

Nice, I played some already. Even got some quasi-wrap experience by starting a large puzzle from the middle)).

Then grid gets put alongside tiles in local storage, both in instance and progress.

I don't get why it needs to be in progress, seems to me it should live in instance only. I haven't looked at the code yet but I'll review how createGrid should work with different-every-time grids.

Detached tiles strike again and my streak is dead. It was only six games long  :smiling_face_with_tear:. At least the tab didn't hang).
I also saw an example where two thin rhombs were detached from the rest of the grid. So we can't even use "tile with no neighbours" logic to detect this situation. I thought of declaring these tiles empty if the generator can't reach them. But sometimes the generator will choose to start from a detached tile and then the whole grid ends up empty. This is exactly what happened in the previous detached example. Tricky stuff)).

You're right, the progress state doesn't need grid.
I've switched to cull strategy, not as nice border in some cases but eliminates islands by repeatedly removing any rhombs with less than two neighbors.
Chose the harder tiles, renamed to penrose.
I think the walking stick is the major problem left. I'm looking at it now.

debugging

Even got some quasi-wrap experience by starting a large puzzle from the middle)).

In theory, I think you could have an infinite penrose pipes puzzle if the maze were generated on the fly as area is explored. Would be a huge endeavor though.

In the new numbering, the flips are +10 on the old numbering (which was previously implemented incorrectly due to y increasing downward).

With flip accounted for, the skinny rhombs are offset 0; the thick rhombs are offset 1.

Without cleaning anything else up, I'm pushing the simplified offset calculation. It is fast, puzzle now loads in 1.5s for 100x100 = 18k tiles
Have to fix the example. Otherwise I think it's pretty solid.
Probably should fix the offset problem on the penrose-fill-polygon side but I still don't completely understand.

So can we assign directions with consistent opposites now?

We could. Since the order of sides in this sense is different for thin vs thick rhombs, there would have to be a mapping for one of them.
On the other hand, what you did with the lesser index seems perfectly reasonable for any grid where you don't know the opposites, so maybe that's worth holding onto.

Super glad to be rid of the walking stick!  But I haven't managed to get consistent directions with the current code.
There must be a bug with determining base polygons because when I tried jigsaw marks again I got this result. See two yellow stars made of fat rhombs. Base 0 and 10 rhombs correctly tell that they're flipped versions of each other. But the rest (base 1, 3, 4, 12) just think they are identical when they should be flipped.

Instance data for debug purposes: penrose_5x5.json.txt. Downloading a puzzle should give this data but that's another todo along with importing a puzzle on custom page)).
I noticed that rhombs data has a key property that contains a string of eight numbers. If that key is only for use in getVisibleTiles then we can just use index instead. Using index doesn't work in wrap puzzles because we may see multiple copies of the same tile. But here the index should be unique enough since penrose grid doesn't wrap.

I agree, by the jigsaw marks those stars should be consistently 0 - 4 or 10 - 14. Instead the pieces seem to be interchangeable.
Why then does the simple offset calculation work?
That key data isn't used by PenroseGrid; it's an artifact of classifying the rhombs by base.  PenroseGrid.getVisibleTiles uses coord, from the tatham coordinates of the rhomb's triangles, but you're right it could just as well use index.
I'm out of time for this week. I'm sure there are many bugs but it runs nice.

I think I have an idea about the wrong rhomb numbers. I assumed that tatham coordinates would correspond to the jigsaw edges but this is apparently not the case. Will look into it next week.
Also noted about saving the grid / geometry with the tiles to download.
It's too bad the data is so bulky. For the example I had to put it in a separate file because it's much larger than grids.js.
It's useful to have redundancy for various calculations, but I think the saved form could deduplicate.

So sorry this happened to you! I didn't have such severe symptoms myself but I think I can understand the feeling. I do have to blink and shake my head occasionally to avoid dizziness while playing largish penrose pipes. The chaotically crumpled space is not easy on the eyes.
Displaying pipes without perspective distortion is not without problems either... It's gonna be really tricky to get them to connect smoothly at weird angles. And the pipes change shape on rotation - this is especially noticeable on thin rhombs.
(Please disregard the coloring in my screenshot, I only made the geometry look somewhat correct)

Hi @gereleth! I combined the technique from the very beginning of this post with clip polygons and have a demo available of Penrose Pipes with uniform pipe widths:

I suspect that I solved this wrong, not that there is a bug in the maze. But I can't figure this one out.
Now the shapes are completely unfamiliar, but I think this is fair - what do you think?
https://penrosepipes-git-p3-gordonwoodhull.vercel.app/penrose/5
It has one severe bug where it is unable to draw arms that go off the grid. If you look closely you will see another glitch implied by arms going straight to neighbour but clipped by polygon. :wink:

Haha the edge marks need to be direct and not transformed, too

After playing a bunch of rounds, I'd say it's confusing but not disorienting: I'm not getting the vertigo I got from the previous version.
But not having familiar or consistent piece shapes makes it more difficult. If the stats are correct it's taking me 5min for a puzzle that took 2min in the previous version.
Lots of work before I can release this, even more work before it would be ready for PR.

It's confusing all right, I can't tell a straight piece from a turn at a glance!
You're drawing the pipe line to the center of neighbour, right? In my attempt above I was trying to go for edge middle. Maybe these two approaches could be combined - like we go for edge middle first and then towards neighbour center to ensure a smooth connection. That might make straights mostly straight (with some bendy ends).
In your buggy-looking puzzle the tile on the left of the green deadend looks like it still has disconnects. So it's probably a sneaky T looking outside :smile:.

Definitely worth trying. I don't like adding extra bends but if it helps the pieces be more recognizable, that would be nice.
I may also experiment with splines as it's a very wavy layout already.
And yes that must have been a sneaky T. I am often getting tripped up by 3s on the border. I think every other piece is unambiguous there.

Okay! I think this looks pretty nice.

https://penrosepipes-git-p3-gordonwoodhull.vercel.app/penrose/7
There is an optical illusion that the narrow rhombs have swollen pipes, but I have measured it and it's not real, just one of those standard optical illusions.
It has a knob symbol_portion which sets how far to draw the recognizable tile shape before then heading toward the counterpart on the next tile. The above is 0.7, which I think is a nice compromise.
Zero draws directly to the center of the next tile, as in last week's iteration.
Values larger than 1 draw past the edge without splining (just for reference):

Lower numbers get more wavy:

It's not bad without Beziers, but a a little jittery:

https://penrosepipes-git-p3-gordonwoodhull.vercel.app/penrose/7
I'm halfway to fixing the edge pieces; many other things to fix but I think it's quite playable now.

The 0.7 variant looks awesome, I love it! The shapes are recognizable and the connections are smooth. Being closer to edge middles got rid of corner glitches too. I haven't looked at the code but the results are very nice =).

Thanks!
I still need to clean up,  putting the changes safely under flags so they don't break the other grids. In particular clip paths should be enabled only for this grid and for iOS to fix #91.
And there is a backlog of things to fix in the Penrose tiles generator that we have discussed before. (E.g. I had to reverse the list of rhombus points and then offset differently for thick vs thin rhombuses, the equivalent of your neighbor_idx workaround.)
Given this will take some time, but I'm eager to get this out in the world, here's my plan:

Fix all gameplay bugs.
Launch at penrosepipes.vercel.app and announce on HN, X, etc, making it clear that this is a prototype and my intention is to clean it up and merge to hexapipes.
Deal with less urgent but annoying design problems like the inconsistencies in the generator, and any issues you raise in code review. Respond to feedback from players. Make the generator a proper package and publish it to npm.
File a PR.
Assuming we agree on something that can be merged, penrosepipes.vercel.app can serve in the long term as a staging area for further improvements. I'd like to improve the ragged edge resolution, think the splines could be even smoother, etc.

Given my time constraints, this will take months.
I'm so happy with how it turned out. The aesthetic is something greater than what I and you put into it - reminds me of fanciful fonts from the 19th century, with just a touch of psychedelia.

I made a quick fix for the missing legs problem in the p3 branch. The logic is to just keep the same direction if we don't have a neighbour to bend for =). My commit touched a lot of lines but the only meaningful changes were around line 220 (the rest was auto formatting on save). I think this looks ok (preview link).
A more sophisticated approach could use invisible neighbours for bend info but that would be overkill imho =).

That's a nice solution! Indeed I was trying to look for the invisible neighbors, which is not necessary here. In fact I think it's better to go straight to emphasize that there is nothing there.
I haven't tried slowing down the animation yet, but I think it will transition fine, since there are the same number of points per arm (and it's not trying to change between line and curve).
I've been playing a lot this week and it really picks up in difficulty on larger grids. This means that if you are playing at your limit, the variation in grid sizes (from a little larger than NxN tiles to almost 3xNxN) can make the difficulty and play times of a particular size erratic.
So I think I will shrink the polygon after generation and throw out tiles until the size is closer to NxN. Seems wasteful but it should be fast since I can use binary search and the triangle intersection code that I got from SO is wicked fast.

I'm tired this weekend, so I've been messing with ragged border resolution rather than fixing the other grids.
There was an obvious (in hindsight) bug in the fill algorithm, where it was checking for a string suffix incorrectly:
-            tri => find_tris.some(find => find.indexOf(tri.coord) === find.length - tri.coord.length),
+            tri => find_tris.some(find => find.endsWith(tri.coord)),

With that corrected, the fill algorithm delivers less portion of tiles with two sides on the border 80% of the time, across many grid sizes. The drawback is that it isn't specifically looking at degree, so it delivers grids with some tiles with three sides on the border 2-6% of the time (worse for small grids). So we'll still need to run cull after fill.
Typical cull:

versus fill:

I've been playing a lot of Penrose Pipes at many sizes, and I remain very happy with the gameplay and the aesthetic.
It will be fun to see the more difficult grids your solver produces. The dailies are very hard even with the cube grid, whereas Penrose is pretty easy with the current settings. Have to go to really big grids to get stuck at all in "proofs mode".

Hi @gereleth - do you have linting or formatting tools I should apply so that merges are less messy?

I use prettier for formatting, npm run format should do it. I normally just have VSCode format files on save.

Okay, soft launch of penrosepipes.vercel.app is live!
Please test to see if you find any more issues. I'll announce later this week.

Posted on HN and X, please upvote: https://news.ycombinator.com/item?id=37842719
I'll probably repost on Sunday morning.


Add Column headers in copy paste

Is your feature request related to a problem? Please describe.
When copying output from results pan, I can select all the records and copy them but there is no option to copy column headers.
Describe the solution or feature you'd like
Provide 'Copy with Header' option similar to SSMS while copying result data from result pan.

@vikarBCC it is already there:


feat: add scaletargetref exists check in webhook and revise some variable name

check scaletargetref exists in webhook and revise some variable name, originally,
1, There is not scaletargetref exists check code in webhook module.
2, Change the inappropriate variable name  Gckr to Gvkr.
3, Upgrade crypto to v0.31.0 which is a imported package to fix vulnerabilities Trivy has detected.
4, If still want to remain the function to create scaleobj first without real scaletargetRef obj.  Think whether this function will be a way can be configged, to confirm the  real scaletargetRef obj already exists  when we create/update scaleobj.  In this way, it can avoid the user misconfigurations about scaletargetRef in yaml file.
Checklist

[x] I have verified that my change is according to the deprecations & breaking changes policy
[x] Tests have been added
[x] Changelog has been updated and is aligned with our changelog requirements
[x] A PR is opened to update the documentation on (repo) - https://github.com/kedacore/keda-docs/pull/1506
[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #

Relates to #
https://github.com/kedacore/keda/issues/6354

Could you please open an issue for this improvement and relate this pr to the issue? This will make it clear and easy to tracing.

Could you please open an issue for this improvement and relate this pr to the issue? This will make it clear and easy to tracing.

Could you please open an issue for this improvement and relate this pr to the issue? This will make it clear and easy to tracing.

Ok, thanks for your idea.

Could you please open an issue for this improvement and relate this pr to the issue? This will make it clear and easy to tracing.

done. Thank you.

@zroubalik @wozniakjan @SpiritZhou @psi @wonko @fivesheep @JorTurFer hope you to review and discuss, thank you.

/run-e2e

PTAL @kedacore/keda-contributors

@ctccxxd , please open another PR to docs adding the new check to the admission webhooks -> https://github.com/kedacore/keda-docs/blob/main/content/docs/2.17/concepts/admission-webhooks.md

@ctccxxd , please open another PR to docs adding the new check to the admission webhooks -> https://github.com/kedacore/keda-docs/blob/main/content/docs/2.17/concepts/admission-webhooks.md

ok, thank you much

LGTM! Thanks for the improvement :)

Thank you much

@ctccxxd , please open another PR to docs adding the new check to the admission webhooks -> https://github.com/kedacore/keda-docs/blob/main/content/docs/2.17/concepts/admission-webhooks.md

done, https://github.com/kedacore/keda-docs/pull/1506, hope to review. Thank you.

/run-e2e internal
I saw a couple of internal tests fail with message.ScaleTargetNotFoundMsg, we should probably check if the tests are flaky or the error is valid
e.g.
    events_test.go:***:
        	Error Trace:	/__w/keda/keda/tests/internals/events/events_test.go:***     	            				/__w/keda/keda/tests/internals/events/events_test.go:***59    	            				/__w/keda/keda/tests/internals/events/events_test.go:***97
        	Error:      	Not equal:
        	            	expected: ""
        	            	actual  : "ScaledObjectCheckFailed:Target resource doesn't exist"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -*** +*** @@
        	            	-
        	            	+ScaledObjectCheckFailed:Target resource doesn't exist

ok, Thank you much

/run-e2e internal

@wozniakjan hello, I have revise the wrong test cases and test myself, and hope for your review, and e2e test, much thanks.

@wozniakjan @zroubalik hello, I have revise the wrong test cases and test myself. Hope for your review, and e2e test, much thanks.

/run-e2e internal

/run-e2e internal Update: You can check the progress here

azureeventgridtopic_test.go:9: --- test emitting eventsource about scaledobject err---
helper.go:54***: Applying template: scaledObjectTemplate
azureeventgridtopic_test.go:***57: --- waiting getMessage ---
azureeventgridtopic_test.go:***90:
Error Trace:	/__w/keda/keda/tests/internals/eventemitter/azureeventgridtopic/azureeventgridtopic_test.go:***90
/__w/keda/keda/tests/internals/eventemitter/azureeventgridtopic/azureeventgridtopic_test.go:97
/usr/local/go/src/runtime/asm_arm64.s:
Error:      	Should be true
Test:       	TestEventEmitter
This test case error seems is not related to my PR. Also because the value in .env need to be set. I can not run to test the case in my local PC.Please have a look at this. @SpiritZhou @JorTurFer