Support updating npm

I'm using javascript-node:12-buster and updating NPM doesn't work as I'd expect.
$ npm -v
6.14.6
$ which npm
/usr/local/bin/npm
$ npm i -g npm
/usr/local/share/npm-global/bin/npm -> /usr/local/share/npm-global/lib/node_modules/npm/bin/npm-cli.js
/usr/local/share/npm-global/bin/npx -> /usr/local/share/npm-global/lib/node_modules/npm/bin/npx-cli.js
+<EMAIL_ADDRESS>added 434 packages from 885 contributors in 10.338s
$ npm -v
6.14.6
$ /usr/local/share/npm-global/bin/npm -v
6.14.8

Hmm sounds like the PATH has npm-global too late. Will take a look.

Should be resolved in the next release!

FYI only, the new solution installs a new npm but leaves the old one in place too. Since the new one comes earlier in PATH, new terminal sessions do pick it up, but existing terminal sessions continue to reference the old one:
$ npm -v
6.14.6
$ which npm
/usr/local/bin/npm
$ npm i -g npm
/usr/local/share/npm-global/bin/npm -> /usr/local/share/npm-global/lib/node_modules/npm/bin/npm-cli.js
/usr/local/share/npm-global/bin/npx -> /usr/local/share/npm-global/lib/node_modules/npm/bin/npx-cli.js
+<EMAIL_ADDRESS>added 434 packages from 885 contributors in 10.338s
$ npm -v
6.14.6
$ /usr/local/share/npm-global/bin/npm -v
6.14.8
$ which npm
/usr/local/share/npm-global/bin/npm

This could confuse users, obviously, since which is "lying".
Works fine on terminal restart, so I'm good with this, just wanted to note the odd behaviour. Thanks!


Replace deprecated shortid package with nanoid

shortid is deprecated. Should replace with nanoid

what about useId? https://react.dev/reference/react/useId


Missing Modules for BentoGrid Implementation

Issue: Missing Modules for BentoGrid Implementation
Description:
I am trying to implement the BentoGrid component, but I am encountering issues with missing dependencies and modules. The required modules for BentoGrid, such as icons, utility functions, and UI components, are not installed or are improperly configured.
Steps to Reproduce:

Clone the repository or open the project.
Try to use the BentoGrid or BentoCard component in your code.
Observe the errors related to missing modules (e.g., @radix-ui/react-icons, @/components/ui/button, cn, etc.).

Expected Behavior:
All the necessary modules should be listed and installed correctly. There should be no errors related to missing dependencies or modules when importing BentoGrid and BentoCard components.
Error Details:

Missing modules such as @radix-ui/react-icons, @/components/ui/button, etc.
Error messages like "Module not found" or "Cannot resolve" when importing components.

Required Modules:

@radix-ui/react-icons – For icons like ArrowRightIcon.
@/components/ui/button – For the Button component used in BentoCard.
@/lib/utils – For utility functions like cn.
@/components/magicui/bento-grid – For the BentoGrid and BentoCard components.
Any additional dependencies required for styling (e.g., TailwindCSS, etc.).

Steps to Resolve:

Install the missing dependencies using npm or yarn.

Example: npm install @radix-ui/react-icons

Ensure all components are correctly exported and imported.
Verify that utility functions like cn are correctly defined and available.
Provide clear documentation on the installation and usage of BentoGrid and BentoCard.

When you clone the repo, you need to run the pnpm install or npm install command to install all the dependencies. Then try running the component, and it should work. For @/components/ui/button it should be coming from the shadcn install.


Child selectors

I just started playing with SASS this week and didn't find anything about child selectors in the documentation.
Something like the following appears to work fine:
.copy {
    > {
        p {
            margin: 0;
            text-indent: 1.5em;
        }
    }
}

Are there any reasons (e.g. complex use cases) not to use this? Otherwise it would be nice if it was
a) documented and
b) if the compressed style would strip whitespaces surrounding '>'

Child selectors are a feature of CSS. The documentation says that Sass supports everything in CSS3; I don't think it's necessary to specifically call out all the individual features.
I'll leave this issue open for the compressed-mode request.

I'm not referring to CSS syntax but SASS 'CSS extensions'. The latter simply mentions 'nested rules' as a feature, but my SCSS example does not start with a nested rule( set).
BTW, if it is possible to break up selectors within rule sets by combinator and nest the parts, I would expect this
foo {
    /* I'm surrounded  by a decendant combinator */ {
        bar {
            /* declarations */
        }
    }
}

to work, too, but the compiler disagrees ;-)
Well, YMMD. Thanks for the confirmation and the compressed-mode commit.
(Speaking about the documentation, all the (compiled) 'font' shorthand examples are invalid.)


Add new CBOR and COSE libraries written entirely in Kotlin.

This is needed to get the libraries working with Kotlin Multiplatform.
This PR also converts all the code in identity and identity-mdoc to use this new code instead of cbor-java and the various support routines in the Util class. Code in identity-android and the apps will be converted in a future PR.
Also create wrappers for all cryptographic routines needed, including hashing, hkdf, encryption/decryption, EC keys, and certificates. This is currently using BC but can be easily ported to other cryptographic libraries when not running on a JVM, for example iOS.
Test: New unit tests and all unit tests pass.
Test: Manually tested (appholder, appverifier, samples/preconsent-mdl, samples/age-verifier-mdl, samples/simple-verifier, wallet, secure-area-test-app)

Still needs an update for the wallet module, will do that after #480 and #481 lands.


Calendar pop-up closes on month selection

Describe the bug
Calendar pop-up closes on month mouseover. Similar or a regression of #34.I'm able to reproduce the original reported behavior using version 0.10.0 with Semantic 0.83.0. Reverting back 0.81.1 resolves this behavior so something between these two versions causes the calendar to close on hover
To Reproduce
Steps to reproduce the behavior:

https://react-e1y1ed.stackblitz.io

Expected behavior
Mousing over the calendar should not close randomly, but close on selection
Dependencies versions
Provide version numbers of following packages:
"semantic-ui-calendar-react": "^0.10.0",
"semantic-ui-css": "^2.4.1",
"semantic-ui-react": "0.83.0",

Would be great, if it could be fixed, but officially version 0.83.0 is not supported (semantic-ui-react@<=0.80.2).

I missed that dependency on version, thanks @eCorke

What about a semantic-ui-react version <=0.80.2, to be honest, I just forgot to delete this restriction. There was some other issues with semantic-ui-react greater than 0.80.2 but they was solved in later versions.
@remingtonlang I can't open your example (the page doesn't load for some reason). But I reproduced the bug. Seems like it starts from<EMAIL_ADDRESS>

semantic-ui-react v0.84.0 was released a few days ago. It works with that version.


Colliding modules

Hi,
I have 4 modules that visually collides with this one:

ICE UI makes the top row menu icons on the left (Basic Controls and Select Tokens) differ form the rest of the Icons.
Custom Hotbar still places the hotbar to the left and the additional hotbars are still sharp edge squares.
Monk's Token Bar its action panel is covered by the hotbar since both are now in the lower middle of the screen. (my temp fix is to hide the hotbar)
Dice Tray is all whited out, the dice icons show when you mouse hover but the math symbols do no appear.

I don't know how much sense it would make to add support for IceUI since it's another UI mod, but I will look at it nonetheless.
I do have support for monks token bar but I have yet to have it's default position moved since I moved the hotbar. It does have a reposition handle (the brighter section on the left) that lets you drag it around.
I will look at getting support for the other two modules! Thanks for the feedback!

I have pushed another update that adds support for Dice Tray and Custom Hotbar. Monks Tokenbar is compatible with my UI mod. If for some reason it is under the hotbar, there is a reset position button in the settings for Monks Tokenbar that will bring it to the right side of the Hotbar. Also it can be dragged around like I mentioned in the first reply. I don't see a reason to add support for the Ice UI since it is another UI mod and you would usually only run one of those at a time.

Thank you! If I see other issues, I'll let you know.


js-on-fhir Version 1.0.0

There is the Beta of js-on-fhir Version 1.0.0. This version has some breaking changes that need to be adressed in the app.
Update the app, so the new version of js-on-fhir will work fine.

Breaking changes (as of 05.12.2022):

Different methods have now typed return values. In TypeScript projects, this may lead to errors (that are usually easy to fix, though).

The search() method now checks the resourceType parameter for validity (if supported by the server, according to the conformance statement). This means that the common practice for passing a whole search string to the method as resourceType does no longer work. Use the params parameter for search params instead.

For fetching a resource with a known id, use the new getResource() method instead. The benefit of this is, that the search() method return value can be typed as a Bundle, and the getResource() return value can be typed as a Resource.

The getPatient() method is deprecated and has been renamed to getUserId(), which is more descriptive (since it returns only the ID and not the whole resource, and can also return the Practitioner ID when logged in as Health Professional or Researcher).

