Feature request: Hooks for publishing and unpublishing pages

Hooks for publishing and unpublish pages
Today the only mechanism to act upon the Publish and Unpublish Page actions are Signals, but I don't think they are useful because:

You can only execute code after the action, not before
You don't have access to the request object

That said, I think we could use the Hooks mechanism to enable code execution before/after the publish/unpublish actions.
I created a small PR (#4591) to demonstrate how that could work. I didn't write any tests or documentation because I don't know if this interests the maintainers/users, but if so, I could improve the PR with that.
What do you think?
Cheers!

Thanks @jonatasbaldin! Happy with the principle of these hooks, but I think we need to be careful about how we specify and document their behaviour, since the 'publish' button on the edit page isn't the only point where a page might get published: it could be submitted for moderation and approved by a moderator, or it could be scheduled for publishing on a future date (in which case the actual publishing will happen from the publish_scheduled_pages management task, where there isn't a request object available at all).
(Also, if a page is 'published' from the edit page, but has a go-live date in the future, does that count as triggering the hook or not?)
Originally the before_edit_page / after_edit_page hooks were implemented as a way to modify the admin workflow: e.g. "if the user editing the page is in the 'restricted users' group, redirect them to a custom dashboard page instead of the standard explorer view". I think that's a useful guideline to stick to: anything related to the view / workflow level should be done with hooks, and anything at the model level (e.g. sending notifications, pushing the published pages to an external server...) should be done with signals.
If we're following that convention, then the behaviour as implemented in #4591 is mostly correct (but we should trigger the hook from the 'add' view as well as the 'edit' view). We should make this distinction clear in the documentation, though.

Hi @linxuanmax - please use the Wagtail tag on Stack Overflow for support queries.

Merged in via #6000


remove slayer drops

This PR does 3 things:

remove average drops
refactor slayer styles (using the grid for kills)
remove unused constants from stats.ejs

Before:

After:

Looks a little funky with the stuff being aligned towards the left, but not sure how you could make that better. Maybe only 3 columns so that the second row doesn't feel as empty?

Or maybe remove the total and center the t5 for revs?

Looks a little funky with the stuff being aligned towards the left, but not sure how you could make that better. Maybe only 3 columns so that the second row doesn't feel as empty?

My proposal was this but it was rejected

Huh. I like that better but it does still look kinda empty

I agree that I like dukio's proposal. At least the centering of the elements.

I think centering looks really weird when it has an even number in the top row and an odd in the button

so... what do we do?

so... what do we do?

I suggest merging it into master and if any further changes are approved, we can always open a new PR.

so... what do we do?

I suggest merging it into master and if any further changes are approved, we can always open a new PR.

Approve 👍


Switch to gp3 volume types and configurable I/O performance values

CI: IaC Security warnings found!

CI: IaC Security warnings found!

CI: IaC Security warnings found!

CI: IaC Security warnings found!


image/draw: increase performances by applying special case if mask is *image.Alpha

What version of Go are you using (go version)?

$ go version
go version devel go1.17-e4615ad74d Wed May 26 13:25:43 2021 +0000 darwin/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/olivierwulveryck/Library/Caches/go-build"
GOENV="/Users/olivierwulveryck/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/olivierwulveryck/GOPROJECTS/pkg/mod"
GONOPROXY="github.com/dktunited"
GONOSUMDB="github.com/dktunited"
GOOS="darwin"
GOPATH="/Users/olivierwulveryck/GOPROJECTS"
GOPRIVATE="github.com/dktunited"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/olivierwulveryck/dev/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/olivierwulveryck/dev/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.17-e4615ad74d Wed May 26 13:25:43 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/j3/t2_lsqzd5mgbv7tqvxg9ty5r0000gn/T/go-build4289980978=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
I am building a tool that is manipulating a lot of images. The process is a bit slow.
I made some performance analysis, and it appears that the drawRGBA method is really time-consuming.
Specially the call to mask.At(mx,my).RGBA()  is causing performance penalty.
I think that most of the use cases of DrawMask function are using an *image.Alpha structure as a mask. Therefore doing a special treatment if the mask is *image.Alpha could be valuable for most of the usage.
I made a simple test and bench for the drawRGBA method (it should be done for other methods as well).
func Benchmark_drawRGBA(b *testing.B) {
	r := image.Rect(0, 0, 500, 500)
	dst := image.NewRGBA(r)
	mask := image.NewAlpha(r)
	src := image.NewRGBA(r)
	for i := 0; i < b.N; i++ {
		drawRGBA(dst, r, src, image.Point{}, mask, image.Point{}, Over)
	}
}

