CustomHelpTemplate is ignored with --help flag

My urfave/cli version is
2.25.0
Checklist

[x] Are you running the latest v2 release? The list of releases is here.
[x] Did you check the manual for your release? The v2 manual is here
[x] Did you perform a search about this problem? Here's the GitHub guide about searching.

Dependency Management

My project is using go modules.
My project is automatically downloading the latest version.

Describe the bug
While cli top-level-command help respects CustomHelpTemplate when printing help, cli top-level-command --help ignores it and prints SubcommandHelpTemplate instead.
Is this intentional? What is the purpose of SubcommandHelpTemplate?
If this is not intentional i can send a PR switching to  CustomHelpTemplate
To reproduce
app := cli.NewApp()
	app.Name = "testapp"
        app.Commands = []*cli.Command{
		        {
			        Name:   "top-level-command",
			        Action: func(c *cli.Context) error { return nil },
			        CustomHelpTemplate: "TESTING",
			 }
}

go run ./cmd/app top-level-command --help

Observed behavior
It prints SubcommandHelpTemplate
Expected behavior
go run ./cmd/app top-level-command --help should print CustomHelpTemplate
Additional context
https://github.com/temporalio/cli/pull/153
Want to fix this yourself?
Yes
Run go version and paste its output here
go version
Run go env and paste its output here

@feedmeapples Can you post your whole main.go file here. ? I want to double check some things. The behaviour is really really tricky to get right.

Here's a small main.go that reproduces the issue.
package main

import (
	"log"
	"os"

	"github.com/urfave/cli/v2"
)

func main() {
	app := &cli.App{
		Name: "myapp",
		Commands: []*cli.Command{
			{
				Name:               "subcmd",
				CustomHelpTemplate: "My template",
				// HideHelpCommand:    true,
				Action: func(c *cli.Context) error {
					return nil
				},
			},
		},
	}
	if err := app.Run(os.Args); err != nil {
		log.Fatal(err)
	}
}

This code has the right behavior, but if you comment in the HideHelpCommand line, the custom template is not used, but the default hard-coded one.
The problem seems to be here, where the fall-through results in the hard coded template being used.


Fix for #527 Download button clickable outside

Account number: fb84a32a698a03dd327c4ce673f19fa0acf6e68cb50f143d5d7c080471bc4625
Fixed issue: #527

@odetolataiwo I have paid this earlier. Don't send coins. Can you make sure this is logged into the system?


use isort in tox, my package is formatted third party

Hello, When I run ISort in Tox, my project package will be judged as a third-party package, but when I run ISort directly, there is no problem. Is there anything wrong? It's also normal when I use Pipenv with tox.
The scene is reproduced as follows
Project details
project tree
(demo)  kevin@kevin  /tmp/test/demo   master  tree
.
├── demo
│   ├── cmd.py
│   ├── __init__.py
│   └── server.py
├── Pipfile
├── Pipfile.lock
├── setup.cfg
├── setup.py
├── tests
│   ├── __init__.py
│   └── test_server.py
└── tox.ini

2 directories, 10 files

file detail
demo/server.py
import os

import uvicorn

from demo.server import app

def run():
    uvicorn.run(
        app
    )

test/test_server.py
import os

import pytest
from fastapi.testclient import TestClient

from demo.server import app

def test_server():
    client = TestClient(app)
    resp = client.get('/')
    assert resp.status_code == 200

setup.py
from os import path

from setuptools import find_packages, setup

setup(
    name='demo',
    version='1.0.1',
    # package_dir={'': 'src'},
    # packages=find_packages(where='src'),
    python_requires='>=3.6, <4',
    entry_points={
        'console_scripts': [
            'demo=demo.cmd:run'
        ],
    },
)

setup.cfg
[isort]
not_skip = __init__.py
skip =
    .tox

[tool:pytest]
testpaths = tests
python_files = tests.py test_*.py *_tests.py

tox.ini

[tox]
envlist = py37

[testenv]
skipsdist = true
skip_install = true
usedevelop = false
changedir = {toxinidir}
deps =
    ; pipenv
    isort
commands =
    ; pipenv install -d --skip-lock
    isort --recursive --check-only --diff demo tests

Run detail
run isort only
(demo)  kevin@kevin  /tmp/test/demo   master  isort
Skipped 2 files

run isort in tox
(demo)  kevin@kevin  /tmp/test/demo   master  rm -rf .tox
(demo)  kevin@kevin  /tmp/test/demo   master  tox
py37 create: /tmp/test/demo/.tox/py37
py37 installdeps: isort
py37 installed: isort==4.3.21
py37 run-test-pre: PYTHONHASHSEED='1399069139'
py37 run-test: commands[0] | isort --recursive --check-only --diff demo tests
ERROR: /tmp/test/demo/demo/cmd.py Imports are incorrectly sorted.
--- /tmp/test/demo/demo/cmd.py:before   2020-07-01 17:42:38.270308
+++ /tmp/test/demo/demo/cmd.py:after    2020-07-01 19:30:40.169042
@@ -1,7 +1,6 @@
 import os

 import uvicorn
-
 from demo.server import app

ERROR: /tmp/test/demo/tests/test_server.py Imports are incorrectly sorted.
--- /tmp/test/demo/tests/test_server.py:before  2020-07-01 17:45:35.386590
+++ /tmp/test/demo/tests/test_server.py:after   2020-07-01 19:30:40.172157
@@ -1,9 +1,8 @@
 import os

 import pytest
+from demo.server import app
 from fastapi.testclient import TestClient
-
-from demo.server import app

 def test_server():
ERROR: InvocationError for command /tmp/test/demo/.tox/py37/bin/isort --recursive --check-only --diff demo tests (exited with code 1)
________________________________________________________________________________________________________ summary ________________________________________________________________________________________________________
ERROR:   py37: commands failed
(demo)  ✘ kevin@kevin  /tmp/test/demo   master 

run isort and piprnv in tox
Pipfile
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]
isort = "*"
pytest = "*"

[packages]
fastapi = "*"
uvicorn = "*"

Run pipenv first, and run isort
tox.ini

[tox]
envlist = py37

[testenv]
skip_install = true
usedevelop = false
changedir = {toxinidir}
deps =
    pipenv
    isort
commands =
    pipenv install -d --skip-lock
    isort --recursive --check-only --diff demo tests

Result
(demo)  kevin@kevin  /tmp/test/demo   master ●  rm -rf .tox
(demo)  kevin@kevin  /tmp/test/demo   master ● 
(demo)  kevin@kevin  /tmp/test/demo   master ●  tox
py37 create: /tmp/test/demo/.tox/py37
py37 installdeps: pipenv, isort
py37 installed: appdirs==1.4.4,certifi==2020.6.20,distlib==0.3.1,filelock==3.0.12,importlib-metadata==1.7.0,isort==4.3.21,pipenv==2020.6.2,six==1.15.0,virtualenv==20.0.25,virtualenv-clone==0.5.4,zipp==3.1.0
py37 run-test-pre: PYTHONHASHSEED='2834522456'
py37 run-test: commands[0] | pipenv install -d --skip-lock
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead. You can set PIPENV_VERBOSITY=-1 to suppress this warning.
Installing dependencies from Pipfile…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 3/3 — 00:00:00
py37 run-test: commands[1] | isort --recursive --check-only --diff demo tests
________________________________________________________________________________________________________ summary ________________________________________________________________________________________________________
  py37: commands succeeded
  congratulations :)

summary
I don't know why. Even though 'pipenv' is possible, I want to break 'isort' separately from 'tox'. I'm trying to find a Python project template that works for me, but this problem is holding me back.
Thank you very much if you can help me.
The source code for this demo project is here: demo.

Can you see if this issue still happens for you in the 5.0.0 release I just pushed out? https://timothycrosley.github.io/isort/docs/major_releases/introducing_isort_5/. Environmental inconsistencies was one of the major problems I aimed to squash in the new release

I tested the new version 5.0.2 successfully. And the github action I added to the demo project was successful. Very happy. Thank you for your help.
This was tested in my laptop's Windows environment. On Monday I will update Linux on my working development machine.
(demo) E:\workspace\develop\python\demo>rm -rf .tox

(demo) E:\workspace\develop\python\demo>tox
py37 create: E:\workspace\develop\python\demo\.tox\py37
py37 installdeps: isort
py37 installed: isort==5.0.2
py37 run-test-pre: PYTHONHASHSEED='736'
py37 run-test: commands[0] | isort --check-only --diff --src demo tests
______________________________________________________________________________________________________ summary ______________________________________________________________________________________________________
  py37: commands succeeded
  congratulations :)

hello, @timothycrosley .
I found a problem while using isort today.
Since I use pytest , conftest.py file exists in the tests directory to define the test configuration. When I refer to the contents of this file in the tests file, when I run isort in the tox, it will treat this part of the content as a third-party package, hoping to make adjustments to this problem later. Thank you.
This is the demo project's action result. Action is use the latest version 5.0.4.
I cannot reopen this issue, so should I make a new one ?
I sincerely look forward to your reply.


Unable to open by "Open graph view"

With latest version I cannot open window in editor clicking on "Open graph view" button in "Source control".

With previous version I can do it.

Cannot reproduce. Could you please share your system details? Win/Mac/Linux and Version? And are you using regular VSCode or VSCodium?
Also, please check the bottom Output pane and select git log --graph - perhaps some errors are shown here?

OS: Windows 11 version 23H2; Visual Studio Code: 1.87.1.
When I click the "Open graph view", I read only the message start command.
But the Git Log window does not appear in the editor.

Happens to me too. Only able to open the graph view via command. Tried disabling all extensions but this one.

vscode Version: 1.87.2 (system setup)
Commit: 863d2581ecda6849923a2118d93a088b0745d9d6
Date: 2024-03-08T15:20:17.278Z
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19045

Same log, but nothing happens:

When using the command and there is no open view, works (also when a view is already open):

Notes:

Using the buttons also do not work when an open view exists and is in focus.
I use "editor" for "git-log--graph.position"
Seems like nothing useful is reported even with "git-log--graph.verbose-logging", I still only get "start command" when pressing any "Open graph view" button.

Does this problem still exist in the latest version?

Hello!
The button seems to work without issues.
Thanks a lot for your efforts!


Packing Data... Access is denied.

I just installed GB Studio 3 and upgraded my GB Studio 2 game file to work with the newer version. Without changing anything else I clicked the play button for it to build and run. It gets to the Packing Data... part then throws Access Denied as below.
Packing Data...
Access is denied.
1
Warnings:

Access is denied.
1

To Reproduce
Steps to reproduce the behavior:

