a small problem about update order

In the paper(https://arxiv.org/abs/1509.02971),update critic first,then update actor.

I tried 10 times on different random seeds and the results showed similar performance.

(red is update critic first)
I think it is better if the tutorial code is the same as the paper.

Cool, thanks for sharing your method.


uSync Stripe connector does not create Shipping Rate on Import

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)
10.6.1
Bug summary
When running an import, the uSync Stripe connector fails to create the Shipping Rate
Specifics
No response
Steps to reproduce
Create a uSync file containing a Shipping Rate not found in the database
Run the import
Expected result / actual result
The Shipping Rate should be created, however it is not

Fixed for RC2


Fix the query option override for leaf stage

Fix the bug of query option being completely overridden when generating leaf stage query. During query planning, we might add query options (e.g. serverReturnFinalResult), which should be preserved.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (59551e4) to head (34f2497).
Report is 1429 commits behind head on master.

:exclamation:  There is a different number of reports uploaded between BASE (59551e4) and HEAD (34f2497). Click for more details.
HEAD has 53 uploads less than BASE

Flag
BASE (59551e4)
HEAD (34f2497)

integration
7
1

integration2
3
1

temurin
12
1

java-21
7
1

skip-bytebuffers-true
3
0

skip-bytebuffers-false
7
1

unittests
5
0

unittests1
2
0

java-11
5
0

unittests2
3
0

integration1
2
0

custom-integration1
2
0

Additional details and impacted files
@@              Coverage Diff              @@
##             master   #14603       +/-   ##
=============================================
- Coverage     61.75%    0.00%   -61.76%
=============================================
  Files          2436        3     -2433
  Lines        133233        6   -133227
  Branches      20636        0    -20636
=============================================
- Hits          82274        0    -82274
+ Misses        44911        6    -44905
+ Partials       6048        0     -6048

Flag
Coverage Δ

custom-integration1
?

integration
0.00% <ø> (-0.01%)
:arrow_down:

integration1
?

integration2
0.00% <ø> (ø)

java-11
?

java-21
0.00% <ø> (-61.63%)
:arrow_down:

skip-bytebuffers-false
0.00% <ø> (-61.75%)
:arrow_down:

skip-bytebuffers-true
?

temurin
0.00% <ø> (-61.76%)
:arrow_down:

unittests
?

unittests1
?

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Low Peer Numbers

Multiple reports of peering issues, this is a placeholder to track and gather info.
Anecdotally seems like issues began after Dencun fork on March 13th and are worse during initial sync.

@garyschulte suspected a Dencun fork id issue on March 22nd related to geth during snap server testing...it ultimately turned out to be an old version of geth, but there were still a lack geth peers on our canary nodes.

Other devs internally have noticed issues connecting to geth peers while trying to sync Holesky.

This node syncs basically using 2 Geth nodes and disconnects all non Geth nodes, because they are useless. After the sync, when we stop sending snap requests we do find peers, but out of a max of 21, I have 2 Geth nodes, 1 reth node, 1 besu node, and the rest is nethermind. Something is not right here!

Issue reported on geth https://github.com/ethereum/go-ethereum/issues/29312

User reports from EthStaker #besu-helpdesk Discord

GGubignou — 17/03/2024 19:51

Hi, I updated to the latest Besu via eth-docker and it now seems to struggle finding peers. I was previously at 25 peers constantly but now it oscillates between 8-13 peers. Has anything been changed with regards to port forwarding in the latest version?
(FYI my consensus client Teku finds peers as usual and I have otherwise not changed anything to my setup)

GGubignou — 18/03/2024 16:49

Hi @siladu, after a couple hours of struggle it eventually managed to go back to 25 peers and it seems fine now. I upgrade frequently so I was likely on the previous release before that.

ktmkancha — 23/03/2024 01:05

Hi Siladu- I've been having trouble with Peer connections. I hadn't updated my node prior to the Dencun fork for few months so I was probably few updates behind. I have been hovering around 9-11 peers in the last few hours. It hasn't really climbed up or down. Any advice?

ktmkancha — 26/03/2024 05:28

Since the Dencun update, my peer count has been single digits. I used to get consistently 25 peers prior to this, any advise? Thank you

ktmkancha — 28/03/2024 02:27

Hi @siladu Just wanted to report that after the besu node sync up with the top of the chain- the peer count is back up to 15+.  It's better than single digits, but compared to dencun update- it's still 10 less peers. I used to get 25 peers consistenly. Will keep an eye out of the any besu updates! thanks

MrPrezident — 24/03/2024 03:08

I noticed that while syncing besu, it is consistently using only 1 peer, whereas teku currently has 24 peers. Is that because I'm doing a checkpoint sync?

MrPrezident — 24/03/2024 06:32

teku is connected to 28 peers, so I don't think it is having any problems. Only besu is having issues with peers. Both teku and besu are being run on the same host using ethdocker
The only firewall should be my pfsense router.
but I have portforwarding turned on in pfsense

MrPrezident — 24/03/2024 14:26

Just for testing purposes, I reconfigured my ethdocker to use geth/prysm and restarted syncing to see if it would have the same problem as besu/teku. It did finish syncing on both execution and consensus clients, but I noticed that the consensus client (prysm) is hovering at about 70 peers and the execution client (geth) is hovering at about 5 peers. That seems like a huge discrepancy. That is sort of in line with what I was seeing with besu/teku. Besu was only getting 1 or 2 peers vs about 20 peers with Teku. Is this normal to have less peers with the execution client? How many peers should I expect to see with the execution client?

MrPrezident — Yesterday at 00:51

This morning I looked at my dashboard and now I see 33 execution peers and 72 consensus peers (this is with geth/prysm). I didn't change anything. I just let it run overnight. I assume this is a normal range? It would be good to know how many peers I should expect. (this is on holesky)

scott — 26/03/2024 05:32

Also happening here, seems to be a known issue with an unknown root cause right now.

All Might — 26/03/2024 06:01

Same here, my peers have been at 5 the entire day. Has happened several times in the last 5 days and I don't know how to fix it

RemiRaznor — 28/03/2024 00:01

I'm having the same issue with low to no peer count. I'm trying to rebuild my Besu database after switching from goerli to holesky. For 2 days, I have gotten "Unable to find sync target. Currently checking 0 peers for usefulness" messages. Once or twice it found 1 or 2 peers enough for the download progress to be just 13.49%. I have restarted besu 4 or 5 times in the last 2 days with no success.   This validator was working fine in goerli. All ports are open.

RemiRaznor — 28/03/2024 06:10

I got it to sync finally by adding the --p2p-port=30303  card to the Besu service. After restarting the EL, I was able to connect with one peer just enough to get the download started again and then I got one more peer which got me to 57% and then I lost the peers again and stalled. I started adding the other ports, rpc port, engine port and metrics port one by one until after the metrics port the sync started up again.  Not sure if this will help but good luck...

Some examples of current peers on some mainnet nodes:
25 peers on dev-elc-besu-teku-mainnet-dev-stefan-BWS-2:
erigon/v2.59.0-0f0a4452/linux-amd64/go1.21.8","caps":["eth/68"]
Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.6","caps":["eth/68","snap/1"]
Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68"]
erigon/v2.58.2-125509e4/linux-amd64/go1.21.5","caps":["eth/66","eth/67"]
erigon/v2.58.1-f12e451c/linux-amd64/go1.21.4","caps":["eth/68"]
erigon/v2.58.1/linux-amd64/go1.21.6","caps":["eth/68"]
erigon/v2.58.1/linux-amd64/go1.21.6","caps":["eth/66","eth/67"]
erigon/v2.58.1-f12e451c/linux-amd64/go1.21.5","caps":["eth/66","eth/67"]
Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68","snap/1"]
reth/v0.1.0-alpha.21","caps":["eth/68","eth/67","eth/66"]
erigon/v2.59.0-0f0a4452/linux-amd64/go1.21.6","caps":["eth/66"]
erigon/v2.58.1-f12e451c/linux-amd64/go1.21.5","caps":["eth/68"]
erigon/v2.59.0-0f0a4452/linux-amd64/go1.21.6","caps":["eth/66","eth/67"]
Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68","snap/1"]
reth/v0.1.0-alpha.22-a9ac903ee/x86_64-unknown-linux-gnu","caps":["eth/68","eth/67","eth/66"]
reth/v0.1.0-alpha.21","caps":["eth/68","eth/67","eth/66"]
reth/v0.1.0-alpha.21","caps":["eth/68","eth/67","eth/66"]
reth/v0.1.0-alpha.21","caps":["eth/68","eth/67","eth/66"]
erigon/v2.59.0-0f0a4452/linux-amd64/go1.21.6","caps":["eth/68"]
reth/v0.1.0-alpha.21","caps":["eth/68","eth/67","eth/66"]
erigon/v2.58.0-9731f716/linux-amd64/go1.20.3","caps":["eth/66","eth/67"]
reth/v0.1.0-alpha.21","caps":["eth/68","eth/67","eth/66"]
erigon/v2.58.1-f12e451c/linux-amd64/go1.22.0","caps":["eth/66","eth/67"]
Nethermind/v1.26.0-exp.3+e02b744c/linux-x64/dotnet8.0.2","caps":["eth/66","eth/67","eth/68","nodedata/1","snap/1"]
erigon/v2.58.2-125509e4/linux-amd64/go1.20.14","caps":["eth/68"]

