incorrect information script

There is an incorrect information in the script. Script documentation and variable highlights Cloud, Messages an On-Prem AD account.
Right is the Cloud account.
Enter an Azure Active Directory global administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group for a domain and a member of the Enterprise Admins group for a forest.'
https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#create-a-kerberos-server-object

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

ID: 50b27a01-622e-d980-83f2-1ed27060613b
Version Independent ID: e6472e15-10d7-bd4a-da02-558f2774dbaf
Content: Passwordless security key sign-in to on-premises resources - Azure Active Directory
Content Source: articles/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises.md
Service: active-directory
Sub-service: authentication
GitHub Login: @Justinha
Microsoft Alias: justinha

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

Thanks for calling this out! I made a pull request to update this. https://github.com/MicrosoftDocs/azure-docs-pr/pull/189043
@justinha


Pipeline reproducibility #3

From https://github.com/c-BIG/NPM-sample-qc/issues/11
The way params.container  is set is seen by Nextflow as an ordinary variable.
Proposed solution:
Add an entry to the process block in the nextflow.config as:
process.container = 'justinjj24/npm-sample-qc:latest'

Agree. Added in the branchawsbatch-dev


load plugin gitbook-plugin-sitemap error

I have run gitbook install, but some error there.
gitbook-cli version 1.0.0
info: load plugin gitbook-plugin-sitemap ....ERROR

Error: Error loading plugins: gitbook-plugin-sitemap. Run 'gitbook install' to install plugins from NPM.

What is the output of gitbook versions:print ?

It works for me with GitBook 2.5.2.

node.js version 4.2.1

Must be installed on the plugin directory.
$ cd ./content/node_modules/gitbook-plugin-sitemap
$ npm install

Like this https://github.com/zhaoda/webpack-handbook


nMigen thinks -5 / 2 = 3

nMigen thinks -5 / 2 = 3 , but verilator disagrees.
I suspect this is because -5 // 2 evaluates to -3 in Python.
Commands
$python3 div.py
quotient = -3
$verilator -Wno-lint --cc --exe --build sim_main.cpp div.v
$obj_dir/Vdiv
quotient = -2

FIles
div.py
from nmigen import Signal, Module
from nmigen.back import verilog
from nmigen.hdl.ast import signed

## make a module
dividend = Signal(signed(8))
divisor  = Signal(8)
quotient = Signal(signed(8))
counter  = Signal(8)

m = Module()
m.d.comb += quotient.eq(dividend // divisor)
m.d.sync += counter.eq(counter + 1)

## write module to verilog
top = m
with open(f"{__file__[:-3]}.v", "w") as f:
    f.write(verilog.convert(top, ports=[dividend, divisor, quotient, counter]))

# simulate module in python
from nmigen.sim import Simulator
sim = Simulator(m)

def process():
    yield dividend.eq(-5)
    yield divisor.eq(2)
    for tick in range(2):
        yield

    print(f"quotient = {(yield quotient)}")

sim.add_clock(1e-6)
sim.add_sync_process(process)
sim.run()

sim_main.cpp
#include "Vdiv.h"
#include "verilated.h"
#include <iostream>
#include <iomanip>
#include <chrono>
#include <cstdint>

  // inspired heavily by code from:
  // https://veripool.org/guide/latest/example_cc.html#example-c-execution
  int main(int argc, char** argv, char** env) {
      VerilatedContext* contextp = new VerilatedContext;
      contextp->commandArgs(argc, argv);
      Vdiv* top = new Vdiv{contextp};

      top->dividend = 5;
      top->divisor = -2;

      top->clk = 0;
      for (int i = 0; i < 20; i++) {
	      top->clk = ~(top->clk);
	      top->eval();
      }

      printf("quotient = %hhd\n", top->quotient);

      delete top;
      delete contextp;
      return 0;
  }

It took me a minute or two to work out what is going on here: the same nMigen code evaluates differently in the nmigen simulator than it does in Verilator.

Yes. It's an issue with the emitted Verilog code, I believe; so not specific to Verilator.

Obviously up to you @whitequark what is canonical nMigen behavior.
But I'd argue that in this case, concerning negative integer division,
verilog's behavior seems a little more reasonable to me:
module arithmetic_operators();

initial begin
  $display (" -5  /  2 = %d", -5/2);
  #10 $finish;
end

endmodule

 -5  /  2 =          -2

negative integer division behavior in Python strikes me as less common

Obviously up to you @whitequark what is canonical nMigen behavior.

Consider the three snippets: Const(-5 / 2), Const(-5) / 2, and Const(-5) / Const(2). Do you think it is acceptable for any of them to evaluate to different values?

OK you got me. Probably not worth fighting Python itself about this.

Thanks for the report! This is now fixed by using the upstream Yosys support for flooring division and modulo operators, added in https://github.com/YosysHQ/yosys/pull/1885. As a result, Yosys >=0.10 is now required.


Isn'an Issue of Feature Request but a Question only

Does Drift saves windows positions/size between sessions? Also it's Account Wide or do I need to do it for every character? Thanks

Hi @Galthariel - good questions! Yes, Drift saves window positions and sizes between sessions. After you log out and back in again, the windows will re-open in the positions you left them in with the sizes you adjusted them to. Yes, the window positions and sizes are Account Wide; all characters share the same window positions and sizes.
Please feel free to re-open if you have any more questions!

I'm not only good but happy with your replies. Installing it NOW. Thanks a lot :-)


'return default' not parsing

Probably caused by my short-lived idea of a result  keyword. Now that that has been dropped (due to too many complications arising) we should return to:

recognising 'default' (without a type) as an option - for return statement only (not as a general substitute for an expression.)
Setting this as the default in the function frame. (So we will - in due course - be able to create a function stub from a usage, setting up default parameter names (a, b, c ...) and returning the default value.

Now fixed and tested - passing back in case you had anything to do in relation to this

After further review decided not to support this idiom.  A return statement will be created with an empty expression that must be provided by the programmer - and may take the form e.g.
return default Player


Create Portal-specific About page

Can we keep the Portal menu in the header on the About page, as well? A Phase 1 user reported: "After navigating to the "about" page, the menu selection disappears, so you can only leave the page with the browser's back button"

Phase 1 feedback from Meg: Create a Portal-specific About page

About page is created, pending more feedback on content. Will close for now.


pull request for e2e test at 12/20/2016 10:56:25

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[WIP] Appveyor install Android SDK API level 27

Motivation
We need to target latest Android SDK.
Description
AppVeyor image currently supports 26. We can wait for 27 or do it by ourselves.
Progress

[x] Script to install Android API level 27 sdk support
[ ] Get it working

is this really required, as of now?

@wei-lee The answer is its complicated.  API 27 is supposed to be in appveyor, but it isn't.  The app veyor forums suggest just managing the Android SDKs manually.  From a best practices standpoint Google encourages android developers to always compile against the latest Android SDK.

closing in favor of https://github.com/aerogear/aerogear-xamarin-sdk/pull/27


update node support to v7

I'm openning this to improve the node support to v7.

Update engine in package.json to support Node v7.
Update travis.yml  to run env Node v7.
Update appveyor.yml  to run env Node v7.
Update 01-installation.md adding Node  v7.

It closes the issue #2559

cc @dignifiedquire via #2559

Thank you :octocat:

Is there any way we can get a . release for this change @dignifiedquire ? Our install currently fails because of engine-strict set to true on node 7

I plan to do a release later tonight

landed in 1.5.0 - thanks @dignifiedquire


Pyreadline compatibility

Same as #229, only with less commits.

Coverage increased (+0.2%) to 86.913% when pulling f032457aa3a8f108759cbbc238ef0a88eb6712a3 on mbikovitsky:pyreadline_compatibility into d66ddb80fed4a620fb768526c445203dee8f02ce on quantmind:dev.

I trust you on this since I don't have a windows machine at the moment 😱
thanks


Queries to MusicBrainz with special characters

If a query to musicbrainz includes special characters, it returns an error 400. Need to remove it.

Have to check in detail, but it seems fixed upstream, in musicbrainz.


[v4.6.0] bug: ionInfinite not emitted

Bug Report
Ionic version:
[x] 4.x
Current behavior:
The ionInfinite event is never emitted when Ionic One is used. I observed this in a Stencil One PWA but others (see messages below) are reporting facing the same behavior in Angular apps.
<ion-infinite-scroll threshold="100px" id="infinite-scroll" onIonInfinite={($event) => console.log('Nothing happens')}>
          <ion-infinite-scroll-content>
          </ion-infinite-scroll-content>
        </ion-infinite-scroll>

Steps to reproduce:
I provide a super simple sample repo:
git clone https://github.com/peterpeterparker/infinite
cd infinite
npm install
npm run start

Try to scroll, ionInfinite will not be emitted
Related code:
See repo https://github.com/peterpeterparker/infinite
Other information:
"@ionic/core": "^4.6.0",
"@stencil/core": "^1.1.2"

Same problem in an Angular app: "@ionic/angular": "4.6.0"
ionInfinite event never emitted
  <ion-infinite-scroll threshold="100px" (ionInfinite)="loadData($event)">
    <ion-infinite-scroll-content
      loadingSpinner="bubbles"
      loadingText="Loading more data...">
    </ion-infinite-scroll-content>
  </ion-infinite-scroll>

Works fine with "@ionic/angular": "4.5.0"

+1.
And docs demo don't work too.
https://ionicframework.com/docs/api/infinite-scroll

That still work fine in v4.4.2, got error (not emitted) when upgrade to 4.5/4.6

Downgrade  "@ionic/angular": "4.5.0" works for me.
@quynh-ng this is my package.json.
{
  "name": "bible-miner-cli",
  "version": "0.0.1",
  "author": "Ionic Framework",
  "homepage": "https://ionicframework.com/",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },
  "private": true,
  "dependencies": {
    "@angular/common": "^7.2.2",
    "@angular/core": "^7.2.2",
    "@angular/forms": "^7.2.2",
    "@angular/http": "^7.2.2",
    "@angular/platform-browser": "^7.2.2",
    "@angular/platform-browser-dynamic": "^7.2.2",
    "@angular/router": "^7.2.2",
    "@ionic-native/core": "^5.0.0",
    "@ionic-native/splash-screen": "^5.0.0",
    "@ionic-native/status-bar": "^5.0.0",
    "@ionic/angular": "4.5.0",
    "cordova-android": "8.0.0",
    "core-js": "^2.5.4",
    "rxjs": "~6.5.1",
    "tslib": "^1.9.0",
    "zone.js": "~0.8.29"
  },
  "devDependencies": {
    "@angular-devkit/architect": "~0.13.8",
    "@angular-devkit/build-angular": "~0.13.8",
    "@angular-devkit/core": "~7.3.8",
    "@angular-devkit/schematics": "~7.3.8",
    "@angular/cli": "~7.3.8",
    "@angular/compiler": "~7.2.2",
    "@angular/compiler-cli": "~7.2.2",
    "@angular/language-service": "~7.2.2",
    "@ionic/angular-toolkit": "~1.5.1",
    "@ionic/lab": "2.0.4",
    "@types/jasmine": "~2.8.8",
    "@types/jasminewd2": "~2.0.3",
    "@types/node": "~12.0.0",
    "codelyzer": "~4.5.0",
    "cordova-plugin-device": "^2.0.2",
    "cordova-plugin-ionic-keyboard": "^2.1.3",
    "cordova-plugin-ionic-webview": "^4.1.1",
    "cordova-plugin-splashscreen": "^5.0.2",
    "cordova-plugin-statusbar": "^2.4.2",
    "cordova-plugin-whitelist": "^1.3.3",
    "jasmine-core": "~2.99.1",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~4.1.0",
    "karma-chrome-launcher": "~2.2.0",
    "karma-coverage-istanbul-reporter": "~2.0.1",
    "karma-jasmine": "~1.1.2",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.4.0",
    "ts-node": "~8.3.0",
    "tslint": "~5.17.0",
    "typescript": "~3.1.6"
  },
  "description": "An Ionic project",
  "cordova": {
    "plugins": {
      "cordova-plugin-whitelist": {},
      "cordova-plugin-statusbar": {},
      "cordova-plugin-device": {},
      "cordova-plugin-splashscreen": {},
      "cordova-plugin-ionic-webview": {
        "ANDROID_SUPPORT_ANNOTATIONS_VERSION": "27.+"
      },
      "cordova-plugin-ionic-keyboard": {}
    },
    "platforms": [
      "android"
    ]
  }
}

I'm honestly not sure what changed, but I submitted a PR that fixes it
https://github.com/ionic-team/ionic/pull/18647

Version 4.5.0 works fine, seems a massive upgrade to Stencil One which happened in version 4.6.0 caused the issue.

same issue here

Downgrade  "@ionic/angular": "4.5.0" works for me.
@quynh-ng this is my package.json.
{
  "name": "bible-miner-cli",
  "version": "0.0.1",
  "author": "Ionic Framework",
  "homepage": "https://ionicframework.com/",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },
  "private": true,
  "dependencies": {
    "@angular/common": "^7.2.2",
    "@angular/core": "^7.2.2",
    "@angular/forms": "^7.2.2",
    "@angular/http": "^7.2.2",
    "@angular/platform-browser": "^7.2.2",
    "@angular/platform-browser-dynamic": "^7.2.2",
    "@angular/router": "^7.2.2",
    "@ionic-native/core": "^5.0.0",
    "@ionic-native/splash-screen": "^5.0.0",
    "@ionic-native/status-bar": "^5.0.0",
    "@ionic/angular": "4.5.0",
    "cordova-android": "8.0.0",
    "core-js": "^2.5.4",
    "rxjs": "~6.5.1",
    "tslib": "^1.9.0",
    "zone.js": "~0.8.29"
  },
  "devDependencies": {
    "@angular-devkit/architect": "~0.13.8",
    "@angular-devkit/build-angular": "~0.13.8",
    "@angular-devkit/core": "~7.3.8",
    "@angular-devkit/schematics": "~7.3.8",
    "@angular/cli": "~7.3.8",
    "@angular/compiler": "~7.2.2",
    "@angular/compiler-cli": "~7.2.2",
    "@angular/language-service": "~7.2.2",
    "@ionic/angular-toolkit": "~1.5.1",
    "@ionic/lab": "2.0.4",
    "@types/jasmine": "~2.8.8",
    "@types/jasminewd2": "~2.0.3",
    "@types/node": "~12.0.0",
    "codelyzer": "~4.5.0",
    "cordova-plugin-device": "^2.0.2",
    "cordova-plugin-ionic-keyboard": "^2.1.3",
    "cordova-plugin-ionic-webview": "^4.1.1",
    "cordova-plugin-splashscreen": "^5.0.2",
    "cordova-plugin-statusbar": "^2.4.2",
    "cordova-plugin-whitelist": "^1.3.3",
    "jasmine-core": "~2.99.1",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~4.1.0",
    "karma-chrome-launcher": "~2.2.0",
    "karma-coverage-istanbul-reporter": "~2.0.1",
    "karma-jasmine": "~1.1.2",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.4.0",
    "ts-node": "~8.3.0",
    "tslint": "~5.17.0",
    "typescript": "~3.1.6"
  },
  "description": "An Ionic project",
  "cordova": {
    "plugins": {
      "cordova-plugin-whitelist": {},
      "cordova-plugin-statusbar": {},
      "cordova-plugin-device": {},
      "cordova-plugin-splashscreen": {},
      "cordova-plugin-ionic-webview": {
        "ANDROID_SUPPORT_ANNOTATIONS_VERSION": "27.+"
      },
      "cordova-plugin-ionic-keyboard": {}
    },
    "platforms": [
      "android"
    ]
  }
}

