Array to string conversion

Array to string conversion
I am getting this error when I create my bread.

\vendor\tcg\voyager\src\Models\DataType.php:99

$fields = $this->fields((strlen($this->model_name) != 0)
                   ? DB::getTablePrefix().app($this->model_name)->getTable()
                   : DB::getTablePrefix().Arr::get($requestData, 'name')
               );

I think the problem is there.
? DB::getTablePrefix().app($this->model_name)->getTable()
kindly resolve this issue.

Thanks for replying. but I have run "composer update" command. but still,
it's saying that array to string conversion issue I am using voyager in
many places but that its new issue I have configured all thing correctly
but I think the problem with this file.
Array to string conversion
vendor\tcg\voyager\src\Models\DataType.php:99
[image: Screenshot_2.png]
[image: Screenshot_1.png]
On Fri, Feb 7, 2020 at 5:25 PM Christoph Schweppe<EMAIL_ADDRESS>wrote:

Closed #4739 https://github.com/the-control-group/voyager/issues/4739.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/the-control-group/voyager/issues/4739?email_source=notifications&email_token=AIUBN2XREIMBGJIKY5HYQLLRBVHMVA5CNFSM4KRNPKZKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWPNPC6I#event-3017470329,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIUBN2QQ25XKDS3J55M74JTRBVHMVANCNFSM4KRNPKZA
.


Eliminate error for "font-awesome": "^4.6.1"

ERROR in ./app/~/font-awesome-webpack/index.js
Module not found: Error: Cannot resolve 'file' or 'directory' ./font-awesome-styles in /Users/yong/code/mashgin/kiosk/ui/app/node_modules/font-awesome-webpack
@ ./app/~/font-awesome-webpack/index.js 1:0-72

Closing this as a duplicate of #23.


Syntax error when running script

Hello, I am trying to run the script and getting a syntax error over SSH on a headless server.
$ python updater.py
File "updater.py", line 242
def parse_credentials(credentials_file: str, user: str, token: str):
^
SyntaxError: invalid syntax
Things I have tried so far separately and together, I'm no coder:
-run directly from server instead of SSH
-verified user and token are in server-settings.json
-changed str values in line 242 to appropriate user and token
-added single quotes in various places in line 242 to make it look like other lines
-read many things in the forum that are above my understanding regarding APIs and authentication
-wiped the server and manually installed 1.1.61 to get the clients working
-run script again
Thank you for any help! If running the script is not possible on my setup, any help to update without wiping would be awesome too. Every time I tried dumping update files or stopping, updating, and restarting it would stay on the older version.

Please disregard, I got it to work by running ~python3 updater.py instead of ~python updater.py then supplying the version needed.
Thank you for the great script!


Implementation of NL

Added samples for v1 Natural Language.

Hi, @timburks Could you please review and merge this pr?


fix: use parsed url for dashboard link href

What this PR does / why we need it:
This PR addresses an issue where users are unable to specify a different hostname in the url for the deployed application.  For example, the below spec would create a link with the url: https://<admin-console-hostname>/some/path instead of https://www.example.com/some/path:
  descriptor:
    links:
      - description: "Open the Application"
        url: https://www.example.com/some/path

In some cases, the user might have a different hostname for the deployed application, so the hostname in the url should reflect what was provided in the spec.
Additionally, if the user provided an invalid url, it could cause an uncaught error on the client-side and render the admin console unusable.
Which issue(s) this PR fixes:

Fixes SC-48585
Special notes for your reviewer:

Is there a reason why we use window.location.hostname here instead of the actual hostname provided in the spec?
Steps to reproduce

Add the following link to the k8s application spec and the resulting url will be different:
  descriptor:
    links:
      - description: "Open the Application"
        url: https://www.example.com/some/path

Does this PR introduce a user-facing change?

Fixes an issue where dashboard links were being re-written to use the admin console hostname instead of the hostname provided in the application manifest.

Does this PR require documentation?

NONE

Is there a reason why we use window.location.hostname here instead of the actual hostname provided in the spec?

Yes.  Normally these links point to the installed application.  Because it's an on-prem instance.


az storage blob sync fails with "--auth-mode login"

Describe the bug
We are trying to use azure CLI to sync data from a local folder to an azure storage account that has Storage account key access set to Disabled. Our runner (Github Actions) uses the auth method OpenID Connect, which is a form of active directory Service principal, and is unable to obtain an explicit service principal key. We therefore require az storage blob sync to support --auth-mode login.
az storage blob upload-batch --auth-mode login does work, but is extremely slow (hours instead of minutes) as we have a large number of blobs that are the same in source and target for our sync jobs.
Related command
Any variation of az storage blob sync --auth-mode login will fail. Below is an example:
az storage blob sync --auth-mode login --account-name $storageacct --source "/repo" --container repo
Errors
unrecognized arguments: --auth-mode
Issue script & Debug output
Run az storage blob sync --auth-mode login --account-name $storageacct --source "/home/runner/work/repo" --container repo --debug
DEBUG: cli.knack.cli: Command arguments: ['storage', 'blob', 'sync', '--auth-mode', 'login', '--account-name', 'qberdlaketst', '--source', '/home/runner/work/repo', '--container', 'repo', '--debug']
DEBUG: cli.knack.cli: init debug log:
Cannot enable color.
DEBUG: cli.knack.cli: Event: Cli.PreExecute []
DEBUG: cli.knack.cli: Event: CommandParser.OnGlobalArgumentsCreate [<function CLILogging.on_global_arguments at 0x7fc73ef712d0>, <function OutputProducer.on_global_arguments at 0x7fc73ee73eb0>, <function CLIQuery.on_global_arguments at 0x7fc73eec1120>]
DEBUG: cli.knack.cli: Event: CommandInvoker.OnPreCommandTableCreate []
DEBUG: cli.azure.cli.core: Modules found from index for 'storage': ['azure.cli.command_modules.storage']
DEBUG: cli.azure.cli.core: Loading command modules:
DEBUG: cli.azure.cli.core: Name                  Load Time    Groups  Commands
DEBUG: cli.azure.cli.core: storage                   0.054        58       272
DEBUG: cli.azure.cli.core: Total (1)                 0.054        58       272
DEBUG: cli.azure.cli.core: These extensions are not installed and will be skipped: ['azext_ai_examples', 'azext_next']
DEBUG: cli.azure.cli.core: Loading extensions:
DEBUG: cli.azure.cli.core: Name                  Load Time    Groups  Commands  Directory
DEBUG: cli.azure.cli.core: Total (0)                 0.000         0         0
DEBUG: cli.azure.cli.core: Loaded 58 groups, 272 commands.
DEBUG: cli.azure.cli.core: Found a match in the command table.
DEBUG: cli.azure.cli.core: Raw command  : storage blob sync
DEBUG: cli.azure.cli.core: Command table: storage blob sync
DEBUG: cli.knack.cli: Event: CommandInvoker.OnPreCommandTableTruncate [<function AzCliLogging.init_command_file_logging at 0x7fc73dd0eb90>]
DEBUG: cli.azure.cli.core.azlogging: metadata file logging enabled - writing logs to '/home/runner/.azure/commands/2023-06-21.03-59-08.storage_blob_sync.2264.log'.
INFO: az_command_data_logger: command args: storage blob sync --auth-mode {} --account-name {} --source {} --container {} --debug
DEBUG: cli.knack.cli: Event: CommandInvoker.OnPreArgumentLoad [<function register_global_subscription_argument..add_subscription_parameter at 0x7fc73dd276d0>]
DEBUG: cli.azure.cli.core.profiles._shared: Traceback (most recent call last):
File "/opt/az/lib/python3.10/site-packages/azure/cli/core/profiles/_shared.py", line 655, in _get_attr
op = getattr(op, part)
AttributeError: module 'azure.mgmt.storage.v2022_09_01.models' has no attribute 'ActiveDirectoryPropertiesAccountType'
DEBUG: cli.azure.cli.core.profiles._shared: Traceback (most recent call last):
File "/opt/az/lib/python3.10/site-packages/azure/cli/core/profiles/_shared.py", line 655, in _get_attr
op = getattr(op, part)
AttributeError: module 'azure.mgmt.storage.v2022_09_01.models' has no attribute 'ListKeyExpand'
DEBUG: cli.azure.cli.core.profiles._shared: Traceback (most recent call last):
File "/opt/az/lib/python3.10/site-packages/azure/cli/core/profiles/_shared.py", line 655, in _get_attr
op = getattr(op, part)
AttributeError: module 'azure.mgmt.storage.v2022_09_01.models' has no attribute 'CorsRuleAllowedMethodsItem'
DEBUG: cli.knack.cli: Event: CommandInvoker.OnPostArgumentLoad []
DEBUG: cli.knack.cli: Event: CommandInvoker.OnPostCommandTableCreate [<function register_ids_argument..add_ids_arguments at 0x7fc73dd6d630>, <function register_cache_arguments..add_cache_arguments at 0x7fc73dd6d750>]
DEBUG: cli.knack.cli: Event: CommandInvoker.OnCommandTableLoaded []
DEBUG: cli.knack.cli: Event: CommandInvoker.OnPreParseArgs []
DEBUG: cli.azure.cli.core.command_recommender: "--auth-mode" is an invalid parameter for command "storage blob sync".
DEBUG: urllib3.connectionpool: Starting new HTTPS connection (1): app.aladdin.microsoft.com:443
DEBUG: urllib3.connectionpool: https://app.aladdin.microsoft.com:443 "GET /api/v1.0/suggestions?query=%7B%22command%22%3A+%22storage+blob+sync%22%2C+%22parameters%22%3A+%22%22%7D&clientType=AzureCli&context=%7B%22versionNumber%22%3A+%222.49.0%22%2C+%22errorType%22%3A+%22UnrecognizedArguments%22%2C+%22correlationId%22%3A+%22af05fbad-d236-4652-b430-6c9a98520a00%22%2C+%22subscriptionId%22%3A+%2279292959-afbb-4928-b2b9-1ad185a6a97b%22%2C+%22eventId%22%3A+%22eb0ffb0e-983d-4b76-99d1-8707189ccd25%22%7D HTTP/1.1" 200 None
DEBUG: cli.azure.cli.core.command_recommender: "--auth-mode" is an invalid parameter for command "storage blob sync".
DEBUG: cli.azure.cli.core.azclierror: NoneType: None
ERROR: cli.azure.cli.core.azclierror: unrecognized arguments: --auth-mode
ERROR: az_command_data_logger: unrecognized arguments: --auth-mode
Examples from AI knowledge base:
az storage blob sync --container mycontainer --source "path/to/file" --destination NewBlob
Sync a single blob to a container.
az storage blob sync --container mycontainer --account-name mystorageccount --account-key 00000000 --source "path/to/directory"
Sync a directory to a container.
https://docs.microsoft.com/en-US/cli/azure/storage/blob#az_storage_blob_sync
Read more about the command in reference docs
DEBUG: cli.knack.cli: Event: Cli.PostExecute [<function AzCliLogging.deinit_cmd_metadata_logging at 0x7fc73dd0edd0>]
INFO: az_command_data_logger: exit code: 2
INFO: cli.main: Command ran in 2.474 seconds (init: 0.181, invoke: 2.293)
INFO: telemetry.main: Begin splitting cli events and extra events, total events: 1
INFO: telemetry.client: Accumulated 0 events. Flush the clients.
INFO: telemetry.main: Finish splitting cli events and extra events, cli events: 1
INFO: telemetry.save: Save telemetry record of length 3728 in cache
WARNING: telemetry.check: Negative: The /home/runner/.azure/telemetry.txt was modified at 2023-06-21 03:58:23.812199, which in less than 600.000000 s
Error: Process completed with exit code 2.
Expected behavior
Behave like az storage blob upload-batch (or other az storage blob commands) and support --auth-mode login
Environment Summary
azure-cli                         2.49.0
core                              2.49.0
telemetry                          1.0.8
Extensions:
azure-devops                      0.26.0
resource-graph                     2.1.0
Dependencies:
msal                              1.20.0
azure-mgmt-resource               22.0.0
Python location '/opt/az/bin/python3'
Extensions directory '/opt/az/azcliextensions'
Python (Linux) 3.10.10 (main, May 19 2023, 08:20:31) [GCC 11.3.0]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
Appears similar to https://github.com/Azure/azure-cli/issues/16071 but that one is closed