prd-elc-besu-teku-mainnet-bonsai-snap
Note: most of the Geth nodes connected here are version 1.1.8, released in 2020? Except for two Geth 1.13. which are up to date
I checked the head block for some of the Geth1.1.8 peers and they were all after the cancun hardfork
The 1.1.8 nodes support more than just eth/68
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0x960cc4e7981bfc70ad8d4ad407d31339b2fd32f4dbf55950b18574effc2eca98
erigon/v2.58.1/linux-amd64/go1.21.7","caps":["eth/66","eth/67"] head:0x1315e4118e98b7caac01e590530bfe2a98e31c5fe0980a1794fd78a2d61a2c3d
Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68"] head:0x03acdf02f882cfe1569fb2c19a75f03e8ec0d0dea99a5a7c512a57030be45a8b
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0x618862fd4423255f62918cc49fd4a6c5abda707f6f66b276dc7acc263a3946f6
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0x004c0539eb79a8a535c725c435dfedad16ee6c1c970b14bffbafca2a524a7890
reth/v0.1.0-alpha.10","caps":["eth/68","eth/67","eth/66"] head:0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0xa8efe59d83d87f93d0a2e61dec881ebbed5688127bf025799462024183b5a9d5
Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68"] head:0x5a3e10c0fe9f6b29ce46d0b01f904906ddb243ca48bd4ea9fe37fed5d960d522
Nethermind/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68"] head:0xd631df240616de2d7e1baa8c8236d5b5711cd52310f47808eafcfc7d2ba650ec
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0x78cb37deca8107b53310e25a848ce097adec57be03481f5e2012f143e22b4f2e
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0xafb9d777feef06413496d16fb19fd21bec1c7d6d1f53ec784091f61f9e93355d
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0xa92c29408b50d5b4084d6d837f280ed0e6ec80a625770beb23627fc3e9583f48
erigon/v2.59.0-dev-729e82db/linux-amd64/go1.21.6","caps":["eth/66","eth/67"] head:0x7a33ad410557e24adcb96a72e427fed177f921f09dfdf08b27f9e409bdfeea49
erigon/v2.59.0-0f0a4452/linux-amd64/go1.20.14","caps":["eth/68"] head:0x6d5e4f3afba38fedd2cefab81fb0c503b75fcc4ca4ea4912de694ac2eddb4b31
Geth/v1.13.14-stable-d5a69be9/linux-amd64/go1.22.0","caps":["eth/68","snap/1"] head:0x19c969aa9e9058a2280b17545c4790f397f66e7e19a4e2e546fea9162d93de0e
Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.6","caps":["eth/68","snap/1"] head:0xca3e61fa5986b66be3dc13b52b78088220537a6a693deadcc02054d5e0769c2c
erigon/v2.59.0-0f0a4452/linux-amd64/go1.21.6","caps":["eth/66","eth/67"] head:0x962fd27661c398b104074b9af8f775d039124f034008f713e74b1b4e42cd23ed
erigon/v2.59.0-7f28419f/linux-amd64/go1.20.14","caps":["eth/66"] head:0xa8efe59d83d87f93d0a2e61dec881ebbed5688127bf025799462024183b5a9d5
besu/v24.1.2/linux-x86_64/openjdk-java-17","caps":["eth/63","eth/64","eth/65","eth/66","eth/67","eth/68","snap/1"] head:0x30c53e9e18a555f9e8ecdf96a1212f1b39bae5ab64fb91d971b3f4b487235fe3
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0x6a8cab760d83df575477c51189a598c17903818cb045653a944650ff4a42c4a4
erigon/v2.58.2-125509e4/linux-amd64/go1.21.5","caps":["eth/68"] head:0x759e27a5069535949f0a7247ebc999367dbd77964d77ed004ffc8db3d4940248
besu/v24.3.0/linux-x86_64/openjdk-java-17","caps":["eth/63","eth/64","eth/65","eth/66","eth/67","eth/68","snap/1"] head:0x82e90be44ae7285a8ebe930361a5603cde6e385e262efc13dff884bb6023c9dc
erigon/v2.58.2-125509e4/linux-arm64/go1.20.14","caps":["eth/68"] head:0xf7e22e2e8c35037af82c95f39248ed8f507b855c6e9692917678fe93cc391f2b
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0x960cc4e7981bfc70ad8d4ad407d31339b2fd32f4dbf55950b18574effc2eca98
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"] head:0x64c3e5f9b4686fb9759881e14a76b28f7a8a7a9b5e5543d1add51026a1dfbae8

prd-elc-besu-nimbus-mainnet-nightly-bonsai-snap
Note: looks a lot like the last node!
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x466cda14dce6f9a4eefb62ef6452df2e85a182b075a51231cfef396eadde0708"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0xfffc4c928eb7f2b58fbd6bd3d870d013c99835f53a866274795131bf8528a857"
besu/v24.3.1-SNAPSHOT/linux-x86_64/openjdk-java-17","caps":["eth/63","eth/64","eth/65","eth/66","eth/67","eth/68","snap/1"]head: 0xf90e0395632d3ea84ae198b20908966b7dd4a2258a1021116cd19a8b2c1a65c4"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0xa3513dfb4012f7bf2cbc17785de83552e08b0f02832eee39804bb6e917c6c658"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x87e1abc77e5380e7ba60b8b01973bbae6c9436d6523fb5b34b2d85658cadaf08"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x0f7c4af187e50e0f1ed0b725c4741aeed693ad7db13863780f0d56acba0ce65a"
reth/v0.1.0-alpha.22-a9ac903ee/x86_64-unknown-linux-gnu","caps":["eth/68","eth/67","eth/66"]head: 0xe8fa17e0eadd1cff120a979f3331d13d90ddf4383df4bcabd5e95e6f34261d7c"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0xe2ec61193fb6aabbf3ec080f308a92419c9cf813c585de68451cf68bfa639769"
erigon/v2.58.2/linux-amd64/go1.21.4","caps":["eth/66","eth/67"]head: 0x40a79ce0537068c6c96416520857e5002144738a8c9ad3ad77c656ee9e43be0b"
Nethermin/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68","snap/1"]head: 0x925f7a7d4c9a6cbfef1e309a7054c541e53b08e6104da61289ae6ed351ecf9e9"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x14bf4dc31c9b81cd290506757d5b8717bc81ed8187a92b6ca83c97371da98040"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0xf90e0395632d3ea84ae198b20908966b7dd4a2258a1021116cd19a8b2c1a65c4"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x000f215a3b5fa3c87eec3c786ceba11aa76d969831d3499d49577f2b4446c231"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0xb91faa6e8f45401eabe750758a260cbb02962956b34a56d49227a8187e4fcda9"
Geth/v1.13.13-stable/linux-amd64/go1.22.1","caps":["eth/68","snap/1"]head: 0x616903f8b03ca625ad93cc2901ba8503ed49036fa7401e82941f00e2f5fc83f5"
Nethermin/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68"]head: 0xda8af43b3c22e19b8d0572ceefaab2e45b636820c9a92e67f043265bdfabf65e"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x000f215a3b5fa3c87eec3c786ceba11aa76d969831d3499d49577f2b4446c231"
reth/v0.1.0-alpha.22-a9ac903/x86_64-unknown-linux-gnu","caps":["eth/68","eth/67","eth/66"]head: 0xad48092a1c4210a4a1905fb53b89fd402fd973609257beb703691961b44a0c9c"
Geth/v1.13.14-stable-aaff12e3/linux-amd64/go1.22.0","caps":["eth/68","snap/1"]head: 0x6f42582ed73ed2927a8dfb5f6199dd4d51957b6422c87c610d225a6b81e2a53a"
Nethermin/v1.25.4+20b10b35/linux-x64/dotnet8.0.2","caps":["eth/66","nodedata/1","eth/67","eth/68","snap/1"]head: 0x3b2afe1a830ffbf5eb7603bfa80ed02fe8be40ecd25b6755a629f4ef5571ccd0"
erigon/v2.58.2-125509e4/linux-amd64/go1.20.2","caps":["eth/66","eth/67"]head: 0xd405b1a8c724d0b6bd2b837b76f1352063e69edc8c4ca611585613449e2d71bf"
besu/v24.3.0/linux-x86_64/openjdk-java-17","caps":["eth/63","eth/64","eth/65","eth/66","eth/67","eth/68","snap/1"]head: 0x8885dd6d5bde29931b63bed1f5e732575aab7d5c3ca0953f3378e83510392220"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x23369871d0083896cf75f688173fd6f4a0fdd08ce5f051716ccd9f2dcec64ee2"
Geth/v1.1.8-859186f2/linux-amd64/go1.16.13","caps":["eth/66","eth/67","eth/68"]head: 0x000f215a3b5fa3c87eec3c786ceba11aa76d969831d3499d49577f2b4446c231"

most of the Geth nodes connected here are version 1.1.8
I wonder if this is a misreported version, but if it's not then this is the commit hash...
https://github.com/ethereum/go-ethereum/commit/859186f2

From Jan 2022.
Merge pull request #743 from binance-chain/develop !

https://github.com/ethereum/go-ethereum/pull/28261

Some discussion on #execution-dev ...

Updated description with more reports. We are still actively looking into this, hopefully have an update soon.

We have identified an issue related to Blob transaction gossip resulting in Geth peers sometimes disconnecting Besu. We are  currently testing out a fix. This should only be an issue once the node is in sync (since transaction gossip is paused during sync).
There may still be a separate issue related to peer discovery which we are still investigating

bob transaction gossip fix has been merged into main - more info - #6777

FWIW observed the same on Holesky with 24.3.0. I raised the peer limit to 40 from 25, but during snap sync it was essentially 0-2 peers that I actually synced with. Towards the very end I started to get more peers. Never hit the 40 limit in the 12 hours it's been running.
I tried making sense of debug logs but don't have much context (new to the staking scene).
It's a little bit verbose and weighs in at 581MB :joy:
I'll try get that shared.
It was clearly trying though, lots of disconnects.

With 24.3.1 I've not been able to resync on holesky :smiling_face_with_tear:
This seems like a regression from 24.3.0. The 2 bootnodes will support the SNAP syncing up to a certain point and a flurry of issues show up. Both sides seems to be saying USELESS_PEER and I'm down to 0 peers at block 3000 or 4000.
2024-03-31 19:36:04.672+00:00 | EthScheduler-Services-42 (importBlock) | TRACE | ImportBlocksStep | Imported block 99 (0x13a0dce9e9be317f1557d573fdc1fca28b1530f97454fae64367d87a56ff1a17)
2024-03-31 19:36:04.672+00:00 | EthScheduler-Services-42 (importBlock) | TRACE | IncrementalTimestampRule | Is block timestamp more recent that its parent? true, [block timestamp<PHONE_NUMBER>, parent timestamp<PHONE_NUMBER>]
2024-03-31 19:36:04.674+00:00 | EthScheduler-Services-42 (importBlock) | DEBUG | TrailingPeerLimiter | Enforcing trailing peers limit (min height 1255002, max trailing peers 0) by disconnecting 0xac906289e4b7f12d...... with height 1255001
2024-03-31 19:36:04.674+00:00 | EthScheduler-Services-42 (importBlock) | TRACE | EthPeer | handleDisconnect - EthPeer PeerId: 0xac906289e4b7f12d...... PeerReputation score: 109, timeouts: {}, useless: 0, validated? true, disconnected? true, client: Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.7, [Connection with hashCode -1312496927 inboundInitiated? false initAt<PHONE_NUMBER>228], enode://ac906289e4b7f12d...:30303
2024-03-31 19:36:04.674+00:00 | EthScheduler-Services-42 (importBlock) | TRACE | EthPeer | Received useless response for request type headers from peer 0xac906289e4b7f12d......
2024-03-31 19:36:04.674+00:00 | EthScheduler-Services-42 (importBlock) | TRACE | EthPeer | Received useless response for request type receipts from peer 0xac906289e4b7f12d......
2024-03-31 19:36:04.674+00:00 | EthScheduler-Workers-0 | DEBUG | DownloadHeaderSequenceTask | Downloading headers from 1401 to 1600.
2024-03-31 19:36:04.675+00:00 | EthScheduler-Services-42 (importBlock) | DEBUG | GetReceiptsForHeadersTask | Requesting bodies to complete 117 blocks, starting with 802.
2024-03-31 19:36:04.675+00:00 | EthScheduler-Services-42 (importBlock) | DEBUG | EthPeers | Disconnected USEFULL peer PeerId: 0xac906289e4b7f12d...... PeerReputation score: 109, timeouts: {}, useless: 2, validated? true, disconnected? true, client: Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.7, [Connection with hashCode -1312496927 inboundInitiated? false initAt<PHONE_NUMBER>228], enode://ac906289e4b7f12d...:30303
2024-03-31 19:36:04.675+00:00 | EthScheduler-Services-42 (importBlock) | DEBUG | EthProtocolManager | Disconnect - Outbound - 0x03 USELESS_PEER - 0xac906289e4b7f12d... - 2 peers left
2024-03-31 19:36:04.675+00:00 | EthScheduler-Services-42 (importBlock) | TRACE | EthProtocolManager | 2 EthPeers {
PeerId: 0xa3435a0155a3e837...... PeerReputation score: 110, timeouts: {}, useless: 0, validated? true, disconnected? false, client: Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.7, [Connection with hashCode -555409451 inboundInitiated? false initAt<PHONE_NUMBER>869], enode://a3435a0155a3e837c02f5e7f56...:30303,
PeerId: 0x3bd1127b27212d2d...... PeerReputation score: 116, timeouts: {}, useless: 0, validated? true, disconnected? false, client: erigon/v2.58.1-f12e451c/linux-amd64/go1.21.7, [Connection with hashCode -975701323 inboundInitiated? false initAt<PHONE_NUMBER>436], enode://3bd1127b27212d2d165ffaa7ae1e0efbdfdf...:30304}
2024-03-31 19:36:04.675+00:00 | EthScheduler-Services-42 (importBlock) | TRACE | AbstractPeerConnection | Writing DisconnectMessage{code=1, size=2} to PeerInfo{version=5, clientId='Geth/v1.13.14-stable-2bd6bd01/linux-amd64/go1.21.7', capabilities=[eth/68, snap/1], port=0, nodeId=0xac906289e4b7f12df423d654c5a962b6ebe5b3a74cc9e06292a85221f9a64a6f1cfdd6b714ed6dacef51578f92b34c60ee91e9ede9c7f8fadc4d347326d95e2b} via protocol null
2024-03-31 19:36:04.675+00:00 | EthScheduler-Services-42 (importBlock) | DEBUG | AbstractPeerConnection | Disconnecting connection -1312496927, peer 0xac906289e4b7f12d... reason 0x03 USELESS_PEER

Deleting all data and reverting to 24.3.0 I'm able to keep syncing with the bootnodes.

Thanks for the analysis @Beanow! Will take a closer look at your logs. What you're describing is similar to what I've I've seen in my analysis so far: on Holesky at least, it can sync with the bootnodes but sometimes disconnects these due to empty responses leading us to treat it as a useless peer (correctly). This can happen if the peer is busy, as I expect a bootnode would be.
The problem during Holesky sync is that it isn't finding new peers, or finds and disconnects them quickly maybe. This is intermittent...sometimes restarting besu finds a new non-bootnode peer, but peer numbers still remain low until after syncing.
Mainnet is a different story: maybe lower numbers during sync too but >> 0. Primary issue on mainnet seems to be the post-sync blob tx gossip disconnects which 24.3.1 (24.4.0) should have resolved.

This seems like a regression from 24.3.0

I think it might just be intermittent/peering luck, as I've been investigating the same problem on 24.3.0 and 24.1.2. But I will try to confirm.

Also worth noting that until 23.3.1/24.4.0, our Holeskly config relied entirely on the bootnodes for finding new peers, we added the dns discovery server during this investigation: https://github.com/hyperledger/besu/commit/63a53aa76f888ab83c9427de68097bb64be9ad4a
Despite this, holesky worked fine until recently.

It did seem more consistent than luck. I've tried to wipe the data and resync on 24.3.0 and 24.3.1 3 or 4 times each.
And with the patch, the bootnodes DC after some time. I think that might be why it doesn't recover either, it sits at like 4k blocks and reports (on prometheus at least) hey I'm 0 blocks behind, all synced! Possibly that made new peers decline us?
While 24.3.0 is able to keep at least 1 of 2 bootnodes for long enough to sync fully.
Haven't tried with DNS discovery yet.

@Beanow When you wipe the data do you also wipe the node key? Retaining the node key may cause us to remain on other peers' good or bad lists and produce more consistent results.

I believe the node key is in $DATA_PATH/key right? Then yes, rocket pool's script discards the docker volume that has the data path.

it sits at like 4k blocks and reports (on prometheus at least) hey I'm 0 blocks behind, all synced!

Hopefully that's just a metric/dashboard being misleading...we should be sending the correct head information to the peers over the rlpx layer https://github.com/ethereum/devp2p/blob/master/rlpx.md
...if our peering logic even makes it that far :)