this package.json is wrok for me, thx

Downgrading @ionic/angular version from 4.6.0 to 4.5.0 fixed it for me too.

Guys... we get it. It works in 4.5.0.
It would be great to hear what the actual regression was

Agree.
Also note, as stated in the issue I opened, I'm building a PWA using Stencil One, therefore a downgrade isn't really a solution as I would have to downgrade both Stencil and my app too.

When fixing this, maybe you can also take this in consideration: https://github.com/ionic-team/ionic/issues/18653
Especially the "Additional Information" part (last paragraph).

Thanks for the issue! I am going to close this as it has been fixed in Stencil, it will be in the 4.6.1 hotfix release. Please follow #18655 for updates on this. 🙂


Added Rim station take 2

About the PR

Added Rim station a small ish map for 60 players. My map has lots of nice hiding spots and areas for roleplay.
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog
:cl:

add: Added Rim station

remove fix part from cl

i think you really should read some docs about using github, and then do prs

remove fix part from cl

Fixed

you have some commits that don't supposed to be here

Ya I fixed that reverting the edits I made by mistake from before. The files being added are the map and prototype

i think you really should read some docs about using github, and then do prs

The map and prototype file are included, I don't see the issue. I am not a computer science major

Your random changes, found here, should be atomized (Moved) to a separate PR if you wish for them to be added, though it seems like these changes are "change for change sake", but that is an entirely seperate discussion. To my understanding you seem to be using github desktop, you can revert commits to your branch, if need be, relatively easily by:

Navigating to your history tab for your respective branch, in this case Starbuckss14:master.
Finding the respective commit(s) that have caused this issue.
Right clicking and pressing Revert Changes In Commit
You will then have to push your revert(s) to origin (your primary branch you are working on.)

In the future, I suggest creating a new branch on github desktop for any projects you may be undertaking. Currently you are pushing any and all changes to your personal repository to this PR. Create a branch with you relevant map files, and then PR that.

Ok Thank you so much for your help! This fixed the issue! Very based as one might say!

I am happy to report that I have fixed the issue! special thanks to PursuitInAshes!

This PR is getting closed! The map Rim will remain on my pc if I come back to it or if anyone wants to take over the project. I switched work to my new asteroid map "Phobos." Below are some teasers!


Implement redirects from old URLs

