Are you guys taking PR?

BNLTK is one of the most famous libraries for Bangla NLP task. Sadly it currently has slight incompatibility issues. There are also rooms for improvements.
If you guys are accepting PRs, we would love to contribute to the library.

I would like to know about it too.
The package is great but there needs to be a lot of updates in the package and I would like to contribute.

@abj-paul @IshmamR Thanks for showing your interest. Please feel free to submit PR. Also, I'll try to allow some time for maintaining the project.


Multiple changes I had to make for Ebou

This PR contains a couple of changes:
Segmented Control
This adds a segmented control. In order to know which index was selected (crucial to do something useful) I had to extend set_action to also receive an object (*const Object) which can then be inspected:
       let mut control = SegmentedControl::new(images, cacao::appkit::segmentedcontrol::TrackingMode::SelectOne);
        control.set_action(|index| {
            println!("Selected Index {index}");
        });

This is a bit of a pervasive change that goes through the whole codebase
Formatting
I'm using the default Rust Analysers auto formatting rules in all my code and somehow my settings are different than the one used in this codebase, so it added a lot of commas in places. I'm not sure if this is a problem for you or not.
Various

Support for SegmentedControl in Toolbar
Added more SFSymbols
Support loading images from URLs

I can look into the conflicts once I know whether you'd be willing to merge this PR :)

I'd say I'm probably down to merge this, because you're actually using it in a production application and discovering things that are necessary. :)
The aspect of it being a slightly invasive change is fine since this repo is prepping for a 0.4 anyway.

Awesome! I've fixed the merge conflicts 😄

Thanks!


Strange regex problem

npm run package yields
><EMAIL_ADDRESS>package /home/jacob/projects/vsc-logtalk
> vsce package

Executing prepublish script 'npm run vscode:prepublish'...

><EMAIL_ADDRESS>vscode:prepublish /home/jacob/projects/vsc-logtalk
> tsc -p ./

 ERROR  Invalid regular expression: /(?<domain>github(\.com\/|:))(?<project>(?:[^/]+)\/(?:[^/]+))(\/|$)/: Invalid group
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>package: `vsce package`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>package script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/jacob/.npm/_logs/2021-08-12T13_45_33_594Z-debug.log

There's no such line /(?<domain>github(\.com\/|:))[...]in the library. Will investigate.

https://www.gitmemory.com/issue/microsoft/vscode-vsce/569/837105561
Similar issue. I may have to upgrade to node 14.

Closed:
Works with node v14.17.5


Use args_schema=false query parameter - when appropriate

@ychiucco introduced this query parameter for GET /api/v2/task-group/ (ref https://github.com/fractal-analytics-platform/fractal-server/issues/1920) - starting from the next alpha release.
The default is true.
Whenever appropriate, the webclient should set args_schema=false, so that response bodies are much more lightweight.

Now available as of 2.7.0a9


Toleration keys regex prevents adding "/"

I'm running flux on Azure AKS which adds the kubernetes.azure.com/scalesetpriority=spot:NoSchedule taint to spot instances.
However, I can't add such key in toleration_keys in the flux provider.
I get the message:
│ Attribute toleration_keys[Value("kubernetes.azure.com/scalesetpriority")] a toleration key must begin with a letter or number, and may contain letters, numbers, hyphens, dots,
│ and underscores., got: kubernetes.azure.com/scalesetpriority

It seems that this is the line that is preventing me doing that.
I wonder if I'm the first one having such issue as I don't see anyone mentioning it.

You can add the toleration as patch in kustomization.yaml, docs here https://registry.terraform.io/providers/fluxcd/flux/latest/docs/resources/bootstrap_git#customizing-flux

In my case I'm using ~1 to represent /
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- gotk-components.yaml
- gotk-sync.yaml
patches:
      - op: add
        path: /spec/template/spec/nodeSelector/node-restriction.kubernetes.io~1reserved-for
        value: ...

@fbueno did @stefanprodan suggestion work? If so, are you happy for us to close this issue?

@fbueno @imishchuk-carbon an example of how to use kustomization_override can be found here


Completed missing meta fields

Motivation for this change
More complete package meta data.
This change just adds missing fields such as long and short descriptions, licence and project home page.
Things done

[ X ] Ensured that relevant documentation is up to date
[ X ] Fits CONTRIBUTING.md.

Looking good thanks :)
Oh although I missed this, for the future, format your commit messages as described in the Contribution Guidelines

Noted. Thanks @Infinisil :-)


Infinite redirect loop in NextJS development environment

Description
I'm getting this error constantly after logging into an account.
This is development environment and running on localhost

Package + Version

[ ] @clerk/clerk-js
[ ] @clerk/clerk-react
[x] @clerk/nextjs
[ ] @clerk/remix
[ ] @clerk/types
[ ] @clerk/themes
[ ] @clerk/localizations
[ ] @clerk/clerk-expo
[ ] @clerk/backend
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/fastify
[ ] @clerk/chrome-extension
[ ] gatsby-plugin-clerk
[ ] build/tooling/chore
[ ] other:

{
  "dependencies": {
    "@clerk/nextjs": "^4.21.12",
    "next": "13.4.7",
  }
}

Hello @Aayushpatil77 and thank you for opening this issue.
If the issue is not resolved after trying the 3 Reasons described in the error message, could you provide a repository that reproduces this error to investigate it more and get back to you?

Same issue here.
Using Next.js and getting an infinite redirect. But when we refresh the page again, it will work as expected.
GitHub repo example->https://github.com/adarsh-gupta101/Next-full-stack-editor

Github repo :- https://github.com/Aayushpatil77/ecommerce-dashboard

Had sort of the same issue. It works fine on localhost, but when I try to proxy (e.g. using ngrok) the browser gets stuck in an infinite loop. In my case, React does not display any error message.
I tried to run the debugger in Chrome; found this line to be the "culprit":
https://github.com/clerkinc/javascript/blob/019992f2063ba8580446edf98c760eabcc8fc71a/packages/backend/src/tokens/interstitial.ts#L101-L102
Why would my page suddenly have an empty fragment? I would expect that it is added in the call itself e.g.
-                        window.location.href = window.location.href;
+                        window.location.href = window.location.href + "#";

This with version @clerk/nextjs==4.19.0, seems fixed in @clerk/nextjs==4.21.13

I got this error after switching auth providers to Clerk, I got it to work by clearing my old cookies.

I got the same problem. Fresh install of T3, installed clerk, followed quick start docs and i got this error. Tried everything. Skewing time updating, checked keys. It doesn't work

This was with version @clerk/nextjs==4.19.0, seems fixed in @clerk/nextjs==4.21.13

I am using   "@clerk/nextjs": "^4.23.2" this version and still getting the error... If anyone knows how to fix it please do let me know

On my windows PC, syncing with the time server solved the issue. It might occur again, but I am good for now

Yeah it also worked for me

I am facing the same issue as of now. It was working fine the day before i was developing the app. when i ran the Next app again the next day, it's showing the infinite loop error. Is their any particular reason??

Clerk needs your system clock to be in sync with your current timezone. I synced my system timezone correctly. The clerk is working fine.

Clerk needs your system clock to be in sync with your current timezone. I synced my system timezone correctly. The clerk is working fine.

Yeah that was the problem

If you are experiencing this in NextJS, please add debug: true to your authMiddleware. See https://clerk.com/docs/nextjs/middleware#middleware-argument-types. This will give you debugging loads which can produce more information.
If you see an error like the one below, then it is indicating your clock is out of sync.
[0]   "message": "JWT issued at date claim (iat) is in the future. Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)"

When I try clearing the cookies it works for me, but after saving a few changes to my code, it doesn't work anymore

If you are experiencing this in NextJS, please add debug: true to your authMiddleware. See https://clerk.com/docs/nextjs/middleware#middleware-argument-types. This will give you debugging loads which can produce more information.
If you see an error like the one below, then it is indicating your clock is out of sync.
[0] "message": "JWT issued at date claim (iat) is in the future. Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)"

Thanks for the tip, it shows much clearer information now, the state for isSignedIn seems to be treated as false, with a JWT message

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)

This is confirming that your clock is out of sync and in the future. Syncing your clock with a time server should resolve this error.

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)

This is confirming that your clock is out of sync and in the future. Syncing your clock with a time server should resolve this error.

Thank you very much, it turns out that toggling "Set time automatically" and "Set time zone automatically", with synchronizing the time, and properly setting my time zone did the trick.

On my windows PC, syncing with the time server solved the issue. It might occur again, but I am good for now

Does anybody encouter it on production app? where use doesn't sync with time server from windows settings?
I mean, We developer fixing it on our device but what if it happens same with end users ? Where they didn't sync with time server?
(Mine also fixed with time server sync)

On my windows PC, syncing with the time server solved the issue. It might occur again, but I am good for now

Does anybody encouter it on production app? where use doesn't sync with time server from windows settings? I mean, We developer fixing it on our device but what if it happens same with end users ? Where they didn't sync with time server?
(Mine also fixed with time server sync)

Yikes, you're definitely right about that, there has to be a workaround this.

I am using "@clerk/nextjs": "^4.23.2". I have changed the time and time zone and I still getting the same error ... Does anyone have a solutions?

We've noticed. that certain users have bad cookie values which causes the infinite loop.
The cookie name is __client_uat and the bad value is 0 instead of some timestamp like<PHONE_NUMBER>
Once we clear this cookie the redirect loops are gone.
Our observation of this cookie is that it gets a bad value when we switch between the subdomains of our app - Production / Staging.

We've noticed. that certain users have bad cookie values which causes the infinite loop.
The cookie name is __client_uat and the bad value is 0 instead of some timestamp like<PHONE_NUMBER>
Once we clear this cookie the redirect loops are gone.
Our observation of this cookie is that it gets a bad value when we switch between the subdomains of our app - Production / Staging.

I didn't get this bad value, All I needed was to change the time zone. Thanks for sharing by the way

I am using "@clerk/nextjs": "^4.23.2". I have changed the time and time zone and I still getting the same error ... Does anyone have a solutions?

Which OS are you using If I may ask?

I"m using Windows 11. I changed my time and time zone. I cleared the cache
and cookies and I'm still getting the same error. Then I tried another web
browser and still the same...
Thanks for your time
El dom, 20 de ago de 2023 1:49 p. m., Timi @.***>
escribió:

I am using @.***/nextjs": "^4.23.2". I have changed the time and time
zone and I still getting the same error ... Does anyone have a solutions?
Which OS are you using If I may ask?
—
Reply to this email directly, view it on GitHub
https://github.com/clerkinc/javascript/issues/1436#issuecomment-1685352120,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUXR5LLQAMTKQI4F4D5HM43XWJE2DANCNFSM6AAAAAAZYYYU6Q
.
You are receiving this because you commented.Message ID:
@.***>

[image: image.png]
El dom, 20 ago 2023 a la(s) 19:07, Emilio Salvia @.***)
escribió:

