Revert "gcc: 11.2.0 -> 11.3.0" for aarch64-darwin

Patches to support GCC 11.3.0 on aarch64-darwin are not available. Homebrew
also is skipping the 11.3.0 upgrade. Approximately 30% of aarch64-darwin packages
will be broken by #171497 because gfortran does not build.
I tried to rebase the branch linked in that issue onto GCC 11.3.0's release source, but I really have no clue what I'm doing and could not make it work.
There is also significant (6%) breakage on x86_64-darwin because libgcc is having trouble building. It's possible this reversion should be extended to all of Darwin.
With this patch I can now build  gfortran on aarch64-darwin and an example dependency like openblas now builds and passes its test.
cc: @trofi @vcunat @NixOS/darwin-maintainers
Description of changes

Things done

Built on platform(s)

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

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

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

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

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

[X] Fits CONTRIBUTING.md.

x86_64-darwin apparently also runs into some gcc11 issue now, though of a different kind: https://hydra.nixos.org/build/175546330
so I wonder if we'll end up... just simplifying the condition of this PR.

Anyway, this PR should go first.

Yeah, I saw that and mentioned it in this PR. I had hoped it would be more easily fixable and/or someone else could step up. I might give it a try tomorrow. I assume GCC 12 has no chance of going in to 22.05 so it would be important to revert if that is in fact unfixable.

It can go to 22.05 but not as default.  There will surely be many packages to fix, at least with missing #includes.


Get Account Info

Is your feature request related to a problem? Please describe.
We are not able to get any information about an account via account address.
Describe the solution you'd like
We should have an API to retrieve account information such as the name/description, roles, and features of the account.

account info api has been implemented


Publish GitHub releases for new versions

Splitting this request out from https://github.com/badeball/cypress-cucumber-preprocessor/issues/689#issuecomment-1114883850.
It would be really helpful if new versions were published as GitHub releases. Releases can be separately subscribed to while tags and CHANGELOG updates cannot. Subscribing to releases is a great way to notify users as new versions are released. The GitHub release contents can either be a copy of the CHANGELOG or a link to the heading in the CHANGELOG corresponding to that version.

From the previous thread, I think there was concern about confusion publishing GitHub releases that included work done during the migration of ownership for this repo. I think not having GitHub releases for the newer versions is equally confusing, since the latest GitHub release version is shown at the top level of the repo. I think new versions since the transfer completed should be published as releases pointing to the corresponding tags.

You're right on all counts. I've made a release for v11.0.0 and will continue to do so moving forward.


Re-Evaluate supported TypeScript versions, open bugs in older versions

I just executed the current test suite against all supported TypeScript versions. The results aren't too promising:
https://travis-ci.org/phryneas/fork-ts-checker-webpack-plugin/builds/522776393
Here's a collection of the failing tests:
TS 2.1
General:
1) should not mark warnings as errors when ignoreLintWarnings passed as option
2) should support custom resolution
3) should fix linting errors with tslintAutofix flag set to true
4) should not fix linting by default
5) should not find syntactic errors when checkSyntacticErrors is false
6) should find syntactic errors when checkSyntacticErrors is true
7) should find the same errors on multi-process mode
8) should only show errors matching paths specified in reportFiles when provided
9) should handle errors within the IncrementalChecker gracefully as diagnostic
Vue-Specific:
10) should get syntactic diagnostics from Vue program
11) should resolve src attribute but not report not found error
12) should be able to compile *.vue with each lang"before all" hook
13) should be able to detect errors in *.vue: "before all" hook
14) should resolve *.vue in the same way as TypeScript counter check - should report report one generic compilation error

TS 2.2
as TS 2.1

TS 2.3
General as above
Vue-Specific:
10) should resolve src attribute but not report not found error

TS 2.4
as TS 2.3

TS 2.5
General
1) should not mark warnings as errors when ignoreLintWarnings passed as option
Vue-Specific
2) should resolve src attribute but not report not found error

TS 2.6
General
1) should not mark warnings as errors when ignoreLintWarnings passed as option

TS 2.7
General (useIncrementalApi: true)
1) should not mark warnings as errors when ignoreLintWarnings passed as option
General (useIncrementalApi: false)
2) should not mark warnings as errors when ignoreLintWarnings passed as option

TS 2.8
as TS 2.7

TS 2.9
as TS 2.7

All TS 3.X versions seem to be working fine.
So the question is: how to continue from here on?
From looking at the tests, I would suggest to drop support for TS<2.5 and investigating the other two failing tests.
But of course, this might be something you know and expect and I'm just over-interpreting those results.
What do you think?
PS: please keep in mind, all these test were only run in the following configuration:
linux node@10 <EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Running other configurations might uncover more errors, but for now I kept it at that.

So I tried hunting down this should not mark warnings as errors when ignoreLintWarnings passed as option test's error.
It boils down to the test finding an error that is not found with later TS versions:
[ { rawMessage:
     'ERROR TS2322: Type \'"1"\' is not assignable to type \'number\'.',
    message:
     '\u001b[1m\u001b[31mERROR in \u001b[39m\u001b[22m\u001b[1m\u001b[36m/home/weber/tmp/fork-ts-checker-webpack-plugin/test/integration/project/src/index.ts(2,7)\u001b[39m\u001b[22m\u001b[1m\u001b[31m:\u001b[39m\u001b[22m\n\u001b[90mTS2322: \u001b[39mType \'"1"\' is not assignable to type \'number\'.',
    location: { line: 2, character: 7 },
    file:
     '/home/weber/tmp/fork-ts-checker-webpack-plugin/test/integration/project/src/index.ts' } ]

Honestly, looking at the tests I would also expect to see this behaviour in TS >= 3.0 :weary:
Do you have any explanation? Did searching for source files somehow change with 3.0?

This is a very sad thing!

Honestly, looking at the tests I would also expect to see this behaviour in TS >= 3.0

When you mentioned that I remembered a change we made when we 1 point oh-ed: https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/master/CHANGELOG.md#v100

There are actually no breaking changes that we're aware of; users of 0.x fork-ts-checker-webpack-plugin should be be able to upgrade without any drama. Users of TypeScript 3+ may notice a performance improvement as by default the plugin now uses the incremental watch API in TypeScript. Should this prove problematic you can opt out of using it by supplying useTypescriptIncrementalApi: false.

You get different behaviour for error reporting with the incremental API:  https://github.com/Realytics/fork-ts-checker-webpack-plugin/pull/198#issuecomment-453790649
Essentially, the compiler starts reporting errors and stops checking for more of different kinds when using the incremental API.  This may / may not explain the specific test you're talking about here.
With regards all tests running with useTypescriptIncrementalApi: true, I would expect near failures for TypeScript 2.9 and lower.  The incremental API didn't arrive until TypeScript 2.7 (I think) and didn't really stabilise until around 2.9.
If you exclude incremental API tests running for < 3.0 how does that change the picture?

Unfortunately, this is not a useTypescriptIncrementalApi: true thing - I did not execute those tests for TS<2.7 and am getting the most errors for these versions nonetheless.
The error in questions occurs for both useTypescriptIncrementalApi: false and (in >=2.7) useTypescriptIncrementalApi: true in the same way :/
On the other hand, we have no additional failures with useTypescriptIncrementalApi: true, which is cool ;)
As for modifying the should not mark warnings as errors when ignoreLintWarnings passed as option test - yes, that could be done, and for that specific test that would  be correct. But it reported something we would have missed otherwise: different behavious with different TS versions. So I want to at least understand what exactly changed here, to be able to decide if this is just "different behaviour" or a full-fledged bug that we are just seeing for the first time and that will bite us in the future..

So I want to at least understand what exactly changed here, to be able to decide if this is just "different behaviour" or a full-fledged bug that we are just seeing for the first time and that will bite us in the future..

Good shout.

New finding:
https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/3990a135cb93e336ef0890061f6c360e7efc2f4d/test/integration/index.spec.js#L178
All tests running helpers.testLintAutoFixTest are not passing the useTypescriptIncrementalApi option at all, so for TS>=3.0, these tests are always running with the default value of useTypescriptIncrementalApi: true, even if the tests that should be running useTypescriptIncrementalApi: false.
That's the only reason these tests are not failing.
So yes, this seems to be a different behaviour between useTypescriptIncrementalApi true|false, nothing to do with TS 2 or 3.

All tests running helpers.testLintAutoFixTest are not passing the useTypescriptIncrementalApi option

How many are in that camp (hands over eyes)

Just four. Assuming I haven't missed anything else.

cool - which ones are they? are they all tslint related?

"should not print warnings when ignoreLintWarnings passed as option"
"should not mark warnings as errors when ignoreLintWarnings passed as option"
"should fix linting errors with tslintAutofix flag set to true"
"should not fix linting by default"

so yes, all linting-related.

But I think I found something far more concerning.
I just copied the files from the test over to a copy of https://github.com/TypeStrong/ts-loader/tree/master/examples/fork-ts-checker-webpack-plugin
In useTypescriptIncrementalApi: true mode I'm not getting any errors even though the files themselves are full of errors.
I'll make a production repo, maybe you can tell me what's going on there...

