Add a way to record video

Use case
Flutter has no way to record video of the Flutter App.
Using repaintBoundary
This method has 2 major drawbacks:

It draws blank white boxes on PlatformViews and WebViews
Bitmaps need to be sent back to the Native platform for encoding into mp4. (Using OpenGL)

Using platform channel
Flutter exposes the getBitmap API but this has 2 major drawbacks

It must run on UIThread so the FlutterApp is blocked, so the video is recording a blocked UI
This method is very slow. Sometimes up to 100 ms depending on the screen content.

Recording the entire screen?
Using MediaRecorder that's possible but we want to:

Record the app only, not the entire screen
Recording the entire screen requires special permission from user

Drawing a canvas from FlutterView?
This draws black screen because FlutterView is a SurfaceView and bitmap cannot be obtained as it was drawn on the different thread.
Use PixelCopy?

This API is only availabe on >= API 24

And this feature has been requested several times https://github.com/flutter/flutter/issues/34632 #34226
Proposal
Expose an API to record Bitmaps continuously in the background not on the Main UI thread . (Or a video recording API but that's too much to ask)

Keywords: getBitmap, screenshot, bitmap, uithread, background, record, recording, screen shot, main thread, flutterview, surfaceview, video, mp4, mediarecorder, opengl, mediamuxer, mediaencoder

@matthew-carroll @mattcarroll @chinmaygarde @xster

As stated, this feature request is likely to be very difficult. However even scoping it down, it's not likely to be something that we'll work on soon, so I'm marking it P6.

Possibly related:

https://github.com/flutter/flutter/issues/129098

Disclaimer: I am working on it


grid creation fails

This Issue is about (✏ delete as applicable)

A bug in the API:

Phaser version(s): 2.7.10
Live example: https://codepen.io/anon/pen/MmdPOe?editors=0010
What should happen: grid should be created
What happens instead:

var grid = this.game.create.grid('grid', this.game.width, this.game.height, 32, 32, 'white');
this.add.sprite(0, 0, grid);

Results in:
Phaser.Cache.addImage: Image "grid" hasn't been retrieved yet
Phaser.Frame: Frame "undefined" has a width or height of zero

This seems to work sometimes though. In my own code in Firefox it works without console open, whereas in Chromium it works only with console open. May be a timing-related issue.

This is another consequence of #136. Guess we need to add a callback here as well.

Also in Phaser.Create#texture.


Home view: don't consider "securing" vaults in the total balance

If the rationale is that we count in the total what we consider "vaults", we only consider a new deposit a vault if we had all the revocation signatures for it.

IMHO we should ditch the total balance altogether, and just have the secured and delegated balances

(From a discussion with @JSwambo)
Having the following balances:

total in custody for EVERYTHING (including only the non-secured deposits),
When funds are pending to be secured, you see them appear as "+ x BTC, 1 vault(s)"
Secured,
When funds are pending to be delegated, you see them as "+ y BTC, 1 vault(s)" and this amount is removed from Secured
Delegated

Regarding the UI:

I'm imagining "total in custody" on the top,
Then 3 boxes for Deposited, Secured, Delegated (all same style) but stacked vertically. Then it may be clear how funds progress from one category to the next

If we go this way, I think we should remove this box, as it would be useless:

What do you think?

If we go this way, I think we should remove this box, as it would be useless:

yeah, or rather make the box match the others.
From the user perspective, funds would be "in custody" from the moment they are deposited, until the moment a spend (or emergency) is confirmed. Also from user perspective, the funds in custody can be "Deposited", "Secured", "Delegated".
It'd be nice to have buttons that make sense for the transitions, e.g. For Secured -> Delegated a "Delegate" button is sensible. However, right now from deposited -> secured the button says "create vault", which isn't clear. So either change it to "Secure Deposit" (with secure being a verb... could be ambiguous), or change the "Secured" naming to "Vault" and keep "create vault".
There should ofc be consistency tho

deposited / acknowledged / active is what we previously had. Cross-linking https://github.com/revault/revault-gui/issues/88  which is the only reference i could find to the decision of moving to not mention deposited coins.
IIRC the rationale was:

Use no Bitcoin lingo, come up with a "vault" vocabulary
Define a vault. What is it? We used the definition of "a coin with the revocation txs pre-signed"
Make deposits second-class citizens since they are'nt vaults

Sorry, misclick!

We still account for the 'securing' funds in the total balance.


Apprise notifications

Adds support for notifying of container restarts via Apprise.
Apprise can be configured with a wide range of notification services including: eMail, Slack, MS Teams, Gotify, Pushover, etc. See the full list for more. Multiple services can be configured for notification at the same time.

Hello
Is there a wiki or a tuto to explain how to make it work ?
Apprise is a bit cryptic
Thanks

And no way to change the title ? (I have mutliple instance of autoheal and don't who send what. I could have multiple apprise key)


docs update tofor canvas.stroke(path2D) in drawing_paths.rst

Same docs for drawing paths as discussed

@martinRenou Oops, I probably have a git workflow mistake. I did not expect the PR to have all these different commits. I think I made a mistake pushing to my own master branch first. I I assume you squash those out when it comes time to accept. In the future, I'm guessing I should delete my current fork, and re-fork and do my PRs from a branch.

Hmm, I just noticed the sinusoidal stroke is not being rendered in the read the docs output for drawing paths
Is that a bug in my submission to ipycanvas itself? Or, is it in the the build process not updating to the latest package version? Let me know if there is something I can help fix.

I made a mistake pushing to my own master branch first

Indeed this is the reason you see all these commits. On my end I'm fine squashing.

In the future, I'm guessing I should delete my current fork, and re-fork and do my PRs from a branch.

Probably that should be best.

There is probably an action I should take on the publishing to fix this.


Fix the prerelease command in the docs.

I think changset preleease isn't a valid command ? And it doesn't match the command from the sample either.

I don't understand why the tests are failing, sorry :/

Thank you! This might be a leftover after the previous implementation or something. Don't worry about tests - the failure obviously has nothing to do with this PR, I'll have to investigate later and merge your PR then.


bump minimal python version to 3.10

As required from https://peps.python.org/pep-0604/

Thanks!
Hopefully, we can support Python >= 3.8 in the future. https://github.com/mlcommons/croissant/issues/28 tracks this feature.


it's shaking a bit

when it's going slower it's a bit shaky.
do you notice?

there are many factors can you send me a example?

it's seen in first demo example. it's going slowly, but it's shaking a bit, doesn't run smooth.

On me it's works fine (and i also notice too the minimal screen tearing)
As I have already said there are many factors (your device, your monitor, screen tearing)
I don't can resolve your issue sorry


add fengshunli as reviewers of OpenYurt

GitHub Username
@fengshunli
Organization you are requesting membership in

openyurtio
Sponsors

@rambohe-ch
Requirements

[x] I have joined in the community Dingding and [WeChat]
[x] I often attend Openyurt Community Week
[x] I have reviewed the [community membership docs]
[x] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application
[x] I have checked my affiliation in devstats (if it's not correct, please fix in cncf/gitdm)
[x] I am actively contributing to 1 or more OpenYurt subprojects

List of your contributions

PRs reviewed / authored:

Issues :
https://github.com/openyurtio/openyurt/pulls

Brief Introduction

@fengshunli Thanks your contributions to OpenYurt. agree +1

agree +1

/lgtm


Feature: Multiline editing for Input

Based on PR #51

Multiline Cursor.
Two modes for multiline editing: editing and preview.

Esc: preview -> editing.
Any key: editing -> preview.
Enter: preview -> submit.

Corner case 1: preview mode is used by default when a default value is specified.
Corner case 2: not losing keys while switching from preview to editing.

I tested, and found in view mode, one can still type in.

We need to know the mode of Input in trait PromptInteraction, but it's hard without changing it.

Not hard ;) https://github.com/fadeevab/cliclack/pull/54/commits/b31385dc04380586cf36fc8531b811e04e5ca45e

So clever!
Then the jobs left are:

make placeholder gray
it's more convenient that interactively valuation failure prevents mode switching.

@kingwingfly

There is a bug with cursor rendering:

I found I have a reflex to hit Esc to switch into the View mode (double Esc to cancel completely) and return to editing by typing any key (except Enter which works as expected and submits data in the View mode).

WDYT?

There is a bug with cursor rendering:

fixed at

#58

And make cursor navigation more correct.

I found I have a reflex to hit Esc to switch into the View mode

Yes, many are vim users, and it's sure more ergnomical.

return to editing by typing any key

It's easy.
I'll try making Tab for indent, and ESC to switch mode.

@kingwingfly All right, now we have this single mega PR :)
I found 1 concern: "home" and "end" don't respect multilining.
And also I was thinking the Cursor could have unit-tests, at least for move up and down actions, but I won't insist on them.
Other than that, we are close to the finish.

And also I was thinking the Cursor could have unit-tests, at least for move up and down actions, but I won't insist on them.

Now we store String as Vec<u8>. But for multiline, maybe Vec<Vec<u8>>(Vec<Line>) is more suitable. And easy to navigate and write tests. Maybe there's crate for this.

And also I was thinking the Cursor could have unit-tests, at least for move up and down actions, but I won't insist on them.

Now we store String as Vec<u8>. But for multiline, maybe Vec<Vec<u8>>(Vec<String>) is more suitable. And easy to navigate and write tests. Maybe there's crate for this.
Edit: I found some other prompts needing StringCursor.

Yeap, especially, using the binary search feels like an overkill.

@kingwingfly Let's move on with the current version of the PR? Or, are you trying to refactor it now?

I think current version is okay now.


Clicking on IconButton changes Backdrop color

I have a special design for a dialog which includes the dialog itself and a floating side menu next to it(Not a regular menu that blocks actions until closed). I was able to achieve it using the Backdrop component, but when I use an icon with IconButton wrapper around it, everytime I click the icon, it changes the background color of the backdrop due to the touch ripples(and I want to keep the ripples)

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

When I click the icon notice how the background color changes to darker during the ripple transition.
Expected Behavior 🤔
I expect the background to not change
Steps to Reproduce 🕹
Here is a live example: https://lqnz2.csb.app/
This is the code: https://codesandbox.io/s/festive-http-lqnz2?fontsize=14&hidenavigation=1&theme=dark
Context 🔦
I wasn't able to achieve the floating side menu behaviour using the dialog or modal component so after digging through the docs I found the backdrop component and after playing with it for a while I got what I wanted. That is until I came across this problem...
Maybe I'm not using the component the right way and there is a better way to achieve what I want.
I have a feeling it got something to do with the ripples css. But even after going through the library code I can't figure out why it's happening.
Your Environment 🌎

Tech
Version

Material-UI
v4.7.1

React
16.11.0

Browser
Chrome(79)

TypeScript
3.6.4

Thanks in advance :)

