[External tools] flutter analyze won't detect local libraries within my project

I created a regular Dart library next to a new Flutter app to try and import it into the app, but the analyzer was unable to detect it.
I'm developing on a Linux device, more details below.
Errors from running flutter analyze
  error • Target of URI doesn't exist: 'lib1/foo.dart' at lib/foo.dart:1:8 • uri_does_not_exist
  error • Classes can only extend other classes at lib/foo.dart:3:21 • extends_non_class
  error • Undefined class 'Foo' at lib/foo.dart:3:21 • undefined_class

Minimal sample case
➜  dart mkdir bad_case
➜  dart cd bad_case
➜  bad_case mkdir lib1
➜  bad_case vim lib1/pubspec.yaml
➜  bad_case mkdir lib1/lib
➜  bad_case vim lib1/lib/foo.dart
➜  bad_case flutter create flt_lib
Creating project flt_lib...
Wrote 54 files.

Running "flutter packages get" in flt_lib...          2.2s

[✓] Flutter is fully installed. (on Linux, locale en_US.UTF-8, channel master)
[✓] Android toolchain - develop for Android devices is fully installed. (Android SDK 25.0.2)
[✓] Android Studio is fully installed. (version 2.2)
[✓] Connected devices is fully installed.

All done! In order to run your application, type:

  $ cd flt_lib
  $ flutter run

Your main program file is lib/main.dart in the flt_lib directory.

➜  bad_case cd flt_lib
➜  flt_lib vim lib/foo.dart
➜  flt_lib flutter analyze
Running "flutter packages get" in flt_lib...          0.3s
Analyzing /home/david/Programacion/dart/bad_case/flt_lib...
  error • Target of URI doesn't exist: 'lib1/foo.dart' at lib/foo.dart:1:8 • uri_does_not_exist
  error • Classes can only extend other classes at lib/foo.dart:3:21 • extends_non_class
  error • Undefined class 'Foo' at lib/foo.dart:3:21 • undefined_class
3 issues found.
(Ran in 5.1s)
➜  flt_lib

lib1/pubspec.yaml
name: lib1

lib1/lib/foo.dart
abstract class Foo {
  String bar();
}

flt_lib/pubspec.yaml
dependencies:
  lib1:
    path: ../lib1
  flutter:
    sdk: flutter

flt_lib/foo.dart
import 'lib1/foo.dart';

class MyFoo extends Foo {}

Additional information: this is not blocking anything in customer: leafy, just a regular bug report.

This appears to be fixed in the latest version of Flutter.


Move presubmit to Jenkins

https://github.com/istio/auth/issues/76

Jenkins job auth/presubmit passed

Jenkins job auth/presubmit passed


Apache License 2.0, also exclude Bintray repos out of POM

Fixes #666
Fixes #119

To validate this pull request against other sbt modules, please visit this link.


Darstellen von Images im Chat

As a chatting user who likes to share and receive images in telegram I want to be able to see the images I send and receive.

#362


older (es5) browsers not fully supported when using workspace scripts

🐞 Bug report
Command
- [ ] new
- [x] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Is this a regression?
Yes, the previous version I'm aware this was still working was 8.0.
Description
Since I upgraded the cli to 8.3.3 my applications do not provide support for older browsers such as IE11.
🔬 Minimal Reproduction

Create a new project.

npx -p<EMAIL_ADDRESS>ng new es5-support

Change the browsers list file to consider IE 9-11 (remove not as suggested in the comments):

> 0.5%
last 2 versions
Firefox ESR
not dead
IE 9-11

Create a custom script that uses, for example, Promises:

const myPromise = new Promise(function(resolve) {
  setTimeout(function(){
    resolve('Promise resolved');
  }, 500);
});

myPromise.then(console.log);

Add this script to the build target (angular.json):

...
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist/es5-support",
            "index": "src/index.html",
            "main": "src/main.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "tsconfig.app.json",
            "aot": false,
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ],
            "styles": [
              "src/styles.css"
            ],
            "scripts": [
              "my-script.js"
            ]
          },
...

Build the application:

ng build --prod

Deploy and run the application on IE11.

Here is a repo that reproduces the error: https://github.com/cladera/ng-cli-es5-support
🔥 Exception or Error

SCRIPT5009: 'Promise' is undefined
File: scripts.31a5e5bdf3ecf1f1be1c.js, Line: 1, Column: 1

🌍 Your Environment

Angular CLI: 8.3.4
Node: 12.3.1
OS: darwin x64
Angular: 8.2.6
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.803.4
@angular-devkit/build-angular     0.803.4
@angular-devkit/build-optimizer   0.803.4
@angular-devkit/build-webpack     0.803.4
@angular-devkit/core              8.3.4
@angular-devkit/schematics        8.3.4
@angular/cli                      8.3.4
@ngtools/webpack                  8.3.4
@schematics/angular               8.3.4
@schematics/update                0.803.4
rxjs                              6.4.0
typescript                        3.5.3
webpack                           4.39.2

Anything else relevant?
If I run the build with the environment flag NG_BUILD_DIFFERENTIAL_FULL set to 1 it runs a build that does work on IE 11.
Anyway, one may wonder why do I need to add a script to my application that may break it whatsoever. Well, in an ideal world, all the libraries I need would be full UMD/cmjs compatible and I may just import them as a normal vendor dependency. But sadly, that's not my case. I need to add some scripts as "global" because I'm forced to do it. My point is, this worked fine few minor versions ago and now it doesn't which in my opinion is a breaking change.

Within the index.html, can you try moving <script src="runtime-es5.js" nomodule defer></script> to the top of the list of scripts?

@clydin I assumed you meant the index.html generated by the build command.
I moved the runtime script line to the top and, yes the app now works on IE11.

Yes.  Thank you.  A permanent fix will be forthcoming.


extending types across files panics

i.e. 3 files, the first includes the 2nd and 3rd, the 3rd includes the 2nd, and the 3rd also defines a type that extends a type in the 2nd file. The parser fails with a nil pointer panic

Fixed in 9b1e198fda74e2b26ab2b32a5aac214abb425010


Moves ranker waiting to be implemented

I think this is a great start and the ranker code is clear to me how It might be expanded on. The winning state and match board function are less clear to me how I might use them.

Thanks for feedback, we'll definitely talk more about winning state and board match, and modules, today in discussion.


AML - MLFlow - Batch Endpoint Deployment - Invalid Endpoint Invocation Command

Issue
On step:
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-mlflow-batch?view=azureml-api-2&tabs=cli#testing-out-the-deployment
It instructs the user to invoke the endpoint they setup
JOB_NAME = $(az ml batch-endpoint invoke --name $ENDPOINT_NAME --input azureml:heart-dataset-unlabeled@latest --query name -o tsv)

Error Dataset Version
ERROR: Met error <class 'Exception'>:

1) At least one required parameter is missing

Details:

(x) Must provide either version or label.
...

Solution: Change dataset --input

Label
Value

Incorrect
azureml:heart-dataset-unlabeled@latest

Correct
azureml:heart-dataset-unlabeled:1

It seems @latest may not be supported anymore. Attempting to use azureml:heart-dataset-unlabeled:1@latest results in
ERROR: (UserError) dataVersion is invalid. It can only contain alphanumeric characters, dashes, underscores, and periods, with a limit of 50 characters.
Code: UserError

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

ID: 0bfb4ffc-a983-cc14-e7d1-c9d7ce803aff
Version Independent ID: ff2fb5b1-8048-2fc5-a334-aeafb60d0b5e
Content: Deploy MLflow models in batch deployments - Azure Machine Learning
Content Source: articles/machine-learning/how-to-mlflow-batch.md
Service: machine-learning
Sub-service: core
GitHub Login: @santiagxf
Microsoft Alias: fasantia

Thanks for reporting this issue. We have assigned a work item to investigate and we will update shortly! 👯

@mattmazzola
Thanks for your feedback! We will investigate and update as appropriate.

@santiagxf Thanks for your quick response.
Hi @mattmazzola Thanks for reporting this, our internal team is working on the same and now we are going to closing this thread but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Is RefreshingManagedChannel being used, or just an experiment?

I happened on RefreshingManagedChannel added in #805, and it concerned me because re-creating the channel is heavy-weight and this may prevent future work. I'm most concerned that to my knowledge grpc team wasn't notified, since this can bite us.
Is this being used by someone, or just an experiment?

Looks like it is, see #804. Please reach out to the original reporters / authors if further discussion is needed.

@miraleung, did you paste the wrong issue/PR? I saw the issue posted and saw the PR #805. But that just exposes an API. It is enabled if you provide a ChannelPrimer, which is @InternalApi("For internal use by google-cloud-java clients only"). The question is if there is a user of it.
Based on a search of GitHub, it appears it is only used by CBT, but since the implementation is using the grpc-experimental API it requires explicit opt-in via a BetaApi.


Configuration set pattern drops all intellisense

Is there anyway to get intellisense when using a configuration set pattern?
I followed this guide but their solution has no intellisense.
I tried many methods, like
var environmentVariabless = environment == 'prd' ? environmentConfigurationMap.Production : environmentConfigurationMap.NonProduction

But I am losing all intellisense.
I would like to just pass in the environment, and have bicep determine the settings.
The only other method I have is to have two parameter files and having CICD pick which file to use in the deploy command.
I don't know what is best practice, but with the configuration set pattern, I can loadTextContent on one file and separate it by environment.
It would also be cool if  loadTextContent didn't need a compile time constant.

related to #4111


SLES 12 packages are compiled with glibc2.26 requirement, while SLES 12 ships with 2.22

Looks like the below packages are compiled on a system with glibc 2.26, but SLES 12 SP5 ships with 2.22.   Doesn't look like SLES gets 2.25 until SLES 15.
https://packages.microsoft.com/sles/12/prod/sysinternalsebpf-1.0.0-1.x86_64.rpm
https://packages.microsoft.com/sles/12/prod/sysmonforlinux-1.0.0-1.x86_64.rpm
Any chance of release a glibc2.22 compatible version?

Compatibility is on the list. Stay tuned. :)


test: change test name and api name

1.Describe what this PR did
Change file name: pouch_api_* to api_*
Change struct name: PouchAPI* to API*
2.Does this pull request fix one issue?

3.Describe how you did it
4.Describe how to verify it
5.Special notes for reviews

LGTM
Much better now, and less redundant display.


Workflow V2.

[ ] Sprinter identifier needs both evaluation identifier and timestamp.
[ ] Workflow needs both evaluation identifier and timestamp.
[ ] Add labels to the kubernetes deployment.
[ ] Restrict deployment based on labels.
[ ] Only shutdown the right experiments.
[ ] Start multiple redis.
[ ] Ensure that the redis sync code pulls the right redis instance.


Fix vcf export bug.  We didn't write the description field in the hea…