The metric is ethereum_best_known_block_number and on 24.3.1 it seems to go up to the expected 1.2 mil regions when we go from 0 to 1 peer. But when they leave it drops back to what's reported as our height with ethereum_blockchain_height.

I've been analysing the logs of a holesky node that dropped all peers during sync and has been sitting on 0 peers for days.
Most interesting things I've found so far...

We got "Failed to connect to peer" for 2200 unique peers during a period of ~4 hours with 0 peers on holesky.
That's out of 112926 attempts in total, so on average 50 "retries" per peer.

About 45% of these are "Timed out waiting to establish connection with peer" which means we've found the peer to be on the correct network + forkId, but have waited 10 seconds between "ForkId OK..." and "Failed to connect to peer"
{"@timestamp":"2024-03-30T09:40:00,227","level":"DEBUG","thread":"pool-8-thread-1","class":"EthProtocolManager","message":"ForkId OK or not available for peer 0xc13e9d36ae609738...","throwable":""}
{"@timestamp":"2024-03-30T09:40:00,227","level":"TRACE","thread":"pool-8-thread-1","class":"RlpxAgent","message":"Initiating connection to peer: enode://c13e9d36ae609738ada0b174972148205eb73d0301e517a6d5800ae74179a3918dd600b089c206a2aff7bf1252002fae5b37a287e0dc29989dbaadb28fed31ab@<IP_ADDRESS>:30303","throwable":""}
{"@timestamp":"2024-03-30T09:40:00,227","level":"TRACE","thread":"nioEventLoopGroup-3-7","class":"ECIESHandshaker","message":"Prepared ECIES handshake with node 0xc13e9d36ae609738ada0b17497214820... under INITIATOR role","throwable":""}
{"@timestamp":"2024-03-30T09:40:10,227","level":"DEBUG","thread":"nioEventLoopGroup-3-7","class":"RlpxAgent","message":"Failed to connect to peer 0xc13e9d36ae609738ada0b174972148205eb73d0301e517a6d5800ae74179a3918dd600b089c206a2aff7bf1252002fae5b37a287e0dc29989dbaadb28fed31ab: java.util.concurrent.TimeoutException: Timed out waiting to establish connection with peer: 0xc13e9d36ae609738ada0b174972148205eb73d0301e517a6d5800ae74179a3918dd600b089c206a2aff7bf1252002fae5b37a287e0dc29989dbaadb28fed31ab","throwable":""}```

Two issues I want to confirm with this:
a. Are we starving the peering resources by waiting 10 seconds for this? We appear to only use 10 worker threads for this type of connection... https://github.com/hyperledger/besu/blob/deaea9b34da62b707509186e2955864e13212cda/ethereum/p2p/src/main/java/org/hyperledger/besu/ethereum/p2p/rlpx/connections/netty/NettyConnectionInitializer.java#L76

b. Why do we end up going through this with the same peers repeatedly...on average 50 times in 4 hours. The peer in the logs above is an outlier, we did it 702 times in 4 hours :(

2. Found an IP, `<IP_ADDRESS>`, with 162 unique enodes attached...wondering if this could be a discovery attack. Most of them yield a TOO_MANY_PEERS disconnect so not sure it's malicious but so many enodes resolving to one IP is a bit sus. Note this could be enodes intended for some other network, maybe not even Ethereum - I've seen polygon peers in the logs for example.

$ cat /var/log/besu/besu.log | grep -o 'enode://[^@]@<IP_ADDRESS>:[0-9]?discport=[0-9]*' | sort | uniq -c | sort
190 enode://f19199dfc0e440eb7fbda76b909e654392fa6abc32bf7238774e7d6a39d0764e76d9301515b995b71dbe89f2c4b9d9b8fcc730419d1fc068815a361c574eacc8@<IP_ADDRESS>:30303?discport=30493
272 enode://606161aaea58a7afd6db21cd8180a6df6e76f73b6ff219e4e2439250046e73baf24fd5680d446c94526a648c3491e634a85e605b1b07b409ca675b47a621d607@<IP_ADDRESS>:30303?discport=30503
...
29769 enode://5508ea580420555129a3bd3c598b9a8d4cc86966987e9caeaaac989a7f07ca533a3d45a43aa535f7a63dccd0d55ba963b021b451f4752702042010f44766a316@<IP_ADDRESS>:30303?discport=30373
93660 enode://e0046ba9621201bcfbaad95bc318a91770ec43b962eb6bbbbfb5501a1bab33974a6f84a19281a5bec7dd9f86d5e6c6da7f1a023eefe98fa5064ab4efc9fe622c@<IP_ADDRESS>:30303?discport=30318

Seeing a lot of that IP too, but haven't gotten a HELLO user agent yet. They do seem to report themselves as neighbors.
Still looking at the unique peers number you have, and the numbers by DC reason I think it should have gravitated towards good peers before long. As in you find a few, they will mention neighbors that are probably good too.
But the reasons are all over the place.

so on average 50 "retries" per peer.

I haven't crunched the numbers on this yet, but I've also seen the same peers being tried over and over, while they're on a different network ID. Or have not capabilities overlap.

Update: We're not get confident enough in 24.4.0-RC2 to release it: it may have some issues unrelated to peering, we are still investigating.
At the same time, we are preparing a hotfix release which contains the known mainnet peering issue related to blobs.

Update: https://github.com/hyperledger/besu/releases/tag/24.3.3 hotfix was released which should help besu keep hold of geth peers.
Note, there still appear to still be some issues finding peers, particularly on the testnets. If you still experience low peers on mainnet for a prolonged period, please let us know. We would regard normal as taking 30-60 minutes to find 25 peers on mainnet. From our testing, we are aware that some nodes are taking as long as 15 hours though.
Also note, it is not expected that low peer numbers should impact your ability to follow the chain and attest, if that is impacted it is likely a separate issue.
We are still working on the next major release which has more peering improvements, but was found to introduce an unrelated syncing bug so has been delayed.

peerage on testnets is always a problem, regardless of clients, I've experienced issues with Geth and Reth as well.  The nodes tend to be more static and fewer in number, resulting in more "cliques".

peerage on testnets is always a problem, regardless of clients, I've experienced issues with Geth and Reth as well. The nodes tend to be more static and fewer in number, resulting in more "cliques".

@shemnon Indeed. There did seem to be a marked difference following Dencun (or at least client updates around Dencun time perhaps). Mixed reports about success on Holesky especially. We have significant issues getting beyond the bootnodes on a lot of our new holesky nodes. I'm sure some of it is noticing pre-existing issues now we're looking more closely.


No package 'libhackrf' found

I was following this guide https://z4ziggy.wordpress.com/2015/05/17/sniffing-gsm-traffic-with-hackrf/ but I ran into some trouble once I got to the kalibrate-hackrf part. I had already run
apt-get install libhackrf0 libhackrf-dev
so I am very confused by this error:
checking for LIBHACKRF... no configure: error: Package requirements (libhackrf) were not met: No package 'libhackrf' found
Do you have any ideas why that would happen? I'm on Kubuntu 15. Thank you.

I used PyBombs[1] to install gnuradio (instead of packages) and was able to build kalibrate successfully.
[1] http://pybombs.info/

I am trying to install on a Raspberry Pi 3 and getting the issue above. Any idea why it can't find llibhackrf?


28 add selectfrom

closes #28

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Snippet to show a hide password HTML CSS JS

Can I add this snippet?

Go for it! @Sowham-3098

Then please assign me this task and add Hactoberfest tag

@avincodes Please assign this task to me and add the Hacktoberfest Tag

Hi @Sowham-3098 the hacktoberfest PR counts from the tag on the pull request, not the tag on the issue, so don't worry about it! You can work on it...

can i work on this issue


Updated kubernetes_distros.md with DC/OS note.

Updated kubernetes_distros.md with a note that Helm is running fine on Kubernetes on DC/OS

Signing CLA is done


Remove Spring Integration version override

As soon as Spring Integration 5.5.7 is released and integrated in the Spring Boot bom, see https://github.com/spring-projects-experimental/spring-native/blob/22eeac314ad454874c462e1aeada79862f3a1dde/samples/integration/pom.xml#L20

And we should remove the line in the docs that mention the version, see https://github.com/spring-projects-experimental/spring-native/commit/00479fb548037da02cb2b855c7924e0fedca628b


chore(master): release 1.1.4

:robot: I have created a release beep boop
1.1.4 (2023-11-23)
Bug Fixes

buffer: bufname conflict when creating a new buffer (#1652) (f304335)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/vscode-neovim/vscode-neovim/releases/tag/v1.1.4 :sunflower:


Bug: Public env file

Describe the bug
The .env file is public on the repo, not sure if it's intentional
Steps to reproduce
Go to https://github.com/open-sauced/app/blob/beta/.env
Browsers
No response
Additional context (Is this in dev or production?)
No response
Code of Conduct

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

Contributing Docs

[X] I agree to follow this project's Contribution Docs

those variables are named PUBLIC_URL so I think it's intentional.

Thanks for checking this @Aadarsh805! This is supposed to be in the project.


notebook for tiny sd

ref. CVS-117156
TO DO:

[x] redraw plot
[ ] switch unet to static shapes (in next prerelease migration, current has issue with that)

Could we import this code from a python module?
I meant - can we remove this code from the notebook and move it to a separate Python module so we can just import it?

Could we import this code from a python module?

I meant - can we remove this code from the notebook and move it to a separate Python module so we can just import it?

no, it is not good practice, for documentation purposes it is recommended to keep all code in notebook (otherwise reading docs page user has no understanding where to find it and how it is looks like) and we are also lost education value without opportunity to explain this code, notebook just turn to the demo


localhost resolution appears to be broken

sslip.io is a DNS server that maps specially-crafted DNS A records to IP addresses (e.g. "127-0-0-1.sslip.io" maps to <IP_ADDRESS>). 				IN	A

;; ANSWER SECTION:
<IP_ADDRESS>.sslip.io.	42834	IN	A	<IP_ADDRESS>

;; Query time: 81 msec
;; SERVER: x#53(x)
;; WHEN: Wed Sep 29 12:38:59 AWST 2021
;; MSG SIZE  rcvd: 67

Thanks for the catch, @iJebus. Could you do me a favor & tell me what your upstream DNS server is  when you get that anomaly? I've checked all my DNS servers and they appear to respond correctly with a query for 127-0-0-1.sslip.io:
for NS in $(dig ns sslip.io +short | grep -v ";;"); do echo -n "$NS: "; dig 127-0-0-1.sslip.io @$NS +short; done

returns the following:
ns-gce.nono.io.: <IP_ADDRESS>
ns-azure.nono.io.: <IP_ADDRESS>
ns-aws.nono.io.: <IP_ADDRESS>

Also, when you get the erroneous response, could you please include a timestamp? I can review my logs &  hopefully find what is going on.

Theoretically the router should be forwarding to <IP_ADDRESS>/<IP_ADDRESS>, but querying them directly is fine soooooooo 😬
$ dig 127-0-0-1.sslip.io @<IP_ADDRESS> +short;
<IP_ADDRESS>

$ dig 127-0-0-1.sslip.io @<IP_ADDRESS> +short;
<IP_ADDRESS>

Running your bash loop I get the following.
$ date
Wed 29 Sep 2021 17:04:43 AWST

$ for NS in $(dig ns sslip.io +short | grep -v ";;"); do echo -n "$NS: "; dig 127-0-0-1.sslip.io @$NS +short; done
ns-azure.nono.io.: <IP_ADDRESS>
ns-gce.nono.io.: <IP_ADDRESS>
ns-aws.nono.io.:
; <<>> DiG 9.10.6 <<>> 127-0-0-1.sslip.io @ns-aws.nono.io. +short
;; global options: +cmd
;; connection timed out; no servers could be reached

All good except AWS, but it's weird that it would be responding fine for you.
Given that it's fine for you maybe there's just something flakey on my side.

Thanks @iJebus , that output is very useful.
The error you're seeing for ns-aws queries was caused by me 2 hours ago. Specifically, this I uncovered a bug when I reboot the ns-aws server (it only binds to the loopback interface, which renders the nameserver inoperable), but it's unrelated to the initial issue. It's working now.
The initial issue may have been caused by an IPv6 network partition because ns-aws is a special nameserver that has both IPv4 & IPv6 addresses. The remaining nameservers are pure IPv4. A simple test:
ping6 2600:: # IPv6 works
ping6 ns-aws.nono.io # is network partitioned?
dig 127-0-0-1.sslip.io @ns-aws.nono.io -6  +short # let's try the query over IPv6
dig 127-0-0-1.sslip.io @ns-aws.nono.io -4  +short # let's try the query over IPv4 for completeness

$ ping6 2600:: # IPv6 works
ping6 ns-aws.nono.io # is network partitioned?
dig 127-0-0-1.sslip.io @ns-aws.nono.io -6  +short # let's try the query over IPv6
dig 127-0-0-1.sslip.io @ns-aws.nono.io -4  +short # let's try the query over IPv4 for completeness

ping6: UDP connect: No route to host
ping6: UDP connect: No route to host
<IP_ADDRESS>
<IP_ADDRESS>

Looks good. I've noticed with some of the other addresses I've been trying that the first query will fail but trying again a few seconds later. That's normal I'm guessing?

Looks good. I've noticed with some of the other addresses I've been trying that the first query will fail but trying again a few seconds later. That's normal I'm guessing?

No, that's not normal. What's you're experiencing is uncommon, and I'll try to figure out what's happening.
One of the things I can do is modify my continuous integration to test against the <IP_ADDRESS>, <IP_ADDRESS>, and <IP_ADDRESS> servers to make sure something isn't wrong between my nameservers and those recursive servers.

Just testing again, I notice I'm only seeing that with my internal setup. As in, when I'm not specifying <IP_ADDRESS> or one of the others. I'm more and more convinced there's something off in my local setup and not an issue with sslip.io so I'll close the issue. Appreciate the time you've taken so far and your very polite manner! 💯

@iJebus I'm glad to hear it's probably not my end. And thanks for raising the issue because it uncovered two unrelated bugs, one of which I already fixed.

For others having the same problem: I had the same problem and at the end my configured dns server couldn't resolve sslip.io subdomains:
$ dig <IP_ADDRESS>.sslip.io +short

whereas it resolved when I used the google dns server:
$ dig hello.default.<IP_ADDRESS>.sslip.io @<IP_ADDRESS> +short
<IP_ADDRESS>

Since I used systemd-resolvd for dns resolution, I ended up adding the google dns servers to my /etc/systemd/resolved.conf:
...
DNS=<IP_ADDRESS> <IP_ADDRESS> 2001:4860:4860::8888 2001:4860:4860::8844
...

And then restarted the related services:
$ sudo systemctl daemon-reload
$ sudo systemctl restart systemd-networkd
$ sudo systemctl restart systemd-resolved

Thanks for the tip, @creydr ! If you have the time, I'd be curious to know which DNS servers systemd-resolvd was using before the override was implemented — I'm quite curious if there's a subtle error which I'm not aware of, and I'm looking for clues.

It seems my router (AVM fritzbox) with its default settings to be the problem. The pre-configured DNS server from the router (2001:1438:2:4::8) works fine and can resolve the sslip.io domains:
$ dig <IP_ADDRESS>.sslip.io +short @<IP_ADDRESS>
<no response>

$ dig <IP_ADDRESS>.sslip.io +short @2001:1438:2:4::8
<IP_ADDRESS>


rundeck jobs '[Project]' [alias] is not not responding

I am able add alias and also list projects from rundeck but not able to perform other options as listing jobs from projects and running it

Please find the attached screen shot

I do understand im a year late, but i just started to use hubot, and i do have a rundeck instance.
So, the doc is wrong, so is your command.
Instead of :

rundeck jobs 'demo - Demo' newrd

You should write :

rundeck 'demo - Demo' jobs newrd

+1, this PR fix the documentation : https://github.com/opentable/hubot-rundeck/pull/3/commits/71c812df1c60592c2c9384bc0ed05af64d87fe5e


Using an editor, like Atom, with this plugin generates many notifications to Vagrant VM

Do you have any recommendations on how to better control the notifications being sent to the Vagrant VM when using an editor like Atom (or, I imagine, Sublime)? It seems like by virtue of having a folder open in Atom a constant stream of events are being sent from the host (in this case macOS) to a simple shared folder on Vagrant, even if the file is not opened (i.e. opened in a tab) or no interaction has occurred with it (e.g. saving the file).
Would it be possible to provide this plugin with an enumerated set of "only send these events"? Or is that not possible?
Thanks!

Experiencing the same issue with IntelliJ IDEA.

This is not true for Atom, on my end

This is because notify-forwarder registers IN_ATTRIB events also.

This is because notify-forwarder registers attribute changes events also.

This is because notify-forwarder registers attribute changes events also.


Fixes forking issues, supply and some mac compile issues

This fixes forking issues due to spork differences inherited from pivx upstream and corrects incorrect circulating supply. Mac fix still requires using --with-unsupported-ssl flag for openssl 1.1.*

Looks like my pushes still causes me to fork. I will try to find the issue but would like some help on this.

Looks like I missed the spork end https://github.com/wqking/Vitae/pull/2/commits/518a656d8ee7b1b05f2c0fa96f12d43a46134977 not sure why that would cause nodes to drop but looks like staying on chain is working... Please check my work asap thank you


Add capability to load custom models, datasets, optimizers

Let users register custom model architectures, datasets, and optimizers with the skeletor interface.
This could be through a specific function, or by pointing skeletor to a subdirectory or submodule of the current project that defines these according to a standard format. It would be easy to parse function and class definitions from all of these submodules.
This would make it easier for people to start adding skeleton training code from other frameworks.

Resolved by PR #16


validate OpUndef OpConstantNull yielding pointer types

Fixes: #4354

Can't create null logical pointers that are not variable pointers
Can't create undef logical pointers that are not variable pointers

Khronos SPIR-V internal issue 660:

Can't create undef pointers into PhysicalStorageBuffer

And this PR would need updates for the fuzzer.

See also #4357: for the fuzzer updates


fix roll mode not set properly from dialog box

Small tweak to fix roll visibility settings not being set from the dialog boxes correctly

Should resolve #1385


bug: $ionicSlideBoxDelegate not ready on page load

Type: bug
Platform: all
$ionicSlideBoxDelegate appears to load asynchronously, but there is not a documented API for waiting for it to load.
Calling a method on a slidebox immediately on page load (even inside a timeout) throws an error. Here for example, the slidebox doesn't yet have any slides.
http://plnkr.co/edit/zkGNHmlRlZXCftqKf6NY?p=preview
There are several other issues which are probably related. #4041, #4309

We just landed a new slider component that solves this issue. It's in master and will be in 1.2 To use it today, do this:
Will be back porting the delegate to work with it soon, but going to close since we can document this behavior instead of fixing it since it's a bit async in nature.
<ion-slides options="options" slider="data.slider">
  <ion-slide-page>
  </ion-slide-page>
</ion-slides>

and your JS:
controller('MyCtrl', function($scope) {
      $scope.options = {
        loop: true
      }

      $scope.data = {};

      $scope.$watch('data.slider', function(nv, ov) {
        $scope.slider = $scope.data.slider;
      })

      $timeout(function() {
        $scope.slider.slideNext();
      }, 1000)

});


TODO: Allow/Restrict Duplicate Symbols

"Decide whether or not duplicate symbols are allowed."

I am in favor or duplicate symbols, symbol alone is not sufficient for degens to ape in anyhow, gotta DYOR.

This is a crosscutting issue with issue#7 or has a dependency rather.
Restricting duplicates (particularly at lower lengths) could result in an 'unfair' distribution of those tickers.
Current or novel brc20 tickers could be squatted on.
On the other hand duplicate ticker scams would be rife.

While I personally am in favor of letting people make whatever naming decisions they want and people DYORing, duplicate ERC20 symbol names have personally made my life as a corporate analyst hell trying to explain to non-technical project managers why the token USDC might not be the USDC they think it is

So long as the IDs (#8) are sufficiently distinguishable, I support allowing duplicate symbols.
As I work for a mining pool, the option of restricting duplicates may present an exploitable hole in the model as we approach symbols with less than 4 characters. There would be an economic motivation for us to engage in MEV and preclaim ALL these symbols for later sell (with no method of competition/fairness other than becoming a miner to hope to beat us to the block). I dislike this game theory conclusion so have no choice but to support duplicates.

Unique symbols would need anti-squat consideration which could be an interesting challenge and solution but might not be worth it for this specific protocol. I saw this play out with Counterparty back in the day and ofc all domain name related systems... and of course recently with BRC-20.
I do think the unique name itself is attractive to degen for most tokens that are not launched with a project. It is something they speculate absent of anything else.
I just don't think the game theory of unique names is something that RUNE will dedicate much attention to so I also am leaning non-unique symbols off the bat or else scope creep could be a thing.

+1 on allow duplicate symbols, there are 17927 unique symbols for 3 char or less. It costs roughly 0.5 BTC to issue all of them.

@Psifour One idea to help with non-savvy users is to always include the ID with the symbol, but to make the ID more memorable, we encode it to words using a word list such as BIP-32. For either sequence-style ID or blockheight/txindex ID, we’d only need 3 words to encode, which makes for a fairly easy memorable phrase to remember and check for compared to just a large integer.

@starcox64 makes a very valid point for the other extreme though that we will always have users who don't know to check IDs and allowing duplicates will facilitate easier methods of defrauding those non-savvy users. Is that risk our responsibility?

I definitely support duplicate symbols. In Solidity, users check a contract's address for authenticity. Similarly, they can learn to verify a rune by its index. While @starcox64's concern is valid, proper education can mitigate risks.

+1 to allow duplicate symbols. I think web3 friends above have discussed well enough technical ideas; but I want to point that for the purposes of growing the protocol enabling duplicated symbols is better than scarcity of symbols (as people trying to issue runes can always pick their desired symbol to make a rune; rather than giving up on the idea of launching a rune because their desired symbol is already taken)

Another option is simply not to have symbols at the protocol level at all, and instead identify runes by BLOCK.TX, which is completely unambiguous. I'm almost of the opinion that duplicate symbols at the protocol level are worse than not having symbols at all. After all, what is the point of a symbol that means nothing, can't be spoofed, and doesn't allow looking up runes by symbol.

@starcox64 makes a very valid point for the other extreme though that we will always have users who don't know to check IDs and allowing duplicates will facilitate easier methods of defrauding those non-savvy users. Is that risk our responsibility?

I definitely support duplicate symbols. In Solidity, users check a contract's address for authenticity. Similarly, they can learn to verify a rune by its index. While @starcox64's concern is valid, proper education can mitigate risks.

The cons of enforcing non-duplicate symbols seem to far outweigh the pros. I’m fully supportive of duplicate symbols

Another option is simply not to have symbols at the protocol level at all

I agree and was going to propose this earlier but it felt so unconventional and sort of anti-degen. unique or non-unique names, it is still a label that ppl are attracted to. But this sort of stuff can just be put in metadata as long as it can be referenced from the RUNE object.
Save some bytes and skip the ticker!

I think that fully skipping the ticker is likely to be a breaking point in terms of degen usage. I also have concerns about using block height as part of the identifier. For stability it should be blockhash instead of height as reorgs happen.

Maybe expose it as part of a protocol field as mentioned in https://github.com/casey/runestone/issues/18?

@Psifour the user push data? yes I think users can have flex to add or point to metadata to include ticker or even point to an inscription like an sns .name or .bitmap or even a BRC that was deployed with zero or 1 token supply (just a name squat).
This makes the ticker layer portable and defined by users, not the RUNE protocol. Unique tickers are prob the only reason to have them as part of protocol, otherwise it is just open-ended metadata.

I think that fully skipping the ticker is likely to be a breaking point in terms of degen usage, but would be superior in terms of a fungible token protocol. Maybe expose it as part of a protocol field as mentioned in #18? This lets people who don't need that feature stay very lean in terms of bytes while allowing degens who insist they need this data to larp.
I also have concerns about using block height as part of the identifier. For stability it should be blockhash instead of height as reorgs happen.

agree

I also have concerns about using block height as part of the identifier. For stability it should be blockhash instead of height as reorgs happen.

Practically speaking, this shouldn't be an issue. Bitcoin's security model is basically that 6 block reorgs don't happen, so waiting 6 blocks after token issuance should be safe.

Instead of requiring unique ticker symbols, think about allowing non-unique symbols while adding a paid verification process for a projects. Those with genuine use cases can pay a reasonable fee. This approach discourages squatting and brings in revenue for the main indexer.
To go even further, make the first mint RUNE a fair mint like (Trac,pipe) implementation, and let RUNE holders vote on future changes on the indexer and share some of the revenue as dividends.

To go even further, make the first mint RUNE a fair mint like (Trac,pipe) implementation, and let RUNE holders vote on future changes on the indexer and share some of the revenue as dividends.

I am not a lawyer, but that sounds like an unregistered security. We are small fish that the SEC and FTC don't care about for now, but if you believe something will grow to a scale they may care about.. Probably best to seek some legal counsel first.

Practically speaking, this shouldn't be an issue. Bitcoin's security model is basically that 6 block reorgs don't happen, so waiting 6 blocks after token issuance should be safe.

I would agree that reorgs beyond a certain threshold are statistically improbable/'impossible', but using an identifier that has to 'mature' before becoming (statistically) stable sounds like it would lead to invalid transfer attempts if an issuance is reorg'd that already has children. So long as the logic to handle the possible scenarios it creates are handled, then blockheight could be a more compact form to store it as:

The case where a transfer has already happened, but the blockheight/txindex now points to something other than an issuance.
The case where a transfer has already happened, but the blockheight/txindex now points to a different issuance.

The main concern being that if the transfer is invalid the blog post (which is NOT the specification, which is why I raise this concern now) originally stated, "Runes input to a transaction with an invalid protocol message are burned." It is incredibly unlikely, but someone losing unrelated runes just because they were involved in a transaction that uses a "reorg'd" rune seems like unexpected/undesirable behavior from the users perspective.

On the main topic of this discussion, I am in support of allowing duplicate symbols. There are drawbacks, but I believe that the alternative leads to over-engineering to resolve issues that we can just avoid ever creating by allowing duplicates.

The main concern being that if the transfer is invalid the blog post (which is NOT the specification, which is why I raise this concern now) originally stated, "Runes input to a transaction with an invalid protocol message are burned."

I believe using an invalid ID doesn't make the protocol message invalid - the blog post also mentions that "Excess assignments are ignored", and if we treat any unissued rune is equivalent to that rune having a supply of 0, then it is just an ignored assignment.

I believe using an invalid ID doesn't make the protocol message invalid - the blog post also mentions that "Excess assignments are ignored", and if we treat any unissued rune to be equivalent to having a supply of 0, then it is just an ignored assignment.

I agree that is the expected behavior for an attempt to transfer an unissued rune. However, does that resolve the (incredibly statistically unlikely without purposeful manipulation by a miner) scenario of the same height:txindex now pointing to a different issuance? Depending on how you interpret "excess assignments" it could, but that is why I say we need to define the logic for these two scenarios.

Blockstream Liquid (L-BTC) did not succeed due to duplicate symbols , and ENS (Ethereum Name Service) struggled to gain traction because of name squatting. We can learn from these experiences and seek a middle ground solution, possibly involving a verification process.
In regards to the revenue-sharing aspect, I'm not a legal expert, but it seems to lean more towards utility. However, in my opinion, even if it were classified as a security, it might not be a major issue. The worst that could happen is that it gets registered as a security, which isn't necessarily a significant problem

Blockstream Liquid (L-BTC) did not succeed due to duplicate symbols , and ENS (Ethereum Name Service) struggled to gain traction because of name squatting. We can learn from these experiences and seek a middle ground solution, possibly involving a verification process.
In regards to the revenue-sharing aspect, I'm not a legal expert, but it seems to lean more towards utility. However, in my opinion, even if it were classified as a security, it might not be a major issue. The worst that could happen is that it gets registered as a security, which isn't necessarily a significant problem

I would argue blockstream liquid didnt take off because blockstream is cancer and noone wants to use their bloatware. Nothing to do with duplicate symbols.
Posted this in the wrong Issue earlier so reposting here:
I'm fairly sure none of you guys actually buy altcoins and are just throwing "cool sounding" things at the wall to help you feel like you're not creating a shitcoin machine, but any form of uniqueness is tickers is most definitely not a good thing.

Complexity is not good if your goal is to allow people to use Bitcoin over ETH in this situation. ETH already makes it 1000x easier and likely will continue.
Makes BRC20 more likely to survive long term vs the Runes protocol, which I am sure is not Casey's goal.
Someone will instantly fork Runes and add non unique tickers.
Pepe:1, Pepe:2, Pepe:3 is also basically unique tickers and a fairly cringe suggestion imo.
Ticker length is not an issue, people ape extremely long tickers all day long.
If you want users, don't make the UX complicated. Don't make the system hard to comprehend. Do not try to reinvent the wheel in some "special bitcoin" way. It's a waste of time. Make a tool that allows people to efficiently launch tokens on Bitcoin. That's it. The rest is just dev ego wanting to do something quirky, it won't work.
Source: been shitcoining since Darkcoin
Happy this is an open discussion for what it's worth, even if you guys ignore me and go based off your minimal shitcoin experiences.
Thanks!

non-unique ticker symbol
then combine non-unique ticker symbol + (insert naming service here, e.g. blah.sats) of etching wallet to limit confusion when referring to symbol in dashboards etc

I'm not totally opposed to the symbol + number approach. I still don't totally like it, for reasons aesthetics and confusion, and I think it devalues the original rune, since there are now other runes with the same name.
But I think it's worth considering. So the first rune, let's say PEPE, would just be PEPE, and you could access it at /rune/PEPE. It's natural for me to think of the original PEPE as PEPE zero, but having the next one be PEPE1 might be confusing, since people might assume that PEPE1 was the first. So maybe the next one would be PEPE2. I would probably include a separator. Either PEPE-2, or a middle dot, since they're cute: PEPE·2, and people have kind of become familiar with them from things like DALL·E.

Another possibility is to make symbols unique but optional. If you want to have a unique symbol, you can try to get it. But if you want to rely on the social layer to identify your rune, you can omit the name, and just reference it by the rune ID, which is unambiguous. This kind of combines unique names, plus no names, e.g. if you want a unique name, you can try to get it, but if you don't, you can opt out and just not have a name.

And, yet another possibility to make unique names better, add a spacing character to the characters that can be in a name, so you can break up a long name with spaces, dashes, or middle dots.

Basically, we are looking for a solution on how to make the tickets unique but repeatable (sorry, I'm limited in answering questions correctly © I'm a robot): And so we decided that everything will be unique but will have its own gradation when moving from one to another, we need to find the best solution for this.
Yes it's fine PEPE.2, PEPE·2, PEPE2, PEPE-2, but it's better more readable through dashes for the visually impaired: PEPE-2, or no PEPE2 characters at all.
Name-2, Name2 I think this is the optimal solution, but need an innovative idea for improvement. Perhaps there is a better solution. We need numbering approaches. Please contact the ticket numbering center. Have a nice day everyone! Leonid.sats

And, yet another possibility to make unique names better, add a spacing character to the characters that can be in a name, so you can break up a long name with spaces, dashes, or middle dots.

Basically, we are looking for a solution on how to make the tickets unique but repeatable (sorry, I'm limited in answering questions correctly © I'm a robot): And so we decided that everything will be unique but will have its own gradation when moving from one to another, we need to find the best solution for this.
Yes it's fine PEPE.2, PEPE·2, PEPE2, PEPE-2, but it's better more readable through dashes for the visually impaired: PEPE-2, or no PEPE2 characters at all.
Name-2, Name2 I think this is the optimal solution, but need an innovative idea for improvement. Perhaps there is a better solution. We need numbering approaches. Please contact the ticket numbering center. Have a nice day everyone! Leonid.sats

I've decided to go forward with unique names, but with some things which should help alleviate some of the concerns:

An etching may now not specify a rune, in which case one is allocated automatically. This means that anyone who doesn't care about getting a particular rune can just have one allocated, and consider it an implementation detail. It also means that if a protocol requires etchings to always succeed, they have that option.
@arik-so came up with a really clever way to prevent front-running by committing to a rune, blinding factor, and one of the transaction inputs, which we can implement before mainnet launch.


Add TrustedDomain Authenticator

Fixes #8217 .
Description
Implement a TrustedDomainAuthenticator which allows traffic from pre-configured domain, Ip address to pass.
Configurable properties for the authenticator -
Implement a TrustedDomainAuthenticator which allows traffic from pre-configured domain, Ip address to pass.
Configurable properties for the authenticator -

druid.authenticator.<authenticator_name>.domain (required =  true): trusted domain name or IP address, Authentication will be skipped for any connection coming from a host whose hostname ends with this domain name. If authentication is expected to be skipped for connections from only a given host, fully qualified hostname of that host needs to be specified.

druid.authenticator.<authenticator_name>.useForwardedHeaders : (default= false, required =  false) When trusted domain authentication is enabled, the clients connecting to druid could pass through many layers of proxy. Some proxies also append its own ip address to 'X-Forwarded-For' header before passing on the request to another proxy. Some proxies also connect on behalf of client. if this config is set to true and if 'X-Forwarded-For' is present, trusted domain authenticator will use left most ip address from X-Forwarded-For header.

druid.authenticator.<authenticator_name>.identity (required =  true) - The identity of the requester.

This PR has:

[X] been self-reviewed.
[X] added documentation for new or modified features or behaviors.
[X] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[X] added unit tests or modified existing tests to cover new code paths.

druid.authenticator.<authenticator_name>.useForwardedHeaders

How difficult would it be to spoof the forwarded header? E.g., suppose a user knows the trusted domain but isn't otherwise able to send messages originating from that domain, would they be able to construct a 'X-Forwarded-For' header with an IP/hostname from the trusted domain and get authenticated that way?

@jon-wei : Yes, its possible to spoof X-forwarded header, that is one of the reasons its not allowed by default.

it would be good to add the cautionary note in the doc of druid.auth.authenticator.<authenticatorName>.useForwardedHeaders property to inform user of potential danger of enabling it.

@nishantmonu51 Can you update the docs to caution the user about the possibility of spoofing with the forwarded headers option? LGTM otherwise.

added note.

teamcity build is failing, probably because of newly added checks .. you probably might need to merge master into this branch.

rebased from master, and added spell checking, waiting for travis.


Add close figure to save memory

Overview
Calling data_availibility multiple times creates new figures everytime, and they don't auto close, which is a problem. This PR should address this, by closing figure after creation.

Pull Request Test Coverage Report for Build 245

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 244:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls

@lsetiawan I had similar issue sometime back with matplotlib, apparently plt.close() doesn't release memory properly. So I would suggest something like this which works:
#clear figure first
plt.clf()
#then close figure
plt.close(fig)

@lsetiawan I had similar issue sometime back with matplotlib, apparently plt.close() doesn't release memory properly. So I would suggest something like this which works:
#clear figure first
plt.clf()
#then close figure
plt.close(fig)

Can that be in yodapy data_availibility function?

Seems like if I close the plot before return, I get nothing....

Makes sense, we cannot close it before the return, won't plt.clf() clear the current plot? I think it should be session level clearance. Documentation says Clear the current figure., should we use this in the beginning of data_availability to clear any residual figures?

Let's try that! Great idea :) Thanks!


Cannot change language back to English in Project Manager. Clicking on Language Button auto-selects option.

Godot version:

310496a
OS/device including version:

Ubuntu 20.04
Issue description:

If language is changed in the Project Manager to any other language than English, it cannot be changed back to English. Also clicking on the Change language button auto selects the option from the opened list based on cursor position.
Steps to reproduce:

Compile for Linux as scons -j4 platform=linuxbsd.Now open the Editor build.
Change language to any language other than English.
Now try to change the Language back to English.

Minimal reproduction project:

No project required
Below are some screenshots to better explain the issue.(Note- The cursor is not visible in the screenshots and is thus replaced  by a red dot)

Selecting any other language highlights it and is Clickable.

Selecting English does NOT highlight it and is not Clickable.

Also deleting and recompiling the code in some other folder does not fix the problem and language is still the new one. This setting must have been saved as some form of cache.

Duplicate of https://github.com/godotengine/godot/issues/44230 (same cause).
To reset the language to English, remove $HOME/.config/godot/editor_settings-4.tres.


Update version regex to match other version numbers

Some version numbers for Ghidra don't have 3 parts, only 2.
Will match versions 9.0 and 9.1 as well as 9.0.1, 9.1.2, etc.

looks awesome! I merged it. thank you for your help 😄

Cool :D Any chance you can release a new version with those changes? I'm trying to use it to test and upload compiled releases for this Ghidra processor project beardypig/ghidra-emotionengine :)

Oops sorry, now i released v0.0.2 on marketplace with your fix. can you try it again?
https://github.com/marketplace/actions/setup-ghidra?version=0.0.2
I'm so glad to help your great project. thank you!

Woo! Thank you! It worked. This is the pipeline if you are interested https://github.com/beardypig/ghidra-emotionengine/runs/549426617?check_suite_focus=true


Exception thrown when closing Visual Studio instance

After closing experimental instance of Visual Studio, a System.NullReferenceException is thrown:

Stack trace:
 at Dexter.UI.DexterCommandPackage.UnregisterSolutionManager() in D:\\Projects\\Dexter\\Dexter\\project\\dexter-vs\\Dexter\\Core\\UI\\DexterCommandPackage.cs:line 173
 at Dexter.UI.DexterCommandPackage.Dispose(Boolean disposing) in D:\\Projects\\Dexter\\Dexter\\project\\dexter-vs\\Dexter\\Core\\UI\\DexterCommandPackage.cs:line 167
 at Microsoft.VisualStudio.Shell.Package.Microsoft.VisualStudio.Shell.Interop.IVsPackage.Close()"	string

This does not seem to be a normal shutdown situation.
A experimental instance for the debugging should be closed by 'Stop Dubugging' button of host VS.

This does not seem to be a normal shutdown situation.
A experimental instance for the debugging should be closed by 'Stop Dubugging' button of host VS.

Ok. When instance is closed by 'Stop Debugging' the problem does not occur.
I am closing this issue then.

@KarolAntczak
I deleted my comment because I realized that the basis of what I said was not clear.
I think this issue and fix are reasonable.

Ok. I reopened issue and will apply fix once again.


Code coverage

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@edbadfa). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #216   +/-   ##
=========================================
  Coverage          ?   94.01%
=========================================
  Files             ?       16
  Lines             ?     1003
  Branches          ?        0
=========================================
  Hits              ?      943
  Misses            ?       60
  Partials          ?        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 edbadfa...2b1923d. Read the comment docs.

This is awesome. Thanks!


the tests seem to be breaking

I've tried running the project but I keep getting Uncaught Error: socket hang up

Thanks for the report! Just checked, could not reproduce, so I've added some debug logging to the tests. Could you please try to run DEBUG=koa-easy-ws:test npm run test on the latest commit and paste your console output here?

@b3nsn0w this is the output from the debug
> standard && mocha

  exposed server
  koa-easy-ws:test running test 'exposed' +0ms
    ✓ should be a ws server

  renamed property
  koa-easy-ws:test server started for test 'renamed' +0ms
  koa-easy-ws:test server listening for test 'renamed' +2ms
  koa-easy-ws:test running test 'renamed/sidious' +1ms
    1) should detect 'ctx.sidious' on route '/sidious'
  koa-easy-ws:test running test 'renamed/maul' +9ms
    2) should detect 'ctx.maul' on route '/maul'
  koa-easy-ws:test server closed for test 'renamed' +2ms

  composing with router
  koa-easy-ws:test server started for test 'router' +0ms
  koa-easy-ws:test server listening for test 'router' +0ms
  koa-easy-ws:test running test 'router/obi' +0ms
    3) should connect to handler at '/pow/obi'
  koa-easy-ws:test running test 'router/ani' +2ms
    4) should connect to handler at '/pow/ani'
  koa-easy-ws:test server closed for test 'router' +1ms

  simple example
  koa-easy-ws:test server started for test 'simple' +0ms
  koa-easy-ws:test server listening for test 'simple' +0ms
  koa-easy-ws:test running test 'simple/websocket' +1ms
    5) should reply to websocket
  koa-easy-ws:test running test 'simple/http' +1ms
    ✓ should still handle http
  koa-easy-ws:test server closed for test 'simple' +9ms

  2 passing (44ms)
  5 failing

  1) renamed property
       should detect 'ctx.sidious' on route '/sidious':
     Uncaught Error: socket hang up
      at createHangUpError (_http_client.js:331:15)
      at Socket.socketOnEnd (_http_client.js:423:23)
      at endReadableNT (_stream_readable.js:1064:12)
      at _combinedTickCallback (internal/process/next_tick.js:138:11)
      at process._tickCallback (internal/process/next_tick.js:180:9)

  2) renamed property
       should detect 'ctx.maul' on route '/maul':
     Uncaught Error: socket hang up
      at createHangUpError (_http_client.js:331:15)
      at Socket.socketOnEnd (_http_client.js:423:23)
      at endReadableNT (_stream_readable.js:1064:12)
      at _combinedTickCallback (internal/process/next_tick.js:138:11)
      at process._tickCallback (internal/process/next_tick.js:180:9)

  3) composing with router
       should connect to handler at '/pow/obi':
     Uncaught Error: socket hang up
      at createHangUpError (_http_client.js:331:15)
      at Socket.socketOnEnd (_http_client.js:423:23)
      at endReadableNT (_stream_readable.js:1064:12)
      at _combinedTickCallback (internal/process/next_tick.js:138:11)
      at process._tickCallback (internal/process/next_tick.js:180:9)

  4) composing with router
       should connect to handler at '/pow/ani':
     Uncaught Error: socket hang up
      at createHangUpError (_http_client.js:331:15)
      at Socket.socketOnEnd (_http_client.js:423:23)
      at endReadableNT (_stream_readable.js:1064:12)
      at _combinedTickCallback (internal/process/next_tick.js:138:11)
      at process._tickCallback (internal/process/next_tick.js:180:9)

  5) simple example
       should reply to websocket:
     Uncaught Error: socket hang up
      at createHangUpError (_http_client.js:331:15)
      at Socket.socketOnEnd (_http_client.js:423:23)
      at endReadableNT (_stream_readable.js:1064:12)
      at _combinedTickCallback (internal/process/next_tick.js:138:11)
      at process._tickCallback (internal/process/next_tick.js:180:9)

npm ERR! code ELIFECYCLE
npm ERR! errno 5
npm ERR<EMAIL_ADDRESS>test: standard && mocha

I also tried adding some additional console logs to the index file but the upgrade event doesn't seem to be getting called.

also what version of node are you using?

yup i'm on node 8.11.4

Quick update: on node 8 websocket upgrade requests don't seem to reach the Koa middleware at all, currently trying to figure out why.

I was actually going to message you that and completely forgot. Nodes .on('upgrade') seems to be handled differently. With node 10 coming into lts next month i'm actually fine with upgrading to it. But if you want to make it work for node 8. I tried quite a few things yesterday trying to see what was wrong with the package, didn't know it was a node version thing, and tried to use the package https://github.com/VanCoding/koa-upgrade to see if I could work around the issue. He built the package a while ago, it was for koa 1 , and he captured the upgrade request in a fairly different setup. I've also only started looking into koa, moving over from express, yesterday so you probably have a better understanding of koa's internal workings and might be able to make better use of it.

Seems like WebSocket upgrade requests aren't handled as simple requests by Node's HTTP module prior to version 10, which means they don't get sent through Koa. I've managed to find a workaround:
const server = http.createServer(app.callback())

if (parseInt(process.versions.node) < 10) { // little bit of trickery here, parseInt stops at the first dot
  server.on('upgrade', req => app.callback()(req, new http.ServerResponse({})))
}

server.listen() // use this instead of app.listen()

We're basically injecting the upgrade requests into Koa manually with this technique. The workaround uses a response that's not tied to anything, which does take away your ability to respond as if it was a normal HTTP request, but since the browser expects an upgrade and not an HTTP response this shouldn't happen in practice anyway.
I'm working on a more permanent fix, but for now this seems to clear the tests and not throw any errors in case the route isn't handled. Let me know if it causes any problems in practice for you.

Just saw your comment from an hour ago (didn't load for some reason), that's great stuff. Actually, my motivation was the same, and even managed to do sort of the same thing with the workaround. Thanks for the link.

yup that does seem to solve it

Workaround added to the package itself. FYI, even though this is a minor version upgrade, it will break the manual workaround on node 8, so you'll need to do either of these two things:

Disable the app's workaround. This one is easy, just add an option to the middleware:
app.use(websocket('ws', {noServerWorkaround: true}))

Everything will continue as it did before the update, you will still need your manual workaround in this case. If you'd like to remove that, option 2 is there:

Use the provided workaround. You will need to pass your HTTP server to the middleware.
const server = http.createServer(app.callback())

app.use(websocket('ws', server))

server.listen()

More details here.


Update to semconv 1.22.0

Closing and replacing with #29. The changes in this PR were pushed to a branch on this repo instead of a fork. I'm going to go ahead and delete the update-to-semconv-1.22 branch as well.


[PREVIEW] Add support for PHP

This is a preview to add support for PHP header comments with minimal code changes. I'm not sure if it is a good idea to change the CommentStyle struct this way by adding two new properties ensure_after or ensure_before.
My idea is composing the header license text by ensure_after + header + ensure_before - if the RegEx provided in after yields no results.
Are there other (script) languages which require a similar behaviour?
What do you think about this? Or do you want to discuss this in a dedicated issue?
Some notes:

declare(strict_types=[0|1]); has to be omitted or it has to be the very first statement in the script, which is pretty common in modern PHP code.
empty php files are considered
PHP can be configured to use a short-tag syntax by enabling short_open_tag in php.ini.  <?php then can be written as <?, but even with short_open_tags set to On <?php is still a valid start of a PHP code block.

@heyanlong This is for license check for PHP, welcome to provide feedback.

@emschu hey, thanks for bringing this up.
Is it allowed to have multiple <?php ... ?> in a single .php file, in another word, is the following codes are valid in PHP?
<?php
/**
 * header license comments
 */
?>

<?php
// some real codes
?>

If it's valid, maybe we can simple use the following comment style config,
- id: PHP
  start: |
    <?php
    /*
  middle: ' *'
  end: |
    */
    ?>

multi-line strings in yaml is rather legit and normal.

@ke4qqq Yes, your example is a valid php script syntax. You can read about this topic here.

If a file contains only PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.

For this reason I think it is not a good idea to generally add a php closing tag after the license header in PHP files as this could cause trouble with whitespace or output buffering in pure php files (pure means: non-template PHP code, e.g. class definitions etc.).
I will think about this problem next week again. Enjoy the weekend!


Switch to Babel 7 branch

I think it's interesting to keep the removed/deprecated documentation on the website. What do you think @hzoo @existentialism ?
I will then make a PR to include the archive repo.
I removed the undeclared-variables-check page to be able to build the website but will re-add it from the archive repo.

I would like to keep this PR open. I will try to work on this when I have some time.


Use build-int type React.FC for Counter component

Use build-int type React.FC<> in Counter functional component

No, we definitely do not want to use React.FC:
https://fettblog.eu/typescript-react-why-i-dont-use-react-fc/
https://github.com/facebook/create-react-app/pull/8177


getApi

The getApi form prop also seems to have disappeared? Nothing mentioned about it in the changelog.
I used it to set some form input fields when the form is submitted or when certain keys are pressed during input. The currently listed methods to get access to the api doesn't seem to work from outside the form.

Use formApiRef now . Same thing

Thanks, that worked. Could be useful to add to the migration guide for v4.

There is its in the changelog:) i may be missing some things but its there! Go give it a read

I did a search of the entire repo for getApi and only got one mention of it (from the June 12, 2018 update).  🤔

Yup then i forgot to add that to migration. My bad. I will add

No worries, we figured it out pretty quickly. :)
While you're at it, can you add info about the Text input ( #376)? That's another thing that tripped me up while migrating.

Sure will do!


Mitigate Stale EKS AMI SSM values that drift from MCP values

MCP defines "golden" AMIs for EKS to use.
Unity has SSM params that store these, but they are a copy and can become stale.
See:
https://github.com/unity-sds/unity-cs-infra/blob/b4cf7a5593f8ab7dbeed3243bc8b83f1fb36ee7c/terraform-unity-eks_module/data.tf#L27-L36
and
#
# Create SSM:
#
EKS_AMI_25_SSM="/unity/account/eks/amis/aml2-eks-1-25"
EKS_AMI_25_VAL=$(get_ssm_val "/mcp/amis/aml2-eks-1-25")
refresh_ssm_param "${EKS_AMI_25_SSM}" "${EKS_AMI_25_VAL}" "processing" "na" "vpc" "unity-all-cs-processing-aml2Eks125Ssm"

#
# Create SSM:
#
EKS_AMI_26_SSM="/unity/account/eks/amis/aml2-eks-1-26"
EKS_AMI_26_VAL=$(get_ssm_val "/mcp/amis/aml2-eks-1-26")
refresh_ssm_param "${EKS_AMI_26_SSM}" "${EKS_AMI_26_VAL}" "processing" "na" "vpc" "unity-all-cs-processing-aml2Eks126Ssm"

#
# Create SSM:
#
EKS_AMI_27_SSM="/unity/account/eks/amis/aml2-eks-1-27"
EKS_AMI_27_VAL=$(get_ssm_val "/mcp/amis/aml2-eks-1-27")
refresh_ssm_param "${EKS_AMI_27_SSM}" "${EKS_AMI_27_VAL}" "processing" "na" "vpc" "unity-all-cs-processing-aml2Eks127Ssm"

We need a better way to keep these values up to date in a venue account, so that new EKS nodes are created with the correct AMI. The above unity params are copies of the current MCP SSM values.  Ultimately the MCP values are better/more-up-to-date, so perhaps it's not worth actually making a copy.

How do we know when MCP updates the list of Golden AMIs? If we get a notification, can we automatically create a GitHub ticket for CS (or someone else) to update the values in the SSM paramaters?

@LucaCinquini , @drewm-jpl , @mike-gangl , per MCP's documentation:
New versions of the MCP-provided Golden AMIs are regularly released on the 15th day of each month.  Additionally, out-of-cycle "hotfix" releases may be required to address critical needs.  The contents of this page identify the changes made, or planned, for each AMI release.

I don't think there is some sort of event notification.
I think the best thing to do is to:

Don't rely on the /unity/account/eks/... params, but instead rely on /mcp/amis/aml2-eks-1-* params
Revisit this on a monthly basis (after the 15th of each month)
At most, wait 4-5 months, as their docs state a 5-month deprecation cycle

See also:
https://jaas.gsfc.nasa.gov/servicedesk/customer/kb/view/103025969?applicationId=8c3b2903-5e4d-3c45-9881-7ac650c5cf0b&spaceKey=GSD1&portalId=2&title=MCP Golden AMI Changelog
https://caas.gsfc.nasa.gov/plugins/servlet/remotepageview?pageId=19041164#MCPAMIConfigurationandUsage-HowLongareAMIsAvailable?

also from their docs:
Notifications
MCP will update the MCP Golden AMI Changelog with planned changes at least five business days prior to the regular monthly release.
MCP will update the MCP Golden AMI Changelog with verified changes within at least two business days of the regular monthly release after performing any necessary verification.
MCP will notify tenants via the Tenant Notifications Teams Channel when one or more of the following changes are included within the list of planned changes to MCP Golden AMIs:
New AMI classifications/OS
Notable modifications to base AMI (e.g. new CSET standard or Python version)
Notable modifications to MCP-installed services (e.g. Vector or Kinesis) within an AMI


Multiple Selection area on same image

Is there any future or currently under development feature to select multiple cropper area on the same image?

I need this functionality, is it in your plans to add it?


State workers having trouble with access

Hey guys.  A few state workers this morning reported trouble accessing the site.  I told them to use the browser Edge, but it didn't help.  They have alerted their IT dept, but I want to make sure it's nothing we can prevent on our end!  Thanks

What kind of trouble are they having? Like they can't access it at all? Does anything on the page load?

Sounds like the page wouldn't even load.  It took an entire day, but the IT guy on site was able to work around their security.  I just don't understand why these offices aren't operating under universal IT security rules.  Seems like it should all be the same across the board!
I just wanted to make sure it wasn't something on our end, since there were two offices having trouble yesterday.  Thanks!


Error: runOnUI() can only be used on worklets, js engine: hermes

<EMAIL_ADDRESS>It shows error:
Error: runOnUI() can only be used on worklets, js engine: hermes

Try version 6.0.0-rc.0
Fixed in #322

Try version 6.0.0-rc.0
Fixed in #322

Thank you for the reply ! But I didn't find a released package in npm, When will it become released ?

It's released as a release candidate under that tag: https://www.npmjs.com/package/react-native-collapsible-tab-view?activeTab=versions

I got it! Thank you very much!
------------------ Original ------------------
From: Andrei Alecu @.>
Date: Sat,Mar 4,2023 10:45 PM
To: PedroBern/react-native-collapsible-tab-view @.>
Cc: 刘力瑞 @.>, Author @.>
Subject: Re: [PedroBern/react-native-collapsible-tab-view] Error: runOnUI() can only be used on worklets, js engine: hermes (Issue #321)
It's released as a release candidate under that tag: https://www.npmjs.com/package/react-native-collapsible-tab-view?activeTab=versions
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Just released version 6.0.0 as a major. It fixes another issue I recently found. Please update to the latest and let me know if you find any issues.

Note that I noticed an issue with Reanimated 3.0, for which I opened an upstream report here: https://github.com/software-mansion/react-native-reanimated/issues/4168

I tried 6.0.1 just now, but it seems like something wrong in second tab:
https://user-images.githubusercontent.com/16587763/222939339-7613c3d3-f822-4b6f-8627-a3134d1c6592.mp4
And My codes below:
`
<Tabs.Container
renderHeader={renderHeader}
renderTabBar={renderTabBar}
headerContainerStyle={byStyle.transparent}>
<Tabs.Tab name="image">

</Tabs.Tab>
<Tabs.Tab name="comment">

</Tabs.Tab>
</Tabs.Container>
const PositionOneImage = (
<Tab.Flatlist />
)
`

I found that it will happen when the Tab.FlatList data doesn't fill all the screen.
Change the example file:https://github.com/PedroBern/react-native-collapsible-tab-view/blob/main/example/src/Shared/QuickStartDemo.tsx
from const DATA = [0, 1, 2, 3, 4]  to const DATA = [0] can show this problem

Version 6.1.1 supports the latest reanimated.


Travis: various tweaks

Run against the highest stable PHP version for the sniff/rulesets build (+ the dev-master quicktest build).
Only run composer validate on the sniff stage.
The composer.json file will be validated on the install for the all builds anyway. This just adds the strict checking.
Add an extra test build against PHPCS 4.x for which development has just started.
This build is allowed to fail for now.
Remove the DealerDirect plugin for the build against nightly. It is not needed anyway as a --no-dev install is done for the test stages and the installed_paths is set directly.
The DealerDirect plugin currently won't install on PHP 8.x, so the build would fail on "failure to install" before doing anything.
This way, the linting and unit tests should still run on nightly.

The changes I made in this PR exposed a PHP 7.4 related bug. PR #1858 should fix that bug. I will rebase this PR after that one has been merged so we can see a passing build (or not in which case I will look at what else is failing :confused: )

Rebased after the merge of #1858 and did some more tweaking and we now have a passing build (including running builds for PHP 8/nightly and PHPCS 4.x-dev, though the PHPCS 4.x-dev one currently doesn't pass, but that's unrelated to the Travis script) :tada:


Do not load stripe script anywhere and opt-in when needed

This PR updates the header templates to not load stripe scripts by default. We only have 3 pages that need it, but are loading it everywhere, which adds up extra page load time. Instead, we should opt-in only when necessary rather than loading it on every page.

I assumed we are only dealing with desktops in this PR. We may also want to do similar things later for mobile, as the difference might be more significant.

It seems like I missed one page and I'll have to update the PR. Until then this PR should be marked as WIP.

@starsirius Yes, I only focused on Desktop to make the footprint shorter and also familiarize myself with the globally loaded scripts. Once I review all the scripts I'll do the same to mobile.

This PR is now ready for a merge.

Thanks, @yuki24! We should do some more tests in staging, especially for auction use cases.

Looks like Stripe is recommending including stripe.js on every page of the website to help detect fraud behavior. We might consider bringing this back (maybe when we switching over to stripe.js v3/Elements).

To best leverage Stripe’s advanced fraud functionality, include this script on every page on your site, not just the checkout page. Including the script on every page allows Stripe to detect anomalous behavior that may be indicative of fraud as users browse your website.

cc @sweir27

Interesting. sounds like we should bring it back in, it shouldn't affect the load time very significantly.


Unreliable hitrate checking IPs.

Notice: Please don't file a bug report for questions on how to use ZMap, etc. Check out our Resources section for FAQ and feel free to chime in on Github Discussions if you're still unclear and we'll be happy to assist!

Describe the bug
Using ZMap to search the following IPs for all open ports, I am getting barely any valid results. Whilst switching to masscan it works just fine. Any ideas?
(Masscan does not support multi-threading like ZMap so it's painfully slow to use, looking to make ZMap work)
CLI Arguments
Please paste your ZMap invocation below
zmap -p 0-65535 -I "ips.txt" -o "save.txt" -B 10G

Example Target IP
Small list, checking 442k IPs.
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
<IP_ADDRESS>
Expected behavior
Higher hitrate like on masscan.
Environment:

OS: Ubuntu server 22.04
Version: zmap-4.0.0-RC1

Additional context
Don't know if it's just how ZMap works or I did something wrong.

Hey @Outcalled, thanks for raising this issue! Sorry you didn't get the hit-rate you were expecting.
Can you provide a bit more details so I can triage this? Specifically:

What hit rate did you observe with ZMap? When I just ran a test with your list of IPs, I got a hit-rate of 9.87% with the small list you provided.

Can you attach your input list of IPs?

What hit-rate did you observe with masscan/did you expect to get with ZMap and please provide what you ran to get that hit-rate.
Can you describe the networking IRT the Ubuntu Server 22.04? What's the bandwidth available to it, any firewalls in between you and your ISP,....

Without knowing what your expected hit-rate is compared to observed, I won't be able to identify if this is a ZMap issue or something with your setup.

No firewalls seem to be set, 10 GB bandwidth. I was getting 0.00% hitrate on zmap, maybe my configuration is wrong? What build did you use and config?

Hitrate on masscan I have no idea as it doesn't really tell, but it's extremely big.

I think I figured out the issue, zmap is just worse for multi-port checking because it does not check the same IP 65k times, it just checks for 1 open port and that's it. Masscan is superior <3

This is not how ZMap works, but I don't get the sense you're looking to productively engage here, so I'm going to close this issue. I'm glad you were able to do what you needed with Masscan.


No colors

Hello
I use Blender 3.3.1
The file imported without colors, is this a bug or it works like that?

Hey, check out this: https://github.com/paireks/dotbim-blender#how-to-see-colors
Side-note: face_colors from 1.1.0 schema are still not supported, cause I had some issues to implement them properly. But normal colors should be fine.

Thanks, yes it work
I add this to create materials, it is faster than Rhino.
matg = bpy.data.materials.new(f"{elt.type}") matg.diffuse_color = obj.color obj.active_material = matg

Yeah, the only issue you will have then is that after export from Blender doesn't use materials currently :)
If I remember correctly @Gorgious56 decided to stick to colors inside mesh to make things simplier. But maybe it's good to do something similiar to Grasshopper and allow 2 versions, one with colors inside mesh and one with materials :)

From Blender when export obj the materials exported as mtl file which can viewed and edited with text editor
newmtl Material
Kd 0.0 0.8 0.02         # rgb color

newmtl Material.001
Kd 0.800000 0.00 0.03          # rgb color
d 0.4        # tranparency = 1-d

Rhino or any other software import the mtl file as materials, maybe you can do the same, and other settings of the mtl file explained here:
https://en.wikipedia.org/wiki/Wavefront_.obj_file
Maybe it is easy to added

The color is associated to the object (object.color), specifically this property

At the time polygon colors weren't part of dotbim schema but it should be relatively straightforward to add.
https://github.com/paireks/dotbim-blender/blob/0575aa482f42294d5de56a31b46c4a7cbed2c1c5/dotbim_to_blender.py#L40
It didn't make sense to add a material since AFAIK dotbim doesn't support custom shaders so defaulting to a single unlit color would save a bit of processing ressources. As I understand dotbim now supports vertex (or face ?) colors so that could be added as an attribute. Or a default emissive / principled bsdf material. that could be an option in the importer, using something akin to the 3 lines of code of @seghier to add a default material.
It also made more sense for roundtripping dotbim <> Blender since a material can be tied to many different colors so it would be a matter of preference which one should be exported and it roundtripping is harder (potential loss of information). Although I don't think it matters that much since dotbim (AFAIK, pls correct if it does) doesn't support material / shader defintion apart from a single color.
@paireks I might have a bit of time this week to update dotbim>blender and blender>dotbim, would you accept if I tried to implement it ? What features would you like ?

Haha I just reopened my vscode workspace and I totally forgot that I already started working on this a year and a half ago...

I just have one question @paireks which version do you want to support ? The mesh color API has evolved a lot since I think version 3.5 where vertex color layers have been dropped in favor of color attributes. We can support both relatively easily but it's a bit of extra work and support down the line.

@Gorgious56 yes, dotbim doesn't support materials in that sense, only colors. So I think you're right with giving up on materials.
With face_colors added in 1.1.0 there is color for each face. That's the only missing feature I think. If you could try this I will be very happy, cause I tried it, but had some difficulties with it.
Regarding Blender's version: it's up to you, I will adapt to your decision :)

@Gorgious56 also here are example files that uses face_colors for tests:

from Archicad: https://3dviewer.net/#model=https://raw.githubusercontent.com/paireks/dotbim/master/test/ExampleFiles/TestFilesFromArchicad/MulticolorHouse.bim
another one from Archicad:
https://3dviewer.net/#model=https://raw.githubusercontent.com/kovacsv/dotbim-archicad/main/Examples/MiniRoom.bim
from C#: https://3dviewer.net/#model=https://raw.githubusercontent.com/paireks/dotbim/master/test/ExampleFiles/TestFilesFromC%23/CubesWithFaceColorsAndWithout.bim

And side-note that dotbimpy has updated to support these face_colors :)

So while writing the PR I also remembered why I didn't use materials. Linked meshes must share the same materials, so you can't have linked meshes with different colors. Well you can store the materials on the object but that's an obscure feature. I can add this as an option if need be, it shouldn't be too hard, let me know. Cheers

@Gorgious56 thank you very much! For me it works great!

I will add a post on Linkedin about an update if you don't mind :)

Hehe please do. Happy to help. I think this issue can be closed since the latest few commits.
Cheers


Unhandled Exception: Parameter name: paths when trying to start use supervisor on Ubuntu

I create a new ASP.Net MVC Core application (2.1.3 sdk) and publish it to my Ubuntu 16.04 server.
Running it with dotnet works but if I try to use supervisor to manage this I get the error below. This is something that works on a quite a few other servers but it seems to be an issue with later versions.

Unhandled Exception: System.ArgumentNullException: Value cannot be null.
Parameter name: paths
at System.IO.Path.Combine(String[] paths)
at Microsoft.Extensions.Configuration.UserSecrets.PathHelper.GetSecretsPathFromSecretsId(String userSecretsId)
at Microsoft.Extensions.Configuration.UserSecretsConfigurationExtensions.AddUserSecrets(IConfigurationBuilder configuration, String userSecretsId)
at Microsoft.Extensions.Configuration.UserSecretsConfigurationExtensions.AddUserSecrets(IConfigurationBuilder configuration, Assembly assembly, Boolean optional)
at Microsoft.AspNetCore.WebHost.<>c__DisplayClass8_0.b__0(WebHostBuilderContext hostingContext, IConfigurationBuilder config)
at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors)
at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
at MyLifeline.Signals.Program.Main(String[] args) in C:__Repos\MyLifeline.Signals\MyLifeline.Signals\Program.cs:line 17

Not sure why supervisor does not work anymore, but anyway, found this article from Microsoft to use systemd instead of supervisor and it worked first time. If you experience the same issue then view this article, super easy to implement.
https://docs.microsoft.com/en-us/aspnet/core/publishing/linuxproduction?tabs=aspnetcore2x


Configured to process generic/lancache

Run steamcache and bind it to whatever IP it needs.
Run lancache / generic and bind to the second IP (configure in /etc/network/interfaces/)
Run steamcache-dns and pass it STEAMCACHE_IP= and LANCACHE_IP=

There's a few changes here, so we need to check everything is OK before we merge your PR, However, Thanks for your contribution.