Order[ContentCoding] failure

2020-04-13T03:25:16.4857959Z [info] order laws must hold for Order[ContentCoding]
2020-04-13T03:25:16.4858291Z [error] x order.antisymmetry (41 ms)
2020-04-13T03:25:16.4858573Z [error]  Falsified after 0 passed tests.
2020-04-13T03:25:16.4858823Z [error]  > Labels of failing property:Expected: true
2020-04-13T03:25:16.4859069Z [error]  Received: false> ARG_0: ContentCoding(t, QValue(0.0))
2020-04-13T03:25:16.4859312Z [error]  > ARG_1: ContentCoding(t, QValue(0.0))
2020-04-13T03:25:16.4859557Z [error]  > ARG_2: org.scalacheck.GenArities$$Lambda$20955/1421781070@14088a8f
2020-04-13T03:25:16.4859794Z [error]  The seed is 2kpw5tJ8tADijqPv2GG3pUWPhjzpJUnaypQufFSWHBB=

can more context be added to this issue? I would like to pick it up but I am not sure what is the issue about?

Antisymmetry says that If ARG_0 <= ARG_1, and ARG_1 <= ARG_0, then ARG_0 == ARG1.  This didn't happen.  To make the failure repeatable, you can call setSeed("2kpw5tJ8tADijqPv2GG3pUWPhjzpJUnaypQufFSWHBB") on the property.
The ordering instance calls toLowerCase, but the equals method calls equalsIgnoreCase.
I think the right change in 0.21 would be to change that ordering instance to use compareIgnoreCase instead of equality on toLowerCase.  The former does a round trip through toUpper and toLower on each character, and is also faster if there is a difference early in the string.
I think none of this matters in the real world: these charsets should always be ASCII, where these weird differences don't happen.  That's probably a non-ASCII t character causing us problems here.

@rossabaker thank you for the explanation:) Where are the order law tests? git grep "order laws must hold for"  does not find any occurrences.

They're defined in OrderLaws, which have some supertypes that reflect the hierarchy.  You shouldn't need to change the test -- just the comparisons in the code.

@rossabaker

To make the failure repeatable, you can call setSeed("2kpw5tJ8tADijqPv2GG3pUWPhjzpJUnaypQufFSWHBB") on the property.

How do I do this?

Oh, good question.  You can call prop { ... }.setSeed(...) on the regular property tests, but I had to look up how to do it in the discipline tests.  This exposes the failure:
checkAll("Order[ContentCoding] for #3328", OrderTests[ContentCoding].order)(Parameters(seed = Seed.fromBase64("2kpw5tJ8tADijqPv2GG3pUWPhjzpJUnaypQufFSWHBB=").toOption))

@rossabaker

That's probably a non-ASCII t character causing us problems here.

Which non-ascii character is causing the problem? I tried out many of Non-Ascii characters from this website. All of them return the same value when toLowerCase is called on them.

@rossabaker From java documentation for toLowerCase() :
This method is locale sensitive, and may produce unexpected results if used for strings that are intended to be interpreted locale independently. Examples are programming language identifiers, protocol keys, and HTML tags. For instance, "TITLE".toLowerCase() in a Turkish locale returns "t\u0131tle", where '\u0131' is the LATIN SMALL LETTER DOTLESS I character. To obtain correct results for locale insensitive strings, use toLowerCase(Locale.ENGLISH).

I think toLowerCase(Locale.ENGLISH) should be the solution here. The tests pass with the seed value. WDYT?

@rossabaker To add to the above point, equalsIgnoreCase compares each character using Character.toLowerCase and Character.toUpperCase. From the java doc of Character.toLowerCase
Note that Character.isLowerCase(Character.toLowerCase(ch)) does not always return true for some ranges of characters, particularly those that are symbols or ideographs.

In general, String.toLowerCase() should be used to map characters to lowercase. String case mapping methods have several benefits over Character case mapping methods. String case mapping methods can perform locale-sensitive mappings, context-sensitive mappings, and 1:M character mappings, whereas the Character case mapping methods cannot.

Note: This method cannot handle supplementary characters. To support all Unicode characters, including supplementary characters, use the toLowerCase(int) method.

See #3518 for what I believe to be the real reason.
That fix is a hack, because we used String instead of CIString in the model and need to preserve it.  I think in 1.0, we want to use CIString, and correctness will follow.


Can't run docker container anymore.

Description
Up until now I had this running flawlessly
---
version: "3"

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    restart: always
    ports:
      - 3020:3000
      - 222:22
    environment:
      - USER_UID=1000
      - USER_GID=1000
    labels:
      - deunhealth.restart.on.unhealthy=true
    networks:
      - gitea
    volumes:
      - /home/xxx/docker-data/gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
networks:
  gitea:
    external: false

Now the log in Portainer says:
2023/07/28 08:13:10 ...g/config_provider.go:327:deprecatedSettingFatal() [F] Deprecated fallback `[server]` `LFS_CONTENT_PATH` present. Use `[lfs]` `PATH` instead. This fallback will be/has been removed in v1.19.0. Shutting down

Received signal 15; terminating.

Server listening on :: port 22.

Server listening on <IP_ADDRESS> port 22

Gitea Version
whatever latest version is pulled from image: gitea/gitea:latest
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
git version 2.34.1 runs on the server / whichever is included in image: gitea/gitea:latest
Operating System
Server runs on Ubuntu 22.04.2 LTS
How are you running Gitea?
Docker container on me server
Database
SQLite

Ah yes, solution was here: https://github.com/go-gitea/gitea/issues/25915#issuecomment-1640933269


IP Validation + optional is behaving unexpectedly

Hello,
I've encountered an issue a couple of days ago and did not find any related topics or issues to that. Maybe my assumption is wrong but I've created a simple example to show what is currently not working as (I) intended it will do:
Sandbox
It is possible to chain ip() with optional() - however the validation will fail for an empty string. I've also checked the docs on any exceptions for the usage of optional() but did not find any limitations to that.
Is this a bug or expected behaviour and if so, how can others be made aware of this behaviour?

Hmm, i couldn't reproduce this. i get a successful feedback for both - here's a screenshot

Did you try my sandbox example? There you can see that is does not work like in your example and I wonder why


cordova linkedin login issue

var scopes = ['r_basicprofile', 'r_emailaddress', 'rw_company_admin', 'w_share'];
var onSuccess = function(r) { myApp.alert('LinkedIn Response: ', r); } var onError = function(e) { myApp.alert('LinkedIn Error: ', e); }
cordova.plugins.LinkedIn.login(scopes, true, function() { cordova.plugins.LinkedIn.getRequest('people/~:(email-address,first-name)', onSuccess, onError); }, onError);
Linkedin login using cordova i added this plugin cordova plugin add cordova-plugin-linkedin --variable APP_ID=YOUR_APP_ID
Example of this code taken from this page ------ https://www.npmjs.com/package/cordova-plugin-linkedin
While i am trying to login in linkedin the splashscreen of linkedin app disppears in seconds and in alert error this is coming "{\n "errorCode": "USER_CANCELLED",\n "errorMessage": "user canceled"\n}"
But when i logging in first time the linkedin app just opens as normal but getting this error myApp.alert('LinkedIn Error: ', e);
Can anyone please help me to fix it? If there is any links available also let me know.

Have you solved it? I also encountered the same problem


chore: Tune Hypothesis configuration

Note! Please review first commit, and just verify fall-out on code generation in the second.
This addresses the issue that Java compatibility tests and other roundtrip tests were configured with wildly different parameters. It removes the explicit @setting(max_examples=1) from all round trip tests, and now instead only configures this on a global level.
Adds two separate Hypothesis profiles and support for choosing them with the HYPOTHESIS_PROFILE env var (I use direnv to set exhaustive in my dev env).
The deterministic is used by default, and it limits max_examples to 5 which seems like a reasonable amount to start with. It enables Hypothesis' own "deterministic" feature, which means it promises to always generate the same data for a test function, as long as the test function itself doesn't change. This is appropriate for CI.
Deadlines and the "too slow" healthcheck are disabled in both profiles, as it's more likely to trigger on VM pauses than actual slow data generation.

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

Comparison is base (ee6e5b1) 96.02% compared to head (aadf97d) 96.02%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #125   +/-   ##
=======================================
  Coverage   96.02%   96.02%
=======================================
  Files          14       14
  Lines        1031     1031
  Branches      144      144
=======================================
  Hits          990      990
  Misses         33       33
  Partials        8        8

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

I'm wondering if make sense to remove the tests from the git repo and always generate the sources from the definition at runtime, its really a huge diff and its hard to navigate from the history :)
Not something I will fight for, just understand if could make sense having out of the history

Yeah, it's a good discussion to have. The current state is a bit of an experiment. However, it was a very deliberate decision to begin with and the reason is because I think it's super helpful from a library consumer's perspective. Being able to jump to definitions, and to link to an actual line is valuable (I can link you here and we can discuss around AddOffsetsToTxnRequest.transactional_id).
If we were to turn that into something that's just generated at packaging time, I believe it becomes much more abstract in the sense that there is no longer concrete lines of code to navigate through and to reference.
I agree status quo is not optimal when reviewing code generation changes, but I'm also somewhat hoping that these changes will become more and more rare as the library stabilizes (so far this has not been true 🙈).
An other aspect is that it might not actually become easier to review if we lazy-generate the models, it might actually become harder to determine what the actual impact on generated code is for a given PR, when the delta is not explicitly displayed.


Amplify v11.0.4 build issues (cannot find schema.graphql or amplify-meta.json)

How did you install the Amplify CLI?
brew
If applicable, what version of Node.js are you using?
18.15.0
Amplify CLI Version
11.0.4
What operating system are you using?
MAC OS, Linux, Windows (all)
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
no
Describe the bug
With amplify v 11.0.4 API graphql file or amplify-meta.json file not found during amplify cicd build
Again a problem with amplify
newest version of amplify breaks in 2 ways depending on the structure of the GRPHQL schema
if multiple graph schema modules are used it breaks like so:
2023-04-11T13:34:02.749Z [INFO]: :octagonal_sign: ENOENT: no such file or directory, open ‘/codebuild/output/src636864984/src/<PROJECT_NAME>/amplify/backend/api/<PROJECT_NAME>/schema.graphql’
if one schema.graphql used it breaks like so:
2023-04-11T13:11:44.315Z [INFO]: :octagonal_sign: File at path: ‘/codebuild/output/src419238389/src/<PROJECT_NAME>/amplify/#current-cloud-backend/amplify-meta.json’ does not exist
CAUSE
amplify version: 11.0.4
FIX
downgrade amplify version to 10.5.2 and rerun (or 11.0.3 might work too - have not tested yet)
Expected behavior
amplify build should work
Reproduction steps