…der for expr-generated va.info fields, which is a violation of the VCF 4.2 spec.
Resolved #471

jenkins


[BUG] Required Authorization/Connection Type to utilize this function

Reposting in "correct" repository from original: https://github.com/MicrosoftDocs/office-docs-powershell/issues/7740
When I try to access the Add-PnPTeamsTeam function through an Azure Function using:
Connect-PnPOnline -Tenant [tenant].onmicrosoft.com -ClientId [appid] -Thumbprint [thumbprint] -Url https://[tenant].sharepoint.com
I get the following error:

I am wondering if the Doc needs updating to specify which connection methods are permitted, or if the function needs to be updated to allow for "Application" API permissions to execute it.
Any Help appreciated, Thanks!

Does it work without the Azure Function?

Does it work without the Azure Function?
I can't remember, I will try again on Monday.

Yeah, certificate auth is not supported for that cmdlet.
@veronicageek / @jarvann - should we update docs for this ? or also update the cmdlet as well to warn users ?

should we update docs for this ? or also update the cmdlet as well to warn users ?

I think both is the right answer. If you have a known "negative" path, it should be checked (if possible) and reported prior to throwing an exception. In addition, the documentation would help, especially if it can explain the "why" for not using certificate AuthN.
Personally, I feel that utilizing Azure Function with "App Registration"/Service credentials is a valid use case. So I would be curious at which point in the call chain would require an update to make that happen? Is it an API permission problem on the AAD side, an issue in the MS Teams cmdlets/API, or is it the PnP Scripts that are preventing this from working?
For now, I am satisfied if the documentation and scripts could be aligned with the existing capabilities.

@jarvann - we fixed this issue couple of days back.
Can you please try with the latest nightly builds ?
Please reopen this if it still happens.
Thanks for reporting !


Error given if location rule of -1 (delivery not offered)z

Expected behavior:
I should be able to add the item on the cart even if it does not reach the minimum delivery value yet (otherwise I am not able to create my cart)
Actual behavior:
I get an error when I try to add an item to the cart, if the minimum delivery charge is not set and delivery is NOT offered for other values
Reproduce steps:

set a location with rule a charge 0 above 15£
set a location rule with a charge of -1 below 15£
Go on the website and try to add something to the site (an item that is less than 15 $)
You will get an error showing that the restaurant does not deliver to the place.

Version:
3.0.4-beta-27
Additional Information:
I have been able to find a workaround, by setting a delivery charge of 5£ for value below the FREE delivery. It seems like that the issue is the use of -1.
video: https://www.loom.com/share/21bc2453d6ca42fb921ab35c4a25cbbe

Hmm - maybe been caused by these changes @sampoyigi ?
https://github.com/tastyigniter/ti-ext-local/pull/38

Seems to be related to this instead to tastyigniter/ti-ext-cart#46. I think we shouldn't do the delivery charge check when adding or updating the cart, it should be done on page load to disable the checkout button and redirect on the checkout page.
Or we could allow add/update cart and somehow display a warning to the customer to add more item to enable checkout...

Actually, we already have a warning message on the Delivery cart condition so I'll revert the commit to fix this.


tasks/c/easy/sum.c

Description

Added the code file for sum of two numbers in C
Additional Context

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!

Code looks good!

Thank you


python311Packages.google-cloud-os-config: 1.18.1 -> 1.19.0

Changelog: https://github.com/googleapis/google-cloud-python/blob/google-cloud-os-config-v1.19.0/packages/google-cloud-os-config/CHANGELOG.md

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 365850

x86_64-linux

:white_check_mark: 8 packages built:

python311Packages.google-cloud-asset
python311Packages.google-cloud-asset.dist
python311Packages.google-cloud-os-config
python311Packages.google-cloud-os-config.dist
python312Packages.google-cloud-asset
python312Packages.google-cloud-asset.dist
python312Packages.google-cloud-os-config
python312Packages.google-cloud-os-config.dist


Improving near interactions

Related to #10471

Makes near interaction more precise and efficient (specifically by adding a sphere-to-mesh intersection test)
Implements near touch, to trigger button without pinching the fingers
Can specify a controllerId to exclude from near interactions (for hand menu to avoid near interaction with the hand that carries the menu)
Enables 2 pointers near interaction with SixDofDragBehavior
Adds a visual cue for near interaction picks

Closes #10471

Is this ready to merge in?

looking at the comments and such I think so, hence the merge, I ll do a nightly in a bit


OData version 3.0 onward not supported

I have a API I am trying to connect to that uses OData version 3.0, and the F# type provider doesn't seem to work with it. Since OData is now to version 4, it seems like some updating should be done.
open FSharp.Data.TypeProviders
FSharp.Data.TypeProviders.ODataService<[URL FOR ODATA 3.0]>

It seems to be discussed on this stack overflow page
http://stackoverflow.com/questions/20906533/webapi2-odata-f-type-provider

ping, any plans on updating OData type provider to version 4?

@theimowski People seem to be moving rapidly to the Swagger type provider.  Is that an alternative for you? https://github.com/fsprojects/SwaggerProvider
See also https://github.com/caindy/ODataTypeProvider

OData is still the only api that some Microsoft products expose. AFAIK swagger is not really helping here.

OData is still the only api that some Microsoft products expose. AFAIK swagger is not really helping here.

I would be very happy to see an updated OData provider.  I think it should be rewritten from scratch though, as an erasing type provider.

My use case is for internal project - would like to property-based test OData api (which is implemented on top of Web Api). Don't know too much about those 2 web tech, but from initial research it looks like it should be possible to add a Swagger definition using Swashbuckle for a Web Api project.
However not yet sure how it could deal with the OData protocol.

I spent a bit of type looking at this when working on the pivot type provider in The Gamma. It turns out that the OData v4 spec has OData extensions for data aggregation, which looks very close to the kinds of thing you can write using the pivot type provider - the only reason why I did not use OData in the end was that it looks quite complicated (probably for good reasons) and I couldn't find many services that actually expose data via this format. (Aside from some MS and SAP products...)

Swagger is great for API documentation but it is completely and totally useless at letting the user build up their own queries against the properties in the response document as well as filtering out or selectively filtering the fields in the response that they want.  That's where OData tends to shine...

Note this is a very old collection of type providers that are Windows-specific and .NET Framework-specific. For up-to-date type providers see https://fsharp.org/guides/data-access/


propagate dispatch + action to the interceptors

this change allows using this middleware for auth popup with a retry queue for unauthorized requests (among other things)

closing this to open another squashed one that fixes lint error


Eval of any .clj file fails

Evaling clojure files fails somewhat silently.
Minimal steps to reproduce:

echo "1" > foo.clj
open foo.clj in Light Table
With the cursor over 1, Cmd + Shift + Enter.

