🚀 Feature: Migrate backstage-cli new plugin template to React 18 and MUI 5

🔖 Feature description
We are migrating our company's Backstage repo to React 18 and MUI 5 and we are heavily using plugins for separation of concerns. We migrated all the existing ones, but backstage-cli new keeps creating plugins with MUI 4 and React 16/17.
This means that we would need to do the migration again each time when creating a new plugin.
I understand that updating the template to newer versions at once can create issues for repos, that still use older setup, but with Backstage's dual support of MUI versions and an eventual removal of React 16 support I think creating newer plugins in older monorepos would work.
I want to hear your thoughts on the matter and how you envision this transition.
Supporting scaffolding of plugins for both MUI versions (with some flags) may be a toll task, considering eventually we will remove MUI 4 support completely.
🎤 Context
We are migrating existing plugins to newer versions of React and MUI, however we frequently create new plugins, particularly FE ones. Therefore scaffolding an old setup and then manually updating to the new one kinda beats the idea of automated scaffolding and naive folder copy-paste could become an easier option.
In most cases, migration would require only changing package.json version as I usually just delete example components.
However ideally the whole template should provide MUI 5 code.
✌ Possible Implementation
We can probably make a hard switch of the plugin template when we have enough confidence in backward-compatibility. This is probably the easiest solution for the maintainers and yet another nudge towards a migration for others.
We can also maintain both versions either as additional options in the existing template or having a completely different template for MUI 5 plugin
👀 Have you spent some time to check if this feature request has been raised before?

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

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, I don't have time to work on this right now

I think there's still some work to be done on the React 18 front for our repo too, as well as the MUI parts still settling.
See https://github.com/backstage/backstage/pull/18243 for example.
I think that we want to make sure that we've covered off some of the MUI issues that we're seeing pop up before we make it the default - but don't see an issue after doing that.

Going to reopen this as it's something we will do just need to get further along with some of the migration bits


I wan't draw an  image with png,but PDFImage force covert to jpg,

draw an png can support Vector Image, now,my image are blurry, so, can your give me some advise how to achieve it ~

I found you set pdf dpi to 72.can this variable been set by custom?


 Could this behavior be because the input is super sparse, so it's better a small input size? However, it is odd that adding bigger internal layers seems to work better.

Did you have time to do some experiments on your side?

Thanks @miguelgfierro for sharing your experiments!
I think the main reason “inverse” pyramids work better is because then first layer is not as heavy as in the “classical” and therefore overfitting is less likely which is important for smaller datasets like this.
BTW, is this movielense 1M or 20M?
I’ll set up some experiments to run over the weekend to see if we can improve this RMSE. What was the best you’ve got using ALS on the same dataset?

Hey, I updated the initial comment with more results.
I'm using movielense 20M.
The best result I got for now is: h256.256.256.256.512_lr0.005_dp0.8_bs32_aug0_ep50_wd0.00001_elu, Process time 7876s, RMSE: 0.8208981665592793
I did experiments with Movielens 20M in databricks with sparkml ALS and also using the implementation with GPU of spotlight. Using rank 12 I got 0.80.
The only problem is that I haven't used the exact same partition of the dataset in the 3 experiments, however, using two different partitions with ALS in databricks and spotlight I got similar results. One of my next steps is to create a common partition repeat the experiments on the 3 frameworks.

Hi,
Can you please help me understand how can i set up the environment on GCP? I am somehow not able to set it up properly.
2. can you also share a sample of final .txt file , folder structure , data formats used etc. I am running into multiple errors such as

609-817-4186

"invalid literal  for int() with base10: '1,2003,Dianosaur plane"
Please help!!

@vaidoorya apparently your input is in the wrong format. Follow the Readme with Netflix data and then make sure your data follows the same format

I was’nt able to prepare the data using the code, some error kept on coming – can you atleast let me know the format used to run the codes?
From: Oleksii Kuchaiev<EMAIL_ADDRESS>Sent: Saturday, March 3, 2018 9:47 AM
To: NVIDIA/DeepRecommender<EMAIL_ADDRESS>Cc: Vaidoorya Agarwal (Big Data Analytics<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [NVIDIA/DeepRecommender] Movielens experiments (#11)
** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution**
@vaidooryahttps://github.com/vaidoorya apparently your input is in the wrong format. Follow the Readme with Netflix data and then make sure your data follows the same format
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/NVIDIA/DeepRecommender/issues/11#issuecomment-370116269, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANG4r4U1caGtmQbhyWq9uvI3bXNXexDrks5tahlVgaJpZM4SB7TH.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com


async client: fix immediate response when request has body

regression from https://github.com/lyft/envoy/pull/353

@lyft/network-team @lizan

Oops, thanks for fixing that!


SR 4232

What's in this pull request?

A clarification of an error message

If this pull request resolves any bugs in the Swift bug tracker, provide a link:

Resolves SR-4232.

Please test with following PR:
https://github.com/apple/swift/pull/8140
@swift-ci Please test macOS platform

Ah, outside contributors can't trigger PR testing.
@swift-ci Please test macOS

@swift-ci Please smoke test

On Mar 15, 2017, at 6:20 PM, Jordan Rose<EMAIL_ADDRESS>wrote:
@jrose-apple commented on this pull request.
In include/swift/AST/DiagnosticsSema.def https://github.com/apple/swift/pull/8140#discussion_r106321122:

@@ -2952,7 +2952,7 @@ ERROR(invalid_nonobjc_decl,none,
ERROR(objc_in_extension_context,none,
"members of constrained extensions cannot be declared @objc", ())
ERROR(objc_in_generic_extension,none,

 "@objc is not supported within extensions of generic classes", ())

 "@objc is not supported within extensions of generic classes, or classes that inherit from generic classes", ())

I hate to be this nitpicky but I don't think we should use the comma. The diagnostic is one thought.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/apple/swift/pull/8140#pullrequestreview-27237629, or mute the thread https://github.com/notifications/unsubscribe-auth/AFUwoWzQGwhIUweagyE2oAbCJISya_9Oks5rmI5hgaJpZM4MeuOl.

K. Do I fix it on my end and resubmit, or do you fix it on your end?

@swift-ci Please test macOS

@swift-ci Please smoke test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 1a2703307ee42318ccbe729cb99cf2562bb22bd8
Test requested by - @jrose-apple

That's... normal? I committed the comma fix to my fork and this seems to have automatically picked up the change. I didn't know it could do that.

Yeah, don't worry about it.  The build has been auto-restarted and is still running.

Linux failure here: https://ci.swift.org/job/swift-PR-Linux-smoke-test/5781/testReport/junit/Swift(linux-x86_64)/decl_ext/extension_generic_objc_swift/
It tried to run your new test even though Linux Swift doesn't support Objective-C. You can disable this by adding // REQUIRES: objc_interop to your test file, below the RUN lines.

Ah, so that's what that line was for! I'll add it back in when I get home.

I don't have a linux box (yet) to test myself, but it should be working now.

@swift-ci please smoke test

Merged. Thanks, Dave!


Cookie expiration always set to Session

Seems like the Identity application cookie is always set to Session even when the expiration TimeSpan is set. I'm using .NET Core 2.0.
services.ConfigureApplicationCookie(options =>
    {
        // Cookie settings
        options.Cookie.HttpOnly = true;
        options.Cookie.SecurePolicy = MyAppConfig.Secure ? CookieSecurePolicy.Always : CookieSecurePolicy.None;
        options.Cookie.Name = "IbIdentity";
        options.Cookie.Expiration = TimeSpan.FromMinutes(30);
        options.ExpireTimeSpan = TimeSpan.FromMinutes(30);
        options.SlidingExpiration = true;
    });

ExpireTimeSpan and SlidingExpiration are mutually exclusive.
Making it permanent is a function of the call to SignIn
await _signInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, lockoutOnFailure: false);

The third parameter, RememberMe is what you want

Thank you @blowdart. What I'm trying to achieve is for Identity to authorize the user for sliding time period of 30 minutes.
With the settings above and setting rememberMe: true during SignIn is that achieved? I can see the cookie being set with an expiration date and that it "slides" with additional requests but I want to make sure Identity is also set to have the authorization work the same way.

I believe you don't need to set options.Cookie.Expiration, just the ExpireTimeSpan and set Sliding. Is that right @HaoK ?

As far as the cookie on the client that seems to be the case. I can remove it and behavior stays the same.
What I want to confirm too is that even though the cookie is set to expire, if someone were to try to use that cookie after the expiration will the server invalidate the request?

Yeah options.SlidingExpiration  = true and options.ExpireTimeSpan

Yes, see https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication.Cookies/CookieAuthenticationOptions.cs#L140

Thanks so much @blowdart and @HaoK ! Really impressed with the work being done! Thanks again!

Just to be clear for others who end up here the expiry of a ticket is a property of the ticket itself, not the cookie. So even if the cookie lives on the expiry date is baked into the data it contains, so after it expires, it's dead regardless.

@blowdart meaning the expiration of the cookie is tied to the expiration of the ticket. So even if someone tried to fudge the cookie expiration the server will reject it?

Correct :)

Yeah this is why the options.Cookie.Expiries property is ignored for cookie authentication, its that embedded expiry date in the data that matters.


Research: Can we use OfflineSigner for Stargate?

Can we use the existing OfflineSigner interface for Stargate transactions?

If yes, great, done.
If no, can we adjust it slightly to only need one interface for Launchpad and Stargate?
If yes, great, let's do that.
If no, create a similar interfce for Stargate

One point that is likely different is the concept of "SignMode". Currently DIRECT (what we support in software) or LEGACY (amino-style, which the ledger uses).
This must be selected by the Signer (most implementations only support one), and both formats should be able to be derived from the TxInfo (which is slightly different than launchpad I think). One catch is that, especially in multisig, the desired signing mode of all parties needs to be specified BEFORE anyone can sign.
Thus, I would propose a second method like signMode() -> string that returns the sign mode the OfflineSigner implementation uses. This can be queried (from all signers) to properly build the TxInfo bytes. Then, they can just sign using the same algorithm. Different signers can use either algorithm. Ledger support demands this and is a good case to ensure we can get this proper.

It is good to look at the TxInfo from stargate, not sure if that can be unified with launchpad signing

Our current OfflineSigner has a sign method with this signature:
readonly sign: (signerAddress: string, signDoc: StdSignDoc) => Promise<SignResponse>;

where a StdSignDoc is:
interface StdSignDoc {
  readonly chain_id: string;
  readonly account_number: string;
  readonly sequence: string;
  readonly fee: StdFee;
  readonly msgs: readonly Msg[];
  readonly memo: string;
}