amplify upgrade - to version 11.0.4
run amplify build by doing source code commit and push to trigger amplify build
amplify console cicd upgrades to "amplify latest"
build fails with one of 2 errors
4.1. ENOENT: no such file or directory, open /codebuild/output/src636864984/src/<PROJECT_NAME>/amplify/backend/api/<PROJECT_NAME>/schema.graphql’
4.2. File at path: ‘/codebuild/output/src419238389/src/<PROJECT_NAME>/amplify/#current-cloud-backend/amplify-meta.json’ does not exist
change amplify settings in amplify console "build settings" to use a previous version (e.g. 10.5.2)
rerun last amplify build
build succeeds

Project Identifier
No response
Log output

# Put your logs below this line
2023-04-11T13:31:14.555Z [INFO]: Git SSH Key acquired
2023-04-11T13:31:14.623Z [INFO]: # Cloning repository: git@gitlab.com:PROJECT_NAME1/PROJECT_NAME.amplify.git
2023-04-11T13:31:17.832Z [INFO]: Agent pid 150
2023-04-11T13:31:17.922Z [INFO]: Identity added: /root/.ssh/git_rsa (/root/.ssh/git_rsa)
                                 Cloning into 'PROJECT_NAME.amplify'...
                                 Warning: Permanently added the ECDSA host key for IP address 'my_ssh_ip' to the list of known hosts.
2023-04-11T13:31:17.923Z [INFO]: # Switching to commit: GUID
2023-04-11T13:31:17.948Z [INFO]: Agent pid 163
2023-04-11T13:31:17.949Z [INFO]: Identity added: /root/.ssh/git_rsa (/root/.ssh/git_rsa)
                                 Note: switching to 'GUID'.
                                 You are in 'detached HEAD' state. You can look around, make experimental
                                 changes and commit them, and you can discard any commits you make in this
                                 state without impacting any branches by switching back to a branch.
                                 If you want to create a new branch to retain commits you create, you may
                                 do so (now or later) by using -c with the switch command. Example:
                                 git switch -c <new-branch-name>
                                 Or undo this operation with:
                                 git switch -
                                 Turn off this advice by setting config variable advice.detachedHead to false
                                 HEAD is now at 6f397cf Merge branch 'GIT_BRANCH' into 'dev'
2023-04-11T13:31:18.021Z [INFO]: Successfully cleaned up Git credentials
2023-04-11T13:31:18.021Z [INFO]: # Checking for Git submodules at: /codebuild/output/src636864984/src/PROJECT_NAME.amplify/.gitmodules
2023-04-11T13:31:18.030Z [INFO]: # Retrieving environment cache...
2023-04-11T13:31:18.091Z [INFO]: # Retrieved environment cache
2023-04-11T13:31:18.091Z [INFO]: ---- Setting Up SSM Secrets ----
2023-04-11T13:31:18.091Z [INFO]: SSM params {"Path":"/amplify/djn69vfdidrnu/dev/","WithDecryption":true}
2023-04-11T13:31:33.827Z [INFO]: # Patching NPM package '@aws-amplify/cli' from 10.5.2 to 11.0.4...
2023-04-11T13:31:50.475Z [INFO]: # Done patching NPM package '@aws-amplify/cli' to version 11.0.4
2023-04-11T13:31:50.547Z [INFO]: # Retrieving cache...
2023-04-11T13:31:50.567Z [INFO]: # Retrieved cache
2023-04-11T13:31:54.405Z [INFO]: ## Starting Backend Build
                                 # Starting phase: build
                                 # Executing command: echo --------- SLACK NOTIFICATION ----------
                                 --------- SLACK NOTIFICATION ----------
2023-04-11T13:31:54.409Z [INFO]: # Executing command: . _CI/STACK333s/slack-start.sh
                                 SLACK JOB
                                 {"type":"section","text":{"type":"mrkdwn","text":":truck: *dev* - PROJECT_NAME-Backend-Schema Deployment *STARTED*"}}
                                 {"type":"section","text":{"type":"mrkdwn","text":":truck: *dev* - PROJECT_NAME-Backend-Schema Deployment *STARTED*"}} ,{"type":"divider"}
                                 Posting slack message!
                                 {"blocks":[{"type":"section","text":{"type":"mrkdwn","text":":truck: *dev* - PROJECT_NAME-Backend-Schema Deployment *STARTED*"}} ,{"type":"divider"}]}
2023-04-11T13:31:54.539Z [INFO]: ok
2023-04-11T13:31:54.540Z [INFO]: # Executing command: npm ci
2023-04-11T13:32:00.972Z [WARNING]: npm
2023-04-11T13:32:00.974Z [WARNING]: WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-url#deprecated
2023-04-11T13:32:01.124Z [WARNING]: npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
2023-04-11T13:32:01.300Z [WARNING]: npm WARN
2023-04-11T13:32:01.301Z [WARNING]: deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
2023-04-11T13:32:01.392Z [WARNING]: npm WARN deprecated
2023-04-11T13:32:01.393Z [WARNING]<EMAIL_ADDRESS>See https://github.com/lydell/source-map-resolve#deprecated
2023-04-11T13:32:01.648Z [WARNING]: npm WARN deprecated
2023-04-11T13:32:01.648Z [WARNING]<EMAIL_ADDRESS>The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
2023-04-11T13:32:01.815Z [WARNING]: npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
2023-04-11T13:32:03.373Z [WARNING]: npm WARN deprecated
2023-04-11T13:32:03.373Z [WARNING]<EMAIL_ADDRESS>support for ECMASTACK333 is superseded by `uglify-js` as of v3.13.0
2023-04-11T13:32:03.447Z [WARNING]: npm WARN deprecated
2023-04-11T13:32:03.448Z [WARNING]<EMAIL_ADDRESS>The package @aws-sdk/eventstream-marshaller has been renamed to @aws-sdk/eventstream-codec. Please install the renamed package.
2023-04-11T13:32:06.983Z [WARNING]: npm WARN
2023-04-11T13:32:06.987Z [WARNING]: deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
2023-04-11T13:32:09.234Z [INFO]: added 1205 packages, and STACK444ed 1225 packages in 14s
2023-04-11T13:32:09.235Z [INFO]: 47 packages are looking for funding
                                 run `npm fund` for details
2023-04-11T13:32:09.238Z [INFO]: 4 vulnerabilities (1 moderate, 2 high, 1 critical)
                                 To address all issues, run:
                                 npm STACK444 fix
                                 Run `npm STACK444` for details.
2023-04-11T13:32:09.257Z [INFO]: # Executing command: npm install --save graphql-ttl-transformer
2023-04-11T13:32:11.307Z [INFO]: up to date, STACK444ed 1225 packages in 2s
2023-04-11T13:32:11.309Z [INFO]: 47 packages are looking for funding
                                 run `npm fund` for details
2023-04-11T13:32:11.310Z [INFO]: 4 vulnerabilities (1 moderate, 2 high, 1 critical)
                                 To address all issues, run:
                                 npm STACK444 fix
                                 Run `npm STACK444` for details.
2023-04-11T13:32:13.598Z [INFO]: Amplify AppID found: djn69vfdidrnu. Amplify App name is: PROJECT_NAME
2023-04-11T13:32:13.700Z [INFO]: Backend environment dev found in Amplify Console app: PROJECT_NAME
2023-04-11T13:32:14.441Z [WARNING]: - Fetching updates to backend environment: dev from the cloud.
2023-04-11T13:32:15.032Z [WARNING]: - Building resource api/PROJECT_NAME
2023-04-11T13:32:30.881Z [INFO]: ⚠ WARNING: owners may reassign ownership for the following model(s) and role(s): STACK444: [userId], STACK44: [userId], STACK11: [userId], STACK222: [userId], STACK22: [userId], STACK888: [userId], STACK1234: [userId], STACK333: [userId], STACK555: [userId], STACK33: [userId], STACK111: [userId], STACK999: [userId], STACK999: [userId]. If this is not intentional, you may want to apply field-level authorization rules to these fields. To read more: https://docs.amplify.aws/cli/graphql/authorization-rules/#per-user--owner-based-data-access.
2023-04-11T13:32:31.751Z [INFO]: ✅ GraphQL schema compiled successfully.
                                 Edit your schema at /codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema.graphql or place .graphql files in a directory at /codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema
2023-04-11T13:32:31.752Z [WARNING]: - Building resource auth/PROJECT_NAME08a93afb
2023-04-11T13:32:31.771Z [WARNING]: ✔ Successfully pulled backend environment dev from the cloud.
2023-04-11T13:32:32.192Z [INFO]: ✅
2023-04-11T13:32:34.506Z [INFO]: Note: It is recommended to run this command from the root of your app directory
2023-04-11T13:32:35.096Z [WARNING]: - Initializing your environment: dev
2023-04-11T13:32:35.775Z [WARNING]: - Building resource api/PROJECT_NAME
2023-04-11T13:32:41.521Z [INFO]: ⚠ WARNING: owners may reassign ownership for the following model(s) and role(s): STACK444: [userId], STACK44: [userId], STACK11: [userId], STACK222: [userId], STACK22: [userId], STACK888: [userId], STACK1234: [userId], STACK333: [userId], STACK555: [userId], STACK33: [userId], STACK111: [userId], STACK999: [userId], STACK999: [userId]. If this is not intentional, you may want to apply field-level authorization rules to these fields. To read more: https://docs.amplify.aws/cli/graphql/authorization-rules/#per-user--owner-based-data-access.
2023-04-11T13:32:42.835Z [INFO]: ✅ GraphQL schema compiled successfully.
                                 Edit your schema at /codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema.graphql or place .graphql files in a directory at /codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema
2023-04-11T13:32:42.836Z [WARNING]: - Building resource auth/PROJECT_NAME08a93afb
2023-04-11T13:32:42.840Z [WARNING]: ✔ Initialized provider successfully.
2023-04-11T13:32:43.226Z [WARNING]: - Building resource api/PROJECT_NAME
2023-04-11T13:32:48.398Z [INFO]: ⚠ WARNING: owners may reassign ownership for the following model(s) and role(s): STACK444: [userId], STACK44: [userId], STACK11: [userId], STACK222: [userId], STACK22: [userId], STACK888: [userId], STACK1234: [userId], STACK333: [userId], STACK555: [userId], STACK33: [userId], STACK111: [userId], STACK999: [userId], STACK999: [userId]. If this is not intentional, you may want to apply field-level authorization rules to these fields. To read more: https://docs.amplify.aws/cli/graphql/authorization-rules/#per-user--owner-based-data-access.
2023-04-11T13:32:49.488Z [INFO]: ✅ GraphQL schema compiled successfully.
                                 Edit your schema at /codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema.graphql or place .graphql files in a directory at /codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema
2023-04-11T13:32:49.489Z [WARNING]: - Building resource auth/PROJECT_NAME08a93afb
2023-04-11T13:32:49.533Z [WARNING]: - Uploading files.
2023-04-11T13:32:56.409Z [INFO]:
2023-04-11T13:32:56.411Z [INFO]: UPDATE_IN_PROGRESS amplify-PROJECT_NAME-dev-93613 AWS::CloudFormation::Stack Tue Apr 11 2023 13:32:51 GMT+0000 (Coordinated Universal Time) User Initiated
                                 UPDATE_IN_PROGRESS apiPROJECT_NAME                AWS::CloudFormation::Stack Tue Apr 11 2023 13:32:54 GMT+0000 (Coordinated Universal Time)
2023-04-11T13:32:56.520Z [INFO]:
2023-04-11T13:32:56.521Z [INFO]: UPDATE_IN_PROGRESS amplify-PROJECT_NAME-dev-93613-apiPROJECT_NAME-161N6H7CWG4VG AWS::CloudFormation::Stack Tue Apr 11 2023 13:32:55 GMT+0000 (Coordinated Universal Time) User Initiated
2023-04-11T13:33:11.459Z [INFO]:
2023-04-11T13:33:11.465Z [INFO]: UPDATE_IN_PROGRESS STACK444                           AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:01 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS GraphQLAPIDefaultApiKey215A6DD7 AWS::AppSync::ApiKey       Tue Apr 11 2023 13:33:01 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK444                           AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:02 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    GraphQLAPIDefaultApiKey215A6DD7 AWS::AppSync::ApiKey       Tue Apr 11 2023 13:33:03 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK333                          AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:05 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK222                    AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:05 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK55                          AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:05 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK44                         AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:05 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK333                          AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:06 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK222                    AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:06 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK55                          AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:06 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK44                         AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:06 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK111                   AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK999                     AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK999                            AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK1234                     AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK888                      AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK555               AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK777             AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK33                         AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK22                      AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK111                   AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK999                            AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:08 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK1234                     AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK999                     AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK555               AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK33                         AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK777             AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK888                      AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_IN_PROGRESS STACK11                AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK22                      AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE    STACK11                AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:09 GMT+0000 (Coordinated Universal Time)
2023-04-11T13:33:31.419Z [INFO]:
2023-04-11T13:33:31.421Z [INFO]: UPDATE_COMPLETE                     apiPROJECT_NAME                AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:16 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE_CLEANUP_IN_PROGRESS amplify-PROJECT_NAME-dev-93613 AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:18 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE                     apiPROJECT_NAME                AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:29 GMT+0000 (Coordinated Universal Time)
                                 UPDATE_COMPLETE                     amplify-PROJECT_NAME-dev-93613 AWS::CloudFormation::Stack Tue Apr 11 2023 13:33:29 GMT+0000 (Coordinated Universal Time)
2023-04-11T13:33:51.453Z [INFO]:
2023-04-11T13:33:51.730Z [INFO]:
2023-04-11T13:33:51.781Z [INFO]:
2023-04-11T13:33:51.831Z [INFO]:
2023-04-11T13:33:51.883Z [INFO]:
2023-04-11T13:33:51.932Z [INFO]:
2023-04-11T13:33:51.933Z [INFO]:
2023-04-11T13:33:51.982Z [INFO]:
2023-04-11T13:33:52.075Z [INFO]:
2023-04-11T13:33:52.076Z [INFO]:
2023-04-11T13:33:52.097Z [WARNING]: - Uploading files.
2023-04-11T13:33:52.126Z [INFO]:
2023-04-11T13:33:52.177Z [INFO]:
2023-04-11T13:33:52.227Z [INFO]:
2023-04-11T13:33:52.277Z [INFO]:
2023-04-11T13:33:52.328Z [INFO]:
2023-04-11T13:33:52.379Z [INFO]:
2023-04-11T13:33:52.379Z [INFO]:
2023-04-11T13:33:52.429Z [INFO]:
2023-04-11T13:33:52.429Z [INFO]:
2023-04-11T13:33:52.479Z [INFO]:
2023-04-11T13:33:52.528Z [INFO]:
2023-04-11T13:33:52.529Z [INFO]:
2023-04-11T13:33:59.249Z [INFO]:
2023-04-11T13:33:59.300Z [INFO]:
2023-04-11T13:33:59.322Z [INFO]:
2023-04-11T13:33:59.323Z [INFO]:
2023-04-11T13:33:59.324Z [WARNING]: - Uploading files.
2023-04-11T13:33:59.375Z [WARNING]: - Uploading files.
2023-04-11T13:34:02.749Z [INFO]: 🛑 ENOENT: no such file or directory, open '/codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema.graphql'
2023-04-11T13:34:02.751Z [INFO]: Resolution: Please report this issue at https://github.com/aws-amplify/amplify-cli/issues and include the project identifier from: 'amplify diagnose --send-report'
                                 Learn more at: https://docs.amplify.aws/cli/project/troubleshooting/
2023-04-11T13:34:02.754Z [WARNING]: ✖ There was an error initializing your environment.
2023-04-11T13:34:02.755Z [INFO]: 🛑 ENOENT: no such file or directory, stat '/codebuild/output/src636864984/src/PROJECT_NAME.amplify/amplify/backend/api/PROJECT_NAME/schema.graphql'
2023-04-11T13:34:02.755Z [INFO]: Learn more at: https://docs.amplify.aws/cli/project/troubleshooting/
2023-04-11T13:34:02.788Z [INFO]:
2023-04-11T13:34:02.788Z [INFO]: Session Identifier: ff026a73-a485-4aab-ac40-f5c818603d3d
2023-04-11T13:34:02.789Z [WARNING]: - Creating Zip
2023-04-11T13:34:02.801Z [INFO]:
2023-04-11T13:34:02.801Z [INFO]: Session Identifier: ff026a73-a485-4aab-ac40-f5c818603d3d
2023-04-11T13:34:02.802Z [WARNING]: - Creating Zip
2023-04-11T13:34:02.852Z [INFO]: ✅ Report saved: /tmp/PROJECT_NAME/report-1681220042794.zip
2023-04-11T13:34:02.853Z [WARNING]: - Sending zip
2023-04-11T13:34:02.856Z [INFO]:
2023-04-11T13:34:02.856Z [INFO]: ✅ Report saved: /tmp/PROJECT_NAME/report-1681220042806.zip
2023-04-11T13:34:02.857Z [WARNING]: - Sending zip
2023-04-11T13:34:04.144Z [WARNING]: ✔ Done
2023-04-11T13:34:04.144Z [INFO]: Project Identifier: a29d368eaf2a6564bacb4612a2319724
2023-04-11T13:34:04.166Z [ERROR]: !!! Build failed
2023-04-11T13:34:04.167Z [ERROR]: !!! Non-Zero Exit Code detected
2023-04-11T13:34:04.167Z [INFO]: # Starting environment caching...
2023-04-11T13:34:04.167Z [INFO]: # Uploading environment cache artifact...
2023-04-11T13:34:04.237Z [INFO]: # Uploaded environment cache artifact
2023-04-11T13:34:04.237Z [INFO]: # Environment caching completed
Terminating logging...

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Hey @francoisharmse777 :wave: thanks for raising this! Can you confirm what version of the CLI you are using in Amplify Hosting to produce a successful build? We have a few reports of this issue where folks are using multiple schema files
https://github.com/aws-amplify/amplify-category-api/issues/1074
https://github.com/aws-amplify/amplify-category-api/issues/1385

hi @josefaidt
versions 10.5.2 and 11.0.3 works fine.

when using amplify cli = latest version today - it now uses version 11.0.3
we noticed that v 11.0.4 had been marked as a "pre release"

Hey @francoisharmse777 thanks for clarifying! Yes, 11.0.4 was deprecated due to a codegen issue. I'll transfer and close this due to the deprecation of 11.0.4, though we will keep this in mind for further enhancements.


Simhub crashes when I install wled plugin

I wanted to use this, but when I install this plugin for the first time simhub crashes. I think its due to the other issue talking about not connecting to a wled device, but how can I configure it without opening simhub?

you can just press okay when the error pops up when you start simhub, then configure the correct url and restart simhub, i will fix this when i have some spare time


typo in _getColor-function.scss