Then I made a patch as an experiment:
diff --git a/src/image/draw/draw.go b/src/image/draw/draw.go
index 8f96aa2d18..205e8cfb43 100644
--- a/src/image/draw/draw.go
+++ b/src/image/draw/draw.go
@@ -530,7 +530,13 @@ func drawRGBA(dst *image.RGBA, r image.Rectangle, src image.Image, sp image.Poin
                for i, sx, mx := i0, sx0, mx0; sx != sx1; i, sx, mx = i+di, sx+dx, mx+dx {
                        ma := uint32(m)
                        if mask != nil {
-                               _, _, _, ma = mask.At(mx, my).RGBA()
+                               if mask, ok := mask.(*image.Alpha); ok {
+                                       off := mask.PixOffset(mx, my)
+                                       ma = uint32(mask.Pix[off])
+                                       ma |= ma << 8
+                               } else {
+                                       _, _, _, ma = mask.At(mx, my).RGBA()
+                               }
                        }
                        sr, sg, sb, sa := src.At(sx, sy).RGBA()
                        d := dst.Pix[i : i+4 : i+4] // Small cap improves performance, see https://golang.org/issue/27857

The performance enhancement is not negligible:
benchmark                 old ns/op     new ns/op     delta
Benchmark_drawRGBA-12     13178981      8599585       -34.75%

benchmark                 old allocs     new allocs     delta
Benchmark_drawRGBA-12     500000         250000         -50.00%

benchmark                 old bytes     new bytes     delta
Benchmark_drawRGBA-12     2025807       1016234       -49.84%

This is a test for opening the discussion, and I guess that other controls should be added as it makes some tests of the draw package fail. Specifically, the test.mask causes panic, and I cannot figure out what  test.mask is nor where it is defined.
What did you expect to see?
N/A
What did you see instead?
N/A

I'm open in principle to the change, with two comments.

Please be aware of the https://github.com/golang/go/wiki/Go-Release-Cycle
The right fix probably involves touching this switch statement (below) in func DrawMask, and probably involves writing a new func drawMaskOver function instead of tweaking the existing func drawRGBA function.

https://github.com/golang/go/blob/6ff0ae2aa4fdb9c6c267efb30927e87563387c49/src/image/draw/draw.go#L148

I thought about adding a private function to replace all the calls to img.At(x,y).RGBA().

We don't want to end up with a function call and type switch per pixel. Better to hoist it out of the loop, hence writing a new top-level function.
See also https://go-review.googlesource.com/c/go/+/311129 "image: add RGBA64Image interface".

I'd be interested in new "compare to the status quo" benchmark numbers now that "image/draw: add RGBA64Image fast path" https://go-review.googlesource.com/c/go/+/340049 has been submitted.
BTW the "delta" column in the tables from your earlier comment has no numbers.

I made a bench comparing the master branch (commit ab7c904bf2bb883b83001d8bb188d1809d74eee6)  (that holds the change you mention including the slowestRGBA struct), and the master branch with the change I made.

Thanks for the new numbers. I overlooked a code path in https://golang.org/cl/340049 which should be addressed by https://golang.org/cl/351852
Once 351852 lands, I'd be curious if you could re-run your benchmarks. I'll repeat that the "delta" column in your tables have no numbers, so it's hard to tell which rows I should focus on.

https://golang.org/cl/351852 has landed

Here are the results of my tests:
❯ cat ~/go.516d75ccf1.bench
goos: darwin
goarch: amd64
pkg: image/draw
cpu: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
BenchmarkFillOver-12           	    1240	    919849 ns/op	       0 B/op	       0 allocs/op
BenchmarkFillSrc-12            	   50834	     24552 ns/op	       0 B/op	       0 allocs/op
BenchmarkCopyOver-12           	    1705	    699634 ns/op	       0 B/op	       0 allocs/op
BenchmarkCopySrc-12            	   55306	     20768 ns/op	       0 B/op	       0 allocs/op
BenchmarkNRGBAOver-12          	    1422	    841424 ns/op	       0 B/op	       0 allocs/op
BenchmarkNRGBASrc-12           	    2649	    464700 ns/op	       0 B/op	       0 allocs/op
BenchmarkYCbCr-12              	    2835	    436423 ns/op	       0 B/op	       0 allocs/op
BenchmarkGray-12               	    8022	    152508 ns/op	       0 B/op	       0 allocs/op
BenchmarkCMYK-12               	    2582	    461211 ns/op	       0 B/op	       0 allocs/op
BenchmarkGlyphOver-12          	    5244	    228985 ns/op	       0 B/op	       0 allocs/op
BenchmarkRGBA1-12              	    1944	    611994 ns/op	       0 B/op	       0 allocs/op
BenchmarkRGBA2-12              	     746	   1626558 ns/op	       0 B/op	       0 allocs/op
BenchmarkPalettedFill-12       	  185510	      6629 ns/op	       0 B/op	       0 allocs/op
BenchmarkPalettedRGBA-12       	     771	   1607542 ns/op	      40 B/op	       2 allocs/op
BenchmarkGenericOver-12        	     745	   1711477 ns/op	       0 B/op	       0 allocs/op
BenchmarkGenericMaskOver-12    	    1329	   1115717 ns/op	       0 B/op	       0 allocs/op
BenchmarkGenericSrc-12         	    1329	    899930 ns/op	       0 B/op	       0 allocs/op
BenchmarkGenericMaskSrc-12     	     982	   1181788 ns/op	       0 B/op	       0 allocs/op
Benchmark_drawRGBA-12          	     355	   3524321 ns/op	    6392 B/op	       0 allocs/op
Benchmark_drawRGBAGray-12      	     432	   2776462 ns/op	    3508 B/op	       0 allocs/op
PASS
ok  	image/draw	28.130s

❯ cat ~/go.25a0774.bench
goos: darwin
goarch: amd64
pkg: image/draw
cpu: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
BenchmarkFillOver-12           	    1226	    937482 ns/op	       0 B/op	       0 allocs/op
BenchmarkFillSrc-12            	   50300	     24057 ns/op	       0 B/op	       0 allocs/op
BenchmarkCopyOver-12           	    1728	    688587 ns/op	       0 B/op	       0 allocs/op
BenchmarkCopySrc-12            	   56661	     21351 ns/op	       0 B/op	       0 allocs/op
BenchmarkNRGBAOver-12          	    1413	    844938 ns/op	       0 B/op	       0 allocs/op
BenchmarkNRGBASrc-12           	    2599	    459764 ns/op	       0 B/op	       0 allocs/op
BenchmarkYCbCr-12              	    2786	    425523 ns/op	       0 B/op	       0 allocs/op
BenchmarkGray-12               	    8143	    147877 ns/op	       0 B/op	       0 allocs/op
BenchmarkCMYK-12               	    2365	    469891 ns/op	       0 B/op	       0 allocs/op
BenchmarkGlyphOver-12          	    4761	    233635 ns/op	       0 B/op	       0 allocs/op
BenchmarkRGBA1-12              	    1956	    604964 ns/op	       0 B/op	       0 allocs/op
BenchmarkRGBA2-12              	    1064	   1131638 ns/op	       0 B/op	       0 allocs/op
BenchmarkPalettedFill-12       	  182772	      6491 ns/op	       0 B/op	       0 allocs/op
BenchmarkPalettedRGBA-12       	     786	   1536837 ns/op	      40 B/op	       2 allocs/op
BenchmarkGenericOver-12        	     775	   1532559 ns/op	       0 B/op	       0 allocs/op
BenchmarkGenericMaskOver-12    	    1360	    884728 ns/op	       0 B/op	       0 allocs/op
BenchmarkGenericSrc-12         	    1386	    868615 ns/op	       0 B/op	       0 allocs/op
BenchmarkGenericMaskSrc-12     	    1164	   1060872 ns/op	       0 B/op	       0 allocs/op
Benchmark_drawRGBA-12          	     500	   2335115 ns/op	    4538 B/op	       0 allocs/op
Benchmark_drawRGBAGray-12      	    1375	    882834 ns/op	    1102 B/op	       0 allocs/op
PASS
ok  	image/draw	26.094s

❯ benchstat -delta-test none ~/go.516d75ccf1.bench ~/go.25a0774.bench
name                old time/op    new time/op    delta
FillOver-12            920µs ± 0%     937µs ± 0%   +1.92%
FillSrc-12            24.6µs ± 0%    24.1µs ± 0%   -2.02%
CopyOver-12            700µs ± 0%     689µs ± 0%   -1.58%
CopySrc-12            20.8µs ± 0%    21.4µs ± 0%   +2.81%
NRGBAOver-12           841µs ± 0%     845µs ± 0%   +0.42%
NRGBASrc-12            465µs ± 0%     460µs ± 0%   -1.06%
YCbCr-12               436µs ± 0%     426µs ± 0%   -2.50%
Gray-12                153µs ± 0%     148µs ± 0%   -3.04%
CMYK-12                461µs ± 0%     470µs ± 0%   +1.88%
GlyphOver-12           229µs ± 0%     234µs ± 0%   +2.03%
RGBA1-12               612µs ± 0%     605µs ± 0%   -1.15%
RGBA2-12              1.63ms ± 0%    1.13ms ± 0%  -30.43%
PalettedFill-12       6.63µs ± 0%    6.49µs ± 0%   -2.08%
PalettedRGBA-12       1.61ms ± 0%    1.54ms ± 0%   -4.40%
GenericOver-12        1.71ms ± 0%    1.53ms ± 0%  -10.45%
GenericMaskOver-12    1.12ms ± 0%    0.88ms ± 0%  -20.70%
GenericSrc-12          900µs ± 0%     869µs ± 0%   -3.48%
GenericMaskSrc-12     1.18ms ± 0%    1.06ms ± 0%  -10.23%
_drawRGBA-12          3.52ms ± 0%    2.34ms ± 0%  -33.74%
_drawRGBAGray-12      2.78ms ± 0%    0.88ms ± 0%  -68.20%

name                old alloc/op   new alloc/op   delta
FillOver-12            0.00B          0.00B         0.00%
FillSrc-12             0.00B          0.00B         0.00%
CopyOver-12            0.00B          0.00B         0.00%
CopySrc-12             0.00B          0.00B         0.00%
NRGBAOver-12           0.00B          0.00B         0.00%
NRGBASrc-12            0.00B          0.00B         0.00%
YCbCr-12               0.00B          0.00B         0.00%
Gray-12                0.00B          0.00B         0.00%
CMYK-12                0.00B          0.00B         0.00%
GlyphOver-12           0.00B          0.00B         0.00%
RGBA1-12               0.00B          0.00B         0.00%
RGBA2-12               0.00B          0.00B         0.00%
PalettedFill-12        0.00B          0.00B         0.00%
PalettedRGBA-12        40.0B ± 0%     40.0B ± 0%    0.00%
GenericOver-12         0.00B          0.00B         0.00%
GenericMaskOver-12     0.00B          0.00B         0.00%
GenericSrc-12          0.00B          0.00B         0.00%
GenericMaskSrc-12      0.00B          0.00B         0.00%
_drawRGBA-12          6.39kB ± 0%    4.54kB ± 0%  -29.01%
_drawRGBAGray-12      3.51kB ± 0%    1.10kB ± 0%  -68.59%

name                old allocs/op  new allocs/op  delta
FillOver-12             0.00           0.00         0.00%
FillSrc-12              0.00           0.00         0.00%
CopyOver-12             0.00           0.00         0.00%
CopySrc-12              0.00           0.00         0.00%
NRGBAOver-12            0.00           0.00         0.00%
NRGBASrc-12             0.00           0.00         0.00%
YCbCr-12                0.00           0.00         0.00%
Gray-12                 0.00           0.00         0.00%
CMYK-12                 0.00           0.00         0.00%
GlyphOver-12            0.00           0.00         0.00%
RGBA1-12                0.00           0.00         0.00%
RGBA2-12                0.00           0.00         0.00%
PalettedFill-12         0.00           0.00         0.00%
PalettedRGBA-12         2.00 ± 0%      2.00 ± 0%    0.00%
GenericOver-12          0.00           0.00         0.00%
GenericMaskOver-12      0.00           0.00         0.00%
GenericSrc-12           0.00           0.00         0.00%
GenericMaskSrc-12       0.00           0.00         0.00%
_drawRGBA-12            0.00           0.00         0.00%
_drawRGBAGray-12        0.00           0.00         0.00%


fix(inputdropdown): stop console warnings about sdsStyle on buttons w…

Summary

What: forward sdsStyle prop from InputDropdown
Why: InputDropdown renders a button, which expects an sdsStyle prop

Demos
Before:

After:
None!
Checklist

[x] I merged latest main
[x] I manually verified the change
[x] I added labels to my PR
[ ] Default Story in Storybook
[ ] LivePreview Story in Storybook
[ ] Test Story in Storybook
[ ] Tests written
[ ] Variables from defaultTheme.ts used wherever possible
[ ] If updating an existing component, depreciate flag has been used where necessary
[ ] Chromatic build verified by @chanzuckerberg/sds-design

Just saw #140 tackles this already!


Heroku

Deploys are so in right now. Let's make sure we can do that and stuff

Coverage remained the same at 100.0% when pulling 89813333d7af49eac83fda84df5adcf5a602e00c on heroku into 33e50ec2c4a06e4c61126c626d66a879799b4e23 on rails.

Coverage remained the same at 100.0% when pulling 1216e2104e9648317e0546bced32e02da3d1a9ea on heroku into 33e50ec2c4a06e4c61126c626d66a879799b4e23 on rails.

Coverage remained the same at 100.0% when pulling 17f82765b5a917c0d22053fd90a9c809cffd1860 on heroku into 33e50ec2c4a06e4c61126c626d66a879799b4e23 on rails.


[bug] Dialog back button

Version: <IP_ADDRESS>
Mods: CBA, TFAR
Environment: MP dedicated
.rpt attatched? No
have you edited the missionfile?: Yes (add TFAR system only)
Issue:

Press Y key to open 'Battle Options' dialog
Press 'Garage Vehicle' button to open 'Personal of Faction Garage?' dialog
Press 'Back' button to return back...hm...what a?!

I guess the actions need to be exchanged in lines 1242, 1580, 1704 in dialogs.hpp to this:
action = "closeDialog 0;nul = createDialog ""radio_comm"";";

thanks! will check it


Proper label and input ids for checkbox and radios with non-sanitized values

Before now label ids and input ids for checkbox and radios inputs were messed of unsanitized option values and sanitized values, that was a nightmare if you had some punctuation or non-latin symbols in options.
This commit fixes it.
It looks a little tricky, but I don't see a more simple and cleaner way without including something like simple_form.

Thanks for this PR @sandrew I have rebased and pushed to master.


retry parameter in volume.fix.replication is not respected when waiting for copied volume to show up

Seems like the logic of https://github.com/chrislusf/seaweedfs/blob/master/weed/shell/command_volume_fix_replication.go#L154 should be reversed? It should retry until the counter is larger than retryCount, not the other way around.

thanks!


Cannot authenticate

I tried authentication by GUI and script but no luck. My OpenSSL version is newer:
Current Version Information:
Python  : 3.11.6
OpenSSL : 3.0.11
gkeepapi: 0.14.2
urllib3 : 1.26.18
gpsoauth: 1.0.2
requests: 2.31.0
ERROR:root:Failed to login to Google Keep: ('BadAuthentication', None)
Authentication failed. Please try again with the known working versions:
Python  : 3.11.4
OpenSSL : 1.1.1n
gkeepapi: 0.14.2
urllib3 : 1.26.18
gpsoauth: 1.0.2
requests: 2.31.0

Same for me!

Same for me:
Current Version Information:
Python  : 3.11.2
OpenSSL : 3.0.11
gkeepapi: 0.14.2
urllib3 : 1.26.18
gpsoauth: 1.0.2
requests: 2.28.1
I got a bit further to run the pip install as sudo, but still no token and got the same error

OpenSSL 3 will not work. This is a known issue with gpsoauth, not with this integration.
Please use the "Generating a Token Using a Docker Container" instructions from the Readme, other people have had better luck with that.

Sad to see that you have closed it... I think you need to specific write either here and/or in your requirement.txt what version of openssl to use, writing that ver 3 doesnt work dont help us very much
Sure i can pull a docker in my VM, but all have this option...

I Don't have a Docker So I Can't use this one 🤥

I just triede the docker version, still no token, i triede with 2 Gmail account, 1 with 2fa and 1 without, Them OpenSSL In the docker is 1.1.1w, i triede to downgrade to 1.1.1n, still no luck…Venlig hilsen/Best Regards,Jan LarsenDen 20. jan. 2024 kl. 11.27 skrev BernieV1977 @.***>:
I Don't have a Docker So I Can't use this one 🤥
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

I Don't have a Docker So I Can't use this one 🤥

@BernieV1977 I can send it too you, but off course that means that i need your info, but you can always change the password afterwards... And only would trust me with these sensitive information... Github has no way to send messages to other users, but here in my link to my Facebook messenger

This issue is not something I can fix directly, it is an issue within another library, gpsoauth.
Right now there are the following options:

Install docker and use the docker container to get a token.
Wait until the issue is fixed within gpsoauth, or another means to get a token is implemented.

Please do not solicit passwords from other people here.


Fix loading of illustration in connection modal

We are trying to modify the photo on this modal, but we didn't find any documentation is there anyway of doing this?

We are trying to modify the photo on this modal, but we didn't find any documentation is there anyway of doing this?

This is an illustration specific to the Hiro Wallet. No, it can't be changed unless you fork this repo. It is not something we support/document.

@nokhodian Do you want to change the illustration itself or the app icon to the bottom-right corner of the illustration?
Illustration

App icon

If the app icon, you can pass the URL for it during authentication with Connect.

@fbwoolf what remains to standardize these days with the intro modal here? Should we keep this issue open and modify it to capture the remaining work more specifically, or close out?

@nokhodian Do you want to change the illustration itself or the app icon to the bottom-right corner of the illustration?
Illustration

App icon

If the app icon, you can pass the URL for it during authentication with Connect.

The problem was that no image was showing up and we couldn't modify the path, the only solution was statically putting the image where it was hardcoded, we ended up implementing the whole modal at our side though :)

The problem was that no image was showing up and we couldn't modify the path

Sorry I'm still not clear on which image wasn't showing up exactly. Do you mean the app icon or illustration or both?

we ended up implementing the whole modal at our side though :)

Did you fork the library or create a new custom modal out of curiosity?

that's what the modal looks like, we are making a new custom modal, still, it's not done though

Thanks for the screenshot for clarification 🙏  If you right click on the broken image, can you copy and paste the URL that's attempted for loading here?

@markmhx this is outdated. The illustration in Connect has been updated and no longer includes the app icon.

Thanks for the screenshot for clarification 🙏 If you right-click on the broken image, can you copy and paste the URL that's attempted for loading here?

sure,,,, /assets/download-hiro-wallet.png ... that's the image and if you statically put an image there it will show up, however, we didn't want to compromise on the structure of our project.

Thanks! By "we didn't want to compromise on the structure of our project", what do you mean exactly?

Thanks! By "we didn't want to compromise on the structure of our project", what do you mean exactly?

we didn't want to add a folder and file exactly like its defined, we have another folder for static resources

I feel like this was reported as a separate bug regarding the app icon, but now there is a different bug with the png being used for the new illustration. Just wanting to make note of that bc when this issue was created in October  /assets/download-hiro-wallet.png did not exist. I can def look into fixing why the new png isn't loading.

Nvm, I read back through the thread here. I see the thread is a bit confusing ...but this is def a bug with the new png illustration, so I'll fix it.

@markmhx is this something I should take on today and get fixed?

There seem to be a few open issues in stenciljs regarding the getAssetPath and setAssetPath not working. It doesn't seem like a great library to use considering these issues have been open for quite some time. I've tried suggested workarounds today, but no luck. We would need to instruct the app to copy the assets in their webpack config (I think) if we want to use pngs. @kyranjamie any thoughts?
https://github.com/ionic-team/stencil/issues/2269
https://github.com/ionic-team/stencil/issues/1868

I'm not super familiar with this problem, but indeed these issues look very stale.
I would try either:

Adding a Webpack loader the same as we use in the web wallet
Inlining the png image as a data uri directly


Vim splits resize when switching windows in fullscreen mode

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit 63e3668529f6c06478ec288723d0ba46374c4bc5 dirty (style: run clang-format). Date: Mon Apr 8 16:33:02 2024 Tag: v0.38.0-73-g63e36685, commits: 4406 flags: (if any) System Information: System name: Linux Node name: archlinux Release: 6.8.4-arch1-1 Version: #1 SMP PREEMPT_DYNAMIC Fri, 05 Apr 2024 00:14:23 +0000 GPU information: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] [1002:747e] (rev ff) (prog-if 00 [VGA controller]) 12:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev ca) (prog-if 00 [VGA controller]) os-release: NAME="Arch Linux" PRETTY_NAME="Arch Linux" ID=arch BUILD_ID=rolling ANSI_COLOR="38;2;23;147;209" HOME_URL="https://archlinux.org/" DOCUMENTATION_URL="https://wiki.archlinux.org/" SUPPORT_URL="https://bbs.archlinux.org/" BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues" PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/" LOGO=archlinux-logo plugins:

Bug or Regression?
Bug
Description
https://github.com/hyprwm/Hyprland/assets/165161791/c93ceac8-3ed6-4975-888b-a653b6fe9b64
Switching between windows in fullscreen mode alters the size of splits in vim.
Terminal: Alacritty Version 0.13.2
How to reproduce
Workflow:

Open two terminals
Open vim in one of the terminals and create two vertical splits (Ctrl-w + v)
Switch to fulscreen mode (bind = SUPER, M, fullscreen, 1)
Switch to the second window
Switch back to the terminal with vim -> Size of the splits will be altered

Crash reports, logs, images, videos
No response

does it happen on kitty or foot, for example?

@MightyPlaza Yes, I've managed to reproduce this issue with both kitty and foot

that's because once you shift fullscreen, the window is resized back to its tiled size.
P much #683


Server reconfiguration admin onboarding

Implement a process where CadenceBot joins a new server and identifies an initial server admin if none is set. This is probably as simple as 'Make the owner admin and generate a message about it'.
Consider also ensuring that at least one server admin exists at all times - This prevents onboarding from occurring a second time for the server when the bot restarts.

@kenellorando in keeping with discussion on #45, ideas:

Onboarding should, if we follow through with this, set a super admin. Simply put, that's what's necessary to have the ability to really administrate the server without help from the instance admin to do so, which is the goal of this task.
This current design only supports triggering onboarding if two conditions are simultaneously satisfied:

CadenceBot is in a startup mode for this server. This means either:

The CadenceBot instance is restarting; or
CadenceBot has been newly added to the server

The server has no (super) admins.

Would it make sense to add a command like Cadence admin onboard to erase the admin list and trigger the flow as well? This can either be instance-admin-only (To save them the trouble of doing so manually) or super-admin-only (As a nuclear option to clean the admin list - This probably requires a confirmation step). Of course, this is probably not a common enough concern to merit either - The second part of this issue, which I want to include, implies that the only way we can require a re-onboard of an existing system is to have the last superadmin leave the server/AFK forever - They won't be allowed to retire unless they nominate a second superadmin first. And I cannot imagine why one would be nuking the admin list, unless one is very disgruntled or one is the last superadmin wishing to retire and wanting to nominate another admin without caring who (Hopefully this person is not the one onboarding is going to nominate). I don't see that as being valuable...
So 2 is probably only a reasonable idea for an instance-admin-only command - Essentially, its scripted disaster recovery.
Thoughts?


Error generating ffjson files.

Hi, i'm getting the following error when trying to generate the ffjson intermediate files.
Error: error=Could not find source directory: GOPATH=["/Users/miguelangelortunoortuno/golang"] REL="/Users/miguelangelortunoortuno/golang" path="":
Any help?
Thank you!

Getting this error now... :(
Error: Go Run Failed for: /var/folders/_s/_kjy0pds16z44fwd6f498gdr0000gn/T/ffjson-inception359608853.go
STDOUT:
STDERR:
/var/folders/_s/_kjy0pds16z44fwd6f498gdr0000gn/T/ffjson-inception359608853.go:8:2: import "github.com/Hooks-Alerts/mercury" is a program, not an importable package

Duplicate of https://github.com/pquerna/ffjson/issues/157 -- main packages aren't currently supported, because the method we use to extract structs can't be used.


[Question] Display definition

https://github.com/gkv311/occt-hello/blob/ee542b8f3ccd631de686ebbb2fe193453d6754db/occt-ais-hello/OcctAisHello.cpp#L171
Where is Display defined in the API? I'm not finding it.

'Display' belongs to X11.
https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html#display_functions

Thanks for this. I am closing the question, but I will probably open another one more general in order to avoid bothering you with many issues.


Segfault on ARM when using log collection, possibly SSL related

ssm-user@raspberrypi:~/datadog-agent/bin $ sudo ./agent/agent run
2019-06-07 14:24:48 BST | CORE | INFO | (pkg/util/log/log.go:473 in func1) | config.Load()
2019-06-07 14:24:48 BST | CORE | INFO | (pkg/util/log/log.go:473 in func1) | config.load succeeded
2019-06-07 14:24:48 BST | CORE | INFO | (cmd/agent/app/start.go:123 in StartAgent) | Starting Datadog Agent v6.11.3+git.2.fa37351
2019-06-07 14:24:49 BST | CORE | INFO | (cmd/agent/app/start.go:151 in StartAgent) | Hostname is: raspberrypi
2019-06-07 14:24:54 BST | CORE | INFO | (cmd/agent/app/start.go:170 in StartAgent) | GUI server port -1 specified: not starting the GUI.
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/forwarder/forwarder.go:154 in Start) | Forwarder started, sending to 1 endpoint(s) with 1 worker(s) each: "https://6-11-3-app.agent.datadoghq.com" (1 api key(s))
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/dogstatsd/listeners/udp.go:77 in Listen) | dogstatsd-udp: starting to listen on <IP_ADDRESS>:8125
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/logs/input/container/launcher.go:27 in NewLauncher) | Trying to initialize kubernetes launcher
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/logs/input/container/launcher.go:30 in NewLauncher) | Kubernetes launcher initialized
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/logs/logs.go:72 in Start) | Starting logs-agent...
2019-06-07 14:24:54 BST | CORE | ERROR | (pkg/logs/auditor/auditor.go:159 in recoverRegistry) | open /opt/datadog-agent/run/registry.json: no such file or directory
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/logs/logs.go:75 in Start) | logs-agent started
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/tagger/tagger.go:82 in Init) | starting the tagging system
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/runner/runner.go:95 in NewRunner) | Runner started with 4 workers.
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/autodiscovery/providers/file.go:70 in Collect) | file: searching for configuration files at: /etc/datadog-agent/conf.d
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/autodiscovery/providers/file.go:70 in Collect) | file: searching for configuration files at: /home/ssm-user/datadog-agent/bin/agent/dist/conf.d
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/autodiscovery/providers/file.go:70 in Collect) | file: searching for configuration files at:
2019-06-07 14:24:54 BST | CORE | WARN | (pkg/autodiscovery/providers/file.go:74 in Collect) | Skipping, open : no such file or directory
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/logs/scheduler/scheduler.go:52 in Schedule) | Received a new logs config: idexx-pi
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/logs/input/file/tailer.go:120 in setup) | Opening  /var/log/syslog
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check cpu
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check cpu with an interval of 15s
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check disk
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check disk with an interval of 15s
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check io
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check io with an interval of 15s
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check load
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check load with an interval of 15s
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check memory
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check memory with an interval of 15s
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check network
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check network with an interval of 15s
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check ntp
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check ntp with an interval of 15s
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler.go:63 in Schedule) | Scheduling check uptime
2019-06-07 14:24:54 BST | CORE | INFO | (pkg/collector/scheduler/scheduler.go:76 in Enter) | Scheduling check uptime with an interval of 15s
2019-06-07 14:24:55 BST | CORE | WARN | (pkg/logs/auditor/auditor.go:145 in func2) | open /opt/datadog-agent/run/registry.json: no such file or directory
2019-06-07 14:24:55 BST | CORE | INFO | (pkg/collector/runner/runner.go:264 in work) | Running check cpu
2019-06-07 14:24:55 BST | CORE | INFO | (pkg/collector/runner/runner.go:330 in work) | Done running check cpu
2019-06-07 14:24:56 BST | CORE | INFO | (pkg/serializer/serializer.go:274 in SendMetadata) | Sent host metadata payload, size (raw/compressed): 3411/1585 bytes.
2019-06-07 14:24:56 BST | CORE | INFO | (pkg/forwarder/transaction.go:193 in Process) | Successfully posted payload to "https://6-11-3-app.agent.datadoghq.com/intake/?api_key=*************************77357", the agent will only log transaction success every 20 transactions
2019-06-07 14:24:59 BST | CORE | INFO | (pkg/collector/runner/runner.go:264 in work) | Running check uptime
2019-06-07 14:24:59 BST | CORE | INFO | (pkg/collector/runner/runner.go:330 in work) | Done running check uptime
2019-06-07 14:25:00 BST | CORE | INFO | (pkg/collector/runner/runner.go:264 in work) | Running check network
2019-06-07 14:25:00 BST | CORE | INFO | (pkg/collector/runner/runner.go:330 in work) | Done running check network
2019-06-07 14:25:01 BST | CORE | INFO | (pkg/collector/runner/runner.go:264 in work) | Running check load
2019-06-07 14:25:01 BST | CORE | INFO | (pkg/collector/runner/runner.go:330 in work) | Done running check load
2019-06-07 14:25:02 BST | CORE | INFO | (pkg/logs/client/connection_manager.go:55 in func1) | Connecting to the backend: agent-intake.logs.datadoghq.com:10516, with SSL: true
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x11a50]