In order to support SIGN_MODE_DIRECT using the existing interface, we need the following in order to generate a Uint8Array representation of a transaction:

chainId (same as chain_id in StdSignDoc)
accountNumber (equivalent to account_number in StdSignDoc)
txBody requires

memo (same as memo in StdSignDoc)
msgs which are equivalent to msgs in StdSignDoc but would need to be converted, in particular to swap the Amino type field for a typeUrl field

authInfo requires

sequence (equivalent to sequence in StdSignDoc)
feeAmount and gasLimit (equivalent to fee in StdSignDoc)
pubkeys which should be known by the signer given the signerAddress

So it's possible to keep the existing interface. The cost is continuing to support/promote the Amino-friendly Msg format, and convert back and forth a lot. It's also unclear whether we'll continue to be able to use this interface with future sign modes (see https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-020-protobuf-transaction-encoding.md#future-improvements).
As a result I propose (in https://github.com/cosmos/cosmjs/pull/482) adjusting the sign method type signature to accept a "sign job", which specifies the sign mode as well as the content to be signed. We can require signers to expose a signModes property which lists sign modes supported by the signer (a list rather than a string in case signers support multiple modes). We also future-proof ourselves against the expected additional sign modes like SIGN_MODE_TEXTUAL.


Golang Debug 失败

GOROOT=E:\software\Go1.9.2 #gosetup
GOPATH=E:\SourceCode\GO_CODE #gosetup
E:\software\Go1.9.2\bin\go.exe build -o C:\Users\Administrator\AppData\Local\Temp___main_go.exe -gcflags "-N -l" -a E:/SourceCode/GO_CODE/src/gzweb/main.go #gosetup
github.com/go-xorm/xorm
..\github.com\go-xorm\xorm\engine_group.go:36:10: engine.engineGroup undefined (type *Engine has no field or method engineGroup)
..\github.com\go-xorm\xorm\engine_group.go:48:9: master.engineGroup undefined (type *Engine has no field or method engineGroup)
..\github.com\go-xorm\xorm\engine_group.go:50:13: slaves[i].engineGroup undefined (type *Engine has no field or method engineGroup)
..\github.com\go-xorm\xorm\engine_group.go:120:11: eg.Engine.SetLogLevel undefined (type *Engine has no field or method SetLogLevel)
..\github.com\go-xorm\xorm\engine_group.go:122:15: eg.slaves[i].SetLogLevel undefined (type *Engine has no field or method SetLogLevel)
..\github.com\go-xorm\xorm\interface.go:100:2: cannot use Session literal (type *Session) as type Interface in assignment:
*Session does not implement Interface (wrong type for Query method)
have Query(string, ...interface {}) ([]map[string][]byte, error)
want Query(...interface {}) ([]map[string][]byte, error)
..\github.com\go-xorm\xorm\interface.go:101:2: cannot use Engine literal (type *Engine) as type EngineInterface in assignment:
*Engine does not implement EngineInterface (missing GetColumnMapper method)
..\github.com\go-xorm\xorm\interface.go:102:2: cannot use EngineGroup literal (type *EngineGroup) as type EngineInterface in assignment:
*EngineGroup does not implement EngineInterface (missing GetColumnMapper method)
Process finished with exit code 2

@bensinos don't know what you mean. Please confirm you have update xorm correctly.
go get -u -v github.com/go-xorm/xorm.

E:\SourceCode\GO_CODE\src\gzweb>gopm list
Dependency list (7):
-> github.com/achiku/xml
-> github.com/astaxie/beego @ tag:v1.9.0
-> github.com/dgrijalva/jwt-go
-> github.com/go-sql-driver/mysql
-> github.com/go-xorm/xorm @ tag:v0.6.4
-> github.com/satori/go.uuid
-> github.com/xuri/excelize
最新版本，在mac下可以。但在windows下不行。

应该是一样的啊


1.7.0 --net=host doesn't work with bridge=none

There's a regression in docker 1.7.0
"docker run --net=host" doesn't work with "docker -d --bridge=none"
We need --bridge=none (as well as --ip-forward=false --ip-masq=false --iptables=false) since we need to be able to push quite a lot of traffic (over 10Gbit/s) to / from the services running in the containers, so docker can't modify host networking at all.
docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Get http:///var/run/docker.sock/v1.19/version: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
This works:
/usr/bin/docker -d
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
INFO[0008] [graphdriver] using prior storage driver "btrfs"
WARN[0008] Running modprobe bridge nf_nat failed with message: , error: exit status 1
INFO[0009] Loading containers: start.
............
INFO[0009] Loading containers: done.
INFO[0009] Daemon has completed initialization
INFO[0009] Docker daemon                                 commit=0baf609 execdriver=native-0.2 graphdriver=btrfs version=1.7.0
INFO[0013] POST /v1.19/containers/create
INFO[0013] POST /v1.19/containers/59083f45c267c89c905a42d7ab43e9e05b2432b0afcf699727ef41efae7e9ce0/attach?stderr=1&stdin=1&stdout=1&stream=1
INFO[0013] POST /v1.19/containers/59083f45c267c89c905a42d7ab43e9e05b2432b0afcf699727ef41efae7e9ce0/start
INFO[0013] No non-localhost DNS nameservers are left in resolv.conf. Using default external servers : [nameserver <IP_ADDRESS> nameserver <IP_ADDRESS>]
INFO[0013] POST /v1.19/containers/59083f45c267c89c905a42d7ab43e9e05b2432b0afcf699727ef41efae7e9ce0/resize?h=24&w=80
INFO[0014] GET /v1.19/containers/59083f45c267c89c905a42d7ab43e9e05b2432b0afcf699727ef41efae7e9ce0/json
^CINFO[0016] Processing signal 'interrupt'
docker run --net host -i -t ubuntu ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet <IP_ADDRESS>/8 scope host lo
valid_lft forever preferred_lft forever
inet <IP_ADDRESS>/32 scope global lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: p2p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether xx:xx:xx:96:9f:b4 brd ff:ff:ff:ff:ff:ff
3: p2p2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether xx:xx:xx:96:9f:b5 brd ff:ff:ff:ff:ff:ff
4: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master lan state UP group default qlen 1000
link/ether xx:xx:xx:ab:c7:50 brd ff:ff:ff:ff:ff:ff
5: em2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master lan state UP group default qlen 1000
link/ether xx:xx:xx:ab:c7:50 brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default
link/ether xx:xx:xx:16:ef:b5 brd ff:ff:ff:ff:ff:ff
This doesn't work:
/usr/bin/docker -d --bridge=none
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
^Croot@master-s1:~# /usr/bin/docker -d --bridge=none
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
INFO[0006] [graphdriver] using prior storage driver "btrfs"
INFO[0006] Loading containers: start.
..............
INFO[0006] Loading containers: done.
INFO[0006] Daemon has completed initialization
INFO[0006] Docker daemon                                 commit=0baf609 execdriver=native-0.2 graphdriver=btrfs version=1.7.0
INFO[0006] POST /v1.19/containers/create
INFO[0006] POST /v1.19/containers/6ff79398d247dc56d9720547e28d545f3f4fc0cdb5f5cc44aa0210c61d253268/attach?stderr=1&stdin=1&stdout=1&stream=1
INFO[0006] POST /v1.19/containers/6ff79398d247dc56d9720547e28d545f3f4fc0cdb5f5cc44aa0210c61d253268/start
INFO[0006] POST /v1.19/containers/6ff79398d247dc56d9720547e28d545f3f4fc0cdb5f5cc44aa0210c61d253268/resize?h=24&w=80
INFO[0007] GET /v1.19/containers/6ff79398d247dc56d9720547e28d545f3f4fc0cdb5f5cc44aa0210c61d253268/json
docker run --net host -i -t ubuntu ip addr show
1: lo:  mtu 65536 qdisc noop state DOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

docker info
Containers: 8
Images: 14
Storage Driver: btrfs
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.17.0-031700-generic
Operating System: Ubuntu 14.04 LTS
CPUs: 24
Total Memory: 47.13 GiB
Name: master-s1.r1.xxx
ID: JZWZ:3O5P:IUDG:ESMQ:2ZEF:U6Q4:5IR3:QKGD:ERLZ:RUP5:64AF:KPWR
uname -a
Linux master-s1.r1.xxx 3.17.0-031700-generic #201410060605 SMP Mon Oct 6 10:07:09 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I'm pretty sure this affects CoreOS 723.0.0 (coreos/manifest@a197f13a73936c307a8f75f77f4e419be27e0d31) as it uses --bridge=none for early-docker.service and --net=host for flanneld.service.

I've modified a couple of tests to detect this bug:
https://github.com/dit4c/docker/tree/14106-bug-detection
The bad behaviour only occurs with --bridge=none, which is how it was probably missed.
I ported the tests back to 1.6.2, and they pass:
https://github.com/dit4c/docker/tree/14106-bug-detection-1.6.2

@cetex @tjdett I have identified the issue and am working on a proper solution.
This is a classic case of incorrect variable names and code assumptions leading to incorrect behavior.
Also, there are some inherent assumptions on what bridge=none really means ?
Will push PR shortly that will address this issue.

I assume bridge=none means that docker won't use a bridge and won't try to setup a bridge. This combined with all the other options we use should mean that docker won't try to do anything "automagically" at all when it comes to networking. and if we want networking in a container we need to specify "--net=host". :)

This is already in master and will be released in 1.7.1 as part of #14264.
Closing, thanks for reporting this issue! :metal:


Show your pending review status in the PRs list

Description
In the PRs list (/pulls) if you hover on a pr, you can see at the bottom a small message saying if the pr needs your approval or not:

This information is not available in the list itself, so you cannot see at-a-glance the prs that needs your approval.
I know you can filter the prs to only show those awaiting review from you, but having the icon/text in the list itself would be faster and more convenient.
Suggestion
Include an extra icon/text in the list of prs with:

If the PR requires your approval, and you haven't approved it yet, add an icon/text to indicate that the pr requires your approval.
If the PR requires your approval, and you have already approved it, add an icon/text to indicate that you already approved the pr.
If the PR requires your approval, and you have requested changes, add an icon/text to indicate that you requested changes.
If the PR doesn't require your approval, there is no change (nothing extra)

Notes: GitHub also considers the 'You left a review' as a related status. I don't think this special status needs to be shown, but I wouldn't mind if it is.
Sample mockups (possible implementations):
Extend the existing text:

Include your user icon with the state:

Example URLs
https://github.com/refined-github/refined-github/pulls

Like for https://github.com/refined-github/refined-github/issues/4730 and https://github.com/refined-github/refined-github/issues/6202, that list is already busy and we shouldn't add further information (there's a lot we could add), especially when, as you said, you can reach that with filters.
I'd advise to just have a bookmark to see the PRs that are awaiting your review, because that's probably what you need to know anyway:
https://github.com/pulls?q=is%3Aopen+user-review-requested%3A%40me+


Is it possible to rertrieve the pure entered value?

When i have a mask like: (000)-000000 and i enter (123)-123456 i would like to store it as 123123456. Is this possible?

+1

This is not possible. You'd probably be able to parse the mask yourself with a function and remove all the static parts. However, there is no clear way to tell, if the intended result-value is supposed to be (123)-123456, 123123456 or maybe even 123-123456.

Hi @bhuijts I guess we have similar interests. 😀
Take a look at #526.
As this is a formatter only lib I try to create the adopted Version that covers View and Model seoarately. As formatter and Parser do...
Best Michael

It would be quite easy to implement your own Version  of textmask by combining conformToMask and correctCursorPosiition.
Unfortunately only the conformtoMask function is exported in the text-mask-core lib... 🙁

Please look at my solution on https://github.com/benitazz/Masking-Control

+1

Hi, I also did a custom implementation for text-mask and the above described problem.
I have a impementation for formatter and parser which i customized to fit textMask.
It's a directive, so no additional html added to the solution.
Also cool with this implementation is that you can configure it in the same way as you would with validators when you use the NG_VALIDATORS token. But here you can use the FORMATTER_PARSER token to provide your function.
The interesting part here is onControlInput() and writeValue()
in both

the default version: https://github.com/BioPhoton/angular-formatter-parser/blob/master/formatter-parser.directive.ts
and the textMask implementation: https://github.com/BioPhoton/angular-formatter-parser/blob/master/text-mask-implementation/formatter-parser-text-mask.directive.ts

+1

+1


Temporary add -D_OPENMP to clang options in hipcc to allow using CMak…

…e OpenMP detection with hip-clang (until updated CMake version is available).

The CMake OpenMP detection mechanism "find_package(OpenMP)" does not work with hipcc and hip-clang. The small test that CMake uses to detect OpenMP support in the compiler fails to compile by hipcc because _OPENMP macro is not defined for the DEVICE compilation pass.
I submitted a corrected CMake test to the CMake Gitlab repo, and the change has been approved. However, it will take considerable time to be able to use updated CMake version. So, let's make this temporary change to the hipcc script to add "-D_OPENMP" to the clang options and keep this change until fixed CMake version is available.

sorry I thought it was a rocblas change.
I do have some concerns about this: -D_OPENMP indicates -fopenmp is passed to the compiler.
we should limit this to hip-clang only (HIP_COMPILER == "clang") and only when -fopenmp is passed to the compiler.

The check for "-fopenmp" is already there, I will add check for clang compiler Thanks!


Expose all library functions to Node

Awesome work on the library!
I found that all of the module functions other than parseDicom weren't available to the node package, so, I made the wrapping code that had only wrapped parseDicom wrap the entire library (but only in the dist build). I don't use AMD or Meteor, so I don't know if this approach broke the build for them, but I don't think it would have (and it's passing the same number of tests that were passing before changes).
Figured that exposing the functions would probably be worth a minor version bump, but happy to open a different PR without that.

Just realizing that only exposing parseDicom could have been intentional...
I was looking for a way access functions in the util folder, and I think those are intended to be exposed?

The util functions should be exposed - I would rather not expose the internals as that would make them APIs people might depend on making future changes harder.  If you can resubmit with just exposing util I can accept that right away, need to think more about how to handle the internals

Any update on a new PR with exposing just util?

According to issue #20 we also need to export readEncapsulatedPixelData so it isn't just util.

Hey @chafey, sorry, I've been really busy lately. I'll take a look now.

OK, should be good to go now!

(Applied those changes and rebased)

@chafey  Any update on that? Thanks!!

Oops I missed this somehow, let me look

merged - thanks!

Thanks guys! Will test it right now!


Initial working version

This is an initial working version. Most function were taken from the MagTag library in order to get the latest versions of things. It is not meant to be used by itself, so there are no examples.

To test, you can use https://github.com/makermelissa/Adafruit_CircuitPython_MagTag/tree/refactor which should run any existing MagTag scripts without changes. I tested on MagTag the examples already.

Thanks for testing


Add __all__ to subsystem __init__ files

Depends-On: #822
Although it is not common practice within the code to import everything from a subsystem, it does appear to be common practice to include a __all__ in each of these __init__ files.
This is mentioned in several places here: https://www.python.org/dev/peps/pep-0008/  (search for __all__)
This is the statement that caught my attention:
To better support introspection, modules should explicitly declare the names in their public API using the __all__ attribute. Setting __all__ to an empty list indicates that the module has no public API.

This also eliminates the need for the global F401 exception for flake8 which is described here, and is handled in #830 https://flake8.pycqa.org/en/2.6.0/warnings.html, which should allow future contributors to"see" and act on the error when reported.
module imported but unused

The lists were put in alphabetical order to make future additions easier, not sure if it matters here, please LMK

The lists were put in alphabetical order to make future additions easier, not sure if it matters here, please LMK

It's okay, I think I even saw a linter or something for ordering them like that. Probably in the pre-commit ecosystem.
One ask I have here, though is to not use lists but replace them with tuples. Not sure why it's not linted but there's a general recommendation to have __all__ immutable. Could you update this?

for my education, can you provide a link to the general recommendation?  The only thing I've been able to find it PEP8 which shows:
__all__ = ['a', 'b', 'c']

and states:
Setting __all__ to an empty list indicates that the module has no public API.

which leads me to believe __all__ was expected to be a list.
BTW, I've gone ahead and made the changes, until we need it to be mutable/generated I see no difference and have no preference.

I did some googling. It seems like in the past this caused some problems with pydocstyle (formerly known as pep257) — https://github.com/PyCQA/pydocstyle/issues/62.
Some people think that lists are semantically more correct. I don't buy it. __all__ is supposed to be declarative, making it generated/dynamic defeats the whole purpose of having it. Immutable structures make it easier to reason about stuff in a predictable way.
Of course, it's even more correct not to expose those imports via __init__ and put them into api submodules but that requires some extra work and the rule that could check for this code smell is currently disabled.

Converted to draft as reviews should stay as draft until they pass CI. That prevents spamming reviewers or confuse them on which pull-requests they can review and merge. Feel free to convert it both ways as many time you need as nothing is lost when you do that.

Don't do this. It's perfectly reviewable. A passing CI is not a prerequisite for human reviews. The protection blocks merges separately.

@cidrblock is it me or did the vetting linters start running in the enforced lint stage? I can't check right now from phone but I'll try to take a look at that later today when I get to the laptop.

@cidrblock is it me or did the vetting linters start running in the enforced lint stage? I can't check right now from phone but I'll try to take a look at that later today when I get to the laptop.

fixed in #835


Update pptxs

Updated the following pptx to match to the latest versions:

data-import
data-transformation
data-visualization
factors
keras
lubridate
package-development
plumber
purrr
quarto
reticulate
rmarkdown
shiny
shiny.python
sparklyr
strings
tidyr

@mine-cetinkaya-rundel in this pull request I updated the pptx files of the cheat sheets mentioned in #340 to make them easier to translate (as I did) or update for those who don't have access to keynote. I did it like this for simplicity, due to the fact that I didn't make any major changes, in case  it's required to do a pull request for each one please let me know. Thanks for the good work.

Thank you!


BINDINGS: raylib-cpp targets raylib 3.7.0

https://github.com/RobLoach/raylib-cpp/releases/tag/v3.7.0

@RobLoach Nice! Thanks for the update! :D


Introduce CI

(I mainly did this to have an ubuntu build to download from my fork)
I commented out other targets than ubuntu and haven't tested them, ubuntu should be the fastest
Rust cache only cached the dependency download for me for some reason, I don't know rust / cargo well enough to know why. Or maybe I had one bad commit where cache got uploaded for that cargo lock with only downloaded and not compiled deps. No idea, worklfow seems fast enough anyway, cache could be removed if causes problems

This is awesome :) Thank you for working through it. I'll try to check it over and merge this evening.

Rust cache only cached the dependency download for me for some reason, I don't know rust / cargo well enough to know why. Or maybe I had one bad commit where cache got uploaded for that cargo lock with only downloaded and not compiled deps. No idea, worklfow seems fast enough anyway, cache could be removed if causes problems

I think it got fixed in https://github.com/michaeljones/gleam-templates/pull/4/commits/0a03d1f37809fdc8743fb502dfdca6ac22e47f36

Should I merge it?

It seems to upload the debug build. Should we think about doing a release build and uploading that too? Or is that a separate thing for some kind of tagging workflow?

I think there's a trade-off of usefulness and time spent on CI. A release build on every commit would be nice but building it takes quite a bit more time than just a debug build. Gleam for example used to be making a "release" build on every commit but the CI got so slow that I recently contributed changes so that release mode is only used on pushed tag, when actually making a release most people would download.

Makes sense!

Gleam's workflow for a pushed tag is here: https://github.com/gleam-lang/gleam/blob/main/.github/workflows/release.yaml
Looks like for linux it additionally is a bit more complicated and statically links musl so that it works on all linuxes, not just newest ubuntu. Here the trade-off is slightly bigger binary. May be worth copying and doing the same if this tool stays being written in rust.

Thanks. I'll take a look soon!


winPB: Update Openssl to 1.1.1k

Issue: eclipse/openj9#12291
Checklist

[x] commit message has one of the standard prefixes
[ ] FAQ.md updated if appropriate
[ ] other documentation is changed or added (if applicable)
[ ] playbook changes run through VPC or QPC (if you have access)
[ ] for inventory.yml changes, bastillion/nagios/jenkins updated accordingly

@willsparker @Haroon-Khel Can one of you take this one and deploy it onto the six windows build (as a minimum!) machines please?


Fixed build issue, where VS2017 presented me with build error CS0121

It seems that in the System.Threading.Tasks.Task.Run(CheckNetwork); line of code, upon compilation in Visual Studio 2017, I was presented with build error CS0121.
Casting the parameter (CheckNetwork) to type Action fixed the build error.
The final result is that the line of code is now as follows:
System.Threading.Tasks.Task.Run((Action)CheckNetwork);

Interesting, I don't promise I can keep the VS 2017 build clean, since I only use VS 2019 but I'll accept this fix, thanks.


Trigger and function not defined in right order using db diff

Bug report

[x] I confirm this is a bug with Supabase, not with my own application.
[x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug
When having a trigger on your database that calls a certain trigger and you run supabase db diff to generate a migration, it will first output the trigger and then the function. When running this code (migration), it will throw an error function (...) does not exist. The simple fix is to manually edit the output and put the trigger creation after the function creation.
To Reproduce

Run the following SQL:

CREATE OR REPLACE FUNCTION public.handle_new_user()
 RETURNS trigger
 LANGUAGE plpgsql
 SECURITY DEFINER
AS $function$BEGIN
INSERT INTO public.profiles (id, email) VALUES (new.id, new.email);
return new;
END$function$
;

CREATE TRIGGER on_auth_user_created AFTER INSERT ON auth.users FOR EACH ROW EXECUTE FUNCTION handle_new_user();

Run supabase db diff -f "add_automatic_profile_creation"
Run supabase db reset
See Error: ERROR: function handle_new_user() does not exist (SQLSTATE 42883)

Expected behavior
The migration should simply succeed
System information

OS: Ubuntu 20.04
Supabase CLI: 1.61.1
Docker version 23.0.6, build ef23cbc

Additional context
I created the function and trigger through the studio and later manipulated them through DBeaver. Can't imagine this has any effect though

I can confirm this behavior. It seems to be limited to triggers on tables in the auth schema.
My application has two triggers on auth.users (on on insert, one on update) and two triggers on tables in the public schema.

I had the same issue. I filed a ticket. this from the support engineering team -
I have made a product feedback to improve the diff tool and will present this case to engineering. Thanks for reporting this. I hope this information helps!

The way db diff works is by diffing schemas one by one in alphabetical order. I'm not sure if there's an easy way to fix this problem. Meanwhile you can work around it by specifying the order of schema explicitly. For eg.
supabase db diff -f public_changes -s public
supabase db diff -f auth_changes -s auth

If it helps, you can also combine them into a single migration afterwards by concatenating the generated migration files.

I faced this with the latest version of 1.112 when I ran supabase db pull to pull down all changes from the remote instance. I am not sure if it is okay to manually modify the migration file. What is the recommended way to get around this?

I also experienced this with db pull even though the functions in question were both in the public schema.


Error in pasting into a file

Hello!
Whenever I'm trying to copy and paste from a text editor into a file in juci, I get this crash and error:
"(juci:5780): Gtk-WARNING **: /tmp/buildd/gtk+3.0-3.14.5/./gtk/gtktextbtree.c:4020: byte index off the end of the line
(juci:5780): Gtk-ERROR **: Byte index 2 is off the end of the line".

Is this with the latest version of juci (see #51)? If so, what OS do you use?

I'd like to see the log file (~/.juci/log/juci.log) and your "cmake ."-output aswell.

Yes. I just git pulled the latest version. I'm on linux debian 8.2.

"cmake ."-output:
"-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   thread
--   log
--   system
--   filesystem
-- Configuring done
-- Generating done
-- Build files have been written to: /home/balder/jucipp."
logfile (Cant upload it, due to write permission):
** Info: /home/balder/jucipp/src/juci.cc@init_logging(11): "Logging initalized"
** Debug: /home/balder/jucipp/src/window.cc@Window(26): "start"
** Debug: /home/balder/jucipp/src/directories.cc@Directories(25): "start"
** Debug: /home/balder/jucipp/src/directories.cc@update(148): "start"
** Debug: /home/balder/jucipp/src/directories.cc@update(154): "end"
** Debug: /home/balder/jucipp/src/window.cc@Window(125): "end"
** Debug: /home/balder/jucipp/src/directories.cc@open(122): "start"
** Debug: /home/balder/jucipp/src/directories.cc@open(144): "end"
** Debug: /home/balder/jucipp/src/notebook.cc@open(58): "start"
** Debug: /home/balder/jucipp/src/source_clang.cc@ClangViewParse(25): "start"
** Debug: /home/balder/jucipp/src/source_clang.cc@ClangViewParse(75): "end"
** Debug: /home/balder/jucipp/src/directories.cc@select(158): "start"
** Debug: /home/balder/jucipp/src/directories.cc@select(198): "end"
** Debug: /home/balder/jucipp/src/notebook.cc@open(147): "end"
** Debug: /home/balder/jucipp/src/directories.cc@update(148): "start"
** Debug: /home/balder/jucipp/src/directories.cc@update(154): "end"
** Debug: /home/balder/jucipp/src/notebook.cc@open(58): "start"
** Debug: /home/balder/jucipp/src/source_clang.cc@ClangViewParse(25): "start"
** Debug: /home/balder/jucipp/src/source_clang.cc@ClangViewParse(75): "end"
** Debug: /home/balder/jucipp/src/directories.cc@select(158): "start"
** Debug: /home/balder/jucipp/src/directories.cc@select(198): "end"
** Debug: /home/balder/jucipp/src/notebook.cc@open(147): "end"

It would be great if you could create a minimal test case where juci fails, that is copied text that crashes juci when pasted.

So, what I'm doing when it's crashing is:

Make a new project.
Make a new file.
Copy text into the file.

The text I'm trying to paste into the file is:
http://pastebin.com/taGuWaAV
This is by the way your file eidheim :)

Ah yeah, I might fix this on Monday or so. It's a Windows-file, which probably contains non-utf8 characters. Think I have to replace the non-utf8 chars before pasting. Thank you for reporting the issue:)

A temporary fix is to open it in juci directly, instead of pasting it. Then the non-standard chars gets removed automatically.

I tried to do this. But the files doesnt seem to recognize each other, because I get a lot of undefined references out of this. But thank you for your time!

Undefined references sounds like a different problem. Remember to add all your .cpp-files in add_executable in the CMakeLists.txt. For instance:
add_executable(oving1 main.cpp broek.cpp)


chore(package): update eslint-config-pretty to version 2.1.1

Codecov Report

Merging #17 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #17   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           3      3
  Lines           3      3
=====================================
  Hits            3      3

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 f59678a...b5a8dab. Read the comment docs.


AutoPS arXiv

From first sight this doesn't look like "disaggregation" to me. Can you double check just in case?

@jaywonchung good point. I thought about it. Juncheng described as so in his dissertation from the point of view that instead of every job having separate PS, this provides a shared PS for all jobs, which will lead to better memory and CPU utilization. But it's a stretch.

I took it off.

Would people who select the "disaggregation" topic manually in our website want to see this?

Oh okay. Merging!

Agreed. I removed Disaggregation.


Can't write or read the eMMC  (IDFGH-1398)

I am currently using the ESP32 to read/write sectors for the eMMC devices. The circuit set up is as below.

However, I can get the information from the chip, but the read/write operations are always fail with the error message  E (6505) sdmmc_req: sdmmc_host_wait_for_event returned 0x107
E (6505) sdmmc_cmd: sdmmc_write_sectors_dma: sdmmc_send_cmd returned 0x107
`#include <stdio.h>
#include <string.h>
#include <sys/unistd.h>
#include <sys/stat.h>
#include "esp_err.h"
#include "esp_log.h"
#include "esp_vfs_fat.h"
#include "driver/sdmmc_host.h"
#include "driver/sdspi_host.h"
#include "sdmmc_cmd.h"
#include "driver/gpio.h"
void setup(){
Serial.begin(112500);
sdmmc_host_init();
sdmmc_slot_config_t slot_config = SDMMC_SLOT_CONFIG_DEFAULT();
slot_config.width = 4;
sdmmc_host_init_slot(SDMMC_HOST_SLOT_1, &slot_config);
sdmmc_host_t host = SDMMC_HOST_DEFAULT();
//host.max_freq_khz = SDMMC_FREQ_HIGHSPEED;
//host.max_freq_khz = SDMMC_FREQ_PROBING;
sdmmc_card_t card;
sdmmc_card_init(&host,&card);
Serial.println("\n ready to get information");
sdmmc_card_print_info(stdout, &card);
pinMode(15, INPUT_PULLUP);
pinMode(2, INPUT_PULLUP);
pinMode(4, INPUT_PULLUP);
pinMode(12, INPUT_PULLUP);
pinMode(13, INPUT_PULLUP);

sdmmc_write_sectors(&card, data, 1000, 1);
Serial.println("check write");
ESP_ERROR_CHECK( sdmmc_write_sectors(&card, data, 1000, 1) );
sdmmc_read_sectors(&card, buff, 1000, 1);
ESP_ERROR_CHECK( sdmmc_read_sectors(&card, buff, 1000, 1) );
}
void loop() {
// put your main code here, to run repeatedly:
}`
the output is shown below
ready to get information Name: Q2J55L Type: MMC Speed: 20 MHz Size: 7264MB CSD: ver=3, sector_size=512, capacity=14876672 read_bl_len=9 E (6505) sdmmc_req: sdmmc_host_wait_for_event returned 0x107 E (6505) sdmmc_cmd: sdmmc_write_sectors_dma: sdmmc_send_cmd returned 0x107 check write

Can you set log level to verbose in menuconfig, and attach the output you get?

My project is Arduino based project, I don't think I can change the contents in menuconfig

Can I simply change like this? but nothing change. The error message is the same

No, indeed the log level needs to be set when compiling with the esp-idf. Since your test code is mostly independent from Arduino functionality, can you switch to IDF for the purpose of debugging this? You can also use Arduino library as IDF component: https://github.com/espressif/arduino-esp32/blob/master/docs/esp-idf_component.md
This will allow log level to be changed, revealing more information about the cause of this issue.

No, indeed the log level needs to be set when compiling with the esp-idf. Since your test code is mostly independent from Arduino functionality, can you switch to IDF for the purpose of debugging this? You can also use Arduino library as IDF component: https://github.com/espressif/arduino-esp32/blob/master/docs/esp-idf_component.md
This will allow log level to be changed, revealing more information about the cause of this issue.
I just need to check one thing first. I found that in this paper https://cdn.hackaday.io/files/269911154782944/esp32_datasheet_en.pdf
It said that the SD/SDIO/MMC host controller is available on ESP32 which supports Multimedia Cards (MMC Version 4.41, eMMC Version 4.5 and Version 4.51). Is there any updated eMMC version that the ESP32 supports? Since I am using the latest version eMMC 5.0 and 5.1 for testing.


fix: modify logging logic of summary.

主要修改：

当测试步骤为测试用例时，该测试用例的测试步骤数据并入到上层summary中
summary与report存放在reports文件夹中，并在文件命名增加当前时间加以区分

Codecov Report

Merging #85 (c33ff5b) into main (5ede366) will decrease coverage by 0.21%.
The diff coverage is 28.07%.

@@            Coverage Diff             @@
##             main      #85      +/-   ##
==========================================
- Coverage   55.73%   55.51%   -0.22%
==========================================
  Files          29       29
  Lines        3628     3678      +50
==========================================
+ Hits         2022     2042      +20
- Misses       1461     1489      +28
- Partials      145      147       +2

Flag
Coverage Δ

unittests
55.51% <28.07%> (-0.22%)
:arrow_down:

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

Impacted Files
Coverage Δ

internal/builtin/function.go
1.42% <0.00%> (-0.82%)
:arrow_down:

internal/scaffold/main.go
0.00% <0.00%> (ø)

runner.go
60.40% <61.53%> (+0.64%)
:arrow_up:

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 c57e32e...c33ff5b. Read the comment docs.


Non-MQTT brightness control?

Hello,
I am working on building multiple standalone units to distribute to family members. They will not be connected to a home assistant instance and therefore cannot be easily controlled remotely.
I see image brightness is an option to be set by MQTT. Is there a way to set it outside of MQTT commands? I would love a brightness sensor and cronjob to make these changes every so often.
My current testing monitor is DVI so I cannot try the ddcutil as most suggest. Picframe seems to be the next best option in the meantime.
Thanks!

Hi @Judman

activate pic frames internal Webserver and use 'curl' on localhost in a script to set the brightness or
install mosquito (mqtt broker) locally on the raspi. Use mqqt messages in a script.

I think @sapnho wrote something about doing this with a background python script sending MQTT messages. I think this would be the easiest way to go if you wanted the brightness sensor to work in conjunction with the timing.
However I can't see the article offhand, just a general help page https://www.thedigitalpictureframe.com/

I only tried this here so far: https://www.thedigitalpictureframe.com/how-to-automatically-control-the-display-brightness-of-your-raspberry-pi-photo-frame/

So it is super easy to turn on the HTTP server and use curl "localhost:9000/?brightness=1" to change the brightness.  Having messed around with MQTT in the past it did not seem worth the effort to set it up just for brightness when the HTTP server works well. I haven't worked on a Photocell (or LDR) script.
However, I figured out ddcutil brightness control on the Pi 3 through HDMI. I used my camera to compare changing the brightness in PicFrame vs changing the monitors to similar levels. Turns out the pictures stay truer to color by adjusting the monitors' native brightness.
All that to say I think using DDC to adjust brightness is the current path I am going to pursue.
Thanks all for the amazing work on this project and being so quick to help with issues of a new user trying to learn all this!


Add chapter about payment batching

Closes #10

Dave, I'm sorry I haven't reviewed this yet. I plan to do so next week!

Still on my todo list as well! Sorry for the delay!!
On Fri, Feb 22, 2019 at 2:57 PM John Newbery<EMAIL_ADDRESS>wrote:

Dave, I'm sorry I haven't reviewed this yet. I plan to do so next week!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bitcoinops/scaling-book/pull/18#issuecomment-466577541,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAT6A-SYPMNtNV0DkE4Hl65j1yuSM0szks5vQHXQgaJpZM4akFNg
.

Pushed separate commits addressing @moneyball and @jnewbery feedback.  Another separate commit removes the sections about RBF and changeless transactions per my comments https://github.com/bitcoinops/scaling-book/pull/18#discussion_r260936004 and https://github.com/bitcoinops/scaling-book/pull/18#discussion_r260958620

Forced pushed a squash of previous fixup commits plus changes in response to @jnewbery's latest feedback.  A branch with the old commits may be found here (I'm keeping it around in case we reconsider including the RBF and changeless sections later): https://github.com/harding/scaling-book/tree/save-chapter-batching-with-fixups

Merging. Looks great, Dave! Let's revisit Combining batching with other opt-in scaling techniques once you've written the consolidation chapter.


x/crypto/acme: Rejected TOS results in inability to register

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.6
What operating system and processor architecture are you using (go env)?
amd64
What did you do?
Call acme.Register with a prompt that returns false, then again with a prompt that succeeds.
What did you expect to see?
Success
What did you see instead?
Register returns a conflict without calling UpdateReg.

This mostly affects autocert -- if you initially return false from prompt, then you have to kill the key

This is approximately the lowest priority bug. Don't expect things to work when you don't agree to the TOS. Actually, LetsEncrypt only has the TOS agreement in the protocol because it's a CA/B forum requirement to have a contractual relationship with their "customers". While we have the hook as a formality to respect the LetsEncrypt necessary legal formalities, you should just always return true.
/cc @x1ddos

I think this is actually WAI. The acme package follows the spec very closely. So, acme.Register literally means perform the "registration" with the CA.
So, calling Register method regardless of the accept TOS return value will always result in a "conflict" error. Try calling it twice with accept TOS always returning true - you'll get a "conflict" error the second time.
@taralx so what are you proposing, add a logic to Register and invoke UpdateReg under certain conditions and don't otherwise? I'm afraid that may lead to unexpected behavior and will certainly break some existing clients which rely on that same fact that Register returns "conflict" error if called with an existing key.
This could be a feature request at best but not really sure it's worth it. Feels like very specific case and may cause more harm than good. Unless I'm missing something.

I'm fine with switching this to autocert if it's WAI for acme, but it seems weird that you only get a free UpdateReg the first time you call Register, after which you get a conflict error and no UpdateReg

Opened issue 18433 for the autocert side.

follows the spec very closely. So, acme.Register literally means perform the "registration" with the CA.

If that's the case, why does it call UpdateReg at all? This is the problem IMO -- the behavior w.r.t. UpdateReg is inconsistent.

@taralx you're right. it should be consistent. I'll try to come up with a fix in the next days.


[bug] sysbench press database, xenon will switch leader, cause data not consistent

Describe the problem

TO STOP xenon switch the leader
To Reproduce

Expected behavior

Environment:

RadonDB MySQL version:

[ ] @andyli029  time xenon.json has the time for switch leader?

electionTimeout:
default: 10000
->
default: 30000
@acekingke @qianfen2021

256 thread per 1c
..
1024thread p 4c
..


[🐛 Bug]: ERROR Could not resolve "async_hooks"

next-on-pages environment related information
System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
CPU: (10) arm64 Apple M1 Max
Memory: 32 GB
Shell: /bin/zsh
Package Manager Used: npm (10.2.4)
Relevant Packages:
@cloudflare/next-on-pages: 1.13.5
vercel: N/A
next: 14.2.18
Description
It just started happening out of the blue. Both when i try to build locally or when I git push and Cloudflare does the build for production.
Even on Cloudflare pages if i try to re-deploy an old commit version that had previously deployed successfully, it also fails.
Not sure exactly what the issue is...
This is what i see in the terminal logs, and i see the error comes after the next build has completed:
[next js build stuff completes succesfully]
...
▲  Build Completed in .vercel/output [33s]
⚡ Completed `npx vercel build`.
✘ [ERROR] Could not resolve "async_hooks"

    <stdin>:596:680:
      596 │ ...umerable:!0})),e);_(exports,{default:()=>N});var R=A(require("async_hooks")),S="@next/request-context",f=Symbol.for(S),C=Symbol.for("i...
          ╵                                                                 ~~~~~~~~~~~~~

  The package "async_hooks" wasn't found on the file system but is built into node. Are you trying
  to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.

/Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:1575
  let error = new Error(`${text}${summary}`);
              ^

Error: Build failed with 1 error:
<stdin>:596:680: ERROR: Could not resolve "async_hooks"
    at failureErrorWithLog (/Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:1575:15)
    at /Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:1033:28
    at runOnEndCallbacks (/Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:1447:61)
    at buildResponseToResult (/Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:1031:7)
    at /Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:1143:14
    at responseCallbacks.<computed> (/Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:680:9)
    at handleIncomingPacket (/Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:735:9)
    at Socket.readFromStdout (/Users/myuser/.npm/_npx/39e2fd552b408994/node_modules/esbuild/lib/main.js:656:7)
    at Socket.emit (node:events:519:28)
    at addChunk (node:internal/streams/readable:559:12) {
  errors: [
    {
      detail: undefined,
      id: '',
      location: {
        column: 680,
        file: '<stdin>',
        length: 13,
        line: 596,
        lineText: '    const fn = (function(module,exports) {var b=Object.create;var p=Object.defineProperty;var w=Object.getOwnPropertyDescriptor;var T=Object.getOwnPropertyNames;var P=Object.getPrototypeOf,L=Object.prototype.hasOwnProperty;var h=e=>p(e,"__esModule",{value:!0});var _=(e,n)=>{h(e);for(var t in n)p(e,t,{get:n[t],enumerable:!0})},U=(e,n,t)=>{if(n&&typeof n=="object"||typeof n=="function")for(let i of T(n))!L.call(e,i)&&i!=="default"&&p(e,i,{get:()=>n[i],enumerable:!(t=w(n,i))||t.enumerable});return e},A=e=>U(h(p(e!=null?b(P(e)):{},"default",e&&e.__esModule&&"default"in e?{get:()=>e.default,enumerable:!0}:{value:e,enumerable:!0})),e);_(exports,{default:()=>N});var R=A(require("async_hooks")),S="@next/request-context",f=Symbol.for(S),C=Symbol.for("internal.storage");function O(){let e=globalThis;if(!e[f]){let n=new R.AsyncLocalStorage,t={get:()=>n.getStore(),[C]:n};e[f]=t}return e[f]}var q=O();function m(e,n){return q[C].run(e,n)}function y(e){let n={};return e&&e.forEach((t,i)=>{n[i]=t,i.toLowerCase()==="set-cookie"&&(n[i]=M(t))}),n}function M(e){let n=[],t=0,i,a,g,o,r;function x(){for(;t<e.length&&/\\s/.test(e.charAt(t));)t+=1;return t<e.length}function s(){return a=e.charAt(t),a!=="="&&a!==";"&&a!==","}for(;t<e.length;){for(i=t,r=!1;x();)if(a=e.charAt(t),a===","){for(g=t,t+=1,x(),o=t;t<e.length&&s();)t+=1;t<e.length&&e.charAt(t)==="="?(r=!0,t=o,n.push(e.substring(i,g)),i=t):t=g+1}else t+=1;(!r||t>=e.length)&&n.push(e.substring(i,e.length))}return n}function N(e){let n=e.staticRoutes.map(i=>({regexp:new RegExp(i.namedRegex),page:i.page})),t=e.dynamicRoutes?.map(i=>({regexp:new RegExp(i.namedRegex),page:i.page}))||[];return async function(a,g){let o=new URL(a.url).pathname,r={};if(e.nextConfig?.basePath&&o.startsWith(e.nextConfig.basePath)&&(o=o.replace(e.nextConfig.basePath,"")||"/"),e.nextConfig?.i18n)for(let s of e.nextConfig.i18n.locales){let u=new RegExp(`^/${s}($|/)`,"i");if(o.match(u)){o=o.replace(u,"/")||"/";break}}for(let s of n)if(s.regexp.exec(o)){r.name=s.page;break}if(!r.name){let s=E(o);for(let u of t||[]){if(s&&!E(u.page))continue;let d=u.regexp.exec(o);if(d){r={name:u.page,params:d.groups};break}}}let x=await m({waitUntil:g.waitUntil},()=>globalThis._ENTRIES[`middleware_${e.name}`].default.call({},{request:{url:a.url,method:a.method,headers:y(a.headers),ip:c(a.headers,l.Ip),geo:{city:c(a.headers,l.City,!0),country:c(a.headers,l.Country,!0),latitude:c(a.headers,l.Latitude),longitude:c(a.headers,l.Longitude),region:c(a.headers,l.Region,!0)},nextConfig:e.nextConfig,page:r,body:a.body}}));return x.waitUntil&&g.waitUntil(x.waitUntil),x.response}}function c(e,n,t=!1){let i=e.get(n)||void 0;return t&&i?decodeURIComponent(i):i}function E(e){return e==="/api"||e.startsWith("/api/")}var l;(function(o){o.City="x-vercel-ip-city",o.Country="x-vercel-ip-country",o.Ip="x-real-ip",o.Latitude="x-vercel-ip-latitude",o.Longitude="x-vercel-ip-longitude",o.Region="x-vercel-ip-country-region"})(l||(l={}));',
        namespace: '',
        suggestion: ''
      },
      notes: [
        {
          location: null,
          text: `The package "async_hooks" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.`
        }
      ],
      pluginName: '',
      text: 'Could not resolve "async_hooks"'
    }
  ],
  warnings: []
}

Node.js v21.6.1

Reproduction
No response
Pages Deployment Method
Pages CI (GitHub/GitLab integration)
Pages Deployment ID
No response
Additional Information
No response
Would you like to help?

[ ] Would you like to help fixing this bug?

I am encountering the same (only difference is Node.js v20.10.0). I can't deploy on Cloudflare.

Seeing it on Node.js v20.18.1 also with these versions:
⚡ @cloudflare/next-on-pages CLI v.1.13.5
⚡ Detected Package Manager: npm (10.8.2)
▲  Vercel CLI 37.5.3

Interestingly, while it is failing in GitHub Actions, it works for me locally on OSX. Maybe if I do an npm install that will change.

Delete .vercel caused it to start failing locally. Unfortunately I didn't check the node_modules in there before deleting.

Same issue with async_hooks error, the same commit was successful a few days ago, but retrying to deploy it today failed.

The workaround we found worked was rolling back and pinning to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

I  also face the issue.

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

This seems to fix it for now thanks @sampotts

This solution didn't work for me...
I still have same error.

https://github.com/cloudflare/next-on-pages/issues/908#issuecomment-2502658653

{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

Add "vercel": "39.1.1" under devDependencies in your package.json. This worked perfectly for me!

@kaiono-g you might have to: run npm install and delete the .vercel folder.
When my .vercel folder was recreated it no longer had the builders subdirectory as t all and started pulling from my package's node_modules instead.

:(
I believe we wouldn't have this problem if they prefixed the import with node:

If you are using pnpm, try this:
pnpm i<EMAIL_ADDRESS>-D

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

This fix is for me. I got the same issue when deploying on Cloudflare pages

<EMAIL_ADDRESS><EMAIL_ADDRESS>@cloudflare/next-on-pages CLI v.1.13.5
Vercel CLI 39.1.1
Next.js version: 14.2.18

But why do we need the Vercel package when deploying it to Cloudflare?

I've had a similar experience. Yesterday deployments were fine, today they're producing this error. The main differences I observe are that I'm using NX and Yarn, and my app-level package.json file is being overwritten.
I modified /package.json and /apps/next-js/package.json to have the version resolution (as above, but yarn-flavoured):
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "resolutions": {
    "vercel": "39.1.1"
  }
}

Here are the steps I took:

I deleted /node_modules, /apps/next-js/node_modules, /apps/next-js/.vercel, /apps/next-js/.next for good measure, and every instance of vercel from /yarn.lock and /apps/next-js/yarn.lock. Then I ran yarn at the root level.
I observed that in /yarn.lock my version had changed from ^37.0.0 to 39.1.1. IMO this is expected, but do correct me if I'm wrong.
Then I ran the next-on-pages command.

I observed:

The same error as reported.
The /apps/next-js/package.json file had changed to:

{
  "devDependencies": {
    "vercel": "^39.1.2"
  },
}

There is an entry near the beginning of the command log saying vercel dev dependency missing, installing vercel as a dev dependency with 'yarn add vercel -D'....
/apps/next-js/yarn.lock had an entry for both 39.1.1 and ^39.1.2.

A colleague with the same setup was able to reproduce the same issue with the package.json file.
Is there something I need to be doing to avoid it running that superflous dev dependency installation? If so, I might actually be able to implement that other downgrade properly.
Have attached a screenshot of my log output where it's installing the dependency.

Even after adding "vercel": "39.1.1" to devDependencies the build on cloudflare still fails
19:05:55.565 | ⚡ @cloudflare/next-on-pages CLI v.1.13.5
-- | --
19:05:55.906 | ⚡ Detected Package Manager: npm (9.7.2)
19:05:55.906 | ⚡ Preparing project...
19:05:55.909 | ⚡ Project is ready
19:05:55.909 | ⚡ Building project...
19:05:56.848 | ▲  npm WARN exec The following package was not found and will be installed<EMAIL_ADDRESS>19:06:00.753 | ▲  npm
                        ...
                        ...
19:06:56.472 | ▲  Traced Next.js server files in: 239.758ms
-- | --
19:06:56.539 | ▲  Created all serverless functions in: 66.363ms
19:06:58.521 | ▲  Collected static files (public/, static/, .next/static): 8.284ms
19:06:58.762 | ▲  Build Completed in .vercel/output [57s]
19:06:58.816 | ⚡ Completed `npx vercel build`.
19:07:02.213 | ✘ [ERROR] Could not resolve "async_hooks"
19:07:02.213 |
19:07:02.214 | <stdin>:327:680:
19:07:02.214 | 327 │ ...:()=>N});var<EMAIL_ADDRESS>19:07:02.214 | ╵                             ~~~~~~~~~~~~~
                        ...
                        ...