You can check out this branch.
https://github.com/phryneas/fork-ts-checker-webpack-plugin/tree/reproduce-useTypescriptIncrementalApi-missing-errors
yarn start and yarn build show no errors, even though there is one right in index.ts.
Turning on checkSyntacticErrors finds errors though - but still misses the semantic error in index.ts.

Yup, it's an edge case with the test suite here.
As long as that syntactic error exists there, the ApiIIncrementalChecker bails on that syntactic error. Due to a syntactic error being present, the semantic errors are never found.
And as semantic errors are not being reported per default, fork-ts-checker-webpack-plugin happily reports
No type errors found
No lint errors found

okay cool.  Heart attack over 😄

So having the syntactic error there essentially nullifies all other tests.
Also, this might be highly confusing in production. In this specific case, ts-loader never reports the error in syntacticError.ts because it never is processed by webpack (it is not referenced anywhere), but fork-ts-checker-webpack-plugin thinks ts-loader reported an error and outputs No type errors found.

okay cool. Heart attack over smile

Yup, had the same heart attack until I re-stumbled over this by accident by reading the README xD.
But this is still concerning - the case I described above might really impact real-life projects out there.

Yes - granted. All suggestions to help fix this are welcome 🤗
I'm not certain what the best way forward here is.

Hmm. Off the top of my head, I can think of two things:

even when checkSyntacticErrors === false, instead of emitting No type errors found, emit something like There are semantic errors that block type checking. Please correct the errors in ${fileName} to get type checking again
override typescript.emitFilesAndReportErrors to continue checking after syntactic errors were found. Seeing that this method has been edited multiple times in the past year, that might end up in a cat-and-mouse game and not be a feasible option.
Override program.getSyntacticDiagnostics() to always return an empty array if checkSyntacticErrors === false. I think this might be the way to go.

In the scenario you discuss above I think you're suggesting that ts-loader won't report the  syntactic error and fail the build. Is that right? If so that's disappointing.
Options 1 and 3 sound interesting. Simplicity of use remains a strong motivation of the plugin. I'd be curious to hear you talk through the developer experience of using each.
(Bearing in mind that the typical user of the plugin won't know that there is a distinction between semantic / syntactic errors I'm keen any solution is easy to consume.)
Another thing to add into the mix is the default way people use the plugin. At present, and this is a result of the way the plugin evolved, error checking is curiously split across ts-loader and fork-ts-checker-webpack-plugin. ts-loader does syntactic errors by default, fork-ts-checker-webpack-plugin does semantic by default.
A possible other option is changing the default behaviour so the plugin checks for both types of error. And change the advice in ts-loader to not report errors at all when working with the fork-ts-checker-webpack-plugin. Aka "happypack" mode: https://github.com/TypeStrong/ts-loader/blob/master/README.md#happypackmode-boolean-defaultfalse
If we follow that route we might want to give some more meaningful names for options. 😁
All things to consider. Thanks for your efforts - I dig it 🤗

No, ts-loader will not fail the build, as it is a syntactic error that does not affect the build at all. (It is not directly referenced in webpack and not imported by any file directly referenced by webpack). The build will succeed without any errors.
fork-ts-checker-webpack-plugin on the other hand sees a syntactic error and does not report errors, assuming that the build has failed. After all, fork-ts-checker-webpack-plugin has no way of knowing which files are being processed by webpack and which files aren't.
Leaving the user will a successful compilation and reports of no errors, even though there might be any number of errors actually present :/
From the user's perspective:

The build succeeds, but there is a report of an error that blocks further type checking.
Same behaviour as in useTypescriptIncrementalApi: false - build succeeds, but errors are reported.

From looking into it, #3 might be much more difficult that I thought. That TS code is a f**ing mess :/ But I'll keep investigating.

Cool - what do you think the option of generally steering people to do all type checking with the fork-ts-checker-webpack-plugin? Codewise there's technically nothing to do. They can achieve the same goal right now by using ts-loader with happyPackMode: true and fork-ts-checker-webpack-plugin with checkSyntacticErrors: true.
Obviously having to supply those two options is rubbish. But if we're agreed that it works then a possibility is to do a breaking changes release of fork-ts-checker-webpack-plugin which sets  checkSyntacticErrors: true by default, and introduce a friendlier alias for happyPackMode to ts-loader. (eg noTypeCheck: true)
The options you suggest may well be the better choice, I just want to establish whether this is a potential other option.

I think that's a good option too, but it would need an update to ts-loader and fork-ts-checker-webpack-plugin at the same time through the user, or a change to configuration. I can kind of see that being error-prone :/
As for option 3., I have got that one working.
In service.ts, directly after const typescript: typeof ts = require(process.env.TYPESCRIPT_PATH!);:
const origCreateEmitAndSemanticDiagnosticsBuilderProgram =
  typescript.createEmitAndSemanticDiagnosticsBuilderProgram;

typescript.createEmitAndSemanticDiagnosticsBuilderProgram = (
  ...args: any[]
) => {
  const program = (origCreateEmitAndSemanticDiagnosticsBuilderProgram as any)(
    ...args
  );
  if (process.env.CHECK_SYNTACTIC_ERRORS !== 'true') {
    program.getSyntacticDiagnostics = () => [];
  }
  return program;
};

This makes the ApiIncrementalChecker emit errors even if there is a syntactic error.

Question is: how would you like to go on from here?
While option 3) feels a bit hacky at first sight, it is essentially how #231 would work internally, so this could be a first step in that direction.
If you would be comfortable with that, I could create a PR based of #253 that fixes the tests and implements this workaround.
That should clear all errors for >=2.6. From then, I could investigate the additional vue error we have with 2.5.
Also, I would suggest visiting the travis config.
We should definitely test for older TS versions there. Maybe we could go from the current approach testing every possible combination of webpack/ts-lint/vue-loader/os/node/typescript to a few more picky tests?

While option 3) feels a bit hacky at first sight, it is essentially how #231 would work internally,

And yet you don't want to use proxies? 😉

Question is: how would you like to go on from here?

Great question...
Your plans sound good. I say go for it! Any thoughts @piotr-oles?

While option 3) feels a bit hacky at first sight, it is essentially how #231 would work internally,

And yet you don't want to use proxies? wink

Question is: how would you like to go on from here?

Nah, the proxies are out of there for a while. Actually, while those things are interesting, it's really easy to shoot yourself in the foot with them. Make a change somewhere down the road and you got an infinite loop that's really difficult to debug (especially for future contributors). All that remains is the name of that PR :grin:

The option 3 looks reasonable - as far as I understand we don't make breaking change with that option.
Speaking about moving forward - in my opinion this plugin became hard to maintain. We have to take care about:

IncrementalChecker
ApiIncrementalChecker
TsLint
VueProgram

keeping compatibility with many typescript, webpack and tslint versions. We need to revise the architecture of the plugin. I think version 2 of this plugin should give up IncrementalChecker in favor for ApiIncrementalChecker. Also vue part should be handled in more generic way - that will allow to handle mdx using the same API (and possibly other formats in the future). That's what came to my mind  - I saw promising PRs here but I think we need plan/roadmap 😃

I think we need plan/roadmap

Agreed - if you'd like to open an issue that's probably a good start.  Here's my initial thoughts:

I think version 2 of this plugin should give up IncrementalChecker in favor for ApiIncrementalChecker

If we get to the point where IncrementalChecker can do all of the things ApiIncrementalChecker can then I'm totally sold on that!  That's not where things are now; but hopefully that will happen

Also vue part should be handled in more generic way - that will allow to handle mdx using the same API (and possibly other formats in the future).

Yup - that's what https://github.com/Realytics/fork-ts-checker-webpack-plugin/pull/231 is hopefully going to lead us to.

TsLint

I'm hoping we'll drop TSLint in the future (given it is deprecated) but I'd like us to add support for ESLint if we can.  See more here: https://github.com/Realytics/fork-ts-checker-webpack-plugin/issues/203

keeping compatibility with many typescript, webpack and tslint version

I'd like to think about dropping support for older TypeScript versions.  That's a given anyway if we move to the ApiIncrementalChecker anyway.  If we move to have just that and not the IncrementalChecker then we start with a minimum TypeScript version of 2.9.
All things to consider!
Also, @piotr-oles would you be okay with making @phryneas a collaborator on the plugin?  He's been doing some great work which has really helped us.

Also, @piotr-oles would you be okay with making @phryneas a collaborator on the plugin? He's been doing some great work which has really helped us.

@johnnyreilly I'm honored that you consider that. One thing though, just to get this off my chest: I can't make any guarantees how much time I can/will spend with this project in the future - but if that is okay, you I'd be happy to continue contributing and try to stick around for a while. This is very much fun :)

I can't make any guarantees how much time I can/will spend with this project in the future - but if that is okay, I'd be happy to continue contributing and try to stick around for a while.