Thank you for opening this issue, we will look into it.

For az storage blob sync we are using AzCopy under the hood. Please refer here https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-authorize-azure-active-directory for the desired logged in identity. Then just call the command az storage blob sync without --auth-mode login

Hi @calvinhzy we tried what you suggested but find it does not work if the storage container has shared key access disabled. This is likely because azcopy is acquiring an account key and using that. It should still work in this scenario, however. Here is some log output describing the problem:
WARNING:  There are no credentials provided in your command and environment, we will query for account key for your storage account. It is recommended to provide --connection-string, --account-key or --sas-token in your command as credentials.
and
`Cannot perform sync due to error: cannot list files due to reason -> github.com/Azure/azure-storage-blob-go/azblob.newStorageError, /home/vsts/go/pkg/mod/github.com/!azure/azure-storage-blob-go@v0.13.1-0.20210823171415-e7932f52ad61/azblob/zc_storage_error.go:42
===== RESPONSE ERROR (ServiceCode=KeyBasedAuthenticationNotPermitted) =====
Description=Key based authentication is not permitted on this storage account.
RequestId:b9de306f-501e-00be-6840-adbea9000000
Time:2023-07-02T23:56:23.1833127Z, Details:
Code: KeyBasedAuthenticationNotPermitted
GET https://REDACTED
User-Agent: [AzCopy/10.13.0 Azure-Storage/0.14 (go1.16; linux)]
X-Ms-Client-Request-Id: [390a4353-e273-4eae-65ae-6b4f002323d1]
X-Ms-Version: [2019-12-12]
RESPONSE Status: 403 Key based authentication is not permitted on this storage account.
Content-Length: [269]
Content-Type: [application/xml]
Date: [Sun, 02 Jul 2023 23:56:23 GMT]
Server: [Microsoft-HTTPAPI/2.0]
X-Ms-Error-Code: [KeyBasedAuthenticationNotPermitted]
X-Ms-Request-Id: [b9de306f-501e-00be-68[40]`
please advise of any likely fix for this issue

Can you refer to the part for login in to Azure AD
https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-authorize-azure-active-directory?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&bc=%2Fazure%2Fstorage%2Fblobs%2Fbreadcrumb%2Ftoc.json

https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-authorize-azure-active-directory?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&bc=%2Fazure%2Fstorage%2Fblobs%2Fbreadcrumb%2Ftoc.json

The alternative is to call the az command with --sas-token.

@stephenhogg-des  @dvasdekis  Can you refer to the part for login in to Azure AD and make sure the role assignment is correct
https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&bc=%2Fazure%2Fstorage%2Fblobs%2Fbreadcrumb%2Ftoc.json

https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-authorize-azure-active-directory?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&bc=%2Fazure%2Fstorage%2Fblobs%2Fbreadcrumb%2Ftoc.json

The alternative is to call the az command with --sas-token.

The role assignment is correct. Also the usage of a sas token is blocked as the storage account has the above discussed setting switched on

Hi again @calvinhzy - just to repeat, the issue we are facing is not related to role assignments. It is about shared access key usage. When we allow access to a container using a shared key, there is no problem. The problem occurs when shared access key usage is disabled, because azcopy is trying to authenticate with a shared key. We should still be able to use azcopy when shared access key usage is disabled, though.

Have you tried login with azcopy with Azure AD, if shared access key is not enabled, it is hard to imagine azcopy would work without any authentication method. (sas token or account key).

Hi @calvinhzy we are able to do az storage blob upload-batch --auth-mode login without error. It is just az storage blob sync that has a problem when shared access key usage is disabled.

Try running azcopy login and run az storage blob sync again

Hi @calvinhzy that solution does not work for us. We cannot run azcopy login because we cannot login interactively and do not have a secret or certificate. We are logging into Azure using OIDC authentication (see https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Clinux#use-the-azure-login-action-with-openid-connect if you are unfamiliar with this), and therefore do not have a secret or certificate. Please advise on how to fix our issue.
``

@stephenhogg-des @dvasdekis We totally understand your pain points.
Let me clarify sth here: az storage blob sync calls azcopy under the hood and pass through almost every parameter. We should support everything that azcopy supports.
azcopy supports AAD auth in two ways:

customer sign in interactively on website
client tool retrieves an OAuth token and then places that token into a secret store on customer's system

CLI was trying to integrate with azcopy AAD auth using the second way. But it requires different secret stores for different operating systems. It takes large efforts since CLI claims to support a lot of systems and doesn't worth doing that just for 1 or 2 commands. Besides, there was technical difficulties to retrieve all Auth info that azcopy needs (CLI is using different auth dependencies and APIs with azcopy, we can't get refresh token but azcopy requires). That's why we disable --auth-mode login for az storage blob sync/az storage copy commands.
Back to your scenario, if your runner always use linux system and have a secret store (eg. Linux keyring), you could try to use the second way by yourself. I can help add AzCopy label to notify azcopy team or you can create a new issue in azure-storage-azcopy repo to ask guidance for AAD auth without interactive mode.

I'm having this same issue in our CI system, which runs on kubernetes and uses a user assigned managed identity with OIDC federation. To login to azure CLI we use this command, which also really shouldn't need to be done as the env vars are already in place, but that's a separate issue https://github.com/Azure/azure-cli/issues/26858
az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" --service-principal -u $AZURE_CLIENT_ID -t $AZURE_TENANT_ID

I don't see those same options in azcopy login --help. Am I missing something here?
These are the environment variables Azure AD Workload Identity injects into the kuberntes pod.
See the "Properties" drop-down at the beginning of this page:
https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html
AZURE_AUTHORITY_HOST | The Azure Active Directory (AAD) endpoint.
AZURE_CLIENT_ID | The client ID of the AAD application or user-assigned managed identity.
AZURE_TENANT_ID | The tenant ID of the registered AAD application or user-assigned managed identity.
AZURE_FEDERATED_TOKEN_FILE | The path of the projected service account token file. /var/run/secrets/azure/tokens/azure-identity-token
Can the az or azcopy CLI tool simply use the DefaultAzureCredential Class and transparently handle auth without even needing any extra login commands or take these same vars as CLI arguments?

It looks like this is still an ongoing issue, my team is facing the same blocking point.  Is there an update on this?
Thank you!

Is there any update on this issue? We are blocked by the lack of the --auth-mode login flag and as far as I can tell, many people have complained about it since 4 years ago (when the original issue was created).


Add a new field named cluster for multiple Druid clusters

Description
For now, there are 5 fields in our Metric System, as follows:

timestamp - the time the metric was created
metric - the name of the metric
service - the service name that emitted the metric
host - the host name that emitted the metric
value - some numeric value associated with the metric

However, they are not enough for multiple Druid clusters. We still need to add a new field named cluster in the Druid Metric System, so that we can use one single Kafka Topic to store all of metric data.

cluster - the name of the Druid cluster, default as druid

Especially in the Cloud-Native situation, the creation of Druid cluster is very easy. If one single Kafka Topic is shared, not only the creation process of Kafka Topic can be omitted (for example, the Kafka cluster outside of Kubernetes), but the resource utilization rate will be relatively high (such as, the metrics data of some of Druid cluster is very tiny, even allocating a Partition is a bit of a waste of resource).

The druid.emitter.kafka.clusterName configuration is good enough, will close this one.


Hot Reloading - Packager does not rebuild code

Is this a bug report?
yes

Have you read the Contributing Guidelines?
No
Environment
Environment:
OS:  Linux 4.10
Node:  7.10.0
Yarn:  1.3.2
npm:  4.2.0
Watchman:  4.9.0
Xcode:  N/A
Android Studio:  Not Found
Packages: (wanted => installed)
react: 16.0.0-beta.5 => 16.0.0-beta.5
react-native: 0.49.3 => 0.49.3
Target Platform: Android (7.0)
Steps to Reproduce
This is very hard to tell, it suddenly broke... init a new react-native project and work a while, maybe it breaks too?
Expected Behavior
Like it was, i expect that the packager will rebuild the app once i change something.
Actual Behavior
"Hot reloading" does not work anymore. Everything used to work really well until some days ago. I dont know what changed but the functionality broke and that is very inconvenient. Once i apply changes to my code i can see the toast message "Hot Loading..." on my phone, so the "watching" seems to work. But i cant see the "bundling index.js..." line in my terminal (where i am running the packager via npm start or react-native start). Using the android emulator does not change anything.
If i shake the phone, which brings up the dev menu and select "Reload" i can actually see the bundling in the packager process (in my terminal) and the app reloads correctly.
In this issue i read, that a .lock file may prevent watchman from detecting the change, so i moved my yarn.lock to _yarnlock to test that. But that did not work (i also restarted the packager with [ctrl]+C and re-running npm start).
Reinstalling watchman (from source again) did not change the behavior either.
Reproducible Demo
nope

https://github.com/facebook/react-native/issues/16505

had to enable hot reloading and then live reload, then I reload JS before I got it to work.


Mobile Theme View Option

Part of the original wireframes.
Not necessary for MVP.

addd in https://github.com/muxinc/player.style/pull/56


feat(ngModelOptions): allow options to be inherited from ancestors