19:07:02.229 | warnings: []
-- | --
19:07:02.230 | }
19:07:02.230 |
19:07:02.230 | Node.js v20.4.0
19:07:02.260 | Failed: Error while executing user command. Exited with error code: 1
19:07:02.272 | Failed: build command exited with code: 1
19:07:03.173 | Failed: error occurred while running build command

I'm using pnpm and fixed the vercel version to 39.1.1. I can also see from CF's build log that it's using 39.1.1, yet it still fails with [ERROR] Could not resolve "async_hooks".
CF deployment log:
14:41:22.183 | ▲  devDependencies:
-- | --
14:41:22.183 | ▲  + @types/node 22.10.0
14:41:22.184 | ▲  + @types/react 18.3.12
14:41:22.184 | ▲  + @types/react-dom 18.3.1
14:41:22.185 | ▲  + @types/rss 0.0.32
14:41:22.185 | ▲  + eslint 9.15.0
14:41:22.185 | ▲  + eslint-config-next 14.2.5
14:41:22.185 | ▲  + postcss 8.4.49
14:41:22.185 | ▲  + tailwindcss 3.4.15
14:41:22.185 | ▲  + typescript 5.7.2
14:41:22.186 | ▲  + vercel 39.1.1
14:41:22.300 | ▲  Done in 3.2s