It's fine with me - people come and go.  That's to be expected.  But I'm always keen to make the best of people when they have time and energy to spare.  Doing open source well is very much about catching the wind when it blows your way ⛵ 😉

@phryneas Invitation sent - welcome aboard 🚢

I'm just running the tests again for the current 1.2.0-beta.4. Looks promising: https://travis-ci.org/phryneas/fork-ts-checker-webpack-plugin/builds/523703738
From what I see:

from 2.1 on, there is only one non-vue test left failing: "should support custom resolution" - as this was just added recently with #260, maybe @arcanis could take a look if it is possible to get that to work with older TS versions?
vue-specific tests are failing as before. But as we saw already, from version >= 2.3, there is only one of those failing: "should resolve src attribute but not report not found error" - maybe I'll take a look at that one in the next few days.

Fixing these two tests (or potentially, bugs) we would be at "fork-ts-checker-webpack-plugin is compatible with TS 2.1, if you want vue support you need TS 2.3".
I think we could live with that?

I can take a look but not before next week at the earliest. In the meantime maybe they can be skipped? 2.5 is almost two years old 😅

@arcanis no worries, those are not the regular tests :grinning:
I just took a moment and executed the test suite against all TS versions we officialy support at the moment, so it would be great to get that going again - otherwise we'd have to drop support for older TS versions ;)

Frankly I'm happy with us just not supporting < 2.5
We should technically do a breaking change for that (and we likely will in future). But given how old that is, and that no-one is really knocking down our door about this, the pragmatist in me is fine with this. 😁
Interestingly, in ts-loader we have tests that are only executed when we are above a certain version of TypeScript: https://github.com/TypeStrong/ts-loader/tree/master/test/execution-tests
That's also a strategy I am fine with. 😁

Support was re-evaluated in the new alpha release (TypeScript >= 2.7.0 - because of the Watch API). The E2E tests check different versions of TypeScript :)


Blocks production stopped after one of the validators was interrupted

The chain is no longer producing blocks
Description
I'm running a custom PoA chain, block production stopped yesterday and the last produced is 842592. I had only 2 validators left, so I added one more. Currently all 3 validators are stuck in a peer discovery loop if I am to trust the logs, and rounds are not producing blocks. I was running v0.6.2 and upgraded to v0.6.3 after the issue, but didn't solve anything. I stopped all nodes and restarted the validators first, still same issue.
Your environment

OS and version : Ubuntu 22.04.2 LTS and 20.04.5 LTS
The version of the Polygon Edge : v0.6.2
develop
Locally or Cloud hosted (which provider) : Cloud hosted on AWS and GoDaddy
Please confirm if the validators are running under containerized environment (K8s, Docker, etc.) : No

Steps to reproduce

Genesis in PoA mode with 4 validators, remove one validator, then remove a second validator
EIther rounds are failing or stuck in peer discovery
Issue started probably after a validator went down
Provide us with the content of your genesis file : Strandard as far as I see, PoA with 2 seconds block production and epochSize 200
Provide us with commands that you used to start your validators : "/usr/local/bin/polygon-edge server --data-dir /data/--price-limit<PHONE_NUMBER> --nat XX.XX.XX.XX --chain /data/genesis.json --libp2p <IP_ADDRESS>:4546 --prometheus <IP_ADDRESS>:5555 --seal --log-level=DEBUG"
Provide us with the peer list of each of your validators by running the following command: polygon-edge peers list --grpc-address GRPC_ADDRESS.

[PEERS LIST]
Number of peers: 6
[0] = 16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
[1] = 16Uiu2HAmGcRXnrP92SYLh9Xig9CSWQFbyEDWW4GK3RgQhKwkgLU3
[2] = 16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
[3] = 16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
[4] = 16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
[5] = 16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
[0] = 16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
[1] = 16Uiu2HAmGcRXnrP92SYLh9Xig9CSWQFbyEDWW4GK3RgQhKwkgLU3
[2] = 16Uiu2HAmDJAUa6wPyzaykyopTfg4piZLLSEGuY8VnhNCU2Ye1NDD
[3] = 16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
[4] = 16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
[5] = 16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
[0] = 16Uiu2HAmDJAUa6wPyzaykyopTfg4piZLLSEGuY8VnhNCU2Ye1NDD
[1] = 16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
[2] = 16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
[3] = 16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
[4] = 16Uiu2HAmGcRXnrP92SYLh9Xig9CSWQFbyEDWW4GK3RgQhKwkgLU3
[5] = 16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5

Is the chain producing blocks and serving customers atm : no

Expected behavior

Chain should be producing blocks