Result: nothing happens (the 1 doesn't eval to 1, as it should). A stack trace in the lower right documents a failure of some kind.
If I try function calls like (+ 1 2) I get an inline "clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: + in this context" but I'm fairly sure it's just due to the same failing setup.
I'm on OS X 10.8.
Stack trace:
bootstrap.js[16107]:
nil
TypeError: Cannot read property 'addEventListener' of undefined
at Function.on (core/node_modules/codemirror/codemirror.js:5241:16)
at Function. (app://lighttable/core/node_modules/lighttable/bootstrap.js:25714:14)
at c (app://lighttable/core/node_modules/lighttable/bootstrap.js:6043:14)
at a (app://lighttable/core/node_modules/lighttable/bootstrap.js:6072:18)
at a (app://lighttable/core/node_modules/lighttable/bootstrap.js:19291:142)
at b (app://lighttable/core/node_modules/lighttable/bootstrap.js:19303:14)
at Function. (app://lighttable/core/node_modules/lighttable/bootstrap.js:25725:24)
at c (app://lighttable/core/node_modules/lighttable/bootstrap.js:6043:14)
at a (app://lighttable/core/node_modules/lighttable/bootstrap.js:6072:18)
at lt.object.raise_STAR_ (app://lighttable/core/node_modules/lighttable/bootstrap.js:19170:502)

uh, hmm, I only just downloaded LT 0.7.2 to this macbook os x 10.9, and i wrote test.clj that has only the number 2 in it, and evaluating it causes things to blow up just like this issue reports. Adding "(ns my-namespace)" in doesn't seem to help, LT seems to be fubar now and just keeps writing such errors into the console.

@raould I can reproduce this, but I'm not sure that this isn't a 'by-design bug'. Clojure isn't typically evaluated as naked expressions in text files, even if they have a .clj extension. Most (?) Clojure code is part of a Leiningen project and every code file defines a namespace in the project. Otherwise, code is evaluated 'live' in a REPL.
Interestingly, the expression 2 isn't visually evaluated in a Clojure "InstaREPL" tab in Light Table, but then again 2 evaluates to itself anyways so this isn't a significant missing feature. And (+ 1 2) evaluated fine, even after I tried reproduced this issue. I can also evaluate that same expression in the test.clj file I created after I run the "Instarepl: Make current editor an instarepl" command.
Are you having problems evaluating expressions that don't evaluate to themselves (i.e. "strings, numbers, characters, true, false, nil and keywords")?

Thanks! I can grok that there are things even Clojure wouldn't like :-), so neither should LT. But I guess I'd want it to just report the Clojure error, and not additionally add in whatever confusing extra layers of errors it does with all the "TypeError: Cannot read property 'addEventListener' of undefined" stuff? Since that makes it look like LT is just borked making it harder for users to figure out where to go from there.


DateFormatter: disable testing of medium date style

Currently, some of the DateFormatter tests fail on High Sierra because the format of the .medium date style has changed.  This is likely due to changes in the underlying platform ICU.
@parkera expressed the opinion to me that we shouldn't be testing the appearance of the DateFormatter presets because they are subject to change and not precisely documented.
I don't entirely agree with that point of view as if the format does change on Darwin platforms then we want to reflect those changes in SCLF, and having our tests start failing is the best way to detect that.
However, there is a whole separate discussion about whether Swift on Linux should use the platform ICU at all, or whether we should ship Apple's fork of ICU (which is used on Darwin) with Swift on Linux to sidestep all these problems.
As fixing the behaviour of SCLF on Linux in this regard is not practical in the short term (we don't want to diverge our CF code further from Darwin's), this PR just disables the currently failing tests.  We could go further and remove/disable all the date style tests but I leave that argumentdiscussion for another day.

@swift-ci please test

If the tests fail only on Darwin, can we have an if os that allows us to conditionally execute these changes solely for the Linux platform, but not have them cause additional noise when they run on Darwin?

I'm not sure what the purpose would be of running them on Linux. In an ideal world they would be failing there too, but they don't because of the ICU differences I mentioned.

Regarding noticing if they are different on different platforms: I agree that is interesting, but perhaps we should also consider that they're even different between different versions of iOS or macOS. So it's not necessarily the end of the world if they are not exactly the same.
That said - I would like consistent behavior. But, the noise caused by failing tests when attempting to get real stuff done (bigger upgrades) is costly.

Thanks @parkera - I'll merge this as a step along the road...
@swift-ci please test and merge


HTML module removes domain from URL's on save

Description of bug
After saving, the HTML module will remove the https://www.yourdomain.com from the URL. The issue is particularly bad when you have URL's with domains different from the domain from your DNN installation.
Steps to reproduce
List the precise steps to reproduce the bug:

Go to 'Edit HTML module content'
Select from the drag and drop 'Basic Text Box'
Select from the Render Mode either 'text or HTML'
NOTE - When you select the Render mode "Raw" the domain will not be removed from the URL's
Save the edits and the module will remove the domain from the URL's leaving only the relative path.

Current behavior
After saving, the HTML module removes the domain from the URL's leaving only the relative path and breaks the link to URL's that have domains different from the one in the installation.
Expected behavior
HTML module shouldn't change or remove the domain from the URL's after saving.
Additional context
In the Basic Text Box mode when you select the Render mode Raw the domain will not be removed from the URL's and the issue will not happen.
Affected version

[ ] 10.00.00 alpha build
[x] 09.06.02 release candidate
[x] 09.06.01 latest supported release

Affected browser

[x] Chrome
[x] Firefox
[x] Safari
[x] Internet Explorer 11
[x] Microsoft Edge (Classic)
[x] Microsoft Edge Chromium

Can you confirm some details regarding the installation this was observed in.

What version of DNN was it using
Was it a clean installation?  If not, what version was it upgraded from
Did you customize the configuration of the Html Editor

There is an option that can allow the editor to behave in this manner, but it is not the default.

v. 09.03.02 (24)
It's not a clean installation and no changes were done to the HTML Editor.
It started doing this out of the blue!


Update sign_juno.sh

I updated the names of the zipped folders to make them clearer, so I think the signing script needs this change to keep working.

If this is what you're referring to, I don't see how this could possibly be the cause of the problem. They were freezing during the upload step, not the signing step.

You should really be using something with a better compression ratio than zip here. It's pretty easy to make a self-extracting 7z archive. An NSIS installer would probably be even better, and could also be 7z-compressed.


Multiple Hash Reindex when multiple delta exist?

Hi, there:
First, thanks for this great product! We are building an advanced version of trello, have very flexible filtering capabilities using Hollow. Now we have a customer who has 1000 people using this tool to manage their daily developement work.
However, we are faceing some slow HashIndex reindexing issue in the morning time, when every one is using this tool.
We have a card server that is producing hollow delta every seconds, and a view server get delta update via nfs and reindex Hash Index every second. we have 30 Hash Index under card consumer, Under the heavy load, we found that Hash Index reindexing may take several minutes even after we can see the data updated through explorer, but the new data won't be available after the reindexing finished.
It seems that Hash Key Reindex is triggered after every delta update.

We want to know whether this is done intentionally? We found that if we set the producer to produce snapshot for every delta, instead of 1 snapshot for 10 delta, this will reduce the reindexing time.
We also found that although we have 8c on our server, but even under heavy reindexing situations, only 4c is used, can we make the reindexing parallel to leverage the CPU power?
Regards!
Adam

We have a card server that is producing hollow delta every seconds, and a view server get delta update via nfs and reindex Hash Index every second.

Cool!
One update per second goes beyond our original intended usage, so I wouldn't be surprised if you're bumping up against some limitations in Hollow's design.
We built for use-cases with updates on the order of minutes. We do have teams within Netflix using it for updates every 30 seconds (and demand for supporting more frequent).

It seems that Hash Key Reindex is triggered after every delta update.
...
We want to know whether this is done intentionally?

Sort of.
When a consumer updates to a newer version it will do one of these:

apply 1 snapshot and 0 or more deltas
apply 1 or more deltas

WRT indexes, the original intent was to full re-index on snapshot and incremental update on delta.
HollowPrimaryKeyIndex has incremental update implemented. In 2019 we made it configurable (defaulting to false) due to an issue with occasional lockups that we suspect, but never proved, are in the incremental index update code. In effect, HollowPrimaryKeyIndex always does a full re-index unless you re-enable the incremental update.
HollowHashIndex never had incremental update implemented.
So...given that both indices will always do a full re-index, it would be optimal (for a given consumer refresh) to wait until all updates are applied and re-index at the end. The current HollowTypeStateListener doesn't allow this.
One way you can work around this:

don't subscribe the indexes for updates directly. If using HollowHashIndex don't call listenForDeltaUpdates(); if using HashIndex or HashIndexSelect don't call consumer.addListener(index).
implement your own HollowConsumer.RefreshListener. In the refreshSuccessful() callback create new hash index instances


HDDS-8854. Avoid unnecessary DatanodeDetails creation for NodeStateManager lookup

What changes were proposed in this pull request?
Add getNode(UUID) in NodeStateManager so that callers with only UUID can avoid creation of temporary DatanodeDetails.
Change dnsToUuidMap in SCMNodeManager to store UUID instead of String.
https://issues.apache.org/jira/browse/HDDS-8854
How was this patch tested?
CI:
https://github.com/adoroszlai/hadoop-ozone/actions/runs/5298453058

Thanks @siddhantsangwan for the review.


v0.3.0 Add "Mined By"

Fixed in: https://github.com/bitpay/insight-api/commit/4a850e2758ee8348cc424b20b026dd08a2c7d142


fortls is bit slow to start

Hi,
I am using fortls in vim8, as supported by coc.nvim.
My minimal vimrc is:
"General "{{{
set nocompatible                     "  because vim is not vi
set spell spl=en_us                  "  Set Spell
syntax enable
set tabstop=2                        "  Tabs width
set shiftwidth=2                     "  Default shift width for indents
set softtabstop=2
set expandtab                        "  but tabs are actually space
set backspace=eol,start,indent       "  Configure backspace so it acts as it should act
set encoding=utf8
set nu                               "  show line numbers
set noshowmode
"}}}

" VimPlug {{{
if empty(glob('~/.vim/autoload/plug.vim'))
  silent !curl -fLo ~/.vim/autoload/plug.vim --create-dirs
        \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
  autocmd VimEnter * PlugInstall --sync | source $MYVIMRC
endif
call plug#begin('~/.vim/plugged')
 Plug 'neoclide/coc.nvim'  , {'do': './install.sh nightly'}
call plug#end()
filetype plugin indent on
"}}}

"LANGUAGE SPECIFIC STAFFS{{{
  "Fortran {{{
    augroup FT_Fortran
      au!
      let fortran_do_enddo = 1
      let fortran_more_precise = 1
      let fortran_free_source = 1
      let fortran_have_tabs = 1
    augroup END
  "}}}
"}}}

" LANGUAGE SERVER{{{
let g:coc_start_at_startup = 0
augroup coc
  autocmd!
  autocmd VimEnter * :silent CocStart
augroup end
let g:coc_user_config = {
      \   'languageserver': {
      \     'fortran': {
      \       'command': 'fortls',
      \       'args': ['--lowercase_intrinsics'],
      \       'filetypes': ['fortran'],
      \       'rootPatterns': ['.fortls', '.git/'],
      \     }
      \   }
      \ }
" }}}

The problem is, it is taking some time to start completion, say, 30-40sec after opening a file.
Is it know or there is some problem in my configuration? Kindly let me know.

Thanks for the report.
First, can you do a debug run from the command line using the same project to isolate if this is an error with the vim setup or the language server? Likely, this is a language server issue and not Vim related.
If the debug initialization is slow as well, can you give me a little more info on the codebase? Is this a large project and is it open source so that I can test out/debug the issue?

I just fixed an issue that may be related. Can you see if release v1.9.1 improves things?

Unfortunately no! As described in that issue, I am also having this problem in new files only. If I reopen an existing file, there is no issue.

Ok, have you been able to try running debug initialization to see if server startup is slow outside of Vim?

you mean fortls --debug_rootpath=.? This I have run, and I haven't found anything unusual.
I am just trying a new hello world inside various directory. Obviously, the above command is taking more time to complete if I am working in $HOME, and very fast when inside an almost empty folder.

Run that command but with 'debug_rootpath' set to the directory where the file you are opening in Vim is located. The point is to see if the initialization of the server is slow on its own or only when used with Vim. If running 'fortls' alone completes fast, but Vim is still slow using the same directory this indicates an issue with how Vim interacts with the server not the server itself.

@hansec: sorry for the late reply. fortls --debug_rootpath=. i.e. I am running the debug in my current directory, where I am opening the file. vim is taking much more time to start completion than the command to complete.

Ok, then that is something related to how Vim is starting the server or perhaps how it is setting up its own completion internally. Do you see this behavior with any other language servers in Vim?

No. I use python and LaTeX, and both of them are very fast.

Also, as I said before, when I reopen an existing file, it's very fast. The problem only comes when I create a new file. any clue?

This definitely appears to be an internal issue with your Vim plugin/configuration not the language server. As I don't use Vim personally I can't really help you out there. I know people have had success with https://github.com/autozimu/LanguageClient-neovim, but other than that I am not sure. Sorry about that.

You have to save the file before open it, some language server have this kind of issue
because vscode always create file before open

Does this fix the issue for you? If so, can you retrieve the log of language server messages? As long as the order of requests coc.nvim emits is consistent I should be able to fix this on the language server end so you don't need to do anything "special".

@hansec: yes, as I said, if I open, write something, write-quit and reopen it, everything is fine.
when new file opened, and something is written to it:
forls_debug.log
CocInfo:
vim version: VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun 28 2019 09:32:51)
node version: v10.16.0
coc.nvim version: 0.0.72-2454a4d1e0
term: dumb
platform: linux

## Messages
Messages maintainer: Mike Williams<EMAIL_ADDRESS>[coc.nvim] Change request failed for unknown file "/home/rudra/Projects/i.f90"
[coc.nvim] Change request failed for unknown file "/home/rudra/Projects/i.f90"
The only match
The only match
The only match
The only match
[coc.nvim] Change request failed for unknown file "/home/rudra/Projects/i.f90"
[coc.nvim] Change request failed for unknown file "/home/rudra/Projects/i.f90"
[coc.nvim] Change request failed for unknown file "/home/rudra/Projects/i.f90"
[coc.nvim] Change request failed for unknown file "/home/rudra/Projects/i.f90"
[coc.nvim] Change request failed for unknown file "/home/rudra/Projects/i.f90"
"i.f90" [New] 9L, 173C [w]
## Output channel: languageserver.fortran

Change request failed for unknown file "/home/rudra/Projects/i.f90"
Change request failed for unknown file "/home/rudra/Projects/i.f90"
Change request failed for unknown file "/home/rudra/Projects/i.f90"
Change request failed for unknown file "/home/rudra/Projects/i.f90"
Change request failed for unknown file "/home/rudra/Projects/i.f90"
Change request failed for unknown file "/home/rudra/Projects/i.f90"
Change request failed for unknown file "/home/rudra/Projects/i.f90"

After write-quit and reopen the same file: (I tried completion of use)
fortls_debug.log
(NB: I have deleted the fortls_debug.log generated on the previous step)
## versions

vim version: VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun 28 2019 09:32:51)
node version: v10.16.0
coc.nvim version: 0.0.72-2454a4d1e0
term: dumb
platform: linux

## Messages
Messages maintainer: Mike Williams<EMAIL_ADDRESS>"i.f90" 10L, 179C
[coc.nvim] FORTLS debugging enabled
match 1 of 2
match 1 of 2
match 1 of 5
match 1 of 5
match 1 of 4
match 1 of 4
match 1 of 2
match 1 of 2
match 1 of 2
match 2 of 2
Unclassifiable statement at (1)
Unclassifiable statement at (1)
"i.f90" 10L, 195C [w]

Or do you mean something else by

Does this fix the issue for you? If so, can you retrieve the log of language server messages? As long as the order of requests coc.nvim emits is consistent I should be able to fix this on the language server end so you don't need to do anything "special".

@hansec L Thanks a lot for your time and help.

Ok, I just pushed a possible fix to the allow_create_on_change branch (see commit above). Can you check it out and see if it fixes the issue? Thanks!

Actually, the allow_empty_open branch is a better fix for this issue. Can you test it when you get a chance and let me know if it fixes this issue? Thanks!

@hansec : I have updated as:
sudo pip3 install git+https://github.com/hansec/fortran-language-server@allow_empty_open --upgrade
There is no change in behaviour, except CocInfo is writing the same line many times more, and this is
fortls_debug.log

Ooops, sorry about that there was a typo that I just fixed. That'll teach me to get lazy on the test cases. Can you update the allow_empty_open  and try it again?

wow! thanks a lot! Now it is working awesome.

Great, it is in v1.10 now so it will be included in the next release. You should automatically get a notification when the issue is closed by that merge.


Fix JSONP main template to allow currently forbidden chunk IDs (#9491)

What kind of change does this PR introduce?
This PR fixes #9491 by allowing to use entrypoint names like constructor with runtimeChunk: 'single'/namedChunks: true.
Doing that currently resulted in the following error at runtime (see the issue for more details):
runtime.js:26 Uncaught TypeError: resolves.shift(...) is not a function
    at Array.webpackJsonpCallback [as push] (runtime.js:26)
    at constructor.js:1

Did you add tests for your changes?
Yes
Does this PR introduce a breaking change?
That shouldn't be the case
What needs to be documented once your changes are merged?
N/A

Thanks


point prompt performance vs original SAM

I'm running the tutorial_point_prompt_seg.ipynb notebook and experimenting with different slices, but the results are worse than the original SAM. I would appreciate any insights into this issue.
MedSAM
Slice 85
https://github.com/bowang-lab/MedSAM/assets/7490180/92096589-0dec-405b-9e0a-c05dd5482108
Original SAM (Meta)
https://github.com/bowang-lab/MedSAM/assets/7490180/59817253-051d-4828-a767-b104504ab9d3

hello,
Could you please confirm if you found the notebook in the SAM/MEDSAM repository, or if you're working on it separately? I'm currently focusing on refining the point prompt using the MEDSAM model.

Yeah I used the notebook in the repo, and only changed the slice number from the middle slice to another slice

Hi @sedghi ,
This is expected since the point prompt is still an experimental function and the model was trained on a small abdomen CT organ segmentation dataset. In fact, this is still an open research question. The goal of sharing the training script is to prompt the development in this direction.

It's good to know. I assumed that since vanilla SAM works fine on the CT, MEDSAM would be even better

@sedghi, I couldn't locate the tutorial_point_prompt_seg.ipynb notebook. Could you please share it with me?

it is here https://github.com/bowang-lab/MedSAM/tree/main/extensions/point_prompt

Thank you @sedghi


Mapping in Simapro-9-ecoinvent-3.8-manual-matches possibly not correct

I might have spotted an issue for the mapping of biosphere flows between Simapro and BW for ecoinvent3.8 with the new randonneur_data+ SimaProBlockCSVImporter functionality. Let me explain below, but I am also happy to follow up with the original database and notebooks by mail, if that is helpful/
I tried to isolate the problem and I think it stems from the Simapro-9-ecoinvent-3.8-manual-matches.json and a too strict/early mapping there.
While I get unlinked exchanges for multiple environmental flows (see list below), I want exemplify it for "Arsenic".
Ecoinvent-3.8-biosphere has the biosphere flows "Arsenic", and "Arsenic, ion" for multiple compartments, see:

For the "air"-compartments, there is only "Arsenic".
Before applying randonneur, my processes contain "Arsenic" to air from Simapro (with the air-compartment connotation from Simapro)

After mapping with randonneur, these Arsenic flows are all turned into "Arsenic, ion", because of the mapping in Simapro-9-ecoinvent-3.8-manual-matches.json l1.782:

Their compartment connotation is also changed to fit with the Ecoinvent way.

However, "Arsenic, ion" does not have an "air" compartment in Ecoinvent-3.8-biosphere (see first screenshot), so this biosphere flow remains unlinked.
What I think would be correct, is to not map "Arsenic", and "Arsenic, ion" in Simapro-9-ecoinvent-3.8, as "Arsenic" still exists in the ecoinvent-3.8-biosphere. It diasappears only in ecoinvent-3.9-biosphere and the mapping between ecoinvent-3.8-biosphere and ecoinvent-3.9-biosphere already contains a mapping from Arsenic to Arsenic, ion.
I haven't checked for all of the unlinked bioflows in my system, but only for a subset, for which the same pattern as above occurs. Overall I have the following unlinked biosphere exchanges, but I could imagine that although the database I am trying to import is quite large, there might be other flows with a similar problem that are not in my system.
{'Aluminium, in ground',
'Arsenic, ion',
'Bromine, 0.23% in water',
'Cadmium, 0.30% in sulfide, Cd 0.18%, Pb, Zn, Ag, In, in ground',
'Calcium, ion',
'Chromium, 25.5% in chromite, 11.6% in crude ore, in ground',
'Cobalt, in ground',
'Copper, ion',
'Dioxins, measured as 2,3,7,8-tetrachlorodibenzo-p-dioxin',
'Fluorine, 4.5% in apatite, 1% in crude ore, in ground',
'Iodine, 0.03% in water',
'Iron, 46% in ore, 25% in crude ore, in ground',
'Lead, 5.0% in sulfide, Pb 3.0%, Zn, Ag, Cd, In, in ground',
'Magnesium, 0.13% in water',
'Manganese, 35.7% in sedimentary deposit, 14.2% in crude ore, in ground',
'Mercury',
'Molybdenum, 0.11% in sulfide, Mo 4.1E-2% and Cu 0.36% in crude ore, in ground',
'NMVOC, non-methane volatile organic compounds',
'Nickel, ion',
'PAH, polycyclic aromatic hydrocarbons',
'Particulates',
'Pesticides, unspecified',
'Phosphorus, 18% in apatite, 12% in crude ore, in ground',
'Potassium, ion',
'Propiconazole',
'Selenium',
'Sodium, ion',
'Tebuconazole',
'Tin, 79% in cassiterite, 0.1% in crude ore, in ground',
'Titanium, ion',
'Uranium, in ground',
'Vanadium, ion',
'Waste to recycling',
'Water, cooling, unspecified natural origin, Europe without Switzerland',
'Water, cooling, unspecified natural origin, RER',
'Water, unspecified natural origin',
'Water, unspecified natural origin, FR',
'Water, well, RER',
'Zinc, 9.0% in sulfide, Zn 5.3%, Pb, Ag, Cd, In, in ground',
'_Exported electricity',
'_Exported heat'}

Addition: while I could of course continue the migration to ecoinvent-3.9 or higher (I tried and it links most of the unlinked biosphere flows above when going to ecoinvent-3.10 and for the remaining unlinked flows, the issue is about the units), it is of interest for my case to have the project in ecoinvent3.8.
And I guess, it would be cleanest to have migration steps that work directly on the versions themselves and not only when combined with a later version-migration step.

@muelleram this is a very well documented issue, thanks for filing it

I suppose this could be linked to issue #4 , but I'm not sure.
I'm guessing the said spreadsheet referenced in #4 is probably a better source for the actual migration data.


Fix required itmdump version to match install steps

Lower in the steps 0.3.1 is used, so I presume this is the correct version.

bors r+


Show the XML file used in log4net configuration as a plain file

First commit is for the snippet generator; second commit uses the changes.

LGTM


add missing usage of CopyChars

@sudoerChris : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"


Emmet balance not working with typed components

VSCode Version: 1.36.1
VSCode Insiders Version: 1.37.0-insider
OS Version: Ubuntu 18.04

Steps to Reproduce:

create typed FunctionComponent
example:

import React, {FunctionComponent} from 'react'

interface IProps {
}

const SomeComponent: FunctionComponent<IProps> = (props) => (

item

)

put cursor on li tag
run command Emmet: Balance (outward)

Current behavior: nothing happening
Expected behavior: li tag selected
Same bug with  Emmet: Balance (inward).
Without <IProps> everything works well.

Does this issue occur when all extensions are disabled?: Yes

same her

same here

Yes, its not working for me too!!!

This issue occurs because the current parser attempts to parse <IProps> as part of the HTML tree. Closing in favour of #99896


Fix log.debug statements

Revert partial code from commit 2c5306e12 that broke(?) log.debug statements inside strategies
Fix small typo

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
bug fix

What is the current behavior? (You can also link to an open issue here)
log.debug is not logging

What is the new behavior (if this is a feature change)?
fix log.debug

Other information:
log.debug from OOTB strategies are not working on latest develop
I'm not sure if the message.log change was an intentional change, or an accidental addition

I removed this (in a commit for something else - apologies) because it was slowing down backtests (since most strats log a lot and all this data was pushed from the backtester -> parent process -> stdout).
But I see this basically hides all logs from the backtesters (when using the UI or API).
I was thinking the following instead:

in the UI add a "debug" tickbox to the backtest screen, this toggles the log level of the backtester (to either log or not).
Apply this patch so that if the backtester logs, it should stream up.
Add documentation on how to properly set up a "create strategy environment".

What do you think?

I am actually applying this already, since it is currently actually a bug. Though the above question still holds.

For sure, some type of checkbox makes sense (and even control in the code with something like this.debug = true)

How the config behaves in general (especially when using the UI) is grown a bit out of hand, if you are interested in the full discussion please check out #956.
Before the UI there was one config that did everything, now it is split into a few different categories (how you want everything to behave, like database stuff / how you want the UI to behave, like ports and hosts / how you want individual instances to behave, like this feature).


(v2 Beta) QDM doesn't work if you switch ES to another monitor

follow up items moved to #101, closing


[consensus] Eliminate unused code intended to update the connectivity…

… manager network configurations

Motivation
Eliminate unused code that connects the ConsensusNetworkSender to the ConnectivityManager.
I stumbled onto this code while attempting to refactor/consolidate/clean the network_builder.  Upon inspection, it turns out that the conn_mgr_reqs_tx field of ConsensusNetworkSender is only accessed in update_eligible_nodes which is not used anywhere in the codebase or in tests.  Ergo, the feature should be unnecessary.
I am currently attempting to re-organize/refactor/simplify the main_node.rs specifically in relation to the network_builder and setup_network call.  This specific feature of consensus mildly interferes with that work.
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
Do not break existing unit or integration tests.
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

@davidiw Holler if you know of some missing context.

@bors-libra r+

:pushpin: Commit 22bc0fa has been approved by davidiw

:hourglass: Testing commit 22bc0fa714a42c602a74da5187c66d5f7b241bdf with merge de2283323e1c8020a8645262459c7e5d1a3ad5af...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: davidiw
Pushing de2283323e1c8020a8645262459c7e5d1a3ad5af to master...


the exe is not working

when I try to open the exe it says I have to open the cmd to open it is there any fix or I'm doing something wrong?

You have to execute the exe via cmd and not double click.


Quote "monospace" in code definition

Unfortunately, Firefox does not correctly use a monospace font when
font-family: monospace is used unless it is quoted.

Can you describe the exact error you're seeing without quotes? I don't think I can replicate at the moment.

Hmm... now that I play with this more, I think this may be a byproduct of my desktop environment, if I recall it was working correctly prior to switching to xfce...
I'll look into it.

Welp, it's something related to switching to XFCE, so I switched to a different desktop manager and now it's fixed. Closing this.


Completed working on responsiveness and the UI

I have made the food cards more responsive than before, changes the background color, improved design.
Added link to the whole card rather than just the name as mentioned in the #33 issue
You can merge and close both #37 and #55 issues

how background changes , how responsiveness  attach photo


patched release-4917

in case that the compute image needs to be rolled back

decided to handle upgrades by https://github.com/neondatabase/neon/pull/7128 instead of creating a backup image.


feat: paginated view

Paginated view + extension of #113 without the breaking change

Closes #10, #112


Improve dockerfile and docker-compose

Added Health check for database, Added Local host Postgress DB URL for the contributors, Improved Dokcerfile, earlier when we do docker compose up the logs were not clear and it got stuck at RUN npm dev, Not it showing both postgres and Tiplink Logs and better startup for contributors

Cool, seems fine, merging it @vanshavenger


Fixed instruction creation code breaking for multiple instructions.

If it ain't First.First it breaks. :')

The build is failing because the master branch still has this broken line in there from my accepted broken pull request lol:
Script.cs -> if (instructions[0]["opcode"] != null && instructions[0]["operand"] != "")
should be
if (instructions[0]["opcode"] != null && instructions[0]["operand"] != null)
The code in this pull request is working fine.

Thanks!


Add implementation and test for write ack problem

We noticed that there was a problem when running setDataWithAck from the client and traced the problem here. The main problem is that there are two different callbacks that both use the same message, but one of the callbacks change the message, making it fault in the second one.
First this.services.storage.set(...) is called here, this may be an async operation. This function in turn calls this.onStorageSetResponse(...) when it is finished, found here.
Second, this.services.cache.set(...) is called here, with a callback to this.onCacheSetResponse(...) when it is finished, found here.
If the call to onStorageSetResponse() is called after onCacheSetResponse() then there is a possibility that correlationId and isWriteAck will have changed, because of here, causing onStorageSetResponse() to not properly acknowledge the original message.
I solved it with this implementation and added a test for it, emulating an async storage and sync cache which causes the fault to trigger.

Looks like there are some CI issues, will take a look later on today so that PRs are green and ready to go.
Thank you and @daviderenger for raising, we needed a bit of a push to get v4 out the door!

I had some more looking into this and found that a term change for requestorData and requestorName would be harder than anticipated. Inside of the protocol there are keys defined that basically say what fields in the messages are "allowed" to be sent for "meta". There is also
In https://github.com/deepstreamIO/urp-js/blob/4b846b3a363977de43cd8bc7c612920318e0eaa2/src/message-builder.ts#L78 we see that only META_KEYS are put into the sent message, otherwise they need to be part of the data/parsedData field. Obviously we cannot let a user configure what goes into META_KEYS, except the default of requestorName and requestorData. I do not think that it is a bright idea to start tinkering with how the data/parsedData looks like, since it can be both null and an object and some RPC_ACTIONS want it to be null.
I am thinking that the option to rename it should be completely removed from the server and if a renaming option should be used then it should be added on the client. I'll update this PR in the afternoon, removing the option to rename requestorName and requestorData

Thanks!


VoxelRCNN, assert xyz.shape[0] == xyz_batch_cnt.sum(),

When I use " POINT_CLOUD_RANGE: [-40, -134.4, -2, 40, 70.4, 2]" and set batch_size=8 in KITTI, training is ok, but when I change the batch_size=12, it outputs the following errors:
pcdet/ops/pointnet2/pointnet2_stack/voxel_query_utils.py", line 77, in forward
    assert xyz.shape[0] == xyz_batch_cnt.sum(), 'xyz: %s, xyz_batch_cnt: %s' % (str(xyz.shape), str(new_xyz_batch_cnt))
AssertionError: xyz: torch.Size([1563008, 3]), xyz_batch_cnt: tensor([27648, 27648, 27648, 27648, 27648, 27648, 27648, 27648, 27648, 27648,
        27648, 27648], device='cuda:0', dtype=torch.int32)

Sorry, I am not sure about what happens here.


SecurityHub import fails with AccessDenied if finding is in another region

Even with policy allowing BatchImportFindings, API call can fail if we are trying to import finding from one region to Security Hub in another region, e.g. missing VPC flow logs in ap-south-1 being imported into us-east-1 Security Hub.
Region-locking prowler (-r switch) does not seem to help, because some checks are global.
This can be important if AccessDenied events are monitored by some CloudWatch alerts, and because of that we can't run prowler frequently without disturbing the team.

Thanks for your feedback @DenSpirit, have you tested running prowler from a region (in an EC2 in that region) where is the same as your Security Hub? You can filter also region by -f to just do that region and avoid any other region that you don't need to check.
For the access denied you can use -f along with your own group of checks and/or whitelisting -w see README for more information. If you don't have permissions to check a particular service, resource or region you can avoid it.

@marcjay what do you think about this issue?

Interesting! I wasn't aware that Security Hub had this restriction, though it makes sense, though means you can't consolidate all your findings if you're multi-regional into one 'Security Hub' environment.
I've raised #621 which should resolve this - forcing the finding to be imported to it's associated region. @DenSpirit please could I possibly ask you to try that sechub-import-to-finding-region-618 branch to see if it resolves your issue?


Refactor param_dict to deepspeed config

As discussed in #983, allows deepspeed_config to be a file path or a dictionary when passed into the Init function or initialize function. This will be a breaking change for people using config_params however should allow cleaner parsing in the future of all the parameters.
cc @stas00 @tjruwase

Thanks everyone for pitching in :) should be good to go, let me know if there is anything that needs addressing!


TST: rename head branch for GEOS from 'master' to 'main'

GEOS renamed their git development head branch from 'master' to 'main' in March 2021 (ref).

Coverage remained the same at 85.421% when pulling 3d09cf3cf903a8a3abb5382ad04ae5446a0602da on mwtoews:geos-main into 4cb8ffab3dcb7dfdd4f539faccdd41c9ed17be8b on Toblerity:master.

@mwtoews I'd be in favor of doing the same here.

@sgillies I'd support that too. It would probably make sense to do two changes at once: move repo to https://github.com/shapely/shapely and rename the head branch to main.

Also +1 on renaming to "main" (I only need to update my local scripts/aliases to handle both master and main for a while .. ;))

It's a matter of timing and tasks related to #962

It could be done at the same time, but I don't think that's necessary. The fact that the content of the "shapely-2.0" branch will move the the master/main branch in the future, doesn't prevent already renaming the current master branch right now.

And also +1 on moving to the github.com/shapely org. It will be good to have the different repo's (shapely-wheels, rfc) in a single organization.


Implement missing List type modules

I glossed over:

https://wbcsd.github.io/data-exchange-protocol/v2/#dt-crosssectoralstandardset
https://wbcsd.github.io/data-exchange-protocol/v2/#dt-productorsectorspecificruleset
https://wbcsd.github.io/data-exchange-protocol/v2/#dt-emissionfactordataset

When I first built the library, and now there's some meh looking code in the repo on classes that aggregate these. the base data types are already implemented but I just need to roll these new classes and then swap them out in the appropriate places.

This is what I mean, the cross_sectoral_stanards attr and the other one, can be improved with an actual implementation of the class, would also provide a lot of benefits in terms of a higher level of abstraction for interacting with them

completed


Any possibility to make backend uia faster

i have a very simple script that click few buttons in calculator app. If I use backend win32 executing script takes about 16 sec, but if I use backend uia same script takes 1 min 35 sec. Below examples scripts. Each script is executed 4 times.
script below uses buttons text to find it
app = Application()
appconnect = app.connect(title='Calculator')
app_dlg = appconnect.top_window_()
app_dlg.window_(best_match='3').Click()

script below uses buttons automatinID
app = Application(backend='uia')
appconnect = app.connect(title='Calculator')
app_dlg = appconnect.top_window_()
app_dlg.child_window(auto_id='button5').click_input()

Choosing search criteria is important for performance. I'd recommend using class_name='Button' in child_window because getting class_name works faster and it filters out a lot of unnecessary controls before searching by auto_id or by title. Though this is true for backend='win32' as well.

it did not work in this case. Is there any other way to get this go bit faster? now it still takes 13-14 sec and with backend='win32' takes 1 sec.
app = Application(backend='uia')
appconnect = app.connect(title='Calculator')
app_dlg = appconnect.top_window_()
app_dlg.child_window(class_name='WindowsForms10.BUTTON.app.0.141b42a_r14_ad1', auto_id='button5').click_input()

Hmm... I think I can improve this for auto_id case (will commit soon). Thanks for the report.

actually it seems that connect() and top_window_() methods are taking the most time to complete. connect() method takes 6-7 sec and top_window_() takes same 6-7 sec
appconnect = app.connect(title='Calculator')
app_dlg = appconnect.top_window_()

They both work for 0.042 sec for me. How many windows do you have opened on your desktop? Is that time reduced after closing some of them?

did not help. only have python and test app. also noticed something interesting
code below
app = Application(backend='uia')
appconnect = app.connect(title='Calculator', framework_id='WinForm')
app_dlg = appconnect.top_window_()
app_dlg.child_window(class_name='WindowsForms10.BUTTON.app.0.141b42a_r14_ad1', auto_id='button5', title='3').click_input()

times to execute
2016-10-29 23:20:49.516000 start
2016-10-29 23:20:49.579000 backend selected
2016-10-29 23:20:55.710000 connection made
2016-10-29 23:21:01.809000 top window
2016-10-29 23:21:02.184000 button clicked and end
code below, I changed top_window_() method to window_() method and now it takes more time to find the actual button
```

app = Application(backend='uia')
appconnect = app.connect(title='Calculator', framework_id='WinForm')
app_dlg = appconnect.Window_(title='Calculator')
app_dlg.child_window(class_name='WindowsForms10.BUTTON.app.0.141b42a_r14_ad1', auto_id='button5', title='3').click_input()

2016-10-29 23:21:59.436000 start
2016-10-29 23:21:59.483000 backend selected
2016-10-29 23:22:05.723000 connection made
2016-10-29 23:22:05.738000 window
2016-10-29 23:22:12.165000 button clicked and end

@nimuston, can you switch to path argument in the connect call ? Like this:
app.connect(path="calculator.exe")

wow now it only takes 7 sec :) this path is now searching calculator.exe process name and makes connection base on that? is this correct? is there still some ways to make it a bit more faster?
2016-10-29 23:40:07.608000 start
2016-10-29 23:40:07.624000 backend selected
2016-10-29 23:40:07.796000 connection made
2016-10-29 23:40:14.644000 top window
2016-10-29 23:40:14.956000 button clicked and end

path is now searching calculator.exe process name and makes connection base on that? is this correct?

Yes, you can specify an executable by its name

is there still some ways to make it a bit more faster

You should try to specify more detailed search criteria. Maybe you could use print_control_identifiers to find more clues:
app.top_window().print_control_identifiers()

and after that try to build a call like:
app.window(title="Calculator", class_name="...")

still some problems with slowness even if I use multiple search criteria's for the button. Even if I use buttons title or window text. I see that this is labeled as bug so any idea when the fix is available?

Hmm... I think I can improve this for  auto_id  case (will commit soon). Thanks for the report.

example with the test app WpfApplication1.exe it takes 5 sec to press one button. Same operation with backend='win32' takes less then a seconds.
app = Application(backend='uia')
appconnect = app.connect(path='WpfApplication1.exe')
dlg = appconnect.window_(title='WPF Sample Application')
dlg.child_window(auto_id='button2', title='Apply').type_keys('ENTER')

@nimuston, UIA backend always runs slower than the native 'win32', but for this simple example it shouldn't take 5 seconds. On my machine it finishes in 200 mlsec.
Could you run the code below and show us the output? I'm just curious to see the timing.
import logging
from pywinauto.application import Application

# Config logger
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)

def run_app(backend):
    logger.info("Start UIA")
    app = Application(backend=backend)
    logger.info("Created")
    appconnect = app.connect(path='WpfApplication1.exe')
    logger.info("Connected")
    dlg = appconnect.window_(title='WPF Sample Application')
    logger.info("Dialog win spec is created")
    btn_wrp = dlg.child_window(auto_id='button2', title='Apply').wrapper_object()
    logger.info("Button wrapper is created")
    btn_wrp.type_keys('ENTER')
    logger.info("End UIA")

run_app('uia')

results
2016-11-01 14:43:21,242 INFO: Start UIA
2016-11-01 14:43:21,242 INFO: Created
2016-11-01 14:43:21,256 DEBUG: Release <POINTER(ITypeLib) ptr=0xccbc20 at 3b69148>
2016-11-01 14:43:21,319 INFO: Connected
2016-11-01 14:43:21,319 INFO: Dialog win spec is created
2016-11-01 14:43:21,319 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x4243940 at 40cc848>
2016-11-01 14:43:21,319 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x30eeee0 at 4012048>
2016-11-01 14:43:27,039 DEBUG: Release <POINTER(IUIAutomationElementArray) ptr=0x4241d70 at 4012048>
2016-11-01 14:43:27,039 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x42439f0 at 3fe3048>
2016-11-01 14:43:27,164 DEBUG: Release <POINTER(IUIAutomationElementArray) ptr=0x4241d10 at 4012048>
2016-11-01 14:43:27,164 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x4245070 at 3fe3048>
2016-11-01 14:43:27,164 INFO: Button wrapper is created
2016-11-01 14:43:27,226 INFO: End UIA
2016-11-01 14:43:27,226 DEBUG: Calling CoUnititialize()
2016-11-01 14:43:27,226 DEBUG: CoUnititialize() done.

OK, now it's clear that btn_wrp = dlg.child_window(auto_id='button2', title='Apply').wrapper_object() takes long.
Try this criteria:
btn_wrp = dlg.child_window(auto_id='button2', title='Apply', control_type='Button').wrapper_object()

What is the output then?

it did not get any faster, but this would be ok for me that the pressing button takes 4-7 sec, but the real problem I have is with the app that I'm actually automating. It takes 4-8 minutes to press buttons. This is really bad thing. The app that I'm automating contains multiply winforms and multiple buttons and it seems that if I'm example in the main view and I press button, then app opens another winforms inside the main form and if I try to press another button there it takes really long time to execute. Any idea how I can get it to be faster? it seems that now it goes through every time every buttons until it finds a match. Is there a way that I can tell to the script that this is the main forms example "app.title" and that is should only search button inside "second.winform" and maybe it would be faster that way?
2016-11-01 19:42:34,819 INFO: Start UIA
2016-11-01 19:42:34,819 INFO: Created
2016-11-01 19:42:35,051 INFO: Connected
2016-11-01 19:42:35,052 INFO: Dialog win spec is created
2016-11-01 19:42:35,052 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x2e
f910 at 2d060c8>
2016-11-01 19:42:35,053 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x2e
f860 at 2d0c848>
2016-11-01 19:42:39,572 DEBUG: Release <POINTER(IUIAutomationElementArray) ptr=0
x2eb670 at 2d0c848>
2016-11-01 19:42:39,572 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x2e
f9c0 at 2dd8848>
2016-11-01 19:42:39,575 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x46
8d50 at 2dd8848>
2016-11-01 19:42:39,575 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x46
8ca0 at 2d0c848>
2016-11-01 19:42:39,767 DEBUG: Release <POINTER(IUIAutomationElementArray) ptr=0
x2eb670 at 2d0c848>
2016-11-01 19:42:39,769 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x46
8e00 at 2dd8f48>
2016-11-01 19:42:39,770 INFO: Button wrapper is created
2016-11-01 19:42:39,792 INFO: End UIA
2016-11-01 19:42:39,793 DEBUG: Calling CoUnititialize()
2016-11-01 19:42:39,793 DEBUG: CoUnititialize() done.

For the child window form it's possible to use parent keyword in search criteria.
Say you have winform2 = app.winform1.winform2.wait('ready') # returns UiaWrapper.
Then you may create criteria so: app.winform1.child_window(parent=winform2, control_type='Button', title='Apply'). Yeah, it's a little bit bulky but should work. Will think about getting window specifications from wrappers as well. It might be a good idea.

tried that and got TypeError: descendants() got an unexpected keyword argument 'process' maybe I just don't understand this the right way.

This looks like a serious bug. Thanks! We will fix it hopefully this week.

hi, any progress with the issue? any possibility to make uia work faster? it is very slow if I have multiply winforms in the same app opened same time. :(

@nimuston, if you your winforms are constantly open you can keep wrappers for each form or even for buttons on the forms and avoid additional windows resolution.
# Find forms and keep
frm1_wrp = app.WinForm1.wrapper_object()
frm2_wrp = app.WinForm2.wrapper_object()

# locate the buttons on the forms
btn_lst = fm1_wrp.descendants(control_type="Button")
btn_[0].click_input()
btn_lst = fm2_wrp.descendants(control_type="Button")
btn_[0].click_input()

@nimuston, I understand your impatience, but our main jobs aren't related to GUI automation. So bug fixing might be slow. Please keep it in mind.
I've fixed the issue with parent criterion locally, but I need to write more tests before merging to the main repo. It will take some time.
So far you can try this workaround:
app.winform1.child_window(parent=winform2.element_info, control_type='Button', title='Apply')

I'll make calling element_info property unnecessary in the next pull request.

Hi, good that my feedback is useful :) I tried something like this, correct my if my code is totally wrong, also i got a nice error message. It also seems that with the app i'm trying to automate it takes really long time to print control indentifiers, it might be because the app has "multiple" layers. I meant that it has a lot of winforms on top of each other.
from pywinauto.application import Application

app = Application(backend='uia')
appconnect = app.connect(title='app.title')
window = appconnect.window(title='app.title')
window2= window.child_window(title="3", auto_id="winformname", control_type="Window")
button = window2.child_window(parent=window, control_type='button', auto_id='_buttonname_1')
bwp = button.wrapper_object()

Traceback (most recent call last):
  File "<pyshell#9>", line 1, in <module>
    bwp = button.wrapper_object()
  File "build\bdist.win-amd64\egg\pywinauto\application.py", line 246, in wrapper_object
    ctrls = self.__resolve_control(self.criteria)
  File "build\bdist.win-amd64\egg\pywinauto\application.py", line 236, in __resolve_control
    criteria)
  File "build\bdist.win-amd64\egg\pywinauto\timings.py", line 402, in wait_until_passes
    func_val = func(*args)
  File "build\bdist.win-amd64\egg\pywinauto\application.py", line 199, in __get_ctrl
    ctrl = self.backend.generic_wrapper_class(findwindows.find_element(**ctrl_criteria))
  File "build\bdist.win-amd64\egg\pywinauto\findwindows.py", line 84, in find_element
    elements = find_elements(**kwargs)
  File "build\bdist.win-amd64\egg\pywinauto\findwindows.py", line 207, in find_elements
    cache_enable=True)
TypeError: descendants() got an unexpected keyword argument 'process'

Please change this line:
button = window2.child_window(parent=window, control_type='button', auto_id='_buttonname_1')

to this one:
button = window2.child_window(parent=window.element_info, control_type='button', auto_id='_buttonname_1')

hi, @vasily-v-ryabov i changed the code but it did not get any faster, also i'm wondering do you know why print_control_identifiers() takes over 2 minutes to complete even if i use depth=1 print_control_identifiers(depth=1) ?

We already saw in your traces that there is a 5-second gap to locate the main window of the application. Notice the time stamp at the last line
2016-11-01 14:43:21,319 INFO: Connected
2016-11-01 14:43:21,319 INFO: Dialog win spec is created
2016-11-01 14:43:21,319 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x4243940 at >40cc848>
2016-11-01 14:43:21,319 DEBUG: Release <POINTER(IUIAutomationCondition) ptr=0x30eeee0 at 4012048>
2016-11-01 14:43:27,039 DEBUG: Release <POINTER(IUIAutomationElementArray) ptr=0x4241d70 at 4012048>

I think this is the root cause. Even print_control_identifiers start with a top window. It's not clear, at least for me, why on your machine it takes so long.

In so called "real use" the gap is bigger 1-2 minutes

Can you provide some details about your environment: OS, architecture, python version e.t.c. ? Did you try to tune it somehow ? Things like: disabling antivirus, raising the python process priority....

Win 10 64 bit, python 2.7 i'm running python script from command line and priority for that window is highest. Tested all the possible search criterias

Hi, found another way to do this it is 1 sec faster :) but still not fast enough
app = pywinauto.Application(backend='uia')
appconnect = app.connect(path='app.exe')
window = app.top_window()
wrapper = window.wrapper_object()
ctrl = wrapper.descendants(control_type='Button')
button = ctrl[1].click_input()

Is there a way for me to know what actually is inside this every index of this list? now if i print for example one index from the list is shows me this below:
<pywinauto.controls.uia_controls.ButtonWrapper object at 0x0000000004D26390>

Is there a way for me to know what actually is inside every index of this list?

print [ctrl.window_text() for ctrl in wrapper.descendants(control_type='Button')]

Hi again,
@vasily-v-ryabov i tested the fix you make for "findwindows.py" file and i got this new error message:
TypeError: descendants() got an unexpected keyword argument 'cache_enable'
do you have time to check what is wrong?

Nice i accidentally closed this issue, how i can open it again?

So the original problem " TypeError: descendants() got an unexpected keyword argument 'process'  seems to be fixed in this new findwindows.py file " , but it generated new error " TypeError: descendants() got an unexpected keyword argument 'cache_enable' "

@nimuston, can you show the full exception stack. Which commit did you use exactly ?
BTW, as I understand you still have the problem with the slow access to the top window. I just thought about an additional option with using Desktop object. For example, if I have an instance of Process Explorer, I can access it as following:
from pywinauto import Desktop
d = Desktop(backend='uia')
d.ProcessExplorerSysinternalsWwwSysinternalsCom.draw_outline()

code I'm using:
app = pywinauto.Application(backend='uia')
appconnect = app.connect(path='WpfApplication1.exe')
appwindow = appconnect.window(title="WPF Sample Application", control_type="Window")
secondwindow = appwindow.child_window(title="Alpha", control_type="ToolBar")
button = secondwindow.child_window(parent=secondwindow, title="button 1", auto_id="toolbar_button1", control_type="Button")
button.click_input()

error message:
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    button.click_input()
  File "build\bdist.win-amd64\egg\pywinauto\application.py", line 346, in __getattribute__
    ctrls = self.__resolve_control(self.criteria)
  File "build\bdist.win-amd64\egg\pywinauto\application.py", line 236, in __resolve_control
    criteria)
  File "build\bdist.win-amd64\egg\pywinauto\timings.py", line 402, in wait_until_passes
    func_val = func(*args)
  File "build\bdist.win-amd64\egg\pywinauto\application.py", line 199, in __get_ctrl
    ctrl = self.backend.generic_wrapper_class(findwindows.find_element(**ctrl_criteria))
  File "build\bdist.win-amd64\egg\pywinauto\findwindows.py", line 85, in find_element
    elements = find_elements(**kwargs)
  File "build\bdist.win-amd64\egg\pywinauto\findwindows.py", line 209, in find_elements
    cache_enable=True)
TypeError: descendants() got an unexpected keyword argument 'cache_enable'

and yes I still have a problem with the slow access to the top window. I tried using Desktop object but the results were same still slow.

actually it seems that Desktop object it bit faster than Application object. at least with the test app
`def desk():
start = time.time()
app = Desktop(backend='uia')
window = app.window(title='WPF Sample Application')
window.child_window(auto_id='button2').click_input()
print time.time() - start
def app():
start = time.time()
app = Application(backend='uia')
appconnect = app.connect(title='WPF Sample Application')
appwindow = appconnect.window()
appwindow.child_window(auto_id='button2').click_input()
print time.time() - start`
in this case desk() takes 7,2 sec to run and app() takes 13,8 sec to run, so I really need to test this in real use, thanks!

I will take the previous comment back, run time is almost the same in both cases, if i just change (title='WPF Sample Application') to (path='WpfApplication1.exe') in app function.

@numiston, here a fixed example. Notice about the parent argument
app = pywinauto.Application(backend='uia')
appconnect = app.connect(path='WpfApplication1.exe')
appwindow = appconnect.window(title="WPF Sample Application", control_type="Window")
secondwindow = appwindow.child_window(title="Alpha", control_type="ToolBar")
button = secondwindow.child_window(parent=secondwindow.wrapper_object().element_info, title="button 1", auto_id="toolbar_button1", control_type="Button")
button.click_input()

@vasily-v-ryabov, there is a problem with passing a WindowSpecification or a wrapper object directly as the parent argument into findwindow chain. We may fix it in find_elements

Hi @nimuston, thanks for the report! And @airelil thanks for the fix!
I hope to get back with some optimizations after these long New Year holidays. :)

@nimuston, I know it's doesn't help with your main problem but still. With my fix in the master you can get now use your original code without specifiying 'element_info' explicitly:
button = secondwindow.child_window(parent=secondwindow, title="button 1", auto_id="toolbar_button1", control_type="Button")
button.click_input()

@airelil you fix works thanks!
yeah the original slowness problem is the biggest issue i have at the moment. I was thinking would it be faster if we were able to use example search depth when we are searching buttons auto_id. Something like this button = secondwindow.child_window(parent=secondwindow, title="button 1", auto_id="toolbar_button1", control_type="Button", searchdepth='3') . One idea to play around :)

Hello,
I see you spend time to improve speed.
But i wonder why these two methodes take the same time to execute:
#time find_till_btn()
#Wall time: 35.1 s
def find_till_btn():
    app_uia = application.Application(backend='uia').connect(path='TPDotnet.Pos.exe')
    win = app_uia['TP.net POS']
    win.child_window(auto_id='_cmdFunctionKey_13').wait('visible', timeout=60)

#time find_till_btn2()
#Wall time: 35.7 s
def find_till_btn2():
    app_uia = application.Application(backend='uia').connect(path='TPDotnet.Pos.exe')
    win = app_uia['TP.net POS']
    win.child_window(auto_id='_cmdFunctionKey_13', control_type='Button').wait('visible', timeout=60)

Hi @sragons thanks for testing it. Do you use 0.6.2 or current master branch? We made some fixes to check control_type prior to auto_id some time ago (but after 0.6.2 was out).

I use up to date master branch.

I also encountered a performance issue with the uia backend on my win10 box (5 seconds delay for finding main window); in my case the culprit seems to be COM IUIAutomationElement::FindAll call. Eg in Desktop("uia").window(title_re=".something.").set_focus() it seems to take FindAll 5 seconds to get to the right window from root, even though TreeScope is set to "children". (see UIAElementInfo.children(..) in uia_element_info.py)
I will try to dig further, but meanwhile, any insight in how/why this could happen?

Hi @RemcoTukker can you try the same on current master?
Direct call to UIAElementInfo().children() also takes the same time?

@vasily-v-ryabov Yes, it is the same on the current master, and I'm sure now that my particular problem is not caused by the pywinauto code. It's the COM FindAll on the root that is slow. I even tried to use it from a small C++ program, and still the same result.
After that I tried to use a TreeWalker, which shows again a similar delay of 4 seconds at the moment I use GetNextSiblingElement on the last child. So, 'FindFirst' functionality would be a possible workaround.
I tried the same on a win7 machine, and there everything worked fine. I don't have access to other win10 machines right now to test if it is just me / some weird stuff in my environment. For reference, I'm using Win10 home edition (up-to-date), but not the creators update.
So what's left to do? Maybe report it to MS somewhere? And one thing I still may try is to use the UIAutomation2 interface if I can figure out how to do that..

I had some fun with writing a monkey patch using the "FirstChild" idea, see this gist. This works around the FindAll call that is slow on my machine.
@nimuston @sragons If you want, you can try if using the gist makes a difference for you. Maybe you're looking at the same problem?
@vasily-v-ryabov Let me know if you think this functionality is good to have for other people as well. If so, I can make a proper pull request for it.

@RemcoTukker I did some testing with your fix and it seems that is it actually faster. For example
d1.window(first_only=True, title="TestApp").set_focus() takes 0,9 sec to execute
d1.window(title="TestApp").set_focus() and previously it took 3 sec to execute

@RemcoTukker this is great idea to add first_only=True option. 👍
It's worth to say option found_index=0 exists for all backends but it doesn't use FindFirst/GetNextSibling as well (I think it should be kept separate but it's discussable). It's just another way to disambiguate search criteria inherited from backend='win32' and it was never optimized. Ideally all backends should be in sync from class ElementInfo point of view for consistency. I'd be happy to discuss all these points in a pull request.
Thank you guys for your efforts!

@RemcoTukker Any plans to add other search criteria to the fix so that we can see how fast this fix really is? example auto_id

Yes I will prepare a pull request.. give me a couple of days though, i'm trying to fit it in office hours. As for your results, I think 0.9 seconds is still slow, and part of the gain you're seeing may be explained by not having to check all the windows. So I'm not sure it will solve all your problems @nimuston , but hopefully its a good start.

I was taking another look at the code today, and now I noticed you can already pass in the handle to the window function, which at least on my win10 pc is very fast. It completely avoids the slow COM UIA calls as long as the handle doesnt change. I guess that the handle stays constant for most usecases (in particular on the root level).
So maybe the best thing to do would be to recommend users to cache the handle themselves (or maybe with some help from pywinauto)? My workaround code would then only make the initial lookup a bit faster, but Im not sure that benefit is worth the extra mess in the code...

edit Ah wait, caching the handle is basically the same as caching the wrapper_object, right?
Correct. Not every UI element has native handle, but in any case wrapper_object isn't re-created if you use return value of .wrapper_object() twice or more.

Right, all is clear to me now, I'll get to work :)
In conclusion, as you mentioned earlier, the most significant speedup for me is to cache the wrapper_object and then use it like this:
pywinauto.Desktop('uia').window(parent=cached_wrapper_object, title_re='something.*', top_level_only=False)
Adding the process, class_name, control_type and title to the criteria can also help.
Maybe it's a good idea to document the above somewhere or to make it easier to do this, eg by allowing calling .window() on a wrapper object, as you proposed. Apart from that I will make a pull request for a slightly optimized version for finding the first direct child that satisfies some criteria.

@vasily-v-ryabov Yes, it is the same on the current master, and I'm sure now that my particular problem is not caused by the pywinauto code. It's the COM FindAll on the root that is slow. I even tried to use it from a small C++ program, and still the same result.

I had the same problem with C ++ code. This is Windows 10 issue, and should be resolved by Windows 10 update kb3093266.

Hi guys, we made significant speed up of dump_tree() method in branch atspi (will be next major release one day, no exact estimation yet). This method now checks for attribute app.allow_magic_lookup == False and it doesn't print and even calculate "best_match" names in this case. Also general speed up and limitation parameters were added.
If you don't mind to adapt your code to other changes in pywinauto interface (should be smooth if you're reading error messages carefully), please try this new version:
pip uninstall -y pywinauto
pip install https://github.com/pywinauto/pywinauto/archive/atspi.zip

I think we made enough optimizations in branch atspi recently. Maybe some bottlenecks are still there. But I'd prefer to close this old issue. Please open new one (and maybe add reference here) if you have some specific case. Thanks all for good discussion.


npm ERR! peer dep missing while installing vue/cli

Version
4.5.8
Environment info
windows 10x64

Steps to reproduce
First I run the command "npm i -g @ vue/cli" to install vue cli. The installation is fine, no errors occur.
But when I run the command "npm list --depth=0 -g" I get the following error: "npm ERR! peer dep missing<EMAIL_ADDRESS>required by<EMAIL_ADDRESS>I installed<EMAIL_ADDRESS>but the error message still appears.
I also tried clearing the cache, reinstalling it but it still didn't work.
The only way that works is I delete vue/cli on npm and install it with yarn, now there will be no error message. But I don't really want to switch to yarn I just want to install vue/cli with npm
What is expected?
OK
What is actually happening?
npm ERR! peer dep missing<EMAIL_ADDRESS>required by<EMAIL_ADDRESS>

See https://github.com/vuejs/vue-cli/issues/5940#issuecomment-706528527


[freetype-gl] Add feature glad

Fixes #31424

[x] Changes comply with the maintainer guide
[ ] SHA512s are updated for each updated download
[ ] The "supports" clause reflects platforms that may be fixed by this new version
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

feature glad tested successfully in the following triplet:

x86-windows
x64-windows
x64-windows-static

The new feature doesn't seem to affect the binary code, but it changes what is included by the package's opengl header: rougier/freetype-gl#218 Isn't this alternative behaviour enough to break downstream code? OTOH consumers should include the relevant headers.

@dg0yt, Thank you for your review and suggestions, I looked at the upstream code and confirmed that some .h files are included when the freetype-gl_WITH_GLAD option is enabled, but I can't test whether these header files affect the downstream code, I tested the gdal feature on multiple triplets locally, I think There should be no problem with upstream accepting this option.


HttpUrl doesn't encode | in query parameters

I'm not able to create a uri that has | in one of the query parameters.
HttpUrl.parse("http://do.not.use").newBuilder()
	.addQueryParameter("q", "one|two|tree")
	.build().uri();

Exception:
java.lang.IllegalStateException: not valid as a java.net.URI: http://do.not.use/?q=one|two|tree
	at com.squareup.okhttp.HttpUrl.uri(HttpUrl.java:336)

Should I encode the field and use addEncodedQueryParameter?

Can you try with the code on master, or the 2.6.0-SNAPSHOT artifact?
On Sat, Nov 7, 2015 at 12:58 AM German Attanasio Ruiz <
<EMAIL_ADDRESS>wrote:

I'm not able to create a url that has | in one of the query parameters
HttpUrl.parse("http://do.not.use").newBuilder()
.addQueryParameter("q", "one|two|tree")
.build().uri();
Exception:
java.lang.IllegalStateException: not valid as a java.net.URI: http://do.not.use/?q=one|two|tree
at com.squareup.okhttp.HttpUrl.uri(HttpUrl.java:336)
Should I encode the field and use addEncodedQueryParameter?
—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/1976.


Improve exceptions handling

Type of issue

[x] Bug
[ ] New feature
[x] Enhancement

Description
The introduction and usage of BaseException has made handling and debugging errors more difficult than needed, mostly due to information loss. The code is catching BaseException everywhere without distinguishing different cases, and not handling them case by case.  Also, exceptions are thrown in different ways, depending on the code being synchronous, asynchronous or within a callback.
Some recommended changes:

remove BaseException and handle exceptions explicitly by type
avoid catching generic exceptions without rethrowing
as in other projects, wrap external exceptions with local exception types
let these exception bubble up to the web service layer, and expose them as "ExternalDependency errors", using HTTP 503 status code, or internal errors, e.g. configuration errors, using HTTP 500 status code.
NotFoundException should reach the web service layer and return a 404 (unless the code is only checking if a resource exists for some reason, in which case an exception is too expensive anyway)
ConflictException should produce a 409
ResourceOutOfDateException should produce a 412
use CompletionException appropriately, using the same pattern in all the codebase

The web UI client application should handle these errors:

500: no need to retry because the service is broken, inform the user
503: retry without overloading the service, the service will eventually recover - inform the user if the error continues for more than N seconds
409: assume some other client tried the same action, and depending on the case take action
412: fetch the resource and retry if possible, inform the user otherwise

Fixed


Report by project and report by project and user do not work resulting 502 error

Fixed in https://github.com/maddevsio/comedian/commit/11c7788ffdc2a34580d7cf11014491604a31ea88


use https instead of git url to git clone repo

ssh keys to github repo are also not necessary if interacting via https as read-only
Also recommend using JNLP slaves for the same reason to ease setup.
This should resolve https://github.com/groupon/DotCi/issues/139

Now rebased to match https://github.com/groupon/DotCi/commits/DotCi-2.11.0

Note to self to investigate options button as well as explore discussion in https://github.com/groupon/DotCi/issues/103

to do explore creating own toggle button like https://github.com/groupon/DotCi/blob/4546e8b5613385e9eb7760403e644ac661015fbd/src/main/java/com/groupon/jenkins/dynamic/build/JobUiProperty.java

slated for DotCi-2.12.3


auth: Help consumers manage signing into tenants better

Consumers of the auth package are running into the same issues that made us develop the tenants view. Users sign in but we can't list subscriptions because we need users to sign in to a specific tenant. For now, consuming extensions need to handle this on their own, but ideally we could handle this in a central place.

Related to #1815


Daily crash summary email

Describe the solution you'd like
Hockey used to support daily crash summary email for all the apps owned by the account. Would like to request this to be enabled for AppCenter.
Describe alternatives you've considered
Current alternative is to open the dashboard to get a crash summary
Additional context

Duplicate of https://github.com/microsoft/appcenter/issues/1378


Ehsaya in all dashboards and roles (Advanced Charts) [complete]

Finally i am done with Statistics of this system!


JSONSchemaType change nullable to be for nulls not undefined

What issue does this pull request resolve?
#1664
What changes did you make?
This removes null from Known, changes Nullable to check for null instead of undefined in a type definition, and hacks Nullable to check if we're passing in Known, in which case it does a union instead of a conditional.
Detailed notes
They way that Nullable<T> handles types in JSONSchemaType makes it
very difficult to create SomeJSONSchema that any JSONSchemaType can
be assigned to. After many efforts to create this from scratch it
became clear that the only thing that would do this is a copy of
JSONSchemaType with Nullable fixed. Doing so revealed a lot of
surprising "bugs" in SomeJSONSchema, the most notable being some
places accept numbers where it should only accept string indices. This
seemed almost like a typescript bug, but I didn't delve in.
My conclusion from all of this is that it may be better to fully
redesign JSONSchemaType due to the number of inconsistencies. In light
of that, I opted for the least breaking change, which was actually to
hack Nullable to behave appropriately for SomeJSONSchema,
essentially, we check if that's what's being called, and if so, "do the
right thing". If someone were to try and type something identical to Known they
would similarly get a slightly more permissive type than they intended.
We could work around this by making the check explicit (akin to the
IsPartial keyword) but I think the times when this might happen aren't
bad enough to be worth it.
Is there anything that requires more attention while reviewing?
This is stacked on another PR, so only look at the second commit to see what this is changing. General thoughts on if you think another approach is more reasonable.

sorry, should I have merged this instead of #1699? Now there are conflicts...

This is rebased so this one should be good. I'm currently trying to figure out how to appropriately stack PRs so that the second one can be reviewed independently.

this one probably should be a breaking change, am I right?
If so I should probably kick off v9 branch and merge it there...

yeah, that makes sense, I can rebase / retarget onto that branch when it exists.

When is the release of v9 likely?


[analyzer] Report error for type which is not well-bounded

This is the analyzer specific issue for #43724.
class A<X> {}
typedef G<X extends Y, Y extends A<X>> = void Function();

main() {
  late G<A<Null>,  A<dynamic>> x;
}

The analyzer as of b2e33ee5509210c84f640ba0ad28649c0e8d4dea does not report an error for the type G<A<Null>,  A<dynamic>> even though that type is not well-bounded. Details in https://github.com/dart-lang/sdk/issues/43724#issuecomment-706058315.

Here is a similar source code example where analyzer similarly does not produce expected compile time error:
class A<X> {}
typedef G<X extends A<X>, Y extends X> = X Function();

main() {
  late G<A<dynamic>, A<Null>> x;
}

@eernstg, is this a same issue or I need to file another issue here?

It is again a type which is not well-bounded (A<dynamic> <: A<A<dynamic>> does not hold; then substitute to G<A<Never>, A<Null>>, but now A<Null> <: A<Never> does not hold), so I think it fits as a single issue.

@eernstg  Analyzer now reports:

'A<Null>' doesn't conform to the bound 'A<Never>' of the type parameter 'X'.

Is this the appropriate error?

Yes, that's a good error message. I'd recommend that error messages involving malformed types that might be intended to be super-bounded should just report the basic errors (like "doesn't satisfy the declared bound"), rather than making an attempt to consider the type to be super-bounded, and then recommending how to fix it as such.
The reason for this preference is that super-bounded types are somewhat complex and would presumably be used by developers who are aware of the typing structure with so much detail that they'll know what to do. Conversely, developers who do not know about super-bounded types at all wouldn't gain anything useful from a message about how to specify a super-bounded type correctly.
I'll close the issue. @srawlins, please reopen if you disagree.


Create robflyrc

Hi @robflyrc it looks like you did everything right except you need to include ".yml" extension on your filename to trigger the workflow that processes your request. If you repeat the steps and include the .yml extension on your filename, your request should be processed by the workflow within ~1-3 minutes. Thanks!


Update template to latest master

Done with zig version 0.12.0-dev.1754+2a3226453

I am interested in pulling this, did you mean to close it?

Yes, I've changed a little more since then and I'm not sure if you agree with the removal of some build.zig functionality I've found weird. I can open a new one after all my changes

Sounds good, thanks!