Previously, you had to apply the complete set of ngModelOptions at every point where
you might want to modify just one or two settings.
This change allows more general settings to be applied at nearer the top of the DOM
and then for more specific settings to override those general settings further down
in the DOM.
It should also be noted that this change means that ctrl.$options will always reference a valid object
and so a large part of this PR is removing the unnecessary checks for existence of that object.
BREAKING CHANGE:
Previously, if a setting was not applied on ngModelOptions, then it would default
to undefined. Now the setting will be inherited from the nearest ngModelOptions
ancestor.
It is possible that an ngModelOptions directive that does not set a property,
has an ancestor ngModelOptions that does set this property to a value other than
undefined. This would cause the ngModel and input controls below this ngModelOptions
directive to display different behaviour. This is fixed by explictly setting the
property in the ngModelOptions to prevent it from inheriting from the ancestor.

Looks good so far, but could you mention the modelOptionsProvider in the commit message?

Btw, in the last paragraph, I am not completely sure what "This would cause the ngModel and input controls below this ngModelOptions directive to display different behaviour." means. Different as in unexpected? Because the option is applied (from ancestor) even though you did not specify it on the current element?

@gkalpak and @Narretz - thanks for the reviews. I will update now.

My main concern about the design of this is that
a) ngModelOptions has to do some post processing on the options which adds some complexity. We could get rid of this with a breaking change to the updateOn option property; but actually it might be a nice feature since we might want to do some processing to optimize model "adaptors" when/if they get implemented.
b) if an ngModel directive has no ancestor ngModelOptions then it needs to get its defaults from the $modelOptions service, but this won't have done the post processing (or we would need to replicate the functionality in both the ngModelOptions directive and the $modelOptions service.
One solution to both of these is to put the post processing into the $modelOptions and then the ngModel and ngModelOptions directives could pass the options to a method to be processed (maybe cached somehow). Then we could be really flexible and allow things to register specific post processors on the options that would be run on all instances of options.

Doing the post processing in the $modelOptions service sounds like a good idea to me.

There was just a new issue opened for that: https://github.com/angular/angular.js/issues/12644
So let's revisit this:
Looks like the post-processing is extracted!
Now what's left, supporting both setting / replacing the options in the provider?
And a rebase.

So I added a bunch more code to this PR.
Given that it is a breaking change anyway, I went all out and broke it properly.
It shouldn't actually break for most users, only those who are writing directives that read from the model options directly.
The upside is that it will allow programmatic changes to model options as well as making it harder to wipe out the options by dodgy overwriting of the ModelOptions object with a POJO.

When you broke it good and proper, did you introduce new BC that aren't yet included in the BC notice?

@Narretz - I still need to update the commit message with the new BC, thanks

LGTM, except some minor issues. And in the commit message there could be an example of how to migrate if a setting that was set to undefined must now be explicitly set to avoid override from a parent / provider setting.

I have updated the commit message. @Narretz PTAL

LGTM

What is the motivation for this change? From the docs:

Although we try to avoid breaking changes, there are some cases where it is unavoidable:

AngularJS has undergone thorough security reviews to make applications safer by default, which drives many of these changes.
Several new features, especially animations, would not be possible without a few changes.
Finally, some outstanding bugs were best fixed by changing an existing API.

This does not seem to fit into any of these categories of unavoidable breaking changes.
As the author of an Angular component library, this is massively breaking due to the fact that we export controls that support ng-model as part of their API, but also consume smaller components in their templates. We have already had to guard against the fact that ng-model does require: '^^ngModelOptions'.
In all the places that we guard against this, we will now also have to add every possible ngModelOptions key explicitly. This has the probably unintentional side effect of making any addition to ngModelOptions (for instance, introducing a new option in Angular 1.7) a breaking change.
This seems like something that has small enough value that it should not have been deemed necessary to make in a minor release.