The (undocumented) generateRandomState(length) method is no longer available. If you used it to create a prefilled registering link, you can instead use the authenticate() method and pass the prefilled fields as key/value pair.

Version 2.0.0 of @i4mi/fhir_r4 is used, which has incompabilities to previous versions. You may have to update your project to Version 2.0.0 of @i4mi/fhir_r4 when using TypeScript.

PKCE Code Challenge is used per default for the auth, which may cause problems if your server does not support PKCE. You can disable this behaviour by setting disablePKCE the option objects of the constructor to true (see chapter 1.2.3)


Is there a way to trigger whatsapp application open in mobile phone?

Instead of opening whatsapp application directly in mobile phone, it opens a whatsapp web by calling Router.push('https://wa.me/phone'). The behaviour is not the same as my previous project using react-router-dom. It opens whatsapp directly without leaving the original site. Thanks in advance.

This is unrelated to Next.js.


convert midi file to csv

I want to evaluate midi files with your repo, but the csv format in testdata/symbolic confuses me. How should I convert midi (or remi/cp) into the required csv format? Is there a script to do so?

Hi, if you happen to have your pieces in the REMI format defined by our Jazz Transformer, then you can use the event_to_encodings() funtion in https://github.com/slSeanWU/jazz_transformer/blob/master/src/convert_to_remi.py to produce the required csv.
Unfortunately, since our original dataset (WJazzD) is not in MIDI format, we didn't write/provide the utilities which work with raw MIDIs. But you can try this: https://github.com/YatingMusic/compound-word-transformer/blob/main/dataset/Dataset.md to convert your MIDIs into REMI.
Hope this helps!

I will try that. Thanks a lot!

I will try that. Thanks a lot!

我想问一下您生成了响应的csv文件了吗？您可以教我一下怎么做到吗？怎么从midi转到csv？
期待您的回复。

@wzk1015 您好，请教一下怎么样才能将midi转为这里需要的csv呢？非常感谢

Hi, if you happen to have your pieces in the REMI format defined by our Jazz Transformer, then you can use the event_to_encodings() funtion in https://github.com/slSeanWU/jazz_transformer/blob/master/src/convert_to_remi.py to produce the required csv.
Unfortunately, since our original dataset (WJazzD) is not in MIDI format, we didn't write/provide the utilities which work with raw MIDIs. But you can try this: https://github.com/YatingMusic/compound-word-transformer/blob/main/dataset/Dataset.md to convert your MIDIs into REMI.
Hope this helps!

Hi, if you happen to have your pieces in the REMI format defined by our Jazz Transformer, then you can use the event_to_encodings() funtion in https://github.com/slSeanWU/jazz_transformer/blob/master/src/convert_to_remi.py to produce the required csv.
Unfortunately, since our original dataset (WJazzD) is not in MIDI format, we didn't write/provide the utilities which work with raw MIDIs. But you can try this: https://github.com/YatingMusic/compound-word-transformer/blob/main/dataset/Dataset.md to convert your MIDIs into REMI.
Hope this helps!

@wzk1015 您好，请教一下怎么样才能将midi转为这里需要的csv呢？非常感谢

Hi, if you happen to have your pieces in the REMI format defined by our Jazz Transformer, then you can use the event_to_encodings() funtion in https://github.com/slSeanWU/jazz_transformer/blob/master/src/convert_to_remi.py to produce the required csv.
Unfortunately, since our original dataset (WJazzD) is not in MIDI format, we didn't write/provide the utilities which work with raw MIDIs. But you can try this: https://github.com/YatingMusic/compound-word-transformer/blob/main/dataset/Dataset.md to convert your MIDIs into REMI.
Hope this helps!

@wzk1015 我已经转换得到了remi的pkl,请问下一步需要怎么做呢？再次感谢

@wzk1015 我已经转换得到了remi的pkl,请问下一步需要怎么做呢？event_to_encodings()怎么根据pkl选择传入参数呢？再次感谢！

同问，得到了remi的pkl，下一步怎么借用event_to_encodings()方法进行生成csv


Add flush method to the DDFileLogger

New Pull Request Checklist

[x] I have read and understood the CONTRIBUTING guide

[x] I have read the Documentation

[x] I have searched for a similar pull request in the project and found none

[x] I have updated this branch with the latest master to avoid conflicts (via merge from master or rebase)

[ ] I have added the required tests to prove the fix/feature I am adding

[x] I have updated the documentation (if necessary)

[x] I have run the tests and they pass

[x] I have run the lint and it passes (pod lib lint)

This merge request fixes / refers to the following issues:

Writes all in-memory data to the file on a DDLog.flushLog call
Allows developers flushing in-memory data to the file.

Pull Request Description

Adds flush method to the DDFileLogger

Codecov Report

Merging #928 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #928      +/-   ##
==========================================
- Coverage    22.3%   22.28%   -0.02%
==========================================
  Files          17       17
  Lines        2627     2629       +2
==========================================
  Hits          586      586
- Misses       2041     2043       +2

Impacted Files
Coverage Δ

Classes/DDFileLogger.h
0% <ø> (ø)
:arrow_up:

Classes/DDFileLogger.m
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Are GpioPin type state generics actually helpful?

We have a lot of type information stored with our GPIO types, and I'm wondering if it's valuable to have or not. The traditional use case for typestates is to ensure that specific pins that have a specific purpose are only used for that purpose and are in the correct state for that purpose.
For esp's we are gifted with the luxury of the IO mux, where any1 pin can be used for any purpose, so the first case is covered. I took a look at our peripheral driver initialization operations, none of them take a GpioPin<TYPE> directly, instead we take the raw pin and configure it in the driver. (I would also like to note at this point, I love this about esp-hal, I think it's one of the nicest features that drivers take care of that!)  This covers the second case from above. This begs the question, are the type state generics actually helpful?
I think at this point I would have to say no, but I might be missing something. I would love to hear some alternative points.
If we did choose to remove it, it would massively simplify the GPIO module. There would be just one parameter on GpioPin which would be the number, and AnyPin would then be truly generic free.
1: There are some limitations around USB pins.

I do not think the generics are especially useful (and get in the way more than anything). I've been of the opinion that our GPIO driver needs a full redesign for quite some time now, so I'm in favour of eliminating as much of this as possible.

After thinking about it for some time I'd say no.

I've been of the opinion that our GPIO driver needs a full redesign for quite some time now, so I'm in favour of eliminating as much of this as possible.

Maybe we can avoid doing a rewrite and get closer to what you want with a refactoring resulting from this? I guess this will be quite a big refactoring task and improving things incrementally is probably a good way forward. Did you outline the ideas somewhere? Just to make sure things don't go into opposite directions

but I might be missing something

I think you're forgetting about e-hal drivers. Some LED or button driver will want a gpio pin specifically in the input or output state.

I think you're forgetting about e-hal drivers. Some LED or button driver will want a gpio pin specifically in the input or output state.

Most of our pins implement both traits anyway. There are only a handful of pins that cannot be used as inputs and we just wouldn't implement the trait on those pins. The typestate information isn't really that relevant to what traits they implement.