Based upon the colors specified in globals/_settings.scss, the following correction should be made to globals/_getColor-function.scss
--  @function getColor($color, $value: "base") {
++ @function getColor($color: "base", $value: "primary") {
  @return map-get(map-get($colors, $color), $value);
}

Is there any problem with the current function? I can't find any issue.
I think using primary would be better and also add a default value for $color but that would be a breaking change because I would have to change the name of the following colors, where base is used instead of primary.
red: (
    "darker":  #653131,
    "dark":    #b73333,
    "base":    #da3c3c,
    "light":   #f25a5a,
    "lighter": #fa8181
  ),

I think some improvements could be made here but perhaps for a next major version. So I'll leave this open for the future. But let me know if you think there is a mistake here!


[Sema] Add "unused result" warning for #selector.

What's in this pull request?
We now have a nice warning when a selector is unused:
import Foundation
func test() {
warning: result of '#selector' is unused
  #selector(NSObject.copy)
  ^~~~~~~~~~~~~~~~~~~~~~~~
}

Resolved bug number: (SR-1022)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Awesome, thank you for working on this, one micro comment for you on the patch.

Fixed.

@swift-ci smoke test and merge

@swift-ci test and merge

I think the test failures are unrelated.


ThemeServiceProvider not found

Describe the bug
I have installed larecipe 2.0. Created a theme called "dark" and then delete it. Then i run composer dumpautoload and got this issue.
To Reproduce
Steps to reproduce the behavior:

Install larecipe 2.0
Create a new theme called "dark" y root folder (just for demo purpose)
Remove the created theme
Run composer dumpautoload, then i get "Vendor\Dark\ThemeServiceProvider not found"

Expected behavior
Running dumpautoload after deleted a theme should not throw an error.
Screenshots

Desktop (please complete the following information):

OS: Ubuntu 16.04
Browser: latest chrome

My composer.json file is:
{
    "name": "laravel/laravel",
    "type": "project",
    "description": "The Laravel Framework.",
    "keywords": [
        "framework",
        "laravel"
    ],
    "license": "MIT",
    "require": {
        "php": "^7.1.3",
        "binarytorch/larecipe": "^2.0",
        "fideloper/proxy": "^4.0",
        "laravel/framework": "5.8.*",
        "laravel/tinker": "^1.0"
    },
    "require-dev": {
        "beyondcode/laravel-dump-server": "^1.0",
        "filp/whoops": "^2.0",
        "fzaninotto/faker": "^1.4",
        "mockery/mockery": "^1.0",
        "nunomaduro/collision": "^3.0",
        "phpunit/phpunit": "^7.5"
    },
    "config": {
        "optimize-autoloader": true,
        "preferred-install": "dist",
        "sort-packages": true
    },
    "extra": {
        "laravel": {
            "dont-discover": []
        }
    },
    "autoload": {
        "psr-4": {
            "App\\": "app/"
        },
        "classmap": [
            "database/seeds",
            "database/factories"
        ]
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi"
        ]
    }
}

Solved it. Just needed to run composer update, and then dumpautoload.


Use kroki to create svg

Using only mermaid will cause large white boxes around the diagram. Using Korki to pre-create a mermaid image helps to avoid this.

Jenkins please retry a build


refactor readiness of mixer CRD store

readiness now means all of the resources are 'HasSynced'. I believe this reflects the readiness status of the store more properly.

@jmuk: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
dd77eb8d41be12e5475c4095c52f2fb6b65c0cc2
link
/test e2e-smoke

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@jmuk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
dd77eb8d41be12e5475c4095c52f2fb6b65c0cc2
link
/test e2e-smoke

prow/istio-pilot-e2e.sh
dd77eb8d41be12e5475c4095c52f2fb6b65c0cc2
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/assign @mandarjog

@mandarjog please review this

@jmuk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
dd77eb8d41be12e5475c4095c52f2fb6b65c0cc2
link
/test e2e-smoke

prow/istio-pilot-e2e.sh
424748415add7845422488b1fdf3f2fa0dab1c41
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test istio-pilot-e2e

@jmuk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-smoke.sh
dd77eb8d41be12e5475c4095c52f2fb6b65c0cc2
link
/test e2e-smoke

prow/istio-pilot-e2e.sh
424748415add7845422488b1fdf3f2fa0dab1c41
link
/test istio-pilot-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

When a new CRD is created the behaviour here would be to cause a intermediate outage, as the new CRD will not be "synced".
The behaviour should be
On start

synchronously attempt to create informers for as many kinds as are discoverable thru the cfg discovery api
wait for those informers to sync to declare "readiness"

For the CRDs that remain

discover it using the API, and start a timer. A new CRD has say a minute or two (configurable) to sync.
If it does not sync in time, then you may declare not-ready.

The subsequent re-sync period should be large enough to not cause outages.
Question:

What ensures that that the informers that were in sync initially remain so on an ongoing basis?

done, PTAL

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
Assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

mixer/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Privileged authorization mechanisms unstable on Big Sur.

As of Betas 3 and 4 of macOS Big Sur, crypt is unstable and should not be used. We are currently experiencing issues with using privileged authorization mechanisms at login and have filed Feedbacks accordingly.
Please follow the steps in the Wiki for troubleshooting logins if you have a Beta3,4 machine that is not able to log in.

Per the B6 release notes
(Beta 6) User login at the Login Window now completes when using certain types of Authorization plugins.

Please try crypt v4 on Big Sur and report back.

Appears to be stable in B6-B8


Create version_example.ts

Description
Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context.
Type of change

[ ] 💔 Breaking
[ ] 🚀 Feature
[ ] 🐛 Fix
[ ] 🛠 Tooling
[ ] 🧪 Test
[ ] 📦 Dependency
[ ] 📖 Requires documentation update

@load1n9 could you please include a description of the changes? Thanks!

Ofc course, just added an examples folder with an example to make this directory more user friendly


Update to latest SDK version (10.0.14393.0)

Is it possible to update mapping to SDK version 10.0.14393.0 which came with latest VS update and release a nuget package?

Is there anything worthwhile new?

Yeah, I think so.
Here is link on MSDN, where describes new features of the latest Windows SDK after update WIn 10 to the version 1607:
https://msdn.microsoft.com/library/windows/desktop/mt748631(v=vs.85).aspx
So, maybe it is worth to update to the latest SDK version.

Could you try a PR for that?

