style(sync): vertically centre sync page title

Description:
If we are syncing after having already completed the initial sync we do not show the funding address QR code. In this case, adjust the title padding so that the page title is better centred.
Motivation and Context:
The sync page looks a little off when syncing a wallet that has already synced at least once.
How Has This Been Tested?
Manually
Screenshots (if appropriate):
Before:

After:

Types of changes:
Style adjustment
Checklist:

[x] My code follows the code style of this project.
[x] I have reviewed and updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes where needed.
[ ] All new and existing tests passed.
[x] My commits have been squashed into a concise set of changes.

Coverage remained the same at 16.267% when pulling d0156137a2d3e5a5100cdf7764e004ed0bd7f0a8 on mrfelton:style/syncing-title-position into 77fb024928a1eaccfd5700e0e0b613335ade6525 on LN-Zap:master.

utACK d015613


Introduce a id selector

Need to support div#someId selectors

Need to extend a parser to:
Locate a id attribute
If got one - parse one id selector
If none - ignore.
Looks simple, but could be confused with ChildSelectors.
4sp, couple days


SonarQube fails in pull request builds

SonarQube runs with the given token and fails for pull requests, causing the build to fail and pull requests unable to be merged.
@SAReyes please try to find a fix for this.

The builds are failing on pull requests from a forked repo, we managed to replicate the same behaviour on one of our repos, it seems like a permission issue but I can't find a quick solution for it.
By the way, I've opened a question SO for this as well.
I would appreciate it if someone lends a helping hand.

I will help you after the BCN conf.

I've got an answer for this. It seems we won't be able to analyse pull requests, it will pollute the sonar project otherwise. This is something the SonarSource team will be working on, it would be a great addition to OSS projects.
I'll update the configuration to run only on master for the time being.


add travis.yml

Enables travis builds. The default command for maven is mvn test, for gradle it's gradle check.
Includes the gradle cache fix from https://docs.travis-ci.com/user/languages/java#Caching.
/cc @chrismwendt

Woot! I forgot that we wanted to have CI for this plugin. Thanks :+1:


Regenerate all resource docs

Proposed changes
The main change in this PR is to fix an issue with the Function names in Go.
We should wait to merge this after #3093, #3098, #3099. I might have to rebase and regenerate after those PRs are merged.
Unreleased product version (optional)
N/A
Related issues (optional)
Fixes #3075. The generator fix is in: https://github.com/pulumi/pulumi/pull/4490.

Now that the generator fix is merged in I will wait to merge this as @stack72 mentioned all of the providers will rolled tomorrow anyway, which will trigger a docs PR for each of them anyway. So we may not need this PR after all.


useAuthState throws error

I'm getting TypeError: Cannot read properties of null (reading 'useReducer') when passing in the auth object to useAuthState. Not sure what went wrong.

@OGreeni Please feel free to reopen this issue with a code example


starting attrs integration

This pr integrates attrs and  closes #15

I am also quite happy. I think not getting a huge tuple returned should improve the user experience quite a bit! The only thing I noticed is that test times increased quite a bit.. My guess is that this comes from me re-initializing PyrasaSpectrum objects in a loop in irasa_mne.irasa_epochs. Any ideas whether/how this can be improved @thht?


Update failed

Hi,
i use mailspring since longtime, today mailspring show update 1.9.2 and after i have error loop
https://i.imgur.com/3AfcylM.png
i clic ok and error show all time: https://i.imgur.com/3AfcylM.png
i have visualstudio 2019, last version nodejs and python 3.10.2
folder: https://i.imgur.com/IdXeQXv.png
can you help please?

Did you mean to post that here https://github.com/Foundry376/Mailspring ?

I am also having this same issue. Unable to bypass error loop - had to entirely uninstall application. Deleted folders mentioned in error, and checked for registry issues. Only way to get app functioning again was to reinstall using a previous install .exe, as most current install .exe from website results in same issue.

https://github.com/Foundry376/Mailspring/issues/2373

Hey @Prinzhorn, sorry for the confusion, I think the issue itself is related to Mailspring only and not to better-sqlite3 in any case, my personal thought is that the build has gone wrong, probably with node-gyp, and show better-sqlite3 (And a couple more other dependencies) as the problem.
As such I'm pretty confident you can close this issue without problem (If you can 🙂). Wish you a good day!


Clicking on every other project tag - first tag getting selected

Description
Steps to reproduce the bug:

open Projest
Go to projects
Click on add project
Click on python/java ...etc on any other tags
java script tag getting selected

https://user-images.githubusercontent.com/71914071/232505949-df4069c2-f5b2-40f0-857a-0875fedbf9ec.mp4
Screenshots
No response
Additional information
No response

Could you please verify if the latest changes have resolved the error in projest, @SoundaryaKoutharapu? Thank you.

The issue still exits.
I guess, that is due to same the naming of 'for=" ' .
If you could assign this to me, I would like to work on this

Could you please verify if the latest changes have resolved the error in projest, @SoundaryaKoutharapu? Thank you.

Yeah, the issue still exists.

@SoundaryaKoutharapu  Done fixing the issue. Thanks


Tests for Up filter

Closed by https://github.com/bojanrajkovic/pingu/commit/2c0e62a0dc5e375fc6da16e20d80c48f7e0c295e


[Rough Nights & Hard Days] Minor Bug with the Clock

I've just figured that the small and large needle were inversed on the clock. When you modify minutes, it is the small which moves and vice-versa.From: Hertingerwfrp4e: 3.0.1wfrp4e-core: 1.01wfrp4e-rnhd: 1.01wfrp4e-starter-set: 1.01

Curse my millennial smooth-brain.


Clean-up and some functions added

whats done:
Cannot edit name, removed email addres, removed manage social accounts,
removed manage social accounts, added a profile page to se your posts,
removed everything with password and sign up forms.
Cleaned the front page
added positions finder on front page
Added Dynamicly generation of page to a templete.

Signin and singup view is practically the same. Since you can only signup using facebook, there is no need to have the actual signup view. (Loggining in using facebook oauth will automatically register the user if they don't exist).
Remove singup.client.view.html view and all it's dependencies!
Since we can only authenticate using oauth2 there is no need to use the "signin.client.view.html" view, since it is only a signin view for "local account" that isn't registered using oauth2.
Remove the signin.client.view.html view and all it's dependencies!
Edit the authentication.client.view.html view to say "Sign in or sign up using your facebook account" rather than just "Sign in using your facebook account", since you can actually register through this link as well.


Integrate Node traits into LaunchContextWith

Describe the feature
It would be nice to have access to the FullNodeComponents and FullNodeTypes traits, so we can also move this into the context:
https://github.com/paradigmxyz/reth/blob/5293a2f58da507abf432d69ff24d165ec49ee224/crates/node/builder/src/launch/mod.rs#L132-L140
this could be done with a new state type, similar to
https://github.com/paradigmxyz/reth/blob/5293a2f58da507abf432d69ff24d165ec49ee224/crates/node/builder/src/launch/common.rs#L685-L685
but with access to the FullNodeTypes trait, either by providing this here
https://github.com/paradigmxyz/reth/blob/5293a2f58da507abf432d69ff24d165ec49ee224/crates/node/builder/src/launch/mod.rs#L130-L130
via with_blockchain_db::<T> and then keep the type T in a phantomType for example.
so we can just call let builder_ctx = ctx.builder_ctx()?
and later by attaching the adapter via fn with_components<N: FullNodeComponents> to the launchcontext with an additional attachment type like WithMeteredProvider
https://github.com/paradigmxyz/reth/blob/5293a2f58da507abf432d69ff24d165ec49ee224/crates/node/builder/src/launch/mod.rs#L168-L172
This way, we can push a ton of setup code currently in fn launch into the context.
FYI @fgimenez in case you find some time
Additional context
No response

FYI @fgimenez in case you find some time

absolutely, thx!


Use a Big Sur-style macOS icon for the Godot editor

This provides a more coherent visual look with the rest of macOS.
This closes https://github.com/godotengine/godot-proposals/issues/1616.
Thanks @hazarek for providing the icon :slightly_smiling_face:
Preview
I don't have a macOS setup at hand right now, so here's Gwenview rendering it for now:

Icon is overeiden during startup. Changing one in the bundle template won't fully change app icon, see #48685 for the relevant code (disables icon override), or the same code can be changed to use macOS specific icon.

It works successfully following the merge of https://github.com/godotengine/godot/pull/48685:

Thanks!

Cherry-picked for 3.4.


Model exported with 5 identical skins.

This one is more tricky and I couldn't dig out a proper lead...
Consider this model
Jaime.zip
It has a fairly complex rig. When I export it I get this files. (note that it's exported with default settings except that selected only is checked, with the mesh selected, export skinning, force sample application is checked, Bake skinning application is checked).
gltf.zip
There are 5 identical skins exported. (there should be one.) And only the last one is actually references by the mesh node.
I can't figure out where it comes from.

Perfect, as it relates to this "issue":
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/39
NLA tracks cannot be exported at the moment. But we will add them soon, and then also this Blender file will work.

The scene is a little bit "messy", as there are many elements, which are not used. This could probably cause the dublications. I cleaned it up, and then only one skin is exported (see attachment).
At the moment - as NLA is not yet supported - only the first animation is exported and used:

Jaime.zip

Nice thanks. well, the mess is kind of the point. What did you clean up exactly? (seems you removed the bone shapes in the last layer, but was it really producing this issue?)
We use this file since quite some time and it's pretty much my crash test for exporters. If I have to clean it for gltf so be it, but I'd just like to know what to clean up for future references.

Well, actually I did not clean anything up. I deleted some objects, but as they still have users, they are still somehow used.
Well, you do not neet to clean it up. The exported file will somehow not be optimal.

Ok, I'll try to figure it out, It's good to know it's possible ;)
Thanks again for your time.

Thanks for your time as well. Probably we will mark the current exporter branch as stable soon and start implementing the enhancements. And, from the community feedback, NLA tracks are top.
Also, I will use your "stress" file to test :-)

Be my guest ;)

Transferring this issue to the new project repository (https://github.com/KhronosGroup/glTF-Blender-IO/). But unfortunately Blender 2.8 crashes when I try to open this file. 🙃 Not sure if that's the file, or a problem with the  Blender 2.8 beta.


panic: runtime error

I made a Signal backup (554MB) today, then attempted to use:
v0.1.6-alpha.1 binary
v0.1.5 stable binary
git clone compiled code.
All produced a panic when using commands extract or analyse.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x566634]