The main value of this is that you don't have to set your model options for every single input, but can set it either in a parent or in the provider. It's very common that you want the same input behavior for parts of your application. And you can still customize your ngModels per instance. You can even "reset" a sub-part of your application (if you don't know what kind of inputs appear in it for example). At the moment, you need to know the defaults for that, that's true. We could maybe introduce a special value that "resets" the options to the default.
Can you show an example of your component and why it breaks? Is it because with this change you possibly don't know what ngModelOptions are set for the application?

The main value of this is that you don't have to set your model options for every single input, but can set it either in a parent or in the provider.

I personally do not feel that this convenience is enough justification for a breaking change.

Can you show an example of your component and why it breaks? Is it because with this change you possibly don't know what ngModelOptions are set for the application?

This breaks my component because the user was able to inject different behavior past my API boundary with that user. We have this all over our library, but for a simple contrived (though realistic) example:
<!-- myReusableComponent template -->
Enter text: <input ng-model="internalModel" ng-model-options="{ updateOn: 'keypress' }"></input>
This should always update instantly: {{ internalModel}}
<button ng-click="writeToModel(internalModel)"></button>

<!-- Application template -->
<my-reusable-component ng-model="userModel" ng-model-options="{ debounce: 100 }"></my-reusable-component>

The user's intent was to debounce how often that userModel gets written to, however because of the inheritance now they are also affecting how often the internalModel inside of myReusableComponent updates.
So basically I'm (as a library author) forced to guard against an Angular "feature", while at the same time my user (app author) needs to be aware of whether or not the libraries they are using properly guard against this (in order to satisfy users must make sure their apps (and that includes 3rd party code) are compatible with it when they use it - I don't think it is reasonable for users to have to understand the implementation details of the libraries they are using. Seems weird to me if the answer to "can we upgrade to 1.6 safely" includes the statement "I will need to look at ngMaterial's source code to be sure".

I'm also not sure introducing a new option will introduce a BC. A new option will be`optional, so users must make sure their apps (and that includes 3rd party code) are compatible with it when they use it.

If a framework (Angular) changes code that causes my project (library) to no longer work correctly without me doing work, that is by definition a breaking change. If one of my users starts to use a new option somewhere higher up in the DOM, that option will cause my implementation details to behave differently, causing my library to need code changes.

This is an interesting use case that we had not thought about. We should definitely work something out here before we release 1.6.0.
Can I be devil's advocate for a moment...

You say, @fenduru, that this PR would make you have to set ngModelOptions for all possible values in every directive that you create. Strictly you only need to set the values of the ones that you care about. In the example case, debounce.
With the behaviour that this PR introduces, any new options added to ngModelOptions would most likely need to be considered as a breaking change since they could affect the behaviour of applications that are already in production. This is the same situation as if we changed the default behaviour of an input directive directly.
So if we followed this approach you would only need to update the ngModelOptions values on your own directives at breaking change versions, e.g. 1.7.0, 1.8.0, etc.

I wonder if this restriction on adding values to ngModelOptions would be too restrictive in any case?
I don't like the idea of adding a "reset" option, since it just adds to the API surface area to work around something in a way that is not intuitive without reading the docs.
One option could be that we, somehow, break the inheritance at isolated scope boundaries. Which means that the ngModelOptions will not impact on components that will have complete control over their ngModelOptions values in their templates. I think this could work, although if users could still update values in the global $modelOptions service then we would potentially have the same problem.
If we cannot find a reasonable solution to this then I agree that we should consider reverting for 1.6.0.

Another idea would be making the inheritance opt-in. E.g. keep ng-model-options non-inheriting (as it was before 1.6.0-rc.0) and add a new ng-extend-model-options (or something)  that does exactly the same except for inheriting (i.e. as it is in 1.6.0-rc.0).
Internally, we will be using the same code with a flag for inheriting vs not inheriting.

Hmm, @gkalpak, I kind of like it but it makes me feel bit queasy...
Perhaps rather than a new directive we just added a property to the ngModelOptions bag, such as inherit: true?
So then you would have:
<form ng-model-options="{ debounce: true }">
  <div ng-model-options="{ inherit:true, allowInvalid: true }">
    <input ng-model="o.x"> <!-- this will have { debounce:  true, allowInvalid: true } -->
    <input ng-model-options="{ updateOn: 'keypress' }" ng-model="o.y"> <!-- this will only have { updateOn: 'keypress' } -->
  </div>
</form>

Would that work??

I'm not a fan of putting another option in the bag. The options affects the ngModel directive, not how the ngModelOptions directive works. It also doesn't make much sense to me that you would have to opt in into the inheritance, because that would defeat the purpose of having to write less code.

Yeah, I am not a big fan of the extra option either. All other options refer to ngModel, but inherit would refer to ngModelOptions. Also what would happen when you inherit inherit: false 😛

It also doesn't make much sense to me that you would have to opt in into the inheritance, because that would defeat the purpose of having to write less code.

Typically, you can save several characters via inheritance, so an extra few character (like -extend or -ext) doesn't defeat the purpose imo. Most importantly, inheritance comes in handy when you want to have consistent behavior across several instances without having to repeat the same code, which makes it easier to make changes in one place and have them propagate to children (via inheritance). This attribute of the feature remains unaffected: You only write -extend once and then any change you make to an ancestor ngModeOptions propagates automatically.

inherit: false would not inherit :-P
There was a request to be able to set defaults for ngModelOptions at an application level - but this would also break the use case given by @fenduru.
The original motivation behind making ngModelOptions inheritable was to support potential changes to ngModel regarding how validators and parsers/formatters work. I believe that it is unlikely that we will implement these changes. (Instead it is more likely that we could offer a completely new forms library that people could opt into).
So I think it is simplest just to revert this feature.
WDYT?

One option could be that we, somehow, break the inheritance at isolated scope boundaries.

This is something that I have desired in the past to prevent transcluded content from being able to require controllers beyond a boundary (I forget the exact use case now though). Even if it is possible, this sort of things seems too high risk to be worth it IMO.

Another idea would be making the inheritance opt-in. E.g. keep ng-model-options non-inheriting (as it was before 1.6.0-rc.0) and add a new ng-extend-model-options (or something)

This seems like probably the best way of accomplishing this goal. I agree it feels weird, but it also seems the most technically correct / least risky way of doing this.

I'm not a fan of putting another option in the bag. The options affects the ngModel directive, not how the ngModelOptions directive works.

I agree philosophically here, but wouldn't hate this if it made the ergonomics better - though I think ng-extend-model-options is probably just as ergonomic
I'm a big fan of opt in solutions here. Currently a user can accomplish something very similar by putting a function on their scope and writing ng-model-options="extendDefaults({ debounce: 100 })" - this might be slightly annoying to do if you have many different scope that want this, but perhaps ng-model-options could pass a local function to the expression? So ng-model-options="$extendDefaults({ debounce: 100 })" (or some better name - naming is hard).

There's a valid use-case for this feature, so I'm not happy with simply reverting it. Introducing a new directive / behavior that achieves inheritance is fine with me. It should be easy to replace ng-model-options with it, so maybe ng-model-options-extend or ng-model-options-inherit


[3.2] Test collision mask before creating constraint pair in Godot physics broadphase 2D and 3D.

This is a the 3.2 branch version of PR #39399.

Thanks!

@madmiraal This PR breaks this test project: Get_colliding_bodies_misbehavior_regression_test.zip
It works in 3.2.1 and doesn't work in 3.2.2. I did a git bisect to find this PR.

As Aaron mentions, this change unfortunately caused a regression that heavily affected my team's project!
Area2D's get_overlapping_bodies no longer works if the body inside the area is enabled after already entering the area. It might be safe to assume this problem affects get_overlapping_areas and may have affected 3D as well.
I made the minimal project to exemplify the problem so we could perform a bisect to deduct that the problem was here. If it outputs 'True' then it is good. If it outputs 'False' then it is no longer working. You will notice that between 3.2.1 and 3.2.2 this regression occurs & the bisect pointed us to here.
$ git bisect bad
5794a4e11e7a8ade3916622c030af6cc1a553a37 is the first bad commit
commit 5794a4e11e7a8ade3916622c030af6cc1a553a37
Author: Marcel Admiraal<EMAIL_ADDRESS>Date:   Mon Jun 8 17:18:23 2020 +0100

    Test collision mask before creating constraint pair in Godot physics
    broadphase 2D and 3D.

 servers/physics/broad_phase_basic.cpp           | 7 +++++--
 servers/physics/space_sw.cpp                    | 6 ++++++
 servers/physics_2d/broad_phase_2d_basic.cpp     | 7 +++++--
 servers/physics_2d/broad_phase_2d_hash_grid.cpp | 5 ++++-
 servers/physics_2d/space_2d_sw.cpp              | 6 ++++++
 5 files changed, 26 insertions(+), 5 deletions(-)

This is #39487 referenced above, which was since fixed with #39505 (master) and #39504 (3.2). Can you confirm?

Ah, yes, it's fixed in the 3.2 branch. I should've tested the head, but I only tested 3.2.1 and 3.2.2 and the commits between them.

No, there is zero crashing experienced with this bug in 3.2.2 . The triggers simply do not show the body in get_overlapping_bodies if the body enables the relevant collision layer. Once the body leaves the overlaps and then enters it again, it will show up in get_overlapping_bodies. I will compile master tonight to see if the bug still exists.

@agameraaron You should compile the 3.2 branch. master is 4.0, and might not be compatible with your project, or lead to different issues.

Okay, thank you. I am including an update to the minimal test. It includes the ability to move around so you can see the project does not freeze & that in versions with the regression it is only when you fully exit the area and re-enter it does it see include the body in the get_overlapping_bodies function. Otherwise it normally will say "Good" (true) without having to move.
Get colliding bodies misbehavior regression test v0-2.zip

@agameraaron your example project is working on the current<PHONE_NUMBER> 3.2 branch, which includes #39895 and #40114.

Yep! Came back to report it's working with the latest compiled 3.2.3.beta as of last night. :partying_face:


Voice animation is no longer centered

It seems the new animation changes the size of the element, as can be seen when used in inline chat:


How to enable Tree-shaking?

First of all, congrats on the great work, for now it is all working (using vue and semantic-ui).
One question. Is Tree-shaking enabled by default? It does not seem like so, here. How do i enable it?
Here you say its supported: https://github.com/JeffreyWay/laravel-mix/blob/master/docs/mixjs.md
Thanks in advance!

Where supported, tree-shaking will take place automatically when you do npm run production.

@JeffreyWay could you elaborate a little on "where supported" ? Is it either a fully on or fully off feature? If I use one CommonJS module will that mean the whole project cannot be tree shaken?
Thanks 👍

@njbarrett @JeffreyWay I'd also like to know this.

This seems to be an issue still, @JeffreyWay . I'm using 2.1.11.
For example:
npm install gsap
test-1.js:
import {CSSPlugin} from 'gsap/all';

npm run production gives a file size of: 178 kB
test-2.js:
import {CSSPlugin} from 'gsap/CSSPlugin';

npm run production gives a file size of: 71.1 kB
That's quite a difference.
Inside of gsap/all is the following:
/*!
 * VERSION: 2.0.1
 * DATE: 2018-05-30
 * UPDATES AND DOCS AT: http://greensock.com
 *
 * @license Copyright (c) 2008-2018, GreenSock. All rights reserved.
 * This work is subject to the terms at http://greensock.com/standard-license or for
 * Club GreenSock members, the software agreement that was issued with your membership.
 *
 * @author: Jack Doyle<EMAIL_ADDRESS> **/
import TweenLite, {Ease, Power0, Power1, Power2, Power3, Power4, Linear, _gsScope} from "./TweenLite.js";

import TweenMax from "./TweenMaxBase.js";
import TimelineLite from "./TimelineLite.js";
import TimelineMax from "./TimelineMax.js";

// plugins
import AttrPlugin from "./AttrPlugin.js";
import BezierPlugin from "./BezierPlugin.js";
import ColorPropsPlugin from "./ColorPropsPlugin.js";
import CSSPlugin from "./CSSPlugin.js";
import CSSRulePlugin from "./CSSRulePlugin.js";
import DirectionalRotationPlugin from "./DirectionalRotationPlugin.js";
import EaselPlugin from "./EaselPlugin.js";
import EndArrayPlugin from "./EndArrayPlugin.js";
import ModifiersPlugin from "./ModifiersPlugin.js";
import PixiPlugin from "./PixiPlugin.js";
import RoundPropsPlugin from "./RoundPropsPlugin.js";
import ScrollToPlugin from "./ScrollToPlugin.js";
import TextPlugin from "./TextPlugin.js";

// utils
import Draggable from "./Draggable.js";

// easing
import {
	Back,
	Elastic,
	Bounce,
	RoughEase,
	SlowMo,
	SteppedEase,
	Circ,
	Expo,
	Sine,
	ExpoScaleEase
} from "./EasePack.js";

export {
	TweenLite,
	TweenMax,
	TimelineLite,
	TimelineMax,
	_gsScope,

	// plugins
	AttrPlugin,
	BezierPlugin,
	ColorPropsPlugin,
	CSSPlugin,
	CSSRulePlugin,
	DirectionalRotationPlugin,
	EaselPlugin,
	EndArrayPlugin,
	ModifiersPlugin,
	PixiPlugin,
	RoundPropsPlugin,
	ScrollToPlugin,
	TextPlugin,

	// utils
	Draggable,

	// easing
	Ease,
	Power0,
	Power1,
	Power2,
	Power3,
	Power4,
	Linear,
	Back,
	Elastic,
	Bounce,
	RoughEase,
	SlowMo,
	SteppedEase,
	Circ,
	Expo,
	Sine,
	ExpoScaleEase

};

So, from what I understand about tree shaking, my file size should be identical regardless of if I import from gsap/all or gsap/CSSPlugin.
Perhaps this is my misunderstanding of webpack (which is possible since I use laravel-mix specifically to avoid it).
Historically, I know that GSAP had issues preventing tree shaking. But that seems to be all fixed now.
Is there a problem with tree shaking, or am I doing something wrong?
Cheers!

I'm also having some issues understanding tree shaking in my project, cause it doesn't look like it's working, any updates here?

Shouldn't this maybe be reopened? I just downloaded the latest laravel 6 and tried out tree shaking and it didn't seem to work out of the box.

It seems to me that GSAP 3 does some stuff under the hood to prevent tree shaking of CSSPlugin  and gsap-core. I opened an issue here: https://github.com/greensock/GSAP/issues/374 .


Wrong HTTP method used on a supported path doesn't produce any log message

Steps to reproduce

deploy knot.x extension that handles POST /services/search/products/details requests
make sure routing is configured accordingly (take a look at config snippet below)
send GET request to /services/search/products/details

Expected state

404 response & information in the logs about unsupported path

Current state

404 gets back to the client
Lack of any message in the logs

Noteworthy factoids

call to a path that's not listed in the configuration anywhere causes expected log message: WARN  i.k.s.SupportedMethodsAndPathsHandler - Requested path /test is not supported based on configuration
log level was increased to TRACE, but that didn't help
configuration snippet that may be useful

"customFlow": {
    "...",
    "routing": {
        "GET": [
            "..."
        ],
        "POST": [
            {
                "address": "knotx.gateway.gatewayknot",
                "onTransition": {
                    "next": {
                        "address": "search.products.details"
                    }
                },
                "path": "/services/search/products/details"
            },
            "..."
        ]
    }
}

I see that you're actually getting the WARN message in LOG about that situation, whilest in "current state" you pointed out that no appropriate logs.
Could you please clarify what's your expectations?

The problem occurs when you use GET method on a supported path (defined in routing) that accepts only POST requests, i.e POST /my/endpoint is supported, but I sent GET /my/endpoint instead.
Proper log message gets printed when you ask for a path that's not present in routing configuration, i.e. /test in my example above.

Fixed in #347


react-hot-toast animation for indicating success and failure in the client side

Fixes https://github.com/humphd/my-photohub/issues/37

Warning: Before this PR to be merged and reviewed, please first read through the other PR I have raised at https://github.com/humphd/my-photohub/pull/35. Since this changes also includes the changes from previous PR

I have used react-hot-toast module to add spinner animation.
A fail on uploading a photo will look like

A successful attempt of uploading photo will look like

Thank you, just updated the https://github.com/humphd/my-photohub/pull/35


Window

Where can I find windows version of HPOworkbench?
Thanks

Hi!
You can download the latest Release
https://github.com/TheJacksonLaboratory/HPOworkbench/releases/tag/v.1.1.0
This is a "jar" file, which will run if your windows system has Java installed (version 1.8).
Probably it will work if you download the file HpoWorkbench.jar to your Desktop (or whereever) and then just double click on it. Alternatively, you can open a terminal and enter
java -jar HpoWorkbench.jar

Could you please try this and let me know if it works?

There is now a newer release. It should work under windows. I am closing this issue for now, please reopen if there are problems!

Thanks Dr. Robinson
Jar file not working on windows. I will try the new version.
Thanks
Suva
On Tue, Oct 9, 2018 at 3:11 AM Peter Robinson<EMAIL_ADDRESS>wrote:

There is now a newer release. It should work under windows. I am closing
this issue for now, please reopen if there are problems!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/TheJacksonLaboratory/HPOworkbench/issues/38#issuecomment-428137238,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Apfr3u3xKty1-Cnv3J4wJzqoEfVNViJQks5ujHZMgaJpZM4W1k3w
.


Polishing after 0.9

Design Two:

[x] Next- Prev- Article not correct linked/ lead to error page

[x] Click on logo leads to AMP front page even if selected “Custom AMP front page = OFF"

[x] Next- Prev- Article not deselectable anymore

[x] Tags link link to AMP-version of archive pages even if selected “Hide AMP on Archive Pages”

[x] Footer Ad gets covered by Sticky Social Icons (a little bit more scrolling down would be good, ok with design one)

[x] Featured image caption missing (already reported in #263)

Design One:

[x] How to remove “Powered by WordPress”?

[x] Related article excerpt sometimes a little bit too long (jumps below the image)

[x] Click on left logo leads to strange AMP version of the front page (selected “Custom AMP front page = OFF”)

[x] No tags available

[x] Bullseye logo on the right side leads correct to front page but the logo itself is totally squeezed

[x] Date translation is incorrect. (German)

**REF:**https://wordpress.org/support/topic/issues-open-points-v-0-9/

@MohammedKaludi
Please do the following 👍

Footer Ad gets covered by Sticky Social Icons (a little bit more scrolling down would be good, ok with design one)

Featured image caption missing (already reported in #263)

Done and dusted.


Feature/353 support replicating contexts

Closes #353

See tests on how the events are emitted to notify the progress of the migration, which will be helpful to display in the user interface:
https://github.com/verida/verida-js/pull/354/files#diff-d94d706630a3f377d01588c3498bb5c8e9e091ff75a89fbf77735fa275e4cb9eR76


The package cmather:iron-router at 0.8.1 is incompatible with Meteor 0.9.0 or later.

I have updated my meteor and meteor project. I'm using Iron-router and I got this error:
The package cmather:iron-router at 0.8.1 is incompatible with Meteor 0.9.0 or later.

Iron router changed name. Remove the old and add the new
meteor remove cmather:iron-router
meteor add iron:router


V2.0 - Fails to load with default configuration from before

Error message stating that one or more libraries need to be configured but I have one configured, just not for posters.
Logs:

    return _bootstrap._gcd_import(name[level:], package, level)

  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import

  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load

  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked

  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked

  File "<frozen importlib._bootstrap_external>", line 850, in exec_module

  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed

  File "/app/movie_selector.py", line 17, in <module>

    from utils.fetch_movie_links import fetch_movie_links

  File "/app/utils/fetch_movie_links.py", line 10, in <module>

    raise EnvironmentError("At least one service (Plex or Jellyfin) must be configured.")

OSError: At least one service (Plex or Jellyfin) must be configured.```

Compose:
```services:
  plex-random-movie:
    image: ghcr.io/sahara101/movie-roulette:latest
    container_name: movie-roulette
    network_mode: host
    environment:
      HOMEPAGE_MODE: "FALSE"
      PLEX_URL: "https://plex.{{REDACTED}}.com"
      PLEX_TOKEN: "{{REDACTED}}"
      MOVIES_LIBRARY_NAME: 'Movies'
      TZ: America/New_York
    volumes:
      - /portainer/Files/AppData/Config/movie_roulette:/app/data
    restart: unless-stopped
    ```

Hey, I added on the README it was a breaking change, had to change the ENV name to make more sense. Please use PLEX_MOVIE_LIBRARIES:

OK, now I am getting:
ERROR:utils.jellyfin_service:Error fetching active Jellyfin sessions: Invalid URL 'None/Sessions': No scheme supplied. Perhaps you meant https://None/Sessions?

I only setup Plex

Thank, that is a bug. I will remove the error, but it should work nontheless now.

I will keep it stopped until the next release to fix that issue so it is not spamming the logs but it does work with the changed ENV for Plex Movies. Sorry I overlooked that.

The Jellyfin error is fixed in the dev image. I will release a new latest version shortly.

Hey, latest version is released, please update to it :)

Looks good!


Scope of this project & style guide debates

Consider #80. Even though the issue is closed there are some points the disposition and approach to that issue raise:

The aim of this project (gts) seems to be to enable the Google style guide for anyone (Google, non-Google) who wants to use it.
However, it is not the right venue to debate the style guide itself. We are basically mirroring what Google uses internally and cannot (should not) editorialize the style itself.
This means that this repo isn't the best venue to debate the style guide.
The style guide document itself isn't public (yet). This makes it hard for users to understand the context and rationale behind the style rules.

The question becomes, how do we deal with critiques of the style guide:

'This is not the correct venue for debates on the style guide'. This is unfulfilling for external users.
Try to proxy concerns between internal and external venues. Somewhat better but still unfulfilling.
Over the longer term, make this repo host the externalized style guide & make this authoritative?

@JustinBeckwith @mprobst: Thoughts?

Great discussion topic.  I'm already running into issues where I need to go digging into the private TypeScript style guide to figure out why rules are the way they are.
I think we should have the TypeScript rules published here:
https://github.com/google/styleguide
And have a public page similar to this:
https://google.github.io/styleguide/jsguide.html
In fullness of time - I think convergence is the only viable option.  One set of rules, internally and externally.  I think it's great to engage in conversations about the rules, with the understanding that at the end of the day we have the final call.

Proxy to internal debates seems reasonable for the time being. We try to be
reasonable and responsive :-) though might fail occasionally.
I do agree it'd be nice to publish the style guide itself.

I'm going to close this issue as there isn't anything immediately actionable on this repo. We are hopeful that the style guide would be public at some point.


Change unicode() --> six.text_type() for Python 3

unicode() was removed in Python 3 because all str are Unicode so this PR changes four calls to unicode() into calls to six.text_type().

@ekelsen Was there something more that I needed to do on this one?


"no wheels with a matching Python implementation tag" with inequality constraint, but no issues with equality constraint

Intro
Trying to support a package which should install different implementations of PyTorch and related packages based on the value of UV_EXTRA_INDEX_URL, but am having issues with their cpu index (https://download.pytorch.org/whl/cpu). Namely it seems that torchX.X.X+cpu as a dependency of torchvision doesn't get recognized unless I specify a strict version
Platform (uname -sri): Linux 5.14.0-362.13.1.el9_3.x86_64 x86_64
uv version: uv 0.3.1
Steps to reproduce
Prep

Create venv using uv venv: $ uv venv -p python3.10
Activate it souce .venv/bin/activate

Failure mode 1

Try installing torchvision>=0.18.0 with the aforementioned index url:

$ uv pip install --index-url https://download.pytorch.org/whl/cpu "torchvision>=0.18.0"

Get the following error (click to unfold)
× No solution found when resolving dependencies:
  ╰─▶ Because only the following versions of torchvision are available:
          torchvision<=0.18.0
          torchvision==0.18.0+cpu
          torchvision==0.18.1
          torchvision==0.18.1+cpu
          torchvision==0.19.0
          torchvision==0.19.0+cpu
          torchvision==0.19.1
          torchvision==0.19.1+cpu
      and torchvision==0.18.0 has no wheels with a matching Python implementation tag, we can conclude that torchvision>=0.18.0,<0.18.0+cpu cannot be used. (1)

      Because torch==2.3.0 has no wheels with a matching Python implementation tag and torchvision==0.18.0+cpu depends on torch==2.3.0, we can conclude that torchvision==0.18.0+cpu cannot
      be used.
      And because we know from (1) that torchvision>=0.18.0,<0.18.0+cpu cannot be used, we can conclude that torchvision>=0.18.0,<0.18.1 cannot be used.
      And because torchvision==0.18.1 has no wheels with a matching Python implementation tag, we can conclude that torchvision>=0.18.0,<0.18.1+cpu cannot be used. (2)

      Because torch==2.3.1 has no wheels with a matching Python implementation tag and torchvision==0.18.1+cpu depends on torch==2.3.1, we can conclude that torchvision==0.18.1+cpu cannot
      be used.
      And because we know from (2) that torchvision>=0.18.0,<0.18.1+cpu cannot be used, we can conclude that torchvision>=0.18.0,<0.19.0 cannot be used.
      And because torchvision==0.19.0 has no wheels with a matching Python implementation tag, we can conclude that torchvision>=0.18.0,<0.19.0+cpu cannot be used. (3)

      Because torch==2.4.0 has no wheels with a matching Python implementation tag and torchvision==0.19.0+cpu depends on torch==2.4.0, we can conclude that torchvision==0.19.0+cpu cannot
      be used.
      And because we know from (3) that torchvision>=0.18.0,<0.19.0+cpu cannot be used, we can conclude that torchvision>=0.18.0,<0.19.1 cannot be used.
      And because torchvision==0.19.1 has no wheels with a matching Python implementation tag, we can conclude that torchvision>=0.18.0,<0.19.1+cpu cannot be used. (4)

      Because torch==2.4.1 has no wheels with a matching Python implementation tag and torchvision==0.19.1+cpu depends on torch==2.4.1, we can conclude that torchvision==0.19.1+cpu cannot
      be used.
      And because we know from (4) that torchvision>=0.18.0,<0.19.1+cpu cannot be used, we can conclude that torchvision>=0.18.0 cannot be used.
      And because you require torchvision>=0.18.0, we can conclude that your requirements are unsatisfiable.

Failure mode 2

Try installing torchvision==0.18.0+cpu with the aforementioned index url:

$ uv pip install --index-url https://download.pytorch.org/whl/cpu "torchvision==0.18.0+cpu"

Get the following error (click to unfold)
× No solution found when resolving dependencies:
╰─▶ Because torch==2.3.0 has no wheels with a matching Python implementation tag and torchvision==0.18.0+cpu depends on torch==2.3.0, we can conclude that torchvision==0.18.0+cpu cannot
    be used.
    And because you require torchvision==0.18.0+cpu, we can conclude that your requirements are unsatisfiable.

Failure mode 3

Try installing torchvision==0.18.0 with the aforementioned index url:

$ uv pip install --index-url https://download.pytorch.org/whl/cpu "torchvision==0.18.0"

Get the following error (click to unfold)
× No solution found when resolving dependencies:
╰─▶ Because torchvision==0.18.0 has no wheels with a matching Python implementation tag and you require torchvision==0.18.0, we can conclude that your requirements are unsatisfiable.

Pseudo-success case

Install torchvision==0.18.0+cpu and torch==2.3.0+cpu explicitly:

$ uv pip install --index-url https://download.pytorch.org/whl/cpu "torchvision==0.18.0+cpu" "torch==2.3.0+cpu"

Installation succeeds.

Conclusion
Not quite sure how to interpret what's happening other than:

It seems that torchvision==0.18.0+cpu wants torch==2.3.0 as a dependency (failure mode 1 & 2)
...But it doesn't recognize torch==2.3.0+cpu as supplying torch==2.3.0?... (failure mode 2)
...Unless I install it explicitly? (pseudo-success case)

Not sure what to make of failure mode 3

Seems related to #1497

Have you read https://docs.astral.sh/uv/pip/compatibility/#local-version-identifiers?

Thanks for the quick reply!
I have now read the link you sent.
Apologies if this issue is adding to the noise. I'm working around this with the --override flag for now.
Feel free to close this if there's no plan for things to change in the near future.
Cheers

No worries at all! I'd like to improve it long-term but probably not in the immediate future :)


AMQ Broker Operator

@jstrickl-redhat and I have put together a base set of files for AMQ Broker Operator, including instance components to facilitate different sets of broker configuration.

There is currently a false negative in the lint-manifests job, due to the use of partial Kustomize Components. Components allow referencing resources that are not directly included within the manifest of the component. This "partial" view of a component allows us to make modification regardless of which other component introduced the resource.
For example, the component at amq-broker-operator/instance/components/certificates/public-ca-truststores/letsencrypt-prod/console-ssl-keystore expects a pre-existing secret named console-ssl-keystore and updates it to use a letsencrypt CA certificates for trust chains. There are multiple options for creating console-ssl-keystore, also including the implicit option to manually create the resource in an overlay.
To help resolve this false negative, I've submitted a secondary pull request to skip components that fail a kustomize build at #325

Will merge this as soon as the @codekow gives the thumbs up changing the linting process.

LTGM.  Thanks.

I've rebased to pick up the changed script from #325 . I'll fix the lint-yaml errors and then remove draft status.

This is a fantastic piece of work!
As a follow up, I think it would be great if we could add some READMEs for the components that include some details of what each component does.
Take a look at what we did for the gitops operator as an example:
https://github.com/redhat-cop/gitops-catalog/tree/main/openshift-gitops-operator/instance/components/annotation-resource-tracking

Yes, I had planned to add documentation/READMEs throughout the amq-broker-operator tree. I haven't been able to dedicate the time to that yet and didn't want to continue holding the whole PR hostage to my time.
Thank you for the link to reference, @strangiato ! As time allows, I'll aim to write additional documentation and follow conventions/styles from that gitops operator in future documentation PRs.


Is there a common use case for the type option on Button macro?

I was looking through the nunjucks options for Button, and was confused what type is for. The docs say:

Type of input or button – button, submit or reset. Defaults to submit.

Is there a common use case for this option? I don't think we would suggest anyone uses reset, not sure why you'd need to set it to button, and if there's a niche case, you could use attributes

Setting type to button is frequently done when creating a button that uses JavaScript to provide functionality, rather than submitting a form, such as on our own example cookie banner component.
Although not used an awful lot in the design system/Frontend, it's a fairly small quality of life tweak, and I think it's probably used enough by service teams to warrant existing.

thanks for explaining!


Respect node-glob's nonegate flag

node-glob has a bug where it does not respect negation at the start of the string: https://github.com/isaacs/node-glob/issues/62
The work-around is to respect the nonegate flag. This fix will allow pickFiles to pass that option. The default is the current behavior so will not have any backwards incompatibility issues.

I tried making this change locally and the bug is still presenting... was there any further work done around this?

Broccoli-funnel has superseded broccoli-static-compiler. I assume this is fixed now, in current broccoli-funnel at least, yes?


Can't reorder services

After adding few services to ferdi, i cant reorder some of them - it happens only when Im logged to ferdi, if im using it without account it works fine.
I saw this issue beign closed on 5.5, i've specifically upgraded to 5.6, it still exist there.
see gif:
https://imgur.com/a/xxfoy1G
How to reproduce:
try dragging service up and down, depending on service it might be impossible / move different icon.

@propiro - is there any error in the Developer tools (accessible from the View menu)?
Also, please post the version of Ferdi, your OS, etc

Closing due to inactivity, please report if this is still an issue with the latest release.


Trying to understand pull requests, please ignore

Just trying to verify that I can get a copy of the master on my personal.

My intention here is to pull from the 'master' that we all share into my personal repository, 'masterUntouched'. If this breaks something, know that it is only intended to break MY repository, not the group one. 'jvossy  wants to merge 93 commits into jvossy:masterUntouched from CS2103AUG2017-T13-B2:master' is what github claims, and I pray it does not lie.


Blazor WebAssembly move to netstandard2.1

This moves the Blazor WebAssembly project template, and packages specific to it, to netstandard2.1. This is the TFM we expect to ship with for the Blazor WebAssembly release. Doing this unlocks a whole bunch of more modern .NET Core functionality.
This is possible now because Mono WebAssembly has had many recent updates to support ns2.1 features, plus @lewing helped us discover what changes to the linker config are needed to make that work.
There is a deliberate extra functional change in this PR, which is needed to make the linker still work:

Previously we used to link (i.e., strip code from) only the Mono BCL assemblies, i.e., those bundled in the special Microsoft.AspNetCore.Blazor.Mono package
After this change, we now link any assembly whose name starts with System., regardless of where it comes from

The reason for this change is:

For System.* packages that aren't in the Mono BCL, we want the linker now to use its own logic to decide whether to resolve against Mono's facades or .dll files from NuGet. We weren't doing that before, and it wasn't compatible with ns2.1 because Mono's assembly layout is different from CoreFx's, and we were picking the wrong implementations of System.* assemblies that can come from NuGet packages.
A side-benefit of the new arrangement is that we have an easy way to specify whether or not assemblies are linkable based on filename or other metadata. I've chosen to include Microsoft.Extensions.* simply because they are quite large, and linking them seems to work perfectly well with no obvious drawbacks. This takes 100kb or so off the final app size. Update: I've reverted that bit, so it no longer links Microsoft.Extensions.*, as it was breaking things as per E2E tests. We would need to provide a more detailed treatment for this in linker config.

Merging this
Let's discuss whether we intend to include this in the preview3 branch or whether to merge this later.

WRT merging I think it's too late for preview3, but ask @Pilchie
I'm in favor of this change as it mostly affects client-side Blazor. (The TFM update for nuget packages being the only thing going into 3.1)
Should we also update Microsoft.JSInterop?

Yeah, I’m going to revert the target change in the libraries and make this a change only to the wasm template and build system.
Dropping ns2.0 support for the core libs is not something I think we’d be ok with for 3.1.

@Pilchie @danroth27 OK we have to make a call on whether moving Microsoft.AspNetCore.Components (etc) to netstandard2.1 is something we'd consider doing for the 3.1 release. Either doing it or not doing it is possible. It could be merged within hours either way.
Are we in general changing TFMs to netstandard2.1 for the 3.1 release?

I would rather not unless there is a good reason to do so in the 3.1 timeframe.  We don't have very much preview coverage remaining for 3.1, and it seems like a lot of risk without a clear upside.

@Pilchie OK. What's your opinion about whether to merge this PR for 3.1 as-is? That means it would only affect the Blazor WebAssembly template and packages. That would be helpful to keep things moving on that side, without risking any change in the shared framework packages for 3.1.

We'd still need to get QB approval from tactics if we want this in the 3.1 release.

What's the latest on this? Has it been QB approved for 3.1 GA?

No, I'll rebase it on the new blazor-wasm branch once that's available and merge it there.

The blazor-wasm branch is now available.

Hello experts,
What would be the best way of moving existing projects targeting 2.0 to 2.1?
Thanks!

@rabbitism 3.1 Preview 3 should now be available.


Fix #1150

Coverage remained the same at 79.29% when pulling 79fdb73a65d82a617450790b8cb486a1fce3e750 on josenavas:fix-1150 into 5ff115e2f2fd44b42449fa27b71a58cfe59afa9c on biocore:master.

@biocore/qiita-dev The system will be updated tonight. It will be useful if this PR can make it, as this is generating some confusion to the users (including @ackermag)

:+1:


Geo support missing

Documentation states that:
10. Support for GEO commands (Redis 3.2 Unstable).

I am not seeing any function which would provide such commands, e.g. no GEOADD command. Am I missing something?

Which version of ioredis did you use? There should be GEOADD command.
const Redis = require('ioredis')
const redis = new Redis()

console.log(redis.geoadd)

Looks like the geo related commands are not in the @types/ioredis.

@luin Has anyone maintained @types?

This library is written in Typescript. Is there any particular reason the types are not emitted to NPM? Seems kind of off to keep @types/ioredis. This is a server library too where tree-shaking and bundle size is not particularly a concern.

commands are not in the @types/ioredis.

:(


Hash checking for downloads is gone

https://github.com/neatorobito/scoop-crystal/commit/f5dccd16af15aeceddf3f592e27e0af197b4acd0#diff-51a72be21a2e29db22429ca095acf9be8b06a5360510cc054955feb5f1b65ecc
Why?

The hashes coming from the update script don't match the hash scoop computes. I've seen this before so I don't think it's the update script. I opted to remove them so that you can still use the package while I investigate.


Expose random_state as parameter for thresholders that use RNGs

I integrated PyThresh into our TimeEval tool and I noticed that REGR builds a normal distribution without seeding the RNG. This leads to different results when calling it multiple times despite the same input:
import numpy as np
from pythresh.thresholds.regr import REGR

scores = np.random.default_rng().random(1000)
regr = REGR(random_state=42)
test1 = regr.eval(scores)
test2 = regr.eval(scores)

# this raises an AssertionError
np.testing.assert_array_equal(test1, test2)

This PR lets REGR expose a random_state parameter to seed the NumPy RNG, similar to other thresholders.

EDIT
Common handling of random_state for all thresholders that use RNGs:

all
boot
clust
decomp
dsn
mcst
ocsvm
regr
wind

All of them expose a random_state parameter to seed their RNGs (either used directly or through included libraries, such as sklearn) that is set by default to 1234. This keeps the previous default behavior.

Hi @CodeLionX thanks for submitting this PR! 100%, the random state should have been set for this method. Currently, the rest of the other methods that have random_state set have the variable set statically within them (also to reduce the number of input variables). Therefore, it would probably be best to do so for the REGR thresholder. If you can change do this, I will push the PR through. Thanks again!

hm 🤔
I would actually argue the other way: All thresholders that use some kind of randomness should provide a way to change the seed, but provide a default one (reproducible default behavior). This does not increase the number of parameters the users have to set, but gives the API more flexibility. That would be similar to the NumPy, Pandas, or Scikit-learn APIs. E.g., it allows testing the influence of the randomness on the results and provides a sensible default behavior.
In this case, we should change the other thresholders to expose their random_state parameter as well. I identified the following thresholders:

all
boot
clust
decomp
dsn
mcst
ocsvm
wind

If you stick to your decision, we must also change the VAE-thresholder:
https://github.com/KulikDM/pythresh/blob/e89168aae8d9691abaf331d94f4b9d92782e2920/pythresh/thresholds/vae.py#L59-L60
Please let me know your opinion on it.

Hi @CodeLionX having the random_state statically set was done more so that the user wouldn't use it to manipulate the resulting contamination level (consistency-wise). However, you are right in that it would give the API more flexibility, and allow for the testing the influence of randomness on the results.  Also, yes the VAE thresholder would also require this parameter. It was more a personal choices I made when setting up this package. However, if you are willing to make the necessary changes to the thresholders that require this parameter, I am more than willing to merge this pull request. Thank you for your efforts so far!

Codecov Report
Base: 97.89% // Head: 97.80% // Decreases project coverage by -0.08% :warning:

Coverage data is based on head (0bd10d1) compared to base (f846b80).
Patch coverage: 96.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main       #2      +/-   ##
==========================================
- Coverage   97.89%   97.80%   -0.09%
==========================================
  Files          59       59
  Lines        2086     2093       +7
  Branches      104      102       -2
==========================================
+ Hits         2042     2047       +5
- Misses         17       18       +1
- Partials       27       28       +1

Impacted Files
Coverage Δ

pythresh/thresholds/all.py
95.52% <75.00%> (+0.06%)
:arrow_up:

pythresh/thresholds/boot.py
100.00% <100.00%> (ø)

pythresh/thresholds/clust.py
93.04% <100.00%> (-1.70%)
:arrow_down:

pythresh/thresholds/decomp.py
95.23% <100.00%> (+0.23%)
:arrow_up:

pythresh/thresholds/dsn.py
100.00% <100.00%> (ø)

pythresh/thresholds/mcst.py
96.15% <100.00%> (ø)

pythresh/thresholds/ocsvm.py
100.00% <100.00%> (ø)

pythresh/thresholds/regr.py
88.00% <100.00%> (+0.50%)
:arrow_up:

pythresh/thresholds/wind.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Off-topic: When working on pythresh.thresholds.clust.CLUST, I noticed the following fishy lines:
https://github.com/KulikDM/pythresh/blob/f846b805a6cabaeab46f5791d916d79bb9957ba6/pythresh/thresholds/clust.py#L242-L245
You might want to look into this.

@CodeLionX , thank you. Sorry I somehow missed your final message. This issue has now been fixed. Appreciate the find. Also to give you an update, exposing the random_state parameter was a good decision. In the PyThresh documentation under Benchmarks you will find the fruit of your efforts as I have added a section on the effects of randomness on thresholding (interesting results). Anyways, all the best!

Happy new year! 🎉
Nice analysis and definitely interesting results! Thanks for the update.
Maybe it would be a good idea to add a warning to the PyDoc of the seed-sensitive thresholders (WIND, VAE, REGR, DSN) with the hint to use it in an ensemble? I do not guess everyone will read the Benchmark-section of your documentation, but the class-doc is quite prominent in most tools.

Great idea, I'll add it as a hint in the Class docs as well.
Much appreciated!
On Wed, 4 Jan 2023, 11:03 Sebastian Schmidl, @.***>
wrote:

Happy new year! 🎉
Nice analysis and definitely interesting results! Thanks for the update.
Maybe it would be a good idea to add a warning to the PyDoc of the
seed-sensitive thresholders (WIND, VAE, REGR, DSN) with the hint to use
it in an ensemble? I do not guess everyone will read the Benchmark-section
of your documentation, but the class-doc is quite prominent in most tools.
—
Reply to this email directly, view it on GitHub
https://github.com/KulikDM/pythresh/pull/2#issuecomment-1370644776, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AR3GHGXJQ4YX4F4RZG6LDG3WQU4FJANCNFSM6AAAAAARXCV3RA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


access content://com.android.providers.media.documents/document/image%3A99

I'm getting a content:// uri in android while using react-native-document-picker or react-native-contacts (for the avatars).
URIs like:
'content://com.android.providers.media.documents/document/image%3A99'
Trying to access this file fails with "stat error: failed to list path null for it is not exist or it is not a folder'"
const urlDecoded = decodeURIComponent(url);
return new Promise((resolve, reject) => {
RNFetchBlob.fs.stat(urlDecoded)
.then(resolve)
.catch(reject);
});
Any idea how to access the file?
10x

You should take a look at my PR (https://github.com/wkh237/react-native-fetch-blob/pull/546) although I haven't touch the FS part of this library.
The current implementation in this library for content URIs on Android seems to try to find the file path for a given content URIs. If the file is a virtual file or in a place your app doesn't have access to, this is problematic.


In case you're interested . . .

Added GraphiQL NuGet
The GraphiQL interface didn't work for me so I added a reference to GraphiQL and one line in Startup.cs.
Automatic Database Creation
Uncommented Database.Migrate() to create database in new environments.
Fixed a typo
Near the bottom of GraphQLController

ping @JacekKosciesza


Add validation function for detailed control

Should be possible to easily decide is component filled or not.

No need for now.


how do i use it?

I installed the youtube transcript function, but when i paste a youtube url it doesnt appear to do anything.

No answer? would really like to use this functionality. Hope anyone can give us a hand.
Thanks

I’ll take a look at this in the next week or two, but I just started a new job across the country so unfortunately don’t have the tools or time to look at this currently

I’ll take a look at this in the next week or two, but I just started a new job across the country so unfortunately don’t have the tools or time to look at this currently

Thanks for the response. It is appreciated.

It does invoke for me when I select the tool. It gives an error: "Error: Exception while accessing title of https://youtube.com/watch?v=9HQx5pgUoiY. Please file a bug report at https://github.com/pytube/pytube"
Not sure where it is using Pytube.


⚠ Quirk Club Argentina (Payment Gateway) has degraded performance

In 5da6ff4, Quirk Club Argentina (Payment Gateway) (https://us-central1-quirkclub-dev.cloudfunctions.net/api/check/payment-gateway-ml) experienced degraded performance:

HTTP code: 200
Response time: 7091 ms

Resolved: Quirk Club Argentina (Payment Gateway) performance has improved in 285d3ef.


Regression: completefunc cannot temporarily switch windows any longer (after 8.2.0614)

Describe the bug
:help E840 (under :help complete-items) reads

The function is not allowed to move to another window or delete text.

Previously, move to another window meant that after the completefunc finishes, the current window has to be the same as the original one (where the completion was triggered). Temporarily switching windows (and going back) used to work fine. Since this change:

commit ff06f283e3e4b3ec43012dd3b83f8454c98f6639
Author: Bram Moolenaar<EMAIL_ADDRESS>Date:   2020-04-21 22:01:14 +0200
patch 8.2.0614: get ml_get error when deleting a line in 'completefunc'

Problem:    Get ml_get error when deleting a line in 'completefunc'. (Yegappan
            Lakshmanan)
Solution:   Lock the text while evaluating 'completefunc'.

any attempt to move to another window (e.g. via :wincmd w) raises E565: Not allowed to change text here.
I believe that this is an unintended side effect of using textlock for preventing the deletion of lines. (If this were an intended, compatibility-breaking tightening of rules, E840 should be raised instead of E565.)
To Reproduce
Detailed steps to reproduce the behavior:

Run vim --clean (or gvim --clean, etc.)
Define a dummy completion

    fun! TestComplete(findstart, base)
        wincmd w
        wincmd w
        return (a:findstart ? col('.') : ['foo'])
    endfun

Trigger the completion with more than one window

    :set completefunc=TestComplete
    :new " To have more than one window.
    :execute "normal! a\<C-x>\<C-u>"
    Error detected while processing function TestComplete:
    line    1:
    565: Not allowed to change text here

Expected behavior
I understand the motivation to prevent unexpected changes during completion. However, switching to other windows temporarily should be harmless, is convenient to implement custom completions [1], and sometimes even necessary [2].

In an attempt to simplify the implementation of custom completions, my CompleteHelper plugin searches other windows in order to offer the same functionality as :set complete+=w.
In many cases, the matching of completion candidates could be done without going to the corresponding window (e.g. using getbufline()), but as matching in the current buffer usually is done via search(), it is convenient to reuse that simple implementation for other windows as well. I have some completions like the MotionComplete plugin that uses a queried {motion} to obtain matches. That could not be emulated via low-level string-matching functions, but really has to be executed in that buffer. (And in order to use other windows as sources, it has to go there.)

Environment (please complete the following information):

Vim version Vim 8.2.654
OS: Ubuntu 16.04 LTS 64-bit

Hi,
On Thu, Apr 30, 2020 at 9:02 AM Ingo Karkat<EMAIL_ADDRESS>wrote:

Describe the bug
:help E840 https://vimhelp.appspot.com/insert.txt.html#E840 (under :help
complete-items
https://vimhelp.appspot.com/insert.txt.html#complete-items) reads
The function is not allowed to move to another window or delete text.
Previously, move to another window meant that after the completefunc
finishes, the current window has to be the same as the original one (where
the completion was triggered). Temporarily switching windows (and going
back) used to work fine. Since this change:
commit ff06f28
https://github.com/vim/vim/commit/ff06f283e3e4b3ec43012dd3b83f8454c98f6639
Author: Bram Moolenaar<EMAIL_ADDRESS>Date: 2020-04-21 22:01:14 +0200
patch 8.2.0614: get ml_get error when deleting a line in 'completefunc'
Expected behavior
I understand the motivation to prevent unexpected changes during
completion. However, switching to other windows temporarily should be
harmless, is convenient to implement custom completions [1], and sometimes
even necessary [2].

In an attempt to simplify the implementation of custom completions,
my CompleteHelper plugin
http://www.vim.org/scripts/script.php?script_id=3914 searches other
windows in order to offer the same functionality as :set complete+=w.
In many cases, the matching of completion candidates could be done
without going to the corresponding window (e.g. using getbufline()),
but as matching in the current buffer usually is done via search(), it
is convenient to reuse that simple implementation for other windows as
well. I have some completions like the MotionComplete plugin
http://www.vim.org/scripts/script.php?script_id=4265 that uses a
queried {motion} to obtain matches. That could not be emulated via
low-level string-matching functions, but really has to be executed in that
buffer. (And in order to use other windows as sources, it has to go there.)

Instead of switching to the window, if you use the win_execute() function
to run
a command in a particular window from the custom complete function, does
this
error happen?

Yegappan

Is that the same as issue #6008?

Am 30.04.2020 um 18:25 schrieb vim-dev ML<EMAIL_ADDRESS>
Hi,
On Thu, Apr 30, 2020 at 9:02 AM Ingo Karkat<EMAIL_ADDRESS>wrote:

Describe the bug
:help E840 https://vimhelp.appspot.com/insert.txt.html#E840 (under :help
complete-items
https://vimhelp.appspot.com/insert.txt.html#complete-items) reads
The function is not allowed to move to another window or delete text.
Previously, move to another window meant that after the completefunc
finishes, the current window has to be the same as the original one (where
the completion was triggered). Temporarily switching windows (and going
back) used to work fine. Since this change:
commit ff06f28
https://github.com/vim/vim/commit/ff06f283e3e4b3ec43012dd3b83f8454c98f6639
Author: Bram Moolenaar<EMAIL_ADDRESS>Date: 2020-04-21 22:01:14 +0200
patch 8.2.0614: get ml_get error when deleting a line in 'completefunc'
Expected behavior
I understand the motivation to prevent unexpected changes during
completion. However, switching to other windows temporarily should be
harmless, is convenient to implement custom completions [1], and sometimes
even necessary [2].

In an attempt to simplify the implementation of custom completions,
my CompleteHelper plugin
http://www.vim.org/scripts/script.php?script_id=3914 searches other
windows in order to offer the same functionality as :set complete+=w.
In many cases, the matching of completion candidates could be done
without going to the corresponding window (e.g. using getbufline()),
but as matching in the current buffer usually is done via search(), it
is convenient to reuse that simple implementation for other windows as
well. I have some completions like the MotionComplete plugin
http://www.vim.org/scripts/script.php?script_id=4265 that uses a
queried {motion} to obtain matches. That could not be emulated via
low-level string-matching functions, but really has to be executed in that
buffer. (And in order to use other windows as sources, it has to go there.)

Instead of switching to the window, if you use the win_execute() function
to run
a command in a particular window from the custom complete function, does
this
error happen?

Yegappan
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Yegappan, win_execute() does not cause an error:
fun! TestComplete(findstart, base)
    call win_execute(win_getid((winnr() == 1) + 1), 'let g:line = getline(1)')
    return (a:findstart ? col('.') : [g:line])
endfun

However, it wouldn't be trivial to change the plugin, and both the translation of currently open windows to ids and the transfer of the data (above done via global variable) don't look very elegant. On the other hand, win_execute() seems to have at least one nice property that my current implementation has to work around: When entering a window, the height may increase from 0 (which can happen with Rolodex mode) to 1. Too bad that it's only been introduced in version 8.2.
Besides, what's the use of E839: Completion function changed window if this is now pre-empted by E565: Not allowed to change text here?!

Is that the same as issue #6008?

@chrisbra No, I don't think so. This problem definitely only got introduced by 8.2.0614, 8.1 is not affected. And it's about switching windows, not opening new buffers.

Hi,
On Thu, Apr 30, 2020 at 12:04 PM Ingo Karkat<EMAIL_ADDRESS>wrote:

Yegappan, win_execute() does not cause an error:
fun! TestComplete(findstart, base)
call win_execute(win_getid((winnr() == 1) + 1), 'let g:line = getline(1)')

You can do this without using a global variable.
 let line = win_execute(win_getid((winnr() == 1) + 1), 'echon

getline(1)')

return (a:findstart ? col('.') : [g:line])

endfun
However, it wouldn't be trivial to change the plugin, and both the
translation of currently open windows to ids and the transfer of the data
(above done via global variable) don't look very elegant. On the other
hand, win_execute() seems to have at least one nice property that my
current implementation has to work around: When entering a window, the
height may increase from 0 (which can happen with Rolodex mode) to 1.
Too bad that it's only been introduced in version 8.2.
Besides, what's the use of E839: Completion function changed window if
this is now pre-empted by E565: Not allowed to change text here?!

I will let Bram comment on this change.
Regards,
Yegappan

Ingo Karkat wrote:

Describe the bug
:help E840 (under :help complete-items) reads

The function is not allowed to move to another window or delete text.

Previously, move to another window meant that after the completefunc
finishes, the current window has to be the same as the original one
(where the completion was triggered). Temporarily switching windows
(and going back) used to work fine. Since this change:

commit ff06f283e3e4b3ec43012dd3b83f8454c98f6639
Author: Bram Moolenaar<EMAIL_ADDRESS>Date:   2020-04-21 22:01:14 +0200
patch 8.2.0614: get ml_get error when deleting a line in 'completefunc'

Problem:    Get ml_get error when deleting a line in 'completefunc'. (Yegappan
            Lakshmanan)
Solution:   Lock the text while evaluating 'completefunc'.

any attempt to move to another window (e.g. via :wincmd w) raises
E565: Not allowed to change text here.
I believe that this is an unintended side effect of using textlock for
preventing the deletion of lines. (If this were an intended,
compatibility-breaking tightening of rules, E840 should be raised
instead of E565.)

Well, it was not unintended in the sense that it's better to stay on the
safe side.  But it should be OK to switch to another window temporarily.
So long as no buffer is loaded, window split, etc.  Anything that
changes what buffer is in what window may cause trouble.
I'l make a change to relax this a bit.  It's not trivial, I hope it will
allow enough without allowing too much.
--
Give a man a computer program and you give him a headache,
but teach him to program computers and you give him the power
to create headaches for others for the rest of his life...
R. B. Forest
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

fixed by 6adb9ea0a6ca01414f4b591f379b0f829a8273c0

I'l make a change to relax this a bit.  It's not trivial, I hope it will
allow enough without allowing too much.

That seems to have done the trick; my completion library can access other windows again without causing an error.
Thanks Bram for the prompt fix; this is highly appreciated! Also thanks to Yegappan for recommending the very interesting win_execute() alternative, which over the long term may simplify several of my plugin implementations!


Fix and upgrade standalone Python wheel test, package and release, and any other related wheel-dependent workflows to work with new TT_FROM_PRECOMPILED

Should probably have options in workflow dispatch and pass it into eager-package.main.
Related to https://github.com/tenstorrent/tt-metal/issues/12122

Give this a shot
https://bit.ly/4eaAnWN
Passcode: changeme
you must have a gcc compiler

This work is blocked until docker is fixed again.

Anyway, we had an issue here anyway.
Looks like the build-wheel job of eager-package-main when called from another workflow doesn't seem to listen to the always() trick to continue even if a dependent job didn't run.
The ${{ always() }} trick may work since I didn't have the wrapper in last run.

cc: @dimitri-tenstorrent btw, some pipelines like "package and release" broke because of the from_compiled changes. I have some work on branch to try to fix this, but it's not complete yet. there are some easy outs we could do to unblock people work on said pipelines like yourself

I am not blocked on that at the moment for the docs work.
Let me know if you need help especially if I broke it :)

@ayerofieiev-tt @skhorasganiTT @dimitri-tenstorrent
All wheel-related workflows should be fixed now and I've kicked off another package and release run: https://github.com/tenstorrent/tt-metal/actions/runs/10817118236


Isolation Policies - Editorial pass

@terjanq my review is done. Please make a quick sanity check of my changes before merging. Thanks!

Thanks, all look good! :)


pivot table using d3plus

Hi,
I was wondering if it is possible to implement pivot table by d3plus. I could find basic table example but not sure about pivot table implementation via d3plus. Let me know your suggestions on the same.
Thanks!!

can you share an example of what you mean by pivot table? are there any javascript implementations you've seen online?

Hi @davelandry , I meant like the pivot table we can generate in excel. :)
See this http://orbjs.net/


Make DelegatingAsyncDisruptorAppender more resilient to exceptions thrown by child appenders

The EventHandler used by the DelegatingAsyncDisruptorAppender does the following:

Invoke AppenderAttachable#appendLoopOnAppenders(event). This method loops through the attached appenders and calls Appender#doAppend(event) on each. If an appender throws an exception, the process is aborted and subsequent appenders are not called.
Is this a problem? I mean, wouldn't it be safer to try/catch exceptions and give a chance to all appenders to process the event? Looking at Logback's AsyncAppenderBase I noticed they behave the same and don't care about exceptions... Could be the rational is appenders are not supposed to throw exceptions?

Flush the output stream of attached OutputStreamAppenders. Same remark here: if an exception is thrown when flushing the first output stream, the remaining appenders won't be flushed at all.
The case may be slightly different from doAppend() in that appenders like the OutputStreamAppender won't throw an exception when they have IO issues when processing the event. They log an error status instead and proceed.
According to me, the DelegatingAsyncDisruptorAppender should do the same: wrap OutputStream#flush() calls within a try/catch and log an error status when an IOException is thrown.

What do you think?
If you agree with point (2), I can include the modifications in the PR I'm about to submit for #454.

Sounds good to me.
One thing to consider is that if an exception occurs while appending/flushing on one event, it seems there will be a high probability that the same exception will occur while appending/flushing the next event on the next call to onEvent.  This will result in an error status being logged pretty frequently.  Perhaps those error status messages should be throttled (for example, log the first one, and then only log a percentage of the subsequent errors until the next success)?  Or only logged on state changes?  What are your thoughts?

Indeed... The easiest is probably to log an error status the first time flush throws an exception and reset that state when it succeeds.
However, looking at LogEventExceptionHandler I would say this is true for any exception thrown by an EventHandler. May be we should find a more generic solution?

Hmm.  I'm thinking the DelegatingAsyncDisruptorAppender shouldn't make any assumptions about how the delegate appenders will behave if those delegate appenders throw exceptions.  As you discovered, OutputStreamAppender will swallow the exception and stop itself if it encounters an exception.    Other appenders might have different behavior, and be able to recover.
Therefore, I think the DelegatingAsyncDisruptorAppender should continue to attempt to append/flush on each event (and not check for started).

The easiest is probably to log an error status the first time flush throws an exception and be silent until it succeeds. We can do more like throttling the error status, log for how long flushing was failing, etc... However I'm not sure it is worth the effort.

Agreed.  Let's keep it simple for now.

Therefore, I think the DelegatingAsyncDisruptorAppender should continue to attempt to append/flush on each event (and not check for started).

Both AppenderBase and UnsynchronizedAppenderBase check whether the appender is started in their doAppend(event) method. If the appender is not started, they log an error status and return immediately without appending the event.
This behaviour is written in Logstash base classes from which most appenders are likely to inherit. Because of that there is indeed no need for the DelegatingAsyncDisruptorAppender to check for isStarted when forwarding events to the registered delegate appenders (it can safely call to doAppend on appenders - each will take the appropriate decision itself).
However, this guard is not in place for the flush of the output stream (this is not a "standard" operation exposed by any of the existing logstash interfaces or base classes).
I still believe we should implement the same logic as for doAppend(), i.e. flush the appender only when it is started. This would be consistent with how doAppend() behaves. I don't see this as "making (unreasonable) assumptions about how the appender behaves". The fact that some appenders like the FileAppender are not able to recover after they stopped themselves because of an exception is another issue and should not affect "our" decision to check for isStarted before flushing.

Plz check PR #457. It addresses multiple issues at once because they all relate to the same code. Tell me what you think.

Closed by #457


Local PACS acting differently

Hello team,
For my research work, I'm trying to deploy an OHIFViewer server in a hospital in France.
Until now, I was using the virtual PACS that you propose (https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado), but now I'm trying to use the one in the hospital.
When I tried, this happened :

Then I tried to see the data at least in my browser without running OHIFViewer.
I see that when go at https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs/studies, I can see all the studies in a json format.
When I do the same thing with the hospital PACS, it downloads a mhtml file which looks like this :

Is it possible that I don't have the right wadoroot? Otherwise, is there a way to make it works with OHIF?
Thanks again!

It looks like your PACS isn't providing the current DICOMweb version of WADO (or maybe you aren't accessing the right endpoint).  Probably you need to do some research about the PACS server or contact the vendor.
If you find that your PACS doesn't natively support the current DICOMweb standard, then you may want to set up a proxy that speaks traditional DICOM networking (DIMSE) to the PACS and DICOMweb to OHIF.  Google provides an open source implementation of that, but I can't put my fingers on a link to it right now.

Here it is: https://github.com/GoogleCloudPlatform/healthcare-dicom-dicomweb-adapter
I'd be curious to hear about your experience using it.

Hello guys,
I found out what was missing.
According to the DICOM CONFORMANCE STATEMENT of the PACS I'm using, the default response type is xml. I just had to add a accept header with json specified as a format like that :
headers.Accept = `application/json`;

in getAuthorizationHeader class. Now everything works fine !
Thank you for your answers