Everything compiles fine locally with pnpm dlx @cloudflare/next-on-pages, it's only the CF deployment that fails.

I'm using pnpm and fixed the vercel version to 39.1.1. I can also see from CF's build log that it's using 39.1.1, yet it still fails with [ERROR] Could not resolve "async_hooks".
CF deployment log:
14:41:22.183 | ▲  devDependencies:
-- | --
14:41:22.183 | ▲  + @types/node 22.10.0
14:41:22.184 | ▲  + @types/react 18.3.12
14:41:22.184 | ▲  + @types/react-dom 18.3.1
14:41:22.185 | ▲  + @types/rss 0.0.32
14:41:22.185 | ▲  + eslint 9.15.0
14:41:22.185 | ▲  + eslint-config-next 14.2.5
14:41:22.185 | ▲  + postcss 8.4.49
14:41:22.185 | ▲  + tailwindcss 3.4.15
14:41:22.185 | ▲  + typescript 5.7.2
14:41:22.186 | ▲  + vercel 39.1.1
14:41:22.300 | ▲  Done in 3.2s

Everything compiles fine locally with pnpm dlx @cloudflare/next-on-pages, it's only the CF deployment that fails.
edit I was able to deploy the site from local with wrangler pages deploy, so if you can build it locally, you can at least get it deployed while we wait for this to be sorted out.