Ah, I see what you mean (sorry it's late here), the pins still need to be put into input or output mode. I guess one level of typestate could be okay. Or we could go down the path of embassy, and esp-idf-hal where the mode is a struct which takes a pin i.e Input::new(io.gpio0).
My main reason for opening this issue is that we have types like Gpio0<Input<PullDown>>, not unwieldy, but does PullDown actually help in anyway or is it just noise?

I think having state for Input, Output and OpenDrainOutput is something we'll need.  I see no real use in the second level of typestate - I guess having separate structs or a state on just one struct should be equivalent but given there is a "trend" to have separate structs we might want that 🤔 but no hard-opinion on that from my side. Introducing separate structs might be a more drastic change but if we want to have it it's probably better to do that in one (bigger) change

I've run into this and would agree that the type states get in the way when using peripherals at least.
For example, I've been trying to create an abstraction over the mcpwm peripheral(s) which should take 12 output-capable pins and pass them into Operator::with_pins.
This is fine and dandy in normal non-embassy land because the abstraction could be made generic over the pins  (despite that being a big mess of repeated generics), however with embassy it just plainly isn't possible because tasks can't be generic so I would have to spell out the specific pins in the task parameter defeating the point.
More concretely this problem arises because Operator::with_pins has the bound impl Peripheral<P = PinA> where PinA: OutputPin but OutputPin is for AnyPin like this: impl<MODE, TYPE> OutputPin for AnyPin<MODE, TYPE> where MODE: OutputMode, TYPE: IsOutputPin but AnyPin has TYPE = () which naturally doesn't implement IsOutputPin.
This in turn means that my abstraction either has to chose between InputOutputPinType or InputOutputAnalogPinType because that's the two types that implement IsOutputPin.
It's not really possible to work around this either with TAIT (as far as I understand) because I can't resolve the TYPE to concrete types in the abstraction module without limiting which pins goes to which pwm output.


Add dictionary of external data sources to facilitate easy updating and centralized record keeping

This may become another branch of the integrated system

Implemented.


Add onpagehide support data

Please add onpagehide attribute support data

This is already covered by https://caniuse.com/#feat=page-transition-events

^ and there's also additionally data from MDN now: https://caniuse.com/mdn-api_window_pagehide_event


Streamlit app

The logic and tests were added. Dockerfile and makefile were constructed.

All tests passed. Merge is approved.


graph release

Coverage increased (+0.1%) to 89.044% when pulling e6ca7684aa4aba5ad72ce48d09ac5824db71be57 on graph-release into e61cddf159c8c8434132ea5ad20fc10d68129f61 on preprod.


Refactor AgentHeaderDescriptor

Replace AgentHeaderDescriptor with AgentHeader, a class with only static methods
In GapicClientTrait, cache only the gapic version loaded from file
Remove AgentHeaderMiddleware and use FixedHeaderMiddleware in its place

Looks like there's a cs error, feel free to merge once it's fixed

Codecov Report

Merging #206 into master will increase coverage by 0.66%.
The diff coverage is 96.29%.

@@            Coverage Diff             @@
##           master     #206      +/-   ##
==========================================
+ Coverage   84.14%   84.81%   +0.66%
==========================================
  Files          63       62       -1
  Lines        2826     2838      +12
==========================================
+ Hits         2378     2407      +29
+ Misses        448      431      -17

Impacted Files
Coverage Δ

src/ApiCore/AgentHeader.php
100% <100%> (ø)

src/ApiCore/Middleware/FixedHeaderMiddleware.php
100% <100%> (+100%)
:arrow_up:

src/ApiCore/GapicClientTrait.php
88.88% <100%> (-0.44%)
:arrow_down:

src/ApiCore/Version.php
66.66% <75%> (+23.8%)
:arrow_up:

src/ApiCore/Serializer.php
91.89% <0%> (-1.05%)
:arrow_down:

src/ApiCore/ApiException.php
90% <0%> (+15%)
:arrow_up:

Continue to review full report at Codecov.

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


Singleton Controller should wait for Cache Sync

Version

Karpenter Version: v0.0.0

Kubernetes Version: v1.0.0
Expected Behavior
Singleton controllers should wait for the controller-runtime caches to sync before proceeding with running due to leader election. Ideally, the RBAC permissions should be a condition for startup and we shouldn't get into a half-state where some controllers are running since they aren't waiting on permissions and others aren't.
Actual Behavior
Singleton controllers are proceeding with their reconcile even if they don't have RBAC permissions while controllers that have Watch on them haven't started/are failing.
Steps to Reproduce the Problem

Remove an RBAC permission that Karpenter requires to run (NodeTemplate is a good example)
Install Karpenter

Observe that Karpenter will fail after a few seconds due to cache sync timeouts but some of the singleton controllers are already starting and running.
Resource Specs and Logs
2023-03-10T20:27:22.604Z        DEBUG   Successfully created the logger.
2023-03-10T20:27:22.604Z        DEBUG   Logging level set to: debug
{"level":"info","ts":1678480042.6075704,"logger":"fallback","caller":"injection/injection.go:63","msg":"Starting informers..."}
2023-03-10T20:27:22.707Z        DEBUG   controller      waiting for configmaps  {"commit": "ffc7705-dirty"}
2023-03-10T20:27:23.218Z        DEBUG   controller      waiting for configmaps  {"commit": "ffc7705-dirty"}
2023-03-10T20:27:23.718Z        DEBUG   controller      waiting for configmaps  {"commit": "ffc7705-dirty"}
2023-03-10T20:27:24.219Z        DEBUG   controller      waiting for configmaps  {"commit": "ffc7705-dirty"}
2023-03-10T20:27:24.719Z        DEBUG   controller      waiting for configmaps  {"commit": "ffc7705-dirty"}
2023-03-10T20:27:25.400Z        DEBUG   controller.aws  discovered region       {"commit": "ffc7705-dirty", "region": "us-west-2"}
2023-03-10T20:27:25.400Z        DEBUG   controller.aws  discovered cluster endpoint     {"commit": "ffc7705-dirty", "cluster-endpoint": "https://2B3A0347E5BF8D9935288F4311843065.gr7.us-west-2.eks.amazonaws.com"}
2023-03-10T20:27:25.405Z        DEBUG   controller.aws  discovered kube dns     {"commit": "ffc7705-dirty", "kube-dns-ip": "<IP_ADDRESS>"}
2023-03-10T20:27:25.406Z        DEBUG   controller.aws  discovered version      {"commit": "ffc7705-dirty", "version": "v0.27.0-16-gffc77057"}
2023/03/10 20:27:25 Registering 2 clients
2023/03/10 20:27:25 Registering 2 informer factories
2023/03/10 20:27:25 Registering 3 informers
2023/03/10 20:27:25 Registering 6 controllers
2023-03-10T20:27:25.407Z        INFO    controller      Starting server {"commit": "ffc7705-dirty", "path": "/metrics", "kind": "metrics", "addr": "[::]:8080"}
2023-03-10T20:27:25.407Z        INFO    controller      Starting server {"commit": "ffc7705-dirty", "kind": "health probe", "addr": "[::]:8081"}
I0310 20:27:25.508308       1 leaderelection.go:248] attempting to acquire leader lease karpenter/karpenter-leader-election...
2023-03-10T20:27:25.527Z        INFO    controller      Starting informers...   {"commit": "ffc7705-dirty"}
2023-03-10T20:27:25.850Z        INFO    controller.aws.pricing  updated spot pricing with instance types and offerings  {"commit": "ffc7705-dirty", "instance-type-count": 631, "offering-count": 2162}
2023-03-10T20:27:27.571Z        INFO    controller.aws.pricing  updated on-demand pricing       {"commit": "ffc7705-dirty", "instance-type-count": 625}
I0310 20:29:31.656942       1 leaderelection.go:258] successfully acquired lease karpenter/karpenter-leader-election
2023-03-10T20:29:31.657Z        INFO    controller.provisioner  starting controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:29:31.657Z        INFO    controller.deprovisioning       starting controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:29:31.657Z        INFO    controller.metric_scraper       starting controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:29:31.657Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "daemonset", "controllerGroup": "apps", "controllerKind": "DaemonSet", "source": "kind source: *v1.DaemonSet"}
2023-03-10T20:29:31.657Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "daemonset", "controllerGroup": "apps", "controllerKind": "DaemonSet"}
2023-03-10T20:29:31.657Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod", "source": "kind source: *v1.Pod"}
2023-03-10T20:29:31.657Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod", "source": "kind source: *v1.Pod"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1alpha5.Provisioner"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Pod"}
2023-03-10T20:29:31.658Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1alpha5.Provisioner"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod", "source": "kind source: *v1.Pod"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "termination", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "termination", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1alpha5.Provisioner"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1.Node"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "source": "kind source: *v1alpha5.Provisioner"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate", "source": "kind source: *v1alpha1.AWSNodeTemplate"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate"}
2023-03-10T20:29:31.659Z        INFO    controller      Starting EventSource    {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "source": "kind source: *v1.Node"}
2023-03-10T20:29:31.660Z        INFO    controller      Starting Controller     {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:29:31.660Z        INFO    controller.interruption starting controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:29:31.660Z        DEBUG   controller.interruption watching interruption queue     {"commit": "ffc7705-dirty", "queue": "joinnis-karpenter-demo"}
2023-03-10T20:29:31.660Z        DEBUG   controller.aws  hydrating the launch template cache     {"commit": "ffc7705-dirty", "tag-key": "karpenter.k8s.aws/cluster", "tag-value": "joinnis-karpenter-demo"}
W0310 20:29:31.662516       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:29:31.662541       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
2023-03-10T20:29:31.729Z        DEBUG   controller.aws  finished hydrating the launch template cache    {"commit": "ffc7705-dirty", "tag-key": "karpenter.k8s.aws/cluster", "tag-value": "joinnis-karpenter-demo", "item-count": 1}
2023-03-10T20:29:31.758Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod", "worker count": 10}
2023-03-10T20:29:31.758Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod", "worker count": 10}
2023-03-10T20:29:31.775Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod", "worker count": 1}
2023-03-10T20:29:32.846Z        DEBUG   controller.deprovisioning       discovered EC2 instance types   {"commit": "ffc7705-dirty", "instance-type-count": 621}
W0310 20:29:32.847295       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:29:32.847319       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
2023-03-10T20:29:33.024Z        DEBUG   controller.deprovisioning       discovered subnets      {"commit": "ffc7705-dirty", "subnets": ["subnet-0a89ab2e50dfe40d6 (us-west-2b)", "subnet-007aafdece10d1105 (us-west-2b)", "subnet-01ac1560ed61b3ea5 (us-west-2d)", "subnet-0d2e48c60b6f70689 (us-west-2d)", "subnet-065d2bd943d9549a6 (us-west-2a)", "subnet-004e4cd40a2953909 (us-west-2a)"]}
2023-03-10T20:29:33.204Z        DEBUG   controller.deprovisioning       discovered EC2 instance types zonal offerings for subnets       {"commit": "ffc7705-dirty", "subnet-selector": "{\"karpenter.sh/discovery\":\"joinnis-karpenter-demo\"}"}
2023-03-10T20:29:33.418Z        INFO    controller.provisioner  found provisionable pod(s)      {"commit": "ffc7705-dirty", "pods": 19}
2023-03-10T20:29:33.418Z        INFO    controller.provisioner  computed new node(s) to fit pod(s)      {"commit": "ffc7705-dirty", "nodes": 3, "pods": 19}
2023-03-10T20:29:33.418Z        INFO    controller.provisioner  launching machine with 3 pods requesting {"cpu":"3125m","pods":"5"} from types r5.24xlarge, r6id.2xlarge, m4.4xlarge, c4.4xlarge, c6in.xlarge and 285 other(s)  {"commit": "ffc7705-dirty", "provisioner": "default"}
2023-03-10T20:29:33.433Z        INFO    controller.provisioner  launching machine with 8 pods requesting {"cpu":"8125m","pods":"10"} from types r5.24xlarge, m4.4xlarge, c4.4xlarge, r6a.metal, r5ad.24xlarge and 207 other(s)  {"commit": "ffc7705-dirty", "provisioner": "default"}
2023-03-10T20:29:33.451Z        INFO    controller.provisioner  launching machine with 8 pods requesting {"cpu":"8125m","pods":"10"} from types r5.24xlarge, m4.4xlarge, c4.4xlarge, r6a.metal, r5ad.24xlarge and 207 other(s)  {"commit": "ffc7705-dirty", "provisioner": "default"}
2023-03-10T20:29:33.634Z        DEBUG   controller.provisioner.cloudprovider    discovered security groups      {"commit": "ffc7705-dirty", "provisioner": "default", "security-groups": ["sg-01dd189962807c84d", "sg-09222dc5dd763565e"]}
2023-03-10T20:29:33.636Z        DEBUG   controller.provisioner.cloudprovider    discovered kubernetes version   {"commit": "ffc7705-dirty", "provisioner": "default", "kubernetes-version": "1.23"}
2023-03-10T20:29:33.677Z        DEBUG   controller.provisioner.cloudprovider    discovered new ami      {"commit": "ffc7705-dirty", "provisioner": "default", "ami": "ami-0f5fb1060cc8f7202", "query": "/aws/service/eks/optimized-ami/1.23/amazon-linux-2/recommended/image_id"}
W0310 20:29:34.699495       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:29:34.699518       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
2023-03-10T20:29:36.154Z        INFO    controller.provisioner.cloudprovider    launched new instance   {"commit": "ffc7705-dirty", "provisioner": "default", "id": "i-099ff9f1117d9d5f8", "hostname": "ip-192-168-134-188.us-west-2.compute.internal", "instance-type": "c6a.xlarge", "zone": "us-west-2a", "capacity-type": "on-demand"}
2023-03-10T20:29:38.185Z        INFO    controller.provisioner.cloudprovider    launched new instance   {"commit": "ffc7705-dirty", "provisioner": "default", "id": "i-04d89097d58fe57b7", "hostname": "ip-192-168-170-69.us-west-2.compute.internal", "instance-type": "c6a.4xlarge", "zone": "us-west-2d", "capacity-type": "on-demand"}
2023-03-10T20:29:38.185Z        INFO    controller.provisioner.cloudprovider    launched new instance   {"commit": "ffc7705-dirty", "provisioner": "default", "id": "i-0f4079a9321adc6e9", "hostname": "ip-192-168-160-253.us-west-2.compute.internal", "instance-type": "c6a.4xlarge", "zone": "us-west-2d", "capacity-type": "on-demand"}
W0310 20:29:39.979086       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:29:39.979111       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
W0310 20:29:49.583808       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:29:49.583833       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
W0310 20:30:02.692771       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:30:02.692795       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
W0310 20:30:36.857529       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:30:36.857555       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
W0310 20:31:29.921641       1 reflector.go:424] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
E0310 20:31:29.921668       1 reflector.go:140] k8s.io/client-go@v0.25.4/tools/cache/reflector.go:169: Failed to watch *v1alpha1.AWSNodeTemplate: failed to list *v1alpha1.AWSNodeTemplate: awsnodetemplates.karpenter.k8s.aws is forbidden: User "system:serviceaccount:karpenter:karpenter" cannot list resource "awsnodetemplates" in API group "karpenter.k8s.aws" at the cluster scope
2023-03-10T20:31:31.657Z        ERROR   controller      Could not wait for Cache to sync        {"commit": "ffc7705-dirty", "controller": "daemonset", "controllerGroup": "apps", "controllerKind": "DaemonSet", "error": "failed to wait for daemonset caches to sync: timed out waiting for cache to be synced"}
2023-03-10T20:31:31.657Z        INFO    controller      Stopping and waiting for non leader election runnables  {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.657Z        INFO    controller      Stopping and waiting for leader election runnables      {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.657Z        INFO    controller.metric_scraper       stopping controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.658Z        INFO    controller.deprovisioning       stopping controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.658Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:31:31.658Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:31:31.658Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:31:31.658Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "worker count": 10}
2023-03-10T20:31:31.658Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:31:31.658Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-03-10T20:31:31.658Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.669Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "worker count": 10}
2023-03-10T20:31:31.669Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:31:31.669Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate", "worker count": 10}
2023-03-10T20:31:31.669Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate"}
2023-03-10T20:31:31.669Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-03-10T20:31:31.669Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.671Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-67-163.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-67-163.us-west-2.compute.internal", "reconcileID": "ddf15083-6643-4c3c-962d-02d4c950c942", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.673Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-190-108.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-190-108.us-west-2.compute.internal", "reconcileID": "5eb12c0f-3215-4d8b-aea4-813da695753b", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.675Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-160-210.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-160-210.us-west-2.compute.internal", "reconcileID": "db1126f6-7bc0-413b-a386-bb91cb9ecbe1", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.677Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-179-4.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-179-4.us-west-2.compute.internal", "reconcileID": "4d7e926d-b69a-4355-8a01-12e2f470508f", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.680Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-14-247.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-14-247.us-west-2.compute.internal", "reconcileID": "be90286a-2b94-4210-bf30-026bd4c84651", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.684Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-164-130.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-164-130.us-west-2.compute.internal", "reconcileID": "460286f9-aeb9-4334-9d84-b768a1b3991b", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.688Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-176-185.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-176-185.us-west-2.compute.internal", "reconcileID": "2fd303c3-6484-4198-aba7-16b53cdae6d3", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.695Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "worker count": 1}
2023-03-10T20:31:31.695Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:31:31.695Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "provisioner_metrics", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:31:31.695Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-03-10T20:31:31.695Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.695Z        INFO    controller      Starting workers        {"commit": "ffc7705-dirty", "controller": "termination", "controllerGroup": "", "controllerKind": "Node", "worker count": 10}
2023-03-10T20:31:31.695Z        INFO    controller      Shutdown signal received, waiting for all workers to finish     {"commit": "ffc7705-dirty", "controller": "termination", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.696Z        INFO    controller.termination  cordoned node   {"commit": "ffc7705-dirty", "node": "ip-192-168-49-107.us-west-2.compute.internal"}
2023-03-10T20:31:31.696Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "termination", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-49-107.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-49-107.us-west-2.compute.internal", "reconcileID": "69c150a9-1e66-429a-9b77-3dc3b3af4798", "error": "cordoning node, client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.697Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "pod_metrics", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:31:31.697Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "pod_state", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:31:31.697Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "provisioner_trigger", "controllerGroup": "", "controllerKind": "Pod"}
2023-03-10T20:31:31.698Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner", "Provisioner": {"name":"default"}, "namespace": "", "name": "default", "reconcileID": "1ae2444c-591b-4618-8116-631bb4cdf3d2", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.716Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "counter", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:31:31.716Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "provisioner_state", "controllerGroup": "karpenter.sh", "controllerKind": "Provisioner"}
2023-03-10T20:31:31.716Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "awsnodetemplate", "controllerGroup": "karpenter.k8s.aws", "controllerKind": "AWSNodeTemplate"}
2023-03-10T20:31:31.718Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-26-120.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-26-120.us-west-2.compute.internal", "reconcileID": "596a8cfa-60e7-4a34-b1a7-f6ce65ebfa67", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.720Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-34-6.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-34-6.us-west-2.compute.internal", "reconcileID": "925ea794-51b9-4c4d-ad35-1f1176afd206", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.723Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-138-197.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-138-197.us-west-2.compute.internal", "reconcileID": "773dab62-ad69-45d8-ad5d-6178ce561768", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.725Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-45-233.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-45-233.us-west-2.compute.internal", "reconcileID": "058ef5a9-acd8-4c64-a07b-d5d8b87998a5", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.727Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-134-188.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-134-188.us-west-2.compute.internal", "reconcileID": "08791d7c-4322-4c12-b9cd-3d92800e8e38", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.738Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-160-253.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-160-253.us-west-2.compute.internal", "reconcileID": "909d27f7-e20b-49e7-9ad0-1236026275b7", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.740Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-167-175.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-167-175.us-west-2.compute.internal", "reconcileID": "0a8cb171-05bb-472b-85f1-2ca01757cd92", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.740Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-49-107.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-49-107.us-west-2.compute.internal", "reconcileID": "9a276159-9c39-4a17-9585-4e6bc9044557", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.740Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "termination", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.740Z        ERROR   controller.interruption getting messages from queue, receiving sqs messages, RequestCanceled: request context canceled
caused by: context canceled     {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.740Z        INFO    controller.interruption stopping controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.740Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-26-120.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-26-120.us-west-2.compute.internal", "reconcileID": "8b0373fd-f86a-4c91-8aa8-a031e64c9365", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.740Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-14-247.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-14-247.us-west-2.compute.internal", "reconcileID": "f59ad77d-ed6e-45c3-9d34-e7f0cfb7e8c3", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.740Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-160-210.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-160-210.us-west-2.compute.internal", "reconcileID": "aeb91fd9-b688-4b6e-820a-37c7752c4dbc", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.740Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-67-163.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-67-163.us-west-2.compute.internal", "reconcileID": "9708015a-b445-4c95-9d22-bff1d66cc6ab", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.740Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-45-233.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-45-233.us-west-2.compute.internal", "reconcileID": "c3e8b449-7365-444f-9d4d-341691de2078", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-167-175.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-167-175.us-west-2.compute.internal", "reconcileID": "229be039-8052-4660-a84d-7b63f0d2d899", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-34-6.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-34-6.us-west-2.compute.internal", "reconcileID": "b35e84a3-6b27-4645-ba6a-d8973176b13b", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-176-185.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-176-185.us-west-2.compute.internal", "reconcileID": "ced4ad63-adf4-45aa-ba1c-6951f6fe5e55", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-164-130.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-164-130.us-west-2.compute.internal", "reconcileID": "7b7a38bf-05a4-40a9-bf1b-4e519f80166b", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-179-4.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-179-4.us-west-2.compute.internal", "reconcileID": "81ab904f-a486-4825-9930-f236a098f7eb", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-190-108.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-190-108.us-west-2.compute.internal", "reconcileID": "ddd28434-0967-4285-8215-b81a18f63e7b", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-138-197.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-138-197.us-west-2.compute.internal", "reconcileID": "1fe3b282-bde2-4333-9801-079d3067e784", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-134-188.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-134-188.us-west-2.compute.internal", "reconcileID": "67a8eaee-8680-47a9-9f46-57178d47482b", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-170-69.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-170-69.us-west-2.compute.internal", "reconcileID": "b55b578b-fa82-45dd-b44b-642e852d982d", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-160-253.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-160-253.us-west-2.compute.internal", "reconcileID": "f50976b9-4e7e-47ae-829b-6b681f626a4b", "error": "Timeout: failed waiting for *v1.PodDisruptionBudget Informer to sync"}
2023-03-10T20:31:31.741Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "inflightchecks", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.747Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.747Z        ERROR   controller      Reconciler error        {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-192-168-170-69.us-west-2.compute.internal"}, "namespace": "", "name": "ip-192-168-170-69.us-west-2.compute.internal", "reconcileID": "a7e002de-fd4d-4730-aae3-2446ee0edb04", "error": "client rate limiter Wait returned an error: context canceled"}
2023-03-10T20:31:31.747Z        INFO    controller      All workers finished    {"commit": "ffc7705-dirty", "controller": "node", "controllerGroup": "", "controllerKind": "Node"}
2023-03-10T20:31:31.894Z        INFO    controller.provisioner  stopping controller     {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.894Z        INFO    controller      Stopping and waiting for caches {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.895Z        INFO    controller      Stopping and waiting for webhooks       {"commit": "ffc7705-dirty"}
2023-03-10T20:31:31.895Z        INFO    controller      Wait completed, proceeding to shutdown the manager      {"commit": "ffc7705-dirty"}
panic: failed to wait for daemonset caches to sync: timed out waiting for cache to be synced

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

The other thing I realize is that if we don't wait for cache sync on these singleton controllers, then we may be working with information in these caches that are not properly up-to-date as expected with controller-runtime.

At first I thought this would be achievable by using the WaitForCacheSynced() function on the reader. But after further inspection, I see that the controller-runtime reader does ad-hoc based registration of the Informers, meaning that it won't register an informer until it needs to in the first Get() call. This means that any controllers that are singleton controllers and are doing polling loops won't hit RBAC issues until they actually do the action of Getting/Listing the thing that they don't have permission to Get/List.
I'm not sure I love the concept of tracking these objects at controller registration time either, since this seems difficult to maintain over time. Realistically, if a user's RBAC is incorrect, I think it makes sense to just restrict the actions that the controller can do based on these limited permissions. This is effectively undefined behavior and not something that should probably be captured more rigorously in startup code.

💡 We could solve this by using the Controller interface directly and initiating it with a GenericEvent through a channel rather than generating our own Runnable and maintaining the controller-runtime logic ourselves

/remove-lifecycle stale


test_gst_io test application not working

Hi,
I am trying to understand how I can send or receive the stream without using web browser using c based code. I checked the openwebrtc test application test_gst_io.c. I build it and try to run. Getting following error:
ERROR:owr_video_renderer.c:314:owr_video_renderer_get_element: assertion failed: (flip)
I enabled the gst debug logs, and found the more detailed reason:
GST_ELEMENT_FACTORY gstelementfactory.c:457:gst_element_factory_make: no such element factory "glvideoflip"!
Following the Video source used in test_gst_io.c
#define CUSTOM_VIDEO_SINK "xvimagesink"
#define CUSTOM_VIDEO_SOURCE "videotestsrc ! capsfilter caps="video/x-raw, width=1280, height=720" ! videoscale"
can someone please help to resolve this issue ?
If I try the same with gst-launch-1.0, its working. I can see the video.
gst-launch-1.0 videotestsrc ! capsfilter caps="video/x-raw, width=1280, height=720" ! videoscale ! xvimagesink
Regards
Manoj

Hi,
I am having the same error message here, did you find a solution?
Regards
Med


fix: cmcd not applying configuration changes

Please add a bug number if there is one.  Otherwise, LGTM.

No issue was created because I found this while working on #5118.


[visualization] Improve HiDPI support

This PR improves HiDPI support of OTNS web interface.

Correctly set PIXI application renderer density.
Use 2x image assets for node shapes.

Before:

After:

I tested the performance impact of this PR on WebGL rendering.
The test simulated 8x8 nodes forming one partition.
Original OTNS:

OTNS with this PR:

So this PR do cause more rendering overhead on GPU. But I think it's fine.


Colors and characters are missing

Have a look at these two screenshots:

vs

It seems the ansicodes and unicode characters of mocha are beeing striped?
Check this gist for reproduction:
https://gist.github.com/enko/31be945ca47b0c481275e76a2b695714
Run docker-compose build and then docker-compose run test_runner alternativly append -f docker-compose_colors.yml to run it without nodejs-dashboard.
This also repros #10.
Thanks for your time for this nice product!

Pretty sure this is caused by isTTY failing in the child process since the parent isn't passing through stdio. As a quick test I updated your mocha exec command to force colors nodejs-dashboard -- mocha test.js --colors and it reproduces them correctly.
The trick here is finding a way to force tty with a child process. The issue is detailed nicely here: https://github.com/nodejs/node-v0.x-archive/issues/2754

For chalk-based apps / scripts, the FORCE_COLOR="true" env variable will force colors to be enabled. Not sure if it's appropriate for the dashboard itself to hack that in though... Possibly could have a dashboard --colors flag to "do all hacks possible to do colors that we know of".
See https://github.com/chalk/supports-color/blob/master/readme.md#info

I can confirm that adding the environment values will fix both issues.
Add the following values to your docker-compose.yml file
    environment:
      LANG: en_US.UTF-8
      FORCE_COLOR: 'true'

I forked @enko 's gist to include adding the environment values. The tests run with the graphs showing the correct dots and the color in the stdout window. https://gist.github.com/jjasonclark/0afed89466db871a3479f55ca2534439
docker-compose run --rm test_runner

Closing as complete

Added README instructions for the environment values found in this issue.
PR https://github.com/FormidableLabs/nodejs-dashboard/pull/74


Can't run "pod install"

Hi, i'm trying to make the proper building and it gives me several error. First it tells me it can't find Campaign Demo.xcodeproj, then it tells me it can't find Campaing Demo target.
Thanks

Hi, which project are you trying to build?

I'm trying to build campaign demo.

Hi,
Please do a fresh pull from the repo. We have done some changes and refreshed both the SDK and the Campaign Demo sample (now called ProximitySense Campaign Demo).

Hi Vlad, just for let you know, users could face problems with the folder naming convention, for example in terminal if I do cd Campaign Demo it would tell me there's no folder with that name. I suggest Campaign-Demo or using - when having space in names. It's just a little detail.


Cheat code doesn't work with SHIFT - only with caps lock

When I enter the EX cheat code, I have to use caps lock for it to work. Typing it in capitals with shift doesn't trigger it.
My environment is Chrome on Windows 10 x64

I see why this is and I think I can fix it without too much trouble. In the meantime, you can actually just enter the code in lower case. SHH DON'T TELL ANYONE.

Should be fixed by 924adb170812458e58227bb6280c72b728fb9e43.


Fixing grid spacing issue

[x] I have followed (at least) the PR section of the contributing guide.

Fixes this issue #24272

Please check out the Demo. The other solution there is on the code is from a user that was discussing issue #24272

Please check out the Demo. The other solution there is on the code is from a user that was discussing issue #24272

This last commit was a code that I wrote a long time ago, but when I got the fork was with an old version of the code.

This last commit was a code that I wrote a long time ago, but when I got the fork was with an old version of the code.

I've created a new PR #24332 to do the same functionally as this without the fullWidth prop

I've created a new PR #24332 to do the same functionally as this without the fullWidth prop

Closing for #24332

Closing for #24332


[BUG] SkiaSharp.Views.WinUI doesn't work with .Net 7

Description

Assembly 'SkiaSharp.Views.Windows' with identity 'SkiaSharp.Views.Windows, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=0738eb9f132ed756' uses 'WinRT.Runtime, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=99ea127f02d97709' which has a higher version than referenced assembly 'WinRT.Runtime' with identity 'WinRT.Runtime, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=99ea127f02d97709'

Code

Expected Behavior

Actual Behavior

Basic Information

Detailed IDE/OS information (click to expand)

PASTE ANY DETAILED VERSION INFO HERE

Screenshots

Reproduction Link
App1.zip

Booo. I literally got this right now and I am trying to figure this out.
Try adding this to your csproj:
<FrameworkReference Update="Microsoft.Windows.SDK.NET.Ref" RuntimeFrameworkVersion="10.0.19041.27" TargetingPackVersion="10.0.19041.27" />

@Summpot  updating WASDK here: https://github.com/mono/SkiaSharp/pull/2276


isLoaded stays in false and never changes until page is refreshed [iOS]

[x] Review the documentation: https://clerk.com/docs
[x] Search for existing issues: https://github.com/clerkinc/javascript/issues
[x] Go through package changelog files.
[] Provide the Frontend API key from your application dashboard.

Package + Version

[x] @clerk/nextjs = 4.23.2

Dependencies + versions
Provide a json with the dependencies used in your project (copy paste from yarn.lock / package-lock.json) or a github project / template that reproduces the issue.
Include the @clerk/ packages and their versions!*
Example:
{
  "name": "cengo",
  "version": "0.1.0",
  "private": true,
  "author": "cengo",
  "scripts": {
    "dev": "next dev",
    "build": "node -v & next build",
    "postbuild": "next-sitemap",
    "start": "next start",
    "lint": "next lint",
    "lint:fix": "eslint src --fix && yarn format",
    "type-check": "tsc --noEmit",
    "format": "prettier --write src",
    "up": "yarn upgrade-interactive",
    "up-latest": "yarn up --latest",
    "release": "standard-version",
    "push-release": "git push --follow-tags origin main",
    "prepare": "husky install"
  },
  "dependencies": {
    "@auth0/nextjs-auth0": "^1.7.0",
    "@chakra-ui/react": "2.4.2",
    "@choc-ui/chakra-autocomplete": "^5.1.4",
    "@clerk/nextjs": "^4.23.2",
    "@emotion/react": "^11.7.1",
    "@emotion/styled": "^11.6.0",
    "@fontsource/inter": "^4.5.7",
    "@fontsource/rubik": "^4.5.6",
    "@formulajs/formulajs": "^3.1.1",
    "@hookform/resolvers": "^3.1.1",
    "@mapbox/search-js-core": "^1.0.0-beta.14",
    "@react-google-maps/api": "^2.18.1",
    "@sentry/nextjs": "^7.50.0",
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "@types/react-icons": "^3.0.0",
    "@types/js-cookie": "^3.0.3",
    "airtable": "^0.11.6",
    "aos": "^3.0.0-beta.6",
    "auth0-lock": "^11.33.0",
    "autoprefixer": "10.4.5",
    "axios": "^1.3.6",
    "chakra-react-select": "^4.6.0",
    "chart.js": "^4.3.0",
    "chartjs-plugin-datalabels": "^2.2.0",
    "crisp-sdk-web": "^1.0.19",
    "cruip-js-toolkit": "^1.0.2",
    "date-fns": "^2.30.0",
    "disable-scroll": "^0.6.0",
    "focus-visible": "^5.2.0",
    "form-data": "^4.0.0",
    "framer-motion": "^7.6.0",
    "fuse.js": "^6.6.2",
    "gray-matter": "^4.0.3",
    "highcharts": "^10.0.0",
    "highcharts-react-official": "^3.1.0",
    "js-cookie": "^3.0.5",
    "lodash": "^4.17.21",
    "mailgun.js": "^8.0.6",
    "markdown-it": "^13.0.1",
    "next": "^13.3.1",
    "next-pwa": "^5.6.0",
    "next-seo": "^6.0.0",
    "next-sitemap": "^4.1.3",
    "node-sass": "7.0.1",
    "numeral": "^2.0.6",
    "postcss": "^8.3.0",
    "prop-types": "^15.8.1",
    "rc-tooltip": "^5.2.2",
    "react": "^18.2.0",
    "react-chartjs-2": "^5.2.0",
    "react-collapse": "^5.1.1",
    "react-dom": "^18.2.0",
    "react-facebook-pixel": "^1.0.4",
    "react-ga4": "^2.1.0",
    "react-google-autocomplete": "^2.7.0",
    "react-google-streetview": "0.0.9",
    "react-hook-form": "^7.45.0",
    "react-hotjar": "^5.0.0",
    "react-icons": "^4.9.0",
    "react-table": "^7.8.0",
    "react-toastify": "^9.0.1",
    "react-transition-group": "^4.4.1",
    "sass": "^1.54.9",
    "stripe": "^9.0.0",
    "tailwindcss": "^2.1.4",
    "use-debounce": "^7.0.1",
    "web-vitals": "^0.2.4",
    "yup": "^1.2.0",
    "zustand": "^4.3.7"
  },
  "devDependencies": {
    "@commitlint/config-conventional": "^16.2.1",
    "@tailwindcss/typography": "^0.4.0",
    "@types/auth0-lock": "^11.27.4",
<EMAIL_ADDRESS>"^3.48.5",
    "@types/react": "^18.0.0",
    "@types/react-dom": "^18.0.0",
    "commitlint": "^16.2.1",
    "eslint": "^8.9.0",
    "eslint-config-next": "^13.0.6",
    "eslint-config-sznm": "^0.2.1",
    "eslint-plugin-react-hooks": "^4.6.0",
    "husky": "^7.0.4",
    "lint-staged": "^12.3.4",
    "prettier": "^2.5.1",
    "standard-version": "^9.3.2",
    "typescript": "^4.5.5"
  }
}

Browser/OS
iOS 16.3.1 / Safari / Chrome
Description
Describe your issue in detail, a demo repository or a sandbox would be great.
After logging in with Clerk, isLoaded variable from the useUser hook doesn't change and isn't able to trigger the useEffect we have.

  useEffect(() => {     if (isLoaded) authenticateUser();     // eslint-disable-next-line react-hooks/exhaustive-deps   }, [isLoaded]);

Hi @cengizhanhakan - could you provide a minimal reproduction for us to look into?

hi @jescalan, any updates?

Hi! Sorry for the delayed response. A link to your production website is not a minimal reproduction. We have a guide here on how to create a minimal reproduction, hopefully this is helpful! Sorry for not linking it before.

hi @jescalan, I hope this is good enough.
https://github.com/cengizhanhakan/clerk-repro
https://clerk-repro-1l2n9zzwf-recipecart.vercel.app/

hello @cengizhanhakan
visiting your https://clerk-repro-1l2n9zzwf-recipecart.vercel.app/ and executing a sign-in I can see that isLoaded is updated based on the logs:
What is the expected the behavior you are trying to achieve using the isLoaded? If your issue is the stale no user message on the page you should either depend on the <SignedIn/>, <SignedOut/> Clerk controls to render authenticated / un-authenticated parts of the page or use the const {user} = useUser() effect on your current example instead of the const {user} = useClerk().

hi @dimkl
Thank you for the comment. The problem only occurs on iOS. Steps to reproduce:

Connect your iPhone device to a mac.
then go into the website and try to log in
in logs isLoaded wont get updated
therefore page wont be loaded

Hi team, we're still waiting on a response here.

Hello @cengizhanhakan @pakaplace, I've tried to reproduce the issue in multiple versions of iOS using both Chrome and Safari. However, based on the logs on https://clerk-repro-1l2n9zzwf-recipecart.vercel.app/, everything seems to be working as expected. Can you please confirm if you are still encountering that issue?

Hello @octoper After doing some testing on real devices. I will update here.

Hello! 👋
Please let me know if the issue still exists after testing on real devices.
Additionally, to keep our GitHub issues organized, if there's no response within the next 7 days, I will consider the issue resolved and close it.
Feel free to reopen it or reach out for further assistance.
Thanks! 🚀

Hi @octoper, the issue stopped happening for us on ios devices about a month ago.
However, I was hoping you could suggest a better pattern on fetching user data from our external backend. We have a user table in our database that stores subscription data. In our next.js frontend, after waiting for isLoadedto be true, we call our API to fetch user subscription data.
Once user data is loaded, then we render the page the user is trying to navigate to. You can see our parent component where we do the fetching in this reproduction:
https://github.com/cengizhanhakan/clerk-repro/blob/main/src/pages/layout.tsx
I'd like to fetch this user data before the page loads so it doesn't slow down our app or affect our SEO. Could this be done from the middelware or should it be done from getServerSideProps? I also thought about using the webhooks. We would have to update the clerk webhooks every time there's an update to a user's info or stripe subscription, I imagine, which seems like a lot of work.

Closing this issue out as it appears to be resolved, but please feel free to keep the discussion going! I am sure that @octoper will respond here soon ✨

Hello @pakaplace , I'm glad to hear that your issue has been fixed.
Answering your other question, the most preferred and optimal way to sync data on your end is by using Webhooks. We have a straightforward guide on how to do it, which you can find here: Sync Clerk data to your backend with webhooks. This solution is the most optimal as you will only update the user on your end when the user is actually updated. Other solutions, like the one you currently have or the getServerSideProps solution, could result in additional queries in your database as you would always update the user on every request, even if the data didn't change at all.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.


Feature: Improve tags context menu

Resolved / Related Issues
Items resolved / related issues by this PR.

Closes #11457

Validation
How did you test these changes?

[x] Built and ran the app
[x] Tested the changes for accessibility

Screenshots (optional)
Add screenshots here.

Should this have "send to" and "open with" as well?

I think we could do that, but shouldn't we do it in another PR, as it would need to be implemented for the rest of the widgets?

The other widgets already have this, I think we're only missing it for tags.


Fix documentation for uploadFromFile

Q
A

Type
improvement

BC Break
no

Fixed issues
#2283

Summary
Fixed argument order
Fixed example with Metadata object used instead of UpdloadOptions containing the metadata

@SenseException I'm going to change the default branch now, forgot to do that yesterday :)
@rrajkomar I tried to change the target branch for you but it produced additional commits. You'll need to rebase your work atop 2.2.x

This should do it.

Please also fix the other $repository->uploadFromFile('image.jpg',  parts.

@SenseException I think I fixed them all this time. Coudn't find any other concerned reference of the method.

@SenseException with @alcaeus' approval I'm marking this as good to go.
Thanks @rrajkomar!


Introduce peer.hostPort standard tag

We currently have a series of standard peer tags like peer.ipv4, peer.hostname, peer.port, etc. I've discovered that quite often the RPC libraries being instrumented with OT do not actually know the exact format of "host:port" string they are given, because they just pass it to lower-level networking libraries. Therefore when RPC libraries need to identify the peer via peer tags, they often have to duplicate the same parsing code, for example here.
I would like to propose a standard tag peer.hostPort (string) which can take a variety of different formats and let the tracer implementation deal with parsing it (or even send it off to collection tier to process later).  Specifically, the tag value could be one of these forms:

host:port (port must be a number)
host (no port)
where host can be

host name, e.g.

"myhost"
"webserver.mydomain.com"
"ip-12-34-56-78.us-west-2.compute.internal"

IPv4 address, e.g. "<IP_ADDRESS>"
IPv6 address in brackers [], e.g. "[2001:0db8:85a3:0000:0000:8a2e:0370:7334]"

cc @bensigelman @dkuebric

@yurishkuro what do you think about peer.address? E.g., at google there was a service-naming scheme that wasn't host:port but was widely available and canonical (and did ultimately boil down to host:port after resolution).

@bensigelman address sounds quite different from hostPort, given what you said about resolution. For example, if you're instrumenting a plain HTTP client, I don't think it will work with address that needs resolution, but it will work with all the variants of hostPort I showed above, and that hostPort will be eventually available in the user code after resolution step.
It's certainly useful to capture resolvable address, but I would do it as a separate tag from hostPort. Also, resolvable address probably isn't going to differentiate between the instances of the target service, whereas hostPort will (unless there's additional routing like haproxy).

It just seems weird to me to support host, port, and hostPort (not to mention address)

It reflects various degrees of information available to instrumentation:

if you know exactly the host and port, use peer.ipv4 / peer.ipv6 and peer.port
if you only know the unparsed hostPort string, use peer.hostPort
if you only know resolvable/virtual name, use peer.address

Right now we don't have a place to store something like google.com:8080 at all.

@yurishkuro another option would be to write a helper (could even be part of OT/ext) that takes an address string and does its best to convert to the finest-grain tags available. So google.com:8080 would become peer.host and peer.port, though some weird/unparseable custom addressing scheme would just end up being passed through as-is to peer:address.
I am (obviously) trying to avoid a situation where the "official" tags overlap more than is needed.

@bensigelman that's certainly an option, my concern with that was actually about adding the CPU overhead on the client app, because this helper function might turn out to be fairly involved. In contrast, having client app submit the same info via hostPort tag moves the performance concern into tracer implementation, where it can try to amortize the parsing cost via caching, or even not bother with parsing and let the out-of-process collectors do the parsing (NB: in order to submit well-formed Zipkin Thrift spans, the host:port do need to be parsed).
PS: I was wrong about "Right now we don't have a place to store something like google.com:8080 at all" - we do have peer.hostname.

PS: performance implication of always parsing hostPort string is especially pronounced when tracer performs heavy upfront sampling (e.g. our default is 1 in 1000)

@yurishkuro I still find myself feeling more enthusiastic about peer.address than peer.hostPort... In the spirit of "cattle not pets"—especially when things like kubernetes/mesos/etc are further virtualizing/obfuscating the notion of a hostname or the meaning of an ip address—I would rather that OpenTracing was encouraging people to use a more semantically meaningful identifier (than hostPort) for their peer. Or, if not encouraging it, I think it would be nice if OpenTracing chose a peer identifier that's general enough to be useful once hostnames are transient and don't mean anything in 5 years.
On that note, we could look towards the Go Dial approach: https://golang.org/pkg/net/#Dial
This would yield a peer.network and peer.address if we were literal about it. I could imagine s/network/scheme/ or similar.

For the reason that @yurishkuro mentions that different clients have different levels of visibility into a RPC call, we've adopted a model that allows either reporting an all-in-one RemoteURL key or a set of component keys (RemoteHost,RemotePort, etc...) depending on what is available in the client.
Ultimately we prefer RemoteURL and allow it to be having/missing various components.  Format: [protocol://][domain-or-ip][:port][/path][?args], where protocol, port, path, and args are all optional.  This is fairly similar to the Dial approach.  We continue to support the other both for legacy reasons and also as it can be more performant in some cases where stringifying a URL isn't ideal.
peer.scheme and peer.address both make sense, and with some flexible parsing on address it will fit a large range of cases.  However, given the commonness of HTTP RPC it's nice to support a URL-ish format as well, since this is often available--so despite the reservation against overlapping keys what would you think about offering an alternative/supplement there?

I also like peer.address - its name is clear enough to know what it should contain and broad enough to support a lot of scenarios.

... continued on https://github.com/opentracing/specification/issues/16


APEX-117 #resolve metrics aggregation triggered withing app window

@davidyan74 Please review
Test application http://node17.morado.com:9097/static/#/ops/apps/application_1441698239695_9615

@davidyan74 done. please merge


Table and content are not consistent - in text, it says only dynamic public IP can be associated with VPN and Appliation Gateways.  However, in the table, it marked as "YES" for both dynamic and static allocations.

Azure documentation issue guidance
Thanks for opening an issue in the Azure technical documentation repository.
We use GitHub issues as the primary channel for customer and community feedback about the Azure documentation.
Creating an issue
We prefer that you create documentation feedback issues using the Feedback link on the published article - the feedback control on the doc page creates an issue that contains all the article details so you can focus on the feedback part.
You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
[ ] A link to the published documentation article that you have feedback about.
[ ] Clear, specific feedback that the author can act on.

Pull requests and article contributions
If you know the change that is needed in an article, we encourage you to submit the changes directly using a pull request. If the change is large, or if you want to contribute an entire article, follow these guidelines:

[ ] Don't surprise us with a big pull request or a pull request with a new article! Submit an issue that describes the details of the proposed large change or new article.
[ ] Include the service or technology area.

We'll route the issue to the appropriate content team for review and discussion.
Tech support and product feedback
If you would like to contact Microsoft about other things, such as product feedback or tech support, please review these guidelines:

If you need technical support using Azure, the paid and free support options are described here: https://azure.microsoft.com/support/options/.

Each article in the Azure technical documentation contains a product feedback button - it's best to submit product feedback directly from a relevant article. Otherwise, you can submit product feedback for most Azure products in the following product feedback forum: https://feedback.azure.com/forums/34192--general-feedback.

@harrchen88 Hi, thanks for your feedback. Could you please share the document you are referring to?

@harrchen88 we will close for now. If you still have an issue please open a new issue and share the doc you are having issues with.


Backport 2.1: Improve documentation of mbedtls_ssl_get_verify_result()

This is the backport to Mbed TLS 2.1 of #2127, fixing #517.

@k-stachowiak Thanks for noticing, I agree and pushed a commit adapting the ChangeLog.
@k-stachowiak @AndrzejKurek Please re-review.


 Calls to ReactContext#getJSModule should only happen once initialize() has been called on your native module.

I'm getting the below crash report in firebase crashlytics (Only Android).
I am not able to reproduce on my device but seems like live users are facing this.
Any help would be highly appreciated.
 Calls to ReactContext#getJSModule should only happen once initialize() has been called on your native module.
       at com.facebook.react.bridge.ReactContext.getJSModule(ReactContext.java:148)
       at com.wix.reactnativenotifications.core.JsIOHelper.sendEventToJS(JsIOHelper.java:21)
       at com.wix.reactnativenotifications.core.JsIOHelper.sendEventToJS(JsIOHelper.java:13)
       at com.wix.reactnativenotifications.core.notification.PushNotification.notifyReceivedBackgroundToJS(PushNotification.java:208)
       at com.wix.reactnativenotifications.core.notification.PushNotification.onReceived(PushNotification.java:68)
       at com.wix.reactnativenotifications.fcm.FcmInstanceIdListenerService.onMessageReceived(FcmInstanceIdListenerService.java:28)
       at com.google.firebase.messaging.FirebaseMessagingService.dispatchMessage(com.google.firebase:firebase-messaging@@21.1.0:13)
       at com.google.firebase.messaging.FirebaseMessagingService.passMessageIntentToSdk(com.google.firebase:firebase-messaging@@21.1.0:8)
       at com.google.firebase.messaging.FirebaseMessagingService.handleMessageIntent(com.google.firebase:firebase-messaging@@21.1.0:3)
       at com.google.firebase.messaging.FirebaseMessagingService.handleIntent(com.google.firebase:firebase-messaging@@21.1.0:3)
       at com.google.firebase.messaging.EnhancedIntentService.lambda$processIntent$0$EnhancedIntentService(com.google.firebase:firebase-messaging@@21.1.0:1)
       at com.google.firebase.messaging.EnhancedIntentService$$Lambda$0.run(:6)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
       at com.google.android.gms.common.util.concurrent.zza.run(com.google.android.gms:play-services-basement@@17.3.0:6)
       at java.lang.Thread.run(Thread.java:764)

I'm facing the same issue, It happens if the app receives a notification while is being opened.
How to reproduce,
Trigger a notification and tap on the app icon just before the notification is received (might need some attempts to get the timing right).
Found this issue with the same symptoms.
https://github.com/OneSignal/react-native-onesignal/issues/877

I've got same error. Did anyone find a solution?

I downgrade  "expo-notifications" to "0.20.0" version. This is fixed my issue.

I've found a way to prevent the crash.
Can i reopen a new issue with the PR?

I've found a way to prevent the crash. Can i reopen a new issue with the PR?

Im receiving these errors with my RN 0.74 app since i added vision camera, i suspect the increased loadup time of the app made these crashes happen. Nothing has changed regarding push notifications

I've found a way to prevent the crash. Can i reopen a new issue with the PR?

Could it be released?


[rv_timer] D2(S) Signoff

Description
Ensure D2(S) signoff criteria are still maintained (this is not a focus area block).

Commits since Earlgrey-ES tapeout
Checked with version dc22677a68 (the head of master on 26/2/24).
Commits since the Earlgrey ES tapeout, found by git log Earlgrey-M2.5.2-RC0..HEAD --oneline hw/ip/rv_timer
(and dropping the CIP_ID change/revert combo):

61a237e197 [util/reggen] reverse order of substruct generation

Moved around cfg0 register ordering.

de31bdf1c2 [reggen] Remove the devmode input

No functional change (this was already tied to 1)

b3bd66c923 [rv_timer] Update the documentation

Documentation tidyup.

110239cb42 [rv_timer, sival] List the features

SiVal only

1b16ca2122 [reggen] Add mubi support SWAccess that sets/clears a reg

Tooling change: no change in behaviour.

59f8142826 [doc] Moved badges over to using hosted images

Documentation format change

5670965b32 [doc] rv_timer registers and interfaces now use CMDGEN

Documentation format change

7688e714e8 [reggen] Add initial support for version and cip_id hjson fields

HJson-only change

Issues closed since the Earlgrey-ES tapeout
Using the filter is:issue is:closed closed:>2023-06-27 rv_timer
finds the following two issues. Both are SiVal tasks and needn't
affect the D2S status of rv_timer.

#19979
#19978

Currently open issues
Here is a list of tests based on the filter is:issue is:open rv_timer.
I've skipped SiVal and the V2(S)/D2(S) signoff issues.

#18918

This is planned design work which is currently intended to land before the M2 milestone.
I'm don't believe it disqualifies rv_timer from D2S status. This is a bugfix, not a new feature.

#18093

Top-level wiring change: it won't affect the internals of
rv_timer.

#270

Ancient top-level tooling change. No direct connection with
rv_timer.

Summary

None of the changes that have landed will affect D2S status.
The only issue that's currently open and might affect rv_timer is #18918
This is essentially a bugfix, so needn't affect D2S status.

Tagging @GregAC (as a relevant design TL).
Greg: if you're happy with this assessment, please close this issue.

Due to our priorities, the interrupt alignment is deferred into PROD.M4 since it does not have notable PD impact.


Anna Veronika Dorogush: Mastering gradient boosting with CatBoost | PyData London 2019

https://youtu.be/usdEWSDisS0
Contents
0:00 - Introduction
1:49 - Intro to CatBoost
2:08 - Overview of the Presentation
2:39 - Intro to Gradient Boosting
6:08 - Numerical and Categorical Data with CatBoost
7:26 - Advantages of CatBoost
9:00 - Library Comparison (Quality)
9:45 - Speed
10:11 - Benchmarking (CPU & GPU)
11:55 - CPU vs GPU
12:50 - Prediction Time
13:24 - Tutorial
15:15 - Problem Statement
15:38 - CatBoost Library (Imports and related issues)
16:22 - Reading and Intro to the Data
18:17 - Exploring the data
19:36 - Training the Model with default parameters
22:16 - Creating the Pool Object
23:12 - Splitting the data (Train & Validation)
24:16 - Selecting the objective function
25:11 - STDOUT of training
28:32 - Plotting metrics while training
30:33 - Model Comparison (plotting after training)
32:39 - Finding the best model
35:05 - Cross Validation
41:30 - Grid Search
44:40 - Overfitting Detector
49:18 - Overfitting Derector with eval metric
51:31 - Model Predictions
57:10 - Select Decision Boundary
1:01:04 - Model Evaluation (new dataset)
1:03:06 - Feature Importance
1:03:37 - Prediction Values Change
1:04:50 - Loss Function Change
1:07:49 - Shap Values
1:16:05 - Snapshotting
1:17:45 - Saving the Model
1:18:36 - Hyperparameters Tuning
1:23:07 - Speeding up Training and Reducing Model Size
1:23:35 - Additional Details about CatBoost Community
1:25:50 - Future Scope of CatBoost
1:26:22 - Questions and Suggestions

This is great! Thanks so much.