Logs
Validator1
Feb 27 09:23:53 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:23:53.734Z [DEBUG] polygon.server.dispatcher: request: method=eth_call id=290
Feb 27 09:23:53 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:23:53.735Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":290,"result":"0x"}"
Feb 27 09:23:57 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:23:57.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:23:57 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:23:57.618Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:23:57 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:23:57.637Z [DEBUG] polygon.network.discovery: Found new near peers: peer=4
Feb 27 09:24:02 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:02.618Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:02 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:02.618Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:02 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:02.715Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.609Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":8740634085497617,"jsonrpc":"2.0","method":"net_version","params":[]}"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.609Z [DEBUG] polygon.server.dispatcher: request: method=net_version id="8.740634085497617e+15"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.609Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":8740634085497617,"result":"785"}"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.623Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":8740634085497618,"jsonrpc":"2.0","method":"net_version","params":[]}"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.623Z [DEBUG] polygon.server.dispatcher: request: method=net_version id="8.740634085497618e+15"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.623Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":8740634085497618,"result":"785"}"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.624Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":8336875740635848,"jsonrpc":"2.0","method":"eth_blockNumber","params":[]}"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.624Z [DEBUG] polygon.server.dispatcher: request: method=eth_blockNumber id="8.336875740635848e+15"
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:05.624Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":8336875740635848,"result":"0xcdb60"}"
Feb 27 09:24:06 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:06.570Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":7760874801819427,"jsonrpc":"2.0","method":"eth_blockNumber","params":[]}"
Feb 27 09:24:06 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:06.571Z [DEBUG] polygon.server.dispatcher: request: method=eth_blockNumber id="7.760874801819427e+15"
Feb 27 09:24:06 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:06.571Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":7760874801819427,"result":"0xcdb60"}"
Feb 27 09:24:07 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:07.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:07 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:07.617Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:07 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:07.638Z [DEBUG] polygon.network.discovery: Found new near peers: peer=4
Feb 27 09:24:12 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:12.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:12 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:12.617Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:12 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:12.637Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:17 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:17.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDJAUa6wPyzaykyopTfg4piZLLSEGuY8VnhNCU2Ye1NDD
Feb 27 09:24:17 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:17.617Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDJAUa6wPyzaykyopTfg4piZLLSEGuY8VnhNCU2Ye1NDD
Feb 27 09:24:17 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:17.618Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:22 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:22.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:22 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:22.617Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:22 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:22.731Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.394Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":1,"jsonrpc":"2.0","method":"eth_blockNumber","params":[]}"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.394Z [DEBUG] polygon.server.dispatcher: request: method=eth_blockNumber id=1
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.394Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":1,"result":"0xcdb60"}"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.564Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":3692004125659954,"jsonrpc":"2.0","method":"net_version","params":[]}"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.564Z [DEBUG] polygon.server.dispatcher: request: method=net_version id="3.692004125659954e+15"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.564Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":3692004125659954,"result":"785"}"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.572Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":3692004125659953,"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false]}"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.573Z [DEBUG] polygon.server.dispatcher: request: method=eth_getBlockByNumber id="3.692004125659953e+15"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.573Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":3692004125659953,"result":{"parentHash":"0x703a6b1edb327f041db0f5709afdf3fa2ea7980a9aa79b4ed3428e203852f18d","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","miner":"0x0000000000000000000000000000000000000000","stateRoot":"0xd55d9dafd84d84ce2e6108bd4e343c43d354710b7f4362d110518ee3457792ba","transactionsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","difficulty":"0xcdb60","totalDifficulty":"0xcdb60","size":"0x40e","number":"0xcdb60","gasLimit":"0x500000","gasUsed":"0x0","timestamp":"0x63fb9dda","extraData":"0x0000000000000000000000000000000000000000000000000000000000000000f901e7f8d8f846947cf073719b93b022525b7c3e1ad6131a4493ae3db093947b6211ff3c576907e259306a7400c05258ebedd5b853926a00dce46be327e453214eb376bc5f532b5943659db140f84694c0814f021206d4dc0ce4d16ea783d99046331600b0af0cc3e7b6a757854ea8f1cb1ac35dd71f6f2a3e3dfd840947d9ebff3ee0cdefb66cdc9504f4912045a30e20d1234622f84694725be146c57499ff58b85934850b3afda4f0e8a3b0a0c00d61a7f087acc4a0c70229c64a0bc48187fd52cd142814312fe3b3ddd1975c2e0d4265435eec6c68bf6518c91673b8410efb62916785353b0b9cf2621c2e78e8e6950311b9edaafdfa233d52826affa331805abfe786812010af31017cc884835d2531dbe55543a0239b3c941878546800f86307b860b56d1f8b073d060fb5b474265d3d0d78972f1c34084d7f5f7e73b5be69bab3a16d093197f8230a80ee623e681d4e37c819415e30399725492c84ee83bc68113021d8457fd0861c7c85d977b20247f6686ae86f3416ba19446d2cc5af627e3134f86307b860b7a17316c6382f9607b51344a3082037dffbcff34a5391445d3f7bd44cdb04a8617981870d8ee034fbed740fa695587b0f7b8e428b8acbc751bdfe044791bbf813f2c5aac9535107cb4f9745ec0aacd017458e7575d0c6e59eb85e14cdc243ac","mixHash":"0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365","nonce":"0x0000000000000000","hash":"0xade7f72ffba097c48f61b619b0394fe0ec15d29fdb2aeff290f100f0b3f5b33f","transactions":[],"uncles":[]}}"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.602Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":7760874801819428,"jsonrpc":"2.0","method":"eth_blockNumber","params":[]}"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.602Z [DEBUG] polygon.server.dispatcher: request: method=eth_blockNumber id="7.760874801819428e+15"
Feb 27 09:24:26 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:26.602Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":7760874801819428,"result":"0xcdb60"}"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.102Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":6676869508046206,"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xcdb60",false]}"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.102Z [DEBUG] polygon.server.dispatcher: request: method=eth_getBlockByNumber id="6.676869508046206e+15"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.102Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":6676869508046206,"result":{"parentHash":"0x703a6b1edb327f041db0f5709afdf3fa2ea7980a9aa79b4ed3428e203852f18d","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","miner":"0x0000000000000000000000000000000000000000","stateRoot":"0xd55d9dafd84d84ce2e6108bd4e343c43d354710b7f4362d110518ee3457792ba","transactionsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","difficulty":"0xcdb60","totalDifficulty":"0xcdb60","size":"0x40e","number":"0xcdb60","gasLimit":"0x500000","gasUsed":"0x0","timestamp":"0x63fb9dda","extraData":"0x0000000000000000000000000000000000000000000000000000000000000000f901e7f8d8f846947cf073719b93b022525b7c3e1ad6131a4493ae3db093947b6211ff3c576907e259306a7400c05258ebedd5b853926a00dce46be327e453214eb376bc5f532b5943659db140f84694c0814f021206d4dc0ce4d16ea783d99046331600b0af0cc3e7b6a757854ea8f1cb1ac35dd71f6f2a3e3dfd840947d9ebff3ee0cdefb66cdc9504f4912045a30e20d1234622f84694725be146c57499ff58b85934850b3afda4f0e8a3b0a0c00d61a7f087acc4a0c70229c64a0bc48187fd52cd142814312fe3b3ddd1975c2e0d4265435eec6c68bf6518c91673b8410efb62916785353b0b9cf2621c2e78e8e6950311b9edaafdfa233d52826affa331805abfe786812010af31017cc884835d2531dbe55543a0239b3c941878546800f86307b860b56d1f8b073d060fb5b474265d3d0d78972f1c34084d7f5f7e73b5be69bab3a16d093197f8230a80ee623e681d4e37c819415e30399725492c84ee83bc68113021d8457fd0861c7c85d977b20247f6686ae86f3416ba19446d2cc5af627e3134f86307b860b7a17316c6382f9607b51344a3082037dffbcff34a5391445d3f7bd44cdb04a8617981870d8ee034fbed740fa695587b0f7b8e428b8acbc751bdfe044791bbf813f2c5aac9535107cb4f9745ec0aacd017458e7575d0c6e59eb85e14cdc243ac","mixHash":"0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365","nonce":"0x0000000000000000","hash":"0xade7f72ffba097c48f61b619b0394fe0ec15d29fdb2aeff290f100f0b3f5b33f","transactions":[],"uncles":[]}}"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.250Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":3692004125659955,"jsonrpc":"2.0","method":"eth_getBalance","params":["0x2D296A4F26E3c8885D59128816EE7567154bfd1B","latest"]}"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.250Z [DEBUG] polygon.server.dispatcher: request: method=eth_getBalance id="3.692004125659955e+15"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.250Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":3692004125659955,"result":"0x490c51aea396de00000"}"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.357Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":330,"jsonrpc":"2.0","method":"eth_chainId","params":[]}"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.357Z [DEBUG] polygon.server.dispatcher: request: method=eth_chainId id=330
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.358Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":330,"result":"0x311"}"
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDJAUa6wPyzaykyopTfg4piZLLSEGuY8VnhNCU2Ye1NDD
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.617Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDJAUa6wPyzaykyopTfg4piZLLSEGuY8VnhNCU2Ye1NDD
Feb 27 09:24:27 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:27.618Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:32 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:32.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:32 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:32.618Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:32 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:32.728Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:33 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:33.448Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":338,"jsonrpc":"2.0","method":"eth_chainId","params":[]}"
Feb 27 09:24:33 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:33.448Z [DEBUG] polygon.server.dispatcher: request: method=eth_chainId id=338
Feb 27 09:24:33 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:33.448Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":338,"result":"0x311"}"
Feb 27 09:24:33 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:33.607Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":339,"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000001112","data":"0x70a082310000000000000000000000002d296a4f26e3c8885d59128816ee7567154bfd1b"},"latest"]}"
Feb 27 09:24:33 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:33.607Z [DEBUG] polygon.server.dispatcher: request: method=eth_call id=339
Feb 27 09:24:33 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:33.608Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":339,"result":"0x00000000000000000000000000000000000000000025995fd40f371deff50000"}"
Feb 27 09:24:37 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:37.617Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:24:37 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:37.617Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:24:37 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:37.707Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:38 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:38.733Z [DEBUG] polygon.server.jsonrpc: handle: request="{"id":1,"jsonrpc":"2.0","method":"eth_blockNumber","params":[]}"
Feb 27 09:24:38 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:38.733Z [DEBUG] polygon.server.dispatcher: request: method=eth_blockNumber id=1
Feb 27 09:24:38 <IP_ADDRESS>.host.secureserver.net nxchain[1263260]: 2023-02-27T09:24:38.733Z [DEBUG] polygon.server.jsonrpc: handle: response="{"jsonrpc":"2.0","id":1,"result":"0xcdb60"}"
Validator 2
Feb 27 09:23:44 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:44.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmGcRXnrP92SYLh9Xig9CSWQFbyEDWW4GK3RgQhKwkgLU3
Feb 27 09:23:44 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:44.954Z [DEBUG] polygon.network.discovery: Found new near peers: peer=4
Feb 27 09:23:49 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:49.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:23:49 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:49.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:23:49 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:49.928Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:23:54 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:54.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:23:54 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:54.928Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:23:55 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:55.026Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:23:59 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:59.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:23:59 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:23:59.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:00 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:00.026Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:04 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:04.926Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:04 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:04.926Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:05 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:05.025Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:09 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:09.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:09 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:09.928Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:09 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:09.948Z [DEBUG] polygon.network.discovery: Found new near peers: peer=4
Feb 27 09:24:14 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:14.926Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:24:14 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:14.926Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:24:14 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:14.927Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:19 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:19.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:24:19 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:19.928Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:24:20 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:20.018Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:24 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:24.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:24 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:24.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:25 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:25.025Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:29 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:29.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:29 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:29.928Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRnoVBhqC6WHv18gfXZBc5FzFzKZvkR4T6FTznqQzgaPF
Feb 27 09:24:30 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:30.031Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:34 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:34.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:34 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:34.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:35 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:35.026Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:39 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:39.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:39 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:39.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:24:40 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:40.025Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:44 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:44.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:44 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:44.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:44 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:44.946Z [DEBUG] polygon.network.discovery: Found new near peers: peer=4
Feb 27 09:24:49 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:49.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:49 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:49.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:49 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:49.947Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:54 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:54.926Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:24:54 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:54.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:24:54 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:54.928Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:24:59 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:59.926Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:59 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:59.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAm27gFELHhBfzXRQsfGFCspFqjd73o95sGNPvEEMofZsYs
Feb 27 09:24:59 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:24:59.946Z [DEBUG] polygon.network.discovery: Found new near peers: peer=4
Feb 27 09:25:04 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:04.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:25:04 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:04.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:25:05 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:05.018Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:25:09 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:09.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmGcRXnrP92SYLh9Xig9CSWQFbyEDWW4GK3RgQhKwkgLU3
Feb 27 09:25:09 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:09.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmGcRXnrP92SYLh9Xig9CSWQFbyEDWW4GK3RgQhKwkgLU3
Feb 27 09:25:09 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:09.948Z [DEBUG] polygon.network.discovery: Found new near peers: peer=4
Feb 27 09:25:14 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:14.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:25:14 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:14.928Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:25:14 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:14.928Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:25:19 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:19.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:25:19 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:19.928Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:25:20 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:20.018Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:25:24 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:24.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:25:24 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:24.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmRCZiu3QPJVYhpgAmL6VwPwTq7bqaVwfd8bY1jG5Hvrh5
Feb 27 09:25:25 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:25.017Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:25:29 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:29.926Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:25:29 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:29.926Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAmDL1TYHNZkZD1VksNAaaoRshxnkCWA71k4GJNEhwjUGXi
Feb 27 09:25:30 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:30.047Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Feb 27 09:25:34 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:34.927Z [DEBUG] polygon.network.discovery: running regular peer discovery: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:25:34 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:34.927Z [DEBUG] polygon.network.discovery: Querying a peer for near peers: peer=16Uiu2HAkz39K426x5rDwsr8jVTL7uvQDonzyz6RR4iZGzvXdtdFe
Feb 27 09:25:34 <IP_ADDRESS>.host.secureserver.net nxchain[1526091]: 2023-02-27T09:25:34.928Z [DEBUG] polygon.network.discovery: Found new near peers: peer=5
Validator 3
Too many RPC requests currently, hard to read logs
Proposed solution
None yet