Click Run button.

Expected behavior
It should build then run the game file.
Screenshots

Platform (please complete the following information):

OS: Windows 10.
App version

Additional context
I've done nothing else thus far with this new version.

Solved: Same issue with the virus detection.


generalise environment setting/getting macros

Enables: https://github.com/balena-io/e2e/pull/581
should be safe to merge as-is.

Requested some additional reviewers because we are both authors at the moment.


%||% followed by |> puts all pipes on the same line

This example:
a <- "foo"
a %||% "bar" |>
  paste("baz") |>
  paste("baz2")

is reformatted to:
a <- "foo"
a %||% "bar" |> paste("baz") |> paste("baz2")

I suppose this is a precedence issue since the following isn't modified:
a <- "foo"
(a %||% "bar") |>
	paste("baz") |>
	paste("baz2")

However, the original code (without parenthesis) correctly returns "foo baz baz2" and therefore shouldn't be reformatted.

Actually maybe it is weird that a %||% "bar" |> paste("baz") |> paste("baz2") returns "foo baz baz2". It seems that %||% has a different precedence from + for instance since this fails:
1 + 1 |>
  paste("baz") |>
  paste("baz2")

Error in `1 + paste(paste(1, "baz"), "baz2")`:
! non-numeric argument to binary operator

I don't know enough on this topic, I'll let you determine if this is a precedence bug or not.

The formatter respects newlines in pipelines after the first operand. Since there is no newline after %||%, it considers the flat display by default (if it fits).
You can either add a newline after %||%:
a %||%
  "bar" |> paste("baz") |>
  paste("baz2")

# Formats as
a %||%
  "bar" |>
  paste("baz") |>
  paste("baz2")

Or add parentheses:
(a %||% "bar") |>
  paste("baz") |>
  paste("baz2")

Or even better:
a <- a %||% "bar"

a |>
  paste("baz") |>
  paste("baz2")


Rename function is renaming the wrong maps

Seems to be a weird problem that started in August after no changes on LegendLore's end, suspect something wonky's up with the Notion API because it happens in clusters of 1-2 days, but not the same 1-2 days for all creators. All users are still correct in MongoDB as well. Probably wasn't a one-time thing, need to implement some sort of second check to ensure it's re-tagging correctly.
Also need to do a one-time cleanup of the incorrectly tagged items using the MongoDB data.

Fixed!


Install README.md instead of pointless empty README

The Makefile of afl installs an empty README file to the doc dir. This is obviously pointless.
This PR changes this to install the README.md instead and removes the empty README file.

Thanks!


Date assert should be able to handle unix timestamp

@JoaoHenriquePereira can you submit a PR adding moment parse to each Date assert instead of what's being done currently?

Actually I took some time today to think about this. WDYT something like this:
this.validate = value => {
    if (typeof value === 'string') {
      if (isNaN(Date.parse(value)) === true) {
        throw new Violation(this, value);
      }

      return true;
    }

    if (typeof value === 'number') {
      if (new Date(value).getTime() < 0) {
        throw new Violation(this, value);
      }

      return true;
    }

    if (Object.prototype.toString.call(value) !== '[object Date]') {
      throw new Violation(this, value, { value: 'must_be_a_date_or_a_string_or_a_timestamp' });
    }

    return true;
  };

It keeps compatibility, adds support to evaluate a timestamp and evaluates a date object in similar fashion to moment isDate (as before).

Update: Ok noticed you changed the assert already :) I'll update later what needs to be done.

Something like that would work, yes. That would work for server as minor, otherwise adding moment has the caveat of making it a major (requires additional peer dependency).

Note this from MDN:
Date.prototype.getTime()

Returns the numeric value of the specified date as the number of milliseconds since January 1, 1970, 00:00:00 UTC (negative for prior times).

I'll have a look on how I could add support for negative dates and submit a PR.


mismatch in size for FactorReMat

The size of a FactorReMat doesn't agree with the size of its sparsified version:
Using the corr FactorReMat from the tests:
julia> size(corr)
(180,36)

julia> size(sparse(corr))
(360,18)

Is that intended behavior? If so, I'm not sure I understand what the purpose of the sparse(::FactorReMat) is; I'd assumed it was to recover the non-condensed form of the random effects matrix.

More to the point, they behave differently in multiplication:
julia> corr'corr
18×18 Diagonal{Array{Float64,2}}:
 [10.0 45.0; 45.0 285.0]          ⋅                        ⋅                        ⋅                …          ⋅                        ⋅                        ⋅
         ⋅                [10.0 45.0; 45.0 285.0]          ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                [10.0 45.0; 45.0 285.0]          ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                [10.0 45.0; 45.0 285.0]             ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                …          ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                …          ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                …  [10.0 45.0; 45.0 285.0]          ⋅                        ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                [10.0 45.0; 45.0 285.0]          ⋅
         ⋅                        ⋅                        ⋅                        ⋅                           ⋅                        ⋅                [10.0 45.0; 45.0 285.0]

julia> sparse(corr)'sparse(corr)
18×18 sparse matrix with 18 Float64 nonzero entries:
        [1 ,  1]  =  295.0
        [2 ,  2]  =  295.0
        [3 ,  3]  =  295.0
        [4 ,  4]  =  295.0
        [5 ,  5]  =  295.0
        [6 ,  6]  =  295.0
        [7 ,  7]  =  295.0
        [8 ,  8]  =  295.0
        [9 ,  9]  =  295.0
        [10, 10]  =  295.0
        [11, 11]  =  295.0
        [12, 12]  =  295.0
        [13, 13]  =  295.0
        [14, 14]  =  295.0
        [15, 15]  =  295.0
        [16, 16]  =  295.0
        [17, 17]  =  295.0
        [18, 18]  =  295.0

Have you upgraded to version 0.9.0, the latest released version?  If so, did you mean FactorReTerm?
In any case, the sparse method is just for pedagogical purposes - to show what the structure of the matrix would be if you wrote it out.

Yes, I'm on master and I made a typo. Thanks for clarifying, and I'll put together a PR.

Thanks for the offer of the PR.  I'm working on this repository today so, unless you have already worked out what needs to change, I can take care of it.


Error while enabling NFSv3

Is there an existing issue for this?

[X] I have searched the existing issues

Greenfield/Brownfield provisioning
greenfield
Terraform Version
v1.7.5
Module Version
Latest git version: 5c5af3b08b3b4f60ab4fb3315a2079b672bca38d
AzureRM Provider Version
3.97.1
Affected Resource(s)/Data Source(s)
azurerm_storage_account
Terraform Configuration Files
terraform {
  required_version = ">= 1.5"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.72"
    }
    random = {
      source  = "hashicorp/random"
      version = "3.6.0"
    }
  }
}

provider "azurerm" {
  features {}
  skip_provider_registration = true
}

resource "random_string" "random" {
  length  = 20
  upper   = false
  special = false
}

module "st" {
  source                        = "github.com/Azure/terraform-azurerm-avm-res-storage-storageaccount.git?ref=5c5af3b08b3b4f60ab4fb3315a2079b672bca38d"
  account_replication_type      = "LRS"
  account_tier                  = "Standard"
  account_kind                  = "StorageV2"
  location                      = "eastus"
  name                          = random_string.random.result
  resource_group_name           = "rg_sb_eastus_78496_1_171126845850"
  shared_access_key_enabled     = false
  public_network_access_enabled = false
  nfsv3_enabled                 = true
  is_hns_enabled                = true
  use_nested_nacl               = true
  network_rules = {
    default_action = "Deny"
  }
  containers = merge(
    { for i, b in compact(local.users) : b => { name = b } }
  )
  enable_telemetry = false
}

locals {
  users = ["foo", "bar"]
}

tfvars variables values
none

Debug Output/Panic Output
https://gist.github.com/elacheche/5a7404d4cf42fd2796b17fe3a74bdd1c

Expected Behaviour
Created a ST with NFSv3 enabled for containers
Actual Behaviour

ST created
NFSv3 enabled
Containers not created, and exits with error:

Error: retrieving queue properties for Storage Account (Subscription: "4f6a6eb9-27d0-4ed6-a31c-2bde135e2db6"
Resource Group Name: "rg_sb_eastus_78496_1_171126845850"
Storage Account Name: "qo056vc3rw81hw7lc79k"): unmarshalling response: could not parse response body

  with module.st.azurerm_storage_account.this,
  on .terraform/modules/st/main.tf line 6, in resource "azurerm_storage_account" "this":
   6: resource "azurerm_storage_account" "this" {

Steps to Reproduce
Just a terraform apply
Important Factoids
No, I reproduced the same with two different accounts on two different tenents
References
No response

Enabling shared access keys solves this issue:
--- main.tf     2024-04-07 10:28:17.193337052 +0200
+++ main.tf     2024-04-07 09:55:39.523940902 +0200
@@ -30,8 +30,8 @@
   account_kind                  = "StorageV2"
   location                      = "eastus"
   name                          = random_string.random.result
   resource_group_name           = "rg_sb_eastus_78496_1_171126845850"
-  shared_access_key_enabled     = false
+  shared_access_key_enabled     = true
   public_network_access_enabled = false
   nfsv3_enabled                 = true
   is_hns_enabled                = true

Thanks to @dstreitberg for the tip https://github.com/Azure/terraform-azurerm-avm-res-storage-storageaccount/issues/64#issuecomment-2037212570


Added Result merge method

Also:

is_ok and is_error use a comparison instead of a match as the comparison is faster
Fixed a typo

Hi, thanks for the PR. Do you have any reference for the merge operator? Who else is using it? I would prefer operators like orElse and orElseWith, ref: https://demystifyfp.gitbook.io/fstoolkit-errorhandling/fstoolkit.errorhandling/result/orelsefunctions#result.orelsewith

Hi, thanks for the PR.

Happy to contribute 🙂

Do you have any reference for the merge operator? Who else is using it?

There is an Either#merge in Scala (docs). (Not sure of your familiarity with Scala but Either is pretty much the same as Result)

I would prefer operators like orElse and orElseWith, ref: https://demystifyfp.gitbook.io/fstoolkit-errorhandling/fstoolkit.errorhandling/result/orelsefunctions#result.orelsewith

merge is orthogonal to these imo. An example use of merge would be if you get a Result from your service layer and want to convert it to a HTTPResponse to return from the router layer.
Simple example:
def create(customer_id: str, email: str) -> HTTPResponse:
    service_result: Result[Customer, InvalidEmailAddress] = service.create_customer(customer_id, email)
    response: HTTPResponse = service_result.map(customer_to_response).map_error(invalid_email_to_response).merge()
    return response

I think the above code might also benefit from a Either#bimap (Scala cats docs) if you would be open to that addition? I tend to use bimap and merge together quite often in Scala.
def create(customer_id: str, email: str) -> HTTPResponse:
    service_result: Result[Customer, InvalidEmailAddress] = service.create_customer(customer_id, email)
    response: HTTPResponse = service_result.bimap(customer_to_response, invalid_email_to_response).merge()
    return response

I've created a PR to add the or_else* methods too #226

Sorry I think I made a merge conflict with your PR. Anyways, I see that merge is the same as default_with(lambda x: x)

Nice catch on the default_with. Pretty succinct now 🙂


Axios error

Everything appears to be working, but all of my team gets this axios error after yarn start or yarn deploy.

(node:35580) UnhandledPromiseRejectionWarning: Error: Request failed with status code 404
    at createError (/Users/garrettboatman/repos/byte-www/node_modules/axios/lib/core/createError.js:16:15)
    at settle (/Users/garrettboatman/repos/byte-www/node_modules/axios/lib/core/settle.js:18:12)
    at IncomingMessage.handleStreamEnd (/Users/garrettboatman/repos/byte-www/node_modules/axios/lib/adapters/http.js:201:11)
    at IncomingMessage.emit (events.js:187:15)
    at endReadableNT (_stream_readable.js:1092:12)

Any ideas?

Hey @garrettboatman. We're getting the same error with the current build.
This is an issue with Slate Analytics. You can see the relevant issue at https://github.com/Shopify/slate/issues/1075
This issue includes a fix that is quite suitable until a new version is shipped. Essentially you should change line 95 of<EMAIL_ADDRESS>to return axios('https://v.shopify.com/slate/track', axiosConfig).catch(() => {});. This ensures the script will bail silently if there is an error.

@Cam Thank you! I couldn't find that Slate gh issue.
and thanks for the quick fix tip 🙂

@garrettboatman no problem!


Smallest trigger interval

The CRON expression permits intervals to be set to seconds. The description of the UseMonitor property mentioned " For schedules that trigger more than once per minute...". What is the highest practical trigger frequency? For example, is triggering a timer every 10 seconds feasible?

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

ID: b5527c3b-a5da-c73d-66c2-20d96003ff7c
Version Independent ID: 42154c7b-b0e0-26db-79bc-3f1673c48e40
Content: Timer trigger for Azure Functions
Content Source: articles/azure-functions/functions-bindings-timer.md
Service: azure-functions
GitHub Login: @craigshoemaker
Microsoft Alias: cshoe

Hi @blyw Thanks for reaching out. We will review and update as appropriate.

@blyw Set the CRON expression "0 */10 * * * *" .  In this Function should trigger every 10 second.
NCRONTAB examples
For now I will proceed with closure of this and If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


[Request] Use less api calls

So I’m planning to scrape stories of about 7000 users, and I think that is gonna be a huge load on instagram.
Let’s say, I already downloaded the whole stories, is there an option to only download new stories so that it uses less api calls and not check every user?

I know it’s possible because there’s a site that scrape million of users.
For reference: isdb.pw

I'm not experienced nor interested in improving functionality for mass scraping, sorry.
You will most likely run into account/ip rate limits by Instagram if you're not using proxies, something this particular script won't support.
Feel free to fork this project and implement proxy support yourself though. (or try a different project that does have proxy support)

Let’s say, I already downloaded the whole stories, is there an option to only download new stories so that it uses less api calls and not check every user?

An api call still has to be made to check whether or not there are new available stories, this can't be changed. I don't think there are any limits on the actual downloading of story files, since those aren't api related.

What script would you suggest?

Perhaps this web api based library can help you get the job done https://github.com/postaddictme/instagram-php-scraper
I think you're going to have to write the script yourself though. I doubt anyone's offering a free, ready to use script capable of doing specifically what you want. Especially considering most projects and the api libraries are written with the intent of legitimate usage and not spam-like activity such as mass account scraping.

Thanks


building python3Packages.protobuf3_2 on OS X fails due to string include

Issue description
Building the python 3 protobuf package fails for me on macOS.
$ nix-build '<nixpkgs>' -A python3Packages.protobuf3_2
...
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I../src -I/nix/store/nkmdx27mxqq4mz9qvnbd8v754y290ndf-python3-3.6.1/include/python3.6m -c google/protobuf/pyext/descriptor.cc -o build/temp.macosx-10.6-x86_64-3.6/google/protobuf/pyext/descriptor.o -Wno-write-strings -Wno-invalid-offsetof -Wno-sign-compare -Wno-shorten-64-to-32 -std=c++11
clang-4.0: warning: argument unused during compilation: '-fno-strict-overflow' [-Wunused-command-line-argument]
google/protobuf/pyext/descriptor.cc:35:10: fatal error: 'string' file not found
#include <string>
         ^~~~~~~~
1 error generated.
error: command 'clang' failed with exit status 1
builder for ‘/nix/store/2z36gcrnmi2bz1a3s3nppc8imp11ppgj-python3.6-protobuf-3.2.0.drv’ failed with exit code 1
error: build of ‘/nix/store/2z36gcrnmi2bz1a3s3nppc8imp11ppgj-python3.6-protobuf-3.2.0.drv’ failed

Digging in (by launching  nix-shell -A python3Packages.protobuf3_2), the cause seems to be that python setup.py build_ext --cpp_implementation calls CC=clang instead of CXX=clang++. The clang call above fails, but the same call works after replacing clang by clang++. Similarly, CC=$CXX python setup.py build_ext --cpp_implementation works fine.
That in turn matters because of
if [[ "$isCpp" = 1 ]]; then
    if [[ "$cppInclude" = 1 ]]; then
        NIX_CFLAGS_COMPILE="$NIX_CFLAGS_COMPILE ${NIX_CXXSTDLIB_COMPILE-}"
    fi
    NIX_CFLAGS_LINK="$NIX_CFLAGS_LINK $NIX_CXXSTDLIB_LINK"
fi

in the clang/clang++ wrappers, because the system include path NIX_CXXSTDLIB_COMPILE is missing in the clang case.
Technical details

System: mac OS 10.12.5
Nix version: nix-env (Nix) 1.11.8
Nixpkgs version: "17.09pre108299.ec9a23332f"
Sandboxing enabled: grep: /etc/nix/nix.conf: No such file or directory :)

When digging in, I used a checkout of nixpkgs with hash 63e9d1c51ec0ad41c3ef729851442f199ce06a25, but it seems to make no difference.

https://github.com/NixOS/nixpkgs/issues/16450 seems related.

@knedlsepp uses Python on Darwin and might help here.

I've had a look at the python setup tools: The relevant line is https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L58:
    executables = {'preprocessor' : None,
                   'compiler'     : ["cc"],
                   'compiler_so'  : ["cc"],
                   'compiler_cxx' : ["cc"], // <- here
                   'linker_so'    : ["cc", "-shared"],
                   'linker_exe'   : ["cc"],
                   'archiver'     : ["ar", "-cr"],
                   'ranlib'       : None,
                  }

which causes C++ source files to be compile with $CC. Not sure whether this is the right or wrong thing to do...
I see two reasonable ways to fix this bug, in a more principled way than #26606:

fix python distutils to compile C++ files using $CXX
fix nixpkg clang-wrapper/bin/cc to treat cc like c++ with respect to $cppInclude and friends

If 1. is the right thing to do, it might still be nice to work around the bug in another way for now.

I've also been bitten by this problem once:
https://github.com/NixOS/nixpkgs/issues/18729
The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both clang++ and clang link the C++ standard library there.
However our nix-clang does not link against the standard library and that's why you will encounter this problem.
I'm not an expert on the darwin-stdenv, so I wouldn't know how to fix this in a way that does not require hacking our ways around that problem.
To hack around this problem you simply have to grep the pythonPackages for libcxx. There are a few packages that use a workaround that involves adding libcxx to the C-compile flags:
See e.g. here:
https://github.com/NixOS/nixpkgs/blob/6b999f3c42607342231b6fe119fcf0f934f40fd8/pkgs/development/python-modules/matplotlib/default.nix

The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both clang++ and clang link the C++ standard library there.
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions.

@LnL7 @copumpkin any clue how to solve this issue?

The problem does not seem all-too widespread, but there are a few instances:
https://github.com/NixOS/nixpkgs/blob/c976806322f322413f3df704d26c32b3f6921642/pkgs/development/haskell-modules/configuration-nix.nix#L233
https://github.com/NixOS/nixpkgs/blob/6b999f3c42607342231b6fe119fcf0f934f40fd8/pkgs/development/python-modules/matplotlib/default.nix#L32
https://github.com/NixOS/nixpkgs/blob/63150762bafc0423761844d203efa67954824286/pkgs/development/libraries/qt-4.x/4.8/default.nix#L167
https://github.com/NixOS/nixpkgs/blob/73a21ae6c93f1d37d68e21c31768f4df6e92e403/pkgs/applications/editors/jucipp/default.nix#L56
https://github.com/NixOS/nixpkgs/blob/0d88299019bcd0611ec7356e7e380d9706f09f9d/pkgs/os-specific/darwin/cctools/port.nix#L75
https://github.com/NixOS/nixpkgs/blob/76e082922f34ba9915d53492b1a4075e51fd2915/pkgs/development/python-modules/pandas/default.nix#L60
https://github.com/NixOS/nixpkgs/blob/f6a7296499cb397651f3ec8d7244330db88980d7/pkgs/os-specific/darwin/apple-source-releases/adv_cmds/xcode.nix#L41
https://github.com/NixOS/nixpkgs/blob/3c320fe7b1039a5d4bfc067b81e4028876c40af5/pkgs/tools/filesystems/irods/common.nix#L26
https://github.com/NixOS/nixpkgs/blob/56904d7c423f2b13b37fbd29f39bbb4b52bc7824/pkgs/development/r-modules/generic-builder.nix#L11
https://github.com/NixOS/nixpkgs/blob/56904d7c423f2b13b37fbd29f39bbb4b52bc7824/pkgs/os-specific/darwin/maloader/default.nix#L19
https://github.com/NixOS/nixpkgs/blob/6b999f3c42607342231b6fe119fcf0f934f40fd8/pkgs/development/python-modules/numba/default.nix#L26

Any reason we can't just change https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L58 to use cpp? Seems like it would work on Linux just fine, and fix a bunch of other stuff.