Unfortunately I am not familiar with all that mapping stuff and don`t know how it works. So, I am afraid I could not upgrade to new SDK version correctly.
Maybe this could be done by someone who is more experienced in this question?

I will try to update this and send PR back.

Just submitted PR, see #815

Thanks a lot!!!


Apple podcasts broken

Checklist

[X] I'm reporting a broken site
[X] I've verified that I'm running yt-dlp version 2021.12.01. (update instructions)
[X] I've checked that all provided URLs are alive and playable in a browser
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
UK
Description
Apple podcasts seems to be not working either for individual episodes or as at podcast (channel) level. Attached is the verbose log for an individual episode but yt-dlp does not work for the podcast at channel level on https://podcasts.apple.com/us/podcast/up-first/id1222114325.
Verbose log
[debug] Command-line config: ['--verbose', 'https://podcasts.apple.com/us/podcast/monday-december-13-2021/id1222114325?i=1000544795004']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, err utf-8, pref UTF-8
[debug] yt-dlp version 2021.12.01 [91f071af6] (zip)
[debug] Python version 3.9.6 (CPython 64bit) - Linux-5.11.0-38-generic-x86_64-with-glibc2.33
[debug] exe versions: ffmpeg 4.3.2-0, ffprobe 4.3.2-0
[debug] Optional libraries: sqlite
[debug] Proxy map: {}
[debug] [ApplePodcasts] Extracting URL: https://podcasts.apple.com/us/podcast/monday-december-13-2021/id1222114325?i=1000544795004
[ApplePodcasts]<PHONE_NUMBER>004: Downloading webpage
ERROR: [ApplePodcasts]<PHONE_NUMBER>004: Unable to extract ember data; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/common.py", line 597, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/applepodcasts.py", line 42, in _real_extract
    ember_data = self._parse_json(self._search_regex(
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/common.py", line 1171, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
yt_dlp.utils.RegexNotFoundError: Unable to extract ember data; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/common.py", line 597, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/applepodcasts.py", line 42, in _real_extract
    ember_data = self._parse_json(self._search_regex(
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/common.py", line 1171, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
yt_dlp.utils.RegexNotFoundError: Unable to extract ember data; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/yt-dlp/yt_dlp/YoutubeDL.py", line 1329, in wrapper
    return func(self, *args, **kwargs)
  File "/usr/local/bin/yt-dlp/yt_dlp/YoutubeDL.py", line 1398, in __extract_info
    ie_result = ie.extract(url)
  File "/usr/local/bin/yt-dlp/yt_dlp/extractor/common.py", line 623, in extract
    raise type(e)(e.msg, **kwargs)
yt_dlp.utils.RegexNotFoundError: [ApplePodcasts]<PHONE_NUMBER>004: Unable to extract ember data; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.; please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output

Any idea when this will be fixed?
Looks like the Fix has been sitting in youtube-dl for weeks. waiting for the pull request.
https://github.com/ytdl-org/youtube-dl/pull/30340

Seems to be merged now: https://github.com/ytdl-org/youtube-dl/commit/584715a803eef68f68fbbb8b72a022a699983197

I'll port it before next release

50e93e03a7ca6ae35a319ea310104f7d6d91eee3

@fidodido48 open a new issue please


Parametrize hostname/domain

Currently hard-coded, which does not work for anyone except me...

https://pypi.org/project/podme-api/


Use @unocss/cli(which version greate 0.61.0) generate wrong css code

UnoCSS version
> 0.61.0
Describe the bug
when I use cli generate css，but i found some class not valid, and I find some error in generate css.
And this issue occur when version > 0.61.0 , 0.61.0 is ok!

Reproduction
https://github.com/chenweiyi/unocss-demo-bug
System Info
System: Macos Big Sur 11.7.4
Browser: MS Edge 126.0.2592.113
Frame: unocss react
Validations

[X] Read the Contributing Guidelines.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

similar to #3930


suppressSingle hides dropdown when only 1 option

Suppress the dropdown when there is only one option to be shown, whether that is a known option, or the option_create control.

Coverage remained the same at 82.91% when pulling 352f1c4f538bbd6a861677650e3caebc4a7d2a18 on duncanbeevers:suppress-single into 9ac1f557649c5de9e1c005be317e94c253754da5 on brianreavis:master.

Coverage decreased (-0.28%) to 82.91% when pulling c18c67543fca1ac628762764f5640921d48a1d75 on duncanbeevers:suppress-single into cff8cd3b76559bf8e5ce14254d07e719445034c1 on brianreavis:master.

Coverage decreased (-0.28%) to 82.91% when pulling c18c67543fca1ac628762764f5640921d48a1d75 on duncanbeevers:suppress-single into cff8cd3b76559bf8e5ce14254d07e719445034c1 on brianreavis:master.

Coverage decreased (-0.98%) to 82.2% when pulling f3c555c61236503069abd5ebd513684d112328b3 on duncanbeevers:suppress-single into cff8cd3b76559bf8e5ce14254d07e719445034c1 on brianreavis:master.

Coverage decreased (-0.28%) to 82.91% when pulling 92dee4d9534c1043b696ca262cff4c8659fc5b88 on duncanbeevers:suppress-single into cff8cd3b76559bf8e5ce14254d07e719445034c1 on brianreavis:master.


Rendering issue on the landing page

I see this (in Chrome):

Closing curly braces probably shouldn't be there.

Good catch. The text is also outdated, e.g.
Moran & Blasi, Cross-linguistic comparison of complexity measures in phonological systems, forthcoming
is published and this is a more suitable URL for pointing to published research that uses phoible:
https://scholar.google.com/scholar?oi=bibs&hl=en&cites=576981116309388928&as_sdt=5
Also on our list is to make a link to the FAQ for users:
http://phoible.github.io/faq/

Good catch. The text is also outdated, e.g.
Moran & Blasi, Cross-linguistic comparison of complexity measures in phonological systems, forthcoming
is published and this is a more suitable URL for pointing to published research that uses phoible:
https://scholar.google.com/scholar?oi=bibs&hl=en&cites=576981116309388928&as_sdt=5
Also on our list is to make a link to the FAQ for users:
http://phoible.github.io/faq/

Problem is caused by the bibtex formatting here https://github.com/clld/phoible/blob/9539cacc5d50343cc03a9e2788c1b60956275db5/phoible/scripts/util.py#L102

Problem is caused by the bibtex formatting here https://github.com/clld/phoible/blob/9539cacc5d50343cc03a9e2788c1b60956275db5/phoible/scripts/util.py#L102

Hmm, I think it's the missing comma here:
https://github.com/clld/phoible/blob/9539cacc5d50343cc03a9e2788c1b60956275db5/phoible/scripts/util.py#L84
and = jan is probably also bad.

Hmm, I think it's the missing comma here:
https://github.com/clld/phoible/blob/9539cacc5d50343cc03a9e2788c1b60956275db5/phoible/scripts/util.py#L84
and = jan is probably also bad.


Evaluation code

Hi, thanks for the great work!
I wanted to ask, could you please show how did you evaluate ID-Pose on the datasets in the paper? More precisely, how did you convert (elevation, azimuth, radius) predictions to rotation matrices?
Thank you!

Hi, sorry to reopen the issue, I tried to do as you said to me, however, if I do the check for the same pose, i.e. c2w_to_elu -> elu_to_c2w I get errors that are always close to ~180 degrees. Did you ever encounter any of those issues?
Thanks!


Make lists of recordedByID or identifiedByID values that did not make the cut

A number of data providers to GBIF are making use of identifiedByID and recordedByID and several use identifiers like VIAF, ISNI, HUH or other. When these are discovered, they are queried in wikidata to find a Q number. On occasion however, these items do not have birth or death dates and so the attributions are not drawn-in. It would help if we could see which of these are missing birth/death dates, included in wikidata, so that the attributions can be properly shown.

Also included here are instances where the ORCID checksum does not validate, which indicates a problem in how identifiers were used/linked in source CMS. So, also include lists of invalid ORCID IDs.

Also included here are instances where the ORCID checksum does not validate, which indicates a problem in how identifiers were used/linked in source CMS. So, also include lists of invalid ORCID IDs.


Quick Script, Ubuntu 20.04 LTS not supported

Deployment Method

[X] Installer
[ ] Docker Development
[ ] Docker Production
[ ] Bare metal Development
[ ] Bare metal Production

Describe the problem*
Trying to install following https://docs.inventree.org/en/latest/start/installer/
Does seem that I got 20.04.05 LTS when looking at "About" screen
Steps to Reproduce
Install Ubuntu 20.04 LTS
In terminal: wget -Nq https://raw.githubusercontent.com/InvenTree/InvenTree/master/contrib/install.sh && bash install.sh
Relevant log output
inven@inven-ThinkCentre-M91p:~$ wget -Nq https://raw.githubusercontent.com/InvenTree/InvenTree/master/contrib/install.sh && bash install.sh
Installer for InvenTree - source: inventree/stable
Detected distribution: Ubuntu 20.04
This OS is currently not supported
please install manually using https://inventree.readthedocs.io/en/stable/start/install/
or check https://github.com/inventree/InvenTree/issues/3836 for packaging for your OS.
If you think this is a bug please file an issue at
https://github.com/inventree/InvenTree/issues/new?template=install.yaml

inven@inven-ThinkCentre-M91p:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.5 LTS
Release:	20.04
Codename:	focal

I've also tried the server version, with same result.
Should I just go for the Docker install?
Or is there hope that this issue will get resolved?

@martin323232 I am working on it - this a free-time project so pls do not expect 24hrs return times

@martin323232 what is your installer showing on a dry run (using bash installer.sh -d)?

@matmair
did not mean it like that. Just wanted start using Inventree.
Switched to Docker on ubuntu and installed it there.
I'll can give it another try on monday.

@martin323232 maybe try also this command, a PR merging this into master is open.
wget -Nq https://raw.githubusercontent.com/matmair/InvenTree/matmair/issue3933/contrib/install.sh && sudo bash install.sh master matmair

@martin323232 the fix was merged so this should work now:
wget -Nq https://raw.githubusercontent.com/inventree/InvenTree/master/contrib/install.sh && sudo bash install.sh master

@matmair
it's working now. but the documentation is not good enough for someone not used to using Linux.
I'll switch back to using docker on windows


Eternal Blue vulnerability

Just a quick question: does this vulnerable to Eternal Blue or Wanna Cry ransomware?

No, it cannot download software.


Adds pagination to collection assets listing and collection

This uses the offset properties of the BCD API to paginate the collection listing. Also fetches all the available collections on load, removing the current limit of 10 collection, as well 10 assets of a collection.
#239 is also fixed with this changes

This is great and working so far on my build (general) - would it be possible to put a spinner or loading indicator to show that it's in the process of pulling more data?

Bug: I am not able to see any tokens in the minter featured collection:

Bug: Only see 10 last added items in a collection:

In relation to the bug on this PR reported by @ricklove I will re-iterate what I stated in Slack earlier...
This PR does not work for me either. It doesn’t pull back all the big map entries. I can’t see my NFTs with it. It also doesn’t load the Minter NFTs on page load. And does some "on scroll" load more mechanic. Which wasn’t what this PR was supposed to be. In hindsight I should have done a better job explaining what we needed. I have updated the BCD code in the marketplace PR (#280) to pull all big map items which effectively resolves what the main goal of this PR was supposed to do.
Since PR #280 solves the main goal of what this PR was meant to do, I’d like to hold this one for now and revisit later. I think there is some useful stuff in here, but there’s also some stuff not needed and some stuff not working right. When things settle a bit, I will gather my thoughts on what those useful pieces are that I think we should pull out of here.


Async consumption / transaction finalization

In short
I believe it makes sense to add a new method to PurchaseManager, which has to be called by the application to mark the transaction as handled (instead of marking it automatically).
Motivation
Currently a PurchaseManager handles successful purchase in the following way:

It calls PurchaseObserver.handlePurchase
It marks transaction as completed (iOS) or consumes inapp (Google Play)

The step 2 is performed in the same thread as the step 1. In particular it also means, that if the step 1 is failed (application code), then the transaction is not marked as completed (which is the right behaviour).
The problem appears, when PurchaseObserver.handlePurchase is written in asynchronous way: to apply transaction the application needs to perform some long running operation (e.g. call to a database). In this case the only option is too trigger async operation and block the thread, which has 2 downsides:

The thread by itself can be a main thread (not sure though), so that could make the app unresponsive
That makes implementation of PurchaseObserver.handlePurchase not so convenient.

Proposal

Add new PurchaseManager.purchaseHandled(transaction) method (maybe you have better ideas for the name), which has be to called by the application code, once the purchase is successfully handled on the apps side.
For iOS PurchaseManager.purchaseHandled will call SKPaymentQueue.getDefaultQueue().finishTransaction (on the main thread)
For Android PurchaseManager.purchaseHandled will call mBillingClient.consumeAsync for CONSUMABLE purchases (on the main thread)
Add Transaction.systemTransaction (or systemObject) field to store underlaying system transaction object.
Remove finalisation of transactions from the current places.

The alternative to step 5 would be to add an option to PurchaseManagerConfig or an argument to PurchaseManager.install, something like: "boolean automaticTransactionFinalisation".
What do you think?

I think you are right that the current handling could be improved. My remarks:

Amazon implementation must be changed, too
I think for remaining compatible to older versions and keep the complexity low for most games, handlePurchase should return a boolean value. If it returns true, the purchase is consumed/finished. If it is false (or an exception is thrown), it is not and handlePurchase must be called manually.
For this change, it would be good to update to Google Billing 2.0 and implement pending purchases which affects entitlements in a similar way.

You are making an interesting point.

if the handlePurchase method is indeed being called on the main thread, we potentially block the UI which is no good. Can we verify if this is really the case?
if it is not being called from the main thread, @MrStahlfelge's response is a lot more straightforward and easy to implement. I would just said we require an exception to be thrown within that method to prevent a purchase from being consumed. Sending the package to the server won't be a problem if it's outside the main thread, even if it takes a little while.
if it is being called on the main thread, we still use the same method as described in 2., but we internally make it so we call handlePurchase outside the main thread and handle it internally.

I think the goal is to make it easy for developers. It should be us that move things off the main thread as needed.

mBillingClient.consumeAsync does not block the thread, it makes no difference on which thread it is called. Can't say something for iOS as I am not that familiar on how it works. Based on my impressions when using gdx-pay on iOS, It does not feel as if it blocks the main thread.

We have to keep in mind, that users may assume (and it is actually convenient in most of the cases), that PurchaseObserver.handlePurchase is called on the LibGDX main thread (by the way it differs from the main thread on Android as far as remember), so they are free to modify any UI related object without conflicts.
Thus we come back to the original issue and it is not important, which thread is used by the OS.

handlePurchase should not be called using the libGDX main thread. Otherwise, sending the data to a server would block the UI as you correctly mentioned.

@alex-dorokhov Maybe my message(s) are coming over a little hard? This isn't a criticism of your solution. Your solution is perfectly fine. The same goes with the existing solution which is simply a different way of going about things. It's a matter of taste and question of if we really want to change everything up for all the existing users?
Based on gdx-pay-example's MyFancyInAppShop.java, a developer has to assume the handlePurchase or handleRestore methods are called outside the main thread. Changing it to the main thread will cause problems, e.g. ANRs for developers who do server-side verification/other longer-running processes for purchase verification.

@noblemaster, it's my fail, I thought it is called in the main thread in the current implementation.
Then you are right, we have to double check every implementation if the method is not called in the libGDX loop and not in a main loop of a platform UI. Maybe it makes sense to create a thread in the library anyway to be safe from future platform and libGDX changes.
About your second point:

if it is not being called from the main thread, @MrStahlfelge's response is a lot more straightforward and easy to implement. I would just said we require an exception to be thrown within that method to prevent a purchase from being consumed. Sending the package to the server won't be a problem if it's outside the main thread, even if it takes a little while.

I also like the solution by @MrStahlfelge, and I would apply it as it was originally suggested by him. Using a library should be both straightforward in async and sync style, so returning a boolean is better. Throwing an exception looks a bit "hacky" (IMHO).
The last sentence makes me think that you suggest to keep only the sync way of doing the things:

Sending the package to the server won't be a problem if it's outside the main thread, even if it takes a little while.

First of all, what you suggest with the exception, is currently implemented in the library. The purchase is not consumed if "handlePurchase" throws an exception. But the original issue is not only about blocking the calling thread, but also about convenience of implementation. Especially, when the code inside "handlePurchase" calls external async code.
Let me show you an example, where the "async" implementation is easier than the "sync" one. To simplify, I'm using the interface suggested by @MrStahlfelge.
Example. Using of Gdx.net.sendHttpRequest to send transaction info to the server.
The async way:
class AsyncExample implements PurchaseObserver {
    PurchaseManager purchaseManager;

    @Override
    public boolean handlePurchase(final Transaction transaction) {
        Gdx.net.sendHttpRequest(new Net.HttpRequest("https://server.com/purchase"), new Net.HttpResponseListener() {
            @Override
            public void handleHttpResponse(Net.HttpResponse httpResponse) {
                if (httpResponse.getStatus().getStatusCode() == HttpStatus.SC_ACCEPTED) {
                    purchaseManager.purchaseHandled(transaction);
                } else {
                    //TODO handle failure
                }
            }

            @Override
            public void failed(Throwable t) {
                //TODO handle failure
            }

            @Override
            public void cancelled() {
            }
        });

        return false;
    }
}

The sync way:
class SyncExample implements PurchaseObserver {
    PurchaseManager purchaseManager;

    @Override
    public boolean handlePurchase(final Transaction transaction) {
        final AtomicBoolean result = new AtomicBoolean(false);

        synchronized (result) {
            Gdx.net.sendHttpRequest(new Net.HttpRequest("https://server.com/purchase"), new Net.HttpResponseListener() {
                @Override
                public void handleHttpResponse(Net.HttpResponse httpResponse) {
                    if (httpResponse.getStatus().getStatusCode() == HttpStatus.SC_ACCEPTED) {
                        synchronized (result) {
                            result.set(true);
                            result.notify();
                        }
                    } else {
                        synchronized (result) {
                            result.set(false);
                            result.notify();
                        }
                    }
                }

                @Override
                public void failed(Throwable t) {
                    //TODO handle failure
                }

                @Override
                public void cancelled() {
                }
            });

            try {
                result.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

        return result.get();
    }
}

As you can see, the first solution is much easier to implement, because the user is not forced to use locks to convert async code (in this case Gdx.net, based on callbacks) to sync (gdx-pay).
In my personal case things go even harder, because it is not only required to send request to the server and wait for response, but additionally update the database (which happens in separate DB-thread).

Using a library should be both straightforward in async and sync style, so returning a boolean is better.

I agree, a boolean is the way to go I think. It's less hacky!
I also agree that the async way is what we should do. They synchronized(...) block won't work on the HTML backend anyway.
It's a little odd to always return false when sending the data to the server. On the other hand, it won't be a problem as the server can just ignore duplicate order IDs. That way, consumables also just don't disappear when they are consumed. It's safer to make sure people will always be able to restore their purchase, incl. consumable purchases in case the database would have to be restored. That way the purchases still appear (return true would not send them anymore when an order is restored).


CartPole-v0 reward above 200.

I understand that there is a Running Mean and Running Std Dev calculation and all that. But that doesn't tell me why the mean/median reward goes above 200, if the history of observations after done is regularly cleaned.

Not exactly sure what you are getting at but in addition to the running mean and standard deviation the raw episode returns of each environment are saved with the baselines bench.Monitor helper. The corresponding directory is the --log-dir command line argument.

When you run the main.py file the reward for CartPole-v0 shouldn't go above 200. By reward I mean the mean/median reward and min/max reward which is printed on the terminal. Although this might not be the real reward it still shouldn't go above 200 because observations are supposed to be cleaned after every 200 time steps.

Yes, the mean/median and min/max rewards are based on the final_rewards which are processed by the VecNormalize wrapper. The normalisation includes a division by the running standard deviation (variance) which can be quite small in the beginning and therefore results in large processed rewards. See also my question in the OpenAI baselins repository https://github.com/openai/baselines/issues/266
If you want to observe the real raw rewards you should work with Visdom and the visdom_plot  function of this repository.

Ahh, I forgot about the division with standard deviation. Makes sense now, thanks!


Remove some verbs from xenos

About the PR

Removed some verbs from xenos
Xenos can no longer:

light flares
remove webbings
toggle weapon attachables
toggle internals
attempt to pray
see or change gun fire modes
--- list incomplete, will update once I manage to find more ---

Why / Balance

Feel like most of these are unintentional
Resolves #3848, resolves #3202
Technical details

Added checks for XenoComponent in various GetVerbsEvent handlers
Media

Requirements

[x] I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl:

fix: Xenos can no longer light flares on ground.
fix: Xenos can no longer remove webbings from jumpsuits.
fix: Xenos can no longer toggle attachables or internals.
fix: Xenos can no longer (attempt to) pray.
fix: Xenos can no longer see or change gun fire modes.

why can't xenos pray man! let us contant our xeno gods!!


Support for binary will and important bug in handling PUBLISH messages

This adds support for sending binary (arbitrary) wills (e.g. for Sparkplug death certificates) and fixes a very important bug which broke responses to PUBLISH messages with QOS2. Have a look into the commit messages for more details.
The binary will implementation in 095b2bd8b6cd6944c331b962e133fa8c9b921660 may not actually be ideal. Perhaps it's better to break the API and rename will_message (see commit message for a discussion). What do you think?

Ping @zhaojh329. Any chance to merge?

Thanks!


adonis new yardstick --api-only not work

when i use this command in terminal  this error occurred

error: unknown option `--api-only'