I"m using Windows 11. I changed my time and time zone. I cleared the
cache and cookies and I'm still getting the same error. Then I tried
another web browser and still the same...
Thanks for your time
El dom, 20 de ago de 2023 1:49 p. m., Timi @.***>
escribió:

I am using @.***/nextjs": "^4.23.2". I have changed the time and time
zone and I still getting the same error ... Does anyone have a solutions?
Which OS are you using If I may ask?
—
Reply to this email directly, view it on GitHub
https://github.com/clerkinc/javascript/issues/1436#issuecomment-1685352120,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUXR5LLQAMTKQI4F4D5HM43XWJE2DANCNFSM6AAAAAAZYYYU6Q
.
You are receiving this because you commented.Message ID:
@.***>

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)

This is confirming that your clock is out of sync and in the future. Syncing your clock with a time server should resolve this error.

Thank you very much, it turns out that toggling "Set time automatically" and "Set time zone automatically", with synchronizing the time, and properly setting my time zone did the trick.

thanks when i setup then restart computer that okay;

Hi mate
I'm having this bug yet...
I've tried everything, cleared cookies and cache, changed time and time
zone automatically. I deleted the project and created it from scratch and
still have the same infinity loop bug....
El lun, 21 ago 2023 a la(s) 09:21, zhou jing @.***)
escribió:

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer
Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European
Summer Time); (reason=token-not-active-yet, token-carrier=cookie)
This is confirming that your clock is out of sync and in the future.
Syncing your clock with a time server should resolve this error.
Thank you very much, it turns out that toggling "Set time automatically"
and "Set time zone automatically", with synchronizing the time, and
properly setting my time zone did the trick.
[image: image]
https://user-images.githubusercontent.com/68476321/260267986-2a4edf9f-dee4-436b-9a1b-a48cb9913469.png
thanks when i setup then restart computer that okay;
—
Reply to this email directly, view it on GitHub
https://github.com/clerkinc/javascript/issues/1436#issuecomment-1686319785,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUXR5LM5OT3J6BQGIENK4QTXWNOFDANCNFSM6AAAAAAZYYYU6Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

I"m using Windows 11. I changed my time and time zone. I cleared the cache and cookies and I'm still getting the same error. Then I tried another web browser and still the same... Thanks for your time El dom, 20 de ago de 2023 1:49 p. m., Timi @.> escribió:
…
I am using @./nextjs": "^4.23.2". I have changed the time and time zone and I still getting the same error ... Does anyone have a solutions? Which OS are you using If I may ask? — Reply to this email directly, view it on GitHub <#1436 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUXR5LLQAMTKQI4F4D5HM43XWJE2DANCNFSM6AAAAAAZYYYU6Q . You are receiving this because you commented.Message ID: @.***>

I want you to sign out first, signout, clear browser cookies, local storage, session-storage, and browsing data for your app. Change the time and zone, as I screenshot earlier, then try again. One thing I've noticed is to try different devices. You can either host it online to test it, or use ngrok

@emLuc86dev maybe this #1566 is the cause of your bug? it also causes infinite loop but for a different reason that the timezone one

Now this one I've not seen before, @emLuc86dev try using the debug mode and share what error you seem to be having

You're welcome

Issued at date: Mon Jul 10 2023 19:40:49 GMT+0200 (Central European Summer Time); Current date: Mon Jul 10 2023 19:40:38 GMT+0200 (Central European Summer Time); (reason=token-not-active-yet, token-carrier=cookie)

This is confirming that your clock is out of sync and in the future. Syncing your clock with a time server should resolve this error.

Thank you very much, it turns out that toggling "Set time automatically" and "Set time zone automatically", with synchronizing the time, and properly setting my time zone did the trick.

thanks when i setup then restart computer that okay;

You're welcome @jokereven

We've noticed. that certain users have bad cookie values which causes the infinite loop.
The cookie name is __client_uat and the bad value is 0 instead of some timestamp like<PHONE_NUMBER>
Once we clear this cookie the redirect loops are gone.
Our observation of this cookie is that it gets a bad value when we switch between the subdomains of our app - Production / Staging.

Is your staging using Dev keys from Clerk? If so, we would recommend either:

using production keys (sharing the user base) for staging so the cookies are the same
using a second domain and a second, free Production instance for staging to have a limited user base.

I"m using Windows 11. I changed my time and time zone. I cleared the cache and cookies and I'm still getting the same error. Then I tried another web browser and still the same...