I knew this was an issue in general (https://github.com/NixOS/nixpkgs/issues/18729), but assumed the problem was something more complicated.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/tensorflow-on-20-09-mac/11931/5


how can  I fetch Voice file after call end

How can I Find Voice Filename when called to someone ?
I need to find something in events to store in server and after call I should fetch that voice file from asterisk but I have just number and I need something else looks like that uniqeId to find that voice file.
I don't know how

Hi,
Can't you just use the Call-ID or something like that?
Anyway, not really related to SIP.js.


Dataset processing

I have a few questions regarding the dataset processing pipeline,

at generate_clips script, why the start index is 80 ??
why there are 13  records in each clip labeled idle in the train test split file ??
are there any parameters I would need to adjust when creating my own data set??

btw there is an error in 3_2_split_train_val_test.py that you naming the validation samples "val" while the model searches for "dev" labeled records.

Thank you for your interest in our work.

In our dataset, there is always a segment of introduction that we want to desert. We will change that part to be a parameter user can set. Thank you for that.
It is because we want to make sure that the training set and test set do not overlap.
As far as we are concerned, all the parameters that should be set by yourself have been indicated as "required=True" in the "argparser". It should be fine if you go by our default setting. If you found anything that is crucial but we did not notice, please follow up on this issue.

Thank you. That is an incompatibility between our naming rules and that of the original dataset from "Speech2Gesture"

Thank you for the illustration.
I have a question regarding the data collection, from your experiments How much data do I need to collect (in hours) to get good results in general, and as good as Oliver specifically?

Here are the lengths of our training sequences for your reference:

Subject
Length (hours)

Oliver
11

Kubinec
3

Luo
7

Xing
2

Besides the length, the variation and the quality of pose may also highly influence the results. So we suggest collecting videos with expressive gestures like Oliver's and visually checking if the detected keypoints are correct and stable.

Many Thanks. @ShenhanQian @Garfield-Finch


[Bug] Webpack5 projects are not getting coverage correctly in development mode (but are in production)

Describe the bug

I wasn't able to reproduce this issue. I think it was happening in previous versions of this addon. However stumbles upon this in newer versions, please let me know with a reproduction ❤
cc @shilman @kasperpeulen


identity: deflake test TestGetIdentity

Currently, the test TestGetIdentity fails with the following error.
--- FAIL: TestGetIdentity (0.85s)
    --- FAIL: TestGetIdentity/Multiple_identities (0.26s)
        identity_test.go:226: Identity not found in the store

The reason is that the watch of the backend (started in its own goroutine) might not be ready when the test starts to create test identities.
Therefore, this PR introduces that the test waits with its continuation until the listener is ready.
Fixes: #23856

/test


No response on UART on ice40hx8k-evb

I tried loading the ice40hx8k-evb board files. The LEDs are blinking and I'm using just the UART for IO, without VGA/PS2.
No response on UART with screen and miniterm (--rtscts /dev/ttyUSB1 115200). Even with CAPS entry.
Tried setting the ps2_select to 1'b0. Still no luck.
Anything else to check ? How do I check if CTS is willing ?

By default there is a toggle pin that will switch between PS2 and UART input.
set_io button[2] F1

If you attach a button (or tap a jumper) to F1 and GND and press it, it should toggle between them.
Pin G1 much that same if you put a button will be the system reset.
It uses hardware CTS for the UART need to make sure the driver supports it. I have issues with MacOS drivers not supporting RTS/CTS.


Fix chart releaser command which uses docker image

Motivation

chart releaser command broker after upgrading to 1.3.0 version by #192
example failure:

Error: unknown command "cr" for "cr"
Run 'cr --help' for usage.

Modifications

remove cr from command since it's part of the docker entrypoint for the quay.io/helmpack/chart-releaser:v1.3.0 image.

quay.io/helmpack/chart-releaser:v1.0.0-beta.1 image didn't have cr as the entrypoint

+1


Expose InheritedWidget subscription cancelation

Description
This PR exposes an overridable method to let the InheritedElement know that a subscription has been canceled.
My plan with this change is to make a custom InheritedElement that could be combined with a listenable object (Stream/Listenable) – and subscribe to that object only if there's at least one widget that would be notified by notifyDependents.
This is something currently not possible because while we know when the listening starts, we currently don't know when it ends.
Related Issues

Tests

removeDependencies + hasDependencies:  done in inherited_test.dart

Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I signed the [CLA].
[x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[x] No, this is not a breaking change.

@goderbauer Hello,
I do not understand why some tests are failing.
Is this something my fault here? Because I don't see at all how these changes are related to the stack trace shown on https://cirrus-ci.com/task/4597873530896384

This change is scary, but I can't think of a case off-hand that it would break...

That said, it probably doesn't do what you want. For example, if you have a child that registers with inherited widgets A and B in build 1, then A makes it dirty and the second time it only registers with A, B won't hear about it until the widget goes away entirely, which might be never.
So I probably wouldn't recommend going down this path. It's better to just vend the actual stream and let the stream do the logic.

B won't hear about it until the widget goes away entirely, which might be never.

Indeed, but that's because the dépendent is actually still depending on B, such that if B makes it dirty, the dependent will still rebuild even if it doesn't call inheritFromWidgetOfExactType(B) anymore.
So thats excepted

@Hixie so, is this something that can potentially be merged?
I don't mind it being refused, but a feature for a package of mine may be implemented differently depending on if  can get merged or not.
The changes described here are not critical, but it'd serve as a solution for https://github.com/flutter/flutter/issues/30062

Indeed, but that's because the dépendent is actually still depending on B, such that if B makes it dirty, the dependent will still rebuild even if it doesn't call inheritFromWidgetOfExactType(B) anymore.

But if you use the "vend a Stream" solution, B would unregister from the stream and so things would be more efficient.
I'm torn on this one. On the one hand, I can see it being useful. On the other hand, it's a few extra cycles even in cases where we don't use it, and you only need a few thousand such "it's only a few extra cycles" before it really adds up. There's also the tradeoff between doing it the efficient way by vending a stream and the reality that doing that is somewhat convoluted and not as clean.
Have you considered making a Builder widget that looks up the stream from an InheritedWidget and does the subscribe/unsubscribe? Maybe that would be clean enough?

I'm torn on this one.

Sorry, I don't understand this paragraph.

Have you considered making a Builder widget that looks up the stream from an InheritedWidget and does the subscribe/unsubscribe? Maybe that would be clean enough?

Yes, but that is not compatible with what provider does.
One of the key feature behind provider is that it allows listening to any kind of object just by using Provider.of.
That both makes it easier to use (a single API), safer (can't forget to subscribe), and malleable (can be used inside didChangeDependencies).

An alternative solution is to expose a set of event listeners for the different widgets life-cycle on Element – like a add/removeUnmountListener.
But I think that would be a lot more dangerous than what this PR does.

Any update?
I'm definitely convinced that listening to complex objects on the inherited widget instead of the consumer is a good idea.
This allows many powerful things that wouldn't be possible otherwise. AnimatedTheme is one example.

"I'm torn on this one" is an English idiom meaning that I am struggling to make a decision because I see good arguments both for and against.
Maybe provider could be changed to do the subscribing/unsubscribing?
The more I think about this the more I think we probably shouldn't do it, because it adds a few cycles to every operation involving inherited widgets, and it isn't strictly adding anything that can't already be done, and it isn't really a complete solution to the problem (since it only handles some "unsubscribes").
Not sure what you mean about AnimatedTheme. Why is it not possible? We do it today, no?

(I hope that I do not sound harsh or too insisting)

But if you use the "vend a Stream" solution, B would unregister from the stream and so things would be more efficient.

Not sure what you mean about AnimatedTheme. Why is it not possible? We do it today, no?

These two quotes are related.
provider voluntarily works like Theme because it makes the API a lot easier to use and composable.
With Theme, consumers don't need an AnimatedBuilder to listen to the object.
But still, replacing Theme by AnimatedTheme is enough to make virtually all widgets that depend on ThemeData to play the animation.
provider does that, but instead of ThemeData, any object will do.
That works great, but one of the requirement is that the "vend a Stream" is not an option (unless I missed something?).
I'd prefer to cancel my plans for #30062 and other similar requests than to lose the simplicity of the current API.

because it adds a few cycles to every operation involving inherited widgets

I do not understand what this means.
The proposed changes shouldn't have any impact on existing InheritedWidgets.

it isn't really a complete solution to the problem

Is it because of https://github.com/flutter/flutter/issues/12992?
If so, then I disagree.
The use-case behind these changes is to do extra work when all listeners are removed (usually when a Route is unmounted).
Due to the nature of InheritedWidgets, there will rarely be only one widget listening to an InheritedWidget (otherwise an InheritedWidget is probably not useful). Therefore https://github.com/flutter/flutter/issues/12992 would rarely have an impact.
And even in the event where it does have an impact, then there's a simple workaround to that specific issue.
Instead of:
if (foo) {
  return Text(Foo.of(context));
} else {
  return Text(Bar.of(context));
}

we can have:
if (foo) {
  return Builder(
    key: const Key('foo'),
    builder: (context) => Text(Foo.of(context)),
  );
} else {
  return Builder(
    key: const Key('bar'),
    builder: (context) => Text(Bar.of(context)),
  );
}

The proposed changes shouldn't have any impact on existing InheritedWidgets.

At a very minimum it adds a polymorphic call to removeDependencies. This is a few cycles. We have to be strict about not adding a few cycles because otherwise everyone has their few cycles they can add and suddenly we have a LOT of cycles that aren't strictly necessary, and things get slow.
#12992 is what I was referring to by "not complete", yes.
I don't really see why you need this for the AnimatedTheme-equivalent behaviour. AnimatedTheme just builds a new Theme each frame. Why doesn't that work for provider?

This isn't to implement an AnimatedTheme.
It's instead to implement a "maintainState"-like parameter, while still being compatible with AnimatedTheme. Such that we have our AnimatedTheme, but when not used anymore, it's GCed.

In case this wasn't clear enough, the issue is:
With provider, it's not rare to have many Inheritedwidgets above Navigator.
These can vary from a simple immutable data, to an object that listens a firestore stream.
There's no problem with the former, but for the latter we do want to both lazily create the object and dispose it when it's not needed anymore.

For the problem of having a Listenable which behaves differently with zero listeners than non-zero listeners, I would expose the Listenable on the InheritedWidget, and then use an AnimationBuilder to register the callbacks:
   return AnimationBuilder(
     animation: MyNotifierSource.of(context),
     builder: (...) { ... },
   );

Similarly if it's a ValueListenable I'd use a ValueListenableBuilder. You can do similar things with a stream, e.g. using StreamBuilder.
I don't see why the inherited widget itself needs to do track if you have callbacks.

I don't see why the inherited widget itself needs to do track if you have callbacks.

For the same reasons behind Theme.of not returning a ValueListenable<ThemeData>.
That heavily simplify the API.

It guards peoples against forgetting to listen to the Listenable. There's nothing preventing the following for instance:
Widget build(context) {
  ValueListenable<T> foo = Something.of(context);
  // we forgot to use `AnimatedBuilder`
  return Text(foo.value.toString());
}

But that's unlikely to be expected as it won't rebuild when the value change.
If .of returns T instead of ValueListenable<T>, then that issue is made impossible entirely.

It makes very easy to listen to an observable object outside of build thanks to didChangeDependencies.
The typical:
class _FooState extends State<Foo> {
  Bar bar;
  ValueListenable<int> listenable;

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    ValueListenable<int> listenable = Something.of(context);
    if (listenable != this.listenable) {
      this.listenable?.removeListener(listener);
      this.listenable = listenable;
      listenable.addListener(listener);
      // the listener is not called immediatly, so we compute the state manually first
      bar = Bar(listenable.value);
    }
  }

  void listener() {
    setState(() {
      bar = Bar(listenable.value);
    });
  }

  @override
  void dispose() {
    super.dispose();
    listenable.removeListener(listener);
  }
}

becomes:
class _FooState extends State<Foo> {
  Bar bar;
  int previous;

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    int value = Something.of(context);
    if (value != previous) {
      previous = value;
      bar = Bar(value);
    }
  }
}

This, too, removes a whole range of potential errors. And it also make the code more readable by removing the "unnecessary redundant bits".

It makes the listening process works for everything. There's no need to learn both AnimatedBuilder, StreamBuilder, FutureBuilder, ...
.of(context) works for everything.

This is compatible with immutability. Animation/ValueListenable are mutable even if their .value property contains immutable objects.
This can cause issues with asynchronous event handlers. There's no guarantee that the value hasn't changed between the build that created the event handler, and the time where the .value is used.
By having Provider.of do the listening, then the value returned is completely immutable. It is therefore guaranteed that there's no undesired mutation that happened in the meantime.

For the same reasons behind Theme.of not returning a ValueListenable<ThemeData>.

But Theme doesn't expose a Stream or Listenable, and AnimatedTheme doesn't avoid animating if there's no subscribers. So I don't think that's the same thing at all.

It guards peoples against forgetting to listen to the Listenable.

You can avoid this by using an API where you only get access to the data if you subscribe (e.g. Stream) if that's a concern.

It makes very easy to listen to an observable object outside of build thanks to didChangeDependencies.

In the same way that a widget like AnimatedBuilder can expose a build method, it can expose callbacks for didChangeDependencies and dispose (though at that point, why not just do the listening directly), or, for the case you have, it could expose a transform callback:
  return ValueListenableWithTransformBuilder<int, Bar>(
    valueListenable: Something.of(context),
    transform: (int value) => Bar(value),
    build: (BuildContext context, Bar value) {
      // ...
    },
  );

It makes the listening process works for everything. There's no need to learn both AnimatedBuilder, StreamBuilder, FutureBuilder, ... .of(context) works for everything.

I'm not really convinced that hiding details like this is a good thing. It just makes it harder to figure out why things break when they break.
Also, it doesn't actually work for everything, as we noted earlier in this thread. It fails to unsubscribe promptly in some cases.

This is compatible with immutability. Animation/ValueListenable are mutable even if their .value property contains immutable objects.

You don't have to use these objects, if you need different properties. They're just existence proofs.

There's nothing as simple as returning T instead of Anything<T>.
Using ValueLisrenable here is just the easiest example available. All other objects comes with their own complexity.
For example Stream is problematic, because in most cases the first event is emitted the next frame. So we have to deal with a blank frame, even when we have our data.
Then we'll typically have to use rxdart, for BehaviorSubject (otherwise our app is likely bugged). Which adds another dependency, and with a big learning curve at that.

I'm not really convinced that hiding details like this is a good thing. It just makes it harder to figure out why things break when they break.

Why would it break?

Also, it doesn't actually work for everything, as we noted earlier in this thread. It fails to unsubscribe promptly in some cases.

While that issue is interesting, it is technically unrelated to these changes.
It's a separate problem that, if this were to big merged, would be fixed by having removeDependencies called when a build stops calling .of
Right now, there's technically still a listener. So it is logical for removeDepenencies to not be called, and for hasDependencies to stay true:

ValueListenableWithTransformBuilder

That's a lot more complex.
This would require a new Widget in the framework, for all objects, and for all situations.
And this approach will get stuck when creating our Bar from two providers instead of one.
Because that ValueListenableWithTransformBuilder<int> will work for one and only one dependency, while didChangeDependencies can handle as many as desired.

In any case, provider have always been doing that.
It's simple and similar to how many widgets from the framework works. Be it Theme.of or Scrollable.of, the listening is performed on the parent, not the descendant.
Changing that would invalidate nearly the entirely library, and reintroduce bugs that were made voluntarily harder.
And even then, that is still incompatible with the desired feature that is a maintainState variable on the widget that crates the object.
For a maintainState to work using your suggestion, it is necessary to override the addListener-like methods, which is outside of the scope of provider.
provider is made to help manipulating existing classes, not to implement its own alternatives.

We don't seem to be really convincing each other. I hear what you are saying, it just doesn't seem like a compelling enough reason to change the framework. If you think that I'm missing something, I recommend writing some demo apps using the style you want; we can see what it would look like to do them in styles possible today, and see how compelling the difference is.

A demo will take a bit of time to make.
But in the mean-time, I have another argument:
Having the InheritedWidget do the listening instead of the consumer of that information absorbs the performance issue of classes such as ChangeNotifier.
The documentation is pretty clear:

ChangeNotifier is optimized for small numbers (one or two) of listeners. It is O(N) for adding and removing listeners and O(N²) for dispatching notifications (where N is the number of listeners).

By having InheritedWidgets do the listening, we'll stay in that "one or two listeners" situations for the entire life of our ChangeNotifier.
If provider changed to listen the ChangeNotifier on the consumer instead of the InheritedWidget, then that would mean we'd end up with dozens if not hundreds of listeners as the app grows.

Knowing that I'll need lots of listeners and reading that notifyListeners() is O(n) has me thinking I should be looking elsewhere for my state solution. It sounds like this PR would address my concern.

@Hixie I've been thinking: is hasDependencies alone reasonable?
With my use-case, I could replace removeDependencies by a post-frame callback.

Having the InheritedWidget do the listening instead of the consumer of that information absorbs the performance issue of classes such as ChangeNotifier.

What about implementing your own Listenable?
In appears that in the Flutter framework itself, the dependents are the keys of a HashMap, and the framework iterates over these keys marking each for rebuilding. That's O(n), which is better than ChangeNotifier's O(n^2) for dispatching notifications.
ChangeNotifier appears to notify at O(n^2) because while it's iterating over the listeners in one list, it's first verifying the listeners in another list. That reminds me of working off of an immutable copy to protect data across threads, especially in closures, though I don't know why ChangeListener is doing it in this case.
So I'm not seeing why provider couldn't maintain its own list at O(n) for dispatching notifications. Mind you, I'm working with very little understanding here!

Within a single thread, I can't see any reason for a Listenable to be O(n^2) unless it's allowing listener callbacks to add and remove other listeners.

cc @gspencergoog who has been working on fixing the O(N) thing

@Hixie I think you missed my question here https://github.com/flutter/flutter/pull/33213#issuecomment-526930687:
Is hasDependencies alone reasonable? With my use-case, I could replace removeDependencies by a post-frame callback

What about implementing your own Listenable?

Reimplementing Listenable is outside of the scope of provider. The library is just an util for inherited widgets.
It just pass existing objects. It should not create new types of objects.
In any case, it's not just about O(N) vs O(N²).
Not having to deal with listeners (and as such forgetting to remove a listener) is pretty significant too.
And having only one listener allows supporting streams without having to broadcast them. That's important to correctly support async* functions.

@Hixie wrote:

why not just do the listening directly

@rrousselGit replied:

Having the InheritedWidget do the listening instead of the consumer of that information absorbs the performance issue of classes such as ChangeNotifier.
[...]
ChangeNotifier is optimized for small numbers (one or two) of listeners. It is O(N) for adding and removing listeners and O(N²) for dispatching notifications (where N is the number of listeners).
[...]
If provider changed to listen the ChangeNotifier on the consumer instead of the InheritedWidget, then that would mean we'd end up with dozens if not hundreds of listeners as the app grows.

I responded with a way to listen without using ChangeNotifier and without getting the O(N^2) performance you expressed worry about.
I didn't mean that would create a new public Listenable class or even a Listenable class at all, just that you would do the listening. I pointed to how Flutter was "listening" to its dependencies by using a HashMap as an example of what could be done instead.

Rereading now I see that you would instead have the "consumer" do the listening. My reading was that provider could listen to the data source and then call setState() on the consumers. Maybe I read that incorrectly.

That'd be equivalent to reimplementing InheritedWidget, which is not possible as a third party package since it requires changes inside Element.
The only way we can make this work without that PR is to stop supporting Provider.of(context).

That'd be equivalent to reimplementing InheritedWidget, which is not possible as a third party package since it requires changes inside Element.

I stand corrected. It sounds like the unsubscribe belongs on InheritedWidget.

I have a question for you @Hixie. I'm reading this issue as Flutter having a memory leak but the leak apparently not being bad enough to fix, perhaps because the memory would normally free on page change, which presumably happens often enough.
QUESTION: Assume inheritFromWidgetOfExactType() subscribes a descendant widget to InheritedWidget state changes. When the descendant widget rebuilds, it actually creates a new widget which must also subscribe to state changes of the InheritedWidget. Are the prior instances of these descendant widgets unsubscribed? Or does every widget that ever subscribed remain subscribed for the life of the InheritedWidget, whether still in use or not? I imagine that those that remain subscribed have to be tested for being dead, lest they rebuild.

I can answer that for hixie:
It's not the widgets that subscribes to an InheritedWidget, but its Element instead.
The Element stays subscribed to the InheritedWidget until it is "deactivated", which happens when:

the associated widget is removed from the widget tree
the widget is moved in the tree (using GlobalKey)

On the other hand, the subscription is not cleared if the widget's build method stops calling inheritFromWidgetOfExactType.

On the other hand, the subscription is not cleared if the widget's build method stops calling inheritFromWidgetOfExactType.

Thank you @rrousselGit! You've prevented me from expressing a misunderstanding in the article I'm writing. It sounds like a widget need only subscribe on its first build to forever thereafter be subscribed, even if it subsequently calls ancestorWidgetOfExactType. That is, subsequent to the first call, inheritFromWidgetOfExactType and ancestorWidgetOfExactType only serve to retrieve the ancestor widget, not to also establish or decline to establish a subscription.

@Hixie I've been thinking: is hasDependencies alone reasonable?
With my use-case, I could replace removeDependencies by a post-frame callback.

I don't understand what this means.
I think we should close this PR, as per https://github.com/flutter/flutter/pull/33213#issuecomment-513474323, until we have a stronger reason to make any changes to the framework for this.

I am going to close this PR as per the previous comment.

Maybe this PR should be reconsidered:

Provider package is popular enough that it probably deserves these few cycles.
notifyListeners is still O(N²).
Stream based solution would be significantly harder than inheriting - probably broadcast stream with some logic to pause/resume it.
Maybe it would open some other possibilities in future. Imagine if InheritedWidget didn't exist and you had to create
Since setDependencies, updateDependencies, getDependencies already exists (presumably to support InheritedModel which hardly anyone uses), adding removeDependencies & hasDependencies would only slightly increase API surface while making things consistent.
InheritedWidget is a very cool idea, imagine if we had to setup individual listeners for theme, language, screen width, etc. Those two methods would give us a chance to experiment a bit and maybe make it even better.

I definitely agree with @szotp.
I find it surprising that we have methods for getDependencies & co, which are called a lot. But removeDependencies is rejected, when it would  be called only when an Element is deactivated (and it is fairly rare).
Currently we may be able to work around it by overriding setDependencies to track everything. But that is a lot of overhead for something that would be very easy to fix on the framework side.

@Hixie is this completely out of question, or could opening a design doc and making some example potentially convince the team?

My recommendation would be to file an issue that describes the problem, ideally using sample code that demonstrates the problem. Until there is agreement that there is a real problem worth solving here, there's not much point us talking about what the solutions should be.
You can write such an issue on GitHub or as a design doc, whatever is easiest for you. The point is just to separate the "problem" stage from the "solution" stage. It may be that someone can come up with a much better solution to the problem once they understand the problem fully.

The issue already exists https://github.com/flutter/flutter/issues/30062
This is not about a "problem", in the sense that it is impossible to do today.
This is about improvement, to make it easier to solve such thing

A more general problem would be:
I want an InheritedWidget that knows if it is being inherited.
I will create an issue with better description.

"I want X" isn't a problem.
"It is hard to do Y" is a problem, especially if you demonstrate it with code that is indeed difficult to write or understand.
"Doing Y involves a lot of boilerplate" is a problem, especially if you can demonstrate that doing it in two cases involves a lot of identical code.


Downward metrics disks using the wrong path in the virt-launcher pod

What happened:
Downward metrics disks are stored under /var/run/kubevirt-private/downwardapi-disks/vhmostmd0 inside the virt-launcher pod.
What you expected to happen:
Downward metrics disks should be stored under /var/run/kubevirt-private/downwardmetric-disks/vhmostmd0 inside the virt-launcher pod.
How to reproduce it (as minimally and precisely as possible):
Launch a VM with downward metrics enabled.
Additional context:
Probably only a copy/paste mistake, see:
https://github.com/kubevirt/kubevirt/blob/0e3a1719c34ca4a0e7eb5925fe0fa2317bc18f0a/pkg/config/config.go#L80
DownwardAPIDisksDir is used instead of DownwardMetricDisksDir.
Environment:

KubeVirt version (use virtctl version): 0.58.1 / master
Kubernetes version (use kubectl version): N/A
VM or VMI specifications: N/A
Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): N/A
Kernel (e.g. uname -a): N/A
Install tools: N/A
Others: N/A