/Orders/* redirects to /*

This may be too complicated to be worth the effort.

Reopening: Broken links reported by Kevin on the EPD website


Improve " not  implemented yet" error output to indicate if it's a missing scope or missing language

I'm testing adding new language support and I have one scope type (comment) supported, so if I say take comment it works fine. However, if I try to use any other syntactic scope it says roughly language 'nix' not supported. My thinking is it would be clearer in a case where the language is partially supported to instead say something like scope 'x' not yet supported for language 'nix'. This would be less confusing to the user and may also help with development a bit (assuming underlying scope names differ from spoken form sometimes).

I just realized if you use visualize command for an unimplemented scope type, it explicitly says that the scope isn't supported for that language. I guess having consistency between the two commands will be good, and probably easier since the error already exists.


Rename Cluster Template to RKE Template for 2.4

To mitigate confusion in 2.3, we are going to call the current implementation of cluster templates RKE Templates.
To accomplish this, we will:

Rename cluster template to RKE Template in the UI.
Move the “Cluster Template” create button off the create cluster page.
Move “Cluster Template” item from the user menu to the Tools menu in global as “RKE Template”.

As cluster templates are expanded in scope and functionality, the RKE Template will be renamed back to cluster template in 2.4.

Rancher version: master-head (v2.3) (09/04/2019)
I was able to verify the requirements are met in the latest 2.3 build from today as expected:

Rename cluster template to RKE Template in the UI.
Move the “Cluster Template” create button off the create cluster page.
Move “Cluster Template” item from the user menu to the Tools menu in global as “RKE Template”.

Navigating is also without issues.
But only thing is that "RKE Template" is plural in the implementation "RKE Templates" but I think it makes sense.

Documentation has a separate issue for updates.


Initial spot instance support

This isn't a final pull request but more a point to begin discussion. It works successfully in us-west-2 and us-east-1.
When you make a spot instance request for N machines, this might result in up to N "reservations" for some number of machines (such that the total is the size of your spot request). Hence having to aggregate the results a bit - both types now contribute to an all_instances variable.
@nchammas is this what you were thinking? Any feedback?

The general approach here seems fine to me. I'll go through and give specific feedback.

Thanks for taking a crack at this! I left some specific feedback. My main concern is about the complexity of the main loop to wait for the spot instances. Otherwise, I think we can get this in for Flintrock's initial release.
By the way, you need to pull the latest changes into your fork. You're missing some changes I introduced yesterday which you'll need to remove.

Thanks for these latest changes @ericmjonas! The PR looks much better. I went through again and left more comments, which you are already responding to (sweet!). Basically, I still think we can greatly simplify the logic for waiting on the spot requests, but otherwise this is shaping up nicely.
A few notes to myself for the future:

When we upgrade to boto3 (#22) we can probably replace the custom spot request wait logic entirely with EC2.Waiter.SpotInstanceRequestFulfilled.
It would be nice in the future to replace the repeated print statements in the spot request wait loop with a progress bar (like proposed in #27) or a simple spinner.

@nchammas I think I messed up on my attempt to rebase to your master and now for some reason my tree is really ugly. I could try fixing but I'm guessing that we'll just squash the entire commit hist for the eventual final PR?

Yeah, before merging the PR I'll ask you to squash it into one commit. Don't worry about it for now.
By the way, the way I've pulled in changes to personal forks in the past is simple.  Sorry Eric, I missed the fact that you submitted some updates yesterday. I just went through and made another round of comments.

I'm having a little trouble applying this patch locally so I can test it out. Is it working for you in this state?

Can you add "Fixes #30." to the PR description, by the way? That way when we merge this PR in GitHub will automatically close the issue for us.

@ericmjonas, if you're ready, I think now's a good time to squash these commits into one. If you need help doing that, pop in to the Flintrock Gitter room and I'll help you out. Once we have that done I think I can merge this in!

Alright, I tested this out and it looks good to me. There's an issue with the exception handling, but that's OK. I'll pull your changes in to a new PR and clean that up along with some minor style issues and get this merged in.
Thanks for working on this!


Manual cherrypick of #20852 to release/3.9

What this PR does / why we need it:

Does this PR need to be backport to the previous release branch?:

https://github.com/yunionio/cloudpods/pull/20852

/lgtm


Cant get ore slurry out of chemical dissolution chamber

I looked up how to transport slurry and it said pressurized tubes but for me they dont work.

Sounds like you're using an old version of Mekanism, this was a bug. Update and things should work fine.


Unable to set "Sync hub Permissions to associated sites"

There is no method to "sync hub permissions to associated sites". The option isn't enabled when you register a hub site via PowerShell, and there is no method to throw this switch programmatically.
Here is the setting in the GUI:
Sync Hub Permissions
Set-PnpHubSite does not have the option, which is where I expected it to be.

Hello, have added the capability.
Will be available in tomorrow's nightly.
You can use it as to enable permissions sync:
Set-PnPHubSite -Identity "https://tenant.sharepoint.com/sites/myhubsite" -EnablePermissionsSync

To disable permissions sync:
Set-PnPHubSite -Identity "https://tenant.sharepoint.com/sites/myhubsite" -EnablePermissionsSync:$false


Parser

CI will not work for this branch, due to workflow in django branch. But I ran tests locally and give you result below:


add apps from CCO project

I remember there were two apps related to https://forum.solidproject.org/t/common-core-ontology-with-linked-data/1860/2, one of them being a calendar app, I think? Trying to remember the URLs.

cc @JKReynolds, I think you were the main author of those apps?

See also https://github.com/solid/vocab/issues/42#issuecomment-557464316

See https://github.com/solid/solid.github.io/pull/213 where I had a go at incorporating the issue. If there's anything missing, submit a pull request on https://github.com/solid/solid.github.io/blob/master/pages/use-solid/apps.md


Support for ARM64

Hi there,
I tried to build this on an ARM64 board but couldn't get it building due to "unsupported platform" within the coroutines section. link
I've done some tinkering with boost context on ARM64 and it seems to work, is there a possibility of using that or something else?

On ARM/ARM64 you need to build HPX using Boost.Context. Please add -DHPX_WITH_GENERIC_CONTEXT_COROUTINES=ON to the cmake command line.

oh that's convenient ^_^

issue with timestamps too


Use C++11 delegating constructors

There are numerous places where we did ugly stuff to make it possible to share code amongst constructors of a class.  In C++11 we can use delegating constructors.  e.g.
class Foo { public:    Foo(char x, int y) {}   Foo(int y) : Foo('a', y) {} };

Jamoma2


Azure DevOps for generated project

Add azure-pipelines.yaml and instructions for configuring CI for generated projects

Closed by #17


Remove escape for meta description.

This is not required since all meta tags are escaped in django-meta.
Description
See description of corresponding issue.
References
Fix #699
Checklist

[x] I have read the contribution guide
[x] Code lint checked via inv lint__ summary __
pep8: commands succeeded
isort: commands succeeded
black: commands succeeded
pypi-description: commands succeeded
congratulations :)

[x] changes file included (see docs)
[ ] ~Usage documentation added in case of new features~
[ ] ~Tests added~

Thanks @corentinbettiol for your contribution. I will merge this as soon as i have github actions back up and running

Thanks your contribution @corentinbettiol , I merged this with #726 to ease porting to updated develop branch

Thanks for merging it!


fixes #8915

changed link to https://github.com/fastlane/examples instead of https://github.com/fastlane/setups/blob/master/samples-ios/distribute-beta-build.md

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Description

Motivation and Context

Also please change the title of the PR

Added a new PR for this https://github.com/fastlane/fastlane/pull/9264


Ignore URLs with custom protocols

Fixes #177
Fixes #152
Closes #153
Breaking changes:

ftp is no longer supported.

An option can be added where users can provide custom protocols they want normalized.

You can no longer pass in a human-friendly URL with auth<EMAIL_ADDRESS>
This should be fine as basic auth in URL is deprecated anyway.

// @daKmoR

@sindresorhus awesome 🤗 thank you 🙇♂
I tested it and it now works exactly as expected in these situations 💪
which means once this is released I can get rid of my workarounds 😍

@daKmoR https://github.com/sindresorhus/normalize-url/releases/tag/v8.0.0


Create 1.md

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset1/1.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset1/1.md
:white_check_mark:Succeeded
View

docset1/2.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset1/1.md
:white_check_mark:Succeeded
View

docset1/2.md
:white_check_mark:Succeeded
View

docset1/3.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset1/1.md
:white_check_mark:Succeeded
View

docset1/2.md
:white_check_mark:Succeeded
View

docset1/3.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset1/1.md
:white_check_mark:Succeeded
View

docset1/2.md
:white_check_mark:Succeeded
View

docset1/3.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


example output should not be required

When omitted, the output line should not be displayed

Fixed in v1.0.1: #7


Integrated VirtualDesktop-OpenXR works fine with Link but not with OpenKneeboard

I tried the new VirtualDesktop OpenXR runtime in VD and it's great!
Thank you very much for your work!
Within DCS I've 10 - 15% more performance.
Contrary to the documentation, it also works great with Oculus Link. At least with DCS.
Only OpenKneeboard is no longer displayed.
Will OpenKneeboard work again if I switch to the standalone version?
Unfortunately I can't find any installation instructions for the standalone version.
Keep up the great work and Merry Christmas to you.

I can't find any release for the standalone version.
Maybe it is distributed in the Discord.
I would be happy to be a beta tester.

The version shipped with Virtual Desktop does not work with Link. The reason your not getting OpenKneeboard is nost likely because DCS fails to start up in OpenXR mode, and falls back to another mode where VDXR is not used at all.
The Standalone version is canceled due to lack of time and resources.  I'll remove the mention from the page entirely.


Build Error - Cannot subscript a value of type '[UIImagePickerController.InfoKey : Any]' with an index of type 'String'

Im getting the error bellow when build on iOS 12 beta, Xcode 10
Cannot subscript a value of type '[UIImagePickerController.InfoKey : Any]' with an index of type 'String'
Any clue what could be wrong?

On this line of code...
let editedImage = info[convertFromUIImagePickerControllerInfoKey(UIImagePickerController.InfoKey.editedImage)] as? UIImage
guard let image = editedImage, let ciImage = CIImage(image: image) else {
  print("Can't analyze selected photo")
  return
}


[feature request] graphing BGP route count

show how many BGP sessions are configured with an ASN and how many of them are up
show graph of routes received and routes filtered

example
http://bgp.as30071.net/AS714

Hi @yang-dev - while that's an interesting feature, I'm afraid it is out side the scope of what we consider appropriate for Birdseye right now.
This kind if information can easily be graphed using tools such as Graphite from the data Birdseye provides.


Hello

Do you need more supporters? We could create an organization among sexual minorities for mutual support. We can build our own online platform without using any Chinese social networks. If needed I can also support the development for the system. I believe our World of Colors will never perish and certainly will revitalize!

你上过去年北大编译课是吧？

简简单单开个盒

Do both of you come from CECA?

Can u speak Chinese？

你认识罗国杰吗？


fetchStripeSignature doesn't work well in a highly concurrent scenario

Describe the bug
We have an app that does quite a few requests on load. Each requests needs to call fetchStripeSignature to get the signature to send to the server. Some of the calls are made very concurrently.
It seems like (at least in development) that when the calls to fetchStripeSignature are to quick, we just get stuck on await and it never returns.
To solve this we've had to add a "sleep" based on the number of pending requests so to not call fetchStripeSignature to quickly.
Expected behavior
That it is possible to call await fetchStripeSignature on each request without having to either cache the signature or implement "sleep"-patterns.

Thanks for the report. We also became aware of this issue internally, and we're working on a fix. ETA is TBD, but it's definitely on our radar and not intended.


ci: simplify the os matrix

:tada: This PR is included in version 0.2.11 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Fix test_svd_property_leading_ones

Description
Fixes #226 by correcting test_svd_property_leading_ones. tensor.T reverses all dimensions of a tensor, while tensor.mT only transposes the last 2 (which is what we want here). https://pytorch.org/docs/stable/tensors.html#torch.Tensor.mT
Type of change

[x ] Bug fix

Checklist:

[x ] My changes generate no new warnings
[x ] I have added tests that prove my fix is effective or that my feature works
[x ] New and existing unit tests pass locally with my changes
[x ] I have not rewritten tests relating to key interfaces which would affect backward compatibility

oh good catch.


global: release v1.4.0

Depends on:

#349
#346
#345
#325

https://invenio.readthedocs.io/en/master/community/contributing/maintainers-guide/releasing.html#module-release

This depends on 4 issues, However the #345 has been set as a "nice to have" in the sprint. Is it blocking? Or can the release go anyway?


Bump submariner to 0.15.0-rc0

/cc @skitt

This is failing because of the status update changes in Admiral. We can fix it either by populating the default scheme, or waiting for the upstream fix to be backported to the 0.15 branch and updating to that.

This is failing because of the status update changes in Admiral. We can fix it either by populating the default scheme, or waiting for the upstream fix to be backported to the 0.15 branch and updating to that.

Just need another approval on https://github.com/submariner-io/admiral/pull/593.  @vthapar @sridhargaddam @aswinsuryan

/approve
/lgtm


metadata refresh is really expensive!

I am using scylla-rust-driver as the driver in a cassandra benchmark.
When that benchmark reaches 60s passed, throughput roughly halves for a few seconds and I have tracked this down to the metadata refresh.
I am able to eliminate the loss in throughput by changing this to a very large number : https://github.com/scylladb/scylla-rust-driver/blob/4efc84dfbc7bb204b49a8564378537e35cfe3ad1/scylla/src/transport/cluster.rs#L485`
I would like to raise two issues as a result:
issue 1
The metadata refresh should be made more performant.
I did a quick investigation and found it was MetadataReader::read_metadata that was impacting throughput.
The atomic swapping of metadata results seems to be working fine as removing the swap did not improve throughput in anyway.
I'm not sure if the cause is cassandra slowing down, the client slowing down due to running queries or the client slowing down due to processing results of queries, or a combination of these or something else entirely.
So I think it would be a good idea for the scylla-rust-driver team to give this a thorough investigation as it seems like this would cause a dip in production performance every 60s.
However for the needs of my project I think all I will need is what I describe in issue 2
issue 2
We need a way to disable and/or change the timing of the metadata refresh.
As I am writing a benchmark from which I can guarantee no other client is altering the schema or topology, I would like a way to completely disable such background work so I can evaluate the average throughput alone.

Hi @rukai There is a PR active to manually set the topology refresh interval.
https://github.com/scylladb/scylla-rust-driver/pull/776

Oh, sorry for duplicating your pr, I'll go ahead and close mine.
It would make semantic sense to be able to set None in order to completely disable the refresh but I can always just set the value to 1000000 for effectively the same result.

@rukai Could you describe the setup of your benchmark in more detail?
I'm not able to reproduce the throughput dip around 60s. For my testing, I'm using cql-stress which uses Rust Driver, ./target/release/cql-stress-scylla-bench -mode write -workload sequential -nodes "<IP_ADDRESS>:9042" --partition-count 1000000. I tried it with both Scylla 5.4.0 (master) and Cassandra 3.11.15 and I don't see a throughput dip:

 Logs
$ ./target/release/cql-stress-scylla-bench -mode write -workload sequential -nodes "<IP_ADDRESS>:9042" --partition-count 1000000
Configuration
Mode:			 write
Workload:		 sequential
Timeout:		 5.0s
Consistency level:	 quorum
Partition count:	 1000000
Clustering rows:	 100
Clustering row size:	 Fixed(4)
Rows per request:	 1
Page size:		 1000
Concurrency:		 16
Maximum rate:		 unlimited
Client compression:	 true
time        ops/s  rows/s errors    max 99.9th   99th   95th   90th median   mean
1.0s        62790   62790      0 1.60ms  716μs  442μs  354μs  326μs  248μs  254μs
2.0s        70961   70961      0 36.1ms  549μs  322μs  290μs  274μs  214μs  225μs
3.0s        70589   70589      0 30.9ms  424μs  331μs  295μs  278μs  217μs  226μs
4.0s        70173   70173      0 22.7ms  414μs  331μs  297μs  280μs  220μs  227μs
5.0s        71800   71800      0 23.7ms  934μs  396μs  291μs  272μs  212μs  222μs
6.0s        74249   74249      0 1.95ms  412μs  317μs  287μs  271μs  212μs  215μs
7.0s        71489   71489      0 29.4ms  351μs  316μs  288μs  273μs  215μs  223μs
8.0s        75378   75378      0  718μs  349μs  313μs  284μs  268μs  209μs  211μs
9.0s        71557   71557      0 36.0ms  820μs  337μs  287μs  271μs  211μs  223μs
10.0s       72476   72476      0 35.0ms  388μs  315μs  284μs  269μs  210μs  220μs
11.0s       74803   74803      0 1.46ms  358μs  313μs  284μs  269μs  211μs  213μs
12.0s       72413   72413      0 34.3ms  369μs  319μs  287μs  270μs  210μs  220μs
13.0s       74634   74634      0 1.24ms  359μs  314μs  285μs  270μs  212μs  213μs
14.0s       71706   71706      0 35.6ms  370μs  316μs  287μs  272μs  213μs  222μs
15.0s       71063   71063      0 34.0ms  755μs  346μs  290μs  273μs  213μs  224μs
16.0s       73064   73064      0 1.45ms  397μs  323μs  292μs  276μs  216μs  218μs
17.0s       72503   72503      0 33.4ms  368μs  316μs  285μs  270μs  210μs  220μs
18.0s       73485   73485      0 1.34ms  352μs  316μs  287μs  272μs  213μs  214μs
19.0s       71586   71586      0 34.8ms  411μs  332μs  294μs  276μs  215μs  225μs
20.0s       70933   70933      0 34.2ms  547μs  327μs  290μs  274μs  214μs  225μs
21.0s       72102   72102      0  515μs  375μs  325μs  296μs  281μs  219μs  221μs
22.0s       70153   70153      0 32.6ms  880μs  338μs  295μs  278μs  216μs  227μs
23.0s       72741   72741      0 1.35ms  352μs  311μs  284μs  270μs  211μs  213μs
24.0s       71337   71337      0 34.5ms  403μs  329μs  297μs  281μs  220μs  230μs
25.0s       71712   71712      0 35.0ms  378μs  317μs  288μs  272μs  212μs  222μs
26.0s       73984   73984      0 1.85ms  463μs  323μs  290μs  273μs  213μs  215μs
27.0s       72069   72069      0 35.8ms  366μs  316μs  285μs  270μs  212μs  221μs
28.0s       72660   72660      0 34.0ms  354μs  312μs  283μs  268μs  210μs  219μs
29.0s       72374   72374      0 1.59ms  870μs  344μs  292μs  276μs  216μs  220μs
30.0s       72031   72031      0 33.9ms  375μs  319μs  288μs  271μs  212μs  221μs
31.0s       74030   74030      0 1.84ms  488μs  326μs  289μs  273μs  212μs  215μs
32.0s       72400   72400      0 33.3ms  369μs  315μs  285μs  270μs  210μs  220μs
33.0s       71191   71191      0 34.8ms  382μs  322μs  290μs  274μs  214μs  224μs
34.0s       73433   73433      0  573μs  349μs  316μs  289μs  274μs  215μs  217μs
35.0s       70170   70170      0 37.4ms  781μs  347μs  293μs  276μs  215μs  227μs
36.0s       73203   73203      0 1.36ms  356μs  318μs  290μs  275μs  216μs  218μs
37.0s       71726   71726      0 34.5ms  440μs  319μs  286μs  271μs  213μs  222μs
38.0s       70500   70500      0 34.3ms  373μs  324μs  292μs  276μs  217μs  226μs
39.0s       74087   74087      0 1.43ms  367μs  319μs  288μs  272μs  213μs  215μs
40.0s       68335   68335      0 35.3ms  403μs  338μs  302μs  285μs  223μs  233μs
41.0s       68565   68565      0 27.1ms  412μs  336μs  302μs  286μs  225μs  232μs
42.0s       70874   70874      0 22.8ms 1.15ms  482μs  294μs  275μs  212μs  225μs
43.0s       71805   71805      0 28.0ms  471μs  322μs  289μs  273μs  214μs  222μs
44.0s       73421   73421      0 1.39ms  384μs  328μs  293μs  276μs  215μs  217μs
45.0s       72422   72422      0 33.7ms  361μs  314μs  285μs  269μs  211μs  220μs
46.0s       74150   74150      0 3.16ms  384μs  315μs  287μs  272μs  212μs  215μs
47.0s       72288   72288      0 35.0ms  368μs  313μs  284μs  269μs  211μs  220μs
48.0s       71578   71578      0 33.5ms  361μs  317μs  287μs  272μs  214μs  223μs
49.0s       73275   73275      0 2.47ms  880μs  333μs  290μs  273μs  213μs  217μs
50.0s       71695   71695      0 33.4ms  360μs  314μs  286μs  271μs  213μs  222μs
51.0s       74182   74182      0 1.34ms  356μs  316μs  288μs  272μs  213μs  215μs
52.0s       71606   71606      0 34.6ms  369μs  319μs  289μs  273μs  213μs  223μs
53.0s       72331   72331      0 36.0ms  360μs  313μs  284μs  268μs  211μs  220μs
54.0s       73054   73054      0  679μs  405μs  322μs  291μs  276μs  216μs  218μs
55.0s       70644   70644      0 34.3ms  686μs  346μs  292μs  275μs  213μs  226μs
56.0s       71554   71554      0 33.2ms  674μs  319μs  289μs  273μs  213μs  223μs
57.0s       74404   74404      0 1.30ms  351μs  314μs  286μs  271μs  212μs  214μs
58.0s       71700   71700      0 33.1ms  375μs  318μs  288μs  273μs  213μs  222μs
59.0s       72182   72182      0 1.68ms  384μs  326μs  296μs  280μs  219μs  221μs
1m0.0s      71219   71219      0 32.2ms  433μs  323μs  290μs  274μs  214μs  224μs
1m1.0s      71140   71140      0 33.2ms  379μs  319μs  289μs  274μs  215μs  224μs
1m2.0s      72428   72428      0 5.56ms  886μs  342μs  294μs  277μs  216μs  220μs
1m3.0s      71487   71487      0 32.4ms  373μs  322μs  289μs  273μs  214μs  223μs
1m4.0s      72515   72515      0 1.54ms  368μs  323μs  294μs  278μs  218μs  220μs
1m5.0s      71244   71244      0 32.8ms  388μs  327μs  292μs  276μs  214μs  224μs
1m6.0s      71459   71459      0 35.3ms  388μs  319μs  289μs  273μs  213μs  223μs
1m7.0s      73278   73278      0 1.30ms  380μs  322μs  292μs  276μs  215μs  217μs
1m8.0s      71029   71029      0 33.5ms  761μs  338μs  291μs  274μs  213μs  224μs

I tested my bencher again and observed that it doesnt happen locally, only when run on AWS.
Maybe the smaller node size, or the extra latency is the cause?
But I'll do some more investigation myself, when I get the chance.
I have a 3 node cassandra cluster running on 3 aws m6a.large instances
I have a bencher running on aws m6a.large instance.
You should be able to reproduce with:
git clone https://github.com/shotover/shotover-proxy
cd shotover-proxy
cargo windsock --cloud --name cassandra,compression=none,driver=scylla,operation=write_blob,protocol=v4,shotover=none,topology=cluster3 --bench-length-seconds 60

BIG WARNING THOUGH: this will create amazon EC2 instances if you have AWS credentials setup on your machine.
It will attempt to clean up after itself but you should make sure that it succeeds, possibly running cargo windsock --cleanup-cloud-resources to force a cleanup if it panics midway through.
If that sounds scary, fair enough, maybe just setup your own bench manually on cloud infrastructure and see if you can reproduce that way.
The throughput drop happens at about 42s into the bench since the driver is started before benching starts.


Conductor connect to ElasticSearch failed: NoNodeAvailableException

Conductor connect to ElasticSearch Transport (9300) failed:
NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{m1YURNHMTKuoleRuLnBexQ}{es.domain.com}{xxx.xxxx.xxx.xxx:9300}]]
	at org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:347)
	at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:245)
	at org.elasticsearch.client.transport.TransportProxyClient.execute(TransportProxyClient.java:59)
	at org.elasticsearch.client.transport.TransportClient.doExecute(TransportClient.java:366)
	at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:408)
	at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:730)
	at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:80)
	at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:54)
	at com.netflix.conductor.dao.es5.index.ElasticSearchDAOV5.setup(ElasticSearchDAOV5.java:152)
	at com.netflix.conductor.bootstrap.Main.main(Main.java:71)

ElasticSearch's 9300 port is listening and can established from conductor's host.

You should set the value of client.transport.sniff to false when using Java clients to communicate with Huawei Cloud's ElasticSearch.
Huawei Cloud's ElasticSearch is listening on private IP address which you could not communicate with it directly, the IP addresses you got from the Console is not real IP used by backend services.
Conductor is unable to communicate with the auto-discoveried private IP addresses when the sniff toggle is on.


feature: linter for time

Hello, before I start making pull requests, I would like to know if checking for preferred time formats that follow the Editing Guidelines would be desirable? This way, most time format errors would be caught early and not later corrected in the future.

Sure https://github.com/Hakanaou/deepLuna/commit/d37afeac374adcb535cc0910e4a53cd99b4348e7


Cannot read properties of undefined (reading 'new')

Hello.
I use this library for Flutter Web.
static Client createRemoteClient(Credentials credentials) {
  var dio = WdDio(debug: true); // Exception
  final client = Client(
    uri: credentials.site,
    c: dio,
    auth: BasicAuth(user: credentials.login, pwd: credentials.password),
  );
  return client;
}

When trying to run this code on the Web in Chrome, I get
Launching lib/main.dart on Chrome in debug mode...
This app is linked to the debug service: ws://<IP_ADDRESS>:51580/iWU1AuUZTag=/ws
Debug service listening on ws://<IP_ADDRESS>:51580/iWU1AuUZTag=/ws
Connecting to VM Service at ws://<IP_ADDRESS>:51580/iWU1AuUZTag=/ws
Connected to the VM Service.
TypeError: Cannot read properties of undefined (reading 'new')
packages/webdav_client/src/adapter/adapter_web.dart 4:35 getAdapter
packages/webdav_client/src/webdav_dio.dart 38:25 new
packages/ble_updater_configurator/api/services/webdav/webdav_update_service_helper.dart 21:15 createRe moteClient
Exited.

This code works on ios and android.

If I call the code like this, WdDio will be initialized.
//tmp will not use
var tmp = BrowserHttpClientAdapter();
var dio = WdDio();

But when trying to make a request, for example:
await _client.readDir("path");
I get an error:
DartError: DioException [connection error]: The connection errored: The XMLHttpRequest onError callback was called. This typically indicates an error on the network layer. This indicates an error which most likely cannot be solved by the library.


Okay I finally found some time to look into this.

Okay I finally found some time to look into this.
You're indeed correct that the error seems to stem from the MockMvcWebClientBuilder from Spring. To be honest I'm not to familiar with the MockMvcWebClientBuilder. The problem seems to be what we're seeing here:
The FormData / RequestBody is not correctly put in to the @RequestParam parameters in the Controller.
Therefore the request fails with 400 Bad Request.
I'm having some difficulties debugging the Spring test code ... however I think the issue comes from HtmlUnitRequestBuilder.content():
This one takes the request body without any escaping and passes it to the controller:
	private void content(MockHttpServletRequest request, Charset charset) {
		String requestBody = this.webRequest.getRequestBody();
		if (requestBody == null) {
			return;
		}
		request.setContent(requestBody.getBytes(charset)); //requestBody = 'subject test message test'
		//requestBody should be: 'subject=subject+test&message=message+test' since it's form encoded.
	}

To get to the results I've transformed the project to use SpringBoot since it was easier for me to find out what's actually happening and where the error potentially is. I hope that it's running with gradle ... since I needed to convert it to a maven project because of my gradle issue 👼
The project is here: https://github.com/twendelmuth/spring-test-htmlunit
Added tests that should illustrate what's wrong: https://github.com/twendelmuth/spring-test-htmlunit/tree/master/src/test/java/spring/test/htmlunit/controller
And more specific: https://github.com/twendelmuth/spring-test-htmlunit/blob/master/src/test/java/spring/test/htmlunit/controller/WelcomeControllerMockMvc.java#L37 - this is what's happening in the end in your test.
I hope this helps :-)
Originally posted by @twendelmuth in https://github.com/HtmlUnit/htmlunit/issues/223#issuecomment-695139395

error, sorry


[Bug]: Application is randomly throwing 'Cannot read properties of undefined' toast on navigating from Deploy to Edit page

Is there an existing issue for this?

[X] I have searched the existing issues

Description
This issue is observed in CI , where on navigating from deploy page to edit page, application is throwing Cannot read properties of undefined (reading 'responseMeta') error toast:

Steps To Reproduce

Login to Appsmith
Create an app
Publish the app
Navigate back to edit page

Public Sample App
No response
Environment
Release
Issue video log
https://github.com/appsmithorg/appsmith/assets/119562824/eb64a836-9ade-4e2f-8632-40d9248d5e80
Version
Self hosted

Recent run with above failure - Logs

Recent run with above failure - Logs

Recent run with above failure

@somangshu we don't know the root cause yet, Please feel free to re-assign this to relevant folks

Recent run logs

@somangshu - We are seeing this when navigating from View Mode to Edit page. So we thought it was App viewers. Can you please let know whom should we re-assign this to instead?

@Aishwarya-U-R @Vijetha-Kaja to debug the problem better can you help me understand the reproducible steps from the cypress test that is failing.
I tried doing it, but did not succeed.
My understanding is that the application crashes, cause I dont see any of the elements load on the canvas. Maybe something to with the canvas in that case.
cc @marks0351 any idea?

Recent run error logs reference - for There was an unexpected error toast.

Recent run with above failure

Recent run - There was an unexpected error - when navigating from Edit to Deploy page:

This seems to be happening on CI only. If there are reproducible steps this can be picked up. To debug these failures on CI we will need more info like network logs and console logs. https://github.com/appsmithorg/appsmith/issues/26006

Recent run with above failure

Adding logs from recent run
dockerlogs (2).zip

Another run failure with logs
dockerlogs (2).zip

Another run failure with logs
dockerlogs (2).zip

Another failure run
docker_logs.zip

Another failure run with logs
dockerlogs.zip

Another latest failing run with logs
dockerlogs.zip

Multiple specs failing with sidebar not visible & app not loading with empty toast - Run1
Run2  with logs
dockerlogs.zip

Side bar not loaded run issue with emtpy toast & logs
dockerlogs (1).zip

Recent run with this fialure after logs added
cypress-console-logs (1).zip

@Aishwarya-U-R As mentioned earlier I think it's better close this issue, the loading issue is tracked in https://github.com/appsmithorg/appsmith/issues/27489 for clarity.
Closing this let me know if you have any concerns.

@akash-codemonk - what you have created is a task that will account for fixing this. This bug cannot be closed - until the bug itself is addressed.

One more recent Internal server error run & logs & logs attached.
dockerlogs.zip

Recent run with logs
cypress-console-logs (2).zip

Anothe run with logs attached.
cypress-console-logs (3).zip

Latest with instance failures at 22 & 42

Latest at instance 33 tests CheckBoxGroupTest.ts, TableV1/Table_spec.js, TableV2/TableV2_Switch_spec.js, Text/Text_truncate_spec.js

This PR is fixed now, any other error toasts in Applications will be tracked separately.


Resize image | IMAGE_URL =WIDTHxHEIGHT is not working

Resizing an image in DevOps wiki is not working as documented here :
![Image alt text]($/project/folder/media/markdown-guidance/image.png =500x250) Adding "=500X200" is not displaying the image anymore.

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

ID: fa622358-f5bb-1f5c-177a-081a37b6acef
Version Independent ID: 72f7fd16-a822-66c8-3a34-8905645ce5f2
Content: Markdown syntax for files, widgets, and wikis - Azure DevOps
Content Source: docs/project/wiki/markdown-guidance.md
Product: devops
Technology: devops-collab
GitHub Login: @chcomley
Microsoft Alias: chcomley

Tried displaying attachments in DEvOps
![image.png](/.attachments/image-23498c-33f0-426e-b798-3d21616d37f5.png =500X250) this is not working either

Tried displaying attachments in DEvOps
![image.png](/.attachments/image-23498c-33f0-426e-b798-3d21616d37f5.png =500X250) this is not working either

@manishmoothedath I think this is a doc-bug rather than product feedback.


Patched vulnerabilties w/ npm audit fix

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

Hi @mick-io thanks for the PR. I am closing this for a couple reasons.

We are unable to verify the commit author, seems like you haven't configured your local git config correctly?
Your changes were made from your master
Finally we have a script that helps us resolve these in all the packages vs just the root.

We will have this resolved shortly in a new PR. Thanks. And BTW, if you are interested in contributing please give Guidelines for Contributing a read.


Destroying the object

Hey! You've done a great job and I'd like to thank you for that. Cool stuff, much better than all those other plugins that affect the actual scrolling performance (on some devices though). But.... I'm lacking a nice destroying function, that will revert the DOM structure into its initial state - without "simplebar-xxx" containers. Perfect-scrollbar has that option actually.
Had to create some 'dirty' workaround....
Looking forward to your respond ;)
P.S. unmount() doesn't solve the problem I described

Hey @apopelyshev thanks for your kind words.
Some users have asked for the same thing but I don't think it's a good idea to implement such a thing because it will add a lot of code for an edge case.
Can I ask what is your use case and why you need to get the original DOM element back to how it was before?
I guess if I get a proper use case I can understand better why some users want to do that and how we can find a workaround.

Well....in my case I think it's more bout aesthetics. I have an expandable absolutely positioned container which serves more as a 'dialog-box' with some overflowing content (a long list of entries). I have my CSS-animations set and some JS also. It's just like... I don't actually need those simplebar-content inside simplebar-scroll-content in a small, non-expanded version (I just limit the number of displaying list items)

It's not a problem at all. I kinda don't like everything being 'containered' when it's not needed (in my particular project)

Ok got it.
Yes that's one of the quirks of SimpleBar compare to other libraries: you get DOM alterations/more DOM elements versus simulating the scroll event with JS. The idea of SimpleBar is that the number of DOM elements and the JS happening there is still more performant than the alternatives. But maybe if you have a lot of instances that can be a problem.
I know DOM alteration to init SimpleBar causes lot of other problems with unmounting and also cross compatibility with other plugins/frameworks. I should probably document that in a "quirks" section!
To come back to this issue specifically, I think that's something that could be implemented if it's not too much code.
I took a look a other plugins and it seems like some are having this feature like Siema carousel for example.

So funny, just came here looking for the same, sort of "destroy" function and this is actually an on-going conversation haha.
I was looking for a destroy function because the parent container of the scroll area has an arrow for collapse and expand the container, after collapse it, when I open the container, the scrollbar of simplebar remains hidden, don't know why, so I was trying to "destroy" when collapsing and "initialize" simplebar when expanding the parent.

@juanpablob sounds like an interesting issue. Maybe open a new issue and if you can provide a jsfiddle showing the issue that would be awesome! (you can use this as a start point https://jsfiddle.net/Grsmto/57obe5w2/1/ )

Thank you!


[vite] Internal server error: Maximum call stack size exceeded

Vue version
3.4.28 and above
Link to minimal reproduction
https://play.vuejs.org/#eNq1U01v00AQ/SujVYUTKSQicEAmTVWgh3KACjiuRCxnnGzrrK3dcRuw/N+ZWSeuk34gDr3EmY+dffPe21qdl+X4tkIVq5lPnSkJPFJVQp7Y1alW5LWaa2s2ZeEIanCYjWCJmbF47n/b9FPBFYuWoIHMFRuIeFikrbZpYT2B1N/A6aNHBoMhnM6hnT2IxpPQLGii4fCDtrNJi4jv54BwU+YJIUcAs3auTTbIIF2R3iBpBWtjieO10WrCfbNJ75Aa8TIMKjOr8bUvLG9cyyitUp5lcnTfSjIMWqsYQkVqSZ4Xd19CjlyFo30+XWN680j+2m8lp9WVQ4/uFrXqapS4lcCU8sWPr7jl/11xUyyrnLufKX5HX+SVYGzbPlZ2ybB7fQHtZeDT2NVPf7EltH6/lACVzib0a8VEC41PrX4P9+34XTinbcMsdiqJZ3oEawqqTOWfpninjXy02uXYWpzi3/uM+SNd8glGk+TMl4md13WQE5qGfSCJfTEvaM4p+YRLg22mx3JzuPNzz8mtt/t+vnJF6Tvvtha8tIQuS1KM2IRd5z9Nz81910//x/XTe9dre2do/RmzpMrJD9oRAeasZeQsBk+O9eXbX7ULzAfDkQinSRpiYGOEY0tWWhMvHUOUJXnEYXP0snaCBgAPBTUQp3niPfO3OKl5EJwJhxDm+YjXT16f1KJxA1xnFblhEZISNAvpjJpFT9sH8pmXku4ZJo9YO2CIQ4Z+SOITrHXXjckzebgN0FiCNruDuL+iE06wkZB2kJBb+y3y1n7dopP3y8P5EY6n71XzF6Pj9hY=
Steps to reproduce
Trying to reproduce inside SFC playground but no error showing up ...
Anyway, I was migrating from 3.4.21 to latest release (3.4.32) and my project didn't work anymore, no change in the code just upgraded vue.js version.
So I went minor version by minor version and the last vue.js version working is the 3.4.27 and then with 3.4.28 I got the vite error message [vite] Internal server error: Maximum call stack size exceeded targeting the file on component (in my case :  "File: /home/xxxx/projects/MyComponent.vue")
Something wrong with the Props definition from external files and using them in two components. The error go away if I change my defineProps lines in both components (see SFC playground for context). Then hit another similar issue with another component trickier, can't find a way to solve it ...
What is expected?
Expected to work like previous version
What is actually happening?
An error is thrown :
11:45:20 AM [vite] Internal server error: Maximum call stack size exceeded
  Plugin: vite:vue
  File: /home/xxxx/projects/MyComponent.vue
at visitDirectory (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:22211:60)
at visitDirectory (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:22212:9)
at matchFiles (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:22180:5)
at Object.readDirectory (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:8764:14)
at getFileNamesFromConfigSpecs (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42798:29)
at getFileNames (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42291:23)
at parseJsonConfigFileContentWorker (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42195:16)
at Object.parseJsonConfigFileContent (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42128:10)
at loadTSConfig (/home/xxxx/projects/node_modules/@vue/compiler-sfc/dist/compiler-sfc.cjs.js:18640:22)
at loadTSConfig (/home/xxxx/projects/node_modules/@vue/compiler-sfc/dist/compiler-sfc.cjs.js:18655:22)

System Info
System:
    OS: Linux 6.5 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (8) x64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
    Memory: 21.54 GB / 31.29 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.8.0 - ~/.proto/shims/node
    Yarn: 3.6.4 - ~/.proto/shims/yarn
    npm: 9.7.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 126.0.6478.126

Same on MacOS

Any additional comments?
Running into that error when updating vue.js package from 3.4.21 to 3.4.31

I downloaded the playground as a local Vite project and cannot reproduce the issue. Both dev and build are working as intended.
Could you please provide a repo that can actually show the error?

@yyx990803 I can provide access to the repository, but not publicly as it's part of the company. However, I can invite you to it if that works for you.

@yyx990803 Invite sent through GitHub : repo named alpsify, it's a monorepo running with Moonrepo.

@yyx990803 I guess this is linked to this modification https://github.com/vuejs/core/commit/bdeac377c7b85888193b49ac187e927636cc40bc in the 3.4.28 version

@nathan-de-pachtere I can't find the invitation in my emails. Can you just post the link to the private repo here?

Here it is : https://github.com/alpsify/alpsify

Still an issue on 3.4.38. @yyx990803 Did you get access to the repo ?

@yyx990803 I tried using version 3.4.38 and modified the code in the compiler-sfc.cjs.js file as follows:

Removed the update made for this issue: https://github.com/vuejs/core/issues/10907

function loadTSConfig(configPath, ts2, fs) {
  const parseConfigHost = ts2.sys;
  const config = ts2.parseJsonConfigFileContent(
    ts2.readConfigFile(configPath, fs.readFile).config,
    parseConfigHost,
    path$3.dirname(configPath),
    void 0,
    configPath
  );
  const res = [config];
  if (config.projectReferences) {
    for (const ref of config.projectReferences) {
      tsConfigRefMap.set(ref.path, configPath)
      res.unshift(...loadTSConfig(ref.path, ts, fs))
      /*const refPath = ts2.resolveProjectReferencePath(ref);
      if (!fs.fileExists(refPath)) {
        continue;
      }
      tsConfigRefMap.set(refPath, configPath);
      res.unshift(...loadTSConfig(refPath, ts2, fs));*/
    }
  }
  return res;
}

