[FEATURE] - delay for auto tunnel

Is your feature request related to a problem? Please describe.
Sometimes i loose wifi connection for 1 seconds. Then auto tunnel is triggered an start the vpn connection, but it doesn't close it after reconnect
Describe the solution you'd like
a delay for autotunnel would be perfect for this. E.g. you can set a time in seconds after this, condition for autotunnel will be checked and if it's true start the auto tunnel

Hello! What version is this happening on? It should automatically reconnect even if there is a rapid network change.

@zaneschepke also for me the issue is back.
We discussed this in a previous issue/version that when I change networks rapidly (same SSID but could shortly fall Back to LTE) there should be:

Delay of few seconds before switching
Recheck in an interval

I think you have implemented the first workaround.
Since the update to 3.6.3, it's not working anymore.
I am on my whitelisted Wifi SSID and since the update (few days ago) the tunnel was two times on.
Is the delay present in current versions?
Any chance to implement rechecks in an interval?
Thx

Here is the old closed issue: https://github.com/zaneschepke/wgtunnel/issues/303

Hey @popy2k14! Yeah, I remember these. Thanks for the additional information and feedback. The thing is both of these solutions are work arounds and don't address the core issue of why things are getting out of sync in the first place. In 3.6.3/3.6.2 had I believed I found and fixed the core issue of these sync problems so I removed these delays/rechecks as I thought they would no longer be necessary.
As I can see you are also reporting that these issues are still present, I'll add back some of these measures to make it more reliable again.

@zaneschepke yeah, issue is also back for me.
It seems the workaround is indeed needed in some situations. It worked flawlessly with the workaround of #303 up until 3.6.X.
Nice to hear that you will add back these workarounds.
If you need a tester, I am here.

Hello! What version is this happening on? It should automatically reconnect even if there is a rapid network change.
v3.6.3

As I can see you are also reporting that these issues are still present, I'll add back some of these measures to make it more reliable again.
Would be great if you could make this configurable, because I would like to start the vpn connection only after I am no longer in the wifi for a certain time

@Scrounger @zaneschepke
I am also on 3.6.3 and the issue happens on this version (i think current play store version).
@zaneschepke
We also discussed a configurable time back than on #303.
I think you decided against an setting to keep the app simple (and the fixed delay value worked also like charm).
I also think a configurable delay in seconds (which defaults and has a minimum of 1 second) would be great.
Please correct me if the default delay was higher in older versions.
The benefit of an configurable delay would be, that the user can increase it if there are switching issues.
As you know, there are so much android manufacturer out there which are also touching the AOSP network switching code (and want to make it better 🤣).
And sure like @Scrounger which want's an higher delay for his use cases.
How do you plan to solve the issue (fixed delay or configurable)?

In the latest nightly build I've added something called a debounce which will delay when there are rapid changes and keep delaying while there are rapid changes then emit the latest value, otherwise is wont delay. I've added one for network events and one for general auto tunnel state. Would one of you be able to try it out and see if it improves things? I think this is a more robust solution than a standard delay and should hopefully help.

@zaneschepke Sadly, Auto tunneling was stucked and the tunnel was always connected, regardless if my devices was connected to an white listed Wifi or not. Also switching auto tunneling on/off did not help. Just when I disabled the tunnel in the app manually the auto tunneling worked again.
Maybe I had accidentally activated the tunnel manually and overridden auto tunneling. Is this a feature?
I have activated local logging after the issue happened, where is the log file located?

@zaneschepke Sadly, Auto tunneling was stucked and the tunnel was always connected, regardless if my devices was connected to an white listed Wifi or not. Also switching auto tunneling on/off did not help. Just when I disabled the tunnel in the app manually the auto tunneling worked again.
Maybe I had accidentally activated the tunnel manually and overridden auto tunneling. Is this a feature?
I have activated local logging after the issue happened, where is the log file located?

Yikes, that doesn't sound good. :( Thanks again for testing. Did it at least work for a while? Did it become stuck after working for a period of time?
When you enable local logging there will be a logging screen you can navigate to from the support screen by clicking "Read the logs" . On that screen, you can view and copy individual log message or share out the logs.

Yeah, i think it worked a day without an hickup.
Sorry totally oversight the logging view function of the app.
So here is the log:
wg_tunnel_logs-1734777104.zip
The issue was arround i posted the first post today.
My timezone is Vienna (GMT+1).

That was not the case, tunnel stayed connected.
After disabling the tunnel in the app (with the switch) it was down and working when i toggled LTE & white listed wifi.

I saw this behavior as well. I just added some changes to the latest nightly that I think will fix these issues if you could give that a try! Thanks again for the testing!

Thx a lot for your work and efforts.
Installed it and report back in a few days.

Saw that you did a full release, are those fixes included?

Nice, thx.
Already running the new release.
Will report back here.

Merry Christmas!!!!
After some runtime where it worked flawless, today it happend again.
I was in my appartment and roamed between two AP's (with same SSID),
VPN tunnel is stucked in ON state.
Sadly after switching to the release version two days ago,
i did not swichted on logging, so log is useless (have looked at it, it's basically empty).
The issue is curently present, any idea's what i should do so we could analyse mhy the issue was triggered?
Sure, when i switch the tunnel off it will work again, but maybe we could not analyse much then...
Just let me know.
But now -> Merry Christmas! :-)

I haven't tried this migration between APs of the same SSID name before. I'll give it a shot and see if I can replicate.

@zaneschepke thx a lot for trying to replicate. Up until now the issue has not occured again.
I think the debounce time is a factor here.

Gotcha. Perhaps I just need to bump the time on it up from one second to two or three.

Maybe that would help 🙂

@zaneschepke
i tested the v3.6.5. It has definitely gotten better, but the problem is not yet completely gone when roaming between AP's.
Can you set the time yourself somewhere, I haven't found a setting for it?
If not, please make it configurable.


Snapshot update (beta.15 compatibility)

The change to passing snapshots to serializers instead of records has interesting implications for model fragments. At their core, fragments are simply embedded JSON attributes, so from the perspective of a snapshot, they should be considered attributes and not relationships. The hasOneFragment and hasManyFragments properties are already marked as attributes, but when creating a new snapshot, the fragment model/array instance is returned when calling snapshot#attr – not exactly a snapshot of the attributes.
Therefore fragments need to be serialized in the snapshot before DS.Model#serialize is invoked, instead of afterwards when transforms are applied to attributes. This unfortunately means relying on even more private APIs, in this case DS.Model#_createSnapshot (since the Snapshot constructor is not easy to override).
@wecc I don't know how familiar you are with this project, but if you could look over where I'm hooking into snapshots, I'd love to get your feedback!

For reference: emberjs/data#2623

Hm, I am not sure you really need to do this, but seems hard to think about.  Do you have time tomorrow for a quick chat?

Just creating a snapshot should be fully backwards compatible though

Yes, cherry picking the _createSnapshot method from DS.Model is enough to get all tests passing, which is great.
I'm mainly trying to keep model fragments inline with the idea behind snapshots (although perhaps I've misinterpreted?). To me, that means that if a snapshot instance hangs around, attributes on the snapshot – including fragments – don't change. Although the more I think about it, the more it seems like maybe calling snapshot.attr('fragmentProperty') should return a snapshot instance(s), and not a pre-serialized fragment. Will think on this.
I'm available 9-5 pacific time, hit me up on IRC.

Thinking about this more, I realize that serializing the fragment in the snapshot can result in confusion when fragments are accessed in the serializer, since attribute names can be munged by the serializer. I think the right approach is for snapshot.attr('someFragment') to return a snapshot of the fragment, or an array of snapshots.
I've rebased this PR and updated the tmp-dist branch.

@slindberg This gets a :+1: from me. Having snapshot.attr('someFragment') return a snapshot not only feels consistent, but seems better in the way of future proofing. It also means that my custom serializer doesn't have to support two code paths (snapshot and fragmentRecords).
The tmp-dist branch seems to work great in our app w/ ember-data-1.0.0-beta.15. All tests pass. Thanks a lot!

@workmanw awesome, thanks for testing with your app, super appreciate it. This is working for my app too, so I'm going to merge this in today or tomorrow and create a release unless @igorT or @wecc have any objections.

I'm testing the upgrade to ED 1.0-0-beta.15 on my app, so I'll confirm this PR locally and update shortly.

This PR does not work for me. I get the following error when trying to save the model:
'undefined' is not a function (evaluating 'record._createSnapshot()') (/Users/blimmer/code/Ibotta-Web/public-test/javascripts/vendor.js:71931)

The tmp-dist branch, on the other hand, works great!

Thanks @blimmer :+1:
I'll try to get this out sometime this afternoon.


Update test script to be more inclusive

Tests should now run all .spec.js files that are not in the node_modules folder.

Coverage remained the same at 98.571% when pulling 991996143a220578f17fc50bc8fcc375167f339a on kwelch:test-pattern-update into cf55a5f6db3f5bc2626327c4120df330c6be37c1 on coryhouse:master.

Interesting. I'd never envisioned tests outside of src. What's the use case?

It came up from an odd scenario at our office, and I thought it may be useful. We had a different folder structure and there was a point of nesting that tests were inconsistency discovered.
Our case was due to us not having out npm setup yet. We moved things some reusable code to a modules folder(sibling to src). Intent was cleaner distinction of the separation of application specific vs application agnostic. With the plan that it would be deleted as we moved the items into their own proper packages.

Sorry I let this languish. Forgot to respond! Thanks Kyle!

No worries. 👍
On Sun, Oct 30, 2016, 8:02 AM Cory House<EMAIL_ADDRESS>wrote:

Sorry I let this languish. Forgot to respond! Thanks Kyle!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/coryhouse/react-slingshot/pull/267#issuecomment-257149718,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPE3AHofbtvyAfxgE77NP34JZne0JCRks5q5JVNgaJpZM4KLNQ-
.


fix syslog parser data race problem

fixed #31

can see the data race log in https://github.com/open-telemetry/opentelemetry-log-collection/pull/32/checks?check_run_id=2005612517#step:5:342


stack ghci and the ghc-8.0 branch

In contrast to the master branch, the ghc-8.0 branch compiles fine for me. However using stack ghci does not:
<interactive>:1:6: error: Not in scope: ‘>>’
<interactive>:1:70: error: Not in scope: ‘>>’
<interactive>:1:135: error: Not in scope: ‘return’