/cc @jcanocan

hello there @0xFelix , how can we reproduce the issue, could u know me a bit I would like to contribute on the issue?

Hi @prakrit55, you can create a VM with downward metrics enabled, then attach to the virt-launcher pod of the VM and have a look at its file system hierarchy. There is already an open PR trying to fix the issue, so it would be best to start from there: #9285

Hi @prakrit55 you can follow these steps to setup the scenario. Then, if you login into the VM launcher pod with cluster-up/kubectl.sh exec --stdin --tty launcher-pod -- /bin/bash and go to /var/run/downward-metri-disk/ you will note that the folder it's empty and the vhostmd file, where the downward metrics are written, is located in downwardapi-disks instead.

yes, I think the pr need reviews.


update-docs

@Harjot1Singh The only concern I have is not knowing whether docker config.yml can be updated like this

@bhajneet can you please update package.json

I must have forgot to push it yesterday. I thought I did and wrote that comment

@saihaj added files


Integrate finite-wasm with wasmer

Leaving as draft until finite-wasm is itself out of draft mode.

I’ll begin reviewing this in earnest shortly.

Ok so I’ve bumped to the current release of finite-wasm, handled your review comments and fixed all tests, including the stack misalignment issue that had me going crazy. I think this is ready for a new round of review, though I’ll need to reset my brain for a while and review it with a clear head myself as towards the end I was just poking around hoping to make things work.
The part I’m most sure is probably wrong is all the things I had to make pub in order to expose reset_stack_meter. @nagisa as you removed on_call from wasmer_call_trampoline to move it upwards the call stack instead in https://github.com/near/wasmer/commit/af6f55a, maybe you have ideas on where I should put it so that wast tests do manage to reset the stack meter properly? Or maybe the current "just make lots of things pub" solution is enough.