goroutine 61 [running]:
runtime/internal/atomic.goXadd64(0x18224f4, 0x69, 0x0, 0x57a1e8, 0x1d1e501)
        /usr/local/go/src/runtime/internal/atomic/atomic_arm.go:96 +0x1c
github.com/DataDog/datadog-agent/pkg/logs/input/file.(*Tailer).incrementReadOffset(0x18224d0, 0x69)
        /home/ubuntu/golang/src/github.com/DataDog/datadog-agent/pkg/logs/input/file/tailer.go:236 +0x34
github.com/DataDog/datadog-agent/pkg/logs/input/file.(*Tailer).readForever(0x18224d0)
        /home/ubuntu/golang/src/github.com/DataDog/datadog-agent/pkg/logs/input/file/tailer.go:168 +0x17c
created by github.com/DataDog/datadog-agent/pkg/logs/input/file.(*Tailer).Start
        /home/ubuntu/golang/src/github.com/DataDog/datadog-agent/pkg/logs/input/file/tailer.go:105 +0x110

Attempting to run agent on raspberry pi with log collection fails. This is possibly related to SSL as our network policy uses a custom SSL certificate for all SSL transactions. Seems like a DataDog bug as collection works fine for other metrics.
uname -a from my environment:
Linux raspberrypi 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux
Log collection configuration file. Agent runs with no problems if this is not here:
logs:
  - type: file
    path: /var/log/syslog
    service: idexx-pi-syslog
    source: custom