Can you share the complete command and how did you installed the CLI?

adonis new test --api-only

error: unknown option `--api-only'

You are using a way older cli
Install it as
npm i -g @adonisjs/cli

tnx


Sm sailing

This adds in coffee-script so that the cake command is available automatically.

@devinus thoughts on this approach?

I'm thinking that until https://github.com/sailthru/sailthru-node-client is updated (which can be awhile) we keep our fork and just commit the compiled assets.

I'll do that now.


Finalize compatibility with objective-c

Related to: https://github.com/orgs/muxinc/projects/32/views/2?pane=issue&itemId=34679875

Testing something out with issues/projects


9.2.0 Posts a comment with error 403

Steps to reproduce
import { ClientType, Innertube } from 'youtubei.js';
async function start() {
const yt = await Innertube.create(
{
client_type: ClientType.WEB,
cookie: "my browser cookie..."
}
);
const vid = 'ZiplxPdOJd4';
const com = await yt.interact.comment(vid, 'GOOD');
console.log(com.data);

}
start();
Failure Logs
node_modules/youtubei.js/dist/src/utils/HTTPClient.js:101
            throw new InnertubeError(`Request to ${response.url} failed with status ${response.status}`, yield response.text());
                  ^

InnertubeError: Request to https://www.youtube.com/youtubei/v1/comment/create_comment?prettyPrint=false&alt=json failed with status 403
    at HTTPClient.<anonymous> (node_modules/youtubei.js/dist/src/utils/HTTPClient.js:101:19)
    at Generator.next (<anonymous>)
    at fulfilled (node_modules\tslib\tslib.js:166:62)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  info: '{\n' +
    '  "error": {\n' +
    '    "code": 403,\n' +
    '    "message": "Comment failed to post.",\n' +
    '    "status": "PERMISSION_DENIED"\n' +
    '  }\n' +
    '}\n',
  date: 2024-04-10T12:53:30.800Z,
  version: '9.2.0'
}

Node.js v18.16.0

Expected behavior
Send a comment and get the result.
Current behavior
Not sending the comment while other functions like getHomeFeed works fine.
Version
Default
Anything else?
No response
Checklist

[X] I am running the latest version.
[X] I checked the documentation and found no answer.
[X] I have searched the existing issues and made sure this is not a duplicate.
[X] I have provided sufficient information.

Works fine here, but I'm using OAuth. I do not recommend cookies because Google rotates them every 15 minutes or so.
Also, you do not need the client_type param. The WEB client is used by default in most cases.

import { ClientType, Innertube, UniversalCache } from 'youtubei.js';
async function start() {
const vid = 'ZiplxPdOJd4';
const yt = await Innertube.create(
{
cache: new UniversalCache(true),
generate_session_locally: true,
client_type: ClientType.ANDROID,
}
);
yt.session.on('auth-pending', (data) => {
    console.log(`Go to ${data.verification_url} in your browser and enter code ${data.user_code} to authenticate.`);
});

await yt.session.signIn();
await yt.session.oauth.cacheCredentials();
console.log((await yt.getHomeFeed()).contents.contents.length);

}
When I use OAuth there is no problem with ClientType.WEB, but when I use ClientType.ANDROID I get this error.
node_modules/youtubei.js/dist/src/utils/HTTPClient.js:101
throw new InnertubeError(Request to ${response.url} failed with status ${response.status}, yield response.text());
^
InnertubeError: Request to https://www.youtube.com/youtubei/v1/browse?prettyPrint=false&alt=json failed with status 404
at HTTPClient. (node_modules/youtubei.js/dist/src/utils/HTTPClient.js:101:19)
at Generator.next ()
at fulfilled (node_modules\tslib\tslib.js:166:62)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
info: '{\n' +
'  "error": {\n' +
'    "code": 404,\n' +
'    "message": "Requested entity was not found.",\n' +
'    "status": "NOT_FOUND"\n' +
'  }\n' +
'}\n',
date: 2024-04-13T12:51:01.363Z,
version: '9.2.0'
}
Node.js v18.16.0

In your case, there's no difference. WEB is just as fast as ANDROID.

ClientType.ANDROID is faster than WEB.
import { ClientType, Innertube, UniversalCache } from 'youtubei.js';

async function start() {
    const vid = 'ZiplxPdOJd4';
    const yt = await Innertube.create(
        {
            cache: new UniversalCache(true),
            generate_session_locally: true,
            client_type: ClientType.ANDROID,
        }
    );

    yt.session.on('auth-pending', (data) => {
        console.log(`Go to ${data.verification_url} in your browser and enter code ${data.user_code} to authenticate.`);
    });

    await yt.session.signIn();
    await yt.session.oauth.cacheCredentials();
    console.log((await yt.getHomeFeed()).contents.contents.length);
}

When I use OAuth there is no problem with ClientType.WEB, but when I use ClientType.ANDROID I get this error.
node_modules/youtubei.js/dist/src/utils/HTTPClient.js:101
            throw new InnertubeError(`Request to ${response.url} failed with status ${response.status}`, yield response.text());
                  ^

InnertubeError: Request to https://www.youtube.com/youtubei/v1/browse?prettyPrint=false&alt=json failed with status 404
    at HTTPClient.<anonymous> (node_modules/youtubei.js/dist/src/utils/HTTPClient.js:101:19)
    at Generator.next (<anonymous>)
    at fulfilled (node_modules\tslib\tslib.js:166:62)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  info: '{\n' +
    '  "error": {\n' +
    '    "code": 404,\n' +
    '    "message": "Requested entity was not found.",\n' +
    '    "status": "NOT_FOUND"\n' +
    '  }\n' +
    '}\n',
  date: 2024-04-13T12:51:01.363Z,
  version: '9.2.0'
}

Node.js v18.16.0

I just made use of WEB and it was successful.

In your case, there's no difference. WEB is just as fast as ANDROID.

How do i clear the cached credentials? Take for instance if i'm  switching accounts


Consider relative cacheDir

See https://discourse.gohugo.io/t/error-setting-cachedir-to-a-relative-folder-since-0-52/15596/2

I believe the intent of this proposal, given the context of the related forum topic, is covered by the ability to configure file caches.
Can we close this issue?

I think this is not solved (and a better default would be implementing https://github.com/gohugoio/hugo/issues/7391). The configuration right now requires absolute paths which basically makes this unusable to store the cache per-project.


Add Our Services Section

This section can go below the Jumbotron (#3) and should include the different services that is provided by AccoTech. Something similar to the the services section in http://marilynnbellco.com/ would be nice.

This is completed, we just need to change the content appropriately.


Add support for absolute timeouts to io_uring_getevents_arg-based io_uring_enter calls

I have been working on implementing an io_uring-based execution context with support for timers where I manage a priority-queue of user-provided timers and compute the earliest due time at which I have work scheduled to run.
Ideally, I would like to be able to call io_uring_enter2() and have that block until either I have a completion-event to process or the earliest due time has elapsed.
Currently, the io_uring_getevents_arg structure seems to require passing a relative time.
While the documentation does not specify whether the time is relative or not, looking at the implementation, the io_cqring_wait() function seems to be adding the current kernel time to the value passed.
While I can convert the absolute time I have to a relative time by calling clock_gettime() just before calling io_uring_enter2(), this approach has a couple of limitations.

It seems like additional overhead - both user-space and the kernel need to ask for the current time to convert to/from a relative time.
It can also be less accurate than passing an absolute time - if the thread's time-slice ends between the calls to clock_gettime() and io_uring_enter2() then the computed relative timeout can be an over-estimate and can result in additional delay to the io_uring_enter2() call returning.

Would it be possible to add support for passing an absolute timeout time to the io_uring_enter2() syscall or to the io_uring_wait_cqe_timeout() or io_uring_submit_and_wait_timeout() functions?
Ideally, with the ability to specify which clock to use (e.g. CLOCK_BOOTTIME or CLOCK_MONOTONIC).
Or am I better off trying to use the IORING_OP_TIMEOUT op-code for this use-case?

Or am I better off trying to use the IORING_OP_TIMEOUT op-code for this use-case?

That's a bad option

While the documentation does not specify whether the time is relative or not, looking at the implementation, the io_cqring_wait() function seems to be adding the current kernel time to the value passed.

right, it's relative

Would it be possible to add support for passing an absolute timeout time to the io_uring_enter2() syscall or to the io_uring_wait_cqe_timeout() or io_uring_submit_and_wait_timeout() functions?

I can take a look, it's easy to add a flag telling whether it's relative or not

io_uring_wait_cqe_timeout() or io_uring_submit_and_wait_timeout() functions?
Ideally, with the ability to specify which clock to use (e.g. CLOCK_BOOTTIME or CLOCK_MONOTONIC).

This one might be more complicated to fit in. Maybe it should be a ring global option set separately via the io_uring register syscall, i.e. if you request the waiting syscall timeout's to be in abs mode, than we'll use that registered beforehand value to decide what clock mode it should use. I can't imagine that an app would be switching b/w abs modes at runtime.

Or am I better off trying to use the IORING_OP_TIMEOUT op-code for this use-case?

That's a bad option

Actually, after re reading your use case I take it back, that's what OP_TIMEOUT is there for. You also have multishot timeouts if that works with you, you queue just one request and it'll produce a CQE each time the required interval passes.
The wait argument might be faster though in some cases, so the question is what the performance looks like in your app comparing two options (while simulating abs through relative modes)?

Or am I better off trying to use the IORING_OP_TIMEOUT op-code for this use-case?

That's a bad option

Actually, after re reading your use case I take it back, that's what OP_TIMEOUT is there for.

If I queue an OP_TIMEOUT with a count of 1 and an absolute due-time and then call io_uring_enter(), am I guaranteed that when the io_uring_enter() call returns that the CQE for the OP_TIMEOUT operation will be present in the completion-queue?

You also have multishot timeouts if that works with you, you queue just one request and it'll produce a CQE each time the required interval passes.

A multishot timeout doesn't work for my use-case. I have a whole bunch of single-shot tasks that need to be executed at specific times. I compute the earliest such time and when I don't have anything else to do I want to wait for events until that time arrives. Once the task(s) scheduled for that time have been executed I look at the next earliest time in the queue and, when idle, I want to wait for events until that next earliest time arrives. The times are not necessarily periodic.

The wait argument might be faster though in some cases, so the question is what the performance looks like in your app comparing two options (while simulating abs through relative modes)?

I'll try to get some measurements for you.

Actually, after re reading your use case I take it back, that's what OP_TIMEOUT is there for.

If I queue an OP_TIMEOUT with a count of 1 and an absolute due-time and then call io_uring_enter(), am I guaranteed that when the io_uring_enter() call returns that the CQE for the OP_TIMEOUT operation will be present in the completion-queue?

Please don't, count is unofficially deprecated, there is no way to use it reliable and there are all sorts of problems with it.
With that said, I don't see what you want to achieve by using it. OP_TIMEOUT is a normal request, once completed it'll post a CQE. If you wait(nr=1), once the timeout completes you have enough CQEs to satisfy the wait condition, which will force the syscall to return back to user space.
IIRC there was a hack breaking the waiting loop if there is at least one timeout completed regardless of the nr you pass to waiting, but I need to double check and it's probably unreliable.

With that said, I don't see what you want to achieve by using it. OP_TIMEOUT is a normal request, once completed it'll post a CQE.

One case I have in mind is where I currently have an earliest scheduled time that is, say, 5s in the future (T+5) and I don't have anything else to do until either an I/O completes or that time 5s in the future arrives, so I am blocked in io_uring_enter() waiting for at least one CQE.
Then I/O completion-event arrives, say at T+0.5, and io_uring_enter() returns, I process the completion-event and it maybe issues some more I/O requests but also schedules a new task to run at T+2. This means the new earliest time is now earlier than the previous OP_TIMEOUT request. So I need to cancel the old OP_TIMEOUT by submitting a new OP_TIMEOUT_REMOVE request and then issue a new OP_TIMEOUT request with the new time, presumably with the IOSQE_IO_HARDLINK flag so that I can reuse the same user_data value.
But since the OP_TIMEOUT_REMOVE request is likely (guaranteed?) to complete synchronously, the next io_uring_enter() will immediately put a CQE for the OP_TIMEOUT_REMOVE op and the existing OP_TIMEOUT request into the completion-queue and return. I then need to process these CQE and call io_uring_enter() again to actually start waiting on the new OP_TIMEOUT time.
So this ends up needing two io_uring_enter() syscalls to set a new due time and wait.
The goal of setting the count to be 1 on the OP_TIMEOUT operation was to have that OP_TIMEOUT implicitly cancelled and completed when io_uring_enter() returns early because a completion-event arrives. This would allow me to issue a new OP_TIMEOUT with a new due-time on the next call to io_uring_enter and then wait for that new timeout with a single syscall.
I only just noticed that OP_TIMEOUT_REMOVE has an optional IORING_TIMEOUT_UPDATE flag that can be used to update the existing OP_TIMEOUT rather than having to cancel the existing OP_TIMEOUT and issue a new one. I will look at trying to use this in conjunction with IOSQE_CQE_SKIP_SUCCESS to avoid immediately posting a CQE whenever the timeout is updated.
Regardless, I think having the ability to pass an absolute time into io_uring_getevents_arg would be a better fit for this usage pattern. It would avoid the complexities needed to manage submitting, updating, cancelling OP_TIMEOUT operations, with the inherent races involved (e.g. an update to a later time might fail with -EBUSY, requiring issuing a new OP_TIMEOUT) and care needed to manage lifetimes of the __kernel_timespec objects needed to issue successive updates in the presence of IORING_SETUP_SQPOLL where submission is asynchronous (I can't reuse the same __kernel_timespec object to issue a subsequent update until the SQE for the last OP_TIMEOUT[_REMOVE] has been consumed).

For an example of some of the challenges using OP_TIMEOUT, see #1164

The goal of setting the count to be 1 on the OP_TIMEOUT operation was to have that OP_TIMEOUT implicitly cancelled and completed when io_uring_enter() returns early because a completion-event arrives. This would allow me to issue a new OP_TIMEOUT with a new due-time on the next call to io_uring_enter and then wait for that new timeout with a single syscall.

That's an interesting use case, but still please avoid using that count feature. Unfortunately, it's racy, and the timeout might get stuck.

I only just noticed that OP_TIMEOUT_REMOVE has an optional IORING_TIMEOUT_UPDATE flag that can be used to update the existing OP_TIMEOUT rather than having to cancel the existing OP_TIMEOUT and issue a new one. I will look at trying to use this in conjunction with IOSQE_CQE_SKIP_SUCCESS to avoid immediately posting a CQE whenever the timeout is updated.

Not sure how SKIP_SUCCESS fits here, the updated request is not going to post a completion until the new timeout expires, assuming update went well. The update/remove request will post a CQE though, when it's either completed updating or failed to find the timeout request.

Regardless, I think having the ability to pass an absolute time into io_uring_getevents_arg would be a better fit for this usage pattern. It would avoid the complexities needed to manage submitting, updating, cancelling OP_TIMEOUT operations, with the inherent races involved (e.g. an update to a later time might fail with -EBUSY, requiring issuing a new OP_TIMEOUT) and care needed to manage lifetimes of the __kernel_timespec objects needed to issue successive updates in the presence of IORING_SETUP_SQPOLL where submission is asynchronous (I can't reuse the same __kernel_timespec object to issue a subsequent update until the SQE for the last OP_TIMEOUT[_REMOVE] has been consumed).

Fair enough, I'll take a look

I only just noticed that OP_TIMEOUT_REMOVE has an optional IORING_TIMEOUT_UPDATE flag that can be used to update the existing OP_TIMEOUT rather than having to cancel the existing OP_TIMEOUT and issue a new one. I will look at trying to use this in conjunction with IOSQE_CQE_SKIP_SUCCESS to avoid immediately posting a CQE whenever the timeout is updated.

Not sure how SKIP_SUCCESS fits here, the updated request is not going to post a completion until the new timeout expires, assuming update went well. The update/remove request will post a CQE though, when it's either completed updating or failed to find the timeout request.

The idea was to apply the SKIP_SUCCESS flag to the update request so that it would not immediately post a CQE and cause the io_uring_enter() call to immediately return to process that CQE and then have to make a second io_uring_enter() call to actually put the thread to sleep until the due time.
As you say, it would still post a CQE in the case that the update failed, but in this case you probably wanted to wake up due to the timer elapsing anyway.

Merged, should be in 6.12 when it comes out
<EMAIL_ADDRESS>


Update install instructions

Addresses https://github.com/devitocodes/devito/issues/1065#issuecomment-573106105
Following up from the linked issue, assuming @mloubout did his part about removing redundancies between requirements.txt and environment.yml already, this PR does the rest of the things from that issue including:

Add three separate subsections each for "docker installation"/"pip installation" and "conda installation", each explaining their respective target audience
Rename environment.yml to environment-dev.yml to highlight that this is the development environment.
Make the quickstart section the one where the user decides which of the three use cases from above they fall into, and link to the appropriate section.

Hope to end these discussions once and for all with this PR.

README.md is the first thing that newcomers see, and I don't think we want to put too much explanation about the installation process. Essentially, just the code snippets and a couple of sentences should suffice.
In the same spirit as https://github.com/tensorflow/tensorflow#install , we should/could move the full explanation to https://github.com/devitocodes/devito/blob/master/docs/source/download.rst , which anyway needs to be updated with this PR
BTW, I will refresh README.md before Rice

@FabioLuporini - your comments appear to have been addressed. GTO?


Add back 3 removed unrelated note lines

Adding back the 3 lines you removed outside of the added note.
One of the last line changes was correctly placed, but
missing the > character to keep the block together.
Ref. https://github.com/MicrosoftDocs/windows-itpro-docs/pull/3414

@j0rt3g4 : Are you able to merge this into your PR file?

@illfated  Done


Bug 2040504: Ensure IOPS setting is honoured on all supported block device types

AWS documentation suggests that IO1, IO2 and GP3 block devices all support a configurable IOPS setting. We are only allowing this for IO1 right now, so we should make sure that we set the IOPS on other supported types as well.

The following are the supported values for each volume type:

gp3 : 3,000-16,000 IOPS
io1 : 100-64,000 IOPS
io2 : 100-64,000 IOPS

/lgtm

/lgtm

/retest-required

/cherry-pick release-4.9

That's because 4.9 is on a different repo. I did a manual cherry pick to that here: https://github.com/openshift/cluster-api-provider-aws/pull/436


I added a Java implementation of selection sort and added it to the bottom of the list of implementation

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Reason: There is already an existing Java example.
Thank you and happy coding.


Couple Ginkgo tests are failing on NERSC Perlmutter

I tried running the ginkgo tests on Perlmutter with both gcc and nvidia compiler builds.
For gcc 11.2.0 compiler with cuda 11.7 builds, "make test" gives:
99% tests passed, 1 tests failed out of 282
Total Test time (real) = 373.87 sec
The following tests FAILED:
250 - test/matrix/matrix_cuda (Failed)
I've attached the "gcc-LastTest.log" file, which showed that while the "make test" output to the screen stated 1 test failed, LastTest.log shows that actually 4 tests failed:
[  FAILED  ] 4 tests, listed below:
[  FAILED  ] Matrix/CsrWithSparselibStrategy.SpMVIsEquivalentToRef, where TypeParam = CsrWithSparselibStrategy
[  FAILED  ] Matrix/CsrWithSparselibStrategy.AdvancedSpMVIsEquivalentToRef, where TypeParam = CsrWithSparselibStrategy
[  FAILED  ] Matrix/CsrWithSparselibStrategy.MixedSpMVIsEquivalentToRef, where TypeParam = CsrWithSparselibStrategy
[  FAILED  ] Matrix/CsrWithSparselibStrategy.MixedAdvancedSpMVIsEquivalentToRef, where TypeParam = CsrWithSparselibStrategy
For the xgc work, the test/matrix/matrix_cuda failure isn't an issue because it's for CSR format, and we use ELL instead.  But I had seen the errors were pretty large.
My cmake line:
cmake
-DCMAKE_CXX_COMPILER=g++
-DGINKGO_COMPILER_FLAGS=-pedantic
-DCMAKE_INSTALL_PREFIX=${install_dir}
-DGINKGO_CUDA_ARCHITECTURES=Ampere
-DGINKGO_BUILD_OMP=OFF
-DGINKGO_BUILD_MPI=OFF
-DCMAKE_BUILD_TYPE:STRING=RELEASE
-DGINKGO_BUILD_TESTS=on
-DGINKGO_BUILD_BENCHMARKS=off
-DGINKGO_BUILD_EXAMPLES=off
-DGINKGO_BUILD_HWLOC=off
..
I then tried ginkgo tests with nvidia 22.9 compiler and cuda 11.7, and quite a few more tests failed (5 additional tests failed):
98% tests passed, 6 tests failed out of 282
Total Test time (real) = 447.98 sec
The following tests FAILED:
39 - reference/test/factorization/lu_kernels (Failed)
90 - reference/test/solver/cgs_kernels (Failed)
133 - core/test/base/math (Failed)
249 - test/matrix/dense_kernels_cuda (Failed)
250 - test/matrix/matrix_cuda (Failed)
253 - test/preconditioner/jacobi_kernels_cuda (Failed)
I've attached the "nvidia-LastTest.log" file, which showed that while the "make test" output to the screen stated 6 tests failed, LastTest.log shows that actually many more than 6 tests failed.
Looks like those other test failures were barely missing the tolerance (e.g. error was 1e-13 and tolerance was 1e-14), so I had wondered if the tolerance was too tight.
gcc-CMakeCache.txt
gcc-LastTest.log.gz
nvidia-CMakeCache.txt
nvidia-LastTest.log.gz

Thanks for reporting it! We also found the cusparse csr issue in the #1212 .
about more failed test from the nvidia compiler, it might be from too tight tolerance.
Is it consistent when running several times?

The cuSPARSE bug in matrix_cuda only concerns strided (non-packed) vectors, so even if you were using CSR storage, this would most likely not cause any issues for you.

@pwxy Could you try this branch https://github.com/ginkgo-project/ginkgo/tree/spmm_single_vector to check whether pass matrix_cuda or not?
It only fallbacks to our own implementation when sparselib with single strided vector

gcc version: it should be solved with #1322
nvhpc: Dense and LU error should be solved with #1306, and CsrSparseLib should also be solved with #1322
However, the issues from Cgs, math, Jacobi are not related to #1306 and #1322
the math test gko::is_finite(limits::quiet_NaN()) returns true not false.
I guess nvhpc by default uses fastmath such that nan is not actual nan.
maybe disable fast math can also solve the left issues.

We use this test for both host and device:
return abs(value) < infinity;

--- https://github.com/ginkgo-project/ginkgo/blob/develop/include/ginkgo/core/base/math.hpp#L1205
So we don't use std::isfinite on host (or device).

Should be fixed after #1331. Please reopen if that is not the case.