@nagisa I just pushed two commits that affect codegen, because I think (the test performed by the first one was now useless and) the second one was code that was actually wrong: I was allocating too much stack space and this could maybe have led to a stack overflow, as the stack probes were not adjusted relatively.
The tests still pass, but seeing how these are codegen changes, can you give these two commits a look before I land? :) (it’s literally the fourth time I’m writing the computation for the second commit, but this time I hope I’ve got it right for good!)


ENH: Refactor the model so it is compatible with DIPY's interface

The strategy is to initiate the new eddymotion.model.dipy, where we test out DIPY "extensions" which potentially will be added to their codebase. In it, a new GP model is added.
Our base module is then updated to handle the GP model as a standard DIPY model.
cc/ @arokem

@jhlegarreta are you comfortable merging this now? That will allow me to make further steps before tomorrow's meeting.
I believe with my last commit, things are in a very good state to be set up as a base for the GP.

@jhlegarreta are you comfortable merging this now? That will allow me to make further steps before tomorrow's meeting.

A few comments:

I do not understand why e.g. the changes to the signature of the angle computation would not be reviewed and eventually merged in the upstream repository: https://github.com/nipreps/eddymotion/pull/212.
The intermediate commits (removing the viz module, adding the covariance models, etc.) make the review  more difficult. Rebasing on the fork master should have been enough to only leave the relevant commits and changes.
Moving things (gradient angle computation, covariance computation, etc.) to a new .dipy module that are not strictly related to the fit/predict wrappers or multi-voxel decorators seems a little bit too early/counter-intuitive to me; I do not believe they make debugging the core of the GP thing easier at this point. I believe that keeping them separate as they were in the upstream repository allowed to focus better on the parts that need attention/debugging (and even when the whole thing may be moved to DIPY).

But I guess my comments are of little value if this needs to be merged now. @oesteban let me know if you really believe that addressing my comments is unfeasible/not useful, and will merge.

I do not understand why e.g. the changes to the signature of the angle computation would not be reviewed and eventually merged in the upstream repository:

My bad, I missed that one. Will work on it tomorrow, merge and then upstream here.

The intermediate commits (removing the viz module, adding the covariance models, etc.) make the review more difficult. Rebasing on the fork master should have been enough to only leave the relevant commits and changes.

I merged upstream/main into my branch precisely to make it easier to review, but yes, your branch would require a rebase to make the diff easier.

Failed to answer the last one:

Moving things (gradient angle computation, covariance computation, etc.) to a new .dipy module that are not strictly related to the fit/predict wrappers or multi-voxel decorators seems a little bit too early/counter-intuitive to me; I do not believe they make debugging the core of the GP thing easier at this point. I believe that keeping them separate as they were in the upstream repository allowed to focus better on the parts that need attention/debugging (and even when the whole thing may be moved to DIPY).

Should this new model be upstreamed to DIPY, these functions must also be propagated there or call equivalent and pre-existing implementations. I do not foresee many more models being upstreamed to DIPY, so it feels okay if all these items are kept together without proliferating small modules. Regarding debugging and testing, I'm not so clear that having these functions scattered in small modules is helpful. On the contrary, it may be easier if the stack trace is in a single file.