After confirming that everything works correctly with the changes, I started digging deeper into the reason behind this modification.
I also work in a monorepo with Yarn workspaces and Moonrepo. I maintain a single tsconfig.json file at the root of my monorepo for a consistent development experience and uniformity. And yes, I do have multiple tsconfig.json files in my packages referencing each other : this part is handled automatically by the Moonrepo CLI to ensure that every package is in sync. And also sync paths.
Maybe I'm missing something about how tsconfig.json files work, but the issue definitely lies within those lines of code.
Or maybe it's the way pnpm handles workspaces compared to yarn that causes everything to break with yarn... I’m not really sure why this issue came up.
I also tried cleaning up the tsconfig.json files to match the test case, but it’s still not working.

@yyx990803 Looking at the reproducer in https://github.com/vuejs/core/issues/10907, it appears that a code change was made in Vue.js to address a problem that actually stems from the project's specific structural choices.
Specifically:

This is not a true monorepo example: the src/folder isn’t an independent package used by the main project, just a folder within the project.
The project should be using Vite alias to match the TypeScript path resolve option like explained here https://stackoverflow.com/questions/77249074/how-do-i-use-typescript-path-aliases-in-vite
The vite.config.js file is at the root of what's being called a monorepo but should be wrapped in a "project folder." Then, the resolve configuration should be used to match paths to the necessary libs/packages.
A package named @whatever should be created to store types or other pieces of code, which can then be used within other  libs or apps projects.