goroutine 1 [running]:
github.com/xeals/signal-back/cmd.ExtractAttachments(0xc4200dc0e0, 0x6, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/cmd/extract.go:68 +0x134
github.com/xeals/signal-back/cmd.glob..func2(0xc420088420, 0x0, 0xc420088420)
        /home/travis/gopath/src/github.com/xeals/signal-back/cmd/extract.go:43 +0x8c
github.com/xeals/signal-back/vendor/github.com/urfave/cli.HandleAction(0x5939a0, 0x5dacf0, 0xc420088420, 0xc420082100, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:490 +0xc8
github.com/xeals/signal-back/vendor/github.com/urfave/cli.Command.Run(0x5cf178, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5d66e7, 0x24, 0x5d6b6a, ...)
        /home/travis/gopath/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/command.go:210 +0xa36
github.com/xeals/signal-back/vendor/github.com/urfave/cli.(*App).Run(0xc4200841a0, 0xc4200760f0, 0x5, 0x5, 0x0, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:255 +0x6a0
main.main()
        /home/travis/gopath/src/github.com/xeals/signal-back/main.go:51 +0x2e1

Using Arch Linux 4.17.3-1-ARCH, golang version 1.10.3.

same problem here with 0.1.6-alpha.1 windows.amd64 binary and a ~65 MB backup file.

seems to be a duplicate of https://github.com/xeals/signal-back/issues/12

I'm not sure what's causing this, to be honest. I'm tempted to say it's architecture-dependant, as for me:

the same binary
the same operating system
the same backup file
different CPU, RAM, etc.

produces different results; one gets this error, and the other can read things fine. Are people encountering this issue also able to share their system information, to see if it can be narrowed down?
I'm segfaulting on Linux, Ryzen R5 1600, but completely fine on Linux, Intel i7-5500U.

I was segfaulting on Arch Linux, Intel E8400.  The software has changed since then (kernel, Go) so I will recompile and see if I get the same result.

I also experience the seg fault issue:
signal-back format -f XML signal-2018-10-21-21-08-04.backup > backup.xml
Password: xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x584874]

goroutine 1 [running]:
github.com/xeals/signal-back/types.(*BackupFile).DecryptAttachment(0xc0000e80e0, 0xc0bd7cc390, 0x7f3f95c07080, 0xc000010d80, 0xc000010d80, 0x5cc640)
	/home/ronald/go/src/github.com/xeals/signal-back/types/backup.go:141 +0x124
github.com/xeals/signal-back/cmd.XML(0xc0000e80e0, 0x632980, 0xc00000c018, 0x3, 0x1)
	/home/ronald/go/src/github.com/xeals/signal-back/cmd/format.go:163 +0x718
github.com/xeals/signal-back/cmd.glob..func4(0xc000094580, 0x0, 0x0)
	/home/ronald/go/src/github.com/xeals/signal-back/cmd/format.go:70 +0x3fc
github.com/xeals/signal-back/vendor/github.com/urfave/cli.HandleAction(0x5c20e0, 0x60b998, 0xc000094580, 0xc000068200, 0x0)
	/home/ronald/go/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:490 +0xc8
github.com/xeals/signal-back/vendor/github.com/urfave/cli.Command.Run(0x5ff162, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x605590, 0x1f, 0x60ac2a, ...)
	/home/ronald/go/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/command.go:210 +0x990
github.com/xeals/signal-back/vendor/github.com/urfave/cli.(*App).Run(0xc0000921a0, 0xc00000e050, 0x5, 0x5, 0x0, 0x0)
	/home/ronald/go/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:255 +0x687
main.main()
	/home/ronald/go/src/github.com/xeals/signal-back/main.go:52 +0x2d0

Os version
Distributor ID:	Ubuntu
Description:	Ubuntu 17.10
Release:	17.10
Codename:	artful

signal-back version (self compiled)
signal-back devel
proto commit: d6610f0

go-version (binary download)
go version go1.11.1 linux/amd64

My signal-xxx.backup file is 3.2 GB

I have the same issue with the signal-back_windows_amd64.exe build. The extract command worked perfectly, I have successfully extracted al my media files from the backup but the format command does not work: I get an empty backup.xml file.
Any suggestions?
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x8 pc=0x57b9bf]

goroutine 1 [running]:
github.com/xeals/signal-back/cmd.XML(0xc0420c80e0, 0x606e40, 0xc042004008, 0x3, 0x1)
        /home/xeal/.local/share/go/src/github.com/xeals/signal-back/cmd/format.go:160 +0x15f
github.com/xeals/signal-back/cmd.glob..func4(0xc042086420, 0x0, 0x0)
        /home/xeal/.local/share/go/src/github.com/xeals/signal-back/cmd/format.go:67 +0x416
github.com/xeals/signal-back/vendor/github.com/urfave/cli.HandleAction(0x5a6140, 0x5ef668, 0xc042086420, 0xc04204a100, 0x0)
        /home/xeal/.local/share/go/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:490 +0xcf
github.com/xeals/signal-back/vendor/github.com/urfave/cli.Command.Run(0x5e20ed, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5e96cb, 0x1f, 0x5ee97c, ...)
        /home/xeal/.local/share/go/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/command.go:210 +0xa3d
github.com/xeals/signal-back/vendor/github.com/urfave/cli.(*App).Run(0xc0420821a0, 0xc04207a000, 0x9, 0x10, 0x0, 0x0)
        /home/xeal/.local/share/go/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:255 +0x6a7
main.main()
        /home/xeal/.local/share/go/src/github.com/xeals/signal-back/main.go:52 +0x31e

I am running into this problem, too. Archlinux, Kernel 4.20.6, go 2:1.12-1, 16 GB RAM.
signal-back v0.1.7-alpha.2-1-g7b9bc21-dirty
proto commit: d6610f0
Backup is 1.3 Gb, I am sure, I was once able to extract one with 3 GB. I also tried XML. Raw export works nevertheless and gives me a text file with very long lines.```
 [rob@r]$ signal-back_linux_386 format -f CSV -o a.csv -P signal_pass signal.backup
 panic: runtime error: makeslice: len out of range

 goroutine 1 [running]:
 signal-back/vendor/github.com/xeals/signal-back/types.(*BackupFile).Frame(0xa452140, 0x10e90a50, x0, 0x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/xeals/signal-back/types/backup.go:94 +0xc8
 signal-back/vendor/github.com/xeals/signal-back/cmd.CSV(0xa452140, 0x81ee1b0, 0x3, 0x821fb10, xa40e008, 0x0, 0x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/xeals/signal-back/cmd/format.go:93 +0x3f
 signal-back/vendor/github.com/xeals/signal-back/cmd.glob..func4(0xa47e210, 0x0, 0x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/xeals/signal-back/cmd/format.go:65 +0x29d
 signal-back/vendor/github.com/urfave/cli.HandleAction(0x81c0fa0, 0x81fb5bc, 0xa47e210, 0xa47ac00, x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/urfave/cli/app.go:490 +0xa2
 signal-back/vendor/github.com/urfave/cli.Command.Run(0x81eec4a, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, x81f4fbe, 0x1f, 0x81fa3da, ...)
         /home/rob/prog/go/src/signal-back/vendor/github.com/urfave/cli/command.go:210 +0x8e4
 signal-back/vendor/github.com/urfave/cli.(*App).Run(0xa400a80, 0xa410050, 0x9, 0xa, 0x0, 0x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/urfave/cli/app.go:255 +0x566
 main.main()
         /home/rob/prog/go/src/signal-back/main.go:52 +0x1fb

 [rob@r]$ signal-back_linux_amd64 format -f CSV -o a.csv -P signal_pass signal.backup
 panic: runtime error: invalid memory address or nil pointer dereference
 [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x594179]

 goroutine 1 [running]:
 signal-back/vendor/github.com/xeals/signal-back/cmd.CSV(0xc0000e40e0, 0x5fb38c, 0x3, 0x62e980, xc00000c008, 0x0, 0x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/xeals/signal-back/cmd/format.go:107 +0xb9
 signal-back/vendor/github.com/xeals/signal-back/cmd.glob..func4(0xc000092420, 0x0, 0x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/xeals/signal-back/cmd/format.go:65 +0x342
 signal-back/vendor/github.com/urfave/cli.HandleAction(0x5bfba0, 0x609008, 0xc000092420, xc000064200, 0x0)
         /home/rob/prog/go/src/signal-back/vendor/github.com/urfave/cli/app.go:490 +0xc8
 signal-back/vendor/github.com/urfave/cli.Command.Run(0x5fbe36, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, x602223, 0x1f, 0x6077bd, ...)
         /home/rob/prog/go/src/signal-back/vendor/github.com/urfave/cli/command.go:210 +0x9a2
 signal-back/vendor/github.com/urfave/cli.(*App).Run(0xc00008e1a0, 0xc00000e090, 0x9, 0x9, 0x0, x0)
        /home/rob/prog/go/src/signal-back/vendor/github.com/urfave/cli/app.go:255 +0x687> main.main()
        /home/rob/prog/go/src/signal-back/main.go:52 +0x2d0

I typed in the following and got this error message. Could you please help??

signal-back_windows_386 format -f CSV -o backup.xml signal-2021-03-10-10-14-21.backup
Password: Password: xxxxx xxxxx xxxxx xxxxx xxxxx xxxxx
panic: runtime error: makeslice: len out of range

goroutine 1 [running]:
github.com/xeals/signal-back/types.(*BackupFile).Frame(0x11206080, 0x11f53950, 0x0, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/types/backup.go:110 +0xc4
github.com/xeals/signal-back/types.(*BackupFile).Consume(0x11206080, 0x111e2120, 0x111e2140, 0x111ea0e0, 0x0, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/types/backup.go:242 +0xaf
github.com/xeals/signal-back/cmd.CSV(0x11206080, 0x5bcf6f, 0x3, 0x5e59c0, 0x111e20e0, 0x0, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/cmd/format.go:105 +0xd6
github.com/xeals/signal-back/cmd.glob..func4(0x111ee2c0, 0x0, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/cmd/format.go:68 +0x29c
github.com/xeals/signal-back/vendor/github.com/urfave/cli.HandleAction(0x58d0c0, 0x5cba80, 0x111ee2c0, 0x1120ec00, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:490 +0xa2
github.com/xeals/signal-back/vendor/github.com/urfave/cli.Command.Run(0x5bda88, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5c5635, 0x1f, 0x5cadd0, ...)
        /home/travis/gopath/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/command.go:210 +0x8e1
github.com/xeals/signal-back/vendor/github.com/urfave/cli.(*App).Run(0x111de2a0, 0x11206000, 0x7, 0x8, 0x0, 0x0)
        /home/travis/gopath/src/github.com/xeals/signal-back/vendor/github.com/urfave/cli/app.go:255 +0x58b
main.main()
        /home/travis/gopath/src/github.com/xeals/signal-back/main.go:52 +0x210


RPC calls to running PseudoNode instance

Is there is no way to query PseudoNode (and therefore query connected peers) for a specific block/header/tx?
How can this be most easily implemented?  This project is so close!

No, this project was originally written for fun and the original implementation was not very good.  I made some effort to improve it some time ago, but then there was not so much interest so it is left "as is".  It is a shame since it provides a very lightweight method for "joining" the network, which can have some useful applications.
So, the current implementation is WYSIWYG, and any new features you'll need to add yourself.


Browser hangs due to infinite loop when editing groups

Describe the bug
In DSpace v8, there is a bug when editing (access control) groups under certain circumstances (see steps to reproduce). As a result, the browser hangs due to an infinite loop and the target page is never reached.
To Reproduce

Login as admin
Go to "EDIT > COLLECTION".
Select any collection - e.g. "Statistics > Books"
Click on "Assign Roles"
Click on any link to edit a group -- if none exists, create one using the UI buttons, in my case on "sandbox.dspace.org" the group is called "COLLECTION_7f052d6e-f7f7-4661-8347-701016969365_WORKFLOW_ROLE_editor".
Scroll down to the last section called "Groups" and click any link in the paginated table, for example, the "Administrator" item.
Now an endless loop starts, the browser hangs after a while and the UI gets stuck, the target link is never reached

While debugging or logging on the console, you can see (at least) in this line - https://github.com/DSpace/dspace-angular/blob/ee7e8358e7e0fd0b69f7c2e308d539670a103026/src/app/access-control/group-registry/group-form/group-form.component.ts#L537 - that this function is called in an infitine loop.
Other click sequences do not necessarily lead to the problem.
Expected behavior
The click on the link should not lead to an infinite loop.

Moving this to the maintenance board & flagging as high priority.  I have not verified the behavior myself, but it sounds like a bug.  Someone should also verify whether the same bug appears in 7.6.x or not.

Hi, I've replicated the issue in a 8.x instance, and can confirm that this does not happen in a 7.6.2 instance.

Thanks @alexandrevryghem !  Assigned to you


[Plugin Proposal] Spam: Alert user that they might be spamming

TODO: Improve issue description
Earlier issue : https://gitlab.com/coala/cobot/issues/16

Can I take up this issue ? :smile:


Allow hijacking a SpriteComponent's drawing.

That is, temporarily re-parenting it so that it is drawn in another context, such as the hands GUI in content.

This is done.


add view files

In this PR:

I Implemented the design from the sneak peek wireframes

I have been waiting for 3hrs now


Infra Integration Playground

Summary

Status: draft
RFCs: Link to RFC, Link to RFC, or $\emptyset$.
Categories: any of protocol-units, networks, scripts, util, cicd, or misc.

Changelog

Testing

Outstanding issues

Gali PR:


In-collection search

Added a search box to the sidebar of the collection view to search within a collection


deserializeUint8ArrayBitListFromBytes ssz api performance issue

Describe the bug
This ssz api takes 2.5% time of a holesky node subscribing to all subnets

holesky_subscribe_all_subnets_main.cpuprofile.zip
Expected behavior
I see some Uint8Array.slice() api there, see if we can improve by using Uint8Array.subarray() to avoid memory allocation
part of #7186
Steps to reproduce
No response
Additional context
No response
Operating system
Linux
Lodestar version or commit hash
unstable and v1.22.0

getAggregationBitsFromAttestationSerialized() really caused gc due to its memory allocation


apps/blemesh_shell: Friend sends Offers even when disabled

This issue is not verified and needs further investigation.

I was not able to reproduce it.


Search results page always contains only one page

https://demo.getsaleor.com/search/?q=jo returns only one page but there are actually more results. We've found that it's caused by results = list(results) at https://github.com/mirumee/saleor/blob/master/saleor/search/views.py#L29. If you remove this line then search works correctly.

PR #1161


Signaling changes

Create signals on changes in method (as described in #12).

Must add blinker to requirements.txt and install_requires on setup.py.


Are large RecordBatches chunked into smaller size messages ?

Describe the usage question you have. Please include as many useful details as  possible.
Based on the docs the RecordBatch in rust is split into approximately 2MB chunks to comply with the recommendation of gRPC of messages not exceeding 4 MB. Is this true across the board in any language that has support for ArrowFlight ?
Component(s)
FlightRPC

For other implementations, you would probably have to do this yourself.

For C++/Python, for a client writing to a server, you can set an optimistic limit with write_size_limit_bytes: https://arrow.apache.org/docs/python/generated/pyarrow.flight.FlightClient.html#pyarrow.flight.FlightClient
If a batch is too big, you get an exception you can catch, and you can retry the write after splitting it.

I’m specifically interested in https://arrow.apache.org/rust/arrow_flight/encode/struct.FlightDataEncoderBuilder.html
equivalent in cpp/python - with_max_flight_data_size
My question is about a client reading from a server.

Then it's not available. The server needs to do it.


Don't drop empty object during merge

We currently drop empty objects when during set({merge: true}) since we only add leaf nodes to the field mask. We need to consider an empty object a leaf node.
Port of firebase/firebase-js-sdk#1202

This caused a serious issue for us. Assuming we already have document.items, where items is a dictionary contains existing keys/values.
Now, if we update that document, with items set to an empty object {}, merge flag is true, existing items will be dropped, returning a new empty document.items, while we expect update/set with merging flag is true should keep the existing data, not wiping them {object }+ {} = {object}, not empty. Please reconsider this PR.

We will discuss your comment internally. Note that you can make the behavior of set() explicit by providing the list of field paths you wish to merge. This will override any setting on our end.


dropdown and AutoSetListHeight

I'm so sorry (but welcome to my life)
A bug that i noticed before, but were never able to reproduce in a consistent fashion. I had a way to avoid it entirely, but it's apparently not reliable, as i have users complaining about it now.
simply put, things like that:
      DropDown terraintype = new DropDown(new Vector2(0, 40), Anchor.Auto)
        {
            OnValueChange = (Entity entity) =>
            {
                World.MapSetup.TerrainType = ((DropDown)entity).SelectedValue;
            }
        };
        var id = 0;
        var nb = 0;
        foreach (var item in World.DB.TerrainPresets)
        {
            terraintype.AddItem(item.Key);
            if (item.Key.ToLower() == "mixed")
                id = nb;
            nb++;
        }
        terraintype.SelectedIndex = id;
        terraintype.AutoSetListHeight = true;
        LeftPanel.AddChild(terraintype);

can trigger a crash when the user click on the dropdown (can't reproduce but here's a trace https://pastebin.com/GVWKUfme ).
Setting the selectedindex after autosetlistheight can trigger a crash too, on rendering/update, but that i managed to avoid. I would love to be more precise, but it's definitely not consistent, or at least i haven't found what would make it consistent.
Might have something to do with me setting up the size vector, which is apparently for the underlying select list, and not the drop-down itself. I'm not sure, but any pointer would be super helpful.
Cheers.

Woha that's a serious bug, crashing the game is not cool at all.
Not sure when I'll have time to dive into this (looks a bit tricky too), but may I suggest that until its solved wrap this call with try-catch and some default handling, so it won't crash your clients..
Ofc if you find any additional data let me know..
Thanks,

Fixed, currently in a branch, will be merged and released soon.
Thanks!

Thank you! Sorry i couldn't get back to you earlier, I've been kept extremely busy these last few weeks.


prometheus-hystrix not working with micrometer.io libraries

This no longer works. It appears that micrometer.io has replaced it. I have:
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
        <groupId>de.ahus1.prometheus.hystrix</groupId>
        <artifactId>prometheus-hystrix</artifactId>
    </dependency>
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-core</artifactId>
    </dependency>
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-registry-prometheus</artifactId>
    </dependency>

But never do I see a hystrix_command_event_total, after many calls to apis have been made, in the output of /actuator/prometheus. I see a lot of micrometer output but nothing from prometheus-hystrix.
Does you library no longer work now that we have micrometer.io?

If you want to see this libraries version of the metrics, you probably want to disable micrometers metrics on Hystrix.
You can do this with a configuration option management.metrics.binders.hystrix.enabled like I did in the following configuration:
https://github.com/ahus1/prometheusspringbootminimal/blob/master/src/main/resources/application.properties#L14
Please note that this is the spring boot 2.x name of the option. Earlier I think it was called
management.metrics.export.hystrix.enabled
I can dig deeper into this once you name the versions you use, but only in the week after next week.

This ticket has been open for quite some time. If you're using Micrometer, IMHO you should use Micrometer to report Hystrix metrics. Still if you prefer, you can use both reportings.


Explore how difficult it would be to have LU+ output maps of biomass removed instead of just a text file

Similar to most other extensions, it would be nice if we could optionally choose to have LU+ output maps (but this is not a high priority).

This functionality appears to exist in Extension Biomass Harvest, which now works properly in tandem with LU+. Closing pending more specific instructions


Bump to v2.8.1

Overview

Bump to SCIM bridge version 2.8.1

Checklist

[X] review the guide to contributing

Pods running and healthy with new chart:
op-scim-bridge-5f5555586d-bm899                     1/1     Running   0             2m7s
op-scim-bridge-redis-master-787c7f4c44-h6pb8        1/1     Running   0             2m7s


Unhandled Promise Rejection error when opening build

Describe the bug
I build my app for Windows, zip. When opening the app I receive an error message. The app starts successfully after clicking "Ok"
To Reproduce
Steps to reproduce the behavior:

Build the app
Start the app

Expected behavior
The app shouldn't error at the start
Screenshots
Screenshot
Desktop (please complete the following information):

OS: Windows

I get the same error.
I created a new angular project with Ionic then added electron.
I can run the app without errors with npm run electron:start
If I start it with
npx cap open @capacitor-community/electron
or if I build with either electron:pack or electron:make and run the built exe file I also get the same error.


Parsing {} + 1 (and similar) results in strange behavior

I'm trying to parse some JS code in the following way:
var jsText = "{} + 1;";
var scriptEnv =
  ScriptEnvironment.builder
    .ecmaScriptVersion(9)
    .constAsVar(false)
    .earlyLvalueError(true)
    .emptyStatements(false)
    .syntaxExtensions(true)
    .scripting(false)
    .shebang(false)
    .strict(true)
    .functionStatementBehavior(ScriptEnvironment.FunctionStatementBehavior.ERROR)
    .build();
var src = Source.sourceFor("name", jsText);
var errManager = new ErrorManager.ThrowErrorManager();
var parser = new Parser(scriptEnv, src, errManager);
var parsed = parser.parse();

However,  parsed.getBody().getStatements() gives me the following strange result (println'ed it in Clojure but you get the point):
[#object[com.oracle.js.parser.ir.BlockStatement 0x50b49634 ""]
 #object[com.oracle.js.parser.ir.ExpressionStatement 0x6c97ac34 "+1"]]

The same thing happens when trying to parse {} /* comment */ + 1; and with function () { {} + 1 };.
A similarly weird thing happens when parsing {} + {}, {} + ({}), function () { {} + {}; }; and function () { {} + ({}); };:
[#object[com.oracle.js.parser.ir.BlockStatement 0x3fa072 ""]
 #object[com.oracle.js.parser.ir.ExpressionStatement 0x321b8ee5 "+{}"]]

And when parsing {a: 2} + 1;:
[#object[com.oracle.js.parser.ir.BlockStatement 0x31b9fec0 "a:;"]
 #object[com.oracle.js.parser.ir.ExpressionStatement 0x2f92a550 "+1"]]

Parsing {} === {}; and {a: 2} === {} flat out fails, while ({}) === {} works as expected.
However, parsing ({} + 1); and ({}) + 1 works as expected:
[#object[com.oracle.js.parser.ir.ExpressionStatement 0x37c1a37f "{} + 1"]]

1 + {}; works in any context:
[#object[com.oracle.js.parser.ir.ExpressionStatement 0x64933fa "1 + {}"]]

Likewise, the following work:

({}) + {}
({a: 2}) + 1
({a: 2}) + {}
function () { return {} + 1 };
function () { var a = {} + 1; };
function () { ({} + 1); };
function () { ({}) + 1; };
function () { return {} + {}; };
function () { var a = {} + {}; };
function () { ({}) + {}; };

This is probably a low-priority bug (hopefully few people are going to do this in the real world), but there may be additional ramifications from it that I'm not aware of.
Let me know how I can help with this.

I believe that this is a misunderstanding. It is correct that parsing of {} + 1 does not produce the same result as ({} + 1). Please, check the JavaScript grammar in the specification. Both are parsed as Script->ScriptBody->StatementList. If the code starts with { then we proceed through StatementList->StatementListItem->Statement->BlockStatement, it cannot be ExpressionStatement because its lookahead excludes {. So, the parsing of {} + 1 results in an empty block ({}) followed by an expression (+1).
The situation is different with ({} + 1). Full details are more complicated here (so, I will omit them) but the main result is that the initial ( will get us to CoverParenthesizedExpressionAndArrowParameterList. So, the part enclosed in parenthesis must be Expression. So, {} is ObjectLiteral not Block now, i.e., we get an expression where + operator is used on an object literal and a constant.

Thanks so much for pointing out my error @iamstolis. {} + 1 evaluated in the latest Chrome yields 1 as you effectively point out.
However, AFAIK this does not invalidate any of my other observations. For instance, {} + {} evaluated in the latest Chrome yields "[object Object][object Object]", not "[object Object]" as the GraalVM parser would suggest.

I have no idea why the evaluation of {}+{} in Chrome yields [object Object][object Object] but the correct result (when this input is parsed as Script) is NaN. It is an empty block ({}) followed by a unary operator (+) applied to an object literal. Of course, ({}+{}) is another story (as I mentioned above). Note that even Chrome will give you NaN if you evaluate eval('{}+{}').

Note that even Chrome will give you NaN if you evaluate eval('{}+{}').

Very good point. So that appears to be a bug in Chrome, not in GraalJS; my apologies.
All right so, so much for {}+{} and {}+1. This leaves us only with:

Parsing {} === {}; and {a: 2} === {} flat out fails, while ({}) === {} works as expected.

In Chrome, {} === {} yields false. However, I'm just now seeing that eval('{} === {}') yields "unexpected token ===" which is what GraalJS yields too. Same story with {a: 2} === 2. So this appears to actually a bug in Chrome as well.
All right, I'm closing this ticket since all these things I mentioned are actually bugs in Chrome, not in GraalJS (impressive job on the parsing work!). I incorrectly assumed Chrome would be a suitable reference implementation.
Keep up the good work! I appreciate it all!

all these things I mentioned are actually bugs in Chrome

One can perceive it like this but I am sure that Chrome guys know what they are doing here (i.e. have this behavior intentionally). As you have seen, JavaScript is tricky in that it sometimes parses {...} as Block and sometimes as ObjectLiteral. I think that they try to help their users to avoid the common pitfalls by trying to parse the input first as expression (despite the specification requires something else).
Note that, for example, REPL of Node.js does it as well. They have another nice example it the corresponding comment: {a:1}. While the specification says that this is a block with a label (a) for the constant 1 (which can be very confusing for majority of users) they prefer to interpret it as object literal (with a property a with value 1).

Ah, that makes sense. Thanks for your clarifications @iamstolis!


Android screengrub on windows

What is wrong here or is it impossible in principle?

What happens if you type appt in your command line? If it gives you an error, you need to find your local path of it and att that to the PATH env var. (But Windows support might be spotty in general.)

What happens if you type appt in your command line? If it gives you an error, you need to find your local path of it and att that to the PATH env var. (But Windows support might be spotty in general.)

What should be the path? I got a similar error on mac os. Why is this not in the guides?

Because when having a working Android SDK or Studio installation, this is usually taken care of.
I am happy to merge a PR to the documentation that includes these instructions when you figure it out.

What should be the path?

That depends on your system where you installed the Android SDK and tools.

Because when having a working Android SDK or Studio installation, this is usually taken care of.
I am happy to merge a PR to the documentation that includes these instructions when you figure it out.

What should be the path?

That depends on your system where you installed the Android SDK and tools.

What did I forget or did wrong?

The error message is about aapt. You need to make sure that is runnable directly in the command line.

The error message is about aapt. You need to make sure that is runnable directly in the command line, then it will hopefully work via fastlane as well.

I added to path %ANDROID_HOME%\build-tools\30.0.0
But error:
The adb command could not be found relative to your provided ANDROID_HOME at E:\Android\Sdk
Please ensure that the Android SDK is installed and the platform-tools directory is present
[!] adb command not found


Build fails on OS X 10.11.4

➜  Source git:(preview) brew install sdl2_ttf
Warning: sdl2_ttf-2.0.14 already installed
note: ld: library not found for -lSDL2_ttf
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: aborting due to previous error
error: Could not compile rs_doom.
➜  Source git:(preview) rustc --version
rustc 1.8.0

Weird! Can you run any rust program which uses sdl2_ttf ? Could you try the example on https://github.com/andelf/rust-sdl2_ttf ?
Thanks for the issue!

Thanks for the link. That doesn't work either so I'll close this and investigate my end.


[CM automation recipes] develop OS and platform detection plugins

platform
os
soft + env
virtual env
docker

will be done in the CK2 dev repo


Unable to hot reload maccatalyst

Hello! Thank you for the great library!
I have problem with hot reload for maccatalyst
my-new-project % dotnet maui-reactor -f net8.0-maccatalyst
MauiReactor Hot-Reload CLI
Version <IP_ADDRESS>
Press Ctrl+C or Ctrl+Break to quit
Setting up build pipeline for my-new-project project...done.
Monitoring folder '/Users/alex/source/test/my-new-project'...
Detected changes to 'Pages/MainPage.cs'
Replacing syntax tree for: Pages/MainPage.cs
Connecting to Hot-Reload server (Port: 45821)...Unable to hot reload the application:
System.Net.Sockets.SocketException (61): Connection refused
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Net.Sockets.Socket.<ConnectAsync>g__WaitForConnectWithCancellation|285_0(AwaitableSocketAsyncEventArgs saea, ValueTask connectTask, CancellationToken cancellationToken)
   at System.Net.Sockets.TcpClient.CompleteConnectAsync(ValueTask task)
   at MauiReactor.HotReloadConsole.HotReloadClient.SendAssemblyFileToServer(MemoryStream stream, MemoryStream pdbStream, CancellationToken cancellationToken) in D:\a\reactorui-maui\reactorui-maui\src\MauiReactor.HotReloadConsole\HotReloadClient.cs:line 297
   at MauiReactor.HotReloadConsole.HotReloadClient.ConnectionLoop(CancellationToken cancellationToken) in D:\a\reactorui-maui\reactorui-maui\src\MauiReactor.HotReloadConsole\HotReloadClient.cs:line 154

but with iOS hot reload works perfectly

Maybe it's a permission problem, can you ensure that the app is not running under sandbox:
Platforms->MacCatalyst->Entitlements.plist
        <key>com.apple.security.app-sandbox</key>
        <false/>

You must set it to true again when you publish to the app store

This solved my problem, thanks!


ARXIVNG-461 Moderation activity scenarios

This simulates holds that occur as a result of moderation activity in the classic system. This does not implement moderation functionality for NG components. I focused on patching the submission representation with hold status (including sticky holds) based on the state of the classic database. I also added a few things that were missing in the submission data handlers, and simplified a few things so that exceptions percolate in expected ways.

Coverage increased (+0.4%) to 92.261% when pulling 08ab5f3a7a79d0b1b3685909e1c8261f5c36b06f on ARXIVNG-461 into 0c2928004d508fc9d5800ac66416682b221c5da0 on develop.

@mhl10 Adding you since we discussed some of these topics earlier; did I get this roughly correct?

Yeah, not sure why I didn't think of that (the comments) before. Will leave this open for the morning in case @mhl10 or @dlf2 have a chance to verify; always paranoid about missing something obscure in the classic DB


change: Make FileTransfer explicitly async

What do you say about this change?
FileTransfer is already async, so let's make that explicit and "by-the-book". By returning the Task we let the caller know when we're finished without interpreting the callback parameters. It also avoids unobserved exceptions if e.g. we get a timeout exception when sending a command/reply pair. Now those exceptions bubble up the caller instead of potentially crashing the process.

Does this change break existing code that uses this function?

No, it won't change a thing. It just gives the caller an option to handle the Task (which he should). If he chooses not to await it, functionality will be identical to today.
I'm also thinking it would be great if FileTransfer would throw in all cases where the transfer was not successful. But I think that can be handled in future improvements.


Currently not working for doc build

After some of Chris's structural changes the only things I didn't have building properly were:

[x] Fig j and Fig 36 (forecast projections), which call make.forecast.depletion.comparison.plot() that then calls SSplotComparisons() which doesn't seem to make a plot.
[ ] Fig 55 and 56 - retropsectives - lines not showing up

I haven't updated all the packages and these may just get resolved automatically in due course anyway. But this might be why a new build doesn't work. Everything else is good.
For the record (mainly for me!), I did the flagging2023 branch then wanted to merge it in, fixed a conflict, then had to fetch and do a rebase, but the full merge hadn't gone through so everything got rebased. Many of my commits in the main branch were done before some of Chris's that rename the folder structure, so the doc won't build on my final da596c5 commit, even though I it building on that commit in the flagging2023 branch.

Retrospectives not showing up as not built yet for 2023, some figs not working but issues have been made (I think for all), so closing.


Create interface for OSS-Fuzz users.

Related: https://github.com/google/oss-fuzz/issues/7479

@jonathanmetzman I wonder if the idea is to make it possible to replace CIFuzz with CFLite with the "oss-fuzz" setting? If not, I think it would be better if it was possible to use corpora, old builds and coverage separately. For example the branches I fuzz with CFLite diverge from the main branch so usually I don't need coverage and old builds. I always download public OSS-Fuzz corpora though.

As far as I understand if CFlite could download corpora itself if something like oss-fuzz-corpora was set https://github.com/google/clusterfuzzlite/issues/84 would be kind of automatically fixed.

@jonathanmetzman I wonder if the idea is to make it possible to replace CIFuzz with CFLite with the "oss-fuzz" setting?

It is sort of my intent. It isn't quite a drop-in replacement because you still need the .clusterfuzzlite/Dockerfile and project.yaml.

If not, I think it would be better if it was possible to use corpora, old builds and coverage separately. For example the branches I fuzz with CFLite diverge from the main branch so usually I don't need coverage and old builds. I always download public OSS-Fuzz corpora though.

I'm making a feature to skip the old builds.
That would only leave you with the corpus downloading and coverage (which is broken right now for your project anyway, leading to all fuzzers being run unless there is a crash).
You would still need to do the .clusterfuzzlite stuff (which I guess you are doing anyway to cover branches) so doesn't the above suit your needs?
I understand that a download oss-fuzz corpus feature would make your life easiest, but it would either be ugly or require significantly changing how corpora are dealt with currently (we have classes for oss-fuzz and (standard) CFL users
that control the interaction with the outside world (e.g. uploading crashes, downloading/uploading corpora, downloading/uploading builds, downloading/uploading coverage). I'm open to changing this design but it will probably take longer than for me to implement this.

coverage (which is broken right now for your project anyway, leading to all fuzzers being run unless there is a crash)

I think systemd is broken but for example elfutils is fine and there I'd prefer to avoid using coverage. I can do that by setting the "keep-unaffected-fuzz-targets" setting explicitly though.

doesn't the above suit your needs?

I'm not sure. I need to take a closer look.

Why couldn't it use these on commits? Those can also be fuzzed with code-change fuzzing (though I don't think this is documented).

Why couldn't it use these on commits? Those can also be fuzzed with code-change fuzzing (though I don't think this is documented).

In theory it should be possible but for that to work CFlite should somehow keep track of what changes between two push events. Without that it can just run all the fuzz targets.

Why couldn't it use these on commits? Those can also be fuzzed with code-change fuzzing (though I don't think this is documented).

In theory it should be possible but for that to work CFlite should somehow keep track of what changes between two push events. Without that it can just run all the fuzz targets.

I don't think it strictly needs to keep track of what happens between pushes. It just needs to know what branch we are merging into and what's the diff from that branch that a change introduces. Once it knows this, it just needs some coverage to download.

It just needs to know what branch we are merging into and what's the diff from that branch that a change introduces

My understanding is that commits aren't merged there. They are pushed directly to various branches and CFLite can't get those diffs in its current form.

It just needs to know what branch we are merging into and what's the diff from that branch that a change introduces

My understanding is that commits aren't merged there. They are pushed directly to various branches and CFLite can't get those diffs in its current form.

Right I misused the term "merge". Anyway I think based on you running CIFuzz against commits, this should work but I could be wrong. I'll stop speculating on it though :-)

FWIW I think https://github.com/google/oss-fuzz/issues/7479 can already be covered with CFLite with a for-loop like https://github.com/systemd/systemd/pull/22302 so I'd just stop using CIFuzz there and fix the build script without any changes to CFLite. Then again, I'm not sure how the branches and the fuzzing infrastructure are maintained there. My use cases are different in the sense that I need to support forks and multiple branches changed via PRs in systemd and PRs opened against a fork of elfutils so I'm not sure I'm going to use the "oss-fuzz" setting.


Document how to migrate from MJML to React Email

As part of this I would also love if there is a comparison to MJML and why one could migrate.

Same here, I saw people asking on Twitter what's the difference with MJML and why use one over the other, but I couldn't find any answer 😅

Also some guides like I'm trying to migrate and in mjml there is a wrapper component. Which is the equivalent here or how should I compose them.


sim: launch_openpilot.sh fix and YUV to NV12 output

Fix for openpilot not launching during simulation: #25493

Output images in NV12 format during simulation: #25451

Converting is done from  YUV to NV12, not from RGB to NV12 directly.
I tried changing rgb_to_yuv.cl to real_debayer.cl, but I am not able to compile the cl program. Also I am not sure if that will work.
Nevertheless, a todo is

swapping to real_debayer.cl or creating a dedicated rgb_to_nv12.cl program.

This is also something I tried to create, but I had the same issue as mentioned above (see image).

I know what's going wrong, however I don't know the proper way to fix this in the codebase (I thought SCons would handle building).

updated requirements and now it works again. Case closed.


qt.qpa.plugin error

hi, I run python people_counter.py --prototxt detector/MobileNetSSD_deploy.prototxt --model detector/MobileNetSSD_deploy.caffemodel --input utils/data/tests/test_1.mp4 and get the error, could you help?
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/home/flash/anaconda3/envs/pc/lib/python3.11/site-packages/cv2/qt/plugins" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

solved after sudo apt install qt6-base-dev, thanks


adding the ability to log hyperparameters associated with a training run

Resolves
Fixes #76
Description
This is a start on a feature to log hyperparameters during a training run. Current implementation looks at the Options object within each Trainer class and logs them to HyperParameter table entity.
Hi @aslotte . @lqdev
Not sure if this is the right approach,As a start i had to use reflection to get access to the HyperParameters in a generic way. Let me know what you guys think.
await manager.LogHyperParametersAsync<LbfgsLogisticRegressionBinaryTrainer>(runId, trainer);
I used with the ReviewPredictor sample project that you created alex and logged the parameters and This is what it produces.

Fascinating idea @AnoojNair, I think we could definitely use this.
A couple of thoughts:

Would it be possible to add some unit tests to test this functionality?
I'm sure the library Dynamitey is useful but I actually think the code will be more readable just using reflection

@lqdev - I think you have more insight into the ML.NET API, let us know if you think another approach would be better.

Hi @aslotte ,
I tried the reflection way using the below but always ended up with null and hence went a ahead with the package. Do you know what could be the reason? Happy to remove it if there is an alternative.
trainer.GetType().GetRuntimeProperty(trainerField.Name) null trainer.GetType().GetRuntimeField(trainerField.Name) null
Will add the tests.

Interesting. If you could add some unit tests I can pull the branch locally later and see if I can figure out what's up with reflection :)

This is great @AnoojNair . Before looking at your PR that's what I was going to suggest, use the Options. That is what contains all the hyperparameters. This is looking awesome!

Interesting. If you could add some unit tests I can pull the branch locally later and see if I can figure out what's up with reflection :)

Thanks , I have pushed the changes

@AnoojNair I gave it a good 30 min to find another simple solution with reflection but I think you're totally right that using that library is easier. The change looks good to me :)


Move flatdata TestPlanBinder into flatdata test module

What type of PR is this?

What does this PR do / why is it needed ?

Which issue(s) this PR fixes:

Fixes #
Other notes for reviewers:
Does this PR introduce a user-facing change?

/easycla


YETUS-685. add junit xml as a reporting format

This is a very simple implementation that likely requires more work.  But it does work for at least Circle CI and Gitlab to some degree.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/1/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
1411
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ master Compile Tests _

0
mvndep
12
Maven dependency ordering for branch

_ Patch Compile Tests _

0
mvndep
4
Maven dependency ordering for patch

+1
shellcheck
0
There were no new shellcheck issues.

+1
shelldocs
0
There were no new shelldocs issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
yamllint
2
There were no new yamllint issues.

_ Other Tests _

+1
asflicense
15
The patch does not generate ASF License warnings.

1467

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/yetus/pull/48

Optional Tests
dupname asflicense yamllint shellcheck shelldocs

uname
Linux f85f8a126103 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
precommit/src/main/shell/personality/yetus.sh

git revision
master / 0255243

Max. process+thread count
50 (vs. ulimit of 2000)

modules
C: . precommit U: .

Console output
https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/1/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.6.0 yamllint=1.12.1

Powered by
Apache Yetus 0.11.0-SNAPSHOT http://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/2/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
1401
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ master Compile Tests _

0
mvndep
12
Maven dependency ordering for branch

_ Patch Compile Tests _

0
mvndep
4
Maven dependency ordering for patch

+1
shellcheck
1
There were no new shellcheck issues.

+1
shelldocs
0
There were no new shelldocs issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
yamllint
0
There were no new yamllint issues.

_ Other Tests _

+1
asflicense
16
The patch does not generate ASF License warnings.

1458

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/yetus/pull/48

Optional Tests
dupname asflicense yamllint shellcheck shelldocs

uname
Linux 5f4e945df985 4.4.0-137-generic #163-Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
precommit/src/main/shell/personality/yetus.sh

git revision
master / 0255243

Max. process+thread count
51 (vs. ulimit of 2000)

modules
C: . precommit U: .

Console output
https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/2/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.6.0 yamllint=1.12.1

Powered by
Apache Yetus 0.11.0-SNAPSHOT http://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/3/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
83
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ master Compile Tests _

0
mvndep
11
Maven dependency ordering for branch

_ Patch Compile Tests _

0
mvndep
4
Maven dependency ordering for patch

+1
shellcheck
0
There were no new shellcheck issues.

+1
shelldocs
0
There were no new shelldocs issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
yamllint
2
There were no new yamllint issues.

_ Other Tests _

+1
asflicense
14
The patch does not generate ASF License warnings.

136

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/yetus/pull/48

Optional Tests
dupname asflicense yamllint shellcheck shelldocs

uname
Linux 1cdf6b833ac3 4.4.0-137-generic #163-Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
precommit/src/main/shell/personality/yetus.sh

git revision
master / 0255243

Max. process+thread count
51 (vs. ulimit of 2000)

modules
C: . precommit U: .

Console output
https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/3/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.6.0 yamllint=1.12.1

Powered by
Apache Yetus 0.11.0-SNAPSHOT http://yetus.apache.org

This message was automatically generated.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/4/console in case of problems.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
192
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ master Compile Tests _

0
mvndep
15
Maven dependency ordering for branch

_ Patch Compile Tests _

0
mvndep
16
Maven dependency ordering for patch

-1
shellcheck
7
The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1
shelldocs
2
There were no new shelldocs issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
yamllint
0
There were no new yamllint issues.

_ Other Tests _

0
asflicense
35
ASF License check generated no output?

319

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/yetus/pull/48

Optional Tests
dupname asflicense yamllint shellcheck shelldocs

uname
Linux 4b4b264d5ccb 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
precommit/src/main/shell/personality/yetus.sh

git revision
master / 0255243

shellcheck
https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/4/artifact/out/diff-patch-shellcheck.txt

Max. process+thread count
47 (vs. ulimit of 2000)

modules
C: . precommit U: .

Console output
https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/4/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.6.0 yamllint=1.12.1

Powered by
Apache Yetus 0.11.0-SNAPSHOT http://yetus.apache.org

This message was automatically generated.

At first I was confused, then I got that this the report of all the yetus tests in the junit result format.
It feels weird for this to be in the junit plugin for some reason? I think because it shouldn't need someone to be relying on any junit testing of their actual source, right?
Also this addition makes it clearer to me that we shouldn't be conflating sources of changes to test with reporting mechanisms (not sure why the html report didn't).
Anywho. That's all stuff not really critical for this first pass.
Maybe too early to include docs? Should atleast make clearer in the cli help that if their project generates its own junit output this isn't going to aggregate it.
+1

It feels weird for this to be in the junit plugin for some reason? I think because it shouldn't need someone to be relying on any junit testing of their actual source, right?

Correct. It was just more of "well, it's junit related so put in the junit.sh file so it is easy to find, I guess?"  We should probably prioritize splitting test-patch.d up. Making robots.d separate has been very nice. haha.

too early

Yeah.  This patch works on Circle CI and Gitlab CI but I cannot get Jenkins to take in the report. So I'm still trying to get that part working.  I guess we could commit as is and then I could open up another to get Jenkins working with it, clean it up, etc.   Thoughts?

... and of course, I just had Jenkins work in my test bed.  Let me clean up this patch and get it committed.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/5/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
124
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

_ master Compile Tests _

0
mvndep
11
Maven dependency ordering for branch

_ Patch Compile Tests _

0
mvndep
4
Maven dependency ordering for patch

+1
shellcheck
0
There were no new shellcheck issues.

+1
shelldocs
0
There were no new shelldocs issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
yamllint
1
There were no new yamllint issues.

_ Other Tests _

+1
asflicense
20
The patch does not generate ASF License warnings.

189

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/yetus/pull/48

Optional Tests
dupname asflicense yamllint shellcheck shelldocs

uname
Linux e74797c417af 4.4.0-137-generic #163-Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
precommit/src/main/shell/personality/yetus.sh

git revision
master / 0255243

Max. process+thread count
50 (vs. ulimit of 2000)

modules
C: . precommit U: .

Console output
https://builds.apache.org/job/yetus-github-multibranch/job/PR-48/5/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.6.0 yamllint=1.12.1

Powered by
Apache Yetus 0.11.0-SNAPSHOT http://yetus.apache.org

This message was automatically generated.

Jenkins test results
WOOT!

Thanks for the review!


Hide longhorn in the legacy apps interface

In 2.6.3, we have longhorn as an app that can be fresh installed in the old legacy app section. It is the only available app.
We need to hide it starting in 2.6.4 in the old legacy apps UI.
It will still allow “upgrades” to the existing deployed version, which are edits to the version that you are currently running. But we will hide it for fresh installs.
SURE-3812

cc @khushboo-rancher @kaxing

@innobead @khushboo-rancher @kaxing Is there metadata on the chart that we can use to know that we can hide it? Or are you asking us to hard-code hiding longhorn as a chart that can not be installed in the legacy app? It would be preferable to have metadata on the chart if possible so we don't have to special-case this.

If the Rancher max version is set to v2.6.3 on the legacy longhorn app, no UI changes would be needed.

@aiyengar2 See below - could we not do as Catherine suggests and fix this by annotating the chart for Longhorn?


Hotspot Area is much larger on mobile than on desktop views

In my mobile phone the hotspot areas are much larger due the "hfov" value change.
Is there any chance to set a different "hfov" value on mobile devices or controlled by an media query?
Thanks

Hot spot size is completely independent of hfov; it is only dependent on screen size. Since the hot spot appearance is defined using CSS, you can change the size by overriding the .pnlm-hotspot class.

Thanks for your answer. But the size seems to depend on the hfov value. If i set the value to 60 everything is working fine. But there seems to be a difference between desktop and mobile. So i decided to change the value due to window width:
if ($(window).width() <= 620) {
        var hfov = 55;
    } else {
        var hfov = 100;
    }

and it is working fine.

There's a difference between desktop and mobile due to differing screen sizes and pixel densities, but hot spot size is still not dependent on hfov. Regardless, it doesn't matter if you were able to get it working to your liking.


Fix incorrect import statement

This isn't Javascript :P
The example would have given a syntax error for improper ordering.

Nice catch, thanks!


[requires.io] dependency update on master branch

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

[Current coverage][cc-pull] is 97.24%

Merging [#42][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master        #42   diff @@
==========================================
  Files            13         13
  Lines           796        796
  Methods           0          0
  Messages          0          0
  Branches         42         42
==========================================
  Hits            774        774
  Misses           17         17
  Partials          5          5

[][cc-pull]

Powered by Codecov. Last updated by e053eeb
[cc-base-branch]: https://codecov.io/gh/fusionapp/fusion-index/branch/master?src=pr
[cc-pull]: https://codecov.io/gh/fusionapp/fusion-index/pull/42?src=pr

Reviewed 1 of 1 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


make fails: unable to find a working luabind (uses system's lua instead of mason's lua)

Current master at 7b4f29b57:
git clone git@github.com:Project-OSRM/node-osrm.git
cd node-osrm
make

fails with:
-- Found Lua51: /usr/lib/x86_64-linux-gnu/liblua5.2.so;/usr/lib/x86_64-linux-gnu/libm.so
-- Looking for LuaJIT 5.1
-- Could NOT find LUAJIT (missing:  LUAJIT_LIBRARIES)
-- Performing Test LUABIND51_WORKS
-- Performing Test LUABIND51_WORKS - Failed
CMake Error at cmake/check_luabind.cmake:38 (message):
  Luabind does not work with Lua 5.1 at
  /usr/lib/x86_64-linux-gnu/liblua5.1.so, no working Luabind found
Call Stack (most recent call first):
  CMakeLists.txt:284 (include)

That is, it does not pick up the lua / luabind we're downloading from mason.
@MoKob just provided me with his OS X output:
-- Found Luabind: /Users/mokob/test/node-osrm/mason_packages/.link/lib/libluabind.a
-- Found Luabind: /Users/mokob/test/node-osrm/mason_packages/.link/lib/libluabind.a
-- Found Lua52: /Users/mokob/test/node-osrm/mason_packages/.link/lib/liblua.a
-- Performing Test LUABIND_WORKS
-- Performing Test LUABIND_WORKS - Success
-- Luabind/Lua5.2 combination working with /Users/mokob/test/node-osrm/mason_packages/.link/lib/liblua.a

which looks fine.
@springmeyer can you look into this?

If I am understanding right the problem is that you have duplicate libraries on your system and the system one is being found instead of the mason one. I presume this can be avoided (for your system) in at least two ways:

Uninstalling the system lib
Passing more flags to osrm-backend's cmake options to try to get cmake and the compiler to use the local libraries. Perhaps https://github.com/Project-OSRM/node-osrm/issues/172?

You could also try debugging if/why https://github.com/Project-OSRM/node-osrm/blob/master/bootstrap.sh#L173-L175 are not working, which should be ensuring that mason libs are used first. What may be happening is that the linux linker still prefers shared libraries over static. We prevent this on OS by using -Wl,-search_paths_first. Maybe linux has some equivalent?

Here's what I got so far:

in bootstrap.sh node-osrm install Lua 53
osrm-backend's buildsystem only supports Luabind with Lua52 or Lua51 and tries to find Lua52

The fact that it works on some platforms seems to be that Lua53 is erroneously detected as Lua52.
I think the way forward here is to always install Luabind+Lua52 from mason or to completely re-write the Luabind+Lua detection part of osrm-backend's buildsystem.
By the way @TheMarex is the Lua version we're shipping with node-osrm considered part of the API as in: user profiles may break when we ship Lua53 vs Lua52.

Going to close and hold on this, since extra work on lua is likely not worth it given upcoming work on nodejs alternative.

Reopening after discussion with @kkaefer and @danpat today.
We have to support Lua for the time being anyway.
And we're thinking of properly mason-izing osrm-backend.

Luabind is gone now. Closing this as stale.


Use Yaml anchors instead of docker compose extends

This is because newer docker compose (at least v2.24.6) enforces this restriction: https://github.com/compose-spec/compose-spec/blob/master/05-services.md#restrictions and throws this error:
> docker compose up
service "worker" can't be used with `extends` as it declare `depends_on`

> docker compose version
Docker Compose version v2.24.6-desktop.1

This has been checked on older docker compose by @nlisgo @will-byrne so I'll merge it


Support multiple LionWeb versions

The goal is to support, with the same codebase, all the LionWeb versions, provided they are not mixed together.
Many APIs now get an optional parameter indicating the LionWeb version to be used. If no value is provided the current one is used.
Not also that all "meta" nodes (Concept, Enumeration, Feature, etc.) needs to know to which LionWeb version they refer to.
Probably more checks should be put in place to identify cases in which multiple versions are mixed.
Regarding serialization tests, in all the cases in which we had files, we kept them untouched, so we check the serialization works for v2023.1. At some point we may duplicate some of those tests to check they still work with v2024.1 (with the appropriate, minimal, adaptations).

After experimenting with using generics in #170 I think that the resulting code is cumbersome to write and to use, so I would prefer going for this PR, where versions compatibility is checked at runtime and not a compile time. @enikao @dslmeinte what do you think?

Sounds like a good decision. If, later on, we do find a way to achieve version-safety through generics (or a similar strategy) it should be doable to retrofit that onto these changes.


Provider dispose managed by Flutter scope

On the Flutter side of our app we basically have global providers and what are effectively Flutter scoped providers (i.e. support the current dialog/view). The end of the "scope" is a user finalizing action such as closing a dialog or navigating to another view. A time-based solution is not reliable since we don't know when the user will "get a coffee".
One problem task flow for us is a prompted multi-card dialog that supports a "go back" feature. Prior provider states are needed when going back. We currently manage these provider lifetimes using keepAlive (we're migrating to 2.0-dev), storing the keepAliveLinks in a scope-aware data structure,  and close() the links on the user finalizing action.
For us, a Flutter "scoped" autoDispose would handle the provider lifetime management that we currently need to code. Yes, there would need to be another form/mode of ProviderScope to be added to the Flutter tree that manages these provider lifetimes. The providers that want to be so managed would need to indicate this. Possibly something like Provider.scopedDispose() instead of the 3 lines of keepAlive code we currently add.
This request is inspired by the lively discussion in #1329 which has many references to Flutter-based user actions and screens.

Hello!
Could you show some code? It's unclear to me what you're expecting and what you're currently doing (I have no idea what keepAlive has to do with this)

We use keepAlive to maintain StateNotifierProviders for previous "cards" that are no longer displayed (i.e. unmounted) that the user can "go back" to. Our cards collect input/choices from users and progress to other cards/decks. The current card display and "back" history is maintained by a top-level "board".
Each card's state is created with something like
final createDeckStateProvider = StateNotifierProvider.autoDispose((ref) {
  final notifier = CreateDeckNotifier();
  final commonBoardNotifier = ref.read(commonBoardProvider.notifier);
  final keepAliveLink = ref.keepAlive();
  commonBoardNotifier.addKeepAliveLink(keepAliveLink);
  return notifier;
});

The common board notifier has a method to collect all keepAliveLinks in use
  /// Riverpod keep alive links are collected here and all closed when this board is disposed.
  /// Future for Riverpod assert "Providers are not allowed to modify other providers during their initialization."
  void addKeepAliveLink(KeepAliveLink keepAliveLink) =>
      Future(() => state = state.copyWith(keepAliveLinks: state.keepAliveLinks.prependElement(keepAliveLink)));

The common board is a provider created with an onDispose to call all of the collected link close() functions
final commonBoardProvider = StateNotifierProvider.autoDispose((ref) {
  final notifier = CommonBoardNotifier();
  ref.onDispose(() {
    _logger.info("Common board disposing ${notifier.currentState.keepAliveLinks.length()} links");
    notifier.currentState.keepAliveLinks.forEach((a) => a.close());
  });
  return notifier;
});

commonBoardNotifier.addKeepAliveLink(keepAliveLink);

This line is anti-pattern. Neither should the KeepAlive link leave the provider it belongs to nor is it allowed to modify other providers during the initialization of a provider.
You shouldn't do such a thing.
And what is it that this issue is requesting?

And what is it that this issue is requesting?

...definitive provider lifetime management. We want providers to live throughout the lifetime of a given display and not beyond - i.e. "scoped". Time-based solutions are not deterministic. Several of the comments in #1329 show concern with the provider behavior combined with users opening/closing/transitioning screens. We've had to watch out on some of our asynchronous processing that display a busy screen. During a few frames of a transition display Riverpod will dispose of our providers. Also the above mentioned previous cards (i.e. valid for "go back") are held in an unmounted state.
At the "top" of each of our displays we have a ProviderScope that overrides a few display specific providers. For us, this is the beginning of a display "scope". All of our U/I state providers are created "under" this scope. When the display is completed this "scope" is disposed. Yes watch mostly handles this but we have encountered edge cases.
Thanks for the feedback about the above "anti-pattern". How about if we reverse the "event flow" and have the top-level board provide an event such as a future that is completed when closed. Something like
  final keepAliveLink = ref.keepAlive();
  ref.listen(commonBoardClosingNotifier, (_, __) => keepAliveLink.close());

Hey - that gets it down to 2 lines. Yes, it would be better if we didn't need to manage provider lifetime.

...definitive provider lifetime management.

But what would that look like exactly?
 I'd like to see some concrete examples about what you're like. Otherwise I'm not sure how to resolve this issue.

We need two additional concepts: a mechanism to define the managed lifetime scope and an opt-in for the providers to use the scoped lifetime.
Establishing a scope could be an option on ProviderScope such as isScoped: true. We generally have one at the top of each of our widget trees that injects additional context with provider overrides.
Widget build(BuildContext context, WidgetRef ref) {
  // Currently this is the provider that manages lifetime with its onDispose
  final commonBoardState = ref.watch(commonBoardProvider);
  return ProviderScope(
    overrides: [profileProvider.overrideWithValue(profile)],
    isScoped: true, // <-- proposed top of the flutter scoped managed lifetime for providers that opt-in
    child: CommonBoard(context, ref, commonBoardState),
  );
}

Provider opt-in to managed lifetime would be somewhere in the provider declaration. It could be Provider.scopedDispose, a parameter to .autoDispose, an additional method on ref such as ref.scopedDispose(), a parameter to an existing method such as ref.keepAlive(isScoped: true), or even a method on the keepAliveLink such as keepAliveLink.closeOnScopeDispose().
final createDeckStateProvider = StateNotifierProvider.autoDispose((ref) {
  final keepAliveLink = ref.keepAlive();
  keepAliveLink.closeOnScopeDispose();  // <-- opt-in this provider's lifetime to that of the "scope"
  return CreateDeckNotifier();
});

If the above scoped provider is not used in a context that has a "scope" defined it will fall back to standard .autoDispose behavior.
Generally we like the way .autoDispose providers work - i.e. disposed when no longer "in use". We would prefer that any other lifetime behavior be "opt-in". In comment https://github.com/rrousselGit/river_pod/issues/1329#issuecomment-1086834827 you are proposing cacheTime default of a few minutes <-- please don't. This would have hidden our card lifetime issue from us in early development (i.e. "go back" failed - oh, they're unmounted and therefore disposed).
For me, a "time-based" solution is an anti-pattern. Caching data is a valid time-based use case but it should be opt-in and applied as an optimization.

What you're describing is already available.
You can scope providers (although it's not recommended)
final a = Provider(...);

...

ProviderScope(
  overrides: [a],
)

This will create a new a instance for this tree and when the scope is removed, a will be disposed.

We already use ProviderScope(overrides: ...) to handle static scoped providers. We need to manage the lifetime of dynamically added state notifier family providers as the user progresses forward and backward through our cards. Each card is (mostly) independent of other cards so no big master state is feasible.

What's preventing you from using overrides: [family(123)]?

At the time we create the ProviderScope we don't know the providers that will be needed.

I'm sure you should be able to figure out the list
Scoping all providers is not reasonable.

We agree that "Scoping all providers is not reasonable." and didn't ask for that.
We have a workable solution using keepAlive with lifetime managed by listening to a named provider.


Add relative flag support

Added relative flag support --relative to support relative paths instead of absolute ones.
The default value is false, but in my opinion, it should be true since I don't want to see absolute path (ex: /home/github/actions/...) in my Github Actions logs

@renatoabreu11 sorry for bothering you, can you take a look at this? There are many PRs open

@renatoabreu11 sorry for bothering you, can you take a look at this? There are many PRs open

Hey @DVDAndroid. No problem at all, I will take a look!
Sorry to take so long, I didn't receive a notification

Will the default value of relative change? I think people don't want to see internal Github Actions path (ex: /home/github/actions) in logs

Will the default value of relative change? I think people don't want to see internal Github Actions path (ex: /home/github/actions) in logs

Yes, I agree with you. I will make the change as well 👍


[dv,cip] Guarantee ordering of sampled A and D transactions

When TileLink transactions are observed by tl_monitor.sv, it writes
items to "A" and "D" ports, depending on what channel observed them.
These writes race against each other, so there's no order guaranteed
between an A and D transaction sampled on the same clock edge.
These ports are connected to fifos in cip_base_scoreboard.sv. Before
this commit, the scoreboard used two tasks (process_tl_a_chan_fifo and
process_tl_d_chan_fifo) to sample from the two fifos. Once an item was
found on either fifo, the corresponding task called process_tl_access,
which itself is a task implemented in the subclass.
The problem is that the subclass implementation couldn't guarantee the
ordering that it would see if there was an A and D transaction on the
same cycle.
But why does this matter? Suppose that my block has a register, FOO,
whose value can be written by hardware but in a way that we can
predict. Then I need to somehow store an expected value when I see the
A channel transaction for a read of FOO, then check it matches the
transaction data for the following D response. The obvious way to do
this is to mirror the expected value in the RAL with a call to
uvm_reg::predict() when I handle the A channel transaction, and this
is what code like keymgr_scoreboard::process_tl_access does.
What happens if I see two back-to-back reads of FOO, where it changes
value between the two? That is, what if the following transactions
happen? (the (1) and (2) are indices to match up the A-side request
with the D-side response)
    Cycle | A channel   | D channel
   ---------------------------------
    0     | Get FOO (1) |
    1     | Get FOO (2) | FOO rdata (1)
    2     |             | FOO rdata (2)

Before this patch, there were two possible orderings for the resulting
calls to process_tl_access(). We'd either see
A (1); D(1); A(2); D(2)

or we'd see
A (1); A(2); D(1); D(2)

If the expected value of FOO changes between the two transactions, the
second ordering (AADD) is a disaster if we're trying to use the RAL to
mirror things: we'll end up checking the D(1) rdata against the A(2)
expected value.
This patch guarantees that, in the (common) case where the device
always responds on the next cycle, we always see the nice "ADAD"
order. To do this, we make sure to handle D before A, meaning that on
the "middle cycle" above, we see D(1) then A(2).
This isn't a completely general solution. For example, if the device
might take multiple cycles to respond, we might get something like this:
    Cycle | A channel   | D channel
   ---------------------------------
    0     | Get FOO (1) |
    1     | Get FOO (2) |
    2     |             | FOO rdata (1)
    3     |             | FOO rdata (2)

and no amount of cleverness can guarantee the "ADAD" ordering. In that
case, the device's scoreboard is going to need to be cleverer.
Similarly, if the device can respond on the same cycle, we might get
something like this:
    Cycle | A channel   | D channel
   ---------------------------------
    0     | Get FOO (1) | FOO rdata (1)

in which case we'll actually have a "DA" ordering, which is a bit
confusing! A future version of this code could be cleverer to avoid
this problem (by counting transactions to realise that the two items
were supposed to match). But that's harder and we don't have any
devices in OpenTitan that respond in zero time at the moment. The
behaviour with this patch is one of two behaviours that the previous
code might have had, so it's no worse at least.

The D() packets already contains the corresponding A() channel information, which is what should be used by the scoreboard to develop the prediction logic, with 'completed transaction' packets.
See:
https://github.com/lowRISC/opentitan/blob/e1d02b58bcbb8bf3d0c4f70ba62e4d03d760d309/hw/dv/sv/tl_agent/tl_monitor.sv#L145

I feel we need to let scb know the transaction occurs ASAP.
As I know, our design latches the value when a channel handshaking is done for read. then compares the read value when d channel is completed. There is a gap. So sometimes, when I need cycle accurate check, I have to store the predicted value when a channel is done (same cycle as design latches the value) and compare it when d channel is done.
For write, design also stores the write value or trigger some logic when a_channel is completed.
In the IP level, if the block contains CSRs and mem, then it can support 2 outstanding transactions, one is CSR, one is mem access.
In the case below, 2 items are accepted by the design, but driver sets d_ready low for a long while. With this PR, we want to wait for CSR (A) and CSR (D) to complete, before let scb know mem(A) is done. It may be too late as design has taken the mem write value and start to process something.
 Cycle | A channel    | D channel
   ---------------------------------
    0    | write (csr) |
    1    | write(mem)  |
    driver  set d_ready low for a while, DUT can't accept new items
    n+1  |             | write done (csr)
    n+2  |             | write done (mem)

this is too late to know mem(A) is done

CSR (A) ->  N cycle   -> CSR (D) -> mem(A) -> mem(D)

prefer to see the transaction in scb like this, as it's closer to how design processes it

CSR (A) ->  mem(A) -> N cycle -> CSR (D) -> mem(D)

WDYT? @rswarbrick

Hi both.
@sriyerg: I don't think your answer is really addressing what this PR is about. The problem isn't that the D channel handling doesn't understand what the A channel transaction was doing. The problem is that it might need to know something about the state of the block when the A channel transaction came in.
@weicaiyang: I'm not completely sure I've understood your message, but in the example you've put forward, I think the scoreboard would see things in the order you want (with or without this patch!). The only time that this patch should have any effect is when an A and D transaction come in on the same cycle. With the code in master, the ordering of events at the scoreboard depends on the simulator's scheduling algorithm. With this patch, it will always be D then A.

@sriyerg: Actually, reading the tl_monitor code a bit more carefully, what happens if there are two back-to-back reads at a the same address, where the D response is delayed for a few cycles? If I understand the code correctly, we'll generate a spurious error from line 95 (DV_CHECK_EQ_FATAL(pending_a_req.exists(cloned_req.a_source), 0)). @weicaiyang: Does that sound right to you?

@sriyerg: Actually, reading the tl_monitor code a bit more carefully, what happens if there are two back-to-back reads at a the same address, where the D response is delayed for a few cycles? If I understand the code correctly, we'll generate a spurious error from line 95 (DV_CHECK_EQ_FATAL(pending_a_req.exists(cloned_req.a_source), 0)). @weicaiyang: Does that sound right to you?

By design, a back-to-back request to the same address with the same a_source (i.e. the same host) cannot occur (@weicaiyang, @eunchan). The TL agent will will always randomize a_source such that it does not match a pending request that has not yet completed (i.e. mimicking multiple hosts accessing the same device). See here:
https://github.com/lowRISC/opentitan/blob/7252f1753991938e0109767b3d8c029c442681e3/hw/dv/sv/tl_agent/seq_lib/tl_host_base_seq.sv#L12

@sriyerg: Actually, reading the tl_monitor code a bit more carefully, what happens if there are two back-to-back reads at a the same address, where the D response is delayed for a few cycles? If I understand the code correctly, we'll generate a spurious error from line 95 (DV_CHECK_EQ_FATAL(pending_a_req.exists(cloned_req.a_source), 0)). @weicaiyang: Does that sound right to you?

By design, a back-to-back request to the same address with the same a_source (i.e. the same host) cannot occur (@weicaiyang, @eunchan). The TL agent will will always randomize a_source such that it does not match a pending request that has not yet completed (i.e. mimicking multiple hosts accessing the same device). See here:
https://github.com/lowRISC/opentitan/blob/7252f1753991938e0109767b3d8c029c442681e3/hw/dv/sv/tl_agent/seq_lib/tl_host_base_seq.sv#L12

Agree with Sri, that check looks right to me. And seems like it isn't related to the change in this PR.

Hi both.
@sriyerg: I don't think your answer is really addressing what this PR is about. The problem isn't that the D channel handling doesn't understand what the A channel transaction was doing. The problem is that it might need to know something about the state of the block when the A channel transaction came in.
@weicaiyang: I'm not completely sure I've understood your message, but in the example you've put forward, I think the scoreboard would see things in the order you want (with or without this patch!). The only time that this patch should have any effect is when an A and D transaction come in on the same cycle. With the code in master, the ordering of events at the scoreboard depends on the simulator's scheduling algorithm. With this patch, it will always be D then A.

Right - the TL monitor already internally matches the D channel response with the corresponding A channel request that must have occurred in the past. We surely don't want to be seeing a random response occurring on D channel with the corresponding req on A channel missing! As a bonus, the D channel packet the monitor writes tacks on the A channel information after the matching is done so that the external scoreboards have the full picture and dont have to worry about matching responses with requests (as you do in this PR).
If you are developing a cycle accurate model (which is almost always a bad idea!) of the design, then you my need to predict the reads / writes on the A channel packet to align it perfectly with the design. There may also be cases where you may need to know the state of the block when the A channel req came in (as you said so), which you would maintain in your scoreboard. Eventually when the D channel resp arrives, you ought to be using the source ID to match it instead (i.e. rely on TLUL spec).

Ok, looks like this won't fly. I'll add something careful to the IP-level scoreboards I'm writing and let's hope we don't trigger the race condition for anyone else. If we do, maybe someone will rediscover this solution.


Home page issue in HUGO V.0.58.1

Thanks for a awesome template..
Home page rendering into post folder... So am using a downgraded version of Hugo V.0.57
Hugo support suggested that we need to use .Site.RegularPages variable to overcome the same..
Can author support in fixing the same??

I have the same issue.

The author of this theme has been inactive on Github for around two years. You should probably not expect any changes.

Can someone help us fixing the issue by creating a fork off of this project??

I have been using this theme for my site and I encountered a similar problem. I have tried to fix this here: https://github.com/eueung/hugo-casper-two/pull/33/commits/3805e9ef2d509d610d0153bccebdfa2d025aa25b
It was my bad that I tried to fix issue 25 in master branch, but since it has not been accepted yet, and most likely will not be, you can find changes from issue 25 too.
Look for the branch issue_31 where I have addressed the problem for you guys. Let me know if there was anything I missed out.

I've only just got back to Hugo and found this issue. @ansin218 I've applied your fix, but noticed it then breaks the tag pages. They will all list all pages rather than just the pages containing the requested tag

@cuotos I cannot quite comprehend your problem. Could you please elucidate?
Also, I am no Hugo expert but I will try my best to help you out!

If you have tags on your posts then go to "site/tags/[tagname]" then all posts are displayed, not just the ones containing that tag.
I've actually moved to using a different theme now, but its where your using .Sites.RegularPages, this will always list all pages, even on a list page that is designed to only show a subset, like the tags example above.

Thanks for the commit @ansin218! I had the same issue as @cuotos.
Did my own dirty fix here (https://github.com/y26805/hugo-casper-two/commit/8cd7185fe731aea79590d8d699aa8ba4789066d4)
by separating post-list-home from post-list.
to use this fix, one would have to add a param to config file
 mainSections = ["post"]

as creating a mainSection is recommended by Hugo

Author not active.
Security concern.. Better not to use the theme


For merging #71

Hey @youngchen7
I took the liberty to move your work into this PR because I wanted to merge it ASAP and I didn't want to bother you asking for a particular commit message.
Anyway, authorship and code got preserved 100%.
Thank you again for your contribution!

I'm going to release the new version on NPM in a couple hours 🚀

Also @all-contributors be a sport and add @youngchen7  for his code contributions!


What is the meaning of 'non-conventional usage' of backbone at Table 7 in the Paper?

Thank you for your great job of this repo and paper!
I notice that the result of ResNet-50 with non-conventional usage has the best performance. I want to know how to implement this ' non-conventional usage'.
Does it mean 'discarding the down-sampling operation between stage3 and stage4' in section 3.1 of the paper?
Thanks a lots.

Thanks for the interest in our paper.
For your question, it means 'discarding the down-sampling operation between stage3 and stage4' in section 3.1 of the paper.
So, you are right :)

Thank you for your response !
So, 'discarding the down-sampling operation between stage3 and stage4' is changing the last stride of Resnet layer4 from 2 into 1 ? That is,  last stride = 1 ?
These days I reimplement your great work with pytorch. When evaluating in CUB-200-2011, I just get 62% Recall@1. I believe I miss some important details.
So, some questions raising:

Batch sample: shuffer all samples and get 128 samples in a batch? or use P-K sampling format(P-classes, K samples per class)
I find that without L2 norm and FC after GD( like another issue said) could get higher performance(can't still reach your proposed results in CUB-200). Do you know the reasons about this?
Could you share some training tricks?
Looking forward to your guidance.
Thank you so much!


value "61440" greater than max "1"

Describe the bug
I get comments in the log that the values don't match the specified parameters. The adapter is not connected to the device.
To Reproduce
Expected behavior
correctly loading parameters from the smartset.
Screenshots & Logfiles

Versions:

Adapter version: 1.0.0
JS-Controller version: 3.3.18
Node version:  v12.22.6
Operating system: raspberry os (debian)

duplicate #65


chore(master): release 3.9.2

:robot: I have created a release beep boop
3.9.2 (2024-08-16)
Bug Fixes

float: fix floating parse (b079314)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v3.9.2
:sunflower:


[FR, maybe Bug] Can we collapse filters?

I have lots of fields in my daily notes:

I would like to be able to open and collapse the filters so I can see content.  Thank you.

Hi, this is available in 0.4.21

Thank you so much! It makes it so much more useful.


Cleanup unchecked cast

Only one unchecked cast is fixed.
The rest are all casting from IField to ListField.
for ListField , the generic type T cannot be checked at runtime. (generic type information will be erased at runtime).

Nothing done in this PR.  Will deny it.