Follow up: I think arm7 is 32-bit.
readOffset in
https://github.com/DataDog/datadog-agent/blob/master/pkg/logs/input/file/tailer.go
is an int64. Could the atomic increment operation be causing the seg fault?

May be applicable:
From:
https://godoc.org/sync/atomic
Bugs:
On x86-32, the 64-bit functions use instructions unavailable before the Pentium MMX. On non-Linux ARM, the 64-bit functions use instructions unavailable before the ARMv6k core. On ARM, x86-32, and 32-bit MIPS, it is the caller's responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned.

Or this might be a double pointer dereference ... I think there's a dereference for the atomic increment and then atomic itself does a dereference.

Could be this:
https://github.com/golang/go/issues/23345

https://github.com/DataDog/datadog-agent/pull/3672

Hello @cgorski-idexx ,
Thanks a lot for submitting this and doing the PR as well.
We will definitely review it and make sure it is merged as soon as possible.
Thanks again for your contribution.


Process Redocly's Extensions

https://redoc.ly/docs/api-reference-docs/vendor-extensions/redoc-supported-extensions/

Hi, Kin. That link seems to be broken.
Maybe the link below can replace it.
Best!
https://redocly.com/docs/redoc/redoc-vendor-extensions/#redoc-vendor-extensions


Stopped working on Araxxor

Noticed in the last couple days this plugin has stopped working at Araxxor.  Still works fine on other monsters though.
Still working on Araxytes:

Not working on Araxxor for mouse-over or tagged

Try enabling "Show for Friendly NPCs" for now.
Bosses don't seem to deliver their health bars in the same way as regular NPCs, so I can't detect them as hostile.

I made several changes for v1.3 that will hopefully fix this and other oddities.
However, I don't have the slayer level for Araxxor, so let me know.
PR is here:
https://github.com/runelite/plugin-hub/pull/6578
Usually takes a few days to hit the plugin hub.

Realized I could just go visit Araxxor without the reqs.
Seems to be working now!


Chore: Update Policy for Campaign

PT link
https://www.pivotaltracker.com/story/show/160445134
Tasks

Add authorize @campaign to edit, update, create
Update policy spec
Update campaign policy with edit

Pull Request Test Coverage Report for Build 5

12 of 12 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+2.4%) to 89.338%

Totals

Change from base Build 47:
2.4%

Covered Lines:
243

Relevant Lines:
272

💛  - Coveralls


(Client/alt): fix isTextureExistInArchetype 2nd param name

In order not to mislead the script developers and to match the cpp-sdk
https://github.com/altmp/cpp-sdk/blob/eee1380f901c0650595d3298d15ef9e734650bd8/ICore.h#L157

Thanks for contribution


Merge upstream

Most importantly, this improves separation between core and client logic, but it is still a work in progress.

Superseded by #68


Add a Dockerfile for easier development

Copied from https://github.com/tomaka/rust-android-docker
I created this PR to let hub.docker.com build the image, which is going to go much faster than if I do it with my aweful Internet connection.
To do before merging:

[ ] Update the README to show usage.
[ ] Compile cargo-apk from the github repo instead of the published version.

Link: https://hub.docker.com/r/tomaka/android-rs-glue/

Apparently it's impossible to put a docker file in its own directory with hub.docker.com. It'll need to live at the root of the repo.


Allow users to modify curl options in plugins

we don't want users to even be able to override CURLOPT_HEADERFUNCTION and CURLOPT_WRITEFUNCTION thought as that's all this is doing


@swc/wasm-typescript transform mode should no perform import elision

Describe the bug
Consider this code:
Input code
const { test } = require("node:test");
// replace "../dist/index.js" with "@swc/wasm-typescript"
const { transformSync } = require("../dist/index.js");
const assert = require("node:assert");

test("should not perform code elision", (t) => {
    const inputCode = `
	import { foo } from ".";
	export { };
  `;
    assert.strictEqual(transformSync(inputCode, { mode: "transform" }).code, "export { };\n");
});

Expected behavior
even if import { foo } from "."; is unused, it should not be removed, since it will change how nodejs handles it.
The same JavaScript code will throw an error.
Actual behavior
unused import is removed
Version
1.7.9
Additional context
No response

It aligns with TypeScript's behavior, where imports not used as values are considered type imports.
If you wish to retain it, you should activate the verbatimModuleSyntax mode; please refer to this:
https://github.com/swc-project/swc/blob/4b5875099be8b01adeeac9156e01e2b450c0e73a/crates/swc_fast_ts_strip/src/lib.rs#L40-L69

Try this:
const { test } = require("node:test");
const { transformSync } = require("@swc/wasm-typescript");
const assert = require("node:assert");

test("should not perform code elision", (t) => {
    const inputCode = `
	import { foo } from ".";
	export { };
  `;
    assert.strictEqual(
        transformSync(inputCode, {
            mode: "transform", "transform": {
                verbatimModuleSyntax: true,
            }
        }).code,
        `import { foo } from ".";
export { };
`
    );
});

test("should preserve import statements with side effects", (t) => {
    const inputCode = `
	import { foo } from ".";
	export { };
  `;
    assert.strictEqual(
        transformSync(inputCode, {
            mode: "transform", "transform": {
                importNotUsedAsValues: "preserve",
            }
        }).code,
        `import ".";
`
    );
});


[Concurrency] Handle more expr types for inout checking

This patch fixes a compiler crash when optional values were being unwrapped and passed to a function. The crash was caused because diagnoseInOutArg could only handle LookupExpr and DeclRefExpr. This patch adds code to unwrap more kinds of expressions.
I've introduced a new static function, getInoutTopExpr , which walks through the expression types it knows about down to what is hopefully either a LookupExpr or a DeclRefExpr, from which we can pull the correct ValueDecl.
If we hit an InOutExpr sub-expression while traversing, we just return a nullptr and jump out of the diagnostic. If we don't do this, we will get duplicate error messages emitted since it appears to get re-checked. The duplicate error messages show up on await modifyAsynchronously(&points[0].x) and await modifyAsynchronously(&points[0].z!).
Fixes: rdar://72906215

@swift-ci smoke test please

@swift-ci smoke test please

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test windows

@swift-ci please smoke test windows

@swift-ci please smoke test windows platform

@swift-ci please smoke test windows platform