Overall, it feels like the fix addresses an edge case that arises from specific, custom structural choices rather than following the "standard" approach.
Or maybe I'm missing something. If @cyrilluce from https://github.com/vuejs/core/issues/10907 could join the discussion, that would be great.

@nathan-de-pachtere
I'm guessing if there are circular reference in your tsconfig?
Try to modify code to verify
  if (config.projectReferences) {
    for (const ref of config.projectReferences) {
      const refPath = ts.resolveProjectReferencePath(ref)
      if (!fs.fileExists(refPath)) {
        continue
      }
      // ------ Add these code
      if(tsConfigRefMap.has(refPath)){
        continue
      }
      // --------
      tsConfigRefMap.set(refPath, configPath)
      res.unshift(...loadTSConfig(refPath, ts, fs))
    }
  }

@cyrilluce First, thanks for joining the discussion.
The change you suggested makes it work:
if(tsConfigRefMap.has(refPath)){
        continue
      }

Could you explain how this change resolves the issue? Feels like I'm gonna learn something here. =D
We use multiple Python scripts to check for circular dependencies at multiple levels (package, tsconfig, import), and nothing shows up. Also, Madge and DepsCruiser. We have a monorepo with 6 projects and over 100 lib packages that reference each other and for sure used by projects, so we continuously monitor for circular dependencies to avoid issues. Additionally, our tsconfig.json files are entirely managed by Moonrepo, our solution for managing the monorepo. So we don’t manually change the references and paths in tsconfig.json for each library or project : precisely to avoid errors.