we are using github actions and Cloudflare (yes, two separate projects with different CI/CD) and experiencing same issue - locally proposed solution with fixing vercel package version to 39.. did the trick but in both CI/CDs problem still exists

Same here. Next + Cloudflare
This worked
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}
``

@IgorMinar Can we pin the Vercel dependency version to a known number so this doesn't happen every time Vercel cuts a release?

using yarn and trying to pin the version like this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "resolutions": {
    "vercel": "39.1.1"
  }
}

but it's just not working. I keep getting this error

using yarn and trying to pin the version like this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "resolutions": {
    "vercel": "39.1.1"
  }
}

but it's just not working. I keep getting this error

I tried to pin the version and it did not work as well.
I was able to resolve the build issue by following @chrisp-code's comment and moving "vercel": "39.1.1" from "devDependencies" to "dependencies". Make sure to update your lock file.

I tried to pin the version to 39.1.1 and it did not work as well.
I was able to resolve the build issue by following @chrisp-code's comment and moving "vercel": "39.1.1" from "devDependencies" to "dependencies". Make sure to update your lock file.

@chrisp-code's comment did not work for us unfortunately. Not sure if it's because we are using npx rather than pnpm. No matter what we do, it still seems to update to 39.1.2

Same as @wolfenchill: I've tried most of (if not all) the solutions described above so far and none of them seem to work...it keeps using the 39.1.2 version for some reason.