Did you add debug: true (see https://github.com/clerkinc/javascript/issues/1436#issuecomment-1668728895)? If so, what were the results of the log?

This error happens after a long time of not using the app. The session token will expire at that time, and a page on the site needs to load to refresh. This is what I've noticed; not sure if it's what's happening.
For me, if I don't use the app for a long time, and then I visit a protected page hoping that I'll be redirected, typically, the error shows up, but at that time, Clerk would have done refresh, and when I reload the page, everything works fine again. I am sure that it's not an issue with my time.
Has anyone else noticed the same thing?

I'm now pretty sure that this is what is happening, at least for me.
The token is usually expired when loading the app after a long time.

Maybe someone else should try it

This issue has been open for nearly 2 months and now encapsulates several different issues from different people, some resolved, some maybe not. In an effort to clean things up a bit, going to close this out. Please do not interpret this as us not caring - we know that this error has been difficult for many, and have been discussing how to improve it internally. Please feel free to open a new issue, ideally with a reproduction, for anyone still encountering this issue!

I am still encountering this issue. syncing the timezone didn't solve the problem

I am still encountering this issue. syncing the timezone didn't solve the problem

Which Operating System are you encountering this issue on?

I am still encountering this issue. syncing the timezone didn't solve the problem

Which Operating System are you encountering this issue on?

Connecting to the application from Windows 11 (tried from 2 different laptops). application is running on an Ubuntu EC2 instance.

I am still encountering this issue. syncing the timezone didn't solve the problem

Which Operating System are you encountering this issue on?

Connecting to the application from Windows 11 (tried from 2 different laptops). application is running on an Ubuntu EC2 instance.

Okay, did you try syncing your time?

I am still encountering this issue. syncing the timezone didn't solve the problem

Which Operating System are you encountering this issue on?

Connecting to the application from Windows 11 (tried from 2 different laptops). application is running on an Ubuntu EC2 instance.

Okay, did you try syncing your time?

Yes, I followed the steps in the thread. didn't fix the problem

I am still encountering this issue. syncing the timezone didn't solve the problem

Which Operating System are you encountering this issue on?

Connecting to the application from Windows 11 (tried from 2 different laptops). application is running on an Ubuntu EC2 instance.

Okay, did you try syncing your time?

Yes, I followed the steps in the thread. didn't fix the problem

Okay, I would need you to turn these off and on again, and then click sync. After that clear your cookies and hit Ctrl + Shift + R

I'm running this app behind varnish and realized with debug logging turned on that the nextUrl variable is localhost:3000 instead of the hostname the browser is using. The behavior I'm experience is everything works absolutely fine until the session is expired.
I looked around the clerk dashboard and found that in paths everything was setup to use clerk components, whereas I have the app hosting it. I adjusted those settings but the redirect loop remains. I do see the clerkUrl is set to what I configured in paths now. I've previously cleared all browser data and was able to sign-in. Hit this again and not feeling confident in shipping what we have to customers.
docent-backend-dashboard-1  | [clerk debug start: authMiddleware]
docent-backend-dashboard-1  |   URL debug, {
docent-backend-dashboard-1  |     "url": "http://localhost:3000/",
docent-backend-dashboard-1  |     "method": "GET",
docent-backend-dashboard-1  |     "headers": "{\"accept\":\"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7\",\"accept-encoding\":\"gzip, deflate\",\"accept-language\":\"en-US,en;q=0.9\",\"cache-control\":\"\",\"connection\":\"keep-alive\",\"cookie\":\"__client_uat=1696990712; __session=eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc18yVnRiOWM1RU9vek51U0d1T25taG1nZVBCSFMiLCJ0eXAiOiJKV1QifQ.eyJhenAiOiJodHRwOi8vZGFzaGJvYXJkLmxvY2FsLmRvY2VudGFwcC5jbyIsImV4cCI6MTY5NzIzMTY1NywiaWF0IjoxNjk3MjMxNTk3LCJpc3MiOiJodHRwczovL2dsb3Jpb3VzLWJ1Y2stMzYuY2xlcmsuYWNjb3VudHMuZGV2IiwibmJmIjoxNjk3MjMxNTg3LCJvcmdfaWQiOiJvcmdfMlZ0Y0ZnNllkOTB4UGlURk9TSDlKbjhFMWluIiwib3JnX3JvbGUiOiJhZG1pbiIsIm9yZ19zbHVnIjoiZG9jZW50Iiwic2lkIjoic2Vzc18yV2JBNERHZVhlanBUOG10enlzMjZLMWczWmsiLCJzdWIiOiJ1c2VyXzJWdGNCeFRLamVTdU1HdjZWT0ZLTVlKREtnWiJ9.Q9V8M5wLp6wyLur-Mkt5MNE8PDy-iYXzlxFQXcqudDJp4b70srbvgo6Ug_9UQDcQ-uZqLh0S_WvoJqA3uKc4Md2D4e6BXaBxgr6igvRhKw8J9ier4G4yEsA36wr0TMRowSugj23YRFDhaKeIOZM112guQJj_uPlD1KmziVbw_51iRHL59mLuD5JBL-9JzSEEci87BflPUqW4O4s_58G6rLo1X2umnhAA1yQ24tlAAXHvpYyw_iI5cKQUoISrbJADGEZMl1CMRl7I8RpdnjwsWgsr_IVXdrwnk_7ANGYvQxzJ25u9eASR4MKyrcWWofH6mi1Duqfnyw13xp2kSUYgew; __clerk_db_jwt=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJkZXYiOiJkdmJfMldHczdhWDhOSFRpVWUzUDMyUUN2YnB2dnJ6IiwiaWQiOiJjbGllbnRfMldHc0RSN1dRblUzaHJrRk1ZdHFGRTVOaHdBIiwicm90YXRpbmdfdG9rZW4iOiI3Z28yOTd1aGNjOGtzc29wd211eHhtNDZ2eWs4OWIzY3RvMmIwajdoIn0.cWnvJyZMKcPu7XCZcH2vMd-Yl-8-XTneHE3ZFwwOLj-ndc37famsBGxhxGQ6HgAK7KZAt6CXwV8f8kMYJJB2N7OjeVfylZ0ZiMFibyP3fJ0qaLHc1rB-NrlQIvJd8C3ECVQM5iF84kF6OTRShqOh9jI0hUv5xup_qGPJ_wfBnZMNp3C18hixZiJljaidmKInEiG-8DAAXu-9irIa6xPSQFjBbCm1MumKFMRCrqVeCA5J2MynQHBdAyryZYNYnlEc4TpAGuDXyTw1wDZpe9j5H2cMsY7AWylQqrbCsW0O4Wjq11O_BNCArTzBobc3uKCyIT8cHXaUoLjh8fWtnl2O2g\",\"host\":\"dashboard.local.docentapp.co\",\"referer\":\"http://dashboard.local.docentapp.co/\",\"sec-fetch-mode\":\"cors\",\"upgrade-insecure-requests\":\"1\",\"user-agent\":\"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36\",\"via\":\"1.1 6af71816a8f5 (Varnish/7.3)\",\"x-forwarded-for\":\"<IP_ADDRESS>\",\"x-invoke-output\":\"\",\"x-invoke-path\":\"\",\"x-invoke-query\":\"\",\"x-middleware-invoke\":\"1\",\"x-varnish\":\"33111\"}",
docent-backend-dashboard-1  |     "nextUrl": "http://localhost:3000/",
docent-backend-dashboard-1  |     "clerkUrl": "http://dashboard.local.docentapp.co/"
docent-backend-dashboard-1  |   }
docent-backend-dashboard-1  |   Options debug, {
docent-backend-dashboard-1  |     "debug": true,
docent-backend-dashboard-1  |     "beforeAuth": false,
docent-backend-dashboard-1  |     "afterAuth": false
docent-backend-dashboard-1  |   }
docent-backend-dashboard-1  |   authenticateRequest state is interstitial, {
docent-backend-dashboard-1  |     "status": "interstitial",
docent-backend-dashboard-1  |     "reason": "token-expired",
docent-backend-dashboard-1  |     "message": "JWT is expired. Expiry date: Fri, 13 Oct 2023 21:14:17 GMT, Current date: Fri, 20 Oct 2023 16:22:34 GMT. (reason=token-expired, token-carrier=cookie)",
docent-backend-dashboard-1  |     "frontendApi": "glorious-buck-36.clerk.accounts.dev",
docent-backend-dashboard-1  |     "publishableKey": "<redacted>",
docent-backend-dashboard-1  |     "isSatellite": false,
docent-backend-dashboard-1  |     "domain": "",
docent-backend-dashboard-1  |     "proxyUrl": "",
docent-backend-dashboard-1  |     "signInUrl": "/user",
docent-backend-dashboard-1  |     "isSignedIn": false,
docent-backend-dashboard-1  |     "isInterstitial": true,
docent-backend-dashboard-1  |     "isUnknown": false
docent-backend-dashboard-1  |   }
docent-backend-dashboard-1  | [clerk debug end: authMiddleware] (@clerk/nextjs=4.25.6,next=13.4.19)

The issues you encountered are likely due to dependency deprecation errors, which are not uncommon in JavaScript. Here's a step-by-step solution to address these problems:

Begin by updating the clerkjs and nextjs versions in your package.json file to the latest available versions.

Delete the .next build file to ensure a fresh build with the updated dependencies.

Clear the npm cache by running the following command:

npm cache clean --force

After clearing the cache, perform a fresh install by executing:
npm install

These steps should resolve the issues you encountered. If you encountered these problems while dockerizing your client-server architecture, it's essential to ensure that the dependencies are updated and compatible. If you have any further questions or need assistance, feel free to reach out to me via direct message. Good luck with resolving the issue!

I was getting this error when using node v20, switching back to 18 resolved it for me

I was getting this error when using node v20, switching back to 18 resolved it for me

This is not working with me :(

I'm shocked this issue has been prolonged to this extent. I'm running node v20 and this works fine. But I get this error once in a while, It's not an everytime thing now. I suggest updating your timezone, and dependencies. Make sure you're running the latest version of @clerk/nextjs
If you are using pnpm simply just run the following commands

Check for outdated dependencies

$ pnpm outdated

Update the dependencies

pnpm up --latest

[!IMPORTANT]
If you have updated the @clerk/nextjs dependency and still you face this issue. You could then try downgrading your Node.js version to v18.

I'm still experiencing this issue with v18 downgrade and npm up --latest. Due to being sick I haven't been signed into prod in over a week and it's handling it fine. Cannot get my local to stop infinite redirect until I delete all my browser data. Just doing it for the site wasn't sufficient in my prior attempts at working around it. Fresh sign-in works fine until 7 days later you get infinitely redirected.
The middleware logging I added looks the same as before:
docent-backend-dashboard-1  |   authenticateRequest state is interstitial, {
docent-backend-dashboard-1  |     "status": "interstitial",
docent-backend-dashboard-1  |     "reason": "token-expired",
docent-backend-dashboard-1  |     "message": "JWT is expired. Expiry date: Fri, 13 Oct 2023 21:14:17 GMT, Current date: Mon, 06 Nov 2023 15:59:28 GMT. (reason=token-expired, token-carrier=cookie)",
docent-backend-dashboard-1  |     "frontendApi": ".clerk.accounts.dev",
docent-backend-dashboard-1  |     "publishableKey": "",
docent-backend-dashboard-1  |     "isSatellite": false,
docent-backend-dashboard-1  |     "domain": "",
docent-backend-dashboard-1  |     "proxyUrl": "",
docent-backend-dashboard-1  |     "signInUrl": "/user",
docent-backend-dashboard-1  |     "isSignedIn": false,
docent-backend-dashboard-1  |     "isInterstitial": true,
docent-backend-dashboard-1  |     "isUnknown": false
docent-backend-dashboard-1  |   }

it got solved when i installed the latest version of clerk and nextjs
On Mon, 6 Nov 2023 at 23:43, Jim Porter @.***> wrote:

I'm still experiencing this issue with v18 downgrade and npm up --latest.
Due to being sick I haven't been signed into prod in over a week and it's
handling it fine. Cannot get my local to stop infinite redirect until I
delete all my browser data. Just doing it for the site wasn't sufficient in
my prior attempts at working around it. Fresh sign-in works fine until 7
days later you get infinitely redirected.
The middleware logging I added looks the same as before:
docent-backend-dashboard-1 | authenticateRequest state is interstitial, {
docent-backend-dashboard-1 | "status": "interstitial",
docent-backend-dashboard-1 | "reason": "token-expired",
docent-backend-dashboard-1 | "message": "JWT is expired. Expiry date: Fri,
13 Oct 2023 21:14:17 GMT, Current date: Mon, 06 Nov 2023 15:59:28 GMT.
(reason=token-expired, token-carrier=cookie)",
docent-backend-dashboard-1 | "frontendApi": ".clerk.accounts.dev",
docent-backend-dashboard-1 | "publishableKey": "",
docent-backend-dashboard-1 | "isSatellite": false,
docent-backend-dashboard-1 | "domain": "",
docent-backend-dashboard-1 | "proxyUrl": "",
docent-backend-dashboard-1 | "signInUrl": "/user",
docent-backend-dashboard-1 | "isSignedIn": false,
docent-backend-dashboard-1 | "isInterstitial": true,
docent-backend-dashboard-1 | "isUnknown": false
docent-backend-dashboard-1 | }
—
Reply to this email directly, view it on GitHub
https://github.com/clerk/javascript/issues/1436#issuecomment-1795665445,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2J45USQ3WO7MTREIIYTB3DYDEOVDAVCNFSM6AAAAAAZYYYU6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJVGY3DKNBUGU
.
You are receiving this because you commented.Message ID:
@.***>

I'm still experiencing this issue with v18 downgrade and npm up --latest. Due to being sick I haven't been signed into prod in over a week and it's handling it fine. Cannot get my local to stop infinite redirect until I delete all my browser data. Just doing it for the site wasn't sufficient in my prior attempts at working around it. Fresh sign-in works fine until 7 days later you get infinitely redirected.
The middleware logging I added looks the same as before: docent-backend-dashboard-1 | authenticateRequest state is interstitial, { docent-backend-dashboard-1 | "status": "interstitial", docent-backend-dashboard-1 | "reason": "token-expired", docent-backend-dashboard-1 | "message": "JWT is expired. Expiry date: Fri, 13 Oct 2023 21:14:17 GMT, Current date: Mon, 06 Nov 2023 15:59:28 GMT. (reason=token-expired, token-carrier=cookie)", docent-backend-dashboard-1 | "frontendApi": ".clerk.accounts.dev", docent-backend-dashboard-1 | "publishableKey": "", docent-backend-dashboard-1 | "isSatellite": false, docent-backend-dashboard-1 | "domain": "", docent-backend-dashboard-1 | "proxyUrl": "", docent-backend-dashboard-1 | "signInUrl": "/user", docent-backend-dashboard-1 | "isSignedIn": false, docent-backend-dashboard-1 | "isInterstitial": true, docent-backend-dashboard-1 | "isUnknown": false docent-backend-dashboard-1 | }

May I ask which clerk dependency you installed?

@creative-tutorials turns out it was not a dependency issue at all. I finally figured out on my own that if you are using a hostname other than localhost over http you hit this redirect due https upgrade header. When I opened up the port on my container and accessed the app via localhost:3000 it worked as designed. I mentioned all of this in a support thread on discord. Honestly kind of dissappointed with the lack of support here from Clerk. I had to debug and figure this out, not one staff member even ones I reached out to directly helped me figure out what's going on. If there were FOSS I'd be totally okay with this, but a paid product...not a good look.

@creative-tutorials turns out it was not a dependency issue at all. I finally figured out on my own that if you are using a hostname other than localhost over http you hit this redirect due https upgrade header. When I opened up the port on my container and accessed the app via localhost:3000 it worked as designed. I mentioned all of this in a support thread on discord. Honestly kind of dissappointed with the lack of support here from Clerk. I had to debug and figure this out, not one staff member even ones I reached out to directly helped me figure out what's going on. If there was FOSS I'd be totally okay with this, but a paid product...not a good look. A callout in the docs is all I've asked but it's fallen on deaf ears. Catching it via software and producing a warning instead of an infinite redirect would be better.

Glad you resolved the issue, didn't even know such a little change could cause such a big issue.

@creative-tutorials turns out it was not a dependency issue at all. I finally figured out on my own that if you are using a hostname other than localhost over http you hit this redirect due https upgrade header. When I opened up the port on my container and accessed the app via localhost:3000 it worked as designed. I mentioned all of this in a support thread on discord. Honestly kind of dissappointed with the lack of support here from Clerk. I had to debug and figure this out, not one staff member even ones I reached out to directly helped me figure out what's going on. If there was FOSS I'd be totally okay with this, but a paid product...not a good look. A callout in the docs is all I've asked but it's fallen on deaf ears. Catching it via software and producing a warning instead of an infinite redirect would be better.

Hi @jameslporter we are facing the exact same issue where our deployed container shows https://localhost:3000 in the Clerk debug info instead of the actual hostname, which fails with https. Did you find a workaround to make it work with an external hostname?
  URL debug, {
    "url": "https://localhost:3000/",
    "method": "GET",
    "headers": "{...}",
    "nextUrl": "https://localhost:3000/",
    "clerkUrl": "https://localhost:3000/"
  }

I'd suspect that is due to reverse proxy. The only way I can get clerk dev environment working correctly is http://localhost:3000 and that port being open directly to the nodejs container, not the proxy. I use varnish and it's fine for our stage/prod envs.
For clarification I'm guessing based on a week of pulling my hair out. Been asking clerk for clarification in the documentation but it seems it's fallen on dead ears. I've had better support from unpaid open source projects than this.

@creative-tutorials turns out it was not a dependency issue at all. I finally figured out on my own that if you are using a hostname other than localhost over http you hit this redirect due https upgrade header. When I opened up the port on my container and accessed the app via localhost:3000 it worked as designed. I mentioned all of this in a support thread on discord. Honestly kind of dissappointed with the lack of support here from Clerk. I had to debug and figure this out, not one staff member even ones I reached out to directly helped me figure out what's going on. If there was FOSS I'd be totally okay with this, but a paid product...not a good look. A callout in the docs is all I've asked but it's fallen on deaf ears. Catching it via software and producing a warning instead of an infinite redirect would be better.

Hi @jameslporter we are facing the exact same issue where our deployed container shows https://localhost:3000 in the Clerk debug info instead of the actual hostname, which fails with https. Did you find a workaround to make it work with an external hostname?
  URL debug, {
    "url": "https://localhost:3000/",
    "method": "GET",
    "headers": "{...}",
    "nextUrl": "https://localhost:3000/",
    "clerkUrl": "https://localhost:3000/"
  }

I never changed much in my code, but I did change some things in my clerk dashboard tho

thx @jameslporter , seems to be related to changes in Next v14, see my comment in #2115. It might be a recently introduced bug in Next 14 or an issue with how Clerk determines the current protocol and hostname.

Nope I'm on 14 as well. It's not a code problem. It's how you are running
it. Again the only way I've gotten it to work properly for http localdev is
to use localhost:3000. Getting kind of frustrated with the lack of support
here. I feel like I'm the clerk support staff trying to help others through
the problems I experienced. I really just want confirmation that my
hypothesis is correct and if so this be stated clearly in the
documentation. My requests have fallen on deaf ears.
On Wed, Nov 15, 2023 at 9:30 AM stx-chris @.***> wrote:

thx @jameslporter https://github.com/jameslporter , seems to be related
to changes in Next v14, see my comment in #2115
https://github.com/clerk/javascript/issues/2115. It might be a recently
introduced bug in Next 14 or an issue with how Clerk determines the current
protocol and hostname.
—
Reply to this email directly, view it on GitHub
https://github.com/clerk/javascript/issues/1436#issuecomment-1812752449,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAG5UDPU5UVDYYBFRBYDK3YETN27AVCNFSM6AAAAAAZYYYU6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSG42TENBUHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Ok in that case our issues are different, because local development and build work fine and we don't get any token-related issues. It's the same with Next v13 and v14.
But once we build our Docker image and upload it to Google Cloud, with the only difference being the Next.js version, Clerk's url debug value is http://localhost:3000 within the Docker container on v13 and https://localhost:3000 on v14 and the error reason we receive is cross-origin-referrer, which is expected in that case.

We have received one reproduction for Next 14 specific redirect issues. Engineering is looking st this. We encourage the creation of reproductions of your issue where and when possible, and posting those in https://github.com/clerk/javascript/issues/2115.

If only the people who knew the answer were here to help. Godspeed and good
luck! Maybe if you share more about your docker setup we can find out what
isn't quite right.
On Wed, Nov 15, 2023, 9:47 AM stx-chris @.***> wrote:

Ok in that case our issues are different, because local development and
build work fine and we don't get any token-related issues. It's the same
with Next v13 and v14.
But once we build our Docker image and upload it to Google Cloud, with the
only difference being the Next.js version, Clerk's url debug value is
http://localhost:3000 within the Docker container on v13 and
https://localhost:3000 on v14 and the error reason we receive is
cross-origin-referrer, which is expected in that case.
—
Reply to this email directly, view it on GitHub
https://github.com/clerk/javascript/issues/1436#issuecomment-1812782957,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAG5UEROSQUJLHYRVLKZ6TYETPYNAVCNFSM6AAAAAAZYYYU6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSG44DEOJVG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

@jameslporter Our issue seems to be fixed in the latest Next.js canary release 14.0.3-canary.9. Wanna give it a try?

@stx-chris @creative-tutorials @jameslporter After digging heavily into Next's internals, as well as performing a number of tests with SSL termination and reverse proxying, I'm fairly confident that the PR we submitted to Next.js earlier today, will solve these issues.
Currently, the PR is approved and, once merged, the changes will be available as a canary build of v14.0.3.
In the meantime, you should should be able to mitigate these issues by setting the X-Forwarded-Host request header to the Host header via Varnish, or otherwise.
This was my configuration via Caddy:
localhost {
  reverse_proxy localhost:3000 {
    header_up X-Forwarded-Host {host}
  }
}

In short, if X-Forwarded-Host is already set, Next doesn't overwrite it with the incorrect value.

Awesome thanks for the update. I'm curious what kind of integration tests do you all have around clerk/nextjs and how do you go about testing new next releases to ensure regressions like this don't happen?

thx @jameslporter , seems to be related to changes in Next v14, see my comment in #2115. It might be a recently introduced bug in Next 14 or an issue with how Clerk determines the current protocol and hostname.

@stx-chris @creative-tutorials @jameslporter After digging heavily into Next's internals, as well as performing a number of tests with SSL termination and reverse proxying, I'm fairly confident that the PR we submitted to Next.js earlier today, will solve these issues.
Currently, the PR is approved and, once merged, the changes will be available as a canary build of v14.0.3.
In the meantime, you should should be able to mitigate these issues by setting the X-Forwarded-Host request header to the Host header via Varnish, or otherwise.
This was my configuration via Caddy:
localhost {
  reverse_proxy localhost:3000 {
    header_up X-Forwarded-Host {host}
  }
}

In short, if X-Forwarded-Host is already set, Next doesn't overwrite it with the incorrect value.

Thanks for the update

I was getting this error when using node v20, switching back to 18 resolved it for me

Thanks, It worked for me. i was on node v21, switched back to 18 and it's working

I still have the issue as well on node 18. Works on localhost directly to the service. Doesn't work through my varnish front proxy that maps the hostnames to service backend host. The same varnish setup works in stage/prod as it's using https via AWS elb with certificate manager. I sent my har files to Colin.

I had same issue but I solved it.
The following is what we did this time.

switch to node v18.18.2 (current latest version)
install latest version of @clerk/nextjs
update packages.

After changing node 20.10.0 to node 18.12.1, it working fine.

If anyone is still having this issue, please make sure your date-time and timezone are set to automatically update. clear cookies, and run your application in incognito mode. If this doesn't work try reconfiguring your application with Clerk again by following the docs.

hmmm still broken on my end

We are experiencing the exact same error since releasing our production environment. The issue might be tied to the __client_uat cookie which is available twice if both the develop and the main instance are running on the same domain.
We have the following scenario:

development on a.b.c.mysite.io
main on app.mysite.io

This is the cookie we see on main:

__client_uat = <timestamp>

This is what we see on develop:

First cookie, domain "a.b.c.mysite.io": __client_uat = <timestamp>
Second cookie, domain ".mysite.io": __client_uat = 0

Once one has visited the main site with their browser and switch to develop to test something, the site is trapped in an infinite loop with the error referring to the said cookie, ie.
The Cookie '__client_uat'  has been rejected for invalid domain.
We have to painfull clear the cookies, refresh everything and refrain from accessing the live site in the same session. It never occurs on localhost. Anybody else having this issue?
(Node v18.17.0, @clerk/nextjs v4.29.3, in Docker)

I just ran into the same issue after updating my node to v.21. I resolved the issue by downgrading node to v.18 and updating nextjs to v.14.1.0

I just ran into the same issue after updating my node to v.21. I resolved the issue by downgrading node to v.18 and updating nextjs to v.14.1.0. Hope this might help someone!

This will help a lot. Thanks!
But I want to know who else is still having this issue. I'm on node v.20.10.0 and I haven't noticed these issues for a long time, it comes back yes, but when I sync my time, I don't notice it again. The issue only comes back whenever I run into a low battery on my laptop.

I'm running into this on node v21.6.1

I'm running into this on node v21.6.1

Try syncing your clock please

I just ran into the same issue after updating my node to v.21. I resolved the issue by downgrading node to v.18 and updating nextjs to v.14.1.0. Hope this might help someone!

This will help a lot. Thanks!
But I want to know who else is still having this issue. I'm on node v.20.10.0 and I haven't noticed these issues for a long time, it comes back yes, but when I sync my time, I don't notice it again. The issue only comes back whenever I run into a low battery on my laptop.

We are also having this issue. Still have no clue how to fix it.

This is due to clerk not supporting multiple instances on the same
host/domain name. I've asked clerk to call it out in the docs to
avoid confusion. They have a future feature planned that would support
instances across subdomain. Use another hostname and you won't hit the
infinite redirect.
On Wed, Jan 31, 2024, 1:39 PM Rey @.***> wrote:

I just ran into the same issue after updating my node to v.21. I resolved
the issue by downgrading node to v.18 and updating nextjs to v.14.1.0. Hope
this might help someone!
This will help a lot. Thanks!
But I want to know who else is still having this issue. I'm on node
v.20.10.0 and I haven't noticed these issues for a long time, it comes back
yes, but when I sync my time, I don't notice it again. The issue only comes
back whenever I run into a low battery on my laptop.
We are also having this issue. Still have no clue how to fix it.
—
Reply to this email directly, view it on GitHub
https://github.com/clerk/javascript/issues/1436#issuecomment-1919805667,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAG5UFXJ6CHKZPPCU2GUKDYRKMWDAVCNFSM6AAAAAAZYYYU6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJZHAYDKNRWG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

@jameslporter yes I just figured out it must be something like that. I was running prod on mydomain.com and a staging instance on a subdomain, staging.mydomain.com.  This caused the infinite loop. I found out that if I cleared my cookies etc. in Chrome and then viewed the subdomain, it would work (at least for a while), but once I viewed the prod instance things would be screwed up again.
Great to hear there is future work planned to support this across subdomains; would rather not have to pay for extra domains just to support a staging environment (unless that's a best practice for some reason etc.)

For me upgrading to (@clerk/nextjs=4.29.7,next=14.0.4 did not help, but eventually clearing cookies and localstorage did

@dimkl Github repo :- https://github.com/Aayushpatil77/ecommerce-dashboard

Not found!

For me upgrading to @clerk/nextjs=4.29.7,next=14.0.4 did not help, but eventually clearing cookies and localstorage did

It happened only in development or even the production?

For me upgrading to @clerk/nextjs=4.29.7,next=14.0.4 did not help, but eventually clearing cookies and localstorage did

It happened only in development or even the production?

It only helped for the initial page load but same issue after I refreshed. I have figured out the final fix now. Seem to be a Nextjs Issue. Upgrading to 14.1.3 solved the issue eventually. https://github.com/vercel/next.js/issues/55648

Mainly

For me upgrading to @clerk/nextjs=4.29.7,next=14.0.4 did not help, but eventually clearing cookies and localstorage did

It happened only in development or even the production?

It only helped for the initial page load but same issue after I refreshed. I have figured out the final fix now. Seem to be a Nextjs Issue. Upgrading to 14.1.3 solved the issue eventually. vercel/next.js#55648

Mainly everyone should just upgrade to Next.js 14.1.3. It worked for me as I upgraded as well.

Yes, upgrading my Next.js ('^14.2.1') worked for me. Just do npm install next@latest  and it should install the latest Next.js which should resolve this issue with clerk.

We are experiencing the exact same error since releasing our production environment. The issue might be tied to the __client_uat cookie which is available twice if both the develop and the main instance are running on the same domain.
We have the following scenario:

development on a.b.c.mysite.io
main on app.mysite.io

This is the cookie we see on main:

__client_uat = <timestamp>

This is what we see on develop:

First cookie, domain "a.b.c.mysite.io": __client_uat = <timestamp>
Second cookie, domain ".mysite.io": __client_uat = 0

Once one has visited the main site with their browser and switches to develop to test something, the site is trapped in an infinite loop with the error referring to the said cookie, ie.
The Cookie '__client_uat' has been rejected for invalid domain.
We have to painfull clear the cookies, refresh everything and refrain from accessing the live site in the same session. It never occurs on localhost. Anybody else having this issue?
(Node v18.17.0, @clerk/nextjs v4.29.3, in Docker)

Same issue here. @stx-chris did you figure out a solution? Was it solved by updating to the latest packages?

Hi guys, I figured out that the issue is related to the local storage and session's keys. When I delete them it works as expected. I guess this happens when the authentication failed. This is my only for my case.

I got into redirect loop with these packages
clearning localstorage and session keys does not help
"next": "^14.2.3",
"@clerk/nextjs": "4.30.1",

@hieutrluu Could you please open a new issue or reach out to<EMAIL_ADDRESS>with a minimal reproduction? Thank you!

I found a rather dumb reason why I was being infinitly redirected in my end. In the middleware.ts setup, I had my RouteMatcher configured like so:
import { NextResponse } from "next/server";

const isProtectedRoute = createRouteMatcher(["/(.*)"]);

export default clerkMiddleware((auth, req) => {
  if (isProtectedRoute(req)) {
    auth().protect();
  }

  return NextResponse.next();
});

export const config = {
  matcher: ["/((?!.+.[w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
};

The problem was that the createRouteMatcher method was configured to redirect every path starting with "/", which Im assuming included the /sign-up page and created the loop.
Changing the line to const isProtectedRoute = createRouteMatcher(["/"]); fixed my problem.
(I added the wildcard cause I wanted to make every route private, seems I might have to find another way...)

Everyone has different ways on how to solve this issue, mainly I'd just upgrade all my packages to latest, and make sure my date-and-time are correct

I faced the redirect issue due to middleware. Make sure, you include the sign in/sign up path in public path routes. Next, redirect won't happen anymore.
const isPublicRoute = createRouteMatcher(['/agency/sign-in(.*)', '/agency/sign-up(.*)', '/_next(.*)'])

Only in development. If your users have a misconfigured clock chances are that they are having problems accessing all types of web pages.

From: Greg Wozniak @.>
Sent: Thursday, December 12, 2024 12:28:44 PM
To: clerk/javascript @.>
Cc: Vinicius Pinho @.>; Comment @.>
Subject: Re: [clerk/javascript] Infinite redirect loop in NextJS development environment (Issue #1436)
So my users will need to sync their clock to the timezone or it's just happening for development?
—
Reply to this email directly, view it on GitHubhttps://github.com/clerk/javascript/issues/1436#issuecomment-2539286976, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXFVS2LBV7K5TSYE2QE34GL2FGTSZAVCNFSM6AAAAAAZYYYU6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZGI4DMOJXGY.
You are receiving this because you commented.Message ID: @.***>


Problem with button alligment

The button is not in the middle of the ripple. I m using Autolayout, NavigationController and iOS8.

I'm having the same exact issue, have you found any solution?

Did you find any solution ?

I had the same Issue. I solved it updating the continuoousripples method.
Just changed this line
CGPoint shapePosition = [self convertPoint:self.center fromView:nil];
For this one
CGPoint shapePosition = [self convertPoint:self.center fromView:self.superview];
It now centers around the target button.
Hope it helps

Guess the solution posted by @virginiapujols should work. I'll try to fix this from my end too


[BACKEND] Support the conversion of nested layout "#slice->#dot->#third_party_mma" to LinearLayout

The method DotOperandEncodingAttr::getElemsPerThread is used when converting the nested layout: #slice->#dot->#mma to the LinearLayout.
But the implementation only supports the MMA layout of the in-tree GPU dialect which blocks the third party extensions.
Use the interface DistributedEncodingTrait::getSizePerThread to replace the getTotalElemsPerThread in the SliceEncodingAttr::toLinearLayout. Because the DotOperandEncodingAttr::getSizePerThread is implemented based on MmaTraits interface, we can support the nested slice layout for the third party extension as well.
The changes has been covered by the existing LinearLayout conversion unittest.

Hi @ptillet
This is an API change using the LinearLayout as first option to support third party extension. Can you help to see if the changes make sense?

cc @lezcano Are you working on something similar to this?

I can prioritise that work after I finish with my current line of work (i.e. I can start working on that next week).
I agree it might be best to postpone this change to until then, as reading https://github.com/intel/intel-xpu-backend-for-triton/issues/2823, it seems that this change is not blocking anything.

@lezcano Thanks for reviewing the changes to support the out-of-tree backends.
I have a question about this "This will happen naturally once all layouts inherit from LinearEncodingAttr".
Can you share some insights of about supporting the out-of-tree backends?
Right now the Intel backends extends the layout attribute by inherit the DistributedLayout and override the interface toLinearLayout
https://github.com/triton-lang/triton/blob/acc25d91fba850c18c099e7e577962ba56bdd06c/include/triton/Dialect/TritonGPU/IR/TritonGPUAttrDefs.td#L506

I am not working on this, but this looks very reasonable to me.
As a side note, I think at some point we should cache the LL computations, otherwise our compile times are going to explode. This will happen naturally once all layouts inherit from LinearEncodingAttr. When we do that, they'll all use this implementation:
https://github.com/triton-lang/triton/blob/79f0eaeb520292bc39bd027f5b4eecee20b161aa/lib/Dialect/TritonGPU/IR/Dialect.cpp#L1646-L1654

There is a problem of the basesPerDim because the LL losses the information of the sizes of each rank of the legacy layout. It is not able to deduce the exactly correct sizes information only from in-dim register when there is redundant values of the case that tensor size < SizePerThread. Especially for slice layout.


feat(lint): implement useNumberProperties

Summary
close #1228
Implement prefer-number-properties

Test Plan
Add snaps for valid/invalid cases

An error occurred in Run Biome Format in Check JS Files CI due to adding a new rule.
So I fixed in 8b0ed4f.


chore: bump json5 from 2.2.1 to 2.2.3

error: https://github.com/IBM/networking-node-sdk/security/dependabot/37
Bumps json5 from 2.2.1 to 2.2.3.

Release notes
Sourced from json5's releases.

v2.2.3

Fix<EMAIL_ADDRESS>is now the 'latest' release according to npm instead of v1.0.2. (#299)

v2.2.2

Fix: Properties with the name __proto__ are added to objects and arrays.
(#199) This also fixes a prototype pollution vulnerability reported by
Jonathan Gregson! (#295).

Changelog
Sourced from json5's changelog.

v2.2.3 [code, diff]

Fix<EMAIL_ADDRESS>is now the 'latest' release according to npm instead of
v1.0.2. (#299)

v2.2.2 [code, diff]

Fix: Properties with the name __proto__ are added to objects and arrays.
(#199) This also fixes a prototype pollution vulnerability reported by
Jonathan Gregson! (#295).

Commits

c3a7524 2.2.3
94fd06d docs: update CHANGELOG for v2.2.3
3b8cebf docs(security): use GitHub security advisories
f0fd9e1 docs: publish a security policy
6a91a05 docs(template): bug -> bug report
14f8cb1 2.2.2
10cc7ca docs: update CHANGELOG for v2.2.2
7774c10 fix: add proto to objects and arrays
edde30a Readme: slight tweak to intro
97286f8 Improve example in readme
Additional commits viewable in compare view

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


http: add support for removing request headers.

While there, move header modification in some tests from
route action level (deprecated in #3838) to route level.
Risk Level: Low
Testing: bazel test //test/...
Docs Changes: Added
Release Notes: Added
Fixes #4249.
Signed-off-by: Piotr Sikora<EMAIL_ADDRESS>

cc @bplotnick


Implementation detail in Merge

In implementing merge, I choose to include that if at a certain level of merging, when merging an array into an array  and comparing values that aren't undefined or other objects, the function will check if an arrays value exists in the other array. If it doesn't exist it will push the value to the end of the array to merge them.
However, this could make the function much slower with bigger arrays. In checking how Lodash treated this case, they treat an array like an object so each element only compares with the element of the same index(key).
Expected behaviour

merge({ 'a': { 'b': [ 3, 4, 15] } }, { 'a': { 'b': [9, 18]} })

{ a: { b: [ 9, 18, 15 ] } }

Actual behaviour

merge({ 'a': { 'b': [ 3, 4, 15] } }, { 'a': { 'b': [9, 18]} }))

{ a: { b: [ 3, 4, 15, 9, 18 ] } }

References

_.merge

I'm good with this :+1:
I wonder where Lodash's version of merge was sourced from. I assume it would work like a union (ie how you implemented it) but that's clearly not the case.
Good catch BTW, that's a pretty obscure bug.

Fixed in 0.67.2


fix(refine-modal): include facets from atomic-external

Consider all atomic-search-interface & atomic-external for the facet acquisitions of the refine-modal.
Rough algo

If a facet is not in a section, put it in the 'orphan bucket'
Sort facet by interface
In a same interface, put vertical facet first, horizontal facet second
Once all non-orphaned facets are sorted out, sort the orphan facets in DOM order, and add'em.

KIT-3428

Looks good, I tested with the facet-manager and also with automatic facets. Two things :
1-The facets in the facet manager seem to be in random order.
   < atomic-layout-section section="facets">
          <atomic-facet field="author" label="facet1"></atomic-facet>
          <atomic-facet-manager>
            <atomic-facet field="author" label="facet10"></atomic-facet>
            <atomic-facet field="author" label="facet11"></atomic-facet>
            <atomic-facet field="author" label="facet12"></atomic-facet>
          </atomic-facet-manager>
        </atomic-layout-section>

first load  second load

We are having facets on all the same fields, so yeah, suboptimal for the facet manager 😆
Facet manager order facets like they want, then we follow for those

2-The automatic facets are being put at the bottom.
<atomic-layout-section section="facets">
          <atomic-facet field="author" label="facet1"></atomic-facet>
          <atomic-automatic-facet-generator
            desired-count="3"
          ></atomic-automatic-facet-generator>
        </atomic-layout-section>

If you put the automatic facet after the static facet, yeah, that make sense 😅

This sorting stuff is so annoying 😢

Complicated indeed, let's go with baby steps, I think it's better than what's currently in place :)


black formatting

Hi I noticed the style in the code varies a bit. What do you think of adding a github action that checks the black style + a pre-commit hook to do the formatting on changed file?
If you approve ill open a pr with the changes

Its a bad idea to format the code for a user without him having the option to review it first. what I meant was the github action will just validate the formatting rules, and the pre-commit hook will format the changed files of the commit and send them back from the staging area, so the user must do git add again on them.


Add links to awesome tools and tutorials for building chat bots | Hacktoberfest

This repository contains links to awesome tools and resources for building chat bots. If you know of some cool tool or tutorial for making bots that is missing in this repo please make a Pull request. :tada: . Thanks for being awesome. Happy Hacktoberfest.

Hello :)
I would like to add two links about bot analytics:

Dialog - https://dialoganalytics.com/
Dashbot - https://www.dashbot.io/

I was wondering if you wanted to create a new category like "Bot analytics", or if I add these two links in "Tools For Building Bots" ? and I will make a PR ;)
Cheers,

@janteuni I think Bot analytics deserve a category of it's own. Looking forward to your PR. :)


Snippet for opentelemetry

Hello,
Thanks for your awesome library. I am relatively new to it (and to rust & flutter in general).
I have a classical library that declares a oltp exporter and sends spans:
#[tokio::main(flavor = "current_thread")]
pub async fn init() {
    global::set_text_map_propagator(TraceContextPropagator::new());

    let mut mymap = HashMap::new();
    mymap.insert("Content-Type".to_string(), "application/json".to_string());

    let tracer = opentelemetry_otlp::new_pipeline()
        .tracing()
        .with_exporter(
            opentelemetry_otlp::new_exporter()
                .http()
                .with_headers(mymap)
                .with_endpoint("http://localhost:8080/traces"),
        )
        .with_trace_config(
            opentelemetry::sdk::trace::config().with_resource(Resource::new(vec![KeyValue::new(
                opentelemetry_semantic_conventions::resource::SERVICE_NAME,
                "rust-client",
            )])),
        )
        .install_batch(opentelemetry::runtime::TokioCurrentThread)
        .expect("pipeline install error");

    let telemetry = tracing_opentelemetry::layer().with_tracer(tracer);
    let subscriber = Registry::default().with(telemetry);
    tracing::subscriber::set_global_default(subscriber).unwrap();
    global::tracer("ex.com/basic");
}

and another function
#[tokio::main(flavor = "current_thread")]
pub async fn doStuff() {

   // Fancy wrap on  an instrumented reqwest async client (https://github.com/TrueLayer/reqwest-middleware)
    let client = client::ClientBuilder::new_unauthenticated("localhost:8080")
        .insecure()
        .build_async()
        .await
        .unwrap();

    let auth_endpoint = Login::builder()
        .email("test@example.com".to_string())
        .password("abc".to_string())
        .build()
        .unwrap();

    let token: types::user::Tokens = auth_endpoint.query_async(&client).await.unwrap();
}

In flutter, I have
    api.init().then((value) => api.doStuff().then((value) => {}));

The http calls between the rust and the server are working for login but the span are never sent.
I tried with all combination of the async workaround shown here: https://cjycode.com/flutter_rust_bridge/article/async_in_rust.html and adjusting  .install_batch(opentelemetry::runtime::TokioCurrentThread) accordingly.
If I execute the same rust code with a more classical #[tokio::main], everything works.
It feels like the rust lib is suspended and never has the ability to send the spans.
Any pointers would be very appreciated - I am a bit out of my depth ;).
Thanks.

More about async: https://github.com/fzyzcjy/flutter_rust_bridge/issues/966

Thanks for your quick reply.
I modified everything to work with sinks, as hinted but to no avail.
#[tokio::main(flavor = "current_thread")]
pub async fn init() {
    global::set_text_map_propagator(TraceContextPropagator::new());

    let mut mymap = HashMap::new();
    mymap.insert("Content-Type".to_string(), "application/json".to_string());

    let tracer = opentelemetry_otlp::new_pipeline()
        .tracing()
        .with_exporter(
            opentelemetry_otlp::new_exporter()
                .http()
                .with_headers(mymap)
                .with_endpoint("http://localhost:8080/traces"),
        )
        .with_trace_config(
            opentelemetry::sdk::trace::config().with_resource(Resource::new(vec![KeyValue::new(
                opentelemetry_semantic_conventions::resource::SERVICE_NAME,
                "rust-client",
            )])),
        )
        .install_simple() //tried with batch + Tokio  and batch + TokioCurrentThread.
        .expect("pipeline install error");

    let telemetry = tracing_opentelemetry::layer().with_tracer(tracer);
    let subscriber = Registry::default().with(telemetry);
    tracing::subscriber::set_global_default(subscriber).unwrap();
    global::tracer("ex.com/basic");
}

pub fn tick(sink: StreamSink<i32>) {
    let mut ticks = 0;

    loop {
        if ticks == 0 {

        sink.add(ticks);
        sleep(ONE_SECOND);
        if ticks == i32::MAX {
            break;
        }

        // force all spans to flush
        for result in TracerProvider::default().force_flush() {
            if let Err(err) = result {
                println!("{}", err);
                panic!("{}", err);
            }
        }

        ticks += 1;
    }
}

and dart
    ticks = api.tick();
    // api.initSynced();
    api.init().then((value) => {
        api.run().then((value) => {
          // print values
    });

The rust doesn't panic and the traces are not sent.

IMHO the best way is to PR such that frb supports async rust, because current workarounds has some drawbacks IIRC.

Hi! I have written about how I use Tokio runtime in my personal project together with Flutter Rust bridge here: https://www.zaynetro.com/post/flutter-rust-bridge-2023/#tokio-runtime
To summarize:

Instead of using tokio macros I start the runtime manually and store it in a global variable
Then whenever I need to call an async method I grab the runtime and block on it.

use tokio::runtime::Runtime;

static RUNTIME: Mutex<Option<Runtime>> = Mutex::new(None);

pub fn start() -> Result<()> {
    // Initialize a runtime
    let rt = tokio::runtime::Builder::new_multi_thread()
        .worker_threads(2)
        .enable_all()
        .thread_name("bolik-timeline-client")
        .build()?;

    // Here we can spawn background tasks to be run on the runtime.

    // Store runtime in a global variable
    *RUNTIME.lock().expect("Set runtime") = Some(rt);
    Ok(())
}

pub struct Person {
    pub id: i32,
    pub name: String,
    pub age: u16,
}

pub fn save_person(name: String, age: u16) -> Result<Person> {
    // We are calling async methods from a thread that is not managed by
    // Tokio runtime. For this to work we need to enter the handle first.
    // Ref: https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.current
    let mut rt_guard = RUNTIME.lock().expect("Get runtime");
    let rt = rt_guard.as_mut().expect("Runtime present");
    let _guard = rt.enter();

    // Let's pretend that we have `othercrate::save_person` function that returns a `Future<String>`.
    let id = rt.block_on(othercrate::save_person(name, age))?;
    Ok(Person {
        id,
        name,
        age,
    })
}

Sadly, I am not familiar with opentelemetry enough but with tracing_subscriber there is a way to register your own writer which could be used to forward events whenever you want.
tracing_subscriber::fmt()
        .with_writer(log_sink /* this is my custom struct that could write log events anywhere */)
        .try_init()


make tab key insert tabs and set tab size to 4 in playground

these changes make it so that you can easily use tabs in the playground

Is this accessible? How would a keyboard user navigate away from the text box? (We've discussed the escape key working in this case. Is that automatic somehow or do you need to add code?)

I think using escape to unfocus the code editor and allow navigating to the next interactive element with tab is a good idea.
It would also be nice to indent every line within the selection, if present, as well.

escape to unfocus sounds like a good idea, indenting every selected line sounds a little tricky to implement so probably out of scope for this PR


ignore vim generated swap files and vim session files

Reasons for making this change:

I use the Python.gitignore file for python projects and edit in a vim environment. This change would stop me and similar developers from needing to add gitignore lines for vim swap and session files for every python project.
TODO
Links to documentation supporting these rule changes:

Thanks for the contribution, but we will need more context about swap sessions and these like minded developers.
Can you provide links?

swap files:
http://vimdoc.sourceforge.net/htmldoc/recover.html
Session files:
https://dockyard.com/blog/2018/06/01/simple-vim-session-management-part-1
Like minded developers:
https://console.dev/articles/neovim-best-code-editor-ide-for-developers/
https://www.vimfromscratch.com/articles/vim-for-python
With neovim's recently implemented language server support, its a valid competitor to IDE's, and can do (or be configured to do) almost everything a modern IDE offers. I use it along with Tmux and have no problems.


cleanup triangle_facts

code cleanup

Looks good! Take a look at the comments and refactor a bit but no need to resubmit this one.

Good work!  Take a look at the comments, refactor and resubmit.  You're almost done!


Browser cache issues

How to avoid browser cache? When all css/js is concatenated, it generates 'application.css' and 'application.js' files, and then serve them to the browser. Concatenated file name is strictly related with manifest file, so if I want to change name of concatenated javascript file, I should change manifest file to. And I should do this in every deployment. There could be some option to pass concatenated file version or something like that and force browser to download new / updated javascript file.

I think that the better way to do that is to add a hash of all file at the end of the name application.css and application.js like Ruby On Rails do.


[Feature Request] Airr URL See More Is cutting Description

Hello again @marcjulianschwarz !!!
Airr URL has an text See More That collapses Description and cuts a great amount of the text .

Would be amazing if the command Podcast Note: Add Podcast Note.  Brings the whole description of the URL.

Let me know if you need more information
Have a great day!

I wrote about this in issue #3 .


iOS GCM Example compilation error - missing<EMAIL_ADDRESS>

error<EMAIL_ADDRESS>No such file or directory

Fixed by removing<EMAIL_ADDRESS>reference from Shared group in Xcode.

Thanks! Think that one is resolved now.


Create GitHub Actions

Needed Actions

[x] Build and Test
[x] Publishing nuget packages
[x] Update DocFX api documantation and reference manual

all actions are testet and runing


Add extra buttons on right click

What do you think?
If you approve, don't merge this, but I suggest selecting the Rebase option, so we can avoid unnecessary merge commits :)

In the gif you can't see it correctly and I made a change so you only need to right click once to show the buttons for every extension.
Normal view (same as before)

After one right click

This will allow the extension to look lightweight but still show all the options after one click.

This gif is clearer:

Hi @bfred-it you are much better than me, So I think you wont need to create merge request anymore unless you want to discuss with me something. You can take full control to this.
And I'm sorry I'd like to add you as secondary publisher to this extension, but my account is holding several extensions for my clients. So I can not add you to my account.
But I will take your idea, enable auto publish for this extension.
Thank you very much again, you make this extension much better and I learned a lot from you.

Ok :)
I've been sending PRs for big features that you might not be interested in. But thank you for your trust!
I'll add the auto-publish feature later and after that you can go on Travis and enter the three values you can get from here: https://github.com/DrewML/chrome-webstore-upload/blob/master/How to generate Google API keys.md

OK


Unsaved changes state recurring after saving Markdown including new line characters

Describe the bug

I keep getting the "Unsaved Changes" status even after actually saving it and not changing anything. It's probably caused by a new line in the Markdown editor. This character is represented as "" when I look at the Markdown viewer within the editor.
To Reproduce

Go to an edit page with a Markdown editor included
Type some text into the editor
Press Shift+Enter (on Windows) to create a new line
Type some more text after the new line
Save changes
For a second, the "Saved Changes" message is showing but is immediately replaced by "Unsaved Changes" again.

Expected behavior

Expected was to maintain the Saved Changes state since nothing was changes after pressing the save button
Screenshots

Applicable Versions:

Netlify CMS version<EMAIL_ADDRESS>and<EMAIL_ADDRESS>Git provider: Github
OS: Windows 10
Browser version: Chrome 79.0.3945.88

Node.JS version: 12.14.0

CMS configuration

backend:
  name: git-gateway
  branch: master
  use_large_media_transforms_in_media_library: false
media_folder: static/img
public_folder: /img
publish_mode: editorial_workflow
collections:
  - name: contentpages
    label: Content pages
    files:
      - label: Homepage
        name: homepage
        file: src/pages/contentpages/homepage.md
        fields:
          - label: Title
            name: title
            widget: string
          - label: url
            name: url
            widget: hidden
            default: /
          - label: Body
            name: body
            widget: markdown

Thanks for opening - this is covered in #2211, please track there.

@erquhart My issue has nothing to do with collections nor custom editor components. Might be another issue or do you think it's the same?

I've just run into this and I'm not using custom editor components either... just a few text inputs and a wysiwyg.
It's a problem because it prevents using editorial workflow – I can't publish because I'm told there are unsaved changes.


Cannot create new database

I'm submitting a...

[X] Bug report
[ ] Feature request
[ ] Question

Current behavior

I am trying to use db:create <dbname> to create a new MySQL database. When the database.json is populated with connection information with the database specified the command fails stating that the database does not exist (doh! I am trying to create it!)
$ ./node_modules/.bin/db-migrate db:create todos
[ERROR] AssertionError [ERR_ASSERTION]: ifError got unwanted exception: ER_BAD_DB_ERROR: Unknown database 'todos'

Expected behavior

The database key in database.json is ignored when running db:create
Minimal reproduction of the problem with instructions

Make sure the "todos" database does not exist in your MySQL database

database.json

{
  "dev": {
    "driver": "mysql",
    "host": "<IP_ADDRESS>",
    "user": "root",
    "password": "root",
    "database": "todos"
  }
}

Run

$ db-migrate db:create todos

What is the motivation / use case for changing the behavior?

To be able to provide stable way to create and seed database for developers when they start working on the project.
Environment

db-migrate version: 0.11.6
no plugins used
db-migrate driver with versions: db-migrate-mysql 1.1.10

Additional information:
- Node version: v12.4.0
- Platform: Linux (but I assume this is not platform specific :) )

I have the same error.
If i remove 'database' param form my config then db:create work.
It like look db:create try connect to mysql with db-name before db created.


Create dataset loader for VLSP2016-NER

Dataloader name: vlsp2016_ner/vlsp2016_ner.py
DataCatalogue: http://seacrowd.github.io/seacrowd-catalogue/card.html?vlsp2016_ner

Dataset
vlsp2016_ner

Description
This dataset is collected from electronic newspapers published on the web and provided by VLSP organization. It consists of approximately 15k sentences, each of which contain NE information in the IOB annotation format.

Subsets
-

Languages
vie

Tasks
Named Entiy Recognition

License
Creative Commons Attribution Non Commercial 4.0 (cc-by-nc-4.0)

Homepage
https://huggingface.co/datasets/datnth1709/VLSP2016-NER-data

HF URL
https://huggingface.co/datasets/datnth1709/VLSP2016-NER-data

Paper URL
https://drive.google.com/file/d/18FuXxRM0slTeReQUCOj8IiToB5eqVQCT/view

#self-assign


po files

I am setting up a site with this way, however I wanted to make sure to use a file format for translations that can be sent to translators, or used with standard translation tools. Found out that .po file seems common, also it is an easy text format.
So: I have an example, basic code. Wonder if it should be cleaned up and added to the project, or maybe be an example?
It introduces one dependency on a po file parser.
This is how it works:
Mty sample now have english and spanish. I make two .po files (en.po and es.po), add in a folder somewhere, in my case src/developer/_translations (src/developer is my input directory).
This is how the spanish .po file looks like (es.po):
# Main page
#, fuzzy
msgid "hello"
msgstr "Hola"

msgid "world"
msgstr "mundo"

Added dependency: npm install gettext-parser --save-dev
And in .eleventy.js this is added. Yes can be cleaned up. And could potentially be a made into a patch, but first I want to hear what you think....
const i18n = require('eleventy-plugin-i18n');

const fs = require('fs');
const gettextParser = require("gettext-parser");

function getTranslations() {
    const baseDir = './src/developer/_translations'

    const locales = ['en-US', 'es-ES']

    var translations = {}

    const loadLocale = (locale) => {

        const getTranForLang = (lang) => {
            var poFile = baseDir + "/" + lang + ".po";
            var input = fs.readFileSync(poFile);
            var po = gettextParser.po.parse(input);
            var poTranslations = po.translations['']; // output translations for the default context
//            console.log(poTranslations);
            return poTranslations
        }
        const addPoTranslations = (poTranslations) => {
            for (var key in poTranslations) {
                var poEntry = poTranslations[key]
                var msgid = poEntry.msgid
                var msgstr = poEntry.msgstr[0]

                var obj = translations[msgid] || {};
                obj[locale] = msgstr
                translations[msgid] = obj
            }
        }
        const lang = locale.substr(0,2);

        const poTranslations = getTranForLang(lang)
        addPoTranslations(poTranslations)
    }

    locales.forEach(loadLocale)

    console.log("Translations")
    console.log(translations)

    return translations;
}

module.exports = function(eleventyConfig) {

    var translations = getTranslations()
        // translations: {
        //     hello: {
        //         'en-US': 'Hello',
        //         'es-ES': 'Hola'
        //     }
        // },

    eleventyConfig.addPlugin(i18n, {
        translations: translations,
        fallbackLocales: {
            '*': 'en-US'
        }
    });

Hey @hankhero, thanks for taking the time to write this up. Definitely think that enabling plugin users the ability to work from PO files is a great idea.
Perhaps this could be a helper function exported from the plugin? I'll take some time to explore this too, and we'll see where we can get it to.

I've not had time to dig back into this, but have spotted https://github.com/sgissinger/eleventy-plugin-i18n-gettext/, which might offer more of what you're after 🙂


Time trend models for individuals

Resolves #493
REVIEW AFTER #491
This PR adds functionality for computing and applying time trends for individuals' nutrient values.
In a nutshell, add these for each nutrients in StaticLinear.json:
  69             "Trend": {
  70                 "Range": [0.0, 5.0],
  71                 "Intercept": 0.0,
  72                 "Coefficients": {
  73                     "Gender": 0.0,
  74                     "Age": 0.0,
  75                     "Age2": 0.0,
  76                     "Age3": 0.0,
  77                     "Sector": 0.0,
  78                     "Income": 0.0
  79                 },
  80                 "LogCoefficients": {
  81                     "FoodCarbohydrate": 1.0,
  82                     "FoodFat": 1.0,
  83                     "FoodProtein": 1.0,
  84                     "FoodSodium": 1.0
  85                 }
  86             },
  87             "ExpectedTrend": 1.0

The main changes are loading and verifying these values in model_parser.cpp, and adding/using new initialise_trends/update_trends in static_linear_model.cpp. These are applied after base nutrients are computed, and before expected value adjustment occurs.
Both time trend and final nutrient values are clipped with their respective ranges throughout. Any questions or need a walkthrough, please reach me on chat. Please do test this @jzhu20, to make sure it is what you wanted.

Thank you, @jamesturner246 . Since it's added to the nutrient models, does the trend change as individual ages, or has changes in income, etc.?

Hi @jzhu20 . Nope, it stays constant throughout life as originally requested.

@jamesturner246 I'll try to take a look at this today

A ...ModelDefinition factory class shares with a ...Model class, so we don't need to copy twice. Idea is eventually baseline and intervention points to the same backend model params, constructed with the same ...ModelDefinition factory. Very open to better ideas though!

No better ideas here! Just wanted to check there was actually more than one instance of each std::shared_ptr around. It's a perfectly sensible way of doing things.


Fix: TypeError: $ is not a function

I've noticed this error on two different (WordPress) sites. It happens when focusing on the select box.
TypeError: $ is not a function /select2.js Line 641
Apologises if it's already been reported, I couldn't find the issue reported.

jQuery should be imported on the second/third line of the file, and the tests are failing because we are using noConflict in tests to ensure that this isn't an issue.

@kevin-brown I'm not really sure I understand how to resolve the issue? How should jQuery be imported?

jQuery should be included before Select2 on the page. As long as this happens, Select2 will pick up jQuery through the shim and it should be imported correctly through the rest of Select2.
On the second line of utils.js is where we are actually importing jQuery into the file.
If this isn't actually happening, I'd need to see a fiddle or link to a live site where this is an issue, so I can try to debug the issue.


operator/watchers: skip expensive debug log operations when disabled

Guard expensive computation of service-related log fields to skip it if debug logs are disabled, as not used at all. In particular, rendering services and endpoints into the corresponding string representation is demanding both in terms of CPU time and memory allocations.
Related: 52c06e1b3b05 ("Add checks to avoid use of logrus WithFields function in hot paths")

/test

Re-implemented as https://github.com/cilium/cilium/pull/35567 got merged in the meanwhile. @pippolo84 PTAL :pray:

/test


[Alert] Use getContrastText for filled variant font color

I have made a small update in Alert.js
Changes:

Implementation of getContrastText method

Deploy preview: https://deploy-preview-29813--material-ui.netlify.app/components/alert/
Closes #29731

@SamoraMabuya Thanks for your first contribution. Can you explain what's the issue are you trying to fix?

@siriwatknp
I was trying to get variant font color  to  show  correct contrast color with getContrastTest method. From what I understand the test contrast is supposed to be dependent on the background color.

@siriwatknp  https://github.com/mui/material-ui/issues/29731, but https://github.com/mui/material-ui/pull/29813#discussion_r753862934 (second sentence).


v0.5 release goals

For v0.5 release I'm thinking of adding the following to the library:

[ ] #93
[ ] #80
[ ] Enable custom logic for constraint evaluation in the prover.
[ ] #52

Suggestions/comments are welcome.

It could be nice to also lift the restriction on the number of auxiliary segments in this release. The required changes are in these commits: https://github.com/maxgillett/winterfell/commit/4d5490f59a5c5e98aa598297765cf4c981c6640e, https://github.com/maxgillett/winterfell/commit/f48ac44b6d2ecb9266f03928cd1aea0741709db5, and https://github.com/maxgillett/winterfell/commit/463ee452278ce78ab29b7708ddff8354a5c73e70, but a test case for the library is still missing.
For the third point do you mean custom divisors? I've implemented constraint-specific transition exemptions in https://github.com/maxgillett/winterfell/commit/6169c6d6abb031f9effc052fab8b55734b56d9b6, but it might be better for performance to make this segment-specific if there isn't a need to specify exemptions at a more granular level. There is some discussion of it in https://github.com/novifinancial/winterfell/pull/91#discussion_r874544533.

It could be nice to also lift the restriction on the number of auxiliary segments in this release.

Added!

For the third point do you mean custom divisors?

I actually meant something different: right now constraint evaluation is shared between prover and verifier (the logic is provide via evaluate_transition() functions etc. from the Air trait). This is nice because we have to write constraint evaluation logic only once and both the prover and the verifier can use it. But it also limits optimization opportunities in the prover where we know we are working with base field elements and could apply various optimizations based on that.
So, I was thinking of adding something like evaluate_constraints() function to the Prover trait. The default implementation of this function would cover these lines but then the implementers would be free to override this implementation with something different.

Hi， I wonder how the  the ARK1 and ARK2 generated for rp64-256 come from? I run the algorithm 5 from https://eprint.iacr.org/2020/1143.pdf can not generate the same ARK1 and ARK2

When is distributed proving coming?

Superseded by #154


PublisherClient/SubscriberClient snippets

Snippets supporting How-to guides @ https://cloud.google.com/pubsub/docs/how-to
FYI, @pongad

Changes Unknown when pulling 5da936adf0f62dbd716e98c404e7bf68cd46f6c0 on jabubake:pubsub_snippets into ** on GoogleCloudPlatform:master**.

Changes Unknown when pulling 5da936adf0f62dbd716e98c404e7bf68cd46f6c0 on jabubake:pubsub_snippets into ** on GoogleCloudPlatform:master**.

LGTM after merge conflicts are resolved - @lesv , do you want to take a look too?

Changes Unknown when pulling e053154de274198479cda5f693b7b11128f673e7 on jabubake:pubsub_snippets into ** on GoogleCloudPlatform:master**.

Changes Unknown when pulling c701671358af40e85eb1cf1500859b1929dcb4ce on jabubake:pubsub_snippets into ** on GoogleCloudPlatform:master**.

Changes Unknown when pulling<PHONE_NUMBER>de9625fdf0e7251d83c61e376365da on jabubake:pubsub_snippets into ** on GoogleCloudPlatform:master**.

Well, I'm happy, but Travis is not. :(

The logs show errors in pubsub tests, but not related to the snippets. I've restarted Travis build.
@garrettjonesgoogle, @pongad  : is there an easy way to restart the appveyor build ?  Appveyor logs show the pubsub package test failures, fyi.

I can't see a button to restart it. The AppVeyor UI isn't terribly intuitive...


🐞[Bug]: proper aligning

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
Patient Portal
Size decrement of the container
Feedback Section
size decrement if your feedback input
Add ScreenShots
Below ss from the deploy of the repo.

What browsers are you seeing the problem on?
Chrome
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@varshith257 please assign me this issue.

@varshith257 please assign me this issue.

@varshith257 please assign me this issue.

@varshith257 please assign me this issue.

@varshith257 please assign me this issue.

@Anjaliavv51 Also see this

This distorted the navbar on the homepage breaking a gap. Could you remove it too? Better move the js code out from it to a separate file  email-validator.js

Something Emergency text also appearing below the Copy Code

@varshith257 yes , i observed it too.


check if the group exists before prepend the middleware

depends on prependMiddlewareToGroup implementation we should check if the group exists or not, because if it doesn't exist, it will ignore adding the middleware to the group

If it doesn't exist, then ignoring is the expected behavior in my opinion.
Do you have a different use-case that justify that changed behavior?


question: How can I create a useg epg

How can I create a useg epg

Will be included in the coming release.

hi @danischm
i see the new configuration of useg epg but i don't find a resource for fvVmAttr
resource "aci_rest_managed" "fvVmAttr" {
class_name = "fvVmAttr"
dn         = "${aci_rest_managed.fvCrtrn_ubuntu.dn}/vmattr-0"
content = {
operator = "startsWith"
type     = "vm-name"
value    = "ubuntu"
name     = "0"
}
}

Hi @micronemo,
Currently VM based uSeg attribute is not supported and it needs to be implemented by updating sub-module terraform-aci-useg-endpoint-group. In my undertanding, VM based uSeg attribute supports unlimited nesting which makes it more complex than network based IP/MAC uSeg attribute (not support nesting).

apic:
tenants:
- name: NWKT-T1
application_profiles:
- name: ANP1
useg_endpoint_groups:
- name: Ubuntu-SRV
useg_attributes:
match_type: any
vm_attributes:
- block: 0
value: ubuntu
type: vm-name
operator: startsWith
- name: Win10-EPG
useg_attributes:
match_type: any
vm_attributes:
- block: 0
value: Win
type: vm-name
operator: startsWith
locals {
model = yamldecode(file("${path.module}/../../custom_case_data/useg.yaml"))
useg_epg_list = flatten([
for tenant in local.model.apic.tenants : [
for ap in tenant.application_profiles : [
for epg in ap.useg_endpoint_groups : [
for atb in epg.useg_attributes.vm_attributes :
{
tenant                = tenant.name
application_profile   = ap.name
useg_endpoint_group   = epg.name
useg_attributes_match = epg.useg_attributes.match_type
vm_attributes         = atb
}
]
]
]
])
}
resource "aci_rest_managed" "fvCrtrn" {
for_each   = { for blk in local.useg_epg_list : "blk_${blk.tenant}${blk.application_profile}${blk.useg_endpoint_group}${blk.useg_attributes_match}${blk.vm_attributes.block}" => blk }
class_name = "fvCrtrn"
dn         = "uni/tn-${each.value.tenant}/ap-${each.value.application_profile}/epg-${each.value.useg_endpoint_group}/crtrn"
content = {
match = each.value.useg_attributes_match
name  = "default"
prec  = "0"
scope = "scope-bd"
}
}
resource "aci_rest_managed" "fvVmAttr" {
for_each   = { for blk in local.useg_epg_list : "blk_${blk.tenant}${blk.application_profile}${blk.useg_endpoint_group}${blk.useg_attributes_match}${blk.vm_attributes.block}" => blk }
class_name = "fvVmAttr"
dn         = "${aci_rest_managed.fvCrtrn[each.key].dn}/vmattr-${each.value.vm_attributes.block}"
content = {
operator = each.value.vm_attributes.operator
type     = each.value.vm_attributes.type
value    = each.value.vm_attributes.value
name     = each.value.vm_attributes.block
}
}

VmAttr is much needed. Possibly could be supported by limiting the amount of tags so don't have to account for unlimited nesting? I don't think anyone uses huge amounts of nest so it could be limited to a certain number

Yeah, I'm also thinking this too. Thank you for your suggestions and the sample code.


Need colour theme (override/config) because unusable per default on some colour themes due to contrast issues

I'm using the theme "Outrun Dark" system-wide (set by stylix in NixOS), also in kitty terminal. Starting tiron in such terminal gives me cells with white background and white and/or light yellow text, i.e. unusable.
I guess solving this would need themability which probably is a ratatui topic, but the config would need to be passed to ratatui by tiron I guess?
Possibly for a start (quick fix) , it might suffice though to choose a colour index per default that is less likely to result in poor contrast? (Even the contrast in the screenshot in this repo is problematic, so it might be straight forward?)
EDIT: I noticed that the normal cell colour defaults are hard-coded deeper in the code, so this will remain an issue anyway. So  it appears colours would have to be declared using a pre-defined palette to solve this.

Oh wait, this is just a mini demo, the "real" spreasheet is sheetsui?
Closing...

Hi @ppenguin , sheetsui is a beautiful project but indeed different from Tironcalc.
We will eventually integrate TironCalc into the main IronCalc repo but a lot of things need to happen before that, including cleanup, testing,...
I will reopen this as it is very good feedback.


bitrise-step-loco 0.0.5

New Pull Request Checklist
Please mark the points which you did / accept.

[x] I will not move an already shared step version's tag to another commit
[x] I read the Step Development Guideline
[x] I have a test for my Step, which can be run with bitrise run test (in the step's repository)
[x] I did run bitrise run audit-this-step (in the step's repository - note, if you don't have this workflow in your bitrise.yml, you can copy it from the step template.)
[x] I read and accept the Abandoned Step policy

Includes changes requested in #2195


Roll Flutter Engine from 1d154ff93a87 to a67a047d4667 (2 revisions)

https://github.com/flutter/engine/compare/1d154ff93a87...a67a047d4667
2024-05-25<EMAIL_ADDRESS>Roll Dart SDK from 641d61332238 to b759e9f83ff9 (1 revision) (flutter/engine#53032)
2024-05-25<EMAIL_ADDRESS>Roll Skia from 7eb8515603c1 to a783c0c8df89 (1 revision) (flutter/engine#53033)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jonahwilliams@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


about searching accuracy

When I'm typing a keyword from the title of an item, it should be more convenient if the plugin provides the most accurate item at the top. Like:

The item I chose (and the following PDF) should be placed at the top, as they are the only 2 items in my library with the search word "misperc" in the title.
This is a very useful plugin for me and thanks a lot for your work.

Hi @ycbrd
Thank you very much for raising this issue, I will look into it as soon as I can
Related: https://github.com/vanakat/zotero-bridge/issues/5

I would like to provide a simple fix for this issue.
step 1. goto .obsidian\plugins\zotero-bridge\ you would see a file named main.js, right? open it.
step 2. find quicksearch-everything inside this file.
step 3. replace it with quicksearch-titleCreatorYear
step 4. save, close and restart Obsidian
After these steps, your search accuracy would be increase, however, limited in  title, creator and year fields
If you have solid javascript background, see here to improve this plugin.


add azure category

Merging this myself because it has changes to package.lock.json and I want to avoid conflicts