@nathan-de-pachtere
For example, a/tsconfig.json ref b/tsconfig.json, and b ref a. loadTSConfig haven't handle these circular situation, will cause dead recurisive loop.
load(a)
  load(b)
    load(a)
      load(b)
        ...

I guess you are using folder path in your tsconfig reference, before my previous PR it will just get a empty config, and them ignore it.
Now reference with folder worked, that expose this bug.
Maybe I should make a pr to fix it

@cyrilluce
We don't have cases of direct circular references between two packages as you describe. If it occurs, we split the code into three packages and reorganize it by creating a middle package that bridges what’s needed by both. This way, we generalize and keep our codebase clean and usable for new projects.
It would be amazing if you could create a PR for that.

@nathan-de-pachtere  Indirectly circular reference also dose, e.g. a -> b -> c -> a

@cyrilluce Thanks for that quick PR


update children context

@viper1104 Hi, thanks for contributing.
First: can you write some description for this?
Second: You dont need to push change of package.json and version update.

ReactIScroll does not rerender children if the context was changed.
Example:
class ChildComponent extends React.Component {
	constructor(props) {
		super(props);
	}

	render() {
		return (
			<div>
				{getText("text-key", this.context.locale)}
			</div>
		);
	}
}

ChildComponent.contextTypes = {
	locale: PropTypes.string
}

class MainComponent extends React.Component {

	constructor(props) {
		super(props);
		this.state = {locale: "en"};
		this.onChangeLocale = this.onChangeLocale.bind(this);
	}

	getChildContext() {
		return {locale: this.state.locale};
	}

	componentDidMount() {
		Localization.bind('change-locale', this.onChangeLocale);
	}

	onChangeLocale(locale) {
		this.setState({locale});
	}

	render() {
		return (
			<ReactIScroll>
				<ChildComponent />
			</ReactIScroll>
		);
	}
}

MainComponent.childContextTypes = {
	locale: PropTypes.string
}

If localization is updated, ChildComponent does not know about the changes and does not rerender, because ReactIScroll does not respond to context changes. Need add check context to shouldComponentUpdate.

Released with 1.1.3


needs more information for settings.cfg

greetings.
really very cool and great mod,
but me think, there are very little information about the settings.
for example:
// reliability settings
QualityScale = 4.0                  // scale applied to MTBF for high-quality components
100.0 will set high-quality components to always working? or 1000?
CriticalChance = 0.25               // proportion of malfunctions that lead to critical failures
SafeModeChance = 0.5                // proportion of malfunctions fixed remotely for unmanned vessels
proportion from 0.0 to 1.0 ? how it apply to manned vessels?
// radiation settings
ShieldingEfficiency = 0.9           // proportion of radiation blocked by shielding (at max amount)
setting it to 1.0 will turn full shielded ship to same radiation like on kerbin ground?
// temperature settings
SurvivalTemperature = 295.0         // ideal living temperature
how control internal temperatures inside ship? or it controlling automatically with enought electricify and radiators?
SurvivalRange = 5.0                 // sweet spot around survival temperature
is this a middle of good temperature in K? +-5'K or +-10'K

100.0 will set high-quality components to always working? or 1000?

It's a scaling factor that multiplies MTBF, as it says, so you'd need infinity to make it never break.  If you don't want things breaking, disable the Reliability system.

how it apply to manned vessels?

Safe Mode only applies to unmanned vessels: https://github.com/ShotgunNinja/Kerbalism/wiki/Reliability#failures .  With long-duration manned vessels you should bring an engineer instead.

setting it to 1.0 will turn full shielded ship to same radiation like on kerbin ground?

1.0 would mean that a fully-shielded pod would not take any radiation.  But this might cause bugs, I don't know.  0.9999 might be safer.

how control internal temperatures inside ship? or it controlling automatically with enought electricify and radiators?

Kerbalism automatically consumes electricity (EC) to keep temperatures within the range.  I'm not sure if radiators are treated specially.

thanks for the detailed explanation :)
me trying to set high-quality components to near always working. (only high-quality)
and lower chance for critical failures (red) close to zero.
for long-term flights, space stations and many others.
me also noticed that even under ideal conditions, the percentage of crew stress is slowly growing.
is it possible to do something for the crew so that this parameter begins to decrease?
or returning to kerbin is the only way out?

Nothing will decrease stress or radiation except recovery on Kerbin.  You can slow them down a lot, though.  If you need either to last longer, you can tweak the rate in Profiles/Default.cfg

so even stay at laythe's surface will not helps


operators [CI] camel-k

Signed-off-by: nicolaferraro<EMAIL_ADDRESS>This is to speed-up releases by setting the reviewers for the Camel K operator.
cc: @astefanutti, @squakez

/merge possible

/merge possible

/merge possible


Key support

Up/down cursor movement is working. The solution here is to note the cursor offset from the beginning of the line, and the length of the adjacent line to be moved to. If the offset is greater than the length of the adjacent line, move to the end of the adjacent line. Otherwise move to the adjacent line at the same offset.
The code is a bit messy, mostly due to dealing with edge cases, and can probably be cleaned up.
I'd be happy to hear any suggestions for improvements or see an alternate implementation.

I'm confused what cls, pls, nls do here; could you please explain their functionality in brief?

Sure, those stand for 'current line start' and 'previous line start'. There's also cle and nle for 'current line end' and 'next line end'. These variables hold the location of the relevant newline character in the document text. As an example:
`f o o \n`
`b a r \n`
`b a z \n`

If my cursor was on the first character on the second line, cls would be the first \n, cle would be the second \n, and nle would be the third \n (if we were moving upward we would need to know pls as well, but here pls would not be set because the 'previous line start' is the beginning of the document, so there is no \n there).
These are used to calculate the length of the line (for instance, when moving the cursor down a line, 'next line end' - 'current line end' = length of next line) to see where the cursor should be placed. If the cursor 'offset' from the start of the line is greater than the length of the next line, then the cursor should just be placed at the end of the next line. Or, if nle-cle < offset {return nle}.
I kept those variables separate instead of just storing the line length in its own variable, because the line length is only necessary for one check (to see if the offset is greater than the length of the line to move to) while the separate variables are useful for checking edge cases like moving to the first or last line in the document.

Thank you for the explanation! It would be great if you could:

add comments describing this behavior (not as inline comments, but as a large block of comment describing this in detail)
write some unit tests for the new behavior

Writing unit tests will help in finding out certain flaws with the current implementation.

Sorry for the crazy delay! I added test cases and found bugs (of course) but got sidetracked with some other stuff before I got around to fixing it.
It seems to be working now, and I cleaned up the code a bit and added comments as explanation.

Thanks for the update! Looks good to me; I'll try testing it locally once.

Right, my mistake. That was a holdover of a previous fix to handle panics that could occur with empty documents (e425b85). Should be working now.

@benmuth Great work on this one, thanks! Merging!


Defining and detecting harassment through cameras is technical challenge

Defining harassment through objective criteria for video analytics is complex. Subtle cues or non-physical harassment might be difficult to detect using cameras alone.
Non-verbal Cues: Often, harassment is communicated through non-verbal cues like body language, facial expressions, or tone of voice. These subtleties are very challenging for video analytics software to interpret reliably.
so for activity recognition:Develop algorithms that go beyond simple object detection to recognize specific actions and interactions that might indicate harassment. This includes analyzing posture, gestures, and relative positioning of people.
Sensor Fusion: Combining data from cameras with other sensors like microphones (with privacy safeguards) or wearables (with user consent) can provide a more comprehensive picture of the situation.
Advancements in AI, particularly in areas like natural language processing and sentiment analysis, can help interpret non-verbal cues and the emotional context of interactions.
so i would like to work on these sensor fusion and sentiment analysis so assign me this issue

I would also like to work on this issue. Please assign this to me under Gssoc'24.

I would love to work on it.Please assign this issue to me.


Filter --tag broken

Describe the bug
Filtering a spec by tag using --tag A --tag B is currently broken as it only accepts the last filter entered.
Instead it should keep all paths that contain any of the tags.
Additional context
This is due to the following check constantly overriding previous results:
exclude = method.Value.Tags?.Exists(x => x == tag) != true;
The code may be rewritten, to remove the looping over includeTags by using the following:
var exclude = method.Value.Tags?.Exists(includeTags.Contains) != true;

Also, previously the enumerated collections were cloned, to not break the enumeration, after the rewrite the enumerators are reused (.ToArray() was removed)
https://github.com/christianhelle/refitter/commit/7025d6182a0df1a067c2f9c69b54af8d6d83e1d6#diff-275851d6772d6a0a03b9aaf63017c87331d0334e274deeebd199fe8cd07cc521R34
https://github.com/christianhelle/refitter/commit/7025d6182a0df1a067c2f9c69b54af8d6d83e1d6#diff-275851d6772d6a0a03b9aaf63017c87331d0334e274deeebd199fe8cd07cc521R37
deleting from an collection that is currently enumerated is undefined behavior

Good catch @kirides
My bad for breaking this 😅


Fix issue JSON scalar crashes on JsonElement inputs #6023

Fix issue parsing JSON scalar inputs

Adds a 'bytes written' to call to GetSpan so that JsonElement.ParseValue only attempts to read the actual bytes written, rather than continuing to read the underlying buffer.

Closes #6023

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Why not just flush?


VM Service's lookupResolvedPackageUris returns different org-dartlang-sdk structure for Flutter apps from Dart

I'm not sure whether this is expected - if so, I think it needs documenting (it may already be, but I've not been able to find anything).
The DAP implementations use the VM Service's lookupResolvedPackageUris call to convert URIs like dart:code/uri.dart (which are provided in stack traces) to things that can be mapped to local file paths on the users machine (so that when debug stepping, the same files can be opened that the user gets if they use Go-to-Definition via the analyzer).
If I write code like this, and step into Uri.parse:
var a = Uri.parse('');

Then in the Dart SDK, lookupResolvedPackageUris converts this URI to org-dartlang-sdk:///sdk/lib/core/uri.dart
==> {
	"jsonrpc": "2.0",
	"id": "41",
	"method": "lookupResolvedPackageUris",
	"params": {
		"isolateId": "isolates/1481761977225271",
		"uris": [
			"dart:core/uri.dart"
		],
		"local": true
	}
}

<== {
	"jsonrpc": "2.0",
	"result": {
		"type": "UriList",
		"uris": [
			"org-dartlang-sdk:///sdk/lib/core/uri.dart"
		]
	},
	"id": "41"
}

Currently, the debug adapters assumed that org-dartlang-sdk:///sdk points to the root of the Dart SDK and correctly map this to the lib/code/uri.dart file in the Dart SDK (/sdk is one example given in the docs).
However, when running a Flutter app (using latest master) the result is org-dartlang-sdk:///third_party/dart/sdk/lib/core/uri.dart:
==> {
	"jsonrpc": "2.0",
	"id": "639",
	"method": "lookupResolvedPackageUris",
	"params": {
		"isolateId": "isolates/3750929181587719",
		"uris": [
			"dart:core/uri.dart"
		]
	}
}

<== {
	"jsonrpc": "2.0",
	"result": {
		"type": "UriList",
		"uris": [
			"org-dartlang-sdk:///third_party/dart/sdk/lib/core/uri.dart"
		]
	},
	"id": "639"
}

I could update the code to also assume org-dartlang-sdk:///third_party/dart/sdk should map to the root of the Dart SDK, however it makes me wonder whether there may be other differences that need to be accounted for. I don't know how the mapping for org-dartlang-sdk is built, but it would make sense to ensure any assumptions in the DAP match the actual rules (and include a note in the code where those rules can be found).
@bkonyi do you know if this is intended, and/or where the rules for org-dartlang-sdk are?

The problem with looking for sdk/lib and assuming that's the Dart SDK root is that it only works when going from org-dartlang-sdk to a file path, but we also sometimes go from a file path to a org-dartlang-sdk URI (and wouldn't know to insert the third_part/dart part).
We could override this in the Flutter DAP if we can assume that it would always be org-dartlang-sdk:///third_party/dart/sdk/lib for Flutter, but it might be good to confirm that this is intended (and not just accidental) first, and if so ensure it's noted in the VM Service docs (or if there are better docs about org-dartlang-sdk somewhere, linked the VM Service docs to them).
@johnniwinther do you know if the difference described above is intended, or do you know who I could ask?

This could be related to the difference in build rules used to compile platform dill files:
For standalone Dart SDK:
https://github.com/dart-lang/sdk/blob/56df8216360772074d3c78c39e966a749f3e1e8d/runtime/vm/BUILD.gn#L182-L183
For Flutter:
https://github.com/flutter/engine/blob/9f306a6ca740ea8f9538587c74d3e39d6e3fd684/lib/snapshot/BUILD.gn#L265-L266
In the first case root directory for org-dartlang-sdk scheme points to the Dart SDK directory, which contains sdk/lib. In the Flutter case it points to the engine src directory, which contains third_party/dart/sdk/lib. This difference is also reflected in corresponding libraries.json files.
Note that there are also separate build rules for building platform dill files for dart2js, DDC, dart2wasm as well as Fuchsia-specific Flutter runner and Dart runner. We might also have a separate copy of those build rules in g3 (as it doesn't use gn).

Also note that in case of Flutter some libraries come from Dart SDK and have third_party/dart/sdk/lib/... path related to org-dartlang-sdk:///, but others (such as dart:ui) come from Flutter engine and have flutter/lib/...  path related to org-dartlang-sdk:///. So we might not be able to redefine location of org-dartlang-sdk for Flutter just to point to Dart SDK.

@alexmarkov do you know whether this is deliberate or a side-effect of the paths being set for another reason?
If deliberate, is it reasonable/feasible to have them documented somewhere (can they be relied on to never change)?
The debug adapter needs a reliable way to map between paths that exist on the users file system and Dart's URIs to correctly handle breakpoints and stepping with the debugger. My original understanding was that org-dartlang-sdk was a consistent way to do this (because the runtime doesn't necessarily know the local SDK paths), but it's not clear to me if the differences are deliberate or accidental.

but others (such as dart:ui) come from Flutter engine and have flutter/lib/...

Ah, that's good to know - I had assumed everything from Flutter was going to be package:flutterxxx. I guess we definitely need to handle flutter/lib then (in both directions). I'm still unclear whether Dart could/should be consistent though (and if not, whether it's safe to assume it's always third_party/dart for Flutter).

@alexmarkov @bkonyi can anyone confirm whether this difference is deliberate or accidental? I'd really like to fix this (breakpoints in SDKs have been a long-standing issue and we seem very close to fixing it), but I don't want to add more hard-coded assumptions into DAP without some confirmation that this is expected (and ideally, a full set of these mappings so the client can handle them correctly).

@DanTup These different paths just reflect different directory layouts we have while building Dart SDK and Flutter engine, so they are deliberate. As far as I know internal google repo uses a yet another directory layout. I think it's not safe to assume particular directory layout relative to org-dartlang-sdk:/// - it may change as needed.
Maybe we can avoid these assumptions by cutting leading directory parts from org-dartlang-sdk:/// URIs and testing if corresponding source file exists in Dart SDK and Flutter? This way we would only assume that relative paths should eventually match.

In the interest of providing a fix for this in the near-term, I'm going to look at handling the specific values above in the Flutter DAP. I'll make sure it doesn't fail if this ever changes (it will just fail to map - the same thing it already does today with those paths) and we can revisit it if it does (or if we get something better).
I chatted with @bkonyi briefly and he suggested that one option could be for the compilation tooling to accept an option to specify where the Dart SDK root is relative to the embedding projects root, which could allow this to be consistent (at which point perhaps consistency could become a "promise"). I don't know how involved that is (or whether it could impact other things) - any thoughts @alexmarkov?

Currently, when compiling platform, we specify real directory of org-dartlang-sdk:/// root and the location of libraries.json file using org-dartlang-sdk:///...  URI. Locations of particular platform libraries are specified in libraries.json file relative to the location of libraries.json itself, so CFE derives their URIs from the URI of libraries.json file. (@johnniwinther Please correct me if I'm wrong.)
Note that different embeddings of Dart have their own libraries.json files (because they have different sets of libraries) and different definitions of org-dartlang-sdk:/// root (because they have different directory structures).
@DanTup Could you clarify how the proposed option would be taken into account and how it would help?
My understanding is that if we would like to rely on a particular value of URIs of platform libraries, then we would need to unify directory layout when building platform in all projects embedding Dart (so that sdk/lib/core/core.dart is always placed into the same directory relative to org-dartlang-sdk:/// root). This would probably involve a bit of copying things around during build or extending front-end to understand multiple different roots when compiling a platform.

Sorry for the wall of text, but some context because it might not be completely clear what all of this relates to from the above :-)
Since forever, if a user VS Code clicked Go-to-Definition on a symbol that led to the SDK, the analysis server would return a file path to the local SDK sources on their disk. If they added a breakpoint in that file, VS Code would send that path to the Dart VM during debug sessions, but the breakpoint would not work (because the running VM doesn't know that path corresponds to the SDK).
(the same was true for package files, although that was fixed some time ago, and the running VM was able to them).
To fix this (or so I thought) some new VM Service APIs were added to map URIs to/from file paths. However, it turned out that this API couldn't map the SDK sources, it could only convert them from dart:foo/bar.dart into org-dartlang-sdk:///sdk/....
So, in the debug adapter (which sits between VS Code's debugger and the VM Service) we have mapping that can convert a URI in the form org-dartlang-sdk:///sdk/... to a file path in the users local SDK folder (and back again). It currently only supports things in org-dartlang-sdk:///sdk and does not handler /runtime or any others (I don't know if any others exist). This largely fixed the original bug, and you could now Go-to-Definition in VS Code to SDK sources, and the debug adapter could translate that path into something the VM understands, and when the debugger breaks, it can translate it back so that VS Code can navigate to the correct SDK source on the users disk.
It turned out this translation of org-dartlang-sdk:///sdk/ didn't work for Flutter for the reasons above. So my proposed fix is to allow the Flutter debug adapter to override the base Dart SDK path from org-dartlang-sdk:///sdk/ to org-dartlang-sdk:///third_party/dart/sdk/ which will be used for mapping Dart SDK sources in both directions.
This may not be a complete fix (we don't handle anything outside of /sdk) and it may not be future proof (if this structure changes, it will stop mapping), however it's no worse than what we have today (which is that none of them work anyway) and in the worst case will just go back to "not working" if things change.
Of course, it would be nice to implement a more complete/more static version (which I guess is what https://github.com/dart-lang/sdk/issues/48435 is about.. removing the need from the "client" - in this case the debug adapter - from needing to handle the org-dartlang-sdk URIs itself and pushing that into the VM/VM Service/DDS or somewhere similar).

Re-reading the above, I noticed you gave another example:

but others (such as dart:ui) come from Flutter engine and have flutter/lib/...

So my fix above is probably incomplete and instead of just allowing a single Dart SDK URI to be overridden, it should probably be a collection of mappings. How much it's worth trying to cover all cases probably depends on how long this code is likely to live until there may be something better though.

@alexmarkov

@DanTup Could you clarify how the proposed option would be taken into account and how it would help?

Sorry, I think I misunderstood and I explained how my short-term fix would work and not what I wrote after discussing with @bkonyi. Re-reading what you wrote, I'm less certain about how this would work, but now I'm not sure whether Ben meant for these URIs to be consistent, or that the DAP would have a way to access that relative path to the Dart SDK.
Perhaps focusing on the Dart SDK is not the right thing (because of things like dart:ui falling outside of it). Perhaps what would be better is a mapping between the relative org-dartlang-sdk:/// paths and the locations of source files in the shipping SDK that the DAP (or another internal API as described in #48435) could use to perform the mapping.


Move proposals and add documentation

Fixes https://github.com/devcontainers/spec/issues/338
As @samruddhikhandale proposed, we should move implemented proposals out of the "proposals" folder. I've made several changes in this PR:

Move implemented proposals into the "specs" folder
Update each implemented proposal to include a link to its initial discussion issue and where it was merged into the CLI or schema
Add README content to the "specs" and "proposals" folder with more info on this process

In the "specs" README, included a list of the main top-level specs for easier navigation (i.e. overall dev container, Features, and Templates specs)

Misc polish (i.e. caps, formatting)

I considered moving all of the proposals out of their individual files and instead into the existing spec files, but this felt less ideal:

It'd make the existing spec files much longer

Keeping a set of smaller individual files may better help with quick navigation

Each file can serve as a point in time reference to that proposal, including the discussion issue and implementation PR links

But if folks would prefer this ^, I'm happy to discuss further.

I considered moving all of the proposals out of their individual files and instead into the existing spec files, but this felt less ideal:

Makes sense to me! 👍

Thank you for the quick review @samruddhikhandale! And for the great idea that spurred this PR 😄. I'll merge now and happy to iterate in future PRs if other folks have additional thoughts.

bamurtaugh/move-props

.patch


Added UberLoggerAppWindow.ToggleWindow.

This allows the window to be toggled programmatically.

@ewanmellor Does this make sense for other users of UberLogger? Perhaps it would make more sense to make the ShowWindow property public?

@Kalmalyzer Some people are sensitive about making properties public, so I went with this.  I don't mind either way though, exposing ShowWindow would be fine too.  I just want to toggle the window from my centralized input handler, I can do that in either case.  It's up to whoever's going to accept the change.

@bbbscarter judgment call plz?

Hi! Sorry for the delay.
Yup, my preference would be to turn ShowWindow into a property (probably just an auto-property for now) and make it public, and allow users to do whatever they want with it.


Error 500 on player search.

Hey bros. The login is working fine, with two factor and all staff
But when i try to search player, i got error 500
anyone else?

regards!

Account was suspended, asking to "play on your console".


Ambari 25166

What changes were proposed in this pull request?
Modifying the value of node memory in the YARN service will affect the maximum value of container memory, but the modification cannot be saved.
How was this patch tested?
We cannot save the maximum value of container memory associated with node memory value when modifying the node memory.

Now we can save the maximum value of container memory when modifying the value of node memory.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4943/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4944/
Test PASSed.


Trying to enable LDAP by uncommenting the sample line in config.yaml results in a failing build

Describe the bug
I was trying to add the PHP LDAP extension to an environment to test the LDAP module for Drupal 8. I found through this queue that there was an example in config.yaml showing how to get that extension, but simply uncommenting that line produces the following error on build:
Errors were encountered while processing:
 php7.3-fpm
E: Sub-process /usr/bin/dpkg returned an error code (1)
', stderr='Building db
Building web
Service 'web' failed to build: The command '/bin/sh -c apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends --no-install-suggests php-yaml php7.3-ldap' returned a non-zero code: 100'

To Reproduce
Steps to reproduce the behavior:

Open config.yaml.
Uncomment the webimage_extra_packages definition.
Attempt to start the project.
See error. 😱

Version and configuration information (please complete the following information):

Host computer OS and Version: macOS High Sierra
Docker version: 19.03.4
ddev version: v1.11.0
config.yaml contents: the current template with the change to the commented line.
Do you have any custom configuration (nginx, php, mysql) in the .ddev folder? Nope.

I'm unable to recreate that problem. I was wondering if you were using php 7.2 and installing php7.3-ldap, but that also worked fine for me. You can experiment with this and maybe see more info with:
ddev ssh
sudo apt-get update
DEBIAN_FRONTEND=noninteractive sudo apt-get install -y --no-install-recommends --no-install-suggests php-yaml php7.3-ldap

I was able to recreate this by going back to v1.11.0, and the problem is that the upgrade of php7.3-ldap actually upgrades way too much stuff, including php-fpm, and there's a config change to www.conf, so you get
Setting up php7.3-fpm (7.3.11-1+0~20191026.48+debian9~1.gbpf71ca0) ...

Configuration file '/etc/php/7.3/fpm/pool.d/www.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** www.conf (Y/I/N/O/D/Z) [default=N] ?

Because DEBIAN_FRONTEND is noninteractive, it's a plain failure.
I'm not entirely sure there's a good workaround for this. But as @Z0zol3 points out, you can probably do php7.2-ldap just fine if you're using php7.2.
It does look like changing to apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y -o Dpkg::Options::="--force-confnew" --no-install-recommends --no-install-suggests may force the new config per https://serverfault.com/a/279446/79810
Thanks for pointing raising this bug. It would happen in the future at various times when a ddev release and its associated images got a little bit old compared to the upstream packages, or major config changes in the upstream Debian packages, as happened here. I'll do a PR to try to make this work more generally.

Thanks so much for the issue, https://github.com/drud/ddev/pull/1951 should fix it, at least in this situation.
And of course for your short-term situation,

you can just use php7.2-ldap if you're using php7.2 (which doesn't have the major churn upstream)
Or if you need php7.3, you can add .ddev/web-build/Dockerfile (copy from .ddev/web-build/Dockerfile.example) with apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y -o Dpkg::Options::="--force-confnew" --no-install-recommends --no-install-suggests php7.3-ldap

BTW, the reason I was initially unable to recreate was that I was using a newer ddev, which used a more recent image, which didn't have the upstream php7.3 churn.

No worries, thanks for all the extra detail and ideas! Wouldn't be a bad thing for me to be testing against 7.3 locally regardless. : D