Authentication with Perses remote deployment not possible

What did you do?
Deploy Perses on a remote server, whether that be in AWS, DigitalOcean or any other provider and enabling authentication to get the login page results in an authentication loop/failure.
I have attempted this using both Docker and Binary install, as well as on various cloud platforms, with and without load balancer.
I have used Safari and Chrome to test with, with and without incognito.
The only way I can log into Perses is by using an SSH tunnel to the server hosting Perses.
More details and full discussion can be seen in the perses-dev channel on Matrix.
What did you expect to see?
I expected to be logged into Perses
What did you see instead? Under which circumstances?
Logging in will redirect back to the log-in page, as if nothing happened. 3 cookies are received, but then quickly erased, resulting in no authentication taking place.
System information
Amazon Linux 2023, Ubuntu 24.04
Perses version
0.45, 0.46 (but happens on older versions too)
Perses configuration file
database:
  file:
  folder: "./database"
  extension: "yaml"

schemas:
  panels_path: "./cue/schemas/panels"
  queries_path: "./cue/schemas/queries"
  datasources_path: "./cue/schemas/datasources"
  variables_path: "./cue/schemas/variables"
  interval: "6h"

security:

  # When it is true, the authentication and authorization config are considered.
  # And you will need a valid JWT token to contact most of the endpoints exposed by the API
  enable_auth: true

  authentication:
    disable_sign_up: false
    # Authentication providers
    providers:
      # List of the OIDC authentication providers
      enable_native: true

Logs
INFO[2024-06-12T10:05:27Z]  method=POST status=200 uri=/api/auth/providers/native/login
INFO[2024-06-12T10:05:27Z]  method=GET status=401 uri=/api/v1/projects
INFO[2024-06-12T10:05:27Z]  method=GET status=401 uri="/api/v1/dashboards?metadata_only=true"
INFO[2024-06-12T10:05:27Z]  method=GET status=200 uri=/api/config
INFO[2024-06-12T10:05:27Z]  method=GET status=401 uri=/api/v1/projects
INFO[2024-06-12T10:05:27Z]  method=POST status=400 uri=/api/auth/refresh
INFO[2024-06-12T10:05:27Z]  method=POST status=400 uri=/api/auth/refresh
INFO[2024-06-12T10:05:27Z]  method=POST status=400 uri=/api/auth/refresh
INFO[2024-06-12T10:05:27Z]  method=GET status=200 uri=/sign-in
INFO[2024-06-12T10:05:27Z]  method=GET status=200 uri=/sign-in
INFO[2024-06-12T10:05:27Z]  method=GET status=200 uri=/main.js
INFO[2024-06-12T10:05:29Z]  method=GET status=200 uri=/api/config
INFO[2024-06-12T10:05:29Z]  method=GET status=200 uri=/api/v1/health
INFO[2024-06-12T10:05:29Z]  method=GET status=500 uri=/8f28e0e1fdb195149f1c.woff2
INFO[2024-06-12T10:05:29Z]  method=GET status=500 uri=/be36596da218e1eec01c.woff2
INFO[2024-06-12T10:05:29Z]  method=GET status=500 uri=/3dc1eff492ab1f598560.woff
INFO[2024-06-12T10:05:29Z]  method=GET status=500 uri=/1e7707c9ec98d9b97e7f.woff

Thanks for the issue. We're investigating. FYI, I just tested in Openshift, Azure Cloud, behind the Openshift router, and behind an Azure App Gateway and it works perfectly.
Interestingly in our side we don't have a refresh of the page. Whereas in a GIF you sent us in private, I noticed that there is a refresh and this is after/while the refresh that the cookies are flushed.

Here is our config
    security:
      readonly: false
      enable_auth: true
      encryption_key_file: /etc/extra-secrets/encrypt/encryption.key

      authorization:
        guest_permissions:
        - actions:
          - read
          scopes:
          - "*"
        - actions:
          - create
          scopes:
          - Project

      authentication:
        providers:
          enable_native: true
          oidc:
          - <redacted>

    database:
      sql:
        addr: <redacted>
        allow_native_passwords: true
        db_name: perses
        net: tcp
        tls_config: <redacted>

    schemas:
      datasources_path: /etc/perses/cue/schemas/datasources
      interval: 5m
      panels_path: /etc/perses/cue/schemas/panels
      queries_path: /etc/perses/cue/schemas/queries
      variables_path: /etc/perses/cue/schemas/variables

    frontend:
      information: <redacted>

    provisioning:
      folders:
      - "/etc/perses/provisioning"

Could you provide what is the infrastructure you are using to deploy Perses ?
Like in DigitalOcean, do you deploy Perses on K8s ? With an ingress ? Or are you using an App platform ?
I wanted to try on Digital ocean, but based on your input, I just have no idea what plan should I choose.

Please as much as possible, provide the necessary resources to be able to reproduce the issue as we are not able to reproduce it so far. Example of resources:

helm chart files
Load Balancer configuration
DNS used
Proxy configuration
Any configuration files required to deploy the app in DigitalOcean / AWS

Guys, I appreciate the effort you are making towards a resolution, but I am not sure how exactly I can explain this as i've really not done much to the setup of Perses besides creating one user and enabling authentication (native)
I provided the configuration for Perses.
I am not sure what else you could need?
Initially I believed this was a load balancer issue. It's not.
Then I questioned whether it was an AWS-specific issue. It's not.
Again, my steps (in my case, I am using AWS, but I don't believe it matters):

Launch EC2 server with public IP
wget Perses release from Github onto server
Extract release
Apply config mentioned above and launch Perses
Create user
Attempt to log in

This results in failure to log in and cookies failing to be retained.

Hi All,
Just want to add my 2 cents also.
I have tried this also with docker and podman, then podman compose after seeing thats how the demo site was deployed and working with no issues.
I have deployed the following podman-compose.yaml and config.json and same as @GSX1400 it just has the same issue logging in.
Obviously the IP I used will need to be substituted for the public IP of the instance you are using.
`version: '3.8'
services:
traefik:
image: traefik:latest
container_name: traefik
security_opt:
- label=type:container_runtime_t
volumes:
- /run/user/1000/podman/podman.sock:/var/run/docker.sock:z
- ./acme.json:/acme.json:z
ports:
- "30080:80"
- "30443:443"
- "8080:8080"
command:
- --api.dashboard=true
- --api.insecure=true
- --entrypoints.http.address=:80
- --entrypoints.https.address=:443
- --providers.docker=true
networks:
- podman
perses:
image: persesdev/perses
container_name: perses
depends_on:
- traefik
ports:
- "80:8080"
labels:
- "traefik.enable=true"
- "traefik.http.routers.perses.rule=Host(<IP_ADDRESS>)"
- "traefik.http.services.perses.loadbalancer.server.port=80"
volumes:
- ./config.yaml:/etc/perses/config.yaml:z
networks:
- podman
networks:
podman:
external: true`
`database:
file:
folder: "/perses"
extension: "json"
schemas:
panels_path: "/etc/perses/cue/schemas/panels"
queries_path: "/etc/perses/cue/schemas/queries"
datasources_path: "/etc/perses/cue/schemas/datasources"
variables_path: "/etc/perses/cue/schemas/variables"
interval: "6h"
security:
When it is true, the authentication and authorization config are considered.
And you will need a valid JWT token to contact most of the endpoints exposed by the API
enable_auth: true
readonly: false
authorization:
guest_permissions:
- actions:
- read
scopes:
- "*"
- actions:
- create
scopes:
- Project
authentication:
disable_sign_up: false
# Authentication providers
providers:
# List of the OIDC authentication providers
enable_native: true
provisioning:
folders:
- "/etc/perses/provisioning"`

Hi All,
Just want to add my 2 cents also.
I have tried this also with docker and podman, then podman compose after seeing thats how the demo site was deployed and working with no issues.
I have deployed the following podman-compose.yaml and config.json and same as @GSX1400 it just has the same issue logging in.
Obviously the IP I used will need to be substituted for the public IP of the instance you are using.
version: '3.8'

services:
  traefik:
    image: traefik:latest
    container_name: traefik
    security_opt:
      - label=type:container_runtime_t
    volumes:
      - /run/user/1000/podman/podman.sock:/var/run/docker.sock:z
      - ./acme.json:/acme.json:z
    ports:
      - "30080:80"
      - "30443:443"
      - "8080:8080"
    command:
      - --api.dashboard=true
      - --api.insecure=true
      - --entrypoints.http.address=:80
      - --entrypoints.https.address=:443
      - --providers.docker=true
    networks:
      - podman

  perses:
    image: persesdev/perses
    container_name: perses
    depends_on:
      - traefik
    ports:
      - "80:8080"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.perses.rule=Host(`<IP_ADDRESS>`)"
      - "traefik.http.services.perses.loadbalancer.server.port=80"
    volumes:
      - ./config.yaml:/etc/perses/config.yaml:z
    networks:
      - podman

networks:
  podman:
    external: true

database:
  file:
    folder: "/perses"
    extension: "json"

schemas:
  panels_path: "/etc/perses/cue/schemas/panels"
  queries_path: "/etc/perses/cue/schemas/queries"
  datasources_path: "/etc/perses/cue/schemas/datasources"
  variables_path: "/etc/perses/cue/schemas/variables"
  interval: "6h"

security:

  # When it is true, the authentication and authorization config are considered.
  # And you will need a valid JWT token to contact most of the endpoints exposed by the API
  enable_auth: true
  readonly: false

  authorization:
    guest_permissions:
    - actions:
      - read
      scopes:
      - "*"
    - actions:
      - create
      scopes:
      - Project

  authentication:
    disable_sign_up: false
    # Authentication providers
    providers:
      # List of the OIDC authentication providers
      enable_native: true

provisioning:
      folders:
      - "/etc/perses/provisioning"

thanks for your input @blairmurray and @GSX1400.
In parallel with @celian-garcia we compared how Grafana could work in the environment your mention.
We noticed the following configuration:
# set to true if you host Grafana behind HTTPS. default is false.
;cookie_secure = false

# set cookie SameSite attribute. defaults to `lax`. can be set to "lax", "strict", "none" and "disabled"
;cookie_samesite = lax

Which differs from what we have done in Perses. In Perses the cookie configuration is hardcoded with the following value:
cookie_secure = true
cookie_samesite = none

Through https://github.com/perses/perses/pull/2069 I am making the cookie setup configurable. While doing this PR I have notices that some e2e tests were failing and after investigation I noticed it failed by reproducing the behaviour you explained yesterday in Matrix.
While the PR is reviewed, could you try to deploy Grafana and set the parameter cookie_secure to true and tell us if it works as before, or if in contrary you noticed an issue ?
Or if you prefer, once the PR is merged, would you like to deploy the main branch with the associated docker image that would contain the same cookie config than Grafana ?

if the issue is linked to the cookie_secure parameter, then the whole issue is an issue with HTTPS that is not secured somewhere

If possible could you try with the docker image: main-2024-06-13-670b9736-distroless that contains the cookie configuration that hopefully should solve the problem ?
Thanks by advance

To conclude this issue, here some advices:

when you are activating the authentication, you should use HTTPS to ensure that password is encrypted during the request
once HTTPS is properly setup, you should set cookie_secure to true as the cookie we are creating contain the JWT token which shouldn't exist excepting if HTTPS is the protocol used
cookie_secure=false should be only used for test purpose or local setup , never in production

Closing this issue as it appears for testing purpose without HTTPS setup, being able to configure the cookie solved the issue


Replaced hardcoded home directory in Systemd ExecStop with HOME variable

Thanks.
Also, we probably shouldn't depend on the hardcoded path to resurrect save file... The plugin does not have to be installed on that path.
Here's the line that dynamically fetches tmux ressurect save path. It would be awesome if we could get the value of that var interpolated in the template.


Bonus loot from discerning vision, precise inspection and astute observation

We have not identified any bonus tiers yet. All we know is that discerning vision improves existing tiers.
Once bonus tiers are known, I am not sure how I will organize this bit, but until then, here are the raids with bonus tiers and the level needed of the associated tech skill:

Name
Easy (raid)
Hard (raid)
Legendary (raid)
Easy (quest)
Hard (quest)
Legendary (quest)

Lesser Tree Ent
done (see #24)
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Minor Watcher
x
x
x
-
-
-

Superior Watcher
DV2
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Elven Rangers
DV3
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Greater Ent
DV3
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Sand Wyrm
DV3
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Corrupted Golem
DV3
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Naga Risaldar
DV3
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Spiderling
x
x
x
-
-
-

Galeohog
-
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Naga Karamati
DV3
DV3, DV5
DV3, DV6
-
AO3
AO3, AO6

Jagar The Red
-
DV4, DV6
DV4, DV7
-
AO4
AO4, AO7

Rotting Fen Lure
DV3
DV3, DV5
?
-
AO4
AO4, AO7

Hill Troll
x
x
x
done
done
AO4, AO7

Sentry Ghoul
DV4
DV4, DV7
DV4, DV7
-
AO4
AO4, AO7

Fallen Naga Subedar
DV4
DV4, DV7
DV4, DV7
-
AO4
?

Bone Dragon
DV4
DV4, DV7
DV4, DV7
-
AO4
?

Fungal Friend
PI1
PI2
PI3, PI5
x
x
x

Rogue Slime
PI2
PI3
PI4
x
x
x

Nitroglycergnat
PI2
PI3
PI4
x
x
x

Basiliscus
PI2
PI3
PI4
x
x
x

Tunnaru
PI2
PI3
PI4
x
x
x

Astute observation, at level 3, provides one extra rare drop for both Lesser Tree Ent and superior Watcher hard quest bosses.
This might be the case for all of them.

On easy difficulty, Hill Troll gives one more common drop with astute observation.

Astute observation level 4
Hard
Hill Troll: +1 common

Fungal Fiend, easy: +1 common at the highest tier. Other tiers must be checked.

Easy superior watcher: +1 mythic ?
200,000 damage: yes
160,000 damage: ?

Greater Ent, easy: +?
Yes: 350,000
No: ?

Elven Rangers, easy: +1 common, +1 rare?
Yes: 240,000
No: ?

Bone dragon, easy raid: +1 rare at unknown tier
Bone dragon, hard raid:

level four (?): +1 rare at unknown tier
level seven (?): +1 mythic at unknown tier

Rotting Fen Lure, legendary raid:

unknown level: +1 rare at unknown tier
unknown level: +1 rare at unknown tier

Thanks to Infinity.


Compile process to refresh GWAS Catalog data

The current workflows assume the presence of GWAS Catalog association/study/ancestry/summstats data. (Which at the moment was last updated in 2022-11-29. These files were manually downloaded from GWAS Catalog website then copyied to GCP. Not particularly ETL friendly.
The logic to refresh these files should do the following:

[ ] Handling parameters from the config file.
[ ] Retain release date in the input file name [1].

[1] It might be up for discussion: we can use static file names, however the process should start with deleting the data first - applying static file names would make it easier to set input for downstream processes. On a flip side, that could very easily lead to out-of-sync data.

I have added a shell script to the utils folder with the logic to fetch/date the most recent GWAS Catalod release then uploads them to our input bucket. However the config file update is still manual. PR: #142


Problem with the build.

Project structure contains functions folder (for firebase functions) in core project folder. I need import function from functions/generateData/generateDataForFile.js
config-overrides.js
  const { alias, aliasJest, configPaths } = require('react-app-rewire-alias');

  const aliasMap = configPaths('./jsconfig.paths.json');

  module.exports = alias(aliasMap);
  module.exports.jest = aliasJest(aliasMap);

jsconfig.paths.json
    {
      "compilerOptions": {
        "baseUrl": ".",
        "paths": {
          "@functionsFolder": ["functions/generateData"]
        }
      }
    }

Yarn start works perfect, but yarn build throw error "Attempted import error: 'generateDataForFile' is not exported from '@functionsFolder/"generateDataForFile'.

This will be an issue with your local project, as the import error has nothing to do with react-app-rewired.
Two things I can see as potentials to begin with:

In the react-app-rewire-alias documentation, they specify that the paths should be "@functionsFolder/*": ["functions/*"] or "@functionsFolder/*": ["functions/generateData/*"] (I'm not quite sure from your usage which you're intending to be using). That "*" is actually important - it means "all file imports begining with '@functionsFolder' should have the '@functionsFolder' part replaced with 'functions/' or 'functions/generateData/'. At present, you're only mapping a single file.
You are specifying the generateData file specifically at present, which does not match the path for generateDataForFile.

I think the first issue of only mapping a single file path above is likely the cause for your issue, but I've listed both possibilities just in case. To be able to debug it any further, I'd need an example repository that demonstrates the issue to be able to look at.

Closing this given no recent activity.


Question: How to use the Microsoft.Toolkit.Uwp.Notifications NuGet for .NET 5?

Hello,
We are building a component for WinForms using Microsoft.Toolkit.Uwp.Notifications version 6.1.1.
We were not able to build it for NET5 and we've noticed that the package is lacking .NET 5 lib both in 6.1.1 and in the latest 7.0.0-preview4. At the moment we are getting the following error, when trying to build with 6.1.1/7.0.0-preview4:

Error	CS0012	The type 'ToastNotifier' is defined in an assembly that is not referenced. You must add a reference to assembly 'Windows.Foundation.UniversalApiContract, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'.

Adding the appropriate reference did not solve the problem.
Is there something that we are missing or do we need a new lib for .NET 5?
If so, do you know, when you are going to have one ready?
Regards,
Stoyan

@100RH Add CsWinRT to your project. If that does not work, report it here: https://github.com/windows-toolkit/WindowsCommunityToolkit

@Jaiganeshkumaran thanks for the reply.
I found that this is a duplicate of the following issue:
https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3579


Explain how to complete Verify flow in local dev

F had to explain this to me when I joined the project; hopefully this
will be useful for new developers.

LGTM, I understood your explanation of how to get through the local verify. I just wanted to check that there wasn't any local VSP setup that also needs mentioning in the docs?

I think that the local VSP setup is already explained pretty well in the "Running locally in development" part of the same document.


Parallel simulation option for HopsanCLI

New option for parallel simulation in HopsanCLI. Resolves #1999.
   -p <integer>,  --parallel <integer>
     Enable parallel simulation with specified number of threads. 0 threads
     means auto-detect number of procssors.

Does this enable parallel optimization ?
I think that was mentioned in the issue description.

Parallel optimization using the Ops algorithms are already supported. I think the issue has external algorithms in mind, e.g. Matlab or Python. This can be achieved by launching multiple hopsancli instances, assuming of course they read from different parameter files and write to different result files.


Feature/android o ble scanning support

Building further on Niels's work, "finalised" the Android O support PR.
Things to do:

Verify that scanning works as intented on Android O devices: Interval scan & instant scan.
Error handling.

Can I get a demo of this?
Did you update the wiki for v2 / new wiki page for v2?


[build] Generate given_exo.{cmi,cmo,cmt} files

Kind: feature

Address #414 first (disabling broken option learn-ocaml build --jobs=2)

Description

Add option learn-ocaml build --enable-cmo-build
This new experimental option is on by default (implicit mode) and generates given_exo.{cmi,cmo,cmt} in the www folder for each prelude ^ " ;;\n" ^ prepare.
This is a key feature for learn-ocaml.el (the Tuareg/Merlin frontend for Learn-OCaml); it can be disabled using the flag:$ learn-ocaml build --disable-cmo-build

If the www/exo.json file is up-to-date, the exo.cm* are not built.
But we can force the exo.cm* build (explicit mode) even for un-changed exercises using the flag:$ learn-ocaml build --enable-cmo-build

This option may later become mandatory if/when the js_of_ocaml front-end also fetches similar *.cmo files.
Regarding the ocamlc naming convention:
require that the input exercise id basename exo-name matches [0-9A-Za-z_-]+, otherwise raise a warning,
then bijectively replace _ → _0 and - → _1 in exo, then yield the output filename dir/given_exo_1name.cmo.

Checklist

[x] Read the CONTRIBUTING.md guide.
[x] Add/update tests
[ ] Implement the learn-ocaml-client counterpart of this feature within this PR

Note to maintainers

Read this wiki page
Make sure the PR has a milestone
Assign yourself before merging (using a regular Merge for this one)

Closed subsumed by #481.


fix: artifacthub files

Description
Fix artifacthub files.

createdAt is a required field in artifacthub-pkg.yaml files

@chipzoller you didn't receive the alert emails ?


BUG: Fix for issue #12553

closes #12553

thanks. See the contributing guide here
Like to have tests!

in the future, no need to open a NEW pull-request, just force push to the old one.


Errror: missingOutputType.  The [optional] syntax appears to be required for mist download.

The syntax for mist download would suggest that [options] are not required when using download.  However, the following error occurred when attempting to download macOS:
user@mymac ~ % sudo mist download "21E258"
Password:
┌──────────────────┐
│ INPUT VALIDATION │
└──────────────────┘
  ├─ User is 'root'...
  ├─ Download search string will be '21E258'...
  ├─ Kind will be 'installer'...
  ├─ Include betas in search results will be 'false'...
  ├─ Output directory will be '/Users/Shared/Mist'...
  ├─ Temporary directory will be '/private/tmp'...
  ├─ Force flag has not been set, existing files will not be overwritten...
  └─ [--application || --image || --package] Output type is missing.
Error: missingOutputType

Here is the syntax as described by mist help download :
user@mymac ~ % mist help download
OVERVIEW: Download a macOS Installer / Firmware.

USAGE: mist download [<options>] <search-string>

ARGUMENTS:
[...]

OPTIONS:
[...]

I agree, the help output should be more obvious. I am proposing the following:

Remove the --application, --image, --iso and --package flags
Add the [<output-type> ...] argument:

➜ mist download --help
OVERVIEW: Download a macOS Installer / Firmware.

USAGE: mist download [<options>] <search-string> [<output-type> ...]

ARGUMENTS:
  <search-string>         Specify a macOS name, version or build to download:
                          * macOS Monterey
                          * macOS Big Sur
                          * macOS Catalina
                          [...]
  <output-type>           Specify the requested output type(s):
                          * application to generate a macOS Installer Application Bundle (.app).
                          * image to generate a macOS Disk Image (.dmg).
                          * iso to generate a Bootable macOS Disk Image (.iso), for use with virtualization software (ie. Parallels Desktop, VMware Fusion, VirtualBox).
                          Note: This option will fail when targeting macOS Catalina 10.15 and older on Apple Silicon (M1) Macs.
                          * package to generate a macOS Installer Package (.pkg).

                          Note: These only apply when the kind is set to 'installer'.
OPTIONS:
[...]

The following command should succeed:
➜ sudo mist download "Monterey" application image iso

Whereas the following command should fail:
➜ sudo mist download "Monterey"
Error: Missing expected argument '<output-type> ...'
Help:  <output-type>  Specify the requested output type(s):
* application to generate a macOS Installer Application Bundle (.app).
* image to generate a macOS Disk Image (.dmg).
* iso to generate a Bootable macOS Disk Image (.iso), for use with virtualization software (ie. Parallels Desktop, VMware Fusion, VirtualBox).
Note: This option will fail when targeting macOS Catalina 10.15 and older on Apple Silicon (M1) Macs.
* package to generate a macOS Installer Package (.pkg).

Note: These only apply when the kind is set to 'installer'.
Usage: mist download [<options>] <search-string> [<output-type> ...]
  See 'mist download --help' for more information.

I just need to confirm a clever way to skip <output-type> validation if firmware is set for the --kind flag 🤔

Even better, I have been able to simplify using subcommands:
➜ mist list --help
OVERVIEW: List all macOS Firmwares / Installers available to download.

USAGE: mist list <subcommand>

OPTIONS:
  -h, --help              Show help information.

SUBCOMMANDS:
  firmware                List all macOS Firmwares available to download.
                          * macOS Firmwares are for Apple Silicon Macs only.

  installer               List all macOS Installers available to download.
                          * macOS Installers for macOS Catalina 10.15 and older are for Intel based Macs only.
                          * macOS Installers for macOS Big Sur 11 and newer are Universal - for both Apple Silicon and Intel based Macs.

  See 'mist help list <subcommand>' for detailed help.

List macOS Firmwares:
➜ mist list firmware --help
OVERVIEW: List all macOS Firmwares available to download.
* macOS Firmwares are for Apple Silicon Macs only.

USAGE: mist list firmware [<search-string>] [--latest] [--include-betas] [--export <export>] [--output-type <output-type>] [--quiet]

ARGUMENTS:
[...]

OPTIONS:
[...]

List macOS Installers:
➜ mist list installer --help
OVERVIEW: List all macOS Installers available to download.
* macOS Installers for macOS Catalina 10.15 and older are for Intel based Macs only.
* macOS Installers for macOS Big Sur 11 and newer are Universal - for both Apple Silicon and Intel based Macs.

USAGE: mist list installer [<search-string>] [--latest] [--include-betas] [--catalog-url <catalog-url>] [--export <export>] [--output-type <output-type>] [--quiet]

ARGUMENTS:
[...]

OPTIONS:
[...]

Download macOS Firmware:
➜ mist download firmware --help
OVERVIEW: Download a macOS Firmware.
* macOS Firmwares are for Apple Silicon Macs only.

USAGE: mist download firmware <search-string> [--include-betas] [--force] [--firmware-name <firmware-name>] [--output-directory <output-directory>] [--temporary-directory <temporary-directory>] [--export <export>] [--quiet]

ARGUMENTS:
[...]

OPTIONS:
[...]

Download macOS Installer:
➜ mist download installer --help
OVERVIEW: Download a macOS Installer.
* macOS Installers for macOS Catalina 10.15 and older are for Intel based Macs only.
* macOS Installers for macOS Big Sur 11 and newer are Universal - for both Apple Silicon and Intel based Macs.

USAGE: mist download installer [<options>] <search-string> [<output-type> ...]

ARGUMENTS:
  <search-string>         Specify a macOS name, version or build to download:
                          * macOS Monterey
                          * macOS Big Sur
                          * macOS Catalina
                          [...]
  <output-type>           Specify the requested output type(s):
                          * application to generate a macOS Installer Application Bundle (.app).
                          * image to generate a macOS Disk Image (.dmg).
                          * iso to generate a Bootable macOS Disk Image (.iso), for use with virtualization software (ie. Parallels Desktop, VMware Fusion, VirtualBox).
                          Note: This option will fail when targeting macOS Catalina 10.15 and older on Apple Silicon (M1) Macs.
                          * package to generate a macOS Installer Package (.pkg).

OPTIONS:
[...]

This also helps cleanup flags / options that should only apply to firmwares / installers, but not both 👍


What should we do with the warning "Cannot update a component from inside the function body of a different component."

Currently, our Provider invokes subscribed components listeners so that they can force update.
The reason why we need it is that we use the undocumented changedBits = 0 in Context API.
https://github.com/dai-shi/use-context-selector/blob/a43963373f123e380c9133eb6e1fc77a7fabc192/src/index.js#L9-L15
https://github.com/facebook/react/pull/17099 will warn this usage as it does not know about force update.
That's fair. But, unless there's another recommended way, we would need to keep our current approach.
Nobody will use this library if React shows the warning all the time. What should we do?
(Not only this library but also react-tracked and reactive-react-redux.)

Moving this to ‘useEffect’ might possibly circumvent this and make it more concurrent-friendly. This will have a small perf tradeoff I think but this could maybe be caught by wrapping in batchUpdates.

Interestingly, I didn't think about useEffect... I thought there would be a tearing issue with useEffect, but not for this case because we have only one useEffect in the parent.
I did use useLayoutEffect before obviously, which works perfectly but it de-opts to sync mode and we don't get benefit from concurrent mode.

I tried https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-mode checking again.
In summary, here's what I understand so far:
in render: all checks pass
in useLayoutEffect: check3 fails
in useEffect: check4 fails
check4 is also failing with use-subscription, so I might be doing something wrong. It would be so nice if we could use useEffect. Either, the check4 is wrong or there is another workaround.

@JoviDeCroock Thanks for the hint! and questions are welcome.

Hmm, I’ll have to double-check for myself. The only other wat I’m aware of would be a custom event emitter. Much like a proxy but a bit more manual book keeping, I’m making a PoC off that since that would increase perf even further by calling every entry max. once.
That being said it should be concurrent since effects registered in P1 should be disposed on interrupt. I’ll check what the failing test is when I can open my laptop.

Hi @JoviDeCroock
Thanks for your trial. Good to know that performance isn't an issue. My concern is the "check4" of my checking tool. We could wait and see how the discussion in https://github.com/facebook/react/issues/16396#issuecomment-545003364 goes.
My understanding is that the use of useEffect could lead to some kind of inconsistency (tearing) because it's a passive effect (other code run before that).

we can't hit a callback twice anymore

I'm not sure if I understand this part.

Hi, trying to solve a similar issue I came across this lib. I thought it's a good idea but I honestly do hate those 3 lines of code xD
Here is a quick idea:
const listeners = new Set()
const context = React.createContext(defaultValue, (prev, next) => {
  if (prev === next || !listeners.size) return 0
  listeners.forEach(l => l(next))
  return 0
})

Now, using useLayoutEffect is also not a good idea. First, when doing SSR, you'll see a warning. Secondly, we can learn something from useSubscription (written by React team)
https://github.com/facebook/react/blob/master/packages/use-subscription/src/useSubscription.js
and that's that subscriptions must not happen sync and instead be passive. See the source code comments' explanations.

@eddyw Hey, thanks for coming! Do you "hate" them because they are in render?
I haven't thought about invoking listeners in calculateChangedBits. I wonder if this eliminates the warning and if it's recommended by the react team... Side effects in calculateChangedBits don't sound natural...
I'm aware of useSubscription to some extent. It's failing my "check4" too. If it's reasonable, it's easy and we can simply move the three lines into useEffect.

@dai-shi hm, yeah, it just doesn't feel "right" doing so in render. For instance, if the provider is a child of a container that manages its own local state, every render will also trigger calling all listeners on the provider which may be unnecessary. calculateChangeBits is not widely documented, from what we know, we return a bitmask that can tell which consumers should update (if using unstable_bits ... something which isn't supported in useContext .. at least yet?). So my point is, there is no rule written in stone that prevents us from doing so and it seems like that is the only reliable way to know when provider has received a new value and if it should propagate this change. So, here is an idea:
const context = React.createContext({ value, listeners }, (prev, next) => {
   if (!next.listeners.length) return 0
   if (prev === next && prev.listeners === next.listeners) return 0
   next.listeners.forEach(l => l(next))
   return 0
})

A few points:

The problem with context is that we can't use a hook to subscribe to a certain slice of state. The problem is not that context doesn't know when to propagate this change. So using calculateChangedBits we can know when value/state has changed and only thing left is to (reinvent the wheel of) manage subscriptions.
There are several issues with using a single Set mutable object to manage subscriptions. As commented in code, it's shared, so it's not ideal. Another issue is that, I feel we could potentially be running on the same issue Redux had before with subscriptions to the store or removing subscriptions while listeners are called, something like (speudo-code):

listeners = [ a, b, c ]
...
store.subscribe(() => { //  <<< listener 'a'
  removeListener(b)
  addListener(d)
  // we end up with: listeners = [a, c, d]
  // while listener 'a' has been called
  // next listener called should be .. ???
})

What Redux does now is listeners.slice() to ensure those exact listeners are called. The same idea could be applied in calculateChangedBits where prev.listeners could be different from next.listeners and it'd be easier to debug if that's the reason of certain unwanted re-renders.
Finally, the order in which listeners are called is somewhat important. React Redux does create a kind of tree of listeners every time connect is used to ensure a parent component is updated before its children. It'd look kind of like (speudo-code, assuming all this components are connected to a store):
[
  listener-a, // <connected(Todo.Header)>
  listener-b, // <connected(Todo)>
  listener-b.listeners  [ // connected children
       listener-c, // <connected(TodoItem) id=1 >
       listener-d, // <connected(TodoItem) id=1 >
   ]
]

However, this is not possible to do with hooks, that's why react-redux warns about it if you opt to use hooks instead of connect. Maybe this is the reason of that warning? I mean, suppose you're calling listener-d which is somewhere deep in the tree while in fact react is rendering the container where the provider is. A quick dirty idea led me to try listeners.reverse().forEach(...) and it worked because the order in which those were subscribed was actually inverted but that's far from a solution and more a hack for a very specific scenario.
At least these are the issues I'm having with my implementation. I hope this helps .. somehow xD

@eddyw Hi, thanks for your detailed explanation.

calculateChangeBits is not widely documented,

True. Both calculateChangedBits and observedBits are unstable. Using observedBits in useContext raises a warning and I needed an undesired workaround in another lib of mine. Luckily, we don't have any warning for calculateChangedBits yet.

there is no rule written in stone that prevents us from doing so

Yeah, but the rule can be changed. As we've been seeing this and the useContext warning.
What I'm comfortable with is this special use case of calculateChangedBits = () => 0.
If this is disabled in the future, we could move to the readContext hack. (I'm not very familiar but that's something react-sweet-state does.)

const context = React.createContext({ value, listeners }, (prev, next) => {

You know what. This is very interesting to me. I haven't thought about passing listeners in the context value. This seems to do the hack.
I would seriously consider this if other means are all disabled.

So using calculateChangedBits we can know when value/state

Yeah, but again I'm not sure how reliable this is in the future.

on the same issue Redux had before with subscriptions to the store or removing subscriptions while listeners are called

I'm not sure if I understand this part. We never remove listeners in the callback.

Finally, the order in which listeners are called is somewhat important.

I suppose this is incorrect. React Redux now uses batchedUpdates, so the order of listeners is not important. In our case, we call listeners in render now (or effect in the past) which are basically batched. We still have the stale props issue though.

the issues I'm having with my implementation.

So, what are you trying in your implementation?

I haven't thought about passing listeners in the context value.

Yet, I had thought about passing subscribe in the context value, like I do in react-tracked.
The reason why I put the bare value in this lib is that it would allow devtools show the real context value. I'm not sure if devtools show the context value though.

@dai-shi it doesn't have anything to do with batching updates and more with stale props and zombie children explained in react-redux while using hooks:

Starting with version 5, React Redux has attempted to guarantee that consistency with ownProps. In version 7, that is implemented using a custom Subscription class internally in connect(), which forms a nested hierarchy. This ensures that connected components lower in the tree will only receive store update notifications once the nearest connected ancestor has been updated. However, this relies on each connect() instance overriding part of the internal React context, supplying its own unique Subscription instance to form that nesting, and rendering the <ReactReduxContext.Provider> with that new context value.

https://github.com/reduxjs/react-redux/blob/master/src/components/connectAdvanced.js#L394-L404
This is to ensure that listeners are called in a specific order, first the ones at the top, then the once nested inside a connected child component. However, as they mention in the docs, this seems not to be possible using just useContext because it cannot inject that overwritten context value to a provider just above the component that's using the context to form that nested hierarchy tree.

So, what are you trying in your implementation?

It's written around useReducer. So the provider is created as { state, dispatch }. That's more or less the core. However, I'm running into the same issues when using useContext with not being able to use a selector function to update only when certain values have changed. React does a good job already propagating these changes, so my primary issue right now is with the subscriptions (zombie children and stale props).

The reason why I put the bare value in this lib is that it would allow devtools show the real context value. I'm not sure if devtools show the context value though.

This is probably off-topic 🙈
Redux dev tools has an API to allow using its devtools outside of a Redux store, so I'm not worrying about that, I have a tiny wrapper around it that automatically connects it to devtools and I'm able to inspect values and dispatch actions there (which map to dispatch of useReducer):
https://medium.com/@zalmoxis/redux-devtools-without-redux-or-how-to-have-a-predictable-state-with-any-architecture-61c5f5a7716f

OK, if you have Redux background. You might be interested in this thread.

stale props

My understanding is that stale props issue with hooks can't be solved in userland. (I wrote it in README).
I'm mostly convinced by "RFC: Context selectors" and the discussion in react-redux.
But, I've once tried a heuristic approach to sort listeners by render order. (https://github.com/dai-shi/reactive-react-redux/issues/22)
I gave it up because I knew my approach is not performant.
Lately, zustand tried and did a similar approach. https://github.com/react-spring/zustand/pull/65
I don't fully understand the details, but there would be a possibility of a heuristic approach to solve the stale props issue.
That would be a good challenge and worth trying. (but yeah this is also the off-topic of this issue.)

so my primary issue right now is with the subscriptions (zombie children and stale props).

You may or may not be interested in my other projects: this and that.
Their useTrackedState doesn't have the stale props issue, because it doesn't "select" a state. It doesn't require listeners to be ordered. Just batched updates work.

Redux dev tools has an API to allow using its devtools outside of a Redux store

That's interesting.
I actually meant React devtools, but still in that case it will show state but maybe not context.
So, putting some other values in context shouldn't be a big problem anyway.

@dai-shi useImperativeHandle! 🙈
So trying to solve a completely different problem, I thought about this issue. Technically, there is an official way to expose instance methods to a parent using refs with useImperativeHandle hook.
This is kind of the idea: https://codesandbox.io/s/dazzling-euler-0kbce
Check hooks.js which is copy/paste of use-context-selector with some changes.
Basically, this is the most important change:
  const ref = React.useRef();
  const subscription = React.useRef();
  ...
  React.useImperativeHandle(ref, () => ({
    f: selector,
    v: value,
    s: selected
  }));
  React.useImperativeHandle(subscription, () => listener, [listener]);
  React.useEffect(() => () => listeners.delete(subscription), [listeners]); // <<< handle unsubscribe

   if (!listeners.has(subscription)) listeners.add(subscription); // <<< sync

So listeners are actually a collection of refs which point to a callback (forceUpdate). We subscribe in the render phase, however, that doesn't ensure that the callback will be available (render was interrupted / paused / or just on render phase). This handles the case:
    listeners.forEach(listener => {
      if (!listener.current) {
        console.warn("Render phase! Interrupted render! ... or unmounting.");
        return;
      }
      listener.current(value);
    });

Since refs are not set on the render phase (first render phase) the ref will be null however a listener will be added. So, to solve the issue we basically need to "wait" for this listener.current to  become not null to be able to force an update. Otherwise, we'd get that warning. Does it make sense? 🙈 I think that can somehow easily be solved 🤔
FYI, I tested the code in codesandbox on will-this-react-global-state-work-in-concurrent-mode and it still passes:
    ✓ check1: updated properly (8331ms)
    ✓ check2: no tearing during update (2ms)
    ✓ check3: ability to interrupt render (1ms)
    ✓ check4: proper update after interrupt (1183ms)

😅

@eddyw I haven't thought about useImperativeHandle.
I'm not sure if I understand the point, but do you mean that we can eliminate the warning message with this approach?

The point of useImperativeHandle is to customize and expose instance methods to a parent through refs. So it won't attach the ref if it's in the "render phase". useImperativeHandle seems to happen at the same time useLayoutEffect, it's sync but both don't happen during "render phase". This is a simple test I made, it basically just logs once a ref is attached and when a useLayoutEffect is run:
[Imperative] Rendering! 1
[Imperative] Rendering! 2
[Imperative] Rendering! 3
[Imperative] Rendering! 4
[Imperative] useLayoutEffect 1
[Imperative] useImperativeHandle 1 // refs attached here
[Imperative] useLayoutEffect 2
[Imperative] useImperativeHandle 2 // refs attached here
[Imperative] useLayoutEffect 4
[Imperative] useImperativeHandle 4 // refs attached here
[Imperative] useLayoutEffect 3
[Imperative] useImperativeHandle 3 // refs attached here

Since we're using useLayoutEffect, we technically shouldn't run into this issue if the subscription happens there. However, I don't know what the case will be if render is interrupted / paused with useLayoutEffect. Since useImperativeHandle was made to expose instance methods to a parent once "it's ready", I assume this will be null if interrupted / paused. Otherwise, you wouldn't be able to do:
React.useImperativeHandle(ref, () => ({ setState }))

which is perfectly legal.

So it won't attach the ref if it's in the "render phase".

Hmm, as I understand the warning will be shown when we invoke listeners in provider, not when we subscribe listeners in children. I'm just guessing though.

https://github.com/facebook/react/pull/17099/files#diff-63c455475b8566c10993b2daa2c3211bR2666
warn About "Render Phase" Updates In DEV 🙈

Hmm, as I understand the warning will be shown when we invoke listeners in provider, not when we subscribe listeners in children. I'm just guessing though.

Ok, so maybe we understand the problem in a different way 😛
Technically, the first time provider renders, there are no listeners (you can do console.log(listeners.size) // 0). The listeners are added with useLayoutEffect that we could think of as componentDidMount. So, useLayoutEffect is actually async, only the updates you make within are scheduled to be sync. The point is, the listeners are not added in the "first" render phase but after a complete first render phase which means, calling listeners in the provider render won't cause this issue because the listener is not added in the "render phase".

warn About "Render Phase" Updates In DEV

what I understand is it warns the invocation of dispatch (of useReducer). 🤔

Yes the above should still throw, the way I found that it doesn't is if you call a function that has been bound in render like: https://github.com/JoviDeCroock/hooked-form/blob/master/src/useContextEmitter.ts#L8

Yeah, useEffect solves my-understanding-of-the warning. My concern is "check4" which I would call parent/child tearing. Probably it would not happen in the hooked-form use case.
(I am still interested in how hooked-form is implemented. I could learn real use cases. It would be nice to continue the discussion in #8.)

const context = React.createContext({ value, listeners }, (prev, next) => {

You know what. This is very interesting to me. I haven't thought about passing listeners in the context value. This seems to do the hack.
I would seriously consider this if other means are all disabled.

Turns out it doesn't solve the issue with this hack. 😕
Now, what's left:

useLayoutEffect and give up getting benefit from CM
useEffect and somehow solve parent/child tearing issue (no idea yet)
completely move away from context and emulate context behavior with subscriptions with versioning? (too much work, not sure if it will really be CM-compatible and get its benefit)

The third option will be something like a completely different library. The second one may sound good, but it's potentially doing something different. I'd go with the first option with opt-in (the current) update-in-render mode for production.

Just in case, let me ping @acdlite and see if he can give us an advice.
Andrew, you don't need to read the whole thread, the question is rather simple: We use forceUpdate,
https://github.com/dai-shi/use-context-selector/blob/a43963373f123e380c9133eb6e1fc77a7fabc192/src/index.js#L58
and invoke it from a different component.
Is it not recommended in CM? I assume https://github.com/facebook/react/pull/17099 warns this usage. (Well, I actually tried your branch.)

Hm, ok. So yeah, I understood that the warning may be happening if child is in render phase while the action is dispatched 🤦♂

useEffect and somehow solve parent/child tearing issue (no idea yet)

I had an idea, I did:
  const [prevValue, setPrevValue] = React.useState(value);

  React.useEffect(() => {
    listeners.forEach((listener) => {
      listener(value);
    });
    setPrevValue(value);
  }, [value]);

  return React.createElement(OrigProvider, { value: prevValue }, children);

Since Main is direct child of the provider, just by providing a new value will cause the provider children to re-render, so Main will actually get the current value not from listener(value) but from re-rendering. So I thought maybe delaying setting the value on the provider until we updated subscribed once first would do the trick. Turn out, this works ... sometimes. Out of 10 tests, it passed 7 times which makes me wonder if this is a bug in async rendering (experimental). I tried to follow a different approach, instead of forceUpdate I directly set the current value:
export const useContextSelector = (context, selector, id) => {
  const listeners = context[CONTEXT_LISTENERS];
  if (!listeners) {
    if (process.env.NODE_ENV !== 'production') {
      throw new Error('useContextSelector requires special context');
    } else {
      throw new Error();
    }
  }

  const initialValue = React.useContext(context);
  const [selectedValue, setSelectedValue] = React.useState(() => selector(initialValue));
  const selectorRef = React.useRef(null);

  React.useImperativeHandle(selectorRef, () => selector);

  React.useEffect(() => {
    const callback = (nextValue) => {
      console.log('[%s] Calling setSelectedValue', id, nextValue);
      setSelectedValue((prevSelectedValue) => {
        try {
          const nextSelectedValue = selectorRef.current(nextValue);
          if (nextSelectedValue === prevSelectedValue) return prevSelectedValue;

          console.log('[%s] Setting this value:', id, nextSelectedValue, prevSelectedValue);
          return nextSelectedValue;
        } catch (e) {
          console.warn(e);
        }
        return null;
      });
    };

    listeners.add(callback);

    return () => {
      listeners.delete(callback);
    };
  }, [listeners]);

  return selectedValue;
};

So useContextSelector received a third argument which is an id. This is just to track updates. It logs when the callback is called and when it should call setSelectedValue but apparently this doesn't happen .. sometimes. It's failing that test4 about ~3 out 10 times 🤔

Ok, this is what I did that worked:
This gave me an idea -> https://reactjs.org/docs/concurrent-mode-patterns.html#baking-transitions-into-the-design-system
  React.useEffect(() => {
    listeners.forEach((listener) => {
      listener(value);
    });
  }, [value]);

And:
const [startTransition] = React.useTransition({ timeoutMs: 1 });
...
startTransition(() => forceUpdate());

However, test3 will fail:
    Expected: < 300
    Received:   580.3

In async mode, it seems like there is a kind of race condition if you call forceUpdate or setSelectedValue while one of them is still running, so the next one seems to be stopped. Not sure if this is a bug or expected behavior but useTransition seems to .. solve the problem?

I think it’s the behavior that I’m checking with check4. I haven’t tried if useTransition solves it.

I tried useTransition, but it seems to me that it doesn't improve anything.
Honestly, I really want to avoid using useEffect which is something really different.
(Surely, useState + useEffect solves the warning, but it is so delayed. It will tear if you use the normal context and this special context.)

I mean, keeping as is, just use useEffect for listeners and wrap forceUpdate in a transition. Did you set timeoutMs? If it's 0 it has no effect, so I set to 1. It's faster than sync updates but slower than 300ms (took about 500ms). I'll try to put it on a codesandbox once I'm home.

Also, I thought that maybe this will make more sense:
React.useEffect(() => {
    startTransition(() => {
      listeners.forEach((listener) => {
        listener(value);
      });
    });
  }, [value]);

According to docs, I understand that everything within the transition will make all the updates work like if they were a separe branch. So after the timeout, all components ""should"" technically display the same value. However, I'm away from my laptop to try this right now. I'll see how this works later.

Meanwhile, let me explain why I don't want to use useState + useEffect.
const Ctx = createContext(null);

const Children = ({ count }) => {
  const value = useContext(Ctx);
  if (count !== value.count) {
    console.log('tear!!!');
  }
  return <div>{count}, {value.count}</div>;
};

const Parent = () => {
  const [count, setCount] = useState(1);
  return (
    <Ctx.Provider value={{ count }}>
      <button onClick={() => setCount(c => c + 1)}>Click me</button>
      <Children count={count} />
    </Ctx.Provider>
  );
};

I didn't run this, but I assume something like this leads to tear with useEffect.

It won't cause tearing 😛
I mean, it will cause a visual tearing but this won't happen:
  if (count !== value.count) {
    console.log('tear!!!');
  }

useLayoutEffect just makes the update sync before commit, so that's why you can't actually see the "visual tearing" when it happens.
You mention:

useLayoutEffect and give up getting benefit from CM
useEffect and somehow solve parent/child tearing issue (no idea yet)
completely move away from context and emulate context behavior with subscriptions with versioning? (too much work, not sure if it will really be CM-compatible and get its benefit)

I think 2. is rather easy to solve. The main issue is that Provider children re-render when a new value is passed to Provider. This doesn't really happen with external stores because a state update isn't even associated with React.
I believe that will-this-react-global-state-work-in-concurrent-mode is not entirely fair ? For instance, useSubscription test is using an external Redux store, so all listeners are called from Redux. However, useContextSelector is using React useState which behaves differently, a change in state will immediately cause the Provider children to re-render, so you're trying to compete with it doing:
 listeners.forEach((listener) => {
   listener(value);
 });

If you make it so Provider children don't re-render when value changes, then it'd be entirely up to the above code to update them. What I mean is, it's two different problems. What I do right now is, React.useMemo(() => children, []), so it won't re-render children and they'll be updated only when listeners are told to force update. However, maybe there is a better way to handle this. I hope this makes sense 🙈

If you make it so Provider children don't re-render when value changes

We can't assume this. Children can re-render at the same time Provider re-renders.
const Children = () => {
  const [count, setCount] = useContext(Ctx);
  const [localCount, setLocalCount] = useState(1);
  return (
    <div>
      <div>{count}</div>
      <div>{localCount}</div>
      <button onClick={() => { setCount(c => c + 1); setLocalCount(c => c + 1); }}>Click me</button>
    </div>
  );
};

const Parent = () => {
  const value = useState(1);
  return (
    <Ctx.Provider value={value}>
      <Children />
    </Ctx.Provider>
  );
};

ash, I was just making a point. Maybe I can summarize all without going in circles 🙈

using useLayoutEffect or calling the listeners directly in render causes a blocking update. So in reality, you give up the benefits of CM in both.

I made this Sandbox: https://codesandbox.io/s/nice-beaver-9uli8
I just copied the current code of useContextSelector but modified the example to use transitions and suspense (as explained in React docs "Concurrent UI Patterns") in one component that also uses useContextSelector. If you click Increment Remote Count enough times (at different intervals), you will eventually see this warning:
Warning:  triggered a user-blocking update that suspended.

The fix is to split the update into multiple parts: a user-blocking update to provide immediate feedback, and another update that triggers the bulk of the changes.

Refer to the documentation for useTransition to learn how to implement this pattern.

This is because forceUpdate is a blocking update, so it's not CM friendly 🙄
This is explained here: https://reactjs.org/docs/concurrent-mode-patterns.html

Using useEffect will just remove that warning.

The Provider parent / child tearing is a different problem caused because Provider re-renders its children.
Using useEffectLayout solves only the ""visible"" tearing problem.
Using call listeners in render phase will cause the warning, so the solution isn't finding another sync blocking alternative that will be async mode friendly 🙃 (if it makes sense to say so)

Current (experimental) docs regarding concurrent patterns recommends baking useTransition into the design system components of the app: https://reactjs.org/docs/concurrent-mode-patterns.html#baking-transitions-into-the-design-system
This should, somehow, be within forceUpdate or whatever that causes an update in the component, so if it's wrapped within Suspense it won't cause the warning Warning:  triggered a user-blocking update that suspended.. If it's not wrapped within Suspense, it won't matter if it's within startTransition, it will still work

@eddyw Thanks for the summary.
Unfortunately, it seems to me like we are still not on the same page.
Let me focus on one thing step by step.

calling the listeners directly in render causes a blocking update.

As far as I understand, it doesn't block. (Or we might be using "block" in different meanings.)
forceUpdate is a setState function which doesn't change the state immediately, but just marks a component to render later with a new state. (Here "later" means in the same render cycle. Not sure about the precise term.)
So, the current code works perfectly in CM. I only care about the warning, and my assumption is that this warning is not applicable to our case because we don't use the forceUpdate's counter value. (It would be really nice if someone can endorse that.)

@dai-shi ok, so I'll leave aside the issues I'm trying to solve for now 😛

my assumption is that this warning is not applicable to our case because we don't use the forceUpdate's counter value

Actually, this has nothing to do with using the value, the state is updated regardless. You can test it yourself:
let setState = null;
class A extends React.Component {
  state = { v: 0 };
  render() {
    setState = this.setState.bind(this);
    return null; // <<<<< not using value
  }
}
class B extends React.Component {
  render() {
    setState({ v: Math.random() });
    return null;
  }
}
...
<A />
<B /> // << warning

While a component can update itself in the "render phase" (at least on functional components, is this missing test in React PR?), a component can't or shouldn't update other components state while in "render phase". To be more specific, this is in "initial render phase" before life-cycle methods are attached. If you put a setTimeout(() => setState(...), 16), in the example above, you'll see the warning disappears because both components will exit "render phase", they will have life-cycle methods attached, and in "commit phase". It's a bit difficult to reason about in functional components because a functional component is just a function, it doesn't mean that the first time it's called, what you return will be rendered. In CM this initial "render" can be interrupted and thrown away so it's not safe.
It "may" work as it is right now without displaying warning:

Children subscribe using useLayoutEffect, so technically there won't be listeners the first time Provider is called (note I said "called" not "rendered"). You add listeners in a child component's "commit phase" (useLayoutEffect before browser paint), so we can assume the provider rendered (otherwise it wouldn't have children)
Since state lives inside React, it should be .. impossible? to try to update the Provider's parent value (through props) while this one is in "initial render phase", so as long as React manages the state passed to the provider, it should be ok?

This may help:
https://twitter.com/dan_abramov/status/981712092611989509?lang=en

@eddyw Welcome back. Now we are discussing the same issue. Uh, probably.
Sorry that my wording is a bit unclear.

a component can't or shouldn't update other components state while in "render phase".

This is my question. Does this apply to the forceUpdate use case? I think it's OK-ish.
(If there is an issue even with the forceUpdate use case, I'd use useLayoutEffect which I used to do.)

Children subscribe using useLayoutEffect

You might miss the point (at least the one I see). The warning is not shown for children subscribing parent, but parent notifying children in our case.

🤦♂ I mentioned:

It "may" work as it is right now without displaying warning

And point 1 and 2 explain why. However, I decided to do one test more:
https://codesandbox.io/s/peaceful-sun-08g72
And it'd actually break, you can think of setState in demo as listeners and component B as the provider which "calls its listeners" on render phase when it receives a new prop force={true | false}. So the warning will in fact happen.

Again, this has nothing to do with "using the value". Regardless if you do or not use the value of forceUpdate, it'll cause the warning. In demo, you can set the return in "render" method to null if you want to try it out.

And point 1 and 2 explain why.

Sorry, I will read it again.
Meanwhile,

Again, this has nothing to do with "using the value". Regardless if you do or not use the value of forceUpdate, it'll cause the warning.

This is I'm aware of. My question is whether the warning is valid or not in our use case.

It "may" work as it is right now without displaying warning:

OK, I misread this one. You said "as it is right now".

So the warning will in fact happen.

Yes, I have already confirmed that with one of the examples.

Do you think this warning is valid for the use case in this project?

I believe the warning will in fact happen. At least from testing a pseudo implementation using Class components. From what I see in that PR, there is one missing test. I think this relates to a component updating itself in render phase.

I already confirmed this warning in fact happens with the branch in that PR.
I'm wondering if I can ignore the warning in our case, or if there's a fundamental issue even with our use case. Naively, it seems OK, but in CM, maybe not?

useLayoutEffect and give up getting benefit from CM

This is the final resort, but according to https://github.com/facebook/react/issues/17334#issuecomment-554075523

synchronous render, React also flushes the remaining/pending effects (including the passive ones

I didn't expect the de-opt case flushes passive effects. It's a huge downside.
Really want an escape hatch for https://github.com/facebook/react/pull/17099, if we can ignore the warning with our use case.

https://github.com/facebook/react/pull/17099 is merged now.
Hopefully, with useMutableSource, it will be fine. Let's wait for it.
Draft PR: https://github.com/dai-shi/use-context-selector/pull/12

Found a solution:
useLayoutEffect(() => {
  runWithPriority(NormalPriority, () => {
    // ...
  });
});

Hmmmm, this solution still leads tearing in useTransition.

I made a proper fix in react-tracked: https://github.com/dai-shi/react-tracked/pull/42
This is only possible because react-tracked has "update" function.
This is not possible with useContextSelector in userland, because update only happens in render. #13 is still a dirty workaround for now, until v2 lands (#12).


Register Camel properties as excluded by default

follow up to https://github.com/redhat-developer/vscode-microprofile/issues/22

Fixed with https://github.com/redhat-developer/vscode-microprofile/issues/30


Don't parse the things that are part of http(s) links

Fixes the regex to not parse anything that is part of a link (http or https)

LGTM
I love saying that!


Undefined function or variable 'skew'.

When i run the demo, error occurs!
Undefined function or variable 'skew'.
Error in reprojectLaserCalib (line 41)
L(4:6,:) = -skew([0;0;10]) * LrsPts;
Error in optimizeLaserCamCalib (line 37)
y                = reprojectLaserCalib(x0,xdata);
Error in lccMinSol (line 71)
[T, r, ri] = optimizeLaserCamCalib(Ti, Tp(:,:,inl), Pl(inl));
Error in demo (line 22)
[T, r, inl, Ti, ri] = lccMinSol(Planes, Points,T_set);
Can you offer the function skew? Thank you!

The commit 834fc96419f8d2838a3726399de07505f5a0e660 should fix this.
Anyway, I and my colleague didn't have the time to polish this project as much as we would have liked. If you find more missing dependencies, maybe you can look at my collection of common math functions in Mmath.


Provide transparency when chunk result counts are maxed out

User Story
As an application developer, I want to know when my query may be at risk of incomplete results due to the CloudWatch Logs Insights 10K result limit.
Task list

Add a counter field to the Stats structure.
Update QueryManager code to increment the counter.

Stats counter field sketch
type Stats struct {
        // ChunksMaxed counts the number of chunks belonging to the
        // stream or query manager for which the chunk contained the
        // maximum number of results (MaxResults) even after splitting.
        //
        // This field can be used to assess whether and to what extent
        // the returned results are
        //
        // (By making it a floating point value, it can possibly
        // reflect splitting, i.e. if a quartered chunk still maxes out
        // we can have ChunkMaxed = 0.25.)
        ChunksMaxed float64
}

This is done and will go out in the 1.3.0 release.


Any Plans to Support ntfy.sh Token Authentication?

I'd prefer to configure this to use a Token for sending to my ntfy.sh server rather than using Basic Auth username/password. Are there any plans to support this, like your PHP library?

I've been meaning to add support for this since last year but never got around to it. Anyway #102 addresses this.

So I'm not sure if I have the token verification configured wrong but I'm noticing that I've received the following error in a recent run.

[Notification error] [Ntfy] forbidden (code: 40301)

Disregard, I just realized that the NOTIFICATION_NTFY_AUTH configuration was change from true to password or token.

I also just tried changing it to username/password and I'm also receiving an authentication error. I was also trying with the URL using both a trailing slash and without.

@VerifiedJoseph so, looking at your tests and your code and it appears your documentation is wrong and the ntfy configuration settings are all missing VIGILANT_ as the leading name requirement.
https://github.com/VerifiedJoseph/vigilant/blob/main/docs/configuration.md

I did confirm that by properly adding the missing leading VIGILANT_ it is now working.

Oops, my bad, should've noticed that. I've merged #108


Publish mutiple versions

Accept documents with different version on publishing
-Update the base model class to handle creating/validating documents with
different 'doc_version'

-Add test case to test_publish that publishes/validates three documents of different
doc_versions (0.23.0, 0.21.0, 0.11.0)

-Restructure the directories that holds the model definition/description source data

-Update the development.ini file to use the new path for the models description/
definition.

John I get this
Traceback (most recent call last):
File "/home/wegrata/virtualenv/lr/bin/nosetests", line 8, in
load_entry_point('nose==1.1.2', 'console_scripts', 'nosetests')()
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/nose/core.py", line 118, in init
**extra_args)
File "/usr/lib/python2.7/unittest/main.py", line 94, in init
self.parseArgs(argv)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/nose/core.py", line 135, in parseArgs
self.config.configure(argv, doc=self.usage())
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/nose/config.py", line 339, in configure
self.plugins.begin()
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line 94, in call
return self.call(*arg, **kw)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line 162, in simple
result = meth(*arg, **kw)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/pylons/test.py", line 74, in begin
relative_to=path)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 272, in loadobj
return context.create()
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710, in create
return self.object_type.invoke(self)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 146, in invoke
return fix_call(context.object, context.global_conf, **context.local_conf)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/paste/deploy/util.py", line 56, in fix_call
val = callable(*args, **kw)
File "/home/wegrata/src/LearningRegistry/LR/lr/config/middleware.py", line 36, in make_app
config = load_environment(global_conf, app_conf)
File "/home/wegrata/src/LearningRegistry/LR/lr/config/environment.py", line 32, in load_environment
config['routes.map'] = make_map(config)
File "/home/wegrata/src/LearningRegistry/LR/lr/config/routing.py", line 17, in make_map
from lr.model import LRNode
File "/home/wegrata/src/LearningRegistry/LR/lr/model/init.py", line 15, in
from resource_data import ResourceDataModel, appConfig
File "/home/wegrata/src/LearningRegistry/LR/lr/model/resource_data.py", line 24, in
BaseModel = createBaseModel(SPEC_RESOURCE_DATA, DB_RESOURCE_DATA)
File "/home/wegrata/src/LearningRegistry/LR/lr/model/base_model.py", line 45, in createBaseModel
class BaseModel(object):
File "/home/wegrata/src/LearningRegistry/LR/lr/model/base_model.py", line 53, in BaseModel
_modelParsers = getModelPasers(modelSpec)
File "/home/wegrata/src/LearningRegistry/LR/lr/model/base_model.py", line 40, in getModelPasers
parser = ModelParser(path.strip())
File "/home/wegrata/src/LearningRegistry/LR/lr/lib/model_parser.py", line 224, in init
self._extractData()
File "/home/wegrata/src/LearningRegistry/LR/lr/lib/model_parser.py", line 387, in _extractData
self._parseResults =  ModelParser.OBJECT.parseString(self._fileString)
File "/home/wegrata/virtualenv/lr/local/lib/python2.7/site-packages/pyparsing.py", line 1032, in parseString
raise exc
pyparsing.ParseException: Expected "{" (at char 0), (line:1, col:1)
When I run the unit tests

Walt,
You are probably using your old development.ini which does not have the correct path for the ressource_data spec definition files.

I ran the update node_setup.py.
This is the section from my development.ini
specs_dir = %(here)s/data/specs
spec.models.node_description = %(specs_dir)s/v_0_23/models/node_description
spec.models.resource_data = %(specs_dir)s/v_0_23/models/resource_data,
%(specs_dir)s/v_0_21/models/resource_data,
%(specs_dir)s/v_0_17/models/resource_data,

Walt,
The problem was that the resource_data spec files were rename 'resource_data_description'.  I had corrected them in my local .ini but failed to change the .ini.orig file.  The recent commit should fix the problem.


Manually revert 10069

Details
The changes in https://github.com/Expensify/App/pull/10069 unintentionally broke the existing behavior the report page which is that the ReportActionsView can be mounted simultaneously as the sidebar is open. Unmounting the ReportActionsView breaks the ability to:

Get the most up to date report action when returning from offline.
Various logic that checks to see if the drawer is open is now dead code as the drawer is always closed.

Also seems bad for performance to unmount the report unnecessarily. So I would suggest we look into alternative solutions and rollback this partial solution that breaks other things.
Fixed Issues
https://github.com/Expensify/App/pull/10069#issuecomment-1222408153
Tests

View the app on a small screen size
Navigate to a report
Navigate back to sidebar
Verify the ReportActionsView did not unmount and visible in React dev tools
Go offline
Go online
Verify in Network tab of Chrome Dev Tools that report actions are fetched (i.e. a call to Report_GetHistory can be seen)

[ ] Verify that no errors appear in the JS console

PR Review Checklist

Contributor (PR Author) Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] Any functional components have the displayName property
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps

View the app on a small screen size
Navigate to a report
Navigate back to sidebar
Slide the drawer and verify the report is visible beneath but do not navigate to it
Go offline
Leave a comment on the report as another user who is online
Go online as the user who was offline
Slide the drawer and verify the new message is at the bottom of the report

[ ] Verify that no errors appear in the JS console

Screenshots

Web

Mobile Web

Desktop

iOS

Android

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @AndrewGable in version: 1.1.89-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

Confirmed this is working on Android 👍

https://user-images.githubusercontent.com/3885503/186481003-35f5441a-3dfb-4908-906b-cb7a0ab97ed1.mp4


ML Kit FaceDetectionProcessor from sample app not detecting ears

Issues details:
I tried the ML Kit Face detection sample app from here but was not able to receive landmark data for the ears while running the LiveDataPreviewActivity. The call face.getLandmark always returns null for FirebaseVisionFaceLandmark.LEFT_EAR and FirebaseVisionFaceLandmark.RIGHT_EAR. All other landmarks are highlighted and retrieved just fine.
Should this work fine? Or is this issue beta version related?
Tested on:
Google Pixel (Android 8.1.0)
Samsung Galaxy S6 (Android 7.0)
Relevant Code:
drawLandmarkPosition(canvas, face, FirebaseVisionFaceLandmark.LEFT_EAR)
drawLandmarkPosition(canvas, face, FirebaseVisionFaceLandmark.RIGHT_EAR)
...
private fun drawLandmarkPosition(canvas: Canvas, face: FirebaseVisionFace, landmarkID: Int) {
        val landmark = face.getLandmark(landmarkID)
        landmark?.let {
            val point = landmark.position
            canvas.drawCircle(
                    translateX(point.x),
                    translateY(point.y),
                    10f, idPaint)
        }
    }

https://github.com/firebase/quickstart-android/blob/master/mlkit/app/src/main/java/com/google/firebase/samples/apps/mlkit/kotlin/facedetection/FaceGraphic.kt#L115

Hi all,
I received yesterday an official answer from firebase tech support (thanks again!) and they recommended adding this in build.gradle:
implementation 'com.google.firebase:firebase-ml-vision-face-model:17.0.2'
... and that was it. Ears are now detected properly in the sample app ;)
I created a pull request for this... hope it gets accepted :)
Cheers and all the best,
Marian.

Fixed in #709


Feature/create structure

In this branch, I did the following:

Set up linters.
Set up webpack.
Create a src folder with this files inside:
[ ] index.html (and set it as a template using the HTML Webpack Plugin in the config file).
[ ] index.js (and set as entry in the webpack config file).
[ ] style.css (and set Webpack Style/CSS Loaders).
Create "renderList" function to render all tasks in the html.
Add styles to all elements in te html.
Add asset rule on the config files to display the icons needed.

Thanks for your review @vickymarz! cheers! 🙌


fix: fixed genesis-network.json file lock issue

Description
This pull request changes the following:

fixed genesis-network.json file lock issue
commented out solo chart and hedera version overrides in taskfile
updated taskfile to work without solo chart and hedera version overrides
updated taskfile to clean up tmp files
updated Solo to use hedera version default when no release tag is provided

Related Issues

Closes #1027

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Replace visited instructions with ancestry sets

This fixed #34.
This is a implementation to detect cycles in a graph by using a Union-Find algorithm with a Disjoint Set.
Also, the test coverage is now 100%.

While promising, it seems that this approach unfortunately has some correctness issues. I'll close this for now until we have time to revisit this optimization.


.key.pem files are not being generated either in Windows or in Linux

After following the instructions on creating demo certificates for testing IoT Edge device, I could not find the following key generated in any of the cases:
iot-edge-device-identity-.key.pem
iot-edge-device-identity-.key.pem
iot-edge-device-ca-.key.pem
iot-device--primary.key.pem
iot-device--secondary.key.pem
iot-device-.key.pem
For example, after running the below command to create downstream device certificates, following certificates were generated:
PS C:\mycerts> New-CACertsDevice "mytestdev-primary"

- iot-device-mytestdev-primary-full-chain.cert.pem
- iot-device-mytestdev-primary.cert.pem
- iot-device-mytestdev-primary.cert.pfx

while 4 numbers of files were expected (.key.pem is missing):

iot-device-mytestdev-primary-full-chain.cert.pem
iot-device-mytestdev-primary.cert.pem
iot-device-mytestdev-primary.cert.pfx
iot-device-mytestdev-primary.key.pem

Thank you!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 869192a9-b222-7355-f5e5-fe2c72a62a03
Version Independent ID: 1581b3d6-9aa5-eea5-0d44-dccd67bad8d8
Content: Create test certificates - Azure IoT Edge
Content Source: articles/iot-edge/how-to-create-test-certificates.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

Hello @ravipath
Thanks for the feedback! We are currently investigating and will update you shortly.

Hello @ravipath
Please have a look at the working directory path///
Few Certificates are placed inside the folder name 'certs' and the other private key files are placed inside 'private' folder

Please let us know if you can see the files/

Yes, thank you. The files are present.


Implements anxcloud_core_location data-source

Description

Implements anxcloud_core_location data-source. Allows Location to be fetched by it's human-readable code-identifier.
Acceptance tests

[x] Have you added an acceptance test for the functionality being added?
[ ] Have you run the acceptance tests on this branch?

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccXXX'
...

Release Note
Release note for CHANGELOG:

* core/v1/Location - implement singular anxcloud_core_location data-source (matched with `code` argument)
* upgrade go-anxcloud dependency to 0.4.2

References

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Failing test shouldn't be related.


Optimization for tokenizing string literal.

We need to optimize the tokenizer, with string literals and templates.
Do some refactors, replace String.fromCharCode with string slices.

代码在 2.0 分支上？

@Aladdin-ADD Sure.

I'm closing this as fixed.  It will land in my PR within a few days. 66 000 string literal tests will back up my words!


Safe-Settings GitHub App not working with GHES

Hello,
When configuring Safe-Settings with our GHES Staging instance, we're finding that after following the deployment instructions the Safe-Settings application throws 500 status codes back to GHES when the it sends a webhook response. Included is the error message generated by the application.
AggregateError:
TypeError: Cannot read properties of undefined (reading 'data')
at ConfigManager.loadYaml (/opt/safe-settings/lib/configManager.js:28:34)
at async syncAllSettings (/opt/safe-settings/index.js:17:29)
at async Promise.all (index 0)
at async middleware (/opt/safe-settings/node_modules/@octokit/webhooks/dist-node/index.js:355:5)

This issue was resolved internally.  Some of the environment variables were not getting included from the .env file while creating the Docker image.


[FEATURE] Allow more content type for neural query with multimodal

Is your feature request related to a problem?
Currently neural-search supports text and image fields for generation of embeddings in both ingestion and search. Content can be of other types like audio or video information, and that is not supported today, e.g. for search there are only query_text and query_image fields.
What solution would you like?
Ability to pass content like audio or video for data ingestion and search.
What alternatives have you considered?
We can use other solutions to generate embeddings for audio or video content, and then post process results from OpenSearch and other systems.
Do you have any additional context?
It's a good extension for https://github.com/opensearch-project/neural-search/issues/318

For videos, does it make sense to extract all the frames in a video and then generate embeddings for each frame? Likewise, for audio, would it make sense to make a transcription of the audio and then generate embeddings on the transcript?
I imagine there are issues with these approaches, but these were my first thoughts and I was wondering if anyone had suggestions for something better.

For videos, embeddings for frame makes sense. For audio, transcription will lose some information like intonation or volume of the audio.


none UTF8 character in javadoc comment

[javac] /home/chris/development/SpritePlacer2/src/org/dyn4j/collision/manifold/ClippingManifoldSolver.java:47: error: unmappable character for encoding UTF8
[javac]  * Uses Sutherland�Hodgman clipping to clip the closest features of the two {@link Convex} {@link Shape}s to obtain

Possibly as my build.xml treats warnings as errors? is there a javadoc UTF8 compatible way to express the included character?

Interesting.  That should be just a '-' character...

looking via git hubs web view (of the source), it seems that a '–' character snook in instead of a '-' character...  –!=-  !!

ahh, I'll get that taken care of.  Are you trying to build the anode branch or master?

I just pulled from the url on the github site and directly included the
src folder in my project - so I assume its the master branch ?
On 11/08/15 23:23, wnbittle wrote:

ahh, I'll get that taken care of. Are you trying to build the anode
branch or master?
—
Reply to this email directly or view it on GitHub
https://github.com/wnbittle/dyn4j/issues/17#issuecomment-130095954.

Yeah, that's the master branch.  I've fixed this in the anode branch, which will soon (next few weeks or so) be merged into master.  anode has a good bit of breaking changes, so it's probably best to work of that.

Implementation of the GilbertJohnsonKeerthi (GJK) algorithm for collision detection.
just did a recent pull (you have been busy!)

also...!

@see GJK (GilbertJohnsonKeerthi)
@see GJK  Distance & Closest Points

....and!
* @see GJK  Distance & Closest Points

doh!

Should all be taken care of now.


Do not reject peripherals without registers

For TM4C, interrupts cannot be automatically, easily, or possibly
at all (since SVD does not define how interrupt sharing should work)
be associated in an 1:n fashion to peripherals.
Since svd2rust does not really care where the interrupts are in SVD,
I simply emit a fake peripheral with the complete list of interrupts
(but no registers at all). This peripheral thence does not show up
in the generated code, except in mod interrupts.
The SVD specification permits this behavior (the <registers>
element is marked as 0..1 occurrences; nowhere in the text
I could find a requirement that a peripheral have registers;
and it passes schema validation).

:pushpin: Commit b22a910 has been approved by japaric

in an 1:n fashion to peripherals.

By this, do you mean that the same  (with the same interupt number) appears in several  trees?
In any case, this change looks good to me.
@homunkulus r+

:hourglass: Testing commit b22a910 with merge b22a910...

:sunny: Test successful - status-appveyor, status-travis
Approved by: japaric
Pushing b22a910807f708f3a9ac46c5f58a16fa247c2aa7 to master...


Vulkan capture not working when Vulkan loader is statically linked

Currently in WrappedVulkan::vkCreateInstance we have this code:
  void *module = Process::LoadModule(VulkanLibraryName);
  PFN_vkEnumerateInstanceExtensionProperties enumInstExts =
      (PFN_vkEnumerateInstanceExtensionProperties)Process::GetFunctionAddress(
          module, "vkEnumerateInstanceExtensionProperties");

  uint32_t numSupportedExts = 0;
  enumInstExts(NULL, &numSupportedExts, NULL);

  std::vector<VkExtensionProperties> supportedExts(numSupportedExts);
  enumInstExts(NULL, &numSupportedExts, &supportedExts[0]);

When I load ANGLE's tests for capture, RenderDoc explodes when it tries to call  enumInstExts which is null. module is also null from the call to Process::LoadModule, because ANGLE never loads vulkan-1.dll. It links in the Vulkan loader statically, which calls right into the driver (as far as I can see, not entirely sure how it works).
Is it possible to change RenderDoc (or barring that, ANGLE) such that we can use Vulkan capture?

At the moment renderdoc only uses this list to try and enable debug report when available. It could easily just add an if(module) in the appropriate place and leave the supportedExts list empty, that would work for now.
But I think I should be able to use the pfnNextGetInstanceProcAddr used to fetch the vkCreateInstance function pointer, since that's what I do after creating the instance. I just wasn't entirely sure at the time whether that was valid before calling vkCreateInstance.

Thanks.. checking for nullptr got a bit farther - this time into Vulkan_CreateReplayDevice, where the module check fails again. I did have it working before at one point, not sure if something changed.

That call happens at replay time - that suggests you don't have vulkan-1.dll at all on your system? RenderDoc won't work in this situation, I'm not going to statically link the vulkan loader so the runtime must be installed - plus any compatible vulkan driver should install it as part of its package.

That's correct, vulkan-1.dll is not being loaded. I'm building the loader myself and statically linking. It might be present in the system somewhere (I do have the SDK installed, and it's in there) but not in the default search paths when I'm running RenderDoc.

The SDK runs the vulkan runtime installer, and puts it in the system directory (C:\Windows\System32). Something sounds wrong if you're not able to load it at all. Does the SDK's cube sample run? It's linked to  vulkan-1.dll instead of LoadLibrarying it, but the effect is the same.

It does not run. I can try reinstalling my graphics drivers - I've just been running ANGLE (OpenGL ES on Vulkan) so haven't been using the more common use cases of loading entry points.

It definitely sounds like your setup is in a strange state. When the SDK is installed it should be in a good state, so it sounds like something corrupted it since then.

Is the SDK required or is the driver install sufficient?

The driver should also install the vulkan runtime, yes.

Driver reinstalled, works like a charm. Must have been a problem with my messed-up setup. Thanks!


build(gradle): Obsolete build dependencies

Refactor to use jvmTarget from 1.7 to 1.8
Remove buildToolsVersion 26.0.2 to use 28.0.3 by default
Refactor compile to implementation
Refactor provided to compileOnly
Modify targetSdk and compileSdk version from 26 to 28
Change kotlin-stdlib-jre8 to kotlin-stdlib-jdk8
Fix jacoco version to 0.1.4 to support gradle 5.4.* & above
Update gradle tools to 3.6.0
Update kotlin plugin version to 1.3.61
Update gradle wrapper to 5.6.4
Update RxKotlin version

this is already merged here #2


Some Direct Challenges are not tracked right

Four games using Direct Challenge had issues tracking the local deck, so they appear broken on both Matches and on Social Feed.

Logs: https://1drv.ms/t/s!At_LoPNJEMUNk68XP6_JPPDZkbqQsA

Direct Challenge are represented differently in log, so it will take additional testing. I'll work on this.

Tracking implemented. You need to restart app to get new filters rolling.