Here are the last logs from the dead validator

And here are the logs at the same moment from another validator

Maybe it's possible to restore to a previous block, as it appears that 842593 is the one the validators can't build

Resolved after relaunching the 3rd validator. There is a minimal amount of 3 validators out of 4 functionning apparently to reach quorum. After adding more validators and killing off the 3rd validator again, the chain kept working


Formatting is incorrect in graph section of website

Numbers should be formatted. Most are scaled by decimals. Performance fee and management fee is a percent out of 1,000.
X-axis is in block number when should be date/time.
Sizing doesn't fit correctly on my screen.
Timeframe default should be 1 week not 1 month.

Not currently featured on website anymore


add ALU support to device-manger

Add ALU (Alcatel Lucent) Support to Device-Manager
Affected Files:
contrail-controller/src/config/device-manager/device_manager/physical_router_config.py

requires patched ncclient with ALU support
https://github.com/GIC-de/ncclient


Cannot evaluate models on MATH: TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

Perhaps this is a user error on my part, but I am having trouble evaluating models on the math:xxx subsets, e.g. this command
accelerate launch --multi_gpu --num_processes=8 run_evals_accelerate.py \
    --tasks="lighteval|math:algebra|5|0" \
    --output_dir "./scratch/evals" \
    --model_args "pretrained=Qwen/Qwen1.5-0.5B" \
    --override_batch_size 1