This setup works for me
"devDependencies": {
    "@cloudflare/next-on-pages": "1.13.5",
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  },
  "packageManager"<EMAIL_ADDRESS>

Same as @wolfenchill: I've tried most of (if not all) the solutions described above so far and none of them seem to work...it keeps using the 39.1.2 version for some reason.

@lcnogueira, what version of @cloudflare/next-on-pages are you using? We were using an old version that was automatically getting the latest vercel, despite "pinning" it to an older version in package.json.  We updated @cloudflare/next-on-pages to the latest version and now it's respecting the "pinned" vercel version and the build is working.

Same as @wolfenchill: I've tried most of (if not all) the solutions described above so far and none of them seem to work...it keeps using the 39.1.2 version for some reason.

@lcnogueira, what version of @cloudflare/next-on-pages are you using? We were using an old version that was automatically getting the latest vercel, despite "pinning" it to an older version in package.json. We updated @cloudflare/next-on-pages to the latest version and now it's respecting the "pinned" vercel version and the build is working.

Hum...that might be it then @bradleybluebean . I'm using version 1.12.1.

@bradleybluebean , I just updated @cloudflare/next-on-pages to v1.13.5 and I can see from the logs it's using that version now.
I installed vercel v.39.1.1 (I tried both as a dev dependency and a regular dependency) and pinned the version:
devDependencies/dependencies {
    "vercel": "39.1.1"
},
"overrides": {
    "vercel": "$vercel"
 }