I can't reproduce this. Not sure what I'm doing differently.

I can't reproduce either.

I can't reproduce this. Not sure what I'm doing differently.

I can't reproduce either.

Are you using Windows os? I use Mac and I was able to reproduce it on my team members computers, but when I tested it on one of our windows servers, it didn't reproduce...

@ilantuqqi I was, I’ll try reproduce on a Mac when I can

@oliviertassinari It happens only on macOS 10.13-10.14 from what I tested on chrome 79.
On 10.15 it didn't reproduce. What version are you on?

Thanks for looking, I'm on macOS 10.15.2 :). Ok, no need to spend more resources on this.

@oliviertassinari After some more experiments it turns out it's something with Samsung screens and Mac on chrome🤷♂(When using Safari it doesn't reproduce)


⚠ SkipTheCommericals has degraded performance

In 71357e5, SkipTheCommericals ($STC) experienced degraded performance:

HTTP code: 200
Response time: 2011 ms

Resolved: SkipTheCommericals performance has improved in 77c41a2.


If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

The time take by go test github.com/mewmew/uc/uc/gocc/lexer taking roughly the same amount of time to run when using Go tip and Go 1.4.

What did you see instead?

"go test" took roughly 20 seconds on Go tip and 0.5 seconds on Go 1.4.
Also note that the compile command used between 25% to 60% of the CPU, during the 20 second duration.

Nuke your $GOPATH/pkg cache before both tests.
I suspect in one case you're building dependencies and in the other case you're not.

I tried to remove the $GOPATH/pkg directory but did not make a difference.
  Are there any differences in build actions?

Perhaps we could preserve the old backend for such cases.
(That is, if the input function is too complicated, just fallback to the
old backend.)

I would certainly hope that we can remove the old backend eventually. It
seems like a bad idea to have to maintain two different backends in one
compiler forever.

gri

On Wed, Mar 23, 2016 at 4:02 PM, Minux Ma<EMAIL_ADDRESS>wrote:

The old compiler has a cutoff threshold: when a function uses more than
some certain number of instructions, it will skip the optimization step.
Perhaps we could preserve the old backend for such cases.
(That is, if the input function is too complicated, just fallback to the
old backend.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/14934#issuecomment-200575768

Try running go test -x -c with both 1.4 and tip. Are there any differences in build actions?

On Go tip
[/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer]$ go version
go version devel +0659cf6 Wed Mar 23 19:22:53 2016 +0000 linux/amd64
[/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer]$ time go test -x -c
WORK=/tmp/go-build249655493
mkdir -p $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/_test/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/
mkdir -p $WORK/github.com/mewmew/uc/uc/gocc/token/_obj/
mkdir -p $WORK/github.com/mewmew/uc/uc/gocc/
cd /home/u/Desktop/go/src/github.com/mewmew/uc/uc/gocc/token
/home/u/go/pkg/tool/linux_amd64/compile -o $WORK/github.com/mewmew/uc/uc/gocc/token.a -trimpath $WORK -p github.com/mewmew/uc/uc/gocc/token -complete -buildid 8b7f374d1fc5ffa423d5d240641f029151c72b20 -D _/home/u/Desktop/go/src/github.com/mewmew/uc/uc/gocc/token -I $WORK -pack ./token.go
mkdir -p $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/_obj/
mkdir -p $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/
cd /tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer
/home/u/go/pkg/tool/linux_amd64/compile -o $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer.a -trimpath $WORK -p _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer -complete -buildid 217e99cb067119187679a189a2297c23179ff229 -D _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer -I $WORK -I /home/u/Desktop/go/pkg/linux_amd64 -pack ./acttab.go ./lexer.go ./transitiontable.go
mkdir -p $WORK/github.com/mewmew/uc/uc/gocc/lexer/_obj/
cd /home/u/Desktop/go/src/github.com/mewmew/uc/uc/gocc/lexer
/home/u/go/pkg/tool/linux_amd64/compile -o $WORK/github.com/mewmew/uc/uc/gocc/lexer.a -trimpath $WORK -p github.com/mewmew/uc/uc/gocc/lexer -complete -buildid 217e99cb067119187679a189a2297c23179ff229 -D _/home/u/Desktop/go/src/github.com/mewmew/uc/uc/gocc/lexer -I $WORK -I /home/u/Desktop/go/pkg/linux_amd64 -pack ./acttab.go ./lexer.go ./transitiontable.go
mkdir -p $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/_test/_obj_xtest/
cd /tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer
/home/u/go/pkg/tool/linux_amd64/compile -o $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/_test/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer_test.a -trimpath $WORK -p _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer_test -complete -D _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer -I $WORK -I /home/u/Desktop/go/pkg/linux_amd64 -pack ./lexer_test.go
mkdir -p $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/_test/
cd $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/_test
/home/u/go/pkg/tool/linux_amd64/compile -o ./main.a -trimpath $WORK -p main -complete -D "" -I .  -I $WORK -pack ./_testmain.go
cd .
/home/u/go1.4/pkg/tool/linux_amd64/6l -o $WORK/_/tmp/go14/src/github.com/mewmew/uc/uc/gocc/lexer/_test/lexer.test -L $WORK/_/tmp/go14/src/github.com/mewmew/uc/uc/gocc/lexer/_test -L $WORK -L /home/u/Desktop/go/pkg/linux_amd64 -extld=gcc $WORK/_/tmp/go14/src/github.com/mewmew/uc/uc/gocc/lexer/_test/main.a
mkdir -p /tmp/go14/src/github.com/mewmew/uc/uc/gocc/lexer/
mv $WORK/_/tmp/go14/src/github.com/mewmew/uc/uc/gocc/lexer/_test/lexer.test /tmp/go14/src/github.com/mewmew/uc/uc/gocc/lexer/lexer.test

real	0m0.599s
user	0m0.557s
sys	0m0.050s

@mdempsky The step which takes most of the time for Go tip is the following:
/home/u/go/pkg/tool/linux_amd64/compile -o $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/_test/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer_test.a -trimpath $WORK -p _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer_test -complete -D _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer -I $WORK -I /home/u/Desktop/go/pkg/linux_amd64 -pack ./lexer_test.go

Can you please provide a link to that source. I cannot figure out which
branch of your repo I need to compile.
On Thu, Mar 24, 2016 at 10:28 AM, Robin Eklind<EMAIL_ADDRESS>wrote:

@mdempsky https://github.com/mdempsky The step which takes most of the
time for Go tip is the following:
/home/u/go/pkg/tool/linux_amd64/compile -o $WORK/_/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer/test//tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer_test.a -trimpath $WORK -p _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer_test -complete -D _/tmp/gotip/src/github.com/mewmew/uc/uc/gocc/lexer -I $WORK -I /home/u/Desktop/go/pkg/linux_amd64 -pack ./lexer_test.go
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/14934#issuecomment-200581827

@davecheney https://github.com/mewmew/uc/blob/9557c0010cde8953d0719ab5df170b8cfbdc3a3f/uc/gocc/lexer/lexer_test.go
(The sha is given in the report.)

I am sorry, this revision does not compile cleanly for me
github.com/mewmew/uc/uc/gocc/lexer
lexer_test.go:11:2: cannot find package "github.com/mewmew/uc/uc/gocc/token"
in any of:
/home/dfc/go/src/github.com/mewmew/uc/uc/gocc/token (from $GOROOT)
/home/dfc/src/github.com/mewmew/uc/uc/gocc/token (from $GOPATH)
% ls $GOPATH/src/github.com/mewmew/uc/uc/gocc/
lexer  Makefile  uc.bnf
On Thu, Mar 24, 2016 at 10:52 AM, Caleb Spare<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney
https://github.com/mewmew/uc/blob/9557c0010cde8953d0719ab5df170b8cfbdc3a3f/uc/gocc/lexer/lexer_test.go
(The sha is given in the report.)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/14934#issuecomment-200586655

@davecheney, I was able to follow the instructions to repro to get my numbers above.

@bradfitz I couldn't get it to work, could you please get a cpu and mem
profile and add their SVGs to the issue. Thanks!
On Thu, Mar 24, 2016 at 10:58 AM, Brad Fitzpatrick<EMAIL_ADDRESS>
wrote:

@davecheney https://github.com/davecheney, I was able to follow the
instructions to repro to get my numbers above.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/14934#issuecomment-200587510

@davecheney Perhaps you didn't run make gen as in the repro steps.

make gen has the gocc tool as a dependency, thus the following commands were included in the instructions above. Also note that the git commit hash 9557c0010cde8953d0719ab5df170b8cfbdc3a3f is on the dev branch.
[~]$ go get github.com/goccmack/gocc
[~]$ export PATH=${GOPATH}/bin:${PATH}

@davecheney All steps in one go, simply copy-and-paste into a terminal to reproduce.
For Go tip
~/go/bin/go version
export GOPATH=/tmp/gotip
~/go/bin/go get github.com/mewmew/uc
~/go/bin/go get github.com/goccmack/gocc
export PATH=${GOPATH}/bin:${PATH}
cd ${GOPATH}/src/github.com/mewmew/uc
git checkout 9557c0010cde8953d0719ab5df170b8cfbdc3a3f
cd uc/gocc
make gen
cd lexer
time ~/go/bin/go test

For Go 1.4
~/go1.4/bin/go version
export GOPATH=/tmp/go14
~/go1.4/bin/go get github.com/mewmew/uc
~/go1.4/bin/go get github.com/goccmack/gocc
export PATH=${GOPATH}/bin:${PATH}
cd ${GOPATH}/src/github.com/mewmew/uc
git checkout 9557c0010cde8953d0719ab5df170b8cfbdc3a3f
cd uc/gocc
make gen
cd lexer
time ~/go1.4/bin/go test

Thanks Robin!
On Thu, Mar 24, 2016 at 11:50 AM, Robin Eklind<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney All steps in one go, simply
copy-and-paste into a terminal to reproduce.
For Go tip
~/go/bin/go version
export GOPATH=/tmp/gotip
~/go/bin/go get github.com/mewmew/uc
~/go/bin/go http://github.com/mewmew/uc~/go/bin/go get github.com/goccmack/gocc
export PATH=${GOPATH}/bin:${PATH}
cd ${GOPATH}/src/github.com/mewmew/uc
git checkout 9557c0010cde8953d0719ab5df170b8cfbdc3a3f
cd uc/gocc
make gen
cd lexer
time ~/go/bin/go test
For Go 1.4
~/go1.4/bin/go version
export GOPATH=/tmp/go14
~/go1.4/bin/go get github.com/mewmew/uc
~/go1.4/bin/go get github.com/goccmack/gocc
export PATH=${GOPATH}/bin:${PATH}
cd ${GOPATH}/src/github.com/mewmew/uc
git checkout 9557c0010cde8953d0719ab5df170b8cfbdc3a3f
cd uc/gocc
make gen
cd lexer
time ~/go1.4/bin/go test
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/14934#issuecomment-200600445

Thanks Robin!

You are very welcome. I'll look into generating CPU and memory profiles.

Don't spend time on the 1.4 data, it's not going to change. The SVG for
memory usage and cpu usage for tip are the important ones. I suggest
go test -i $PKG   # compile all the test depenencies to ensure only one
command is run
go test -gcflags='-cpuprofile=/tmp/c.p' $PKG
go tool pprof -svg $(go tool -n compile) /tmp/c.p
On Thu, Mar 24, 2016 at 11:51 AM, Robin Eklind<EMAIL_ADDRESS>wrote:

Thanks Robin!
You are very welcome. I'll look into generating CPU and memory profiles.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/14934#issuecomment-200600648

Thanks for the how to instructions. I ran the commands you suggested and got the following profiles.
CPU profile

Memory profile

From what I can tell, it doesn't look like the profile managed to capture the entire compilation time? The CPU profile only captured 10 ms of the 20 seconds. And the memory profile only captured ~5 MB of the ~3 GB. Any suggestions?

I hacked together a standalone file slow.go from lexer_test that gives pretty awful performance (but not 30x slower).  The 3k lines of go generates over 4 million SSA values.

Run the command with -X, I think there may be more than one compile happening, overwriting the file.
Worse case you can copy and paste the output from -x and run each command by hand.

On 24 Mar 2016, at 12:14, Robin Eklind<EMAIL_ADDRESS>wrote:
Thanks for the how to instructions. I ran the commands you suggested and got the following profiles.
CPU profile
Memory profile
From what I can tell, it doesn't look like the profile managed to capture the entire compilation time? The CPU profile only captured 10 ms of the 20 seconds. And the memory profile only captured ~5 MB of the ~3 GB. Any suggestions?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@tzneal Thanks! Profiling slow.go produces the following for Go tip.
[/tmp/gotip/src/slow]$ go version
go version devel +0659cf6 Wed Mar 23 19:22:53 2016 +0000 linux/amd64

CPU profile

Memory profile

Lots of inlining, lots of gotos, big slice constructor, not surprised it is bad.
LookupVarOutgoing & friends point to the phi generation algorithm which is not perfect at the moment.  We're using something that is usually good in practice but can but O(n^2) in some cases, which this CL may tickle.

Possibly a dup of #14774.

David, does your sparse phi insertion CL help here?

Sparse phi insertion helps.
Doesn't get back all the performance, but lots better than it was.
(Timings on a Macbook Air laptop running on battery)
export GO_SSA_PHI_LOC_CUTOFF=0 # use sparse everywhere
time go test
...
real	0m13.318s
user	0m14.309s
sys	0m0.863s

export GO_SSA_PHI_LOC_CUTOFF=-1 # use sparse nowhere
time go test
...
real	0m33.241s
user	0m39.499s
sys	0m2.954s

export GO_SSA_PHI_LOC_CUTOFF=2500000 # default threshold 2.5million (#vars*#blocks)
time go test
...
real	0m13.448s
user	0m14.335s
sys	0m0.955s

New profiles from compiling lexer_test.  locatePotentialPhiFunctions is still doing a lot of work even when sparse and there might be some upside hiding there, but the big pig is now register allocation and all the memory that it allocates.   Still 38X?

I now get
go1.4:
real	0m0.843s
user	0m0.626s
sys	0m0.104s

tip:
real	0m8.631s
user	0m11.185s
sys	0m0.586s

So ~10x

Also, FWIW
go1.6:
real	0m1.785s
user	0m1.956s
sys	0m0.262s

So ~2x from 1.4 to 1.6, ~5x from 1.6 to tip.

OK, well it sounds like that's just where we're going to be for Go 1.7?
It's not like all compiles are 10X slower, just large init tables.
(See also #1860, #6289.)

FYI, I just checked whether https://go-review.googlesource.com/c/23136/ is any help here, and it is:
Before (tip as of this morning, includes the sparse CL):
time go test
...
real	0m7.208s
user	0m9.288s
sys	0m0.277s

After:
time go test
...
real	0m4.488s
user	0m4.613s
sys	0m0.266s

That is queued up for 1.8.

It sounds like current tip is 10x slower. @rsc @randall77 @dr2chase Is there anything we still want to do here for Go1.7, or should I move this to Go1.8?

Nothing else planned for 1.7.  Let's move this to Go1.8early.

This is now fixed.  Tip compiles Todd's slow.go in under half a second.
Tip is ~2x slower than 1.4 and ~3x faster than 1.6.  I'm happy with that.

I can confirm that tip is ~2x slower than 1.4.
Average from 10 consecutive runs follow the instructions of https://github.com/golang/go/issues/14934#issuecomment-200600445:
For Go 1.4:
Average time 0.5824 sec.

The comparison has been updated above. @randall77, my results do not seem to mirror yours. Any idea as to why this may happen? Can I assist with some additional information?

The numbers I quoted above were for Todd's example, not yours.
I am seeing similar numbers for your example (I get tip 5.5x slower than 1.4).
I'm inclined to leave this issue closed.  It's only a 4 second build.  (Most of that time is regalloc.)


Filters in Kubernetes Views not functioning - shows all namespaces only

WC Version: 0869d26e
Cloud: Digital Ocean
OS: Unbuntu: 16.04.2  4.4.0-79-generic
Kubernetes: Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.5", GitCommit:"490c6f13df1cb6612e0993c4c14f2ff90f8cdbf3", GitTreeState:"clean", BuildDate:"2017-06-14T20:15:53Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
Can't filter my app (sockshop) by its namespace in the Kubernetes views.
 Are you clicking on the "sock-shop" namespace selector but it's not activating?

I'm not seeing this behaviour now. If I see it again. I will reopen this.


Feat/tokenuri

This is for the metadata generation, replacing the base64 branch.
Tasks for metadata:

Dynamic URI size based on resource and wonder ownership
Different image link based on Realm and S_Realm (SVG and 3D render)
Lookups for ID to ASCII encoded text
Tests

I have so far implemented the URI logic for all apart from realm names. Please can you review so far and advise on whether to follow the same pattern for Realm names? (i.e hardcoding 8000 ASCII encoded felts and looking up)
Also, I cannot find the current SVG link to lookup for data of a Realm (rather than S_Realm). I have currently implemented https://realms-assets.s3.eu-west-3.amazonaws.com/{realm_id}.svg.
Please review so far and I will complete.
ADDED NOTE:
Noticed some inconsistencies in spelling (British English v American English). game_structs.cairo struct RealmData refers to Harbour, whereas metadata files are Harbor. I have used metadata file spelling in the encoding, but we should think about consistency.

Potential for checking through 8000 realm names (even if we return when found) seems quite a task. Looked into adding into the realm data, as we have 148 bits to play with.
Unfortunately 17 realm names, when encoded are over 148 bits. List below:
Hlu‘nri‘‘ro‘
‘inwan‘i‘neh
‘ok‘ok‘el‘el
‘á‘ha‘á‘kákó
‘illo‘‘i‘‘i‘
‘la‘‘rek‘ol
‘uol‘o‘‘uol
Kem‘a‘‘apwüm
Šïšäššïšäš
‘a‘ po‘ Ljo‘
Pü‘‘ek‘alpö‘
‘upch‘u‘ch‘i
‘emi‘e‘e‘en
‘o‘lup‘o‘‘o‘
hä‘ Pë‘lë‘
Lal Wóú‘‘óuw
Smá‘á Shá‘á

All apart from one have ‘ in a few characters, if we replace this with ' the bits reduce to under 148. Then need to decide how we sort Šïšäššïšäš (160 bits).
Just throwing out some ideas. Len me know thoughts.

@milancermak review comments have been added.
I have also now added realm_name as storage in set_realm_data.
Had to fiddle with sumbmoduls, cairo_erc4626 now has latest updates. Hope does not cause problems.


Add duplicate application option

Seems like a straight forward test case can be added to check if the dsl exists in the cloned app.


Fix: Backend of Contact form

Description
Connect it to the server.
Screenshots
No response
Additional information
No response

Can I be assigned this??


Generate CLI client from GRPC protocol file

Is your feature request related to a problem? Please describe.
Hi. I’m new to GRPC and I’m trying to find a framework that can generate the SDK of multiple languages and the CLI from one protocol file, similar to AWS json protocol: https://smithy.io/1.0/spec/aws/aws-json-1_0-protocol.html. GRPC can only generate language specific client (similar to SDK) but not CLI today.
Describe the solution you'd like
Generate CLI client from GRPC protocol file. For example, the hello-world protocol (https://github.com/grpc/grpc-go/blob/master/examples/helloworld/helloworld/helloworld.proto) can generate a CLI application that has this command support.
$ greeter say-hello --name “Ziwen"

There can be a global config or env var to point the server endpoint. The command will call the GRPC service running in the endpoint. If the service is running, it will return “Hello Ziwen”.
Describe alternatives you've considered
I know there are multiple tools that can call the GRPC service in terminal, but they are different with generating an independent CLI tool, so can't support the same use cases.
Additional context
Did GRPC community have this discussion before? Are there any blockers or scope concerns of having this feature in GRPC? I’m happy to contribute to it if GRPC has the interest, and also interested to learn the concern if not.

I think https://github.com/fullstorydev/grpcurl is what you are looking for :)

@yashykt
Looking into the documentation, it is different with the request of this issue.
Grpcurl still relies on a grpcurl  cli
grpcurl -d @ grpc.server.com:443 my.custom.server.Service/Method <<EOM
{
  "id": 1234,
  "tags": [
    "foor",
    "bar"
  ]
}
EOM

The issue requests generating a independent CLI
$ greeter say-hello --name “Ziwen"

Even if they both call GRPC service in terminal, the use cases can be much different. The service owner may directly distribute the generated independent CLI to users to let them use the service with seamless CLI experience. But it is not typical to ask their users to use a third party CLI to support it.


Release 0.2.1

Codecov Report

Merging #23 (b6035b7) into main (5f7c688) will decrease coverage by 0.59%.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##             main      #23      +/-   ##
==========================================
- Coverage   96.49%   95.90%   -0.59%
==========================================
  Files          12       12
  Lines         342      342
==========================================
- Hits          330      328       -2
- Misses         12       14       +2

see 1 file with indirect coverage changes


Archive (ZIP, 7z, rar, ...) extension

Taken from https://github.com/radiantearth/stac-spec/issues/921#issuecomment-746398428:
What I thought would be useful to add something like an "archive" extension, which allows to specify individual files from archives in assets, e.g. linking to a xml and tiff in a zip so that you can use for example eo:bands to describe the tiff in the archive. Something like archive:path could describe the path of the file in the archive (e.g. ZIP) and allows direct mapping and extraction. May also be useful for Zarr or so?
@DanielJDufour agreed in a private message:

I saw your comments here about a possible "archive" extension [..] and just wanted to say that I think it would be a great idea. I often see data producers who don't have any experience with web technologies releasing files as zip files and it could be a good opportunity for software devs to create STAC catalogs of the metadata without having to host the actual files.

I'm very much in favour of an archive extension.  We're currently experimenting with using STAC to automate data management (downloading) between server and client applications.  We need the client to check if files have already been downloaded and extracted, so it needs to know the contents of the archive.  We added the contents and target_folder objects to aid in this:
"assets": {
        "analytic": {
            "href": "https://my.server.com/data/arctic/2020_37_258.zip",
            "roles": ["data"],
            "type": "application/zip",
            "contents": [
                {
                    "name": "2020_37_258.cnt"
                }
            ],
            "target_folder": "./data/artic/"
        },

@brentfraser What exactly is target_folder referring to? I don't understand the purpose...
Just for future reference, here's an example of how I imagined it to be, e.g. for a ZIP file containing an image (data/image.tiff) and a metadata file (meta/iso.xml):
{
  ...
  "assets": {
    "analytic": {
      "href": "https://my.server.com/data/category/example.zip",
      "roles": [
        "data",
        "archive"
      ],
      "type": "application/zip",
      "archive:href": "data/image.tif",
      "archive:type": "image/tiff"
    },
    "metadata": {
      "href": "https://my.server.com/data/category/example.zip",
      "roles": [
        "metadata",
        "archive"
      ],
      "type": "application/zip",
      "archive:href": "meta/iso.xml",
      "archive:type": "application/xml"
    }
  }
}

The use case is for automatic dowmloading by the client, so we added the target_folder as a hint as to where to save the zip file.  We could have just had the client app decide, but this adds a little bit of flexibility for the future.  It's very application-specific so I wouldn't expect it to be added to the STAC spec.
Since the archive could have more than one file, I added the contents as a list of objects.  Using your example as a guide we could have:
        "archive:contents": [
            {
                "href": "2020_37_258.cnt",
                "type: "application/octet-stream"
            },
            {
                "href": "2020_37_258meta.txt",
                "type: "text/plain"
            },

@brentfraser Yeah, my examples lists the archive twice (i.e. as often as there are assets). I guess that's a matter of how we understand assets. It could either list the archive once or multiple times. The latter is easier for validation and the behavior of adding specific things like eo:bands to assets works better. I guess my proposal would also work in your case, right?

@m-mohr  Ah I missed that the archive name was the same for both of the contained assets.  I see the wisdom of your approach in that it allows for using all of the STAC spec asset objects to describe the content.  The little bit of duplication in specifing the href/roles/type and the overhead of the client comparing the href is worth the flexibility when multiple files are in the archive.  Thanks!

An archive extension would be useful for the work we're doing on Radiant MLHub, as well. We are generating gzipped tar archives all assets associated with our collections to make it easier for users to download a dataset in its entirety.
I'm thinking that one way we might use this would be in combination with the Collection-level assets introduced in #800. We would reference the tar archive as an asset on the Collection, but then Items would also have assets that point to the location of those resources within the main archive.
Because our collections can sometimes contain hundreds of thousands of items, I think the implementation that @m-mohr is suggesting would work better for us than the implementation that @brentfraser suggests. A single "contents" list on the collection would become too unwieldy, but having a way to reference an archive within each Item would be reasonable.

@m-mohr Just to clarify, the archive:href and archive:type properties would be optional, yes? When referring to the archive itself as an asset it seems like neither of those would be relevant.

Yes, I think so. Would anything else be needed except href and type?

It would probably be useful for us to have something like an archive:size property that gives the total byte size of the archive. This might only be relevant on the main archive asset, though.
For the type, it would be good to be able to represent both the type of archive and any compression that was applied. I'm not sure this is possible with MIME types. I know we could use application/gzip to indicate the compression, but I don't think there's anything to indicate something like a tar archive.

It would probably be useful for us to have something like an archive:size property that gives the total byte size of the archive.

We have recently added file:size, which would achieve exactly that, I guess. Although one could argue that it's the size of the file in the archive. On the other hand it's counter intuitive if archive:size refers to the archive size while all other archive:... fields refer to the file in the archive...

For the type, it would be good to be able to represent both the type of archive and any compression that was applied. I'm not sure this is possible with MIME types.

I don't think that is possible with media types.

I know we could use application/gzip to indicate the compression, but I don't think there's anything to indicate something like a tar archive.

Yeah, the issue is that it's inside the gz again, so not just one leve.
One could think of nesting it so that the first level describes the gzip and the second level describes the tar. But that seems a bit over the top. Maybe we just make archive:type and archive:href an array so that it can go through it after each other:
href: 'example.tar.gz',
type: 'application/gzip',
archive:type: ['application/tar', 'image/tiff'],
archive:href: ['example.tar', 'image.tiff']

What would you all think about adding properties to indicate the byte range for the asset inside a zip file?  For example, if you had a zip for 4 different crop types (corn, wheat, barley, rice):
{
    "assets": {
        "corn": {
            "href": "https://my.server.com/data/category/example.zip",
            "roles": [
                "data",
                "archive"
            ],
            "type": "application/zip",
            "archive:href": "data/corn.tif",
            "archive:type": "image/tiff",
            "archive:start": 0,
            "archive:end": 73242
        }
    },
        "wheat": {
            "href": "https://my.server.com/data/category/example.zip",
            "roles": [
                "data",
                "archive"
            ],
            "type": "application/zip",
            "archive:href": "data/wheat.tif",
            "archive:type": "image/tiff",
            "archive:start": 73243,
            "archive:end": 132021
        }
    }
}

We could also consider, something like: "archive:range": "bytes=73243-132021" to mimic HTTP Range Requests (https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests).
Here's some complications:

The client may need to assume other relevant metadata found in the zip file's central directory.
Not all archive formats concatenate files like zip, so this wouldn't apply in many cases.

Here's some benefits:

Clients could automatically grab the assets from a zip file without reading the header first
You could calculate the file size quite easily (but this is probably covered by the fileinfo extension...)

I'm not strongly opinionated about it, but just curious to hear your thoughts.  We could also consider rolling this into a zip-specific extension.  Does STAC have a concept of sub-extensions like "archive:zip:start": 73243?

It would probably be useful for us to have something like an archive:size property that gives the total byte size of the archive.

We have recently added file:size, which would achieve exactly that, I guess. Although one could argue that it's the size of the file in the archive. On the other hand it's counter intuitive if archive:size refers to the archive size while all other archive:... fields refer to the file in the archive.

I agree that the scope of archive:size would be confusing since the other archive:* properties refer to files in the archive. I think file:size would be clear enough in the context of the other properties. In the absence of archive:href and archive:type properties we would infer that the asset (and the file:size property) refers to the entire archive. If those properties are present, we assume it refers to an individual member of the archive.

I know we could use application/gzip to indicate the compression, but I don't think there's anything to indicate something like a tar archive.

Yeah, that it's not just one level could be an issue.
One could think of nesting it so that the first level describes the gzip and the second level describes the tar. But that seems a bit over the top. Maybe we just make archive:type and archive:href an array so that it can go through it after each other:
href: 'example.tar.gz',
type: 'application/gzip',
archive:type: ['application/tar', 'image/tiff'],
archive:href: ['example.tar', 'image.tiff']

This would work for members within the archive, but we would also want to have a property that is present for the archive asset itself that contains this info. In the case where an asset refers to the entire tar archive it seems like we wouldn't be using the archive:* properties, so the asset would look something like this...
"archive": {
      "href": "example.tar.gz",
      "roles": [
        "metadata",
        "archive"
      ],
      "type": "application/gzip",
}

...and it would be nice to have something in there that indicates how a client should handle the archive.
I agree that nesting it seems a bit heavy-handed. Here are a few thoughts on how we might handle it:

Allow type to be a list and do something similar to what you suggest for archive:type. In this case, our archive might look like:
{
  ...
  "type": ["application/gzip", "application/x-tar"]
...
}

Add an archive:format property that is defined at the archive level to handle this info. Then the archive asset might be:
 "archive": {
   "href": "example.tar.gz",
   "roles": [
     "metadata",
     "archive"
   ],
   "type": "application/gzip",
   "archive:format": "application/x-tar"
}

and a member of the archive might look like this:
"image": {
  "href": "example.tar.gz",
  "type": "application/gzip",
  "archive:format": "application/x-tar",
  "archive:type": "image/tiff",
  "archive:href": "data/image.tiff"
}

As you suggested for archive:size above, this could be counterintuitive if the other archive:* properties apply to archive members, but if it's clearly documented then it might be okay.

We could also consider rolling this into a zip-specific extension. Does STAC have a concept of sub-extensions like "archive:zip:start": 73243?

Yes, I think I'd prefer a separate extension as it's very specific. We don't have anything like that where you can have two extension prefixes, but you can simply add zip:start and inherit from archive in the JSON Schema of the ZIP extension.

I agree that the scope of archive:size would be confusing since the other archive:* properties refer to files in the archive.

The way I'd design the extension is that it's fully backward compatible for clients that do not implement the archive extension. Thus all common fields must refer to the archive file. For example, file:size refers to the archive file size. On the other hand, the properties like file:bits_per_sample don't make much sense any longer on the top level. Other properties work better, like eo:bands, which seems also reasonable to have at this level and just tells that there are those bands in the zip file. Looking at the extensions, the only extensions that are somewhat problematic seem to be file and timestamps. We need to clearly document how to use them in combination with archive and on the same hand make sure it's compatible with clients not implementing archive.
@duckontheweb Honestly, I don't understand your second comment (https://github.com/radiantearth/stac-spec/issues/956#issuecomment-772955132) . I don't understand the difference between my proposal for "two-level" archives?!

@duckontheweb Honestly, I don't understand your second comment (#956 (comment)) . I don't understand the difference between my proposal for "two-level" archives?! We won't be able to change the type to arrays though.

Yeah, sorry for the rambling reply on that one... The only difference is that in your proposal the archive:type property would have one value that applies to the archive (application/tar) and one value that applies to the member within the archive (image/tiff). I was proposing that we separate those so that archive:format only ever refers to the archive itself. archive/type and archive/href would only be present for assets that refer to members within the archive. I'm open to pushback on this, though...

What would you all think about adding properties to indicate the byte range for the asset inside a zip file?

I'd be +1 on this as long as it's optional. But clearly not all archive formats support random access to a single file.

The extension now lives at https://github.com/constantinius/archive/


Add support for detection in nested archives

Currently, the detection mechanism only looks into outer archives or nested ZIP archives. However, there are many normal/valid instances where a vulnerability may be in a nested archive (for example, a JAR within a TGZ). The crawling/detection logic should be updated such that all nested archive types are examined recursively.

Closed by https://github.com/palantir/log4j-sniffer/pull/47

Closed by https://github.com/palantir/log4j-sniffer/pull/47


added new grommet icons

added grommet icons

Closing since https://github.com/grommet/grommet-site/pull/357 was merged


ISSUE 343 : Provide example to demonstrate custom schema lifecycle

ISSUE  343: Provide example to demonstrate custom schema lifecycle.
Closes #343

@satishd: Addressed review comments and made required changes as per our discussion


fixed club model

Created object in meeting time to hold day, time, period. Also added require for a clubs name, description, and officer.

@mbarbas11  can you add the active attribute to the club schema? it's a boolean that marks if the club is still active or not.
And we decided to have a favorite functionality in our project, can you add an attribute for it too? you can call it whatever you want. it basically just stores the users' id that favorite that club

No problem, I will add it today

Should the active attribute be required?

@mbarbas11 yes, it should be required

Finish changing club model and also create user model


[FLINK-3466] [runtime] Cancel state handled on state restore

This pull request fixes the issue that state restore operations can get stuck when tasks are cancelled during state restore. That happens due to a bug in HDFS, which deadlocks (or livelocks) when the reading thread is interrupted.
This introduces two things:

All state handles and key/value snapshots are now Closable. This does not delete any checkpoint data, but simply closes pending streams and data fetch handles. Operations concurrently accessing the state handles state should fail.
The StreamTask holds a set of "Closables" that it closes upon cancellation. This is a cleaner way of stopping in-progress work than relying on "interrupt()" to interrupt that work.

This mechanism should eventually be extended to also cancel operators and state handles pending asynchronous materialization.
There is a test that has an interrupt sensitive state handle (mimicking HDFS's deadlock behavior) that causes a stall without this pull request and cleanly finishes with the changes in this pull request.
This also adds a test validating that all state handled and key/value snapshots add a proper serialVersionUID.

Looks very good! The test failures seem unrelated:

ClientTest: https://issues.apache.org/jira/browse/FLINK-4220 (newly created)
JobManagerHACheckpointRecoveryITCase: https://issues.apache.org/jira/browse/FLINK-3516 (known instability)
Travis Scala dependency issue

The added tests and refactorings are very readable.
I think this is good to merge mod some minor inline comments.

Thanks, I'll address your comments and merge this...

Manually merged in e9f660d1ff5540c7ef829f2de5bb870b787c18b7

Is this related to https://issues.apache.org/jira/browse/HADOOP-14214? Thanks,

I think it is yes. We worked around it in the meantime...


Feature request: Ability to reply in HTML

Is it possible to reply to a message using HTML? I see that the HipChat API does allow for it.
Thanks!

+1 :+1:

See #270
We have it deployed and it's working pretty well.


Ping a service without revealing the target IP address when service is down

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
I'm looking for a way to mask the IP address (for security concerns) when the monitored service is down.
Currently for Ping monitoring, the standard output error message sent to my telegram is as such:
[Service] [🔴 Down] PING HOSTNAME ([<IP_ADDRESS>](http://<IP_ADDRESS>/)) 56(84) bytes of data.
I have used hostAliases to map custom hostname to target IP but the IP is still shown together with the custom hostname.
HTTPs monitoring have the same issue of disclosing the FQDN.
Is there any way to mask the IP/FQDN and only show the friendly name of my monitored service?
🐻 Uptime-Kuma Version
1.20.1
💻 Operating System and Arch
Ubuntu 20.04 x86
🌐 Browser
Google Chrome 110.0.5481.104
🐋 Docker Version
K8S
🟩 NodeJS Version
No response

No straightforward way to do that. You need to write your own program.
Uptime Kuma setup a webhook notification => Your program receive the webhook notification and mask it => Telegram


Added the Friends/Home screen fix

Sorry to deny your commit bcuz I have already prepared everything and commited it but I still did not push. I am really sorry.


Iframe proxied requests may have invalid Referer header

What is your Test Scenario?
Currently I'm implementing third party integration which uses iframe to get their SDK. They use API keys and allow-list to either deny iframe request or to accept it. E2E tests using Testcafe are failing with the "deny" error whilst manual tests on the same environment work. Localhost host which Testcafe is using is whitelisted for the given API key. The issues seems to be connected to the request being sent with invalid header:
Here's how I found it
class 3rdPartySDKHook extends RequestHook {
    constructor() {
        const requestFilterRules = [/* regex filtering requests to only those iframe is performing */];
        super(requestFilterRules);
    }

    public async onRequest(event: any): Promise<void> {
        console.log(event.requestOptions.headers);
    }

    public async onResponse(): Promise<void> {
        // noop
    }
}

const hook = new 3rdPartySDKHook();

fixture`My fixture`
.page(TEST_URL).requestHooks(hook);

What is the Current behavior?
The Referer header is set to unproxied version of iframe src.
What is the Expected behavior?
The Referer header is set to url of page rendering iframe.
What is your web application and your TestCafe test code?

Working workaround:
class 3rdPartySDKHook extends RequestHook {
    constructor() {
        const requestFilterRules = [/* regex filtering requests to only those iframe is performing */];
        super(requestFilterRules);
    }

    public async onRequest(event: any): Promise<void> {
        event.requestOptions.headers.referer = TEST_URL;
    }

    public async onResponse(): Promise<void> {
        // noop
    }
}

const hook = new 3rdPartySDKHook();

fixture`My fixture`
.page(TEST_URL).requestHooks(hook);

Steps to Reproduce:

Use iframe with src that uses ACL based on origin.
See if the origin header gets set properly.

Your Environment details:

testcafe version:                   1.9.4
node.js version:                    lts/erbium
command-line arguments:  chrome --disable-web-security --allow-insecure-localhost --use-fake-device-for-media-stream --use-file-for-fake-audio-capture
browser name and version: Chrome 90
platform and version:          macOS 11.2.3

I wasn't able to reproduce this issue. Could you please clarify how the iframe with src should look?
I used the following code:
require('http')
    .createServer((req, res) => {
        if (req.url === '/') {
            res.writeHead(200, { 'content-type': 'text/html' });
            res.end(`<iframe src="http://localhost:2022/" referrerpolicy="unsafe-url"></iframe>`);
        } else
            res.destroy();
    })
    .listen(2021, () => console.log('http://localhost:2021/'));

require('http')
    .createServer((req, res) => {
        if (req.url === '/') {
            res.writeHead(200, { 'content-type': 'text/html' });
            res.end(`Referer header: ${req.headers.referer}`);
        } else
            res.destroy();
    })
    .listen(2022, () => console.log('http://localhost:2022/'));

It creates two servers. The first one renders the iframe with the src attribute, which points to the url of the second one. Then I used the following test code:
import { RequestLogger } from 'testcafe';

const logger = RequestLogger('', {
    logRequestHeaders: true
});

fixture `My fixture`
    .requestHooks(logger)
    .page `http://localhost:2021/`

test(`Referer should be set to url of the page rendering iframe`, async t => {
    await t
        .expect(logger.requests[1].request.headers.referer).eql('http://localhost:2021/');
});

It passed the check that the Referer header was set to the url of the page that renders the iframe ('http://localhost:2021/') as expected.
Also, please update your TestCafe version to the latest version (v1.14.2 right now) to be sure that the issue can still be reproduced with it.

Hey, I'll try doing that outside of work, since we're fine with workaround and didn't intend on updating Testcafe version for now. It might be possibly fixed between current version and one I was using. I'll also try to provide a better example without actually revealing what iframe src was since I can't do that.

Thank you for the reply. I'll close this ticket then. Feel free to reopen it or open a new one once you can share an example.


Offical Python Package

Hello @peterhinch
thank you for this great package.
Would you be interested to publish your package on pypi.org? I really would love to use upip to install this on my ESP8266
Greets,
Christian

You can use a tool like rshell or mpremote to copy the files to an ESP8266 filesystem.

Yes. I know this tools. But I would like to have an experience like using pipenv install. I can even provide you with a pipeline for this.

Promoting micropython-msgpack to PyPI is actually a great idea – but perhaps not for the expected reason. As Peter says, the official mpremote remote is MicroPython's de facto package manager. (rshell, on the other hand, is largely unmaintained, non-portable, and irrelevant in 2022.)
Then why would promoting micropython-msgpack to PyPI be a great idea? Forwards compatibility and namespace parking. By claiming micropython-msgpack on PyPI, you prevent others from doing so. Moreover, MicroPython will probably provide a genuine package manager at some point; at that point, PyPI-hosted packaging will suddenly be the MicroPython norm rather than the exception.

I don't understand how mpremote could be a package manager.
I really would like to use upip to get every dependency into my repository. For my project, I've the following workflow. I have a setup.py script, where I describe my dependencies. I can execute it with micropython (unix port) which copy the dependencies into a directory. Now I can execute, copy or mount everything with mpremote onto my board (ESP32). Without a python package, I've to copy this library into my repository.

At least to make a one file library, with one single class.
This would facilitate the code integration into an existing project file especially if your project uses OTA, so not an additional file to upload/handle.
Also ensure it works on MP and regular python since we need to pack/unpack on the server side too.

At least to make a one file library, with one single class.

The docs explain the reason for the design: to save resources by using "lazy imports".

Also ensure it works on MP and regular python

I did not target CPython because u-msgpack-python supports it. As explained in the docs, this library was derived from the above with the objective of running on a microcontroller. MessagePack is a standard protocol: you can use any library on the server.

This package can now be installed to a microcontroller using the official mpremote tool.
On CPython options are manual installation or to use u-msgpack-python.


React query plugin comments

Commenting on main logic of react query plugin.

@Zetazzz can you check on the conflict, maybe we need to rebase?

Done, thanks!


[Docs]: Improve - OIDC - Okta Docs

Is there an existing issue for this?

[X] I have searched the existing issues

Documentation Link
https://docs.appsmith.com/setup/instance-configuration/single-sign-on-sso/openid-connect-oidc/okta
Describe the problem
For setting up OIDC, a couple of things actually.
1 - From this documentation link,I was lost after "Save the redirect URL ..... " part, where you move on to the OIDC providers.
2 - I was stuck was while following the Okta doc..
From the video on the above page, I could not find the Okta Domain in my General Settings section.
Attaching a screenshot below.

Describe the improvement
For 1 - That could be because I am a newbie in this area, but is there a possibility of some more clarity before giving the links to the exhaustive guides? You could just probably reword it with- "you can choose to integrate with any one of the following OIDC providers, and click on any of them to learn more" .. {With the current format, I actually thought I had to do steps from all of the providers listed there !! :smiling_face_with_tear:}
For 2 - I found it in the following place -

@btsgh - Please verify and log details if I've missed anything.


Update smoltcp dependency to 0.9.0

The smoltcp 0.9.0 release has some features that would be nice to use, but is backwards-incompatible, so I made this PR that updates the dependency and makes the necessary changes to be compatible with the upgrade.
I verified it by checking that my code (which uses this crate and smoltcp extensively) still works, but I'm open to doing other verification to demonstrate that it still works if you want.
Being compatible with the newer version of smoltcp does impose some backwards-incompatible changes on this crate's API, so it'll have to come with a version bump. I hope this is acceptable.

Thanks for the PR! I haven't looked at the 0.9.0 release of smoltcp yet, but of course to would be great to upgrade.
There aren't any special requirements for testing this, but I would ask that you check the examples that use smoltcp. The CI requires that they compile, and before merging the PR I will check some or all of them still function correctly.

Thanks for the PR! I haven't looked at the 0.9.0 release of smoltcp yet, but of course to would be great to upgrade.
There aren't any special requirements for testing this, but I would ask that you check the examples that use smoltcp. The CI requires that they compile, and before merging the PR I will check some or all of them still function correctly.

Good check, the examples don't presently work. I'll fix this up and then get back to you on this.

I think these changes should fix the examples. I don't have the setup to actually run them, but they all compile and I think they should work.
Also, the new smoltcp version requires a newer rust version than your CI is running. I didn't touch the MSRV for this crate since it's an optional dependency, but your CI will have to be updated to at least 1.65 for it to run (sorry, I don't know how CI works, so I don't know how to do this myself).

I actually suggest that you do bump the MSRV of this crate from 1.62 to 1.65. There's a commit here that shows how to change the MSRV in both the README and the CI.

rust-version should probably also be updated in Cargo.toml. Seems like this was missed the last time msrv was bumped.

I'm actually of the opinion of forcing people to upgrade this. They're free to remain on older versions of stm32h7xx-hal, but I don't see the purpose in slowing down development of the HAL to accomodate people not wanting to keep dependencies updated.
Context: I'm currently in the process of updating smoltcp-nal to support 0.9, the changes are non-trivial, but it's not bad IMHO.

This needs to be rebased onto master, but is otherwise ready to merge. I don't have permission to modify this branch, so @JarredAllen would you prefer to perform the rebase yourself?

This needs to be rebased onto master, but is otherwise ready to merge. I don't have permission to modify this branch, so @JarredAllen would you prefer to perform the rebase yourself?

Sorry about that, I don't know why it didn't let you rebase it (I thought I enabled the option to let people with access to this repo edit my PR, but maybe I misclicked or something?), but it should be rebased and ready to merge now.

No problem. Thanks for the contribution!
bors r+

bors r+


Unpin tox version used by travis

We're already using the latest tox when running tests locally, let's do the same for travis runs.

Coverage remained the same at 99.579% when pulling b29e6361a4d84873ce1e887de2aceb27d945f9f3 on sjaensch:upgrade-tox-travis into 37395a51e8ced9690dfe1db9b376238441ac7507 on striglia:master.

Coverage remained the same at 99.579% when pulling b29e6361a4d84873ce1e887de2aceb27d945f9f3 on sjaensch:upgrade-tox-travis into 37395a51e8ced9690dfe1db9b376238441ac7507 on striglia:master.


swift 3 pod update?

Hi there, any swift 3 pod update?

the latest version is swift 3

i did do a pod update, but still get this message:
SwiftSpinner will not be code signed because its settings don't specify a development team.
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.


Support for Google App Engine

Does this library or python3-saml run on Google App Engine or has anyone gotten this library to run on GAE? GAE only allow 3rd party libraries that are written in pure python with no C extensions and I'm looking for an alternative to Pysaml2 since that relies on a C crypto library.

No idea if is compatible with GAE.


When there is only one button on the right, or there are multiple buttons, clicking the rightmost button will crash

*** Assertion failure in -[UITableView _Bug_Detected_In_Client_Of_UITableView_Invalid_Number_Of_Rows_In_Section:], UITableView.m:2581

Because I need to delete the cell after requesting the network


Update index.js

Hello man,
Here is a small modification of the families!

Of the ternary.
Arrow function.
Of the love.

Peace and love 🥇

As far as I can tell, this PR doesn't change any functionality, but would make this library break in es5 envs and require a major version bump.
I appreciate the feedback but I'm gonna have to pass on merging this. Thanks anyway!


allow -1 file descriptor for ioregionfd

This allows setting up a shadow ioeventfd without an eventfd. This can be useful when the ioeventfd doesn't need to be kicked but the value still needs to be copied e.g. NVMe completion queue head doorbells.

can we add a test?

done


[DX] installation has 4 commands, which is a lot

Bug report
What I did
Followed the v6 docs to install Backpack.
What I expected to happen
Be easy - one-two commands max.
What happened
It's a whopping four commands:
composer require backpack/crud:"v6.x-dev"
php artisan storage:link
php artisan backpack:install
php artisan basset:internalize

What I've already tried to fix it
Nothing yet. But I think we should:

🔴 MUST automatically do php artisan storage:link upon installation;
🟡 but then again... php artisan storage:link is something the developer should do upon each installation... so how about we run it (sure) but also prompt the developer, ask if they want us to add it to composer.json scripts, under post-install-cmd? that way we make sure the dev runs php artisan storage:link, at least upon first deployment; fewer headaches on deployment;
🔴 MUST run php artisan basset:internalize as a last step in the Backpack/CRUD installation process; and maybe in all our backpack:require-x commands too? 🤷♂

Note:

I’ve followed the docs to install a clean v6, which instruct me to do “php artisan basset:internalize” first, then “php artisan backpack:install”. That’s done in order for the last command to be actionable, to show the final URL people should click and get started with their admin panel. But there’s a problem… because theme-tabler is only installed on the install command, that means the theme assets never got internalized. No bueno. Perhaps we should run “php artisan basset:internalize” as part of the v6 installation command… right before we show all the final output?

Hmm... now that we're running basset:install and BASSET_DEV_MODE is true by default... do we really need to run php artisan basset:internalize on local?! I guess we should still do that, for zip files etc? 🤷♂ What do you think @promatik ?
I guess what we want is a pleasant first experience loading Basset pages. Are most pages fast right now, because we're using BASSET_DEV_MODE? If so... perhaps it's a better experience to NOT internalize because that takes quite a bit of time and it makes the installation process longer.

Also, can we remove zips at least from core ?
We can use 5 or 6, 100 @basset() directives to load the needed files, but this tinymce zip is killing me.

Also, can we remove zips at least from core ?
We can use 5 or 6, 100 https://github.com/basset() directives to load the needed files, but this tinymce zip is killing me.

I don't think this is regarding the installation - please open a separate issue for this.

I'm reasonably happy with how things are right now. We've gone from:
composer require backpack/crud:"v6.x-dev"
php artisan storage:link
php artisan backpack:install
php artisan basset:internalize

to
composer require backpack/crud:"v6.x-dev"
php artisan backpack:install

Which I think is the best we can do, really. So I'm going to close this issue.


Allow RTA in Uniform without BufferBlock in SPV1.4+

My understanding on the BufferBlock vs Block deprecation is a bit fuzzy. But if Block hasn't replaced BufferBlock, seems like RTA cannot be used in a uniform anymore. So seems like Block has replaced it, hence this validation fix to allow the alternative decoration in SPV1.4+
Fixes #5628

Uniform with BufferBlock == StorageBuffer with Block. So in 1.4 you use StorageBuffer instead of Uniform. This is intentional. The validation change in this PR instead allows runtime-sized arrays in UBOs in 1.4 or later and is not correct. The goal of StorageBuffer was to disambiguate SSBO from UBO. 1.3 made StorageBuffer core so anything targeting 1.3 could use that instead of Uniform (with BufferBlock). Then 1.4 removed BufferBlock since SPIR-V waits a version (at least) to remove deprecations.
The Vulkan VU explains this reasonably clearly:

VUID-StandaloneSpirv-OpTypeRuntimeArray-04680
OpTypeRuntimeArray must only be used for:

the last member of a Block-decorated OpTypeStruct in StorageBuffer or PhysicalStorageBuffer storage Storage Class
BufferBlock-decorated OpTypeStruct in the Uniform storage Storage Class
the outermost dimension of an arrayed variable in the StorageBuffer, Uniform, or UniformConstant storage Storage Class

Uniform with BufferBlock == StorageBuffer with Block

Ahh, thanks! That's the part I was missing to understand.
Thanks! Closing the PR and the issue.


Method dispatching based on this polymorphism

TypeScript Version:  2.7.2 or 2.8 dev
Code
type ObjectLiteral = object & {
    reduceRight?: 'nope';
}

interface Dispatcher<T> {
    at(this: Dispatcher<ObjectLiteral>): string
    at<A>(this: Dispatcher<A[]>): Date
}

const objDispatcher = {} as any as Dispatcher<{}>
// That's fine we got a string back
objDispatcher.at().toLowerCase()

const arrDispatcher = {} as any as Dispatcher<number[]>
// The correct overload should have picked the Array form and returned a Date, but it did not: This does not compile
arrDispatcher.at().getTime()

Note that it used to work with TS 2.6.2. In the more recent versions, it simply always choose the first method signature.

Good catch, but in my real code I had a T somewhere in the interface to simulate a nominal type. Looks like this example is too simple; let me get back to you :)


Shahid/keydb

Description
[Please describe what this change achieves]
Issues Resolved
[List any existing issues this PR resolves, or any Discourse or
StackOverflow discussions that are relevant]
Check List

[ ] New functionality includes tests
[ ] All buildkite tests pass
[ ] Full omnibus build and tests in buildkite pass
[ ] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/main/CONTRIBUTING.md#developer-certification-of-origin-dco
[ ] PR title is a worthy inclusion in the CHANGELOG

https://buildkite.com/chef/chef-chef-server-main-omnibus-adhoc/builds/6418#019090a4-6fd1-477d-b4b2-a59d0aacd073

Keydb working ubuntu build - https://buildkite.com/chef/chef-chef-server-main-omnibus-adhoc/builds/6477


Scan all release pages

Symptom: the release is not consolidated when adding "old" releases, e.g. v1.21.3.
This patch ensures we scan all release pages, so the result is more accurate and avoids missing releases.
This also adds a way to avoid rate limiting when testing locally.

The relevant "CI run" on Netlify: https://app.netlify.com/sites/archive-envoy/deploys/652f56a6af8a0800081dc2c1.

Updated here: https://app.netlify.com/sites/archive-envoy/deploys/652f577980599b0008c213a5

Preview: https://deploy-preview-49--archive-envoy.netlify.app/


Improve handling nosec for multi-line strings

This commit improves handling nosecs
in multi-line strings, like:
1. nosec_not_working = f"""
2.     SELECT * FROM {table}
3. """  # nosec

Before this change, bandit was checking if there is
a nosec in line 1. Now, in the case of ast Constants
it searches for nosec in the last line of the expression.
This commit also moves detecting nosec without test number
to test phase from "pre-visit" phase.
It may increase the time of performing checks but avoids
counting the same nosec mark multiple times.
"pre-visit" phase is run separately for each part of multi-line
string split by FormattedValue items. Thus for the above example,
it would be run twice, the first time for "\n    SELECT * FROM "
and the second time for "\n" making the nosec being counted twice.
Resolves: #880

So I think using the last line of linerange will fail for Python 3.7. Currently Bandit incorrectly reports the last line number for Py37. See issue #820

Thank you for taking a look at my changes.
I'm not sure if I understand. Do you mean that my changes are not going to work in Python 3.7?
get_nosec function returns context['lineno'] for strings in Python 3.7. Why? Because in the case of Python 3.7 strings are parsed to ast.Str. In the case of Python 3.10 they are parsed to ast.Constant. It looks like ast.Constant is used from 3.8 according to https://docs.python.org/3/library/ast.html:

Changed in version 3.8: Class ast.Constant is now used for all constants.

I did the following test:
file: string_examples.py
a = "string 1"
b = f"f-string {a}"
c = """multi-line
string
1"""
d = f"""multi-line
f-string
{a}"""

file: ast_example.py
import ast

with open('string_examples.py', 'r') as f:
    ast_tree = ast.parse(f.read())

    for node in ast_tree.body:
        print(ast.dump(node))

And the output is:

python 3.7:

Assign(targets=[Name(id='a', ctx=Store())], value=Str(s='string 1'))
Assign(targets=[Name(id='b', ctx=Store())], value=JoinedStr(values=[Str(s='f-string '), FormattedValue(value=Name(id='a', ctx=Load()), conversion=-1, format_spec=None)]))
Assign(targets=[Name(id='c', ctx=Store())], value=Str(s='multi-line\nstring\n1'))
Assign(targets=[Name(id='d', ctx=Store())], value=JoinedStr(values=[Str(s='multi-line\nf-string\n'), FormattedValue(value=Name(id='a', ctx=Load()), conversion=-1, format_spec=None)]))

python 3.8:

Assign(targets=[Name(id='a', ctx=Store())], value=Constant(value='string 1', kind=None), type_comment=None)
Assign(targets=[Name(id='b', ctx=Store())], value=JoinedStr(values=[Constant(value='f-string ', kind=None), FormattedValue(value=Name(id='a', ctx=Load()), conversion=-1, format_spec=None)]), type_comment=None)
Assign(targets=[Name(id='c', ctx=Store())], value=Constant(value='multi-line\nstring\n1', kind=None), type_comment=None)
Assign(targets=[Name(id='d', ctx=Store())], value=JoinedStr(values=[Constant(value='multi-line\nf-string\n', kind=None), FormattedValue(value=Name(id='a', ctx=Load()), conversion=-1, format_spec=None)]), type_comment=None)

python 3.10:

Assign(targets=[Name(id='a', ctx=Store())], value=Constant(value='string 1'))
Assign(targets=[Name(id='b', ctx=Store())], value=JoinedStr(values=[Constant(value='f-string '), FormattedValue(value=Name(id='a', ctx=Load()), conversion=-1)]))
Assign(targets=[Name(id='c', ctx=Store())], value=Constant(value='multi-line\nstring\n1'))
Assign(targets=[Name(id='d', ctx=Store())], value=JoinedStr(values=[Constant(value='multi-line\nf-string\n'), FormattedValue(value=Name(id='a', ctx=Load()), conversion=-1)]))

Thank you for working on this. This also fixes #658 reported in December 2020.

Hi @ericwb , would you find a while to take a look at this pull request? If you think it should be fixed in another way, do not hesitate to say so. I'm willing to spend some more time on this if needed.

Hello guys, can we expect this PR to be merged some time soon?

@sigmavirus24 Thank you!

Not sure but this change appears to have broken our Python 3.7 runs. We had tests getting skipped and now none of them are.  Still investigating root cause.

@JRemitz Please let me know if you have examples that should be skipped and are not.

Definitely and I think I'm eating my words... we had a reduction in "skipped" tests, but the new ones were not previously skipped, they were two of the new rules that were added.  I am able to correlate those, I just need to dig up why the skipped tests count dropped.  I'll let you know if that has any relationship to this change. Apologies for the noise!


Getter types cannot be refined from nullable into non-nullable during inheritance

class A {
  get foo(): ?Object {
    return null;
  }
};

type BProps = { x: number; y: number; };
class B extends A {
  get foo(): BProps { // Flow error
    return {x: 1, y: 2};
  }
};

In this example Flow does not allow to refine the return type of .foo from ?Object to BProps. The regular (non-getter) methods work fine in this case.

This works in 0.34


Scale embeddings for integrated analyses of multi-modal data.

Codecov Report

Merging #15 (e7322de) into master (326e20e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #15   +/-   ##
=======================================
  Coverage   97.88%   97.88%
=======================================
  Files          59       59
  Lines        3789     3789
  Branches       63       63
=======================================
  Hits         3709     3709
  Misses         43       43
  Partials       37       37

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 326e20e...e7322de. Read the comment docs.


Rename Animation Class

Flutter has it's own Animation class in Material Library which is very conflicting while using Flame's Animation class.
IDE doesn't suggest importing the Flame's Animation class but instead takes Flutter's class as Default, even after importing, the IDE still throws an error that problems will occur while using classes with the same name.

There is indeed a workaround to use as to avoid this.
import 'package:flame/animation.dart' as animation;

...
//use this for Animation class of Flame
animation.Animation;
...

However, we should change the name of the class to make it simpler for Developers.

I'd love to work on this issue @luanpotter @renancaraujo :)

This discussion has been raised already and we don't see the need to rename this.
Yes there has that name clash, but this is not the only one that can clash and since the Flutter framework has a lot of classes and features, it is unlikely that we can prevent all the name clashes.
Using the as on import is not a workaround IMO, it is supposed to be used exactly on situations like this.
And this should only happens when you need to use the animation from flame, on the same file that you are using flutter widgets, which is most likely to only happen on small projects that are not organised with components and entities.
So I don't think we should do this rename, @luanpotter @renancaraujo @spydon, what are your thoughts?

@erickzanardo I guess that kind of makes sense, but since Flame Components are very independent, people who are new to it and learning it may find it frustrating. I myself was just trying to play around with Flame and this happened, I couldn't figure out what the problem was because the Animation class I used didn't show any error at all, rather just told me that there was no such message for the class. I'm sure new developers will have a tough time with this.
Since we don't want to break the library for people who are using it right now, we can create a duplicate of the Animation class for example, FlameAnimation while keeping the original Animation. When developers are using the Animation class, we can show a warning that they should use FlareAnimation instead and the old Animation class will be deprecated in 3-4 months. That way, we can prepare current developers and avoid hassles and confusion.
We can do this for other widgets as well.

@obitodarky even though I am not sure about the renaming, we did an extensive discussion with the tema ad @renancaraujo convinced us that SpriteAnimation is a better name, as it gives more context about what the animation is about.
We will do that for the v1 since this is a total breaking change.
Thanks for raising that discussion @obitodarky

@erickzanardo that's great SpriteAnimation seems a viable name. I'd really love to be involved in this issue, is there any way I can help?

@obitodarky, @renancaraujo is going to handle that issue, if you two can find a way to collaborate it would be awesome, if you are not yet, I suggest you join our discord, so you two could communicate easier.

Done on v1.0.0


Fix: clean up archived task

Details

Fix: clean up archived task
Fixed Issues

$ https://github.com/Expensify/App/issues/25483
PROPOSAL: https://github.com/Expensify/App/issues/25483#issuecomment-1683932826
Tests

Create a new task.
Type something under that task.
Click three dot menu and choose cancel.
Change the current mode to #focus.
Verify that canceled task is not visible in #focus mode.

[x] Verify that no errors appear in the JS console

Offline tests

Same as Tests.
QA Steps

Create a new task.
Type something under that task.
Click three dot menu and choose cancel.
Change the current mode to #focus.
Verify that canceled task is not visible in #focus mode.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/16502320/b243ece5-306b-4d61-b82a-04338a838f58

Mobile Web - Chrome

https://github.com/Expensify/App/assets/16502320/c39001d5-9b2e-49ff-87e3-d6ee3c90228c

Mobile Web - Safari
https://github.com/Expensify/App/assets/16502320/05ec0e96-c28c-4df7-a909-ea6a1c450651

Desktop

https://github.com/Expensify/App/assets/16502320/b243ece5-306b-4d61-b82a-04338a838f58

iOS

https://github.com/Expensify/App/assets/16502320/3e35f276-591a-4f93-8e78-28e8cda6dff4

Android

https://github.com/Expensify/App/assets/16502320/c39001d5-9b2e-49ff-87e3-d6ee3c90228c

Yup. It's happening in both on staging and this PR with staging server as well.
https://github.com/Expensify/App/assets/25876548/b42b44f8-65e4-4ac7-be72-02dc7a721905

@hungvu193 Can you give it a try?

@hungvu193 Looks like it is an expected behavior. Found a related issue: https://expensify.slack.com/archives/C049HHMV9SM/p1692786066068369
@thienlnam has mentioned in the thread that we are planning not to archive canceled task. In that case, this PR might not be required.
Let's wait for confirmation from @thienlnam and @Li357  before proceeding with the PR.


Menu item: mouse-down on text, mouse-release off the text, doesn't register click in Safari

In Safari, click down on the text of a menu item, drag your mouse slightly over so that it's off the text but still on the menu item and then release the mouse button. A click will not be registered.
It works in Firefox and Chrome but not in Safari. Tested on OS X 10.10 using SUI 2.0.0.

Does this behavior occur on other sites? Perhaps safari just registers clicks differently? I'm not sure there's much I can do in terms of code to solve this.

That might be the case and I just hadn't noticed it before. On this page, the same behavior is present for the Sign In and Register buttons:
http://en.lichess.org/login
So yeah, it may be unfixable. It's such a minor issue anyway, I probably shouldn't have even posted it.

Thanks anyways. I always appreciate the input.


.NET runing issue

Problem encountered on https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/edit
Operating System: windows
Provide details about the problem you're experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.

Can you give us more details of what the issue is?

fixed the problem


Enable disaster recovery backup of user storage on GCP, via Filestore

We use Google Filestore storage for home directories on GCP. It offers a backup management, but to automate scheduling of backups it seems that they have no managed solution besides allowing the use of a REST API to start backups. This is then in turn something that can be scheduled for example using their Cloud functions service and a Python script + GCP service account etc.
This issue is created for parity with the cloud equivalent AWS's EFS service and Azure's Files services.
Related

#623
#624

I think this was done, so closing as outdated.


 Sorry.

Hmm... same exact error?

@secrettriangle try just doing godep go build -o bin/envdb

@secrettriangle let me know if that worked. Going to close for now.

$ godep go build -o bin/envdb
go build _/home/dan/envdb: signal: killed
godep: go exit status 1

@secrettriangle yea, I think there is something wrong with your gopath. Trying to figure out why it's looking in _/home/dan


Enhancement request

Great job Zacharee !
Please add the the 7 digit tower ID.
thx, George

The tower ID is the last nine digits of the ECGI. Convert that to hexadecimal to get the 7 digit version.
The value is provided by the gateway as the full ECGI and not separately.


Refactored all instances of Person to Student

We can start building on this now that we have adjusted persons to students for our project!

Great job Simon! 👍🏻


Remove the Promoting BTP Manager to release channel section

Description
Changes proposed in this pull request:

Move the Promoting BTP Manager to release channel section from the workflows.md file to internal repository

Related issue(s)

/retest

/retest

/retest


Set adam magan commit

Deployed http://contributors.rubyonrails.org/contributors/adam-magan/commits.


HMS-2590 fix: align wizard page 2 and 3

Align the appearance for the pages 2 and 3, and add the VerifyRegistry
component to the page 2.
Please before review this PR, review the PR at: https://github.com/podengo-project/idmsvc-frontend/pull/4

Merged via https://github.com/podengo-project/idmsvc-frontend/pull/8.  Closing.


Fix single wildcard match uploads

We were initially going to just create a failing test for this and get to it in the refactor. HOWEVER, I discovered it was such a trivial fix that I just went right through with it. Best to have it in the June release, anyway.
If you're wondering, no, this change actually doesn't break plan files. It indirectly FIXES this functionality on past versions when resuming.
If you're curious as to what was even happening before, consider the following request:
PUT https://<account>.blob.core.windows.net/<container>/test/?timeout=901
The service was inferring our file name as test, and thus plopping it under test/test. With this change, the request then becomes
PUT https://<account>.blob.core.windows.net/<container>/test/<file>?timeout=901
Fixes the following issues: #410, #397

@zezha-msft Could you hit this up again? I've rewritten the relevant function to well, actually function.

Thanks Adele for the description of the change.  It helped me get my head around it.

Squashing and merging


OCTO-1502: cleanup of call chains

OCTO-1502
introducing make_delta() to hide statistics parameters in the call chains.

hmm, it fails with minor diffs in floating point constants in low-level bayesian functions that I didn't touch...

I would say that the difference is negligible, from my point of view you can simply update the unit test values.

I'm running tox-based tests locally in order to reproduce (just used runtests before)

Thank you Grisha. It looks good! See my comments above for a few small suggestions.

Changes Unknown when pulling f8f2a0026b67133592872503b8663744623e9583 on gbordyugov:introducing-make-delta into ** on zalando:dev**.

Changes Unknown when pulling f8f2a0026b67133592872503b8663744623e9583 on gbordyugov:introducing-make-delta into ** on zalando:dev**.

Changes Unknown when pulling f8f2a0026b67133592872503b8663744623e9583 on gbordyugov:introducing-make-delta into ** on zalando:dev**.


Use langDir without lazy loading

What problem does this feature solve?
It's nice to use locales separated to files for better code organization, but when you need to bundle them, you lose this feature
What does the proposed changes look like?
If langDir set - use separated files
If lazy set - use lazy-loading

This feature request is available on Nuxt community (#c289)

Any movements?

We need something like this as it can solve fallback issue as well. Now I have problem that our nl.js is subset of en.js, but with lazy loading this does not work...


[Ignore] Validating IT test failure - Forked version of a green commit from last week

Created from commit 9344e9ae which was committed to main last week and builds were green with this commit. So testing that again to see it is a worker code issue or infra issue.

We figured out this was related to a host change...


bump to version 0.2.1

New release now has bootstrapped confidence intervals around the best-fit lines

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

We haven't agreed on a way to do rcs yet. Please see this issue ( https://github.com/conda-forge/conda-forge.github.io/issues/147 ) for the discussion.

I'm just using RC tags while i hammer out the tests on the different platforms. Once I straighten that out, it'll be v0.2.1 and I'll force push a rebase for a proper new release.
--
Sorry if this was unintelligible. I'm on my phone.
On Sun, Jul 17, 2016 at 4:32 PM -0700, "jakirkham"<EMAIL_ADDRESS>wrote:
We haven't agreed on a way to do rcs yet. Please see this issue ( conda-forge/conda-forge.github.io#147 ) for the discussion.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

SGTM