throws the following error:
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'
    main(args)
  File "/fsx/lewis/git/hf/lighteval/src/lighteval/logging/hierarchical_logger.py", line 144, in wrapper
    return fn(*args, **kwargs)
  File "/fsx/lewis/git/hf/lighteval/src/lighteval/main_accelerate.py", line 91, in main
    evaluation_tracker = evaluate(
  File "/fsx/lewis/git/hf/lighteval/src/lighteval/evaluator.py", line 64, in evaluate
    full_resps = lm.greedy_until(requests, override_bs=override_bs)
  File "/fsx/lewis/git/hf/lighteval/src/lighteval/models/base_model.py", line 346, in greedy_until
    dataset = GenerativeTaskDataset(requests=requests, dataset_splits=self.DATASET_SPLITS)
  File "/fsx/lewis/git/hf/lighteval/src/lighteval/data.py", line 44, in __init__
    sorted_enumerated_requests = sorted(enumerated_requests, key=lambda x: self._sorting_criteria(x[1]))
  File "/fsx/lewis/git/hf/lighteval/src/lighteval/data.py", line 44, in <lambda>
    sorted_enumerated_requests = sorted(enumerated_requests, key=lambda x: self._sorting_criteria(x[1]))
  File "/fsx/lewis/git/hf/lighteval/src/lighteval/data.py", line 198, in _sorting_criteria
    return -(len(toks) + gen_length)
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

I think it comes from the task definition, this looks like the max gen length was left to None for the task or stg similar, I'll take a look

Can you close this then ?

Argh it should have been automatically closed! Yep, doing it rn


Add a request id field in messages

Hi @grunch @bilthon ,
as requested from @bilthon as enhancement for clients I have added a very simple request_id in messages that will echo the received one from client messages.
I understood that this thing is useful for clients so I want to refactor code with a more clear implementation.
Now I extract from incoming message the field and propagate it in all actions, but in some cases i put an option in the field, for example if there is a resubscribe action of an invoice at mostro startup i cannot add it because i did not receive a message from the client, the are some other cases like that, typically in invoices management.
Now I ask you if we need this  new field also in these case? @bilthon drop me your ideas of the messages where the echo is needed.
I have in mind two ways to improve this:

Add an atomic static variable, so I can use it everywhere easily, but still usable no for all messages.
Add a db field so we can still have this number available.

Drop me your ideas here...

Closed via #376

Closed via #376

closing it via #376


wr.s3.to_parquet() exception

When calling

wr.s3.to_parquet(
df = taxi,
path = 's3://{}/{}'.format(bucket_str, 'cooked/'),
dataset = True,
database="nyc-tlc-project-database",
table="nyc-tlc-project-dataset"
)

I am getting this exception:

AttributeError                            Traceback (most recent call last)
 in
4     dataset = True,
5     database="nyc-tlc-project-database",
----> 6     table="nyc-tlc-project-dataset"
7 )
~/anaconda3/envs/python3/lib/python3.6/site-packages/awswrangler/s3/_write.py in to_parquet(df, path, index, compression, use_threads, boto3_session, s3_additional_kwargs, sanitize_columns, dataset, partition_cols, mode, catalog_versioning, database, table, dtype, description, parameters, columns_comments, regular_partitions, projection_enabled, projection_types, projection_ranges, projection_values, projection_intervals, projection_digits)
834     session: boto3.Session = _utils.ensure_session(session=boto3_session)
835     cpus: int = _utils.ensure_cpu_count(use_threads=use_threads)
--> 836     fs: s3fs.S3FileSystem = _utils.get_fs(session=session, s3_additional_kwargs=s3_additional_kwargs)
837     compression_ext: Optional[str] = _COMPRESSION_2_EXT.get(compression, None)
838     if compression_ext is None:
~/anaconda3/envs/python3/lib/python3.6/site-packages/awswrangler/_utils.py in get_fs(session, s3_additional_kwargs)
183         s3_additional_kwargs=s3_additional_kwargs,
184         use_listings_cache=False,
--> 185         skip_instance_cache=True,
186     )
187     fs.invalidate_cache()
~/anaconda3/envs/python3/lib/python3.6/site-packages/fsspec/spec.py in call(cls, *args, **kwargs)
52             return cls._cache[token]
53         else:
---> 54             obj = super().call(*args, **kwargs)
55             # Setting _fs_token here causes some static linters to complain.
56             obj.fs_token = token
~/anaconda3/envs/python3/lib/python3.6/site-packages/s3fs/core.py in init(self, anon, key, secret, token, use_ssl, client_kwargs, requester_pays, default_block_size, default_fill_cache, default_cache_type, version_aware, config_kwargs, s3_additional_kwargs, session, username, password, **kwargs)
169         self.kwargs = kwargs
170         super_kwargs = {k: kwargs.pop(k)
--> 171                         for k in ['use_listings_cache', 'listings_expiry_time', 'max_paths']
172                         if k in kwargs}  # passed to fsspec superclass
173
~/anaconda3/envs/python3/lib/python3.6/site-packages/s3fs/core.py in connect(self, refresh)
227     def split_path(self, path) -> Tuple[str, str, Optional[str]]:
228         """
--> 229         Normalise S3 path string into bucket and key.
230
231         Parameters
AttributeError: 'Session' object has no attribute 'client'

I noticed a similar error here, but I couldn't resolve my issue there.
To reproduce, I am using:
python 3.6.10
awswrangler version 1.5.0
boto3 version 1.14.5
I also get the same error trying wr.s3.to_csv().
I've also tried using the developer version of awswrangler, but without luck.

Thanks for reach out to us @kevinhpinkerton.
Could you also check the s3fs version, please?

My s3fs version is 0.4.0.
And I installed wrangler in my SageMaker notebook using import sys  !{sys.executable} -m pip install awswrangler

@kevinhpinkerton the problem is there, it is a common bug on s3fs version 0.4.0. Thats why Wrangler requires at least version 0.4.2.
Did you try to restart the kernel after the installation command? Sometimes the kernel get confused about dependency versions on "on going" installations.

Closing due to inactivity.


Restructure docs ToC to be task-oriented, and to better fit reader personas

@awoods187 and I discussed making some larger changes to the ToC, to better guide readers, loosely based on tasks and reader personas.

Get Started

Overview
Install Cockroach
etc.
Tutorials
Troubleshoot

Develop

Overview
Languages
3rd-party Tools
Debug
Tutorials
Best Practices

Deploy

Overview
Topology Patterns
etc.
Tutorials
Troubleshoot

Administer

Overview
Set Permissions
etc.
Tutorials
Troubleshoot

Migrate

Overview
Migrate from ...
etc.
Tutorials
Troubleshoot

Reference

Overview
CLI
SQL
etc.

Learn

Architecture
etc.

FAQ
Releases

This is very much a WIP issue, open for discussion.

I'm excited for this work! Happy to help however I can.

Nice, @ericharmeling. Really like this experiment. Feel free to prototype in a PR.

One thing I didn't share when we discussed in our team meeting: I think each top-level section should be heavily task-oriented. So in addition an overview and tutorials, the majority of topics should be , . Similar to how Get Started currently works: Install CockroachDB, Start a Local Cluster, Learn CockroachDB SQL, etc.
For the Develop section in particular, which is a particular focus for Q4/Q1, this is a crucial aspect. Topics like Query Data, Filter and Sort Data, Paginate Results, Insert Data, etc.

+1 @jseldess I think a good framing question is: "how do I do X?"

Long-term, the task-based topics can also offer language variations, to be really dev friendly: https://rethinkdb.com/docs/cookbook/python/

Closing this in favor of the docs UX redesign project being lead by @luciaaa and @lnhsingh.


Gh 1260 road example

Codecov Report

Merging #1323 into develop will decrease coverage by <.01%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             develop    #1323      +/-   ##
=============================================
- Coverage      65.36%   65.35%   -0.01%
  Complexity      1537     1537
=============================================
  Files            690      690
  Lines          22005    22006       +1
  Branches        2733     2734       +1
=============================================
  Hits           14383    14383
  Misses          6502     6502
- Partials        1120     1121       +1

Impacted Files
Coverage Δ
Complexity Δ

...eration/handler/impl/FederatedAddGraphHandler.java
86.66% <0%> (-6.2%)
0% <0%> (ø)

Continue to review full report at Codecov.

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


Not showing my seo from model, but from defaults

I'm sorry to bother you, I've read the docs again and again... but I can't get  {!! (seo($page ?? null)) !!} to show the SEO stored by the seo model...
Is there something I'm missing?
Dumping the seo call at blade {!! dd(seo($page ?? null)) !!}, I get this:
RalphJSmit\Laravel\SEO\TagManager {#2555 ▼ // resources/views/layouts/app.blade.php
  +model: ? Illuminate\Database\Eloquent\Model
  +SEOData: ? RalphJSmit\Laravel\SEO\Support\SEOData
  +tags:
RalphJSmit\Laravel\SEO
\
TagCollection {#2036 ▼
    #items: array:6 [▶]
    #escapeWhenCastingToString: false
  }
}

with results in defaults for seo:

BUT in my controller (PostController) I check the SEO for my post:
    $seo = $post->seo;
    dump($seo->toArray());

I get the correct data:
array:11 [▼ // app/Http/Controllers/PostController.php:15
  "id" => 1
  "model_type" => "App\Models\Post"
  "model_id" => 1
  "description" => "The best description is one that incites the imagination."
  "title" => "Manually set SEO Title at creation/update (test)!!"
  "image" => null
  "author" => "Cyrus Frank"
  "robots" => null
  "canonical_url" => null
  "created_at" => "2024-05-04T08:57:57.000000Z"
  "updated_at" => "2024-05-04T09:50:39.000000Z"
]

How can I get {!! seo() !!} to use the current stored seo data of my post?
Thanks a lot (in advance) :)

Hi @ADezon! It seems like the variable $page ?? null is undefined, and then it falls back to null using the ?? null.
Could it be that you need to use the variable $post perhaps?
Can you try to dd($page) and dd($post)?

OMG!! you are right!!
And of course it works!!
And I feel so dummy!!
Thanks 4 replying this 🤦🏻♂!
I'm using filment extension too!
Great work!!


refactor: 💡 Move generated TxTags to generated/types.ts

Description

Merged the scripts generateTxTags and generateCountryCodes into a single script - generateConsts. This now generates TxTags in src/generated/types.ts.
Refactored all files to use TxTag, TxTags, ModuleName from ~/types instead of polymesh-types/types

JIRA Link
DA-239
Checklist

[ ] Updated the Readme.md (if required) ?

:tada: This PR is included in version 15.0.0-alpha.4 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 15.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Feature/gltfio header refactor for ResourceLoader and AssetLoader

These changes make both ResourceLoader and AssetLoader more inline to the code design of other classes such as FilamentAsset, which uses an internal struct FBarClass that derives from the public regular BarClass and has that in a separate header in the src folder. Current functionality should remain intact, with functions being declared in these FClass headers. The Impl struct was removed from ResourceLoader and its (Impl) functions where put into FResourceLoader. Projects that where working before on Android and Windows where tested.
Why are these changes important? I believe it brings some consistency to these objects that we see in all other objects. It also makes it easier (than before) to extend gltf loading and usage of additional extensions. While ideally I would like to have complete access (putting these headers in the include path) to FFilamentAsset, FAssetLoader, and FResourceLoader, and deriving from those into custom classes for handling additional gltf extensions. I can still work around it by using forward declarations and namespace functions. This would also have the benefit of not intermingling the additional extension code with what’s already in the gltfio library.
I’m open to other suggestions for accomplishing this.

Thanks. Could you explain a bit more the reasons for this change? Consistency, while nice, is not always necessary. The design of Foo classes and FFoo implementations exists mostly to hide away internals and preserve binary compatibility as much as possible (and to avoid STL types in our public headers). Is this what you are trying to achieve here?

I would be interested in learning how you'd like to extend the library.  If you need to process a custom glTF extension, you can look at the raw cgltf data using getSourceAsset(), then create your own Filament primitives accordingly.

@romainguy @prideout Thank you for taking the time to look at this PR and for replying.
Currently I’ve added custom gltf extensions that are parsed through cgltf, with custom object members kept in FFilamentAsset, and loaded with both Asset and Resource loaders. For example, apng & video textures, node triggers for events, and other effects that are defined in the gltf file. This code is intertwined and prone to merge conflicts making it hard to manage. My intention is to extend / derive from these 3 internal classes, where the custom changes would live without affecting any of the original Filament code.
I understand why there are internal FFoo implementations that derive from interface Foo classes, although this make extending a little tricky but not impossible if I can access the FFoo from a header, even if it’s in the src directory. My intention is not to completely change the design, but use precedence for a design pattern already being used in gltfio.
The way I would extend these objects is by deriving from the FFoo struct with MyFFoo struct and using a series of public functions that would call the hidden MyFoo. So far I've done this on Windows with the gltf_viewer project without issues. It's a bit of extra hoops to jump through but it should keep those headers in the scr without moving them to include.
For instance the idea is,
JNI <- FilamentAsset <- FFilamentAsset -> MyFilamentAsset -> Interface_MyFilamentAsset -> MyJNI
public header       private header       private header            public header functions
fwd declaration MyFilamentAsset
The catch here is that I must do this for ResourceLoader and AssetLoader. It's not pretty but should work without changing much in Filament.

Thanks for the clarification. Just to be clear any FFoo class/struct in Filament is private APIs and may (will) break at any time as we make changes.

Thanks for the clarification. Just to be clear any FFoo class/struct in Filament is private APIs and may (will) break at any time as we make changes.

That is fine and if I implement things on my end correctly, there should be no issues when these changes do occur.

@prideout @romainguy I was trying out getSourceAsset() pulling the cgltf_data to create the extension objects. It should take care of all of my current use cases, haven't converted everything but looks promising. I'll continue with this and if everything works out, I'll close this PR or report back if there was an issue. Thank you for the help.

Closing this PR. See my previous comment.


GH-44480: [Release][Packaging] Use --platform explicitly for docker run

Rationale for this change
It seems that recent Docker requires --platform to run different architecture images with QEMU.
What changes are included in this PR?
Use --platform explicitly.
Are these changes tested?
Yes.
Are there any user-facing changes?
No.

GitHub Issue: #44480

@github-actions crossbow submit verify-rc-binaries-apt-* verify-rc-binaries-yum-* --param release=18.0.0 --param rc=0

+1


Accuracy on LFW

In the article http://krasserm.github.io/2018/02/07/deep-face-recognition/ @krasserm said that the accuracy on LFW is 95.7%.
But on the LFW official site (http://vis-www.cs.umass.edu/lfw/results.html#ImageRestrictedLF) is said that the accuracy with FaceNet is 0.9963%.
My question is: the difference between the two results could depend on the specific implementation of the Model, or it could depend on the fact that here we're testing on a small subset of the LFW?

The model used in the blog post (nn4.small2) is a much smaller model than the top-performing model in the FaceNet paper. The accuracy of nn4.small2 on the LFW benchmark is  93.0%. One reason for the difference to 95.7% is indeed the smaller LFW subset used in the blog post.

Thank you @krasserm!
Apart from this clarification, your blog post helped me a lot.


Have hex addresses all lower-case

This one upper-case character in the hex address in this example prevents automated tests being performed after encoding/decoding (where case is lost).

That looks like an EIP-55 checksummed execution address.  Not sure that lower-casing it in this instance would be considered a fix, could you include EIP-55 encoding for execution addresses in the automated tests?

According to this site it's not proper EIP-55 encoding (assuming this site is correct). Looks more like a typo to me. Also I have not seen others address being checksummed.
And does it make sense at all to have hex with upper-case produced by the API? My (limited) understanding is that it does not in this scenario.

There are very few execution addresses in the beacon API, this may even be the only place where one is present.
Having the API output execution addresses in checksummed format would be good practice.  It isn't mandated anywhere in this API, so down to individual implementations to implement (or not).
If there is a change to be made, I'd prefer to see any and all instances of execution addresses using checksum format in the specification, but it's only a mild preference given how frequently APIs don't bother outputting checksummed addresses.

It does look like the encoding is invalid according to EIP-55, correct would be 0x9Be8d619c56699667c1feDCD15f6b14D8B067F72 but even if it was valid I think it still does make sense to use all lower-case.

Consensus / beacon API do not use any EIP-55 encoded addresses (e.g. ExecutionAddress, added in #178)
BLSToExecutionChange is part of the consensus spec and the SSZ type for to_execution_address uses Bytes20, there is no special type for execution address
The events API is a bit of an outlier were the examples are used as "schema" due to OpenAPI limitations https://github.com/OAI/OpenAPI-Specification/issues/396
(EIP-55 encoding seems more useful for user facing applications like wallets / explorers)

As I doubt any consensus client implements EIP-55 encoding for execution addresses, it might be better to use all lower-case to maintain consistency and avoid misleading assumptions for API consumers.

I realize that I'm likely fighting a losing battle here, but IMO API's should absolutely state that execution addresses should be output in EIP-55 format.  It's incredibly cheap to do, and shows best practice.  It also allows cut and paste of addresses directly from the output of the API into systems that expect checksummed addresses.
The more systems that use EIP-55 for addresses the more that others will do so for compatibility as well as recognizing best practice.  Even if it's optional and not implemented in consensus clients, it would be good to have it in the spec.

I realize that I'm likely fighting a losing battle here

I am not really opposed to this, just stated the status quo. You have more experience in the usefulness of this (building cli tooling that consumes APIs) and we should probably push for a standard encoding as this improves spec consistency and allows for easier testing against spec values as all example addresses in the API spec would then have to use ERC-55 format. I don't really see this as part of consensus spec though.

https://github.com/ethereum/beacon-APIs/pull/396

@mcdee your point makes sense, and I feel like it's reasonable to address the EIP-55support as a separate issue as @nflaig did.
The current PR fixes what looks like a typo, as currently the execution address is not in EIP-55 format. As a first step towards improved data format I suggest to have every addresses in lower-case.

As I doubt any consensus client implements EIP-55 encoding for execution addresses, it might be better to use all lower-case to maintain consistency and avoid misleading assumptions for API consumers.

I'm 99% sure teku is using EIP-55 encoding...

I'm 99% sure teku is using EIP-55 encoding...

Looks like you do, there is a custom ssz type that extends bytes20
Eth1Address.java
public class Eth1Address extends Bytes20 {

Something we could  easily adopt in Lodestar as well

I think this has been superceded by ERC-55 mixed-case addresses... ok to close?

Good point!


WIP: level zero & spv translator build integration

Hi,
I was able to modify mapd-deps for ubuntu from-source build to include spirv translator in-tree llvm-10 build (static linkage only). There're 2 simple tests that show components work properly that pass for me. Notice that I had to link the spv test with thrift handler for some reason - otherwise getting linking issue:
/home/petr/code/offloading/omniscidb/ThriftHandler/QueryState.cpp:51: error: undefined reference to 'Catalog_Namespace::UserMetadata::userLoggable[abi:cxx11]() const'
/home/petr/code/offloading/omniscidb/ThriftHandler/QueryState.cpp:164: error: undefined reference to 'Catalog_Namespace::UserMetadata::userLoggable[abi:cxx11]() const'

FindLevelZero is taken from here (there's no single source for that for now, so just copying): https://github.com/oneapi-src/level-zero-tests/blob/master/cmake/FindLevelZero.cmake

Level zero build is under an option:
cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_L0=ON -DCMAKE_EXE_LINKER_FLAGS=-fuse-ld=gold -DENABLE_AWS_S3=off
Works along with cuda.

These changes will go along with others in another pr


ISE on exclusive constraint

EdgeDB Version: 3.0-dev.7343+4d0b071
EdgeDB CLI Version: 3.0.0-dev.941+730fc35
OS Version: ubuntu 22.04

Steps to Reproduce:
$ edgedb migration create
Created dbschema/migrations/00001.edgeql, id: m14qm75zdaubqhctniawlfnnr6vd4weqtqduxuenhpclnxjvzavvba

$ edgedb migration apply
edgedb error: InternalServerError: functions in index expression must be marked IMMUTABLE
  Hint: This is most likely a bug in EdgeDB. Please consider opening an issue ticket at https://github.com/edgedb/edgedb/issues/new?template=bug_report.md
  Server traceback:
      edb.errors.InternalServerError: functions in index expression must be marked IMMUTABLE

Schema:
module default {
  scalar type Status extending enum<'Active', 'Inactive'>;
  type Foo {
    required property ip -> str;
    required property status -> Status;
    constraint exclusive on ((.ip, <str>.status = 'Active'));
  }
}

We fixed some stuff related to this in #4775 but there is more to do apparently.
(I think as a workaround, doing the cast in the other way should work now?)


Feature Testing using playwright round 2 part I: clean fixtures site

We have playwright working, we just aren't testing very much with it ...
Acceptance

[x] e2e tests with playright are testing stuff again that is in templates/default and not in the app ✅2022-09-20 see commit https://github.com/flowershow/flowershow/commit/b7ca935ce9b19ca7c0aa599270483de82ff03289 and see running build with new test setup https://github.com/flowershow/flowershow/actions/runs/3089822372/jobs/4997867883

Tasks

[x] Where do put our markdown fixtures for testing? ✅2022-09-14 templates/default/tests/fixtures

In site/content/tests` ** very ugly and bad smell**
In templates/default/test/fixtures? Problem: how do they get rendered? ✅2022-09-14 Ans: github workflow that deletes content (and assets) symlink and replaces it with symlink to fixtures and then runs stuff ...

[x] Create one test and fixture
[x] update npm test to do this symlinking automatically (?) or even better do it one-off test setup (and teardown - so you don't break your local system)
[x] Update github workflow (if needed)

FIXED. All working.


Mod not working

When i try opening the Monke Map Loader or Monke Map Hub, nothing appers

Yeah CI is Broken and will never be fixed Which Means MML will never work unless someone makes it Compatible with Computer++


[incubator/cassandra] Cassandra backup job can't be installed in k8s 1.13

Describe the bug
We recently updated our EKS kubernetes cluster to k8s 1.13. We have our own fork of the cassandra helm chart here, but we were seeing a problem upon installation. We tried installing the incubator one, but we were seeing the same issue. The backup job does not want to install due to validation error with PodTemplateSpec
Version of Helm and Kubernetes:
Kubernetes 1.13 on EKS
Helm 2.14 client and tiller versions
Which chart:
incubator/cassandra
What happened:
After cluster upgrade, the incubator chart throws an error when trying to validate the backup cronjob
Error: validation failed: error validating "": error validating data: ValidationError(CronJob.spec.jobTemplate.spec.template): unknown field "affinity" in io.k8s.api.core.v1.PodTemplateSpec
What you expected to happen:
The chart is installed without issues.
How to reproduce it (as minimally and precisely as possible):

Have a kubernetes cluster at version 1.13 (this was done in an EKS cluster)

Have helm 2.14 client and server versions

Run the following:
helm install --namespace "cassandra-test" -n "cassandra-test" incubator/cassandra -f override.yaml
Where override.yaml contains:

backup:
  enabled: true
  google: {}

Anything else we need to know:

Upon further investigation, it seems that this is a problem with helm 2.14.0. Updating to 2.14.1 or 2.14.2 fixes the problem. I'll close this issue.


[Slides]: Double-Check Exercises/Solutions

[x] ensure that we present solutions to all exercises in the slides such that the participants that did not finish the exercise can copy them.

As discussed, seems to be resolved due to refactorings


Prop for disabling scrolling of thumbnails

I've added a prop called "disableScrolling" that will disable scrolling of the thumbnails. In my case, I have a CSS that layouts the thumbnails in multiple lines and no scrolling is required.
I've also added some missing parentheses.

I rebased and removed bind()


missing sdist for 2.7.1 release on pypi

👋 looks like sdist is missed for the latest release on pypi, raise an issue for awareness. Thanks!

I'm looking into it - the initial upload to Pypi had issues and now I'm having trouble redeploying since the binary distribution is already there.

why not just create a new release? like 2.7.2?

any update on this thread?
relates to https://github.com/Homebrew/homebrew-core/pull/139795

v2.7.2 with source was just released


Display sources

Sources need to diplay on project (and other entity) sites.
Display both source name, type, year, etc. as in input tables.

Ive got source tables on the project detail and concession detail page. @KseniyaKuprina can you throw these on the rest of the entity pages?


Crash when loading into a game with the mod in 1.1.87

The mod Item Cam (0.0.1) caused a non-recoverable error.
Please report this error to the mod author.
Error while running event itemcam::on_configuration_changed
Only custom shortcut prototypes with the action type "lua" can be used. For all others there are specific functions/properties.
stack traceback:
[C]: in function 'set_shortcut_toggled'
itemcam/control.lua:923: in function 'exit_itemcam'
itemcam/control.lua:88: in function <itemcam/control.lua:86>

I can't reproduce this. It seems like a mod conflict, because my shortcut prototypes already has the action type "lua".
Does it still crash if you disable all mods except Item Cam?

I can't reproduce this. It seems like a mod conflict, because my shortcut prototypes already have the action type "lua".
Does it still crash if you disable all mods except Item Cam?

Interesting, disabling Shortcuts for 1.1 fixed it. Wish I could continue to use both, not sure if that would be on you or on them to fix.

"Shortcuts for 1.1" is destroying all "lua" shortcuts by overwriting them with "spawn-item" shortcuts.
The only fix I could do is do a dependency arms race to overwrite it back. But I don't care enough to support compatibility with such a buggy mod.


Feat/mixin and or exported fns

Same can be achieved without much of a hassle by destructuring the directive property from default export.
import vClickOutside from 'v-click-outside';
const { bind, unbind } = vClickOutside.directive


[Bug]: Notebook Examples Fail

Describe the bug
I am unable to get any of the notebook examples to work.
https://github.com/openvinotoolkit/anomalib/tree/v1.1.1/notebooks
I've tried starting with 001_getting_started.ipynb.
If I run it in colab, there's a lot more missing dependencies that I must work with installing. Missing module Lightning, FrEIA, dotenv, etc.
If I run this in my own env, I'm able to get the fit() to run, but it only does one epoch even if I set max_epochs=100. Depending on the notebook I'm running, but I end up with warnings about optimizer returns None.
Do these notebooks still work? In a fresh venv?
I am new to unsupervised learning and I am trying to get into it. Your library looks excellent but I am struggling to get it to work.
Dataset
MVTec
Model
PADiM
Steps to reproduce the behavior
python -m venv .anomalib_env
source .anomalib/bin/activate
pip install anomalib
anomalib install
https://github.com/openvinotoolkit/anomalib/blob/main/notebooks/000_getting_started/001_getting_started.ipynb
OS information
OS information:

OS: RHEL 8.10
Python version: 3.11.9
Anomalib version: 1.1.1
PyTorch version: 2.5.0
CUDA/cuDNN version: 12.1
GPU models and configuration: 8x RTX 4090
Any other relevant information:

Expected behavior
I expect the notebook tutorials to run with minimal adjustments.
Screenshots
This is the closest I get to running it, but I cannot seem to get the epochs to update. I am currently trying to figure out how to deal with the optimizers return None.

Pip/GitHub
pip
What version/branch did you use?
No response
Configuration YAML
I don't have a config yaml because I'm just trying the tutorial notebooks.

Logs
I don't have any logs as I'm just trying to run the notebooks.

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@vmiller987, looks like it is working. The reason why you are seeing None is Padim model does not have an optimiser. And the reason why you are not seeing any output is, you are just fitting the model with engine.fit If you call engine.test(..) it would give you some output

I appreciate the fast reply and the info. If it's working for you, then it's a skill issue on my part. I didn't realize Padim did not have an optimizer as I haven't had enough time to dig through all these libraries that are new to me.
Does Anomalib only need to run for 1 epoch? I tried to set max_epochs=100, but it still ends at 1 epoch. The Engine stated it uses Trainer parameters so I thought I could adjust it with that.

Padim only needs 1 epoch. You could try other models if you would like to train for longer. EfficientAd for example

Oh, well that would explain my issue then. I made an incorrect assumption.
I shall continue to work through the notebooks, and I'll make sure I dig into the different models available to understand them better. My work is wanting me to pursue some unsupervised learning for defect detection in x-ray images of objects, and I have a few thousand unlabeled images.
I am a novice and doing my best to learn. I greatly appreciate your fast replies and pointing out my issues.
Thanks!


Duplicated markers in to clusters

Looks like its adding the same location to a cluster when a zoom event happens. Do you know anything about this?

No we've never seen this unless the 2 markers have the same location. Do you have a reproduction case?

Is this the same issue as https://github.com/googlemaps/google-maps-ios-utils/issues/58?

Has the source of this issue been determined?

Closing this issue out as stale. Please re-open with a link to a minimal reproduction case if this is still an issue.


Compile findings from usability testing with industry operators

Describe the task
After usability sessions conducted between 25th April - 5th of May, the insights collected need to be synthesized and shared with teams.
Acceptance Criteria

[x] Compile feedback
[x] Sort notes in themes
[x] Update User Journey Map
[x] Prepare Miro board for presentation

Additional context

Add any other context about the task here.
Or here

Usability Test findings have been compiled in the CIF Usability Testing Miro Board, and presented in the Sprint Review. Recommendations have been added for addressing those findings. A suggestion for if and when we have capacity, it would be great if we could maintain timestamps of key points from our usability sessions for future easier reference.
@pbastia this ticket is good to be closed after your review!

Thank you so much @suhafa for documenting all of this! Fantastic work!


Execution

@lwasser can this get directly merged and then conversation can continue in #1 ?

@lwasser gentle nudge

@ucodery i'm so sorry I didn't reply /missed these pings. YES, please, lets merge this as is. it's been open for too long and you did too much work on it and it's great... to not merge. I totally missed this pr in my repo - I don't track my work the way I track pyogenic. Also if you want to merge the pyopensci version so you have more control over edits and such you can do that as well. I don't want to slow things down!


Ability to detect if a users cancels / closes a transaction window

There is currently no way to detect if the user cancelled / closed a transaction window. (Opened with openContractCall() for example.) It makes it quite cumbersome to create specific user interactions or stage multiple transactions in sequence.

Needed!

@markmhx I know it is in the icebox, but any updates on this?

Not yet, but I just moved it to the top of the web wallet column in the icebox so we take a prioritized look at it once this milestone is achieved: https://github.com/blockstack/stacks-wallet-web/milestone/39

+1 on this, a need for my sample app too

The PR for this will need to be paired with: https://github.com/blockstack/connect/pull/122 in connect.


fix(compare_map_segmentation): add missing mutex lock

Description

To add some missing mutex lock for current_voxel_grid_dict_ which was pointed out here: https://github.com/autowarefoundation/autoware.universe/pull/3087#issuecomment-2414061694

Related links
Parent Issue:

Link

How was this PR tested?
Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

@badai-nguyen
At first, please change the variable name mutex_ptr_ so that which data structure is protected by it.

Isn't is necessary locking here?
  if (current_voxel_grid_dict_.size() == 0) {
    return false;
  }

Strictly speaking, relaxed memory ordering is enough here (I think), but stricter ordering will not invoke a bug, so I will admit it.
is_initialized_.load(std::memory_order_acquire)

After you check the result of Autoware Evaluator again, I will approve this PR!!

@veqcc I recheck this update on Evaluator again and all tests were passed. https://evaluation.tier4.jp/evaluation/reports/1e5dd036-27fa-5480-b44f-b4ef14d6aa3d?project_id=prd_jt

@yukkysaito Could you review this PR as codeowner?

The code itself seems fine. However, I haven't thoroughly checked whether the resources being locked are appropriate.
Is it correct to assume that the mutual exclusion control was reviewed by @veqcc ?

The code itself seems fine. However, I haven't thoroughly checked whether the resources being locked are appropriate.
Is it correct to assume that the mutual exclusion control was reviewed by @veqcc ?

Yes it is.
But I think it's worth being double checked. If you approved it, you are responsible for the codebase. If you do not have enough time for checking it thoroughly, please assign somebody else.

@yukkysaito friendly ping.
FYI: I updated description by adding tested video on static and dynamic mode on split map pointcloud with internal rosbags.


Improve CGMES documentation regarding transformers and boundaries

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?
Doc update: complete documentation regarding CGMES import of transformers and equipment at boundary

@colinepiloquet I know you have transfered most of the cim-cgmes documentation in readthedocs. What about this PR? Could you check if there is something to get from it and then close it?
Thanks a lot!

@colinepiloquet I know you have transfered most of the cim-cgmes documentation in readthedocs. What about this PR? Could you check if there is something to get from it and then close it? Thanks a lot!

Indeed I don't like "linking device".

@colinepiloquet I know you have transfered most of the cim-cgmes documentation in readthedocs. What about this PR? Could you check if there is something to get from it and then close it? Thanks a lot!

Indeed I don't like "linking device".

Me neither. We do need to integrate this PR in the documentation though. I have trouble finding another word for linking device.

I have done some corrections, according to your feedback @So-Fras and @annetill. Once merged, I will transfer it to the documentation on readthedocs.