Then in my pipeline I build the app by running pnpm next-on-pages, but it still uses vercel v.39.1.2f for some reason. It's a monorepo and those dependencies/scripts are set in one of the apps for testing purposes.

@bradley's solution worked for us! you are a genius! thank you

Same as @wolfenchill: I've tried most of (if not all) the solutions described above so far and none of them seem to work...it keeps using the 39.1.2 version for some reason.

@lcnogueira, what version of @cloudflare/next-on-pages are you using? We were using an old version that was automatically getting the latest vercel, despite "pinning" it to an older version in package.json. We updated @cloudflare/next-on-pages to the latest version and now it's respecting the "pinned" vercel version and the build is working.

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

It worked perfectly for me

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

It worked perfectly for me

it also worked perfectly for me

moving vercel package from dev dependencies to dependencies fixed the issue, also think it's time to move away from vercel and nextjs, wtf is this issue?

This worked for me on Cloudflare Pages:
  "devDependencies": {     "@cloudflare/next-on-pages": "^1.13.5",     "vercel": "39.1.1"   },   "overrides": {     "vercel": "$vercel"   } }

I tried to pin the version to 39.1.1 and it did not work as well.
I was able to resolve the build issue by following @chrisp-code's comment and moving "vercel": "39.1.1" from "devDependencies" to "dependencies". Make sure to update your lock file.

this worked for me as well

This worked for me as well; thanks

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

Don't forget to npm i after

So? Closed it without fixing? Pining the version just temporarily work around.

So? Closed it without fixing? Pining the version just temporarily work around.

It has been fixed in the new release - v1.13.6

I tried building with the new release  v1.13.6
The build works (both locally and in Cloudflare). When i do npm run pages:dev the site works well locally.
But in production loading the website page gives an error 500 and i see this in the Cloudflare logs:
"logs": [
    {
      "message": [
        "Error: No such module \"__next-on-pages-dist__/functions/async_hooks\".\n  imported from \"__next-on-pages-dist__/functions/middleware.func.js\""
      ],
      "level": "error",
      "timestamp":<PHONE_NUMBER>843
    }
  ],

:(
I believe we wouldn't have this problem if they prefixed the import with node:

So FYI even with the fix I started to get the following with NextAuth:
TypeError: Illegal invocation: function called with incorrect this reference. See https://developers.cloudflare.com/workers/observability/errors/#illegal-invocation-errors for details.
  at K.waitUntil

(file:///***/.vercel/output/static/_worker.js/next-on-pages-dist/functions/api/auth/[...nextauth].func.js:2:828)
Implementing the vercel version into devDependencies and even with the latest next-on-pages and I am working again at least - but something has definitely broken between Cloudflare and Vercel ...

I tried building with the new release v1.13.6
The build works (both locally and in Cloudflare). When i do npm run pages:dev the site works well locally.
But in production loading the website page gives an error 500 and i see this in the Cloudflare logs:
"logs": [
    {
      "message": [
        "Error: No such module \"__next-on-pages-dist__/functions/async_hooks\".\n  imported from \"__next-on-pages-dist__/functions/middleware.func.js\""
      ],
      "level": "error",
      "timestamp":<PHONE_NUMBER>843
    }
  ],

Are you using a compability date after Sept 23rd 2024? Non-node prefixed imports require nodejs_compat_v2, which was merged into nodejs_compat on compatibility dates after Sept 23rd.

[!NOTE]
Please bump your Pages project's compatibility flag to the most recent one for both Preview and Production environments.

@bradley's solution worked for us! you are a genius! thank you
thank you

I tried building with the new release v1.13.6
The build works (both locally and in Cloudflare). When i do npm run pages:dev the site works well locally.
But in production loading the website page gives an error 500 and i see this in the Cloudflare logs:
"logs": [
    {
      "message": [
        "Error: No such module \"__next-on-pages-dist__/functions/async_hooks\".\n  imported from \"__next-on-pages-dist__/functions/middleware.func.js\""
      ],
      "level": "error",
      "timestamp":<PHONE_NUMBER>843
    }
  ],

Are you using a compability date after Sept 23rd 2024? Non-node prefixed imports require nodejs_compat_v2, which was merged into nodejs_compat on compatibility dates after Sept 23rd.

Note
Please bump your Pages project's compatibility date setting to the most recent one for both Preview and Production environments.

Thanks so much for the detailed instructions, @james-elicx . Updating the package fixed the build and bumping the compatibility date fixed the prod issue 🤝

That worked for me too ^^^ thanks @james-elicx

Thanks, I think i just had to clear the build cache and now they are working again.

I still face this issus even I changed my setting as below.
'Could not resolve "async_hooks"'

worked with the new compatibility date

Still having this error with 1.13.6

getting this https://github.com/cloudflare/next-on-pages/issues/908#issuecomment-2506399922 issue using:
compatibility_date = "2024-11-11"
with
  "devDependencies": {
    "vercel": "39.1.1",
    }
  "overrides": {
    "vercel": "$vercel"
  },

please remember to update the document,I spent one or two hours to find this solution.So sad.

Final Solution:
npm i @cloudflare/next-on-pages
and
compatibility_date = "2024-09-23"

The workaround we found worked was rolling back vercel and pinning and overriding it to 39.1.1. Assuming you're using npm, you can use this:
{
  "devDependencies": {
    "vercel": "39.1.1"
  },
  "overrides": {
    "vercel": "$vercel"
  }
}

You'll also have wipe out any references to vercel from package-lock.json and run npx npkill to clear out node_modules of old versions.

thank you so much bro it works for me, thanks again


Index of Examples Fixes and Changes

Description
This PR fixes and changes the following in the README.md of the examples directory:

Added all communication examples to index
Added ssr_router to index
Added function_router to index
Reordered the index into alphabetical order to match the examples directory
Unified full-stop usage for index descriptions
Minor heading and text tweaks
Improved index legend

More explicit breakdowns are available in each individual commit.
Checklist

[x] I have reviewed my own code

The checklist item for additional tests has been omitted as they are not necessary in this situation.

@WorldSEnder

I've taken the liberty to check for spelling of other descriptions and add some suggestions for improvements there. Might as well. Thanks for the contribution!

I've added the changes you mentioned, ready for your review again. 😄


update roles option for mcapp install

Address issue: https://github.com/rancher/rancher/issues/18609

Use 'project-member' as the default value
Update description

LGTM

LGTM

testable in v2.2.0-rc12


chore: Add tracing for debuging the js procedure slowness

While debuging why configSet was slow, was using this trace. @chrisguida  thought it would be nice if others could trace this too.

This will be extremely useful during our switch from docker to JS


Fix JDK11 issue with IBM ppc64le or s390x

The JDK 11 app "jaotc" is not part of the IBM ppc64le or s390x package. Also, removed old OpenJ9 references as it is not longer used.

Thanx for patience!

@judovana I'm still running the unit test now... I'll report if I hit a error in the refactored code.

Sure. It looked good enough to be merged. Pls openanother PR if it goes wrong. TY!

Late to the game. After re-deploying my cluster I ran testing on x86 and have not seen any issues againt JDK 11 images. Thank you @redmark-redhat and @judovana


Update Benchmarks and Documentation for GraniteCausalLM

In this PR we update the benchmarks for GraniteCausalLM

in addition, the README.md  is also updated to describe how a new model can be added in the future

Note this PR requires the following dependency updates

transformers>=4.45: for GraniteCausalLM
accelerate>=0.34: wihch is needed for transformers>=4.45, and then this fix is needed for a bug that was introduced in this accelerate release https://github.com/huggingface/accelerate/pull/3075
trl>0.11.1: when using baseline bnb, requires this fix for a bug that was introduced in transformers==4.45 https://github.com/huggingface/trl/pull/2089
bitsandtbyes==0.43.3: it seems that the later versions give segmentation fault errors

Known issues with quant peft

single GPU w/o FOAK ✅
single GPU w FOAK ->  ~fused lora dequant problem~ (maybe resolved)
multi GPU w/o FOAK -> ~rank 1 stuck at prepare_model~ (can be resolved)
multi GPU w FOAK -> ~meta device problem~ (see 2 in #83) (can be solved)
bad loss with BNB+FOAK

Performance
Overall impressive improvements with kernels.
FULL FT and PEFT

Quantized Peft (BNB)

awesome, great results @fabianlim

Indeed, awesome results @fabianlim !

@wynterl @raghukiran1224 the loss for BNB + fused ops looks problematic. Needs more debugging


Thanish's submissions

5 submissions

Lol, now that's a pull request! Loking at it now.

XGB 7: 0.560
RF 12: 0.576
NN 2: 0.455
NN 3: 0.475
NN 4: 0.470

Disappointing NN performance after your first NN try, sorry Thanish. The RF continues to look good though.

Lolz, initially I planned on 10 submissions. Since It was already midnight I settled for 5 ;). I will be on business travel followed by my vacation from next weekend until the end of the month so I'm trying to make the best I could right now. I guess I won't be online until the sands settle for this contest :|
That's so mean of NN. Since this is the first time I'm trying NN I'm unable to interpret the validation results and parameter tuning. Well good news is XGB is getting me good results too. Let me see what I can do for next 2 or 3 days.


Using Transifex service for team translation

See Using Transifex service for team translation.

@all-contributors please add @tkoyama010 for doc infra translation promotion

@all-contributors please add @tkoyama010 for ideas


transform() plugin invoked twice in dev; zero times in build

Using snowpack 3.0.11, a transform() plugin is invoked twice in dev, but zero (0) times in build
Here is the output from both start and build with the --verbose option. Notice that:

in start, the "inject-version" plugin is called twice on the HTML file
in build, that plugin is not called at all. That failure led to the report in https://github.com/snowpackjs/snowpack/discussions/2526

See the links at the bottom of this report for more info and a short reproducible test case.
$ yarn start --verbose
...
[snowpack] starting @snowpack/plugin-typescript run() in watch/isDev mode

[inject-version] transform() starting… [public/index.html]
[inject-version] ✔ transform() success [public/index.html]
[snowpack] [200] GET /
[snowpack] [200] GET /_snowpack/hmr-client.js
[snowpack] [200] GET /_snowpack/hmr-error-overlay.js

[inject-version] transform() starting… [public/index.html]
[inject-version] ✔ transform() success [public/index.html]
[snowpack] [200] GET /
[snowpack] [200] GET /_snowpack/hmr-client.js
[snowpack] [200] GET /index.css
[snowpack] [200] GET /_snowpack/hmr-error-overlay.js
[snowpack] [200] GET /logo.svg

[@snowpack/plugin-esbuild] load() starting… [src/index.ts]
[@snowpack/plugin-esbuild] ✔ load() success [src/index.ts]
[inject-version] transform() starting… [src/index.js]
[inject-version] ✔ transform() success [src/index.js]
...

$ yarn build --verbose
...
[snowpack] starting @snowpack/plugin-typescript run() (isDev=false)
[snowpack] generating meta files
[snowpack] ! building source files...

[@snowpack/plugin-esbuild] load() starting… [src/index.ts]
[@snowpack/plugin-esbuild] ✔ load() success [src/index.ts]
[inject-version] transform() starting… [src/index.js]
[inject-version] ✔ transform() success [src/index.js]

More Info
Initial report in Discussions: https://github.com/snowpackjs/snowpack/discussions/2526
Reproducible test case: https://github.com/richb-hanover/snowpack-inject-version-test

It is not running transform in your build because you have static: true in your snowpack.config.js - this will directly copy it to the final build with-out running any build step for it.
Just remove static and it should work - the default is static false.
So change your config to:
/** @type {import("snowpack").SnowpackUserConfig } */
module.exports = {
  mount: {
    public: { url: "/" },
    src: { url: "/dist" },
  },
  /* ... rest of your config ... */
}

Not sure why it's transforming during dev run. I think it should not run.

OK, I found why it's running in dev. It's running because for hot module reloading there is a need to inject a script - even for static files. (see https://github.com/snowpackjs/snowpack/blob/main/snowpack/src/commands/dev.ts#L875)
Once virtual files are added this behavior will change (see #1122). I'd expect that the transform will not run with static: true but I'm not sure.

Just remove static and it should work - the default is static false.

Bingo! This did indeed solve the problem. Thank you. (I will update my note in Discussions with this information.)
But... I see where I was led astray. You suggest that the default should for static should be false. I generated my test case with:
npx create-snowpack-app second-snowpack-test  --template @snowpack/app-template-blank-typescript --use-yarn

and the snowpack.config.js contains:
/** @type {import("snowpack").SnowpackUserConfig } */
module.exports = {
  mount: {
    public: {url: '/', static: true},
    src: {url: '/dist'},
  },
...

Should this be reported as a bug? Thanks again.

You're welcome.
No, this is correct as you typically want to copy everything as it is from your public folder to the build location. The folder is for static files like fonts, images etc.
Your case is a bit special because you're injecting it into the html file. With default I just meant that if there is no static prop, it will use the files during build.
For a front-end app you'd probably inject the version into your script and render it.

Ahah! That solves another peculiarity. My code currently reaches into the html file to get the "injected version" so that it can report the version elsewhere.
What I should do (as you suggest) is leave the HTML file static (and leave static:true in the snowpack config file), and inject the version directly into the .js file, where it can be doled out as needed. Thanks again!

Maybe you could also add your version to process.env so you can use it in your HTML and Javascript.
Please have a look at the following Gist to get an idea https://gist.github.com/AWolf81/edb0872c1cb8b4e96ec4bfbf2f15fc22
I'll check if that's possible to add to @snowpack/plugin-dotenv I think it should be possible to pass it as a plugin option.

Glad you found a solution! @richb-hanover it's fine to set the public directory to static:false if you want to transform the files within it. We just set it to true as a default for most users.
Starting in #2707 build will now match the behavior that you're seeing in dev, so at least you won't have this "works in one place, but not the other" issue.


Crash: SocketException

04-18 13:29:24.191 17989-18076/org.wordpress.android E/NosaraClient: Error while sending the events to the server
                                                                     java.net.SocketException: Software caused connection abort
                                                                         at java.net.PlainSocketImpl.socketConnect(Native Method)
                                                                         at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:334)
                                                                         at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:196)
                                                                         at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:178)
                                                                         at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:356)
                                                                         at java.net.Socket.connect(Socket.java:605)
                                                                         at com.android.okhttp.internal.Platform.connectSocket(Platform.java:113)
                                                                         at com.android.okhttp.Connection.connectSocket(Connection.java:196)
                                                                         at com.android.okhttp.Connection.connect(Connection.java:172)
                                                                         at com.android.okhttp.Connection.connectAndSetOwner(Connection.java:367)
                                                                         at com.android.okhttp.OkHttpClient$1.connectAndSetOwner(OkHttpClient.java:130)
                                                                         at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:329)
                                                                         at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:246)
                                                                         at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:457)
                                                                         at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:405)
                                                                         at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:521)
                                                                         at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
                                                                         at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java)
                                                                         at com.automattic.android.tracks.TracksClient$3.run(TracksClient.java:235)
                                                                         at java.lang.Thread.run(Thread.java:761)
                                                                     	Suppressed: javax.net.ssl.SSLHandshakeException: SSL handshake aborted: ssl=0x731a14fc00: I/O error during system call, Connection reset by peer
                                                                         at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
                                                                         at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:357)
                                                                         at com.android.okhttp.Connection.connectTls(Connection.java:235)
                                                                         at com.android.okhttp.Connection.connectSocket(Connection.java:199)
                                                                         		... 12 more

This is weird, since the socket exception is catched in Tracks, and logs are bumped fine. In fact, in the log above ,the error message is written here: https://github.com/Automattic/Automattic-Tracks-Android/blob/develop/AutomatticTracks/src/main/java/com/automattic/android/tracks/TracksClient.java#L259

I know it's considered bad practice generally speaking but in this particular case where we just need to keep running, does it make sense to catch the general Exception ?
I also doubted when I saw it but no other exceptions appeared in logcat
It might be an isolated case though, will circle back here if I see it again

I know it's considered bad practice generally speaking but in this particular case where we just need to keep running, does it make sense to catch the general Exception ?

We're already catching the general Exception there :)
So I doubt the crash is due to Tracks. Maybe the app crashed in another thread?

the thread says 04-18 13:29:24.191 17989-18076/org.wordpress.android E/NosaraClient: Error while sending the events to the server                                                                      java.net.SocketException: Software caused connection abort
¯_(ツ)_/¯ what do you think?

We're already catching the general Exception there :)
So I doubt the crash is due to Tracks. Maybe the app crashed in another thread?

My bad - double checked - closing


Using zio-sql with Scala 3

I'm trying to use zio-sql in a Scala 3 project, and I'm getting a failure to build.
It appears that there is no _3 artifact being published, so I added the following dependency to build.sbt:
      "dev.zio" %% "zio-sql" % "0.1.1" cross CrossVersion.for3Use2_13

I'm getting the following error:
[error] Modules were resolved with conflicting cross-version suffixes in ...:
[error]    dev.zio:zio-prelude _3, _2.13
[error]    dev.zio:zio-schema _3, _2.13
[error]    dev.zio:zio-stacktracer _3, _2.13
[error]    dev.zio:zio-prelude-macros _3, _2.13
[error]    dev.zio:izumi-reflect _3, _2.13
[error]    dev.zio:zio-internal-macros _3, _2.13
[error]    dev.zio:izumi-reflect-thirdparty-boopickle-shaded _3, _2.13
[error]    dev.zio:zio _3, _2.13
[error]    dev.zio:zio-schema-macros _3, _2.13
[error]    dev.zio:zio-streams _3, _2.13
[error]    dev.zio:zio-schema-derivation _2.13, _3
[error] (... / update) Conflicting cross-version suffixes in: dev.zio:zio-prelude, dev.zio:zio-schema, dev.zio:zio-stacktracer, dev.zio:zio-prelude-macros, dev.zio:izumi-reflect, dev.zio:zio-internal-macros, dev.zio:izumi-reflect-thirdparty-boopickle-shaded, dev.zio:zio, dev.zio:zio-schema-macros, dev.zio:zio-streams, dev.zio:zio-schema-derivation
[error] (... / ssExtractDependencies) Conflicting cross-version suffixes in: dev.zio:zio-prelude, dev.zio:zio-schema, dev.zio:zio-stacktracer, dev.zio:zio-prelude-macros, dev.zio:izumi-reflect, dev.zio:zio-internal-macros, dev.zio:izumi-reflect-thirdparty-boopickle-shaded, dev.zio:zio, dev.zio:zio-schema-macros, dev.zio:zio-streams, dev.zio:zio-schema-derivation

How are you guys using this library from your Scala 3 projects?

hello @daharon,  in my understanding CrossVersion. for3Use2_13 would work only if zio-sql had 0 dependencies, but 2.13 library build depends on 2.13 libraries (like zio, zio-schema) and if your project depends on scala 3 versions of the same libraries, there are conflicts.
So I am afraid there's no way to use ZIO SQL with Scala 3 at the moment. This month I am focused on simplifying core module, so scala 3 migration then will be easier. I will start focusing on that in couple of days.


Http stream v2

from v1:

use sol_util_memdup
write_cb returns a size_t
Added more http samples

I also miss a some features in the sample:

streaming: This is useful to simulate what people may do like broadcast video from a camera. Don't care about payload, you can keep reading from stdin and send to client or server. No content-length is to be defined, new data is pushed as it shows -- so for stdin tests, you can give it few seconds before sending more commands, like this: (echo "first batch"; sleep 10; echo "second batch") | ./stream-send
resume: This is useful to simulate resume, basically you stat() to get current size and provide that in the Range header, check the returned header to see if you got what you asked (I don't recall the semantics, maybe it may send you the whole file, in that case you'd ftruncate() and start from the beginning).

fixes on https://github.com/solettaproject/soletta/pull/1107


fix dependencies

Hey @denvned! I believe there are a few dependencies missing

Thank you @juhaelee!