Like Doug, I do wonder what other expression forms might be missing, but this is good as-is.
What happens with other kinds of operators, e.g., function application, unary negation, addition, and the conditional ternary operator ? :? Can they be used inside of an in-out argument expression? (I don't know the normal restrictions on in-out)

I agree on the issue with other expressions. I've tested what I know how to hit and can be passed inout, which is certainly not exhaustive. Ternary operators only return non-mutable results, so it can't be passed inout.
I've kind of started going through the list of Expr types that inherit directly from Expr and handling those, where I know how to get a test case.
From that I'm missing the following expression types (as defined in Expr.h):

ErrorExpr -- Maybe we should propagate that up instead of exploding. Would probably be good.
CodeCompletionExpr -- no idea how to get one of these injected into an AST
LiteralExpr -- Literals are not mutable
TapExpr -- Not entirely sure what this is, or how it would get injected into the AST as a paramter
DiscardAssignmentExpr -- Can only appear on left side of an assignment
SuperRefExpr -- Not sure how you'd get one of these as part of an inout parameter
TypeExpr -- Not sure how to get one of these as part of an inout parameter
OtherConstructorDeclRefExpr -- Not sure how it would be a part of a valid inout parameter
OverloadSetRefExpr -- ??? Not sure what this is.
UnresolvedDeclRefExpr -- Not sure how to get one in Swift, though maybe it's possible?
UnresolvedMemberExpr -- Not sure how to get one in swift, though maybe it's possible?
AnyTryExpr -- Results from a function aren't mutable, I'm not sure how else you might use try.
IdentityExpr -- ??? Not sure what this is. self is immutable passed directly. Might want to handle ParenExprs like in myFunc(&(foo)) or AwaitExpr, though is the result of an AwaitExpr mutable?
TupleExpr -- TupleExpr's aren't mutable myFunc(&(1,2,3)) isn't legal.
CollectionExpr -- ??? Seems like it's either a ParenExpr or TupleExpr, but not totally clear.
KeyPathApplicationExpr -- ??? Not sure what this is.
UnresolvedDotExpr -- ??? Need to figure out how to get unresolved types to test this
TupleElementExpr -- This should only be a sub-expression of a TupleExpr, which is already illegal.
OptionalEvaluaionExpr -- Something like foo.bar?(), which would not be mutable since it's the result of a function call
MakeTemporarilyEscapableExpr -- ??? Not sure.
OpenExistentialExpr -- ???
UnresolvedSpcializeExpr -- ???
VarargExpansionExpr -- Comment says it's not surfaced. Probably don't need?
SequenceExpr -- ???
AbstractClosureExpr -- I don't think we can pass one of these inout?
CaptureListExpr -- Pretty sure this can't be passed inout
DynamicTypeExpr -- Pretty sure this can't be passed inout.
OpaqueValueRef -- I'm not sure how to get one of these in the AST, but we might want to handle passing it?
PropertyWrapperValuePlaceholderExpr -- ??? I'm pretty sure this can't appear as part of the inout parameter subtree.
DefaultArgumentExpr -- Also probably can't be part of an inout parameter subtree.
ApplyExpr -- Can't be pass inout since the result of an application is not mutable
DotSyntaxBaseIgnoredExpr -- ???
ExplicitCastExpr -- Result is not mutable, can't be passed inout.
ArrowExpr -- Goes on function decls, not sure how it would be passed as part of a parameter
RebindSelfInConstructorExpr -- ??? Not sure what this is for
IfExpr -- ternary and friends are not mutable
EnumIsCaseExpr -- ?? Not sure what this is, but It sounds like it would not be mutable.
AssignExpr -- Immutable
UnresolvedPatternExpr -- ??? Not sure how to get one of these
EditorPlaceholderExpr -- Not sure how to get one of these
LazyInitializerExpr -- Not sure how to get one of these
ObjcSelectorExpr -- I'm not familiar with this one? Can it return stuff?
KeyPathExpr -- Not familiar with this one. Looks like the return value is immutable.
KeyPathDotExpr -- ??
OneWayExpr -- ??

I definitely need to add a clause for ParenExpr, but otherwise I haven't seen the other expression types type-check far enough to cause the crash. If we wanted to weaken the check, I could make the else-clause return a nullptr which would skip out early on unknown expression types. I'm hesitant to do this since we could potentially accept buggy code for one version, then add the missing clause to the check and make a source-breaking change. Thoughts?

Like Doug, I do wonder what other expression forms might be missing, but this is good as-is.
What happens with other kinds of operators, e.g., function application, unary negation, addition, and the conditional ternary operator ? :? Can they be used inside of an in-out argument expression? (I don't know the normal restrictions on in-out)

I agree on the issue with other expressions. I've tested what I know how to hit and can be passed inout, which is certainly not exhaustive. Ternary operators only return non-mutable results, so it can't be passed inout.
I've kind of started going through the list of Expr types that inherit directly from Expr and handling those, where I know how to get a test case.
From that I'm missing the following expression types (as defined in Expr.h):

ErrorExpr -- Maybe we should propagate that up instead of exploding. Would probably be good.
CodeCompletionExpr -- no idea how to get one of these injected into an AST
LiteralExpr -- Literals are not mutable
TapExpr -- Not entirely sure what this is, or how it would get injected into the AST as a paramter
DiscardAssignmentExpr -- Can only appear on left side of an assignment
SuperRefExpr -- Not sure how you'd get one of these as part of an inout parameter
TypeExpr -- Not sure how to get one of these as part of an inout parameter
OtherConstructorDeclRefExpr -- Not sure how it would be a part of a valid inout parameter
OverloadSetRefExpr -- ??? Not sure what this is.
UnresolvedDeclRefExpr -- Not sure how to get one in Swift, though maybe it's possible?
UnresolvedMemberExpr -- Not sure how to get one in swift, though maybe it's possible?
AnyTryExpr -- Results from a function aren't mutable, I'm not sure how else you might use try.
IdentityExpr -- ??? Not sure what this is. self is immutable passed directly. Might want to handle ParenExprs like in myFunc(&(foo)) or AwaitExpr, though is the result of an AwaitExpr mutable?
TupleExpr -- TupleExpr's aren't mutable myFunc(&(1,2,3)) isn't legal.
CollectionExpr -- ??? Seems like it's either a ParenExpr or TupleExpr, but not totally clear.
KeyPathApplicationExpr -- ??? Not sure what this is.
UnresolvedDotExpr -- ??? Need to figure out how to get unresolved types to test this
TupleElementExpr -- This should only be a sub-expression of a TupleExpr, which is already illegal.
OptionalEvaluaionExpr -- Something like foo.bar?(), which would not be mutable since it's the result of a function call
MakeTemporarilyEscapableExpr -- ??? Not sure.
OpenExistentialExpr -- ???
UnresolvedSpcializeExpr -- ???
VarargExpansionExpr -- Comment says it's not surfaced. Probably don't need?
SequenceExpr -- ???
AbstractClosureExpr -- I don't think we can pass one of these inout?
CaptureListExpr -- Pretty sure this can't be passed inout
DynamicTypeExpr -- Pretty sure this can't be passed inout.
OpaqueValueRef -- I'm not sure how to get one of these in the AST, but we might want to handle passing it?
PropertyWrapperValuePlaceholderExpr -- ??? I'm pretty sure this can't appear as part of the inout parameter subtree.
DefaultArgumentExpr -- Also probably can't be part of an inout parameter subtree.
ApplyExpr -- Can't be pass inout since the result of an application is not mutable
DotSyntaxBaseIgnoredExpr -- ???
ExplicitCastExpr -- Result is not mutable, can't be passed inout.
ArrowExpr -- Goes on function decls, not sure how it would be passed as part of a parameter
RebindSelfInConstructorExpr -- ??? Not sure what this is for
IfExpr -- ternary and friends are not mutable
EnumIsCaseExpr -- ?? Not sure what this is, but It sounds like it would not be mutable.
AssignExpr -- Immutable
UnresolvedPatternExpr -- ??? Not sure how to get one of these
EditorPlaceholderExpr -- Not sure how to get one of these
LazyInitializerExpr -- Not sure how to get one of these
ObjcSelectorExpr -- I'm not familiar with this one? Can it return stuff?
KeyPathExpr -- Not familiar with this one. Looks like the return value is immutable.
KeyPathDotExpr -- ??
OneWayExpr -- ??

I definitely need to add a clause for ParenExpr, but otherwise I haven't seen the other expression types type-check far enough to cause the crash. If we wanted to weaken the check, I could make the else-clause return a nullptr which would skip out early on unknown expression types. I'm hesitant to do this since we could potentially accept buggy code for one version, then add the missing clause to the check and make a source-breaking change. Thoughts?

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

Fixing merge conflicts, then merging. Thanks for the reviews.

Fixing merge conflicts, then merging. Thanks for the reviews.

@swift-ci please test

@swift-ci please test


Add: Add dry-run mode to ask for confirmation before applying changes

Implements #7.

Thank you for adding this feature.


Feature/184 cli skeleton

Added a basic CLI tool to be used in MVD pipeline.
For now only a command to list participants is available, in a later PR we will add a command to register a participant (after #5)
Relates to https://github.com/agera-edc/MinimumViableDataspace/issues/184

Moved to new repo


Fixed #35189 -- Render admin collapsible fieldsets with .

TL;DR: Improve the accessibility of admin fieldsets and collapse them with a native HTML implementation.

Ticket: #35189
Proof of concept: Example 2: Details inside (no JS)
Initial discussion on Discord, accessibility channel

Important facts

Works with the main model fieldset and stacked inline fieldsets.
This change removes all JavaScript for collapsible fieldsets.
I have recycled as much CSS as possible.
JavaScript used to check if a fieldset could be collapsible. With JS gone, I moved that check to the Fieldset helper class in Python.
The translations for "Show" and "Hide" are now redundant.
A new translation "Fields" (context "form fields") was introduced.

Known issues

No existing CSS bugs were fixed.

Example: The font size of the fieldset is below 16px/1rem.
Example: The fieldset heading is hard to distinguish in forced-colors mode.
Context: Style for .collapse. h3 in forms.css was copied from .module h2, .module caption, .inline-group h2 in base.css.

The
 heading in stacked inlines should be a
; however, it was originally a
, so it's still better than before.

A potential UX issue could be that the clickable area of the fieldset has moved: You click on the details toggle ("fields") instead of the blue fieldset header.
Screenshots

A collapsible fieldset; collapsed

A collapsible fieldset; expanded

A fieldset that cannot be collapsed due to a validation error

A collapsible fieldset inside a stacked inline; collapsed

A collapsible fieldset inside a stacked inline; cannot be collapsed due to a validation error

buildbot, test on selenium.

I have removed the draft status of the PR. I expect that people will have feedback on the look and feel of the feature and that the code will require some changes. As such, I have not fixed every Selenium test yet.

I didn't realize you can make inline admins collapsible as well. I will work on adding that feature.

Hi @MHLut I think this looks really promising thank you ⭐
I've found something I'd like you to look into. I had some screenshots generated from this PR. You can see these here when you download the Artifacts.
These screenshots are taken under a few scenarios we try to support include dark mode and right to left languages (side note we should think about adding forced-colors mode to these).
I can see on your PR that in RTL we have this:

Collapisble is on the left here where as before it was on the right

I am also not sure if the collapse icon (> triangle thingy) should be on the left, so before Fields in the right to left case (maybe @sakhawy might be able to tell us 🙏 )
You might need to look into django/contrib/admin/static/admin/css/rtl.css 👍

@sarahboyce I guess it "feels off" because we're used to seeing dropdowns with the triangle after the text and not before it :D
But I think the triangle here is part of the  tag's default style, so nothing to worry about!
One reason for checking the django/contrib/admin/static/admin/css/rtl.css file would be this line:
https://github.com/django/django/blob/88274f6997b73326453695db8607822b0922d89f/django/contrib/admin/static/admin/css/forms.css#L225
I think it's the reason 'Collapsible' is on the left when dir="rtl".

@sarahboyce @sakhawy Thanks for the heads-up. I can't remember why I put the text-align: left in forms.py, but it's gone now. The heading aligns to the right side again in RTL mode.
The triangle is—as Moe mentioned—part of  native styling; I'd rather not mess with that. Since Moe seems OK with it, I'll keep that as-is.
FYI: I'm currently doing some free-form CSS experiments for forced-colors mode.

I've added a border around the collapsible fieldsets so that their fields look more grouped, just like the original collapsible widget.
The collapsible-fieldset-within-an-inline looks OK enough. It also still has the heading level bug (H3 instead of H4). We can argue it's still better than before and not a blocker, as @knyghty mentioned above.

We also need to tweak the docs: https://docs.djangoproject.com/en/5.0/ref/contrib/admin/ It says things like:

with a collapse class will be initially collapsed and their header will have a small “show” link.

And an existing wrong sounding:

Fieldsets with the collapse style will be initially collapsed in the admin and replaced with a small “click to expand” link.

We probably need a "versionchanged" note and release note also 👍

@sarahboyce I have updated the texts and release notes that you mentioned. I am not entirely pleased with the wording yet, feel free to update these! (I won't be around for the rest of the day)

Tagging @thibaudcolas since he is the author of the original ticket.

Hello @MHLut! Thank you so much for your work on this, for all the investigation and sharing your thoughts in the description and in Discord.
I read thru the Discord thread (I may have missed something), and while I acknowledge that you said the following:

So far, I like Example 2 most, Example 1 is OK, and don't like Example 3.
[...] the third example just feels meh to me. The look and feel is clunky, with a duplicate mention of "Address", where the  content feels useless.
Code-wise though; the second example is the cleanest, and allows us to reuse the existing structure of the fieldsets.
The first example has the same perks, but needs JS to get it to work.
The first example also requires CSS to add in the triangle icons which have no specific meaning.

I honestly dislike the "Fields" summary. It feels (to me, I know, very objectively) very unpolished in terms of UI, mainly because the fieldset is supposed to be collapsed and yet Django is "stubbornly" showing just a peak, a little more of it. I think is, to some extent, important to keep the previous "implicit agreement" that a collapsed fieldset would only show the fieldset name and nothing else.
With that in mind, do you think there is a way to have Example 3 working (purely in terms of UI) without duplicating the fieldset name? Basically have Example 3 without the words highlighted in red:

Happy to coordinate a chat or meet if you feel that discussing this IRL(ish) would be easier.

@nessita Thank you for your feedback. As far as I have seen, there is no good way to do the third option whilst hiding information. Here is why.
The HTML requires the following items:

A  element.
A  inside the details.
A  element.
A  inside a fieldset.
A heading ( in this case) inside the fieldset or summary.

We can place the heading inside the legend.
However, we cannot place the summary inside anything other than the top level of the details element.
This means that both the heading and the summary need to have some form of descriptive text.
I picked the solution that looks the most streamlined (in my opinion) and has the least replication.
By ensuring that the heading comes first in the structure, we don't have to add the heading contents to any of its child elements. (Since the fieldset name has already been announced)
If we choose the third solution, we would have to repeat the fieldset name in the summary.
I prefer solution 2 to the old UI, so let's agree to disagree there.
I also think that showing just a hint of the fieldset contents alongside the details triangle icon gives the user a visual hint of an expandable area.
Nb. If desired, the text "Fields" could be replaced with another text.

The HTML requires the following items:
* A  element.
* A  inside the details.
* A <fieldset> element.
* A <legend> inside the fieldset.
* A heading (
 in this case) inside the fieldset or summary.
We can place the heading inside the legend. However, we cannot place the summary inside anything other than the top level of the details element. This means that both the heading and the summary need to have some form of descriptive text.

Thanks for these details. To be honest, I'm struggling to understand why all these elements are necessary. Based on the Discord messages I read, it seems there are two primary reasons: firstly, to enable the use of CSS for selectors and to handle the hide/show behavior without JavaScript, and secondly, to ensure proper accessibility and assist screen readers. However, I'm still not entirely clear on why each element is essential. I'm unsure how to experiment with this and comprehend the consequences of removing each item individually.
To try to understand a bit more, I copied the HTML from your codepen for Example 3, and below these I put some questions:

Example 3: Details outside (no JS)

      Address fields
      <fieldset class="module aligned collapse">

Address

Optional description.

...

...

...

...

...

...

      </fieldset>

Could we simply remove the h3? If not, could you please explain why not? It would be easier for me to understand if you could outline what happens if the element is not present.
If we absolutely cannot remove the h3, could we hide it instead? That way, we could retain the necessary information for screen readers while making it visually invisible.

With the above, and changing "Address fields" -> "Address", I think we would have a nice solution.

By ensuring that the heading comes first in the structure, we don't have to add the heading contents to any of its child elements. (Since the fieldset name has already been announced) If we choose the third solution, we must repeat the fieldset name in the summary.

This I'm not sure what it means, sorry. Could you please help me understand? An example would certainly help me!

I prefer solution 2 to the old UI, so let's agree to disagree there.

Sure.

I also think that showing just a hint of the fieldset contents alongside the details triangle icon gives the user a visual hint of an expandable area.

I agree that the hint about the expandable area is necessary, but I think the triangle in the "fieldset title row" (the blue one with white letters) accomplish that perfectly. There is no need for an extra row IMHO.
Having yet another row (white background in example 2) seems unnecessary (from an UI POV) and doesn't provide any useful information (I know we can change the text, I replied about this further down). I consider this a regression, in that Example 2 makes the interface feel cluttered and can be confusing for users who expect collapsible sections to minimize the amount of visible content, especially when vertical space is limited.
I believe it's unnecessary to append or mention "fields" anywhere, as it seems redundant. This is similar to how the admin doesn't append "Model" everywhere because it's implied.

Nb. If desired, "Fields" could be replaced with another text.

Yes, absolutely, though I can't think of a text to put in there that would justify the extra row. Do you have any ideas?

@MHLut, @nessita,
I had a (very quick!) look into this.
The <legend> element is not (strictly speaking) necessary. It is useful, but in our case I think the  element achieves the same goal. We do need to make sure we keep it for <fieldset>s that do not use collapse however (not sure how much the admin uses fieldsets otherwise).
As for the
, I am not sure. We could move it into the  element, this is allowed. I think that we should just do whatever makes the outline more correct here, whether that's having a heading or not.
With removing the <legend> element we should probably test that it makes sense when using a screen reader (I'd guess so, and I'd guess possibly it's even less confusing without the repeated text.

Notes regarding UI changes to the third proof of concept (link in top description):
I tried to combine the fieldset and details elements, but the Firefox accessibility inspector threw warnings.
The problem is that a fieldset needs a legend to describe its contents to assistive technology, and the legend should be its first child.
The same goes for details: the summary describes its contents and should be the first child.
(If you omit a summary, the collapsible widget's label defaults to "Details" in English.)
When putting the legend inside the summary, the accessibility inspector did not recognize it as a label.
I also tried to attach the fieldset name to the fieldset through aria-label, but the accessibility inspector indicated that this isn't good enough (and once again hinted at using a legend).
I don't see how we can use the third UI solution without sacrificing accessibility.
Unless we could somehow use aria-label or aria-describedby.
(My third proof of concept also lacks a legend, meaning it is an incomplete solution.)
NB. Regarding aria-describedby:
If we'd use that, we need to add an ID to the fieldset's heading element and use the heading as a descriptor.
However, fieldset names are not mandatory, and sometimes there is no heading.
We also lack a property guaranteeing a unique ID output.

@MHLut could we use a "complete" solution for the third option without sacrificing accessibility by hiding the
 with a custom CSS class that allows to screen readers to still mention it?

@nessita The
 isn't the problem.
We cannot intertwine the <legend> and the  without sacrificing accessibility.
We would need to do that to achieve the look and feel of the third solution without JavaScript or hacks.
I also would prefer to keep the <fieldset> as the outer element so that most of the outline will be identical between collapsible and regular fieldsets.
Solution 2 provides that, but solution 3 doesn't.
If we sacrifice the <legend>, solution 3 would probably be achievable, even retaining <fieldset> as the outer element.
However, adding a legend is one of the original assignments of this ticket (point 3 under "Accessibility bugs").
I have tried several things and don't know what else would be good.
Accessibility-wise, the current solution is probably the best we will get.
Thibaud hasn't looked at this yet, though, and I hope he has ideas for an improvement.

@MHLut Thank you. Could you please, when you have some time, push changes in another branch with what you have for solution 3? Ideally this temporary branch would have a complete solution in terms of accessibility (ie all the required HTML elements for assistive technologies would be present). I'd like to see how it looks and use it a bit, if possible.

Per @nessita's request, I have updated the PR (in a separate commit for now) with a new UI style.
See these notes I added to the PR:
## Accessibility notes

I discussed this solution with a blind developer. He suggested we replace `<fieldset>` with `<div role="group">` if the lack of `<legend>` bothers the accessibility checkers.

Due to styling issues, I had to change the heading level of inline fieldsets to `<h4>`. This also fixes a heading bug I mentioned in the original PR.

## Other notes

This solution hinges on adding a unique ID to a fieldset heading so that we can use `aria-labelledby` on the `<fieldset>.` Due to the lack of a clean way of generating such an ID in the template, I added another property to the `Fieldset` class.

Tagging @jscholes as my aforementioned advisor.

Apologies for the failed tests; I've added some classes to existing headings, but the tests do not like it. I will fix these later, but you can test this new UI design already!

@nessita Could you check if you approve of this look and feel? If so, I will fix the unit tests. Otherwise, I will revert the commit.

@nessita I'm glad you like it! Per your feedback:

Changing the cursor to a pointer on elements that don't naturally have one is typically considered bad practice. I am reluctant to make this change and would like a second opinion from the accessibility team.

The header is in line with the current admin design, and changing it would also affect the non-collapsible UI.

I don't have much time until the feature freeze, and fixing the tests alone will be a task. James (@jscholes) uses a screen reader and clarified that whatever we push will already be a significant improvement compared to the current UI. As such, I would rather see us commit these changes to Django 5.1 and make overarching UI improvements in future tickets.

1. Changing the cursor to a pointer on elements that don't naturally have one is typically considered bad practice. I am reluctant to make this change and would like a second opinion from the accessibility team.

I find myself changing the CSS to set the cursor as a pointer in all my own usages of details/summary. I admit I didn't search for the rationales of not making this behavior the default in the specs.

@nessita I'm glad you like it! Per your feedback:
1. Changing the cursor to a pointer on elements that don't naturally have one is typically considered bad practice.

Would you have any reference link for this affirmation? It was a surprise to me to read this since I would generally think that the pointer mouse cursor would be an additional (and welcomed) "clickability" indicator. I tried searching for articles or reasons explaining why it'd be a bad practice and I couldn't find any, so I would definitely appreciate if you could provide some.
I did find a very interesting link supporting the pointer mouse cursor for anything that can be "interacted with" (but this should be in addition to other indicators like the "arrow pointing right" that you are proposing, which I this is a positive adding), see https://github.com/w3c/csswg-drafts/issues/1936 (very long conversation) with a resolution from the CSS Working Group to add:

Authors should use pointer on links and may use on other interactive elements.

I know it says "MAY" use but the whole thread and many other related issues focus on how this can enhance user experience and make the interface more intuitive, especially for users who are accustomed to the pointer cursor indicating interactivity on the web. Furthermore, the MDN Web docs change the mouse cursor to pointer in the examples for customizing the appearance of the details element.
Because of the above, I think we should change it.

2. The header is in line with the current admin design, and changing it would also affect the non-collapsible UI.

Fair enough.

I don't have much time until the feature freeze, and fixing the tests alone will be a task. James (@jscholes) uses a screen reader and clarified that whatever we push will already be a significant improvement compared to the current UI. As such, I would rather see us commit these changes to Django 5.1 and make overarching UI improvements in future tickets.

Thanks for the heads up!

FWIW I agree with adding cursor: pointer here for Natalia's reasons and more. It's a handy way to know something is interactive (there are times you can see non-interactive arrows, e.g. in lists (should they? maybe not, but we're here).
Another notable site to have a pointer on these elements is this one.

For example
  etc.

Also +1 for cursor: pointer. As Tom says, GitHub does it too - they have the following rule to apply it globally which seems sensible:
details summary {
    cursor: pointer;
}

We have also already done the same for changelist filters:
#changelist-filter h3,
#changelist-filter details summary {
    font-weight: 400;
    padding: 0 15px;
    margin-bottom: 10px;
    cursor: pointer;
}

If we apply it globally, we can remove the duplication from that rule.

I'll add the pointer, although I would like to add that GitHub is not necessarily an example of good usability. Agreed on the global styling for this one, since we're also introducing more details and summaries in other PRs.

@nessita The tests finally seem to pass, so that you can return to testing and reviewing!
I don't have much time for follow-ups, but I would like to see this merged before the feature freeze, so feel free to update the branch as you see fit.
@sakhawy might also be able to assist with issues that don't require knowing the entire PR history.

@nessita The tests finally seem to pass, so that you can return to testing and reviewing!
I don't have much time for follow-ups, but I would like to see this merged before the feature freeze, so feel free to update the branch as you see fit.
@sakhawy might also be able to assist with issues that don't require knowing the entire PR history.

Thank you so much @MHLut, I'll work in this PR tomorrow or Thu at the latest.

@MHLut Hey there! I have pushed some changes removing the definition and usage of heading_id because it felt inconsistent with the existing code, and also because it's usually a bad practice to rely on random numbers to generate unique IDs (random module does not guarantee uniqueness, even in large ranges). We could use UUID instead (which does guarantee uniqueness) but that feels a bit overkill for the branch's need, so I built the fieldset heading ID by using information available in the template (or its parent template), similar to what formsets already do.
@sarahboyce Would you fancy to re-review that commit (it's isolated in a second commit to ease review)? (Since I changed some of the already approved code.)
FYI I still need to review in detail tests and docs, but overall I think the branch is in very good shape.

@nessita @sarahboyce Thank you for the heading ID update! I cannot review the ID changes in detail right now, but the only thing important to me is that they are predictable and unique since aria-labelledby relies on them for accessibility reasons.
A nice to have for IDs would be for them to be short and readable so that they are understandable when read from a browser URL.

Looks good! If we want to split commits I would have:
* setting the header levels and adding the `aria-labelledby` as "Associated fieldsets with their headers."

* updating collapse to use details/summary

This is a good proposal, thank you! I will try to work this out after our weekly sync.

I split the first commit into two logical commits.


[ruby:bundler] Failing to create PRs with JSON::GeneratorError

For about 3 weeks now we're not getting any new dependancy updates for our ruby:bundler ecosystem. This correlates to the moment we turned the vendor: true option, but I didn't yet confirm causation (i.e. if reverting that change would fix it, but we would really like to have vendoring on).
Here is the relevant part of the log for one dependency. All that need to be updated fail at same place with the same error.
updater | INFO <job_86767312> Checking if newrelic_rpm 6.14.0 needs updating
  proxy | 2021/02/03 16:58:57 [148] GET https://rubygems.org:443/api/v1/versions/newrelic_rpm.json
  proxy | 2021/02/03 16:58:57 [148] 200 https://rubygems.org:443/api/v1/versions/newrelic_rpm.json
updater | INFO <job_86767312> Latest version is 6.15.0
  proxy | 2021/02/03 16:58:58 [150] GET https://index.rubygems.org:443/versions
  proxy | 2021/02/03 16:58:58 [150] 206 https://index.rubygems.org:443/versions
updater | INFO <job_86767312> Requirements to unlock own
updater | INFO <job_86767312> Requirements update strategy bump_versions
updater | INFO <job_86767312> Updating newrelic_rpm from 6.14.0 to 6.15.0
  proxy | 2021/02/03 16:59:13 [152] GET https://index.rubygems.org:443/versions
  proxy | 2021/02/03 16:59:13 [152] 206 https://index.rubygems.org:443/versions
  proxy | 2021/02/03 16:59:24 [154] GET https://rubygems.org:443/gems/newrelic_rpm-6.15.0.gem
  proxy | 2021/02/03 16:59:24 [154] 200 https://rubygems.org:443/gems/newrelic_rpm-6.15.0.gem
updater | INFO <job_86767312> Submitting newrelic_rpm pull request for creation
updater | I, [2021-02-03T16:59:31.805722 #72]  INFO -- sentry: ** [Raven] Sending event e3c9ae4f7724410f8c9a2afe16318955 to Sentry
  proxy | 2021/02/03 16:59:31 [156] POST https://sentry.io:443/api/1451818/store/
  proxy | 2021/02/03 16:59:31 [156] 200 https://sentry.io:443/api/1451818/store/
updater | ERROR <job_86767312> Error processing newrelic_rpm (JSON::GeneratorError)
updater | ERROR <job_86767312> source sequence is illegal/malformed utf-8
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/vendor/ruby/2.6.0/gems/http-4.4.1/lib/http/mime_type/json.rb:12:in `to_json'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/vendor/ruby/2.6.0/gems/http-4.4.1/lib/http/mime_type/json.rb:12:in `encode'
updater | ERROR <job_86767312> /usr/lib/ruby/2.6.0/forwardable.rb:230:in `encode'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/vendor/ruby/2.6.0/gems/http-4.4.1/lib/http/client.rb:176:in `make_request_body'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/vendor/ruby/2.6.0/gems/http-4.4.1/lib/http/client.rb:44:in `build_request'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/vendor/ruby/2.6.0/gems/http-4.4.1/lib/http/client.rb:30:in `request'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/vendor/ruby/2.6.0/gems/http-4.4.1/lib/http/chainable.rb:27:in `post'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/api_client.rb:59:in `create_pull_request'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:632:in `create_pull_request'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:271:in `check_and_create_pull_request'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:66:in `check_and_create_pr_with_error_handling'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:51:in `block in run'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:51:in `each'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:51:in `run'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/update_files_job.rb:17:in `perform_job'
updater | ERROR <job_86767312> /home/dependabot/dependabot-updater/lib/dependabot/base_job.rb:27:in `run'
updater | ERROR <job_86767312> bin/update_files.rb:21:in `<main>'

Package manager/ecosystem
ruby:bundler
What you expected to see, versus what you actually saw
I expect ruby:bundler PRs to be created, but they are not. Neither is @dependabot rebase or @dependabot recreate working on any PRs that were opened before.

Thanks for opening this issue @filipkis, it's very likely that this is indeed related to vendoring, especially the source sequence is illegal/malformed utf-8 bit makes me think that, we need to upload binary files as base64, and maybe we're failing to do that in this case.
Does this happen for all the dependencies in your repo?
Could you share which repo this is happening on so I can dig a little deeper? Feel free to go through support if it's a private repo that you don't want to share publicly. I'll try to set up a dummy project with gem "newrelic_rpm", "~> 6.14.0" to try and replicate this, but if this is happening for all gems, I'm not sure if I'll be able to replicate this.
I'm not sure if I'll be able to dive into it this week, but any info you have that you think would help us debug this would be greatly appreciated

Hi @jurre and thanks for a very prompt response. I've went ahead and created a dummy project repo that has same Gemfile, Gemfile.lock` and dependabot settings. And indeed same errors appear.
Hope this helps.

Hi @jurre and thanks for a very prompt response. I've went ahead and created a dummy project repo that has same Gemfile, Gemfile.lock` and dependabot settings. And indeed same errors appear.
Hope this helps.

That's amazing, thanks so much ✨

From sprint planning: Let's investigate what's going wrong in this case.


flags dont work anymore

Hi,
something happened to the github link of the flags as can be seen here:
https://tnovau.github.io/react-circle-flags/gallery
Would be better to add the flags to the package?
cheers

It's related to an issue with the page where the flags are stored

which is github...?

https://github.com/HatScripts/circle-flags/issues/20

Maybe, it will be a good idea to add a feature to use your own CDN


[Feature] when two instances of PowerShell are running Set-DbaDbCompression the script fails

Report

Host used

[ ] powershell.exe
[x ] ISE
[ ] VS Code
[ ] Other (please specify)

Errors Received

writeErrorStream      : True
PSMessageDetails      :
Exception             : System.Exception: Could not complete cursor operation because the table schema changed after the cursor was declared. --->
                        System.Data.SqlClient.SqlException: Could not complete cursor operation because the table schema changed after the cursor was declared.
                           at Microsoft.SqlServer.Management.Common.ConnectionManager.ExecuteTSql(ExecuteTSqlAction action, Object execObject, DataSet fillDataSet,
                        Boolean catchException)
                           at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteWithResults(String sqlCommand, Boolean retry)
                           --- End of inner exception stack trace ---
TargetObject          : [Client-AlexTestRenamed]
CategoryInfo          : NotSpecified: ([Client-AlexTestRenamed]:PSObject) [Write-Error], Exception
FullyQualifiedErrorId : dbatools_Test-DbaDbCompression,Stop-Function
ErrorDetails          : Could not complete cursor operation because the table schema changed after the cursor was declared.
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at Stop-Function, C:\Program Files\WindowsPowerShell\Modules\dbatools\1.0.141\allcommands.ps1: line 87807
                        at Test-DbaDbCompression<Process>, C:\Program Files\WindowsPowerShell\Modules\dbatools\1.0.141\allcommands.ps1: line 73647
                        at Set-DbaDbCompression<Process>, C:\Program Files\WindowsPowerShell\Modules\dbatools\1.0.141\allcommands.ps1: line 67195
                        at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}

Steps to Reproduce

When  using Set-DbaDbCompression in two different PowerShell windows and I get error like they interfere with each other, so one of the sessions fails, even though they are doing the compression on different databases.
Expected Behavior

I would expect both of the running session will successfully complete the compression.
Actual Behavior

one one instance of PowerShell i got this:
Set-DbaDbCompression -SqlInstance myServer -Database AlexTest -CompressionType Recommended -PercentCompression 30 #-MaxRunTime 60
WARNING: [10:30:45][Get-DbaBuildReferenceIndex] Index is stale, last update on: 2021-04-07T00:00:00, try the -Update parameter to fetch the most up to date index
WARNING: [10:30:49][Test-DbaDbCompression] Unable to query myServer  - [AlexTest] | Invalid object name '##TestDbaCompression'.
on another instance of powershell i got similar error:
PS D:\Tools\AccountRefresh> Set-DbaDbCompression -SqlInstance myServer  -Database AlexTestRenamed -CompressionType Recommended -PercentCompression 30 #-MaxRunTime 60
WARNING: [10:30:30][Get-DbaBuildReferenceIndex] Index is stale, last update on: 2021-04-07T00:00:00, try the -Update parameter to fetch the most up to date index
WARNING: [10:30:49][Test-DbaDbCompression] Unable to query myServer  - [-AlexTestRenamed] | Could not complete cursor operation because the table schema changed
after the cursor was declared.
Environmental information
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨
Please provide the output of the below script
PowerShell Version        : 5.1.17763.1852
dbatools latest installed : 1.0.141
Culture of OS             : en-US

SQL Server:
Microsoft SQL Server 2019 (RTM-CU10) (KB5001090) - 15.0.4123.1 (X64)   Mar 22 2021 18:10:24   Copyright (C) 2019 Microsoft Corporation  Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Datacenter 10.0 <X64> (Build 17763: ) (Hypervisor)

us_english

@niphlod   from DBATools slack channel had mentioned this:
the table is on tempdb, so ....... it blocks. https://github.com/sqlcollaborative/dbatools/blob/90474c562c7696c8957c38e8becbb4ca408f53a8/functions/Test-DbaDbCompression.ps1#L289

yeah, I can take care of it in the next few days

Thanks for the info. So the question is: Can we move from global temp tables to temp tables? Or: Do we generally want to allow two sessions to run Test-DbaDbCompression in parallel?
Have you tried to seperate Test-DbaDbCompression from Set-DbaDbCompression? So first running both Test-DbaDbCompression one after the other and saving the result in a variable (or even a file with | ConvertTo-Json) and then using this as -InputObject with the two Set-DbaDbCompression running in parallel?

the easiest fix just to be sure dbatools is not the culprit is not using fixed names for temp tables.
the thing is, sp_estimate_data_compression_savings was not made to run parallel.
If you have large enough dbs, and the queries take some time to run, it creates an inter-lock on
select @sample_compressed_desired = used_page_count      from tempdb.sys.dm_db_partition_stats      where object_id = @sample_table_object_id and index_id = @sample_index_id
select @sample_compressed_current = used_page_count      from tempdb.sys.dm_db_partition_stats     where object_id = @sample_table_object_id and index_id = @sample_index_id

with one blocking the other. One of the two gets terminated by the deadlock monitor.
So no, you can't parallel-compress if you wanna rely on estimates (-CompressionType Recommended), which calls Test-DbaDbCompression, which in turn calls sp_estimate_data_compression_savings.
You need to collect estimates beforehand and serially (Test-DbaDbCompression), then you can run compression in parallel (Set-DbaDbCompression).
Example 4 shows how to pipe in precompiled estimates
$testCompression = Test-DbaDbCompression -SqlInstance ServerA -Database DBName
Set-DbaDbCompression -SqlInstance ServerA -Database DBName -InputObject $testCompression

I believe with running it this way, we will just switch the blocking from Set-DbaDbCompression to Test-DbaDbCompression running in parallel, won't we?

nope, if you run test-dbacompression on all of your dbs serially
# serial estimate
$testCompression = Test-DbaDbCompression -SqlInstance ServerA -Database DBName1, DBName2
# save it for all
$testCompression | Export-Clixml some\path\to.xml

then you can run your "usual" parallel, just doing in one process
# parallel 1
$testCompression = Import-Clixml some\path\to.xml
Set-DbaDbCompression -SqlInstance ServerA -Database DBName1 -InputObject $testCompression

and in the other
# parallel 2
$testCompression = Import-Clixml some\path\to.xml
Set-DbaDbCompression -SqlInstance ServerA -Database DBName2 -InputObject $testCompression

that is actually a problem, as the databases refresh requests (followed by compression) are coming at different time, sometimes in parallel, and ideally the process should be able to handle it

Go tell Microsoft about it...we can't really touch their sprocs. If you're
responding to external events that you can't manage, you need to implement
a singleton and queue at least the part that fetches the reccomendations.
Il mar 25 mag 2021, 19:39 alexsinkevich @.***> ha
scritto:

that is actually a problem, as the databases refresh requests (followed by
compression) are coming at different time, sometimes in parallel, and
ideally the process should be able to handle it
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/sqlcollaborative/dbatools/issues/7374#issuecomment-848078731,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA52B4WHBEJG55RE26W67DTPPOFZANCNFSM45PVJZBQ
.

the more I think of it the more I like the way it is.
We could check if the temp table is there before starting, but it could potentially end in a waiting loop, and nobody wants to wait potentially forever.
And that's a job for a higher level function, or a "dbasolution" project (it's maybe 4 lines of code on top of what's readily available).
Wanna keep simple and don't wanna think about managing singletons and queues (or writing checks for concurrency) ?
Just loop till it doesn't bomb out.

haha, feature, not a bug. that is funny.
anyways, I have tried using the following two scripts in parallel and the results were the same
script 1:
$SQLInstance  = 'MyServer'
$DBName = 'MyDB1'
$testCompression = Test-DbaDbCompression -SqlInstance $SQLInstance  -Database $DBName
Set-DbaDbCompression -SqlInstance $SQLInstance  -Database $DBName -InputObject $testCompression -CompressionType Recommended -PercentCompression 30
output  of script 1:
WARNING: [17:16:45][Get-DbaBuildReferenceIndex] Index is stale, last update on: 2021-04-07T00:00:00, try the -Update parameter to fetch the most up to date index
WARNING: [17:18:27][Test-DbaDbCompression] Unable to query MyServer - [MyDB1] | Invalid object name '##TestDbaCompression'.
Script 2:
$SQLInstance  = 'MyServer'
$DBName = 'MyDB2'
$testCompression = Test-DbaDbCompression -SqlInstance $SQLInstance  -Database $DBName
Set-DbaDbCompression -SqlInstance $SQLInstance  -Database $DBName -InputObject $testCompression -CompressionType Recommended -PercentCompression 30
output of script 2:
WARNING: [17:16:35][Get-DbaBuildReferenceIndex] Index is stale, last update on: 2021-04-07T00:00:00, try the -Update parameter to fetch the most up to date index
WARNING: [17:18:27][Test-DbaDbCompression] Unable to query MyServer - [MyDB2] | Could not complete cursor operation because the table schema changed after the cursor was declared.

maybe if that temp table is a local table (not a global temp table) it might work? i am willing to test

not a bug of dbatools, it's a "bug" of sp_estimate_data_compression_savings , which we have no control upon.
we may add a feature of dbatools, if we wanna go around it.
back to you:
Did I get correctly that you're running in two separate shells, but at the same time
$testCompression = Test-DbaDbCompression -SqlInstance $SQLInstance -Database $DBName

btw, if you wanna hop on the Slack channel the conversation may be speedier

note for the reader: solution on looping was provided via Slack. if it works, we may add an example to clarify parallel usage.

The looping did not work :(

back to slack and drawing board


404 postgres support api ref

Page https://www.ktorm.org/api-docs/org.ktorm.support.postgresql/index.html returns 404.
Link found here: https://www.ktorm.org/en/dialects-and-native-sql.html#Built-in-Dialects’-Features in ktorm-support-postgresql section

It's moved to https://www.ktorm.org/api-docs/ktorm-support-postgresql/org.ktorm.support.postgresql/index.html

Fixed, thanks for your feedback.


Installation issue

When I try to install using pip I get a dependency issue caused by the Ultralytics YOLO model.

Turns out the issue is probably some recent changes in Ultralytics that need python>=3.8 and torch>=1.8. Also I guess some users might experience this issue with the new python 3.12 where torch does not have to be available yet.

Turns out the issue is probably some recent changes in Ultralytics that need python>=3.8 and torch>=1.8. Also I guess some users might experience this issue with the new python 3.12 where torch does not have to be available yet.


Introduce DragAndDrop library

📃 Description
The DragAndDrop library is to provide an easy way to implement DragAndDrop in Compose.
🧪 How Has This Been Tested?
The library is tested manually with the built samle.
⚒ Does the PR contain new tests or refactored old ones?
N/A
📷 Screenshots (if appropriate)

📦 Types of changes

[x] New feature (non-breaking change which adds functionality)
[ ] Enhancement to a current functionality
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Bug fix (non-breaking change which fixes an issue. Please add issue link here too).

✅ Checklist

[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] This PR contains new tests that cover the new code.
[ ] This PR refactor previous tests to cover the new code.
[ ] This PR is part of a set of PRs that build a bigger feature. If so, please, add here links to previously merged or open PRs.

README is coming :)