I am not exactly sure why (is there some fundamental difference in how the REPL works with extensions?)... I guess a mixture of the non-implicit prelude and RebindableSyntax is the culprit, but I am way to new to haskell to figure out on my own.
Reproduction steps:
git clone https://github.com/mikeizbicki/subhask
cd subhask
git checkout ghc-8.0
stack build
stack ghci

If you turn off RebindableSyntax, this should work.
On Fri, Dec 16, 2016 at 10:01 AM, Paul Hilbert<EMAIL_ADDRESS>wrote:

In contrast to the master branch, the ghc-8.0 branch compiles fine for me.
However using stack ghci does not:
:1:6: error: Not in scope: ‘>>’
:1:70: error: Not in scope: ‘>>’
:1:135: error: Not in scope: ‘return’
I am not exactly sure why (is there some fundamental difference in how the
REPL works with extensions?)... I guess a mixture of the non-implicit
prelude and RebindableSyntax is the culprit, but I am way to new to haskell
to figure out on my own.
Reproduction steps:
git clone https://github.com/mikeizbicki/subhask
cd subhask
git checkout ghc-8.0
stack build
stack ghci
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mikeizbicki/subhask/issues/65, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABAP1k3a8YIPVNlTJL269LM9zCm5RT1xks5rItIGgaJpZM4LPclg
.

Well that gives me dozens of compile errors given that subhask does not compile without it...
(I tried removing it from the default-extensions in the cabal file or alternatively using
stack ghci --ghci-options XNoRebindableSyntax

which also triggers a rebuild - and no, --no-build won't help).

I'm having the same problem. Build and run works but not ghci.

By turn off RebindableSyntax, I meant modify your ~/.ghc/ghci.conf file so that :set -XRebindableSyntax is not included.  This would only work for non-stack users.
I personally don't use stack, but it looks like stack is starting up ghci with whatever flags the project uses.  A quick fix would be to just run import Control.Monad first thing when you start ghci.  This will import the required functions from base.  An alternative would be to import SubHask.Monad to load the symbols from subhask.  These won't be compatible with any monads defined in base, however.  There is some template haskell code that will automatically define these, but I've tried it from ghci.

I switched away from stack for further tests so it kind of works for me by disabling RebindableSyntax. I didn't do any more complex tests since I already switched away from subhask, but from a quick check I could tell that modifying the .ghci.conf with NoRebindableSyntax/import Control.Monad did indeed seem to at least have the stack ghci start (stack does use the local .ghci.conf in PWD). Whatever the solution the initial source of the problem seems to be the assertion of stack that ghc and ghci extension parameters always agree which imo makes this a problem of stack, not subhask (so feel free to close this issue).


Crash when reloading message history

Checklist

[X] I'm reporting a problem with Chatterino
[X] I've verified that I'm running the most recent nightly build or stable release
[X] I've looked for my problem on the wiki
[X] I've searched the issues and pull requests for similar looking reports

Describe your issue
Steps to Reproduce

Reconnect due to either an account switch or Twitch deploy
crash

stacktrace:
https://paste.ivr.fi/wigozyxoge.rs
Points to https://github.com/Chatterino/chatterino2/blob/8ea5b49/src/common/Channel.cpp#L262 corrected by dnsge
My assumption is that it's just not liking how many channels need to be reconnected to at once, as I was unable to replicate the issue when just using -c pajlada or a short list of channels. see below comment
(note): This crash happened sometime after the first set of changes, as I had a user testing the PR as of 4a7d1cc and they had no problems or crashes, but switching to the recent nightly causes them to crash on reconnects as well.
PR: Chatterino/chatterino2/pull/3878
Screenshots

OS and Chatterino Version
Chatterino Nightly 2.3.5 (commit 8ea5b49c modified) built on 2022-08-14 with Qt 5.15.2, Windows SDK, MSVC 193231332 Running on Windows 10 Version 2009, kernel: 10.0.19043

Looking at the stack trace, the critical issue seems to occur here:
https://github.com/Chatterino/chatterino2/blob/8ea5b49c52ed726b6a1f258a94ea5d1fb1a38ae1/src/common/Channel.cpp#L262
My guess is that the LimitedSnapshotQueue is empty, and this leads to a bad access. (Is the part of the stacktrace stating unsigned int64 index = 0xffffffff`ffffffff actually giving the index being accessed? If so, that supports this hypothesis).
I'm pretty sure I had looked at this as a potential issue but forgot about it (?) before.
We can probably just add a
if (snapshot.size() == 0)
{
    return;
}

Actually ignore the fix I suggested, we would actually need to do something like
if (snapshot.size() == 0 && !messages.empty())
{
	this->messages_.pushFront(messages);
    this->filledInMessages.invoke(messages);
    return;
}

to actually still see the newly added recent messages

I asked the other issue holder to close their tabs with no message history (as I have too many) and they confirm no longer crashing.


chore: keep the last round task outputs

Related issue
# followed by the number of the issue
Summary
Notes
Please check if the PR fulfills these requirements

[ ] If the feature has an impact on the user experience, the changelog has been updated
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] The commit message follows the conventional commit specification

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --tests substrafl

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --tests substrafl --mode standalone

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --tests substrafl --mode standalone

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --tests substrafl --mode standalone

End to end tests: :hourglass_flowing_sand: STARTING

e2e tests passed with clean models to True and download the artifact of the lasts round.


Question about timeline for next release

I am curious about when you might release the next version of the SDK.
We recently moved our Java based Lambdas to graalvm, but this caused us to loose subsegments due to the missing _X_AMZN_TRACE_ID information. Your next release should fix this issue for us, but we are looking to do some optimisation work within the next month where this information is critical.
Can you share some indication of if you are planning to release within the next two weeks? Then I will know if I can wait for your vended version if I need to build the SDK from source and include that in our build.

Hi @Morras,
Unfortunately we cannot provide ETAs or estimates for our release. I'm sorry for the inconvenience, but I encourage you to "watch" the repo to be notified when it happens.


Added makedumpfile test cases

It run makedump file on colleted vmcore and verify output
Signed-off-by: Praveen K Pandey<EMAIL_ADDRESS>

As part of optest I think we have a dump test can't we cover makedump also as part of the same test. instead of a new test file.

@harihare yes good idea to move to a part of an existing Test case, did and addressed the review comment, please have a look

@abdhaleegit review please


Automate Mentorship Program Status

For the mentorship program option we have hard-coded statements which need to be updated manually once the program becomes live.
Approaches :

Would like to automate this update using some API provided by these organizations ( not sure if orgs have something like this )
Have a simple environment variable that could be changed manually in order to update this status

Below attached is the file I am pointing to
Link to the file

@meetagrawal09  that’s a great idea, assigning this to you now


drivers: stm32: SPI: cannot send several buffers if frame size=16bits

The stm32 SPI driver does not work if one tries to send several buffers with a frame size of 16 bits.
If the SPI's transaction's frame size is set to 16 bits and more than one buffer wants to be sent, the data sent is wrong. This is caused by a function dividing the length of the 'next buffer' by a parameter dfs, which should not happen.
More details in #57247
The following proposal assumes that the struct spi_buf's len field is expected to be units of frame size, not bytes. This, as far as I understand, matches the logic of spi_context_update_tx.
After removing the division by dfs, the result is:

Fixes #57247
Closes #57247

@erwango @FRASTM @gautierg-st @ABOSTM could you please take a look?


Contraption on Rope Pulley force-pulls player down, even in Spectator.

Describe the Bug
Contraption using a Rope Pulley and Mechanical Drills as a quasi-quarry. If I stand on the contraption as it drills it's way down, it will pull me to it when it goes down another layer. This causes the player to not be able to ascend in water and they will drown. Oddly enough, this also happens in Spectator, though the player must stand on the contraption first. The pull breaks if you are able to get a certain amount of blocks above it, or if you can move away from it horizontally. This may also be accomplished by just jumping before the drills go down. You'll notice the contraption pull you down.
Reproduction Steps

Rope Pulley contraption sending drills down.
Stand on the drills / chests as it goes down.
If in water, try to swim up. If not in water, switch to spectator and try to fly up.
...

Expected Result
I wouldn't expect to be drowned by my own creation. :D
Screenshots and Videos
No response
Crash Report or Log
No response
Operating System
Win 10
Mod Version
0.5.1c
Minecraft Version
1.19.2
Other Mods
Modpack is StaTech Industry
Additional Context
No response

Occurs on forge aswell


Fresh install wont start. Failed at the discord_channels script.

For some reason, it fails right here. Any ideas?

Have you configured your environment file (.env) properly? For some reason the promise rejection occurs at the top of the log for some reason.
If you have, could you attach the log file made by the bot itself? It will be called sgs_bot.log in the directory the bot is in.

Sure:

There are no debug messages though. All just info "Registered Command" entries.
I do get this:

If you attach log files in code tags it's much easier for us to read. Heres a good guide if you're unsure what to do: https://guides.github.com/features/mastering-markdown/

Screenshots here really aren't useful.
Can you run node index.js and copy the entire output into something like Gist or Pastebin

Yea sorry. Working remotely and the copy paste functionality of my KVM through VNC is not great. I'll get a paste to you.

root@SLRPLY:~/sgs_bot#node index.js
2017-10-19T15:54:27.380Z - debug: Loading commands from /root/sgs_bot/command_handlers
2017-10-19T15:54:27.400Z - info: Registered command blacklist_game from file blacklist_game.js
2017-10-19T15:54:27.401Z - info: Registered command create_command from file create_command.js
2017-10-19T15:54:27.402Z - info: Registered command create_role from file create_role.js
2017-10-19T15:54:27.402Z - info: Registered command debug from file debug.js
2017-10-19T15:54:27.403Z - info: Registered command delete_command from file delete_command.js
2017-10-19T15:54:27.403Z - info: Registered command delete_role from file delete_role.js
2017-10-19T15:54:27.403Z - info: Registered command edit_command from file edit_command.js
2017-10-19T15:54:27.404Z - info: Registered command flip from file flip.js
2017-10-19T15:54:27.422Z - info: Registered command game_graph from file game_graph.js
2017-10-19T15:54:27.422Z - info: Registered command game_stats from file game_stats.js
2017-10-19T15:54:27.423Z - info: Registered command join_role from file join_role.js
2017-10-19T15:54:27.423Z - info: Registered command leave_role from file leave_role.js
2017-10-19T15:54:27.423Z - info: Registered command list_commands from file list_commands.js
2017-10-19T15:54:27.424Z - info: Registered command list_roles from file list_roles.js
2017-10-19T15:54:27.424Z - info: Registered command ping from file ping.js
2017-10-19T15:54:27.424Z - info: Registered command purge from file purge.js
2017-10-19T15:54:27.424Z - info: Registered command roll from file roll.js
2017-10-19T15:54:27.425Z - info: Registered command self_stats from file self_stats.js
2017-10-19T15:54:27.425Z - info: Registered command user_stats from file user_stats.js
root@SLRPLY:~/sgs_bot#

I've just added a bunch of debug handlers in branch issue-14 here. Would you mind running the code from that branch and providing updated logs?

These issues were all my own fault. This being my first bot, there were a lot of backend steps I didnt understand regarding authing my bot with tokens etc.
Some updating to installation / pre-reqs can probably save first timers going forward :) Thanks for all the help!!!


Logic for the token is wrong

The use of token or basic auth was a conditional inside the TLS verify loop.
You can use TLS or skip the verification and use token or basic auth.
Just a tab issue. Put the token conditional outside the kubeInsecure check.
Also handled the case that we actually switch the boolean for skip TLS and forced it to replace true or false.

I tested this by building my own resourcifier image locally and it works fine.
I am finally able to deploy templates.

@jackgr

Thanks, @runseb!


Multi architecture support

What
Support bulding multi architecture docker image with docker buildx.
Build(e.x.)
docker buildx create --name mybuilder
docker buildx use mybuilder
IMAGE_PREFIX=onokatio2 IMAGE_TAG=0.6.0 make image-multiarch

https://hub.docker.com/repository/docker/onokatio2/topolvm/
Status
Architecture:

amd64
arm64
arm v7
powerpc 64

Depends
#215

Some changes are included to #215 so close this.

I'll reopen another PR for multi archtecture supporting.


Feature/ts tsup

this PR is for refactor original javascript version to typescript + tsup;
also contain test cases, but example cases not yet.

Have updated this pr from current diff

Some high-level note: we should I think remove jest and replace it by vitest, especially to get rid of babel as a dependency.

Currently I still use jest but get rid of babel by jest config setting preset: 'ts-jest/presets/default-esm', which could work fine as well.

all issues raised by @sublimator in previous batch have been resolved, thanks :)

On mobile now, but I think the throw branch also included resp.text()
On Tue, 14 May 2024, 6:56 pm Jamie Lee, @.***> wrote:

all issues raised by @sublimator https://github.com/sublimator in
previous batch have been resolved, thanks :)
—
Reply to this email directly, view it on GitHub
https://github.com/mistralai/client-js/pull/73#issuecomment-2110014418,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEAHG5C7E22J5BUAJ2CAIDZCH3W7AVCNFSM6AAAAABHMGW7YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQGAYTINBRHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

And yeah, prettier would rock!
Not sure if lint --fix still works now TS
On Tue, 14 May 2024, 7:00 pm Nicholas Dudfield, @.***> wrote:

On mobile now, but I think the throw branch also included resp.text()
On Tue, 14 May 2024, 6:56 pm Jamie Lee, @.***> wrote:

all issues raised by @sublimator https://github.com/sublimator in
previous batch have been resolved, thanks :)
—
Reply to this email directly, view it on GitHub
https://github.com/mistralai/client-js/pull/73#issuecomment-2110014418,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEAHG5C7E22J5BUAJ2CAIDZCH3W7AVCNFSM6AAAAABHMGW7YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQGAYTINBRHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Looking forward to this!

Looking forward to this! Lack of Commonjs support has prevented me from using this.

sure let me catch up the latest commit and merge into this pr
hope Mistral team could approve this pr

@fuegoio
Please kindly help check the updated version.
This version is also fetched up job and file features~

Thanks for opening this PR. We have deprecated this package in favor of mistralai/client-ts, which is the new official Mistral client, compatible with both TypeScript and JavaScript.
You can find all installation information here.
This change is effective starting with version 1.0.0 of the npm package.


Allow ember-source v4 as peer dependency

Closes #72.

@bertdeblock Thank you.
Released in v0.5.3.


Clean package metadata after running svelte2tsx

Remove package metadata like:

scripts, devDependencies in package.json
.gitignore

Closed by #21


Fix README link to travis-buddy-failure-template.md

File was just deleted in the bluzi-travis-buddy-test branch of the name-db repo: https://github.com/bluzi/name-db/commit/fd70c288cdf7c57b533f68da3393939efe048663

Travis tests have failed
Hey @rmzelle,
Please read the following log in order to understand the failure reason.
It'll be awesome if you fix what's wrong and commit the changes.
Node.js: 8
View build log

     npm test

><EMAIL_ADDRESS>test /home/travis/build/bluzi/travis-buddy
> mocha

  api
    POST /
17:19:20.481Z  INFO unknown : Pipe load payload finished
17:19:20.482Z  INFO unknown : (travis payload validation) Validating payload
17:19:20.483Z  INFO unknown : (travis payload validation) Pipe travis payload validation finished
17:19:20.483Z  INFO unknown : (travis payload validation) Pipe validate payload finished
17:19:20.483Z  INFO unknown : (get metadata) Metadata created
17:19:20.483Z  INFO unknown : (get metadata) Pipe get metadata finished
17:19:20.483Z  INFO unknown : (wait) No wait time
17:19:20.483Z  INFO unknown : (wait) Pipe wait finished
17:19:21.742Z  INFO unknown : (travis parser) bluzi/name-db #501: Pipe travis parser finished
17:19:21.742Z  INFO unknown : (travis parser) bluzi/name-db #501: Pipe parse payload finished
17:19:21.883Z  INFO unknown : (star repo) bluzi/name-db #501: Pipe star repo finished
17:19:22.027Z  INFO unknown : (fetch configuration) bluzi/name-db #501: Selected config
17:19:22.027Z  INFO unknown : (fetch configuration) bluzi/name-db #501: travis.yml
17:19:22.027Z  INFO unknown : (fetch configuration) bluzi/name-db #501: Pipe fetch configuration finished
17:19:22.028Z  INFO unknown : (search for a stop comment) bluzi/name-db #501: Pipe search for a stop comment finished
19:22.615Z  INFO unknown : (format message) bluzi/name-db #501: Pipe format message finished
17:19:22.615Z  INFO unknown : (format message) bluzi/name-db #501: Pipe format message finished
17:19:22.781Z ERROR unknown : 403 error making request POST https://api.github.com/repos/bluzi/name-db/issues/501/comments: "Forbidden"
      1) should return HTTP status 200 and ok message
    GET /status
      ✓ should be running and return HTTP status 200

  site
    GET /
      ✓ should return HTML and status 200
    GET /getting-started
      ✓ should return HTML and status 200
    GET /contact-us
      ✓ should return HTML and status 200
    GET /dashboard
      ✓ should return HTML and status 200

  TravisBuddy configuration
    ✓ should parse successfully (118ms)

  6 passing (2s)
  1 failing

  1) api
       POST /
         should return HTTP status 200 and ok message:
     Error: expected 201 "Created", got 500 "Internal Server Error"
      at Test._assertStatus (node_modules/supertest/lib/test.js:266:12)
      at Test._assertFunction (node_modules/supertest/lib/test.js:281:11)
      at Test.assert (node_modules/supertest/lib/test.js:171:18)
      at Server.assert (node_modules/supertest/lib/test.js:131:12)
      at emitCloseNT (net.js:1664:8)
      at _combinedTickCallback (internal/process/next_tick.js:136:11)
      at process._tickDomainCallback (internal/process/next_tick.js:219:9)

npm ERR! Test failed.  See above for more details.

     npm run lint

Done. Your build exited with 1.

TravisBuddy Request Identifier: 4f44a4f0-c667-11e8-a5a1-47c8df4b6166

Thanks!


Allow Google Analytics plugins to be specified in config

Allows specifying Google Analytics plugins in config.

Mind adding a test for this similar to this? https://github.com/poteto/ember-metrics/blob/master/tests/unit/metrics-adapters/google-analytics-test.js#L18-L27

Will do 👍


ENH: have scipy Wheel for pypy3.8-v7.3.9-win64

Is your feature request related to a problem? Please describe.
I don't have a scipy wheel for PyPy, unless I use the cgohlke one, but that requires the gigantic numpy+mkl wheel
Having an official wheel from scipy build for OpenBlas would make things 210Mo smaller (couting on wheel size)
Describe the solution you'd like.
official wheels from Scipy for PyPy 3.8 (and soon 3.9), on Windows
Describe alternatives you've considered.
cgohlke wheels are getting way too big with the MKL
Additional context (e.g. screenshots, GIFs)
No response

Hi @stonebig, thank you for reporting. We don't have plans at the moment to distribute again wheels for PyPy.
FYI, SciPy wheels are built on another repo and there is already an issue for that: https://github.com/MacPython/scipy-wheels/issues/87
I will close this one to keep a single discussion.


Use Hamcrest assertions instead of JUnit in integrations/cdi/jta-weld(#1749)

Part of #1749
I've already signed OCA. It's an automation problem.
Backport 2.x

/trigger


Build a simple Grafana Dashboard and visualize some metrics from k8s / app

Grabbing (parts of) this, at least for the services & in docker-compose env.

I'll take this one


docs: Move myself to approvers

Signed-off-by: Yuan Tang<EMAIL_ADDRESS>

@terrytangyuan helps a lot on OSS management, common code base and and MPI part. +1. Hold for other reviewers.
/lgtm
/hold

/lgtm

/hold cancel

/approve

Thank you all!


fix deprecated ops in pytorch 1.6

Hello! Does this change cause any problems? Is there any reason why its not merged yet?

any issues with the PR?


Release version 1.21.0

@kcw-grunt please review the last 3 commits. Thanks!

@kcw-grunt please review the last 3 commits. Thanks!

LGTM

FYI as you can see it here https://github.com/litecoin-foundation/loafwallet-android/pull/194/files#diff-d0403fc4549ad9420f95fc150aa2361e7ed0236677e7680bddb122685792f2f4R325
I just send the timestamp instead of a formatted date/time

LGTM

FYI as you can see it here https://github.com/litecoin-foundation/loafwallet-android/pull/194/files#diff-d0403fc4549ad9420f95fc150aa2361e7ed0236677e7680bddb122685792f2f4R325
I just send the timestamp instead of a formatted date/time

LGTM

FYI as you can see it here https://github.com/litecoin-foundation/loafwallet-android/pull/194/files#diff-d0403fc4549ad9420f95fc150aa2361e7ed0236677e7680bddb122685792f2f4R325
I just send the timestamp instead of a formatted date/time

Yep that's fine. I don't anticipate enough data for a few months and during that time we can come up with a platform agnostic data stream. Looks good.

LGTM

FYI as you can see it here https://github.com/litecoin-foundation/loafwallet-android/pull/194/files#diff-d0403fc4549ad9420f95fc150aa2361e7ed0236677e7680bddb122685792f2f4R325
I just send the timestamp instead of a formatted date/time

Yep that's fine. I don't anticipate enough data for a few months and during that time we can come up with a platform agnostic data stream. Looks good.


Add polars to nightly tests workflow

Codecov Report
Patch and project coverage have no change.

Comparison is base (8e90533) 100.00% compared to head (7aa8d2b) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #146   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           11        11
  Lines          670       670
  Branches       169       169
=========================================
  Hits           670       670

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[alpha.20] Word count disappears in smaller window

Issue Summary
If you make ghost editor window small enough the word counter will disappear.
Technical details:
Ghost Version: alpha.20
ghost-cli Version: 1.0.0-alpha.16
Node Version: v6.10.0
OS: Debian 3.16.39-1+deb8u1
Database: MariaDB 10.0.29 & SQLite3
Screenshot

Hey @PaszaVonPomiot, that's by design so that the word count does not overlap the editor content. Closing as a non-issue for now.


Cherry pick commits for v0.1.1 release

Description of the change: Cherry picked commits for v0.1.1 release
Motivation for the change: Important bug fixes

We should also change the version/version.go file to use version=v0.1.0+git. Since this is in between releases v0.1.0 and v0.1.1.


use drizzle-zod

Fixes #988
x-ref: https://github.com/t3-oss/create-t3-turbo/discussions/966

Hello @juliusmarminge,
I've tried to follow all your changes, and it seems to have resolved my issue with fetching schema data inside a client component. Awesome!
Additionally, you introduced the use of drizzle-zod and demonstrated its application in the post form. On my side, this has created a new issue. For the useForm:
const form = useForm({
  schema: createPostSchema, // Using it from the db package as in your PR
  defaultValues: {
    content: "",
    title: "",
  },
})

The fields now include a null type addition (which wasn't present before when using CreatePostSchema from @acme/validators):
title?: string | null | undefined;
content?: string | null | undefined;

This change is causing an error in VSCode for the input fields, as null is not allowed for the Input field component.
Note: Is there a specific reason you removed the "schema" folder? On my side, I didn't move any files from there; I simply added schema.ts at the root of src/ (as in your PR) and exported all the files from there like so:
src/schema.ts:
export * from "./schema/auth"
export * from "./schema/post"
export { mySqlTable } from "./schema/_table"

This setup seems to work well and maintains ease of reading and updating, as a single file table can quickly become overly lengthy.

Note: Is there a specific reason you removed the "schema" folder? On my side, I didn't move any files from there; I simply added schema.ts at the root of src/ (as in your PR) and exported all the files from there like so:

No reason, just preference. Splitting up in multiple files may be beneficial as your schema grows but it's a bit premature to do so when there's only 4 tables

Hello, I'm not sure if this is the best place to post this, but since we are updating the Drizzle setup in this PR, I think we should also adapt it to the latest update of AuthJs.
1. Enable foreign key constraints on PlanetScale:
Settings: check the box for foreign key constraints.
2. Adapt the Drizzle Schema:
export const users = mySqlTable("user", {
  ...
  emailVerified: timestamp("emailVerified", { mode: "date", fsp: 3 }), // <-- Remove the default value
  ...
});

export const accounts = mySqlTable("account", {
  ...
  access_token: varchar("access_token", { length: 255 }), // <-- Changed to varchar(255)
  ...
  id_token: varchar("id_token", { length: 2048 }), // <-- Changed to varchar(2048)
  ...
});

export const sessions = mySqlTable("session", {
  id: varchar("id", { length: 26 }).$defaultFn(() => ulid()).primaryKey(), // <-- Add an 'id' column (choose whichever method suits you for ID generation)
  sessionToken: varchar("sessionToken", { length: 255 }).notNull().unique(), // <-- Change 'primaryKey' to 'unique'
  userId: varchar("userId", { length: 255 }).notNull().references(() => users.id, { onDelete: "cascade" }), // Add the reference constraints
  ...
});

3. Adapt the authentication configuration in "packages/auth/src/config.ts":
import {
 // mySqlTable,
 accounts,
 sessions,
 users,
 verificationTokens,
} from "@acme/db/schema" // <-- Remove the import of mySqlTable and directly import the four necessary schemas

...
export const authConfig = {
 adapter: DrizzleAdapter(createDBClient(), {
   usersTable: users,
   accountsTable: accounts,
   sessionsTable: sessions,
   verificationTokensTable: verificationTokens,
 }), // <-- Replace 'mySqlTable' with the specific tables
 ....
};

I might have done something wrong; I think the Drizzle adapter isn't compatible with Edge. :'(  "issue with crypto"

I might have done something wrong; I think the Drizzle adapter isn't compatible with Edge. :'( "issue with crypto"

I'm not sure about your context, but when I read "Edge" and "crypto," I remembered this brilliant blog post: https://zenstack.dev/blog/adapt-to-edge#node-apis. Maybe it's something worth looking into.
TLDR: "crypto" is provided as a built-in on Edge, so there's no need to import the package in this environment.

I might have done something wrong; I think the Drizzle adapter isn't compatible with Edge. :'( "issue with crypto"

I'm not sure about your context, but when I read "Edge" and "crypto," I remembered this brilliant blog post: https://zenstack.dev/blog/adapt-to-edge#node-apis. Maybe it's something worth looking into.
TLDR: "crypto" is provided as a built-in on Edge, so there's no need to import the package in this environment.

Maybe, don't use Edge? Lately even Vercel is acknowledging we shouldn't place stuff like db calls in edge-location or even edge-runtime

I might have done something wrong; I think the Drizzle adapter isn't compatible with Edge. :'( "issue with crypto"

I'm not sure about your context, but when I read "Edge" and "crypto," I remembered this brilliant blog post: https://zenstack.dev/blog/adapt-to-edge#node-apis. Maybe it's something worth looking into.
TLDR: "crypto" is provided as a built-in on Edge, so there's no need to import the package in this environment.

Maybe, don't use Edge? Lately even Vercel is acknowledging we shouldn't place stuff like db calls in edge-location or even edge-runtime

lol drizzle should work on edge (that's one of their selling points). If you are doing any auth check in the middleware then you are automatically using the edge runtime.

There were a bunch of bugs/breaking stuff in drizzle adapter 1.0 so maybe if you used that then you'd have some issues.
1.0.1 should be out soon with fixes

I am just confirming that there are no more edge runtime issues with the latest drizzle-adapter for AuthJS.  🥳


Update Level 1 map to match Wikipedia animation.

The level visible on Wikipedia contains a storage space (VOID) already filled with a box (SUCCESS_BLOCK) => updated constants.js to initialize the board accordingly.
Then updated movePlayer function to check initial board state based on VOID and SUCCESS_BLOCK.
(No problem to delete this PR)

Neat!


feat: allow passing raw call data to sendUserOperation

Pull Request Checklist

[ ] Did you add new tests and confirm existing tests pass? (yarn test)
[ ] Did you update relevant docs? (docs are found in the site folder, see guidleines below)
[ ] Do your commits follow the Conventional Commits standard?
[ ] Does your PR title also follow the Conventional Commits standard?
[ ] If you have a breaking change, is it [correctly reflected in your commit message](https://www.conventionalcommits.org/en/v1.0.0/#examples? (e.g. feat!: breaking change)
[ ] Did you run lint (yarn lint:check) and fix any issues? (yarn lint:fix)
[ ] Is the base branch you're merging into development and not main?

PR-Codex overview
Focus of the PR:
This PR focuses on modifying the UserOperationCallData type to allow for an additional property Hex, and updating related code to accommodate this change.
Detailed summary:

Modified UserOperationCallData type to include an additional property Hex
Updated KernelUserOperationCallData type to exclude Hex
Updated KernelBatchUserOperationCallData type to exclude Hex
Updated BatchUserOperationCallData type to exclude Hex
Updated sendUserOperation.md guide to include Hex as a possible parameter type

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@denniswon docs are updated


Still working, when gamepad unplugged

Hi again :). I found another bug. In last versions, when I unplug physical gamepad, emulated gamepad (x360 controller) it still working and do some weird stuff, like left analog goes left up corner, so I can't use windows UI, like start menu etc.

Added to v3.23.


WIP: Add happy path for shutting down the daemon

This PR (work in progress) implements the changes proposed in #42.
Things remaining to be done/solved:

[x] pollSpotTermination continues to run after pollTerminationNotice has exited and the handler has started running (and vice versa). To solve this we'll need to supply a "sub" context that can be cancelled when either of the polling functions return, which then triggers the other to exit. In addition, we'll need to use buffered channels so that the reader (daemon.Start()) can stop reading and start executing the handler, without deadlocking the writer. I don't think this issue will cause any problems, but just for "correctness" it would be nice to fix it.
[ ] I think we need to decide on a logging strategy and perhaps implement it as part of the refactoring, or at least make a separate issue for it. Some things to consider:

log.Fatal(): In my opinion, fatal should only be used inside main.go when we want a non-zero exit code, or because continuing execution would result in a panic. Ideally, we wouldn't use Fatal at all, but in this case I think it's worth doing since we then get a log entry with the error in CloudWatch.
log.Error() and log.Warn(): Error should be reserved for err's that cannot be recovered from. E.g., we don't get a second try if we fail to delete the queue when shutting down. Whereas if we fail to query the ec2 metadata, we get to try again in 5 seconds.
log.Info() and log.Debug(): I'd like it if Info just gave enough info to verify that the control-flow has executed as expected. Whereas Debug would output more chatty stuff, like a log entry everytime it hits one of the endpoints.
I think we should always use WithError(err).
I think that instance ID should be attached to every log entry, to make it easier to filter/read multiple log streams at once (and still understand what happened to a particular instance).
I think most other pieces of information can just be logged once. E.g. if I'm wondering which SQS MessageID started the handler, I can just scroll up a few lines and see the log entry from when the message was received.
Related to the above, we should consider creating a logger in main.go, and passing a logrus.Entry (which is the output of log.WithField()) to the functions instead of using a global logger. This way we can e.g. logrus.SetField("instanceId", instanceID) in one place, and have it be a fixed field for all log entries.

[ ] Implement the Monitor structs from #44 on top of the changes in this PR. Could either be done in the branch, on top of the branch, or after merging.

Have a look and let me know what you think @lox 👐

If we managed to merge together the best parts of this PR and your #44, I think it would be best to implement any logging changes on top of that. Also, I think your monitor structs would make it easier to follow the code in daemon.Start() of this branch.

@lox - Still a work in progress, but I've added a Listener (much like your Monitors) and Handler interface, as well as Notice interface which gives a lot of flexibility but also makes the flow of the program a lot easier to reason about (in my opinion).
Some outstanding work:

Standardise the logging (when and where, what level and what fields etc).
Better named flag for spot listener (currently just --spot).
Use ec2metadata to get Instance ID as well.
Move main.go to cmd/main.go so that we can the rest of the code can live in a lifecycled library?
Don't export (lowercase) structs and methods that are not meant to be a part of a 'public' interface.
Perhaps add a init() function to main.go to set up logging and parse CLI flags.
autoscaling.AutoScaling should be masked and mocked like SNSClient etc.

And in the end, we should be able to add some basic unit tests and integration tests. Unit tests will hopefully be easier to add since we are using interfaces, so we can basically fully mock listeners, notices and handlers.
Take a look and let me know what you think!

This is looking really good. I'm going to close #44 and we will focus on this one. Some comments:

I'd probably favour keeping it simple and not moving it in to a sub-package. I think even with the current flat package it's reasonable to use lowercase and uppercase to control what is effectively the public api.
I'd also avoid the init for setting up the logging and parsing. IMO that is what main() is for. If anything, we should move some code out of main() and into Daemon.

Aside from that, I'll make some comments as you go!

Also made you a contributor, thanks for all your contributions so far 🙇🏼♂

Tested the latest commit on this PR and everything seems to work fine/as expected. Going to clean up log messages now and then ask that you review, and then I think we should make issues of the "outstanding work" we can think of, that are not critical to the refactoring but should be done at some point.
PS: I think it would be nice to use the "squash and merge" button in github to merge this, so that we get 1 commit in master branch, but we can still look at the PR to see all the commits that were squashed?

I'll do a proper review of this next week and we can look at merging it for a 3.0.0 release?

Sounds good @lox! I've started a new branch (based on this one) to add some testing facilities and basic tests: https://github.com/itsdalmo/lifecycled/tree/add-basic-tests. Thinking that should perhaps also be a part of a 3.0.0 release (can always rewrite the tests later etc, but it's nice to have something)?

Merge at your leisure @itsdalmo and then we can look at the tests.

@lox - I'll merge this now, but I think we should wait with 3.0 until we have some tests in place (which might require a little more refactoring to get right).


Unable to complete the installation

Microsoft PowerToys version
0.60.1
Running as admin

[ ] Yes

Area(s) with issue?
Installer
Steps to reproduce

Setup Failed - 0x80070661- This installation package is not supported by this type of processor.

I formatted my computer yesterday, Windows was installed cleanly and updated, the processor did not change... PowerToys was working before formatting.
Thanks in advance,
JOURNAL:
[2DC8:14E4][2022-08-01T09:43:40]i001: Burn v<IP_ADDRESS>26, Windows v10.0 (Build 22000: Service Pack 0), path: C:\Users\marcm\AppData\Local\Temp{E2C89A87-D7BC-49D4-B53F-745C55645BE1}.cr\PowerToysSetup-0.60.1-arm64.exe
[2DC8:14E4][2022-08-01T09:43:40]i000: Initializing string variable 'InstallFolder' to value '[ProgramFiles6432Folder]PowerToys'
[2DC8:14E4][2022-08-01T09:43:40]i000: Initializing string variable 'MsiLogFolder' to value '[LocalAppDataFolder]\Microsoft\PowerToys'
[2DC8:14E4][2022-08-01T09:43:40]i000: Initializing version variable 'DetectedPowerToysVersion' to value '<IP_ADDRESS>'
[2DC8:14E4][2022-08-01T09:43:40]i000: Initializing version variable 'TargetPowerToysVersion' to value '0.60.1'
[2DC8:14E4][2022-08-01T09:43:40]i000: Initializing version variable 'DetectedWindowsBuildNumber' to value '0'
[2DC8:14E4][2022-08-01T09:43:40]i009: Command Line: '-burn.clean.room=C:\Users\marcm\OneDrive\Bureau\PowerToysSetup-0.60.1-arm64.exe -burn.filehandle.attached=580 -burn.filehandle.self=484'
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\marcm\OneDrive\Bureau\PowerToysSetup-0.60.1-arm64.exe'
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\marcm\OneDrive\Bureau'
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\marcm\AppData\Local\Temp\powertoys-bootstrapper-msi-0.60.1_20220801094340.log'
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting string variable 'WixBundleName' to value 'PowerToys (Preview) ARM64'
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting string variable 'WixBundleManufacturer' to value 'Microsoft Corporation'
[2DC8:1460][2022-08-01T09:43:40]i000: Setting numeric variable 'WixStdBALanguageId' to value 1033
[2DC8:1460][2022-08-01T09:43:40]i000: Setting version variable 'WixBundleFileVersion' to value '<IP_ADDRESS>'
[2DC8:14E4][2022-08-01T09:43:40]i100: Detect begin, 4 packages
[2DC8:14E4][2022-08-01T09:43:40]i000: Product or related product not found: {42B84BF7-5FBF-473B-9C8B-049DC16F7708}
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting version variable 'DetectedPowerToysVersion' to value '<IP_ADDRESS>'
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting string variable 'DetectedWindowsBuildNumber' to value '22000'
[2DC8:14E4][2022-08-01T09:43:40]i000: File search: wfs8C0990386AC06F307964ED8F1A52127E, did not find path: C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.6\System.Xaml.dll
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting numeric variable 'HasDotnet606' to value 0
[2DC8:14E4][2022-08-01T09:43:40]i000: Registry key not found. Key = 'Software\Microsoft\EdgeUpdate\Clients{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}'
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting numeric variable 'HasWebView2PerUser' to value 0
[2DC8:14E4][2022-08-01T09:43:40]i000: Setting numeric variable 'HasWebView2PerMachine' to value 1
[2DC8:14E4][2022-08-01T09:43:40]i000: Registry key not found. Key = 'Software\Microsoft\VisualStudio\14.0\VC\Runtimes\ARM64'
[2DC8:14E4][2022-08-01T09:43:40]i052: Condition 'HasDotnet606' evaluates to false.
[2DC8:14E4][2022-08-01T09:43:40]i052: Condition 'HasWebView2PerMachine OR HasWebView2PerUser' evaluates to true.
[2DC8:14E4][2022-08-01T09:43:40]i052: Condition 'DetectedVCRedistVersion >= 32' evaluates to false.
[2DC8:14E4][2022-08-01T09:43:40]i101: Detected package: DotnetRuntime6, state: Absent, cached: None
[2DC8:14E4][2022-08-01T09:43:40]i101: Detected package: WebView2, state: Present, cached: None
[2DC8:14E4][2022-08-01T09:43:40]i101: Detected package: VCRedist, state: Absent, cached: Complete
[2DC8:14E4][2022-08-01T09:43:40]i101: Detected package: PowerToysSetup_0.60.1_ARM64.msi, state: Absent, cached: Complete
[2DC8:14E4][2022-08-01T09:43:40]i052: Condition 'TargetPowerToysVersion >= DetectedPowerToysVersion OR WixBundleInstalled' evaluates to true.
[2DC8:14E4][2022-08-01T09:43:40]i052: Condition 'DetectedWindowsBuildNumber >= 19041 OR WixBundleInstalled' evaluates to true.
[2DC8:14E4][2022-08-01T09:43:40]i199: Detect complete, result: 0x0
[2DC8:1460][2022-08-01T09:43:42]i000: Setting numeric variable 'EulaAcceptCheckbox' to value 1
[2DC8:14E4][2022-08-01T09:43:42]i200: Plan begin, 4 packages, action: Install
[2DC8:14E4][2022-08-01T09:43:42]w321: Skipping dependency registration on package with no dependency providers: DotnetRuntime6
[2DC8:14E4][2022-08-01T09:43:42]i000: Setting string variable 'WixBundleLog_DotnetRuntime6' to value 'C:\Users\marcm\AppData\Local\Temp\powertoys-bootstrapper-msi-0.60.1_20220801094340_000_DotnetRuntime6.log'
[2DC8:14E4][2022-08-01T09:43:42]w321: Skipping dependency registration on package with no dependency providers: WebView2
[2DC8:14E4][2022-08-01T09:43:42]w321: Skipping dependency registration on package with no dependency providers: VCRedist
[2DC8:14E4][2022-08-01T09:43:42]i000: Setting string variable 'WixBundleLog_VCRedist' to value 'C:\Users\marcm\AppData\Local\Temp\powertoys-bootstrapper-msi-0.60.1_20220801094340_001_VCRedist.log'
[2DC8:14E4][2022-08-01T09:43:42]i000: Setting string variable 'WixBundleRollbackLog_PowerToysSetup_0.60.1_ARM64.msi' to value 'C:\Users\marcm\AppData\Local\Temp\powertoys-bootstrapper-msi-0.60.1_20220801094340_002_PowerToysSetup_0.60.1_ARM64.msi_rollback.log'
[2DC8:14E4][2022-08-01T09:43:42]i000: Setting string variable 'WixBundleLog_PowerToysSetup_0.60.1_ARM64.msi' to value 'C:\Users\marcm\AppData\Local\Temp\powertoys-bootstrapper-msi-0.60.1_20220801094340_002_PowerToysSetup_0.60.1_ARM64.msi.log'
[2DC8:14E4][2022-08-01T09:43:42]i201: Planned package: DotnetRuntime6, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: None, cache: Yes, uncache: No, dependency: None
[2DC8:14E4][2022-08-01T09:43:42]i201: Planned package: WebView2, state: Present, default requested: Present, ba requested: Present, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2DC8:14E4][2022-08-01T09:43:42]i201: Planned package: VCRedist, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: None, cache: No, uncache: No, dependency: None
[2DC8:14E4][2022-08-01T09:43:42]i201: Planned package: PowerToysSetup_0.60.1_ARM64.msi, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2DC8:14E4][2022-08-01T09:43:42]i299: Plan complete, result: 0x0
[2DC8:14E4][2022-08-01T09:43:42]i300: Apply begin
[2DC8:14E4][2022-08-01T09:43:42]i010: Launching elevated engine process.
[2DC8:14E4][2022-08-01T09:43:42]i011: Launched elevated engine process.
[2DC8:14E4][2022-08-01T09:43:42]i012: Connected to elevated engine.
[2E74:2618][2022-08-01T09:43:42]i358: Pausing automatic updates.
[2E74:2618][2022-08-01T09:43:42]i359: Paused automatic updates.
[2E74:2618][2022-08-01T09:43:42]i360: Creating a system restore point.
[2E74:2618][2022-08-01T09:43:42]w363: Could not create system restore point, error: 0x80070422. Continuing...
[2E74:2618][2022-08-01T09:43:42]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{e231b5e9-8bed-4270-af91-18f4a457a53b}, options: 0x7, disable resume: No
[2E74:2618][2022-08-01T09:43:42]i000: Caching bundle from: 'C:\Users\marcm\AppData\Local\Temp{5BA9034B-92D1-49C8-9875-693340D8C398}.be\PowerToysSetup-0.60.1-ARM64.exe' to: 'C:\ProgramData\Package Cache{e231b5e9-8bed-4270-af91-18f4a457a53b}\PowerToysSetup-0.60.1-ARM64.exe'
[2E74:2618][2022-08-01T09:43:42]i320: Registering bundle dependency provider: {e231b5e9-8bed-4270-af91-18f4a457a53b}, version: <IP_ADDRESS>
[2E74:2618][2022-08-01T09:43:42]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{e231b5e9-8bed-4270-af91-18f4a457a53b}, resume: Active, restart initiated: No, disable resume: No
[2DC8:26A0][2022-08-01T09:43:42]w343: Prompt for source of package: DotnetRuntime6, payload: DotnetRuntime6, path: C:\Users\marcm\OneDrive\Bureau\windowsdesktop-runtime-6.0.6-win-ARM64.exe
[2DC8:26A0][2022-08-01T09:43:42]i338: Acquiring package: DotnetRuntime6, payload: DotnetRuntime6, download from: https://download.visualstudio.microsoft.com/download/pr/d09acad2-0abb-4ec8-8388-b8b42b31cd58/517cff2da8fbcdcb514bb4e2f1dc8879/windowsdesktop-runtime-6.0.6-win-arm64.exe
[2E74:36D0][2022-08-01T09:43:47]i305: Verified acquired payload: DotnetRuntime6 at path: C:\ProgramData\Package Cache.unverified\DotnetRuntime6, moving to: C:\ProgramData\Package Cache\599CF13A1B0E3F1C2DBC2FE6210062C3795094A7\windowsdesktop-runtime-6.0.6-win-ARM64.exe.
[2E74:36D0][2022-08-01T09:43:47]i304: Verified existing payload: VCRedist at path: C:\ProgramData\Package Cache\FEECAC80EF04125B058381487332872896F38477\VCRedist-14.32.31332.exe.
[2E74:36D0][2022-08-01T09:43:47]i304: Verified existing payload: PowerToysSetup_0.60.1_ARM64.msi at path: C:\ProgramData\Package Cache{AD460648-675F-436C-A933-3D5F2C64CCEE}v0.60.1\PowerToysSetup-0.60.1-ARM64.msi.
[2E74:2618][2022-08-01T09:43:47]i301: Applying execute package: DotnetRuntime6, action: Install, path: C:\ProgramData\Package Cache\599CF13A1B0E3F1C2DBC2FE6210062C3795094A7\windowsdesktop-runtime-6.0.6-win-ARM64.exe, arguments: '"C:\ProgramData\Package Cache\599CF13A1B0E3F1C2DBC2FE6210062C3795094A7\windowsdesktop-runtime-6.0.6-win-ARM64.exe" /install /quiet /norestart'
[2E74:2618][2022-08-01T09:43:48]e000: Error 0x80070661: Process returned error: 0x661
[2E74:2618][2022-08-01T09:43:48]e000: Error 0x80070661: Failed to execute EXE package.
[2DC8:14E4][2022-08-01T09:43:48]e000: Error 0x80070661: Failed to configure per-machine EXE package.
[2DC8:14E4][2022-08-01T09:43:48]i319: Applied execute package: DotnetRuntime6, result: 0x80070661, restart: None
[2DC8:14E4][2022-08-01T09:43:48]e000: Error 0x80070661: Failed to execute EXE package.
[2E74:2618][2022-08-01T09:43:48]i351: Removing cached package: DotnetRuntime6, from path: C:\ProgramData\Package Cache\599CF13A1B0E3F1C2DBC2FE6210062C3795094A7
[2E74:2618][2022-08-01T09:43:48]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{e231b5e9-8bed-4270-af91-18f4a457a53b}, resume: None, restart: None, disable resume: No
[2E74:2618][2022-08-01T09:43:48]i330: Removed bundle dependency provider: {e231b5e9-8bed-4270-af91-18f4a457a53b}
[2E74:2618][2022-08-01T09:43:48]i352: Removing cached bundle: {e231b5e9-8bed-4270-af91-18f4a457a53b}, from path: C:\ProgramData\Package Cache{e231b5e9-8bed-4270-af91-18f4a457a53b}
[2E74:2618][2022-08-01T09:43:48]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{e231b5e9-8bed-4270-af91-18f4a457a53b}, resume: None, restart initiated: No, disable resume: No
[2DC8:14E4][2022-08-01T09:43:49]i399: Apply complete, result: 0x80070661, restart: None, ba requested restart:  No

Any chance you might be trying to install the arm64 version of PowerToys on a x64 CPU? Does the x64 installer work instead? https://github.com/microsoft/PowerToys/releases/download/v0.60.1/PowerToysSetup-0.60.1-x64.exe /needinfo

It is already the x64 that I am trying to install.

Any chance you might be trying to install the arm64 version of PowerToys on a x64 CPU? Does the x64 installer work instead? https://github.com/microsoft/PowerToys/releases/download/v0.60.1/PowerToysSetup-0.60.1-x64.exe /needinfo

It is already the x64 that I am trying to install. Same as the link you gave me.

I see in the log file you uploaded lots of mentions to PowerToysSetup-0.60.1-arm64.exe. /needinfo

Then I don't understand what happened! I already have the file from your link in my download folder but it's not the one I was trying to install but the arm64 version I had downloaded before formatting. Thanks for seeing this! I made a mistake!
Thanks a lot :), it works. Have a nice day :)


release: Update core SDK

Update IBM core SDK version to latest version.

:tada: This PR is included in version 1.0.43 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Error during multi-GPU training

Hello.
Training on a single GPU works fine.
However, if a number greater than 1 is given to the --devices parameter of piper_train it fails with the following trace.
Traceback (most recent call last):
  File "/miniconda3/envs/piper/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/miniconda3/envs/piper/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/piper/src/python/piper_train/__main__.py", line 150, in <module>
    main()
  File "/piper/src/python/piper_train/__main__.py", line 127, in main
    trainer.fit(model)
  File "/miniconda3/envs/piper/lib/python3.10/site-packages/pytorch_lightning/trainer/trainer.py", line 696, in fit
    self._call_and_handle_interrupt(
  File "/miniconda3/envs/piper/lib/python3.10/site-packages/pytorch_lightning/trainer/trainer.py", line 648, in _call_and_handle_interrupt
    return self.strategy.launcher.launch(trainer_fn, *args, trainer=self, **kwargs)
  File "/miniconda3/envs/piper/lib/python3.10/site-packages/pytorch_lightning/strategies/launchers/multiprocessing.py", line 107, in launch
    mp.start_processes(
  File "/miniconda3/envs/piper/lib/python3.10/site-packages/torch/multiprocessing/spawn.py", line 189, in start_processes
    process.start()
  File "/miniconda3/envs/piper/lib/python3.10/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/miniconda3/envs/piper/lib/python3.10/multiprocessing/context.py", line 288, in _Popen
    return Popen(process_obj)
  File "/miniconda3/envs/piper/lib/python3.10/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/miniconda3/envs/piper/lib/python3.10/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/miniconda3/envs/piper/lib/python3.10/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/miniconda3/envs/piper/lib/python3.10/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
  File "/miniconda3/envs/piper/lib/python3.10/site-packages/torch/multiprocessing/reductions.py", line 143, in reduce_tensor
    raise RuntimeError("Cowardly refusing to serialize non-leaf tensor which requires_grad, "
RuntimeError: Cowardly refusing to serialize non-leaf tensor which requires_grad, since autograd does not support crossing process boundaries.  If you just want to transfer the data, call detach() on the tensor before serializing (e.g., putting it on the queue).

What can be the possible cause, can you point me in the right direction to solve this issue?

Providing --strategy ddp resolved this issue.


[WIP] Support Ajbrock SN and Update BigGAN with best FID and IS

Support SN implemented by ajbrock.
Updated BigGAN trained on imagenet128x128 which reached best FID(8.69) and IS(129.07).

TODOs:

[ ] Docs and citation statement of biggan_snmodule.
[ ] Complete Unittest.

You may need to merge the conflict from the master branch. Then, I can merge this PR.


typings issue

Transpile is throwing errors, I suspect it's related with typings update

Resolved and merged


Editor crash after connecting to LSP server

Godot version
4.0.beta2
System information
Apple M1 Pro, macOS Monterey 12.6, Vulkan API 1.1.216
Issue description
Connecting to Godot's language server (in my case using VSCode with the Godot Tools extension) causes the editor to crash if a script contains the following line:
@onready var _input: TestNode = get_node(path)

I found that it only crashes if I add a type annotation and if other types in the project extend the annotated type:
# test_node.gd
class_name TestNode extends Node3D

# test_node_child.gd
class_name TestNodeChild extends TestNode

It also only seems to crash if the variable name is the name of a builtin callback (i.e. _input, _ready, _process)
In some cases it does not crash immediately but I have to comment/uncomment the line several times. Most of the time it crashes without any error or log but occasionally I get a backtrace:
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta2.official (f8745f2f71c79972df66f17a3da75f6e328bc55d)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] 1   libsystem_platform.dylib            0x00000001b35434a4 _sigtramp + 56
[2] Object* ClassDB::creator<GDScript>()
[3] Object* ClassDB::creator<GDScript>()
[4] Object* ClassDB::creator<GDScript>()
[5] Object* ClassDB::creator<GDScript>()
[6] Object* ClassDB::creator<GDScriptWorkspace>()
[7] Object* ClassDB::creator<GDScriptWorkspace>()
[8] Object* ClassDB::creator<GDScriptWorkspace>()
[9] Object::can_translate_messages() const
[10] Object::can_translate_messages() const
[11] Object::can_translate_messages() const
[12] Object::get_instance_id() const
[13] Object::get_instance_id() const
[14] EditorPlugin* EditorPlugins::creator<GridMapEditorPlugin>()
[15] EditorPlugin* EditorPlugins::creator<GridMapEditorPlugin>()
[16] Object* ClassDB::creator<GDScript>()
[17] Object* ClassDB::creator<GDScript>()
[18] GDScriptLanguageProtocol::is_initialized() const
[19] GDScriptLanguageProtocol::is_initialized() const
[20] ScriptInstanceExtension::_add_property_with_state(void*, void*, void*)
[21] Node::is_inside_tree() const
[22] Node::is_inside_tree() const
[23] RendererCompositorRD::_create_current()
[24] 24  Godot                               0x0000000105324984 Godot + 3918212
[25] RendererCompositorRD::_create_current()
[26] 26  dyld                                0x000000010b98108c start + 520
-- END OF BACKTRACE --

The problem does not seem to occur when using the Godot script editor but only once an external editor connects to the language server.
Steps to reproduce

Open the minimal reproduction project
Open the test.tscn scene
Open the onready_bug.gd script using an external editor that connects to Godot's language server
If the editor does not crash, comment/uncomment line 4 repeatedly

Minimal reproduction project
onready_bug.zip

I ran into even more crashes. I did some more testing:
var _input: TestNode # crash
var testnode: TestNode # no crash
var _test_node: TestNode # crashes sometimes

I seems like it crashes when I mess around with variable names that (partially) match any of the builtin callbacks (i.e. anything that would be autocompleted/suggested in the editor).
Also it does not seem to crash when I add a different type annotation e.g.:
var _input: Node3D # never crashes

I did some tests on Windows and I could not reproduce the issue. Could be exclusive to macOS or maybe it is an issue specific to my machine/setup. Would be interesting to test this on another Mac.

Am facing the same or similar Issue on Ubuntu. I cannot reproduce the error with your provided example and so far am not able to pinpoint the exact Issue in my Code yet. I don't know if its helps, but here is the  backtrace i am getting when connection to the lsp server:
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta3.official (01ae26d31befb6679ecd92cd3c73aa5a76162e95)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7fa34c488520] (??:0)
[2] /lib/x86_64-linux-gnu/libc.so.6(+0x19d97d) [0x7fa34c5e397d] (??:0)
[3] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x4234081] (??:0)
[4] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x4234186] (??:0)
[5] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x1119b8d] (??:0)
[6] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x11dc62b] (??:0)
[7] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x11de0dc] (??:0)
[8] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x10ec31d] (??:0)
[9] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x10edb82] (??:0)
[10] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x49b11f4] (??:0)
[11] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x10844ac] (??:0)
[12] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x1076dfa] (??:0)
[13] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x422c518] (??:0)
[14] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x424ef8f] (??:0)
[15] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x1438990] (??:0)
[16] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x143930a] (??:0)
[17] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x1055955] (??:0)
[18] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x105ab6b] (??:0)
[19] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x4226024] (??:0)
[20] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x2908a7e] (??:0)
[21] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0x294c8fe] (??:0)
[22] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0xe57eb5] (??:0)
[23] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0xd928ac] (??:0)
[24] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fa34c46fd90] (??:0)
[25] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fa34c46fe40] (??:0)
[26] /home/lommix/Tools/Godot_v4.0-beta3_linux.x86_64() [0xdb3e3e] (??:0)
-- END OF BACKTRACE --

Currenty trying to move out regions of my project to an empty one to pinpoint the problem, i will update as soon as find new information.

I managed to get the debugger output with gdb, the moment I connect to the lsp on Linux.  I am not invested enough into the engine to tell what is happening (yet), but hopefully someone with more experience can explain the issue.

strlen-avx2.S
Could not load source './string/../sysdeps/x86_64/multiarch/strlen-avx2.S': 'SourceRequest' not supported..

I am similarly having this issue.  Interfacing with the LSP server in emacs causes a near automatic crash IF the script editor itself isn't loaded, and a progressive crash every single time a new buffer is associated with the LSP server.
Ubuntu 22.04, doom emacs with lsp-mode.  Not entirely sure why.  I'll attempt to narrow it down, but I wonder if its related to parsing object types.
I'm fairly close to just moving to C# tbh, but even so I think this is something worth looking at.  The GDScript editor in the editor itself is good for small scale stuff, but very large code bases need a proper editor.

Below is a backtrace for a crash on macOS, running Ventura 13.0.1 on an M2 MacBook Air. I'm using VS Code as my editor. My GDScript file doesn't contain any type hints, but I do use terms like input and player and node in identifiers.
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta7.official (0bb1e89fb7046209f64d46ccedc6b42645c96573)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] 1   libsystem_platform.dylib            0x000000018e51c2a4 _sigtramp + 56
[2] Object* ClassDB::creator<GDScript>()
[3] Object* ClassDB::creator<GDScript>()
[4] Object* ClassDB::creator<GDScript>()
[5] Object* ClassDB::creator<GDScript>()
[6] Object* ClassDB::creator<GDScriptWorkspace>()
[7] Object* ClassDB::creator<GDScriptWorkspace>()
[8] Object* ClassDB::creator<GDScriptWorkspace>()
[9] Object::can_translate_messages() const
[10] Object::can_translate_messages() const
[11] Object::can_translate_messages() const
[12] Object::get_instance_id() const
[13] Object::get_instance_id() const
[14] EditorPlugin* EditorPlugins::creator<GridMapEditorPlugin>()
[15] EditorPlugin* EditorPlugins::creator<GridMapEditorPlugin>()
[16] Object* ClassDB::creator<GDScript>()
[17] Object* ClassDB::creator<GDScript>()
[18] GDScriptLanguageProtocol::is_initialized() const
[19] GDScriptLanguageProtocol::is_initialized() const
[20] ScriptInstanceExtension::_add_property_with_state(void*, void*, void*)
[21] Node::is_inside_tree() const
[22] Node::is_inside_tree() const
[23] RendererCompositorRD::_create_current()
[24] 24  Godot                               0x0000000104449e74 Godot + 4021876
[25] RendererCompositorRD::_create_current()
[26] 26  dyld                                0x000000018e1c3e50 start + 2544
-- END OF BACKTRACE --
================================================================

#68049

Fixed by #69606


Version hint of "dependencies" section sometimes doesn't update on navigation

E.g. the grpc module page shows this, even though it doesn't have a matching version:

Steps to reproduce

Navigate to https://registry.bazel.build/all-modules
Click on the card for boringssl
Click on grpc in the "dependents" section (also works when clicking on any dependency)

Interestingly, the same issue doesn't occur when starting navigation (via hard refresh) from a module page (https://registry.bazel.build/modules/boringssl)

Closing this, as I'm unable to reproduce the issue. There have been some changes in that area after opening this issue, so this may have been resolved in passing.


Revert "Update Build Wheels to only build once on RCs"

Reverts apache/beam#32009 because both builds are used in RC deployment at different places.

Added an explicit 8-hour timeout to give us some head room, should be well under 6 once Python 3.8 is deprecated.


Not gzip package installed and drush archive-dump fails.

Drush use gzip to compress the files when using drush archive-dump. Right now this command fails, adding gzip fix this issue.

Hi @erozqba,
I've added gzip.

Thanks a lot, great work! :+1:


Should we allow connectivity between containers within the same deployment unit even when defaultNetworkPolicy is set to None.

Rancher Versions: Build from master
Steps to reproduce the problem:
Create a service S1 with 2 sidekicks sk1 and sk2.
Set defaultNetworkPolicy to "deny" and policy to None for the network.
With this setting , should we still expect connectivity between containers within the same deployment unit to be allowed?
Currently there is no connectivity  between containers within the same deployment unit.

This is inline with our design. If the default policy action is deny it means, the user wants to lockdown every communication. Now unless a policy is defined to enable communication, no two containers can communicate with each other. If the sidekick containers were sharing the same network as the primary service, then this question anyways doesn't come into picture as the two containers would be sharing the same network stack.

Closing as this is expected behavior


Styling Excel Sheets

Hello,
I am trying to apply styling to my sheet. However, I get this error;
BadMethodCallException  : Method Maatwebsite\Excel\Sheet::styleCells does not exist.
Below is my Exports file
namespace App\Exports;

use Illuminate\Contracts\View\View;
use Maatwebsite\Excel\Concerns\FromView;
use Maatwebsite\Excel\Concerns\Exportable;
use Maatwebsite\Excel\Concerns\ShouldAutoSize;
use Maatwebsite\Excel\Concerns\WithEvents;
use Maatwebsite\Excel\Events\BeforeExport;
use Maatwebsite\Excel\Events\AfterSheet;

class MitieReport implements FromView, ShouldAutoSize, WithEvents
{
    use Exportable;

    public function registerEvents(): array
    {
        return [
            AfterSheet::class    => function(AfterSheet $event) {
                $event->sheet->styleCells(
                    'B2:G8',
                    [
                        'borders' => [
                            'outline' => [
                                'borderStyle' => \PhpOffice\PhpSpreadsheet\Style\Border::BORDER_THICK,
                                'color' => ['argb' => 'FFFF0000'],
                            ],
                        ],
                        'font' => [
                            'bold' => true,
                        ]
                    ]
                );
            },
        ];
    }

    public function view(): View
    {
        return view('reports.weeklyReport');
    }

}

I did see this, but I couldn't figure out how to implement it @m-bosch

Hi @Gareth-3aaa
You can put your 'styleCells' macro definition as @m-bosch pointed out in App\Providers\AppServiceProvider boot()
Or you can make your own provider using
php artisan make:provider YourMacroServiceProvider
and register it in config/app.php and then you can put your all macro definitions inside the boot method of your new provider.
You might want to read more about Laravel macros here or here
Good luck!

Thanks for the extra info @m-bosch and @RoyIrwan as I was having the same issue as @Gareth-3aaa
For anyone else running into this, it looks like there is a typo in the sample code for styleCells (bold added):
`use \Maatwebsite\Excel\Sheet;
Sheet::macro('styleCells', function (Sheet $sheet, string $cellRange, array style) {
$sheet->getDelegate()->getStyle($cellRange)->applyFromArray($style);
});`
Should be:
`use \Maatwebsite\Excel\Sheet;
Sheet::macro('styleCells', function (Sheet $sheet, string $cellRange, array $style) {
$sheet->getDelegate()->getStyle($cellRange)->applyFromArray($style);
});`


Remove crictl from Dockerfile

We don't have a CRI API, we'll never use it. Should make the tests a tiny bit faster when run in a container.

bot, retest this please

Changes LGTM, test error seems to be a network issue.

bot, retest this please

@rh-atomic-bot r+


[Bug]I somehoe die at 63 on Cataclysm and it must have something to do with mod because when I deletred the mod it worked. Maybe the mod changes the physics but I dont have physics bypass or tps bypass on.

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
What steps did you do to get this result?
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.

it's a vanilla bug related to "Show Hitboxes".
you can either disable hitboxes, or get the beta build which fixes the issue from here:
https://github.com/Prevter/OpenHack/releases/tag/nightly

OMG THX


Aux scanner does not recognize multiple citations when using the cite package

Using multiple keys in a citation  is not recognized.
the command:
\cite{Akey,Bkey,Ckey}
produces  the following in the aux file :
\citation{Akey,Bkey,Ckey}
Apparently, the regular expression in use :
re = /\citation{([^}]+)}/g
interprets this case as the single citation key "Akey,Bkey,Ckey" that, of course, is not in Zotero and a notice for missing key  is generated, while the actually existing keys Akey, Bkey, Ckey, are not imported .
Steps to reproduce:
1 Create a file main.tex wit hthe following content
(change A_key and B_key to values that exist in your zotero database):
\documentclass{article}
\usepackage{cite}
\begin{document}
\cite{A_key,B_key}
\end{document}
2 compile the file
pdflatex main
3 open zotero and import the main.aux file
Expected result:
A_key and B_key are imported as two separate items.
Actual result:
the two keys are not imported,
the concatenation of "A_key,B_key" is signaled as missing key.
Notes:
This was observed after upgrading to the latest version today.
This does not happen when the cite package is not in use.

This must have been a long-standing error, I haven't changed anything about the AUX scanner in 5 months. Can you try https://github.com/retorquere/zotero-better-bibtex/releases/download/builds/zotero-better-bibtex-1.6.65-circle-2546.xpi ?

Thank you for the quick response.
I just tried  the version you linked and it imported all the references in my document correctly.
I think the bug can be closed.


Instructions for enabling Tor with systemd do not work

Right now, tor.html recommends enabling the systemd Tor service:
systemctl enable --now tor

However, this does not seem to work, at least not for me on my Debian server because the default file tor.service does absolutely nothing.
This is because Debian supports multiple Tor instance, and a new one must be created:
# Create instance
tor-instance-create MY_INSTANCE_NAME
# Edit `torrc`
# (Set `HiddenServiceDir` to be inside `/var/lib/tor-instances/MY_INSTANCE_NAME`)
vi /etc/tor/instances/MY_INSTANCE_NAME/torrc
# Start systemd service
systemctl enable --now tor@MY_INSTANCE_NAME

There also comes a default Tor instance<EMAIL_ADDRESS>but for some reason systemd doesn't let it be enabled.
See https://askubuntu.com/a/903341 and man tor-instance-create.

You already made a pull request, just add these findings to it. I did a fresh install of tor following the guide 20 minutes ago on a Debian 10 VPS (amd64). Everything worked until printing out the hostname. That's an easy fix though, just do systemctl restart tor.
If there is some radically different way of setting tor up with systemd I'm not opposed to it, but the tutorial should be rewritten.

If everything works for you, then that would mean that the setup varies across different system, so I'm not sure what to put.
On my Debian 11 (bullseye) x86_64 server, my tor.service file does not start Tor and there are two other service files for Tor.
cat /lib/systemd/system/tor.service
----
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.

[Unit]
Description=Anonymizing overlay network for TCP (multi-instance-master)

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true

[Install]
WantedBy=multi-user.target

ls /lib/systemd/system/tor*.service
----
/lib/systemd/system/tor.service
<EMAIL_ADDRESS><EMAIL_ADDRESS>
What happens when you run cat /lib/systemd/system/tor.service and ls /lib/systemd/system/tor*.service?

The outputs are identical. If you do figure out a Debian 11 solution (most likely a systemd problem) then post your solution here.

Strangely, it's working now.  It seems that tor.service starts<EMAIL_ADDRESS>which loads the normal config file at /etc/torrc.  Thanks for the help.


Return go-get info on subdirs

This PR is an alternative to #15628 and makes the go get handler a
handler.
Fix #15625
Close #15628
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

It seems this still not resolve the sub dir problem. And I think with a test is better.

@lunny what do you mean it does not resolve the subdir problem?
What are you expecting and what are you testing?

With this patch as it stands:
> curl 'http://localhost/gitea/administrator/admin/asjdaljsda?go-get=1'                      [18:40:08]
<!doctype html>
<html>
	<head>
		<meta name="go-import" content="localhost/gitea/administrator/admin git http://localhost/gitea/administrator/admin.git">
		<meta name="go-source" content="localhost/gitea/administrator/admin _ http://localhost/gitea/administrator/admin/src/branch/master{/dir} http://localhost/gitea/administrator/admin/src/branch/master{/dir}/{file}#L{line}">
	</head>
	<body>
		go get --insecure localhost/gitea/administrator/admin
	</body>
</html>

Test case added and conflicts resolved


suggestion to fix #185. extend the datepicker.js default values with a passed configuration

Makes using the datepicker much more comfortable. you can now easily set options like "firstDay", "format" etc, which datepicker.js already supports, simply by passing your own object to DatePicker().
This is just a minor patch

Hi @aremes, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

Thanks for this @aremes! This is directly in reference to issue #185, so I'm going to go ahead and close that too.
Just to reiterate from the same issue I'm closing... the design language currently doesn't support all of the functionality in pickadate.js's robust API, so we can't take on any bugs resulting from the API's many options or the visualizations of those options.
To that end, we'll definitely look into supporting more of the functionality provided by pickadate.js (e.g. disabled days, formatting options, etc.) and we opened an issue on ourselves - #188 - to track this.


Why do sleeping futex-based SpinLocks wake and spin again periodically?

I'm trying to understand this code:
https://github.com/abseil/abseil-cpp/blob/1ae9b71c474628d60eb251a3f62967fe64151bb2/absl/base/internal/spinlock_linux.inc#L59-L72
SpinLock uses futexes for the slow path on Linux. The thread calling FUTEX_WAIT apparently sets a random timeout on the wait. When either the futex is woken or the timeout expires, the thread will wake up and try to take the lock again.
But AFAICT the thread that holds the lock will reliably call FUTEX_WAKE when releasing it. So it seems like there is no reason for the waiting thread to set a timeout. It will always get an explicit wake if the lock is available. If it wakes from the timeout, it will presumably always find the lock is still held, in which case it will SpinLoop() (burning CPU) and then (if it's still locked) go back to sleep.
This code appears to be ancient. The same code can be found in gperftools, where it appears to date back to at least 2009 -- before that, the code didn't use futex at all and was just a sleep loop.
Is this timeout behavior vestigial and possibly no longer useful?
I came across this behavior while trying to debug a problem we see in production with tcmalloc: Occasionally, a server gets locked up with 1000+ threads all waiting on the global freelist's spinlock. It looks like this is not a deadlock situation, but instead a live lock. We suspect the spinlock behavior means that when a very large number of threads is waiting on the same spinlock, the CPU gets saturated with threads running SpinLoop() while the thread that actually holds the lock struggles to make progress. We're going to try ripping out all the spinning code and see if that improves anything, but I also want to understand if there's some rationale behind the approach here.

This does appear to be vestigial to me.
It looks like https://github.com/abseil/abseil-cpp/commit/44b0fafc62d9b8f192e8180cbe9c4b806b339d57#diff-2d68645321260a286f9f39f0494e13bfcbb62b1aba31873946240c441222adda removed the possibility of a missed wakeup at the expense of a slightly slower Unlock path.
As far as I can tell what happened here is that spinlock_linux.inc is actually a forked copy of our production copy, but with the fiber scheduling code removed. We normally use a code stripping mechanism to avoid forks, but for some reason that didn't happen here. I'll see if the code can be merged and the timeout removed.
Note: This is issue has been tracked for a while under b/209611780 and was probably also reported to https://github.com/google/tcmalloc/issues/111.

Oh yeah, https://github.com/google/tcmalloc/issues/111#issuecomment-987503032 is in fact describing the same problem that I am suspecting here, but I didn't actually understand the comment when I first read it. Hah.
(And yeas, that thread was started by someone on my team.)

Interestingly, the missed-wakeup fix you reference seems to have been fixed in gperftools much earlier: https://github.com/gperftools/gperftools/commit/560ca8650c8a9d2971420970f0ed5e17848150eb


Readme with example?

I do maintain a list of RSCG at https://ignatandrei.github.io/RSCG_Examples/v2/docs/List-of-RSCG
I did find your - but I cannot understand the usage
Could you put into readme.md?

Hello,
first of all, I think your page listing Roslyn source code generator (RSCG) projects is very nice. I've spotted some interesting projects that I didn't know of yet. I think I'll return to it in future. ;)
That said, I'm not sure whether this project is a good fit. This repository in particular doesn't host an actual RSCG (you won't finde an ISourceGenerator or IIncrementalSourceGenerator implementation here). This is just meant as a library with useful functions meant for other RSCG projects. Because I have several RSCG projects now, I wanted to keep it "DRY" (as in "Don't Repeat Yourself") and create a library with the shared functionalities.
This library isn't polished at all. It just contains the functions that I needed in my RSCG projects so far. If it is useful for someone else, it's okay.
However, I have some other RSCG projects that might be of interest for your page with the list:

MrMeeseeks.DIE A Dependency Injection container generator. It also has a dedicated documentation homepage and recently I started to build a DI container feature comparison page.
MrMeeseeks.Visitor A generator for the boilerplate code of the Visitor pattern from the Gang of Four.
MrMeeseeks.ResXToViewModelGenerator A generator which generates ViewModel classes based on ResX localization files (relevant for WPF-like UI apps that use the Model-View-ViewModel MVVM pattern and ResX files for localization)
MrMeeseeks.StaticDelegateGenerator A generator for the - what I call - "Static Delegate" pattern (it's described in more detail in the ReadMe)
I would feel honored if any of these RSCG projects make it to your list. :) These also have pretty accurate ReadMe's (with the exception of MrMeeseeks.ResXToViewModelGenerator).

Last thing that I want to mention. Do you know of this repository: csharp-source-generators? It seems that it purpose (i.e. to list RSCG projects) is similar to your list. Maybe it can be a source of inspirations for your list.

Thanks for your comment.
Yes, I know the repo csharp-source-generators . I am looking sometimes
And yes, I know the other yours RSCG. Unfortunately, my RSCG list is very opinionated. I do not want to test something that is on ISourceGenerator , but only on IIncrementalGenerator ( to justify partially, is because of how dotnet build / VS behaves )
If you are upgrading those, please let me know .
Thanks again!