* I do not understand why e.g. the changes to the signature of the angle computation would not be reviewed and eventually merged in the upstream repository: [ENH: Make grad vec angle computation method accept two input parameters nipreps/eddymotion#212](https://github.com/nipreps/eddymotion/pull/212).

Addressed - #212 is now merged and I have updated downstream. Apologies for the oversight.

* The intermediate commits (removing the `viz` module, adding the covariance models, etc.) make the review  more difficult. Rebasing on the fork `master` should have been enough to only leave the relevant commits and changes.

I have rebased your branch and this PR - diff should be clean now.

* Moving things (gradient angle computation, covariance computation, etc.) to a new `.dipy` module that are not strictly related to the fit/predict wrappers or multi-voxel decorators seems a little bit too early/counter-intuitive to me; I do not believe they make debugging the core of the GP thing easier at this point. I believe that keeping them separate as they were in the upstream repository allowed to focus better on the parts that need attention/debugging (and even when the whole thing may be moved to DIPY).

This is the only outstanding point, which I hope I made sense responding above - let's chat later :)

OK, I'm merging this after our conversation, and we move forward from there. Thanks Óscar.


mass drawer addition to controller

writing this while manually adding 20480 drawers to my system, would love a better way to mass add them

would like to alse mention that after exactly 256 drawers are on a controller adding/removing from that controller causes massive lag spikes

The linking tool has a multiple mode, the description should tell you how to change it …


xtensor-blas documentation fails to build on RTD

Due to "Command killed due to excessive memory consumption/".
We might be able to get around this by ignoring FLENS headers.

Fixed in master by excluding new xflens directory.


Upgrades a few dependencies.

The main purpose of this upgrade was to get us new gluegun features.  There were a few others i noticed were aging so i brought them up too.
Finally the fs-mock now works.  (tested on node 8.2.1)
This gives us symlink support #1134 (for example using npm link).

I didn't explain this well.
What this allows us to do is:

develop plugins/boilerplates within a project.
open up that project's node_modules/ignite-thing/ files, hit save, and it gets picked up immediately.

A quality-of-life PR.


As a head nurse, I can track and display the availability status of staff members (e.g., on-duty, off-duty, on-call)

... so that the facilitation of decision-making for patient care assignments can be done

The function onduty to list staff members that are on shift will be added in v1.3b.

onduty command has been added.


Create a beautiful music player web app

This music player contain play, pause and next and previous song features and you can listen beautiful songs

Pls assign to me this issue under hacktobetfest'22

Please assign to me this issue under hacktobetfest'22

I also want to work on it bro ....you can work on digitial clock app


Module 7 - Project - Milestone

Completed and posted to the assignment a draft of the project that included the C++ version of the project.


Fix for http://jira.grails.org/browse/GPSPRINGEVENTS-7 and some cleanup

All the tests pass except for two. ReloadTests fails since there's no reloadClass() method (I assume because of the switch to the agent-based reloading). ListenerHibernateTests.listenersCanAttachDetatchedDomainObjects() also fails at the call to domainObjectInstance.isAttached() but that should work (a 2.0 issue?) That's not that critical a check and if you comment it out the test passes.

Thanks Burt. I'm going to try to get a release of this plugin & joda-time out in the next few days with any Grails 2 fixes that are needed.


GPUImage project makes Xcode crash on MacOS 10.13 beta

OS: macOS 10.13 Beta(17A352a)
I know this could be a bug of macOS or Xcode, but I still wanna try my luck here.
Xcode(both Xcode 8 and Xcode 9-Beta) crashes on opening project as long as the project or workspace contains GPUImage.

This appears to be a bug in CoreFoundation in the current macOS betas: https://twitter.com/kcase/status/901900659154235392 and impacts all large Xcode projects.


Disable page caching (close #3780)

@VasilyStrelyaev check option description
@AlexKamaev @AndreyBelym

@testcafe-build-bot retest

@testcafe-build-bot retest

@testcafe-build-bot retest

@testcafe-build-bot retest

@testcafe-build-bot retest

@testcafe-build-bot retest

@testcafe-build-bot retest

FPR

I checked the scenario from https://github.com/DevExpress/testcafe/issues/3780
It works successfully

@miherlosev
The --disable-page-caching flag works perfectly in the case of the https://github.com/DevExpress/testcafe/issues/4024 issue (without a workaround):
"test:e2e:chrome": "testcafe chrome testcafe/**/*.test.ts --disable-page-caching",


Modbus Master as TCP server

Sorry, I don't know about the modbus specification.
I want to ask if I can make the modbus master as a TCP server and the slave as a TCP client.
Can I make the slave on the local network access the server on the Internet?

No, the master is always the client and initiator. The slave is always the server and listener.


call place_cursor_at function by callback

In Windows OS, it raised ValueError except first seach.
changed to call place_cursor_at function by callback, with as_url function

Get the error too. It's making this plugin unusable... Merge asap please :)

Thank you @jacegem however as far as I can tell this is already fixed.
Can you please confirm?


Video unit height in EOY feature

the videos all seem to have tons of space around them for some reason. (in safari)

Hmm looking into this now.  Seems to be fine in other browsers.


hydra.errors.HydraException

hydra.errors.HydraException: Error calling 'model.sketchsampler.SketchSampler' : Encountered error: No module named 'cd' when loading module 'model.sketchsampler.SketchSampler'
Some mistakes about hydra.

It's not about hydra (in this case, hydra just print the error log). It seem to be an error occurred when compiling the module 'cd'. You can debug the line for loading the 'cd' module, or replace it with other chamfer distance implement such as pytorch3d.


Transistor primitives with variable number of fins

This PR allows for a PDK to have variable number of fins in a unit transistor. This is achieved a new primitive naming convention and variant generation targeting FinFET technologies. The transistor parameters below are required to be present in the netlist:
Transistor parameters:
  m:  number of instances
  nf: number of fingers
  w:  effective width of an instance (width of instance x number of fingers)

Looks good !
There are a couple of hacks in main.py & write_verilog_lef.py that we should eliminate long term but that's not the subject of this PR anyway.

Thank you. Agreed on eliminating the hacks. Eliminating hacks seem to be tricky and I think requires a sprint (dedicated days/week).

@kkunal1408  and @Lastdayends , I need your help to debug the failing test:
tests/constraints/test_constraint.py::test_do_not_identify
Error:
PnR.placer.Placer.PlacementCoreAspectRatio_ILP ERROR : Couldn't generate a feasible solution even after 10000 perturbations.
This test passes on master but fails on this branch. The only significant difference I could find is the compiler adding a SymmBlock constraint on this branch. I do not know why compiler does not auto-generate this for the exact same circuit.  Regardless of this constraint, this circuit is trivial and there should be a solution.

@soneryaldiz
May I know the name of the design? or how to reproduce this error?

@soneryaldiz
May I know the name of the design? or how to reproduce this error?

@Lastdayends , this test creates the design on the fly. All you need to do is to run the test locally via two ways:

vscode pytest framework (easiest, find the test in browser and hit run)
Command-line:

cd tests/constraints
pytest -v test_constraint.py -k test_do_not_identify

@soneryaldiz
May I know the name of the design? or how to reproduce this error?

@Lastdayends , this test creates the design on the fly. All you need to do is to run the test locally via two ways:

vscode pytest framework (easiest, find the test in browser and hit run)
Command-line:

cd tests/constraints
pytest -v test_constraint.py -k test_do_not_identify

@Lastdayends , if you do not have any local commits yet, can I move this test to another PR for you and Kunal, and merge this branch as we have a demo coming up this Tuesday?

@soneryaldiz
May I know the name of the design? or how to reproduce this error?

@Lastdayends , this test creates the design on the fly. All you need to do is to run the test locally via two ways:

vscode pytest framework (easiest, find the test in browser and hit run)
Command-line:

cd tests/constraints
pytest -v test_constraint.py -k test_do_not_identify

@Lastdayends , if you do not have any local commits yet, can I move this test to another PR for you and Kunal, and merge this branch as we have a demo coming up this Tuesday?

Please use #752 PR for debug.


cask/audit: add audit_min_os

[X] Have you followed the guidelines in our Contributing document?
[X] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[ ] Have you successfully run brew tests with your changes locally?

This PR adds an audit to ensure that the minimum macOS version specified in the cask matches the minimum macOS version specified by the developer.
It does so by:

Hijacking audit_livecheck_min_os to obtain the sparkle version information.
Adding audit_plist_min_os to extract the version information from Info.plist.
Comparing the cask min_os version with the extracted value. If both a sparkle min_os and plist min_os are present, we take the larger value of the two.

Note: This will break a lot of casks.

I'm incorporating the comments made by people, but also slowly going through casks and updating min_os versions. If we end up implementing something akin to this audit, I think the effort required to update all the casks won't be trivial.
@apainintheneck
Number of casks affected:
I ran the audit on homebrew/cask-versions and 33.6% (81/241) of casks failed. I would imagine this number to be similar, if not higher for the main tap.
Time to run:
As part of the full audit, it doesn't seem to make much of a difference. Ran individually, it seems to add 5 seconds, but I didn't have a good audit to benchmark this against. In terms of running it for all the casks, ~11 hours excluding download times.
❯ hyperfine 'brew audit --cask --online --strict quickgpt' --prepare 'git checkou
t cask-audit-min-os' 'brew audit --cask --online --strict quickgpt'
Benchmark 1: brew audit --cask --online --strict quickgpt [old]
  Time (mean ± σ):     20.708 s ±  1.540 s    [User: 2.400 s, System: 1.209 s]
  Range (min … max):   18.472 s … 23.800 s    10 runs

Benchmark 2: brew audit --cask --online --strict quickgpt [new]
  Time (mean ± σ):     20.647 s ±  4.108 s    [User: 2.360 s, System: 1.134 s]
  Range (min … max):   12.560 s … 24.493 s    10 runs

❯ hyperfine 'brew audit --only \'name\' quickgpt --strict --online' 'brew audit -
-only \'min_os, name\' quickgpt --strict --online'
Benchmark 1: brew audit --only 'name' quickgpt --strict --online
  Time (mean ± σ):      3.245 s ±  0.223 s    [User: 1.883 s, System: 0.542 s]
  Range (min … max):    3.023 s …  3.709 s    10 runs

Benchmark 2: brew audit --only 'min_os, name' quickgpt --strict --online
  Time (mean ± σ):      8.001 s ±  0.829 s    [User: 2.193 s, System: 0.848 s]
  Range (min … max):    7.052 s …  9.655 s    10 runs

Thanks for the benchmarks. It doesn't look like it'll be a performance problem.
Like you already noted the number of casks this affects is large enough that it will take a lot of work to update all of them. Maybe it'd be better to just apply this to new cask updates so that we can ship it faster and then maybe enable it for all casks later on as a follow-up.

Like you already noted the number of casks this affects is large enough that it will take a lot of work to update all of them. Maybe it'd be better to just apply this to new cask updates so that we can ship it faster and then maybe enable it for all casks later on as a follow-up.

This makes the most sense. Once it's merged we can create a tracking issue like we've done for our other projects of this scale.

Like you already noted the number of casks this affects is large enough that it will take a lot of work to update all of them. Maybe it'd be better to just apply this to new cask updates so that we can ship it faster and then maybe enable it for all casks later on as a follow-up.

Agreed. I think making it a --strict and/or --new-cask only audit makes sense until it's fully implemented.


Reduce db calls in /v3/security_groups and /v3/space_quotas/

instead of selecting all space guids for admin user, visual_space_guids is set to :all
if visual_space_guids is :all (=admin user), no filtering is done, just return all space guids
replace consequently occurences of old behaviour
also adapt unreadable_space_guids in SpaceQuotaApply and SecurityGroupApply
add tests for admin user in respective specs
fix typo in security_group_apply_spec

[x] I have reviewed the contributing guide

[x] I have viewed, signed, and submitted the Contributor License Agreement

[x] I have made this pull request to the main branch

[x] I have run all the unit tests using bundle exec rake

[ ] I have run CF Acceptance Tests

This improved the query from 60s down to 7s, thanks!


Gym does not detect provisioningProfiles for SDK-specific PROVISIONING_PROFILE_SPECIFIER.

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
When specifying the PROVISIONING_PROFILE_SPECIFIER in the build settings of my application target like this:
//:configuration = Debug
PROVISIONING_PROFILE_SPECIFIER =
PROVISIONING_PROFILE_SPECIFIER[sdk=iphoneos*] = match Development AdHoc company.demo.app
PROVISIONING_PROFILE_SPECIFIER[sdk=appletvos*] = match Development AdHoc company.demo.app

//:configuration = Ad-Hoc
PROVISIONING_PROFILE_SPECIFIER =
PROVISIONING_PROFILE_SPECIFIER[sdk=iphoneos*] = match AdHoc company.demo.app
PROVISIONING_PROFILE_SPECIFIER[sdk=appletvos*] = match AdHoc company.demo.app

//:completeSettings = some
PROVISIONING_PROFILE_SPECIFIER

And when trying to run gym without explicitly specifying the provisioniongProfiles in export_options, fastlane does not detect PROVISIONING_PROFILE_SPECIFIER.
The reason for this behavior is in the following code of code_signing_mapping.rb:
# Catalyst apps will have some build settings that will have a configuration
# that is specific for macos so going to do our best to capture those
#
# There are other platform filters besides "[sdk=macosx*]" that we could use but
# this is the default that Xcode will use so this will also be our default
- sdk_specifier = Gym.building_mac_catalyst_for_mac? ? "[sdk=macosx*]" : ""
+ sdk_specifier = Gym.building_mac_catalyst_for_mac? ? "[sdk=macosx*]" : "[sdk=#{sdkroot}*]" # fix issue
``

I fixed `sdk_specifier` in the local copy of the fastlane gem, and this fixed my bug.

##### Command executed

```rb
build_app(
  scheme: MY_SCHEME,
  configuration: 'Ad-Hoc',
  export_method: "ad-hoc",
)

Complete output when running fastlane, including the stack trace and command used

Error Domain=IDEProvisioningErrorDomain Code=9 ""DS Demo.app" requires a provisioning profile." UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription="DS Demo.app" requires a provisioning profile., NSLocalizedRecoverySuggestion=Add a profile to the "provisioningProfiles" dictionary in your Export Options property list.}
** EXPORT FAILED **
ERROR [2024-12-17 01:22:16.92]: Exit status: 70
ERROR [2024-12-17 01:22:16.92]: No provisioning profile provided
ERROR [2024-12-17 01:22:16.92]: Make sure to pass a valid provisioning for each required target
ERROR [2024-12-17 01:22:16.92]: Check out the docs on how to fix this: https://docs.fastlane.tools/actions/gym/#export-options

Thank goodness i have found someone else experiencing the same problem.


Conditional fields in Drupal form

It would be nice if we would have option for conditional fields in form for adding repository items. For example, you have two radio button options, Add person as literal string and Link agent. Depending on selection, appropriate fields would pop-up on form.
I found one example on Drupal site: link

In Islandora Tech call we discussed that this may be related to what is being discussed in this issue: https://github.com/Islandora/documentation/issues/1659

It might be related. In a sense that universal solution for implementing conditional fields and conditional labels would be preferable. I just don't know if that is possible.

@miha-pece also at today's Tech Call we decided to point out that there is a Drupal module (https://www.drupal.org/project/conditional_fields) that allows site builders to do the kind of things you are asking for without any coding/API. TSo while it is technically possible to configure conditional form fields similar to what you are describing, we came to the conclusion that providing a default Islandora configuration for conditional form fields is complicated because so many of the fields provided by default in Islandora are optional.
Would you mind providing some additional specific examples of what you would be looking for? The more information you can provide, the better.

A also found Drupal option, so yes, question is only if this could be useful if included as default Islandora. Maybe as example, how is possible to address some user interaction options. But I understand problems designing universal, general form, too many options could be confusing.
Our use case (at the moment as idea) is mixed fields for agents as strings or as minted agents. We think that mixed approach in one collection could be the best approach, because we have two categories of persons: on one side very stable group of persons with repeatable appearances, and on the other, many random passers, usually without sufficient personal data. Because of that, we thought that a mix approach with minted persons and open text field would be the most appropriate.


Suggestions for predefined enum sets

There are plenty more options for implemented in 0.4.0 [--enum-sets] (http://snowplowanalytics.com/blog/2015/11/17/schema-guru-0.4.0-with-apache-spark-support-released/#enums) feature. Here we're collecting them to decide what we can add.
One important restriction is that we must have single source of truth for proposed enumerations, like ISO, source code or something similar, that's why "colors" doesn't seem appropriate.

Language codes
Timezones
HTML tags
Snowplow enriched event object properties
...

ISO 8601: https://en.wikipedia.org/wiki/ISO_8601

Can the enum also be a pattern ("pattern" : "^([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)$") or a format ("format" : "ipv4") or is it exclusively for an array of representations as allowed values?
And why is the format: "ipv4" not a regexp as well :) ?

Unfortunately, enum is always just an array of allowed values (not just strings, but numbers, objects etc are allowed as well). It is defined like that in JSON Schema specification. Same for ipv4: we derive it as format just because it is defined that way in specs. I think creators of JSON Schema have reasons to not use regex property for IPv4 (readability may be? I'm going to find out).
But idea with custom regexes can be good as your idea with mappings or this one with enum sets. It can be especially good because theoretically it can allow us to derive precise maxLength for strings.

I really like all ideas with custom logic: mappings, regexes, etc. One problem with it is just it seems not very on demand among Schema Guru users and relatively hard to implement. I think it could be much more useful if it will be embedded in Web UI.

Also fine with me. I did not use the web ui yet.

http://schemaguru.snowplowanalytics.com/

I uploaded 80+ files  and it would not generate a schema. The submit button is not activated, unless i put JSON into the text field. Upload only does not seem to be supported.

Ok, i read up on the JSON schema and saw there is support for the ISO 8601 aka RFC 3339 already. But for some reason the email format is not correctly detected. So i think #143 is still valid, to pass in any mapping between a field name and a enum/type/format definition.


[CI] Setup CI/CD for the website

This app needs CI/CD for better development, automatic deployments, previews, etc.

Hey @EmperorYP7 can I work on this?

@EmperorYP7 I believe you have some update regarding this :slightly_smiling_face:


Release Notes in GH

In the  (GH Tag page for 1.0.6), you barely state fixes and enhancements. E.g: For 1.0.6, it just says "Fix text on risk detail page #879".
Via Email, I got full details of the update.
Please add this info to the Tag page as well (and in the future):
Bug fixes
Fix text on risk detail page #879
Fix blank Data Privacy page after 5 minutes without user interaction #825
Fixed wrong implementation of shouldPerformExposureDetection #869
Error 13 mitigations #863
fixes wrong days with tracing info on home screen #849
Updating of home cells #822
Fixed number of active days #841
Remove error when submitting 0 keys #800
Fix number of days since last exposure #811
Hotfix/pruning 2 #812
Fix pruning of tracing history #807
[bug] Mitteilungen - image not focusable with voice over (closes 1427) #725
Fixed deadlock when clicking on risk cell (closes #747) #746
[Bug] Nutzung Chapter 7 link (de) updated #779
[Bug] Remove invite friends footer translucency #751
[Bug] Submission Flow Navigation #687
EXPOSUREAPP-1531 Sharing function is missing explanation text #745
show indicator progress on the risk cell #634
Fixed: Link to English FAQs when running the App in English (closes #643) #644
[Bug] Fix ActionTableViewCell accessibility issue (closes #670) #673
[Bugfix] Only request user notifications where necessary #674
[fix] change timeout interval #676
[Bug] Disable iTunes file sharing for the app (closes #700) #705
[Bug] Fixed risk view #718
[Bug] Fix height of manual refresh button on home screen. #606
Fix unknown out dated card button #611
[Bug] Fix unknown outdated risk detail screen #613
[HOTFIX] Set earliestBeginTime to nil #612
New features
Tracing Status Animation #821
Added Arabic and Russian translation #858
Updated [TR] html content to Turkish translations #829
Translation for turkish added #773
[Feature] ENAButton activity indicator for submission flow #753
[Feature] ENAButton accessibility #752
Enhancements
Add home screen risk cell update button countdown #866
Home Screen Risk Cell Update on App start + Risk Calc Refinements #874
Reschedule bgtasks #824
Risk Calculation Errors - Alert Refinement #868
ExposureDetectionViewController refresh countdown #838
integrate new localized errors for exposurenotification settings #840
Exposure Submission Flow - Error Alert adjustments #843
Update turkish translation #832
Added the missing localizations for the alerts. #672
Update ExposureSubmissionService.swift #608
[HOTFIX] Call requestRisk on sceneWillEnterForeground #607
Others

That's a weakness of GitHub release notes. I creates release notes for everything that has been closed since the last release. But since this hotfix contains only the one PR that has been merged into master branch (not everything we already have in develop branch) I had to manually remove all PRs that are not part of this release from the release notes.

Thanks for clarification.


Getting started with Docker

I'm trying to get started using Docker locally and am happy to provide a tutorial once I succeed.
I'd like to start with little extra setup as possible (i.e. without building the additional image), to get a first impression.
Iiuc, I should be able to start versatile with
docker run --rm versatiles/versatiles:latest-alpine versatiles serve '[osm]https://storage.googleapis.com/versatiles/download/planet/europe/germany/germany-20230226.versatiles'

But it fails with:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Syntax(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
regex parse error:
    ^bytes (\d+)-(\d+)/\d+$
     ^
error: Unicode-aware case insensitivity matching is not available (make sure the unicode-case feature is enabled)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
)', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/versatiles-0.5.3/src/containers/versatiles/abstract_readers/data_reader_http.rs:64:18
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Passing -e RUST_BACKTRACE=full doesn't provide any more useful information.
Maybe I'm doing sth wrong here, can you please point me in the right direction ?

Thanks, pulling the latest image fixed the issue:
$ docker run --rm versatiles/versatiles:latest-alpine versatiles serve '[osm]https://storage.googleapis.com/versatiles/download/planet/europe/germany/berlin-20230101.versatiles'
   /tiles/osm/*                    <-  https://storage.googleapis.com/versatiles/download/planet/europe/germany/berlin-20230101.versatiles
server starts listening on <IP_ADDRESS>:8080

Btw, I was also able to serve a local versatiles file with docker run -v $(pwd)/data/:/data --rm versatiles/versatiles:latest-alpine versatiles serve '/data/berlin-20230101.versatiles' :+1:


Delete hard-coded Scaladoc url

This will now be set automatically to the javadoc.io unidoc link.
https://www.javadoc.io/doc/org.http4s/http4s-docs_2.13/0.22.13/org/http4s/index.html

Ugh, somehow this didn't work right 😕 must be an sbt-typelevel bug, or something.


Badges are not working with Github

@romariclaurent found this odd issue in Github's handling of badges:
https://github.com/romariclaurent/strider-badge-test
After a brief look, it seems that Github's behavior around our redirect and their CDN has changed and breaks them.
We should investigate as part of #257

Closing, since this works.