x/net/idna: backward compatibility issues with recent change

What version of Go are you using (go version)?
go version go1.7.3 darwin/amd64

What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/weppos/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.7.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.7.3/libexec/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rk/llwxtd9s6jn91p2ky13tr30c0000gn/T/go-build321981550=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?
It looks like https://github.com/golang/net/commit/67957fd0b1868d2b9f4fd2b3a3474c83bc3d49c3 (change 34770) broke backward compatibility. Given the commit message says otherwise, I'm filing this as a bug.
There are at least 2 strings that are current causing failures:

the empty string
a string starting with a leading *

I detailed the issue at https://github.com/weppos/publicsuffix-go/issues/56, along with some code to reproduce it.
Here's the simplest example:
package main

import (
	"fmt"
	"os"

	"golang.org/x/net/idna"
)

func main() {
	s, err := idna.ToASCII("")
	if err != nil {
		fmt.Printf("Error converting empty string: %v\n", err)
		os.Exit(1)
	}

	fmt.Println("Empty string works!")
	fmt.Printf("Result: `%v`\n", s)
}

and here's the log
➜  publicsuffix-go git:(master) ✗ cd ~/go/src/golang.org/x/net/idna; git co 69d4b8; cd -; go run idna-test.go
Note: checking out '69d4b8'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 69d4b8a... http2: remove unnecessary TODO for trailer keys allocation
~/go/src/github.com/weppos/publicsuffix-go
Empty string works!
Result: ``

➜  publicsuffix-go git:(master) ✗ cd ~/go/src/golang.org/x/net/idna; git co 67957f; cd -; go run idna-test.go
Previous HEAD position was 69d4b8a... http2: remove unnecessary TODO for trailer keys allocation
HEAD is now at 67957fd... idna: use code generated by internal x/text package
~/go/src/github.com/weppos/publicsuffix-go
Error converting empty string: idna: invalid label ""
exit status 1

What did you expect to see?
I'd expect the following string conversion:
String "" converts into "" with no errors
String "*.uk" converts into "*uk" with no errors

What did you see instead?
The empty string fails with error idna: invalid label "".
The string "*.uk" fails with error idna: disallowed rune U+002E
/cc @nigeltao

+1
x/net/idna is a dependency of cloud.google.com/go/bigquery, making it unusable for now too.

/cc @mpvl

Additionally, ToASCII now lowercases domains where it didn't before.

Looks like RFC 4343 states that the case folding for internationalized labels is not part of DNS, and PRECIS as defined in RFC 7564 uses only the keywords "RECOMMENDED" and "NOT RECOMMENDED" in the sections describing the case mapping/folding.
I'm not sure whether the change is intentional, but feel like the clarification on ToASCII and ToUnicode is nice to avoid unnecessary confusion; for example, idna.ToASCII doesn't do case preservation and the returned sequence of labels is not suitable for DNS messages because of the violation of RFC 4343.

@mpvl is on paternity leave, and I don't have many spare cycles at the moment.
Perhaps the best course of action is to roll back https://go-review.googlesource.com/34770 (@bradfitz, others, WDYT?), and when @mpvl has some free time again (ha!), start a conversation on golang-dev about re-rolling it forward?

See also #18582 "x/net/idna: recent change adds ~200KB of machine code to any program using x/net/http2".

+1 for rolling back for now – although good luck waiting until @mpvl has "free time again", haha, I went through this recently and I can tell you that you can wait a long time :P.

I mailed out a "git revert" CL at https://go-review.googlesource.com/#/c/35270/

Picking this up from my absence.
The ToASCII documentation states that it will return an error when it encounters one (i.e. if the input is not valid IDNA label). *.uk is an invalid domain name by IDNA2003, IDNA2008,  and UTS 46, so I would expect it to return an error. Am I missing something?
As for the empty string, labels are required to be length 1-63. Arguable, the empty string is a sequence of zero labels, so this requirement should not apply. If there is good arguments in favor I could see we should adopt this interpretation.

Thanks for the feedback @mpl. The main argument I had is that the code suddenly break, whereas the commit message was explicitly mentioning BC.
If BC is not guaranteed, then I think this should be explicit. I know for sure a few implementations that will break with this change (one of them is code I directly have to maintain), hence we'll have to plan accordingly.
The empty string is not a big deal, if that's not going to be valid, I can handle the case specifically. Although I would suggest to consider simply returning an empty string as it may be simplifying usage (specifically, avoid to wrap any single execution around an empty string check). I understand this is a kind of selfish request as a consumer, that may not fit into the POV of a provider.
As for *.uk, what I can tell is that in pretty much all the cases I've seen around (in Go or different languages), passing an ASCII string into an UnicodeToPunycode converter, would simply return the string itself (as it's already ASCII hence Punycode). Conversely, if the string contains any Unicode char, this is converted into Punycode.
It seems to me that that was also the original implementation (or the current) of the Go IDNA library. However, the change you make seems to be more inclined to consider the input as a domain name itself, rather than considering the chars that compose the string.
This  may pose interesting questions. Let's suppose I want to convert *.faß.de to *.fass.de or *.网址 to *.xn--ses554g. Both are valid use cases for the Public Suffix, and any Unicode to Punycode library I've encountered so far is happy to perform the translation. If that's not a valid use case for this library, do you have any suggestion on the recommended approach? Again, the current code is perfectly happy to perform this translation.

The backwards compatibility applies to the API, not which strings are accepted. The old implementation violated the rules of the IDNA spec. The latest change basically fixed these bugs.
I understand what you're saying and see where the issue is coming from. There is a discrepancy in the old implementation between the documentation and the implementation. The package documentation states the packages implements the various IDNA RFCs (or at least is supposed to). The ToASCII comment makes clear it is operating on domain names, as does the package name.
However, the implementation merely split on dots and then applies a punycode conversion. So indeed it (almost) behaved like a simple punycode converter if you pass it a label. But if you follow the package documentation this is a bug.
So we can do two things here:

Change the package documentation
Expose the punycode algorithm under a different API within this or another package, and leave the semantics of the API as documented.

Unless there is strong objections, I think it should be 2. idna.ToASCII strongly suggests it implements the RFC spec mentioned before. If it is redefined to be a punycode converter,  the actual idna API is likely going to be awkward and confusing.
As for *.faß.de being valid, I've been going with both what browers do and what http://unicode.org/cldr/utility/idna.jsp spews out. The latter, for example, seems unhappy with such input. Note however that the new idna package would still do the conversion for you as suggested (returning *.fass.de and *.xn--ses554g), it would just also report the input is erroneous. This is the behavior prescribed by UTS 46.

Can we back up a bit? I did the original x/net/idna implementation many years ago, but haven't followed the latest developments that closely.
The original implementation was purely algorithmic, with no tables. Can you give some examples of IDNA names that that algorithm gets 'wrong', and we now need tables to understand?
On #18582, you also mention comparing the code size increase relative to $THIS_THING instead of $THAT_THING. So there are actually two sets of tables ('old' and 'new')?? Again, I'm not familiar with the context here. Can you give some example inputs where the two implementations give different output?

I encountered panics following the merge of the now-reverted CL from within the library in some unit tests checking for edge cases. Prior to the revert, idna.ToUnicode("xn--") panics rather than returning an error, resulting from an index out of range here.
Couple of other examples that trigger panics in this example snippet below:
func TestToUnicode(t *testing.T) {
	testData := map[string]string{
		"xn--":     "",     // panics golang.org/x/net/idna
		"foo.xn--": "foo",  // panics golang.org/x/net/idna
		"xn--.foo": ".foo", // panics golang.org/x/net/idna
	}

	for input, expected := range testData {
		output, err := idna.ToUnicode(input)
		if err != nil {
			t.Errorf("Failed to convert %q to unicode: %s", input, err)
		}

		if output != expected {
			t.Errorf("Expected %q, got %q", expected, output)
		}
	}
}

It's fine that these are invalid; I just would prefer the library not panic when we can return an error back instead.
cc @cee-dub

@mikioh: the package has always claims to implement RFC 5890, RFC 5891, RFC 5892, RFC 5893 and RFC 5894, not 4343 or 7564. The latter two are related but different. For example, putting the strings in NFC is mentioned as a MUST. And indeed not doing so can lead to very unexpected results or even security issues.
@nigeltao: More context: I've not changed what the package claims to implement, I've merely implemented what it claimed to implement. Note that these RFCs prescribe not just punycode and the old implementation was quite incomplete. I assume, given the package name, that the intention was to really implement these RFCs and that the list of RFCs supported is not a documentation bug.
Assuming this is correct, there are two ways to implement this: add a bunch of transforms on top of the punycode. This is attempted by net/http in Go 1.8. This is very hard to get right, though, and also is less efficient than doing the alternative. The alternative is to implement UTS 46. Most implementations in browsers, for example, are based on this. It provides tables that removes the need for a lot of intricate code and is faster than applying a bunch of transforms in sequence.
UTS 46 is more permissive than then the RFCs but otherwise fully compliant in non-transitional mode.
A nice demo/playground to view the differences between IDNA2008, IDNA2003 and UTS46 can be found here: http://unicode.org/cldr/utility/idna.jsp.

@alextoombs that is simply a bug. See https://go-review.googlesource.com/#/c/36280/.
cc @cee-dub
It seems that such input is okay. With idna.VerifyDNSLength can enable stricter checking.

I remain of the opinion that the new implementation, albeit a big change, fixes (many) bugs of the old one. It is unfortunate that people have relied on, IMHO, unintended and undocumented semantics.
Exposing the raw Punycode algorithm seems one solution. However, from what I gather what people want is not to process raw labels, but rather still domain names but with special characters that are normally illegal.  So a nicer API may be to allow an option in the idna package to permit a set of otherwise disallowed runes, like "".  This will avoid the error in the case of "". This way the usual error checking is retained while still permitting such cases as *.faß.de.  Comments?

@mpvl,
Thanks for the explanation and references, especially https://tools.ietf.org/html/rfc5894#section-4.4. For the case preservation on ToASCII with LDH/A-labels, I think it's fine as it is,  or with a brief summary of https://tools.ietf.org/html/rfc5894#section-4.4 to notify people who work on DNS infrastructure applications.

@mikioh: I seem you suggest to preserve case on ToASCII.
Here is my proposal to accommodate that. In addition to the Lookup and Register cases of IDNA, we support a "Raw" or "Punycode" profile which preserves case and does minimal checking.  The existing ToUnicode and ToASCII functions will use this profile. This may be a bit of an odd choice, but supports maximum compatibility and allows table growth to be kept at a minimum.
Users can use the Lookup or other profiles, or create their own, for different purposes.

@mpvl,

I seem you suggest to preserve case on ToASCII.

Nope, sorry I wasn't clear. My comment I think it's fine as it is is just for https://go-review.googlesource.com/34770; I wrote the comment while reading the CL. I agree that the package idna should focus on IDNA (and people who work on DNS infrastructure applications must be aware of the requirements for IDNA-aware applications are different from DNS servers, registrars and registries.)

@mikioh Ah okay. Please take a look at https://go-review.googlesource.com/#/c/36512/. (not sure why this issue wasn't updated).
I've now adopted the semantics that a zero Profile only does Punycode and that any validation is optional. A few pre-made profiles are provided for Lookup and Registration cases of the idna. One could argue that at least a normalization check should at least always be in there, but that's also the largest table. So this semantics also addresses #18582. If validation is not used, tables are not linked.
I think this is an acceptable API whilst having the highest backwards compatibility and still being within the spirit of IDNA. If one squints one's eyes a bit, this is what the RFC intended. :)


Relicense to dual MIT/Apache-2.0

This pull request was automatically generated because my scripts detected that
everyone in the relicensing issue agreed to
relicensing.
License headers in files were not updated, if they exist. I've reproduced an
example license header below if you want to copy-paste it in. If you don't
have license headers, don't feel compelled to add
them.
// Copyright 2016 shutdown_hooks_rs Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

I recommend publishing a new patch version (the z in x.y.z) so that the
metadata propagates to crates.io.
Please be sure to check the README.md for style. I've try to
review these PRs as they go out, but I might miss something.
Thanks for relicensing!
(For my bookkeeping: this is repository id shutdown_hooks_rs-fc9f2463-9942-489b-9530-9867248fb206)

Thank you :) I'll fix up any formatting issues that slipped by tonight and push out a new version through the week some time


workflow: build and deploy: Change name to deploy on release tag

Tags can happen on any branch, not just on master, for example for ESR.
Changelog-entry: Rename deploy workflow
Signed-off-by: Alex Gonzalez<EMAIL_ADDRESS>

@balena-ci I self-certify!


Odd behavior generating clang arguments

I've discovered odd behavior with how bindgen generates flags to pass to clang. In particular, I added a println! here to print the clang_args variable.
Bindgen Invocation and Results
Here are three different invocations of bindgen along with the value of clang_args that was printed as a result:

bindgen bindgen.h

["--target=x86_64-apple-darwin", "-isystem", "/Library/Developer/CommandLineTools/usr/include/c++/v1", "-isystem", "/usr/local/include", "-isystem", "/Library/Developer/CommandLineTools/usr/lib/clang/9.1.0/include", "-isystem", "/Library/Developer/CommandLineTools/usr/include", "-isystem", "/usr/include", "-isystem", "/System/Library/Frameworks", "-isystem", "/Library/Frameworks", "bindgen.h"]

bindgen bindgen.h -- -I foo

["--target=x86_64-apple-darwin", "-I", "foo", "-isystem", "/Library/Developer/CommandLineTools/usr/include/c++/v1", "-isystem", "/usr/local/include", "-isystem", "/Library/Developer/CommandLineTools/usr/lib/clang/9.1.0/include", "-isystem", "/Library/Developer/CommandLineTools/usr/include", "-isystem", "/usr/include", "-isystem", "/System/Library/Frameworks", "-isystem", "/Library/Frameworks", "bindgen.h"]

bindgen bindgen.h -- -foo bar

["--target=x86_64-apple-darwin", "-foo", "bar", "bindgen.h"]

bindgen bindgen.h -- --target=foo

["--target=foo", "bindgen.h"]

Expected Results
Unrecognized flags such as -foo shouldn't affect other flags that are passed, such as -isystem. I'm not sure whether --target altering what flags are passed is intentional; at the least, bindgen seems smart enough to realize that the --target argument should replace the default --target=x86_64-apple-darwin.
I found this while debugging https://github.com/rust-lang-nursery/rust-bindgen/issues/1331, and I suspect that they may be related.

Ah, that's a shame. Oh well. I understand the limitations, though.

Alright, closing then.
Note that there's #297 to consider moving away from libclang, which presumably would allow us to get better error information... But that's a bigger undertaking as well :)


New proposals now written to DB

I broke something with #292
NODE-WATCHER: Error: Variable '$data' expected value of type 'ProposalStatusCreateInput!' but got: {"blockNumber":{"connect":{"number":1915200}},"proposal":{"connect":{"proposalId":17}},"status":"Tabled"}. Reason: 'uniqueStatus' Expected non-null value, found null. (line 1, column 11):
mutation ($data: ProposalStatusCreateInput!) {
          ^
    at BatchedGraphQLClient.<anonymous> (/node_watcher/node_modules/http-link-dataloader/src/BatchedGraphQLClient.ts:74:13)
    at step (/node_watcher/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:40:23)
    at Object.next (/node_watcher/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:21:53)
    at fulfilled (/node_watcher/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:12:58)
    at processTicksAndRejections (internal/process/task_queues.js:88:5) {
  result: { data: null, errors: [ [Object] ], status: 200 }
}

it looks like the image we use isn't from master.

Weird, what's in master is not the same sha as the last image https://github.com/paritytech/Nomidot/pull/293/files reverting to that.

I can't understand that. master has the image sha 38a.. here: https://github.com/paritytech/Nomidot/blame/master/back/node_watcher/kubernetes/nomidotwatcher-last-50k-job.yaml#L30
from #284
Which should have been changed then by #293 for f88... but this simply does appear anywhere.

@yjkimjunior can you make sense of this ^ it looks like #293 just never happened!


Configuration of ad response timeout

Hi,
Seems the option responseTimeout of VPAIDAdUnitWrapper is hardcoded as 5 seconds. Sometimes it's necessary to make it longer to increase ads fill rate. So is there anyway to override it from outside? Just like what adsCancelTimeout does.
Thanks.

@qlxucn You are right this timer should be configurable. I have labeled the issue as an enhancement and we will try to solve it as soon as possible.
Wanna try doing the PR yourself?

@carpasse No problem, I will provide a PR after my work. Thanks.


Performance issues on grpc api

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug
I connected the unit test from pyedb. First test from passed but was slow. Since I can switch the test from .NET to grpc, using the same code, same project here is a picture from the difference directly printed from the code execution (time is in second)
same command from unit test grpc and .NET
selected_pins = [pin for pin in self._pedb.components.components[ref].pins.values()
if pin.net_name in net_list and pin.is_pin]
PyEDB INFO: EDB initialized.
PASSED [100%]Fetching pins belonging to net DDR4_DQS0_P and DDR4_DQS0_N
time_elapsed grpc api : 62.692482233047485
Fetching pins belonging to net DDR4_DQS0_P and DDR4_DQS0_N
time_elapsed grpc api : 62.796724796295166
PyEDB INFO: EDB initialized.
PASSED [100%]Fetching pins usinh .NET api
time_elapsed .NET api : 0.07809185981750488
Fetching pins usinh .NET api
time_elapsed .NET api : 0.0821077823638916
this command is retrieving pins (e.g. padstack instances with checking the net_name)
📝 Steps to reproduce
NA
💻 Which operating system are you using?
Windows
📀 Which ANSYS version are you using?
NA
🐍 Which Python version are you using?
3.9
📦 Installed packages
NA

the number of queries is the real bottleneck here. two options:

do filtering on backend

pins = components.pins(net=net_list, is_pin: True)

send back all attributes of PadstackInstance to avoid n + 1 queries

components.pins
#=> [
#   PadstackInstance({ id: 1, net_name: "net1", is_pin: True }),
#   PadstackInstance({ id: 2, net_name: "net2", is_pin: False })
#   # etc
# ]

closing this issue. It seems to be related to pyedb code. So I have to investigate on my side before performing addionnal tests.


Allow translations and multiple language website

I created a specific branch for multilingual and language switcher to replace pull request https://github.com/digitalcraftsman/hugo-icarus-theme/pull/100 which was on my master branch

A flag is shown on the top bar to change language
Every specific words of the theme can be translated with lang.toml in the i18n folder

Thank you, already merged that into my local repository :D


Pattern grid displays machine from one mod, creates pattern for a different mod.

Trying to create a pattern for an IC2 generator. Pattern grid displays correct materials and output for IC2 machine, but it will create a pattern for a RS machine.

???

https://drive.google.com/open?id=0Bwtrqbm8rR01SmZXdWFMdzIzOGs

That is not a problem! It just says that the pattern disc belongs to the RS mod. Put it into a crafter and it will work as intended.

Like @Harith163 said, that is just the WAILA mod reporting that the pattern item belongs to RS.

Sorry.

No problem!


FancyZones 0.67 does not move window to zones when changing monitors with same zone layout but different resolutions

Microsoft PowerToys version
0.67
Installation method
GitHub, PowerToys auto-update
Running as admin
No
Area(s) with issue?
FancyZones
Steps to reproduce
Relevant options ticked: Keep windows in their zones when screen resolution changes, during zone layout changes windows assigned to a zone match new size/positions

Have 2 monitors (e.g. laptop and external screen) of different resolutions
Configure Windows to only show 1 monitor, e.g. if external is plugged in then laptop display turns off
Assign the same custom canvas layout to both monitors
Switch to small monitor
Arrange windows in zones
Activate larger monitor (e.g. plugging in external monitor)

✔ Expected Behavior
I expect windows to line up in same zones.
Small monitor:

Expected large monitor:

❌ Actual Behavior
Windows stay the same size as they were on the smaller (laptop) monitor while their top-left corners are positioned at the top-left of the zones they are meant to be in
Actual large monitor after plugging it in:

Other Software
No response

I'm running into a similar issue where the key-bindings just stop working when switching between zones on different monitors with different resolutions (1-Horizontal, 1-Vertical). Attempting to enable/disable FancyZones doesn't rebind, only a full exit/reopen will allow usage of the Win+[arrows] on the same monitor. Interestingly, enabling the "Show zones on all monitors while dragging a window" and then drag-dropping the window into zones on a different monitor works fine.

This issue is a duplicate of https://github.com/microsoft/PowerToys/issues/23820. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!


#001 Creating Youtube Rendering functionality

[x] Create a logger.
[x] Create a custom exception.
[x] Youtube file to deal with this module.
[x] Manual check in a jupyter notebook.

It is done


Add multi-hop swap unit test

Multi-hop swap unit tests.
Currently failing with exp 6000000 but got 1999999. (fixed)

Codecov Report

Merging #16 (acce6fe) into wasm-integration-2 (12627c1) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head acce6fe differs from pull request most recent head 31ba019. Consider uploading reports for the commit 31ba019 to get more accurate results

@@                 Coverage Diff                 @@
##           wasm-integration-2      #16   +/-   ##
===================================================
  Coverage               20.92%   20.92%
===================================================
  Files                     201      201
  Lines                   25453    25453
===================================================
  Hits                     5326     5326
  Misses                  19164    19164
  Partials                  963      963

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 12627c1...31ba019. Read the comment docs.


Encoding limited to 25 fps

I am encoding a live application, capturing from screen and feeding the encoder frames at a framerate of 30fps. However the output encoded stream is 25 fps, this generates a decoder delay that increases over time.
I can't find why this is.
If I set my application to run at 25 fps then both run at the same speed and the decoder catches up, but so far it's impossible to get a 30fps output stream.
This seems related to: #1394
Thanks for the library!

can you output the log and check the lines with "EncoderStatistics"? what is the "SpeedInMs" value there?

@chuckleplant  if you still have questions on this, please submit a new issue and attach the logs.
we will follow this continually. thanks!


UE4 4.22.2 needs MS Visual C++ 2013 runtime on Windows Server 2019

Output of the ue4-docker info command:
(venv) PS C:\Users\localadmin> python -m ue4docker info
ue4-docker version:         0.0.34 (latest available version is 0.0.35)
Operating system:           Windows Server 2019 Standard Version 1809 (OS Build 17763.557)
Docker daemon version:      18.09.5
NVIDIA Docker supported:    No
Maximum image size:         200GB
Available disk space:       863.19 GiB
Total system memory:        63.89 GiB physical, 73.39 GiB virtual
Number of processors:       20 physical, 40 logical

Command-line used:
python -m ue4docker build 4.22.2 --no-engine --pull-prerequisites -username TBBle

I didn't record the entire failure log (sorry), but the line I identified during a later stage (something about InstalledDDC) of the ue4-minimal image build was:
LogModuleManager: Warning: ModuleManager: Unable to load module 'C:/UnrealEngine/LocalBuilds/InstalledDDC/Engine/Binaries/Win64/UE4Editor-MeshUtilities.dll' because the file couldn't be loaded by the OS.

The failure that failed the container build was an assertion during a cook step by FModuleManager that MeshUtilities had been loaded, and that suggests the above error is the cause of the failure.
I extracted the Win64 directory, and fed UE4Editor-MeshUtilities.dll into Dependencies and noticed:

A quick check shows that msvcr120.dll and msvcp120.dll are not in C:\Windows\system32 inside the container, but are present on the host Windows Server 2019.
So as a quick hack, I've added those two files to the return list of WindowsUtils.requiredHostDlls:
	@staticmethod
	def requiredHostDlls(basetag):
		'''
		Returns the list of required host DLL files for the specified container image base tag
		'''

		# `ddraw.dll` is only required under Windows Server 2016 version 1607
		common = ['dsound.dll', 'opengl32.dll', 'glu32.dll', 'msvcp120.dll', 'msvcr120.dll']
		return ['ddraw.dll'] + common if basetag == 'ltsc2016' else common

and am retesting the build.
python -m ue4docker build 4.22.2 --no-engine -username TBBle

I've not built ue4-docker images for 4.22.2 before now, so I have no baseline, and hence I've not yet proven that the problem is actually that these DLLs are missing.
I'm not familiar with Epic's third-party management (i.e, the "Getting Dependencies" hook in their git repo) so I don't know how to go see if this is a recently-introduced issue by a third-party library upgrade to their Intel TBB binaries as part of the 4.22.2 point-release, if this has always been an issue, or if there's something funny about this build system that is causing it to build against UE4Editor-MeshUtilities.dll against embree.2.14.0.dll and that would normally not be done.

Sorry, I did capture the end of the build log, but I had it sitting in an open gvim session. Here's the failed build stage:
****** [9/10] Build DDC Win64

Reading local file list from C:\UnrealEngine\Engine\Saved\BuildGraph\Compile UE4Editor Win64\Tag-UE4Editor Win64.xml
Reading local file list from C:\UnrealEngine\Engine\Saved\BuildGraph\Build Tools Win64\Tag-Build Tools Win64.xml
Reading local file list from C:\UnrealEngine\Engine\Saved\BuildGraph\Compile UnrealHeaderTool Win64\Tag-Compile UnrealHeaderTool Win64.xml
Reading local file list from C:\UnrealEngine\Engine\Saved\BuildGraph\Update Version Files\Tag-Update Version Files.xml
Reading local file list from C:\UnrealEngine\Engine\Saved\BuildGraph\Build Tools CS\Tag-Build Tools CS.xml
Reading local file list from C:\UnrealEngine\Engine\Saved\BuildGraph\Build Tools CS\Tag-Build Tools CS Binaries.xml
Reading shared manifest from C:\UnrealEngine\Engine\Saved\BuildGraph\Compile UE4Editor Win64\Manifest-UE4Editor Win64.xml
Reading shared manifest from C:\UnrealEngine\Engine\Saved\BuildGraph\Compile UE4Editor Win64\Manifest-UE4Editor Win64+UE4Editor Win64 Unstripped.xml
Reading shared manifest from C:\UnrealEngine\Engine\Saved\BuildGraph\Build Tools Win64\Manifest.xml
Reading shared manifest from C:\UnrealEngine\Engine\Saved\BuildGraph\Compile UnrealHeaderTool Win64\Manifest.xml
Reading shared manifest from C:\UnrealEngine\Engine\Saved\BuildGraph\Build Tools CS\Manifest.xml
Reading shared manifest from C:\UnrealEngine\Engine\Saved\BuildGraph\Build Tools CS\Manifest-Build Tools CS Binaries.xml
Copying 27960 files from C:\UnrealEngine to C:\UnrealEngine\LocalBuilds\InstalledDDC...
Copying 115 files from C:\UnrealEngine\Engine\Saved\CsTools to C:\UnrealEngine\LocalBuilds\InstalledDDC...
Running: C:\UnrealEngine\Engine\Binaries\DotNET\AutomationTool.EXE -nop4 BuildDerivedDataCache -TempDir="C:\UnrealEngine\LocalBuilds\InstalledDDC" -FeaturePacks=Templates/FP_FirstPersonBP/FP_FirstPersonBP.uproject;Templates/TP_FlyingBP/TP_FlyingBP.uproject;Templates/TP_HandheldARBP/TP_HandheldARBP.uproject;Templates/TP_RollingBP/TP_RollingBP.uproject;Templates/TP_SideScrollerBP/TP_SideScrollerBP.uproject;Templates/TP_ThirdPersonBP/TP_ThirdPersonBP.uproject;Templates/TP_TopDownBP/TP_TopDownBP.uproject;Templates/TP_TwinStickBP/TP_TwinStickBP.uproject;Templates/TP_VehicleBP/TP_VehicleBP.uproject;Templates/TP_PuzzleBP/TP_PuzzleBP.uproject;Templates/TP_2DSideScrollerBP/TP_2DSideScrollerBP.uproject;Templates/TP_VehicleAdvBP/TP_VehicleAdvBP.uproject;Samples/StarterContent/StarterContent.uproject;Samples/MobileStarterContent/MobileStarterContent.uproject;Templates/TP_VirtualRealityBP/TP_VirtualRealityBP.uproject -TargetPlatforms=Windows+WindowsNoEditor -HostPlatform=Win64 -SavedDir="C:\UnrealEngine/Engine/Saved\Installed\Win64"
  Parsing command line: -nop4 BuildDerivedDataCache -TempDir=C:\UnrealEngine\LocalBuilds\InstalledDDC -FeaturePacks=Templates/FP_FirstPersonBP/FP_FirstPersonBP.uproject;Templates/TP_FlyingBP/TP_FlyingBP.uproject;Templates/TP_HandheldARBP/TP_HandheldARBP.uproject;Templates/TP_RollingBP/TP_RollingBP.uproject;Templates/TP_SideScrollerBP/TP_SideScrollerBP.uproject;Templates/TP_ThirdPersonBP/TP_ThirdPersonBP.uproject;Templates/TP_TopDownBP/TP_TopDownBP.uproject;Templates/TP_TwinStickBP/TP_TwinStickBP.uproject;Templates/TP_VehicleBP/TP_VehicleBP.uproject;Templates/TP_PuzzleBP/TP_PuzzleBP.uproject;Templates/TP_2DSideScrollerBP/TP_2DSideScrollerBP.uproject;Templates/TP_VehicleAdvBP/TP_VehicleAdvBP.uproject;Samples/StarterContent/StarterContent.uproject;Samples/MobileStarterContent/MobileStarterContent.uproject;Templates/TP_VirtualRealityBP/TP_VirtualRealityBP.uproject -TargetPlatforms=Windows+WindowsNoEditor -HostPlatform=Win64 -SavedDir=C:\UnrealEngine/Engine/Saved\Installed\Win64
  Generating DDC data for FP_FirstPersonBP on Windows+WindowsNoEditor
  Running UE4Editor DerivedDataCache for project C:\UnrealEngine\Templates\FP_FirstPersonBP\FP_FirstPersonBP.uproject
  Commandlet log file is C:\UnrealEngine\Engine\Programs\AutomationTool\Saved\DerivedDataCache-2019.06.18-16.55.31.txt
  Running: C:\UnrealEngine\LocalBuilds\InstalledDDC\Engine\Binaries\Win64\UE4Editor-Cmd.exe C:\UnrealEngine\Templates\FP_FirstPersonBP\FP_FirstPersonBP.uproject -run=DerivedDataCache  -TargetPlatform=Windows+WindowsNoEditor -fill -DDC=CreateInstalledEnginePak -ProjectOnly -abslog=C:\UnrealEngine\Engine\Programs\AutomationTool\Saved\DerivedDataCache-2019.06.18-16.55.31.txt -stdout -CrashForUAT -unattended -NoLogTimes
    LogConsoleResponse: Display: Failed to find resolution value strings in scalability ini. Falling back to default.
    LogInit: Display: Running engine for game: FP_FirstPersonBP
    LogHAL: Display: Platform has ~ 64 GB [68602970112 /<PHONE_NUMBER>6 / 64], which maps to Largest [LargestMinGB=32, LargerMinGB=12, DefaultMinGB=8, SmallerMinGB=6, SmallestMinGB=0)
    LogTemp: Display: Module 'AllDesktopTargetPlatform' loaded TargetPlatform 'AllDesktop'
    LogTemp: Display: Module 'MacClientTargetPlatform' loaded TargetPlatform 'MacClient'
    LogTemp: Display: Module 'MacNoEditorTargetPlatform' loaded TargetPlatform 'MacNoEditor'
    LogTemp: Display: Module 'MacServerTargetPlatform' loaded TargetPlatform 'MacServer'
    LogTemp: Display: Module 'MacTargetPlatform' loaded TargetPlatform 'Mac'
    LogTemp: Display: Module 'WindowsClientTargetPlatform' loaded TargetPlatform 'WindowsClient'
    LogTemp: Display: Module 'WindowsNoEditorTargetPlatform' loaded TargetPlatform 'WindowsNoEditor'
    LogTemp: Display: Module 'WindowsServerTargetPlatform' loaded TargetPlatform 'WindowsServer'
    LogTemp: Display: Module 'WindowsTargetPlatform' loaded TargetPlatform 'Windows'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ASTC'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ATC'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_DXT'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ETC1'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ETC1a'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ETC2'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_PVRTC'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'AndroidClient'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ASTCClient'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ATCClient'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_DXTClient'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ETC1Client'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ETC1aClient'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_ETC2Client'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_PVRTCClient'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_Multi'
    LogTemp: Display: Module 'AndroidTargetPlatform' loaded TargetPlatform 'Android_MultiClient'
    LogTemp: Display: HTML5 SDK path "C:/UnrealEngine/LocalBuilds/InstalledDDC/Engine/Extras/ThirdPartyNotUE/emsdk/Win64", does not exist!
    LogTemp: Display: HTML5 SDK path "C:/UnrealEngine/LocalBuilds/InstalledDDC/Engine/Extras/ThirdPartyNotUE/emsdk/Win64", does not exist!
    LogTemp: Display: Module 'IOSTargetPlatform' loaded TargetPlatform 'IOSClient'
    LogTemp: Display: Module 'IOSTargetPlatform' loaded TargetPlatform 'IOS'
    LogTemp: Display: Module 'TVOSTargetPlatform' loaded TargetPlatform 'TVOSClient'
    LogTemp: Display: Module 'TVOSTargetPlatform' loaded TargetPlatform 'TVOS'
    LogTemp: Display: Module 'LuminTargetPlatform' loaded TargetPlatform 'Lumin'
    LogTemp: Display: Module 'LuminTargetPlatform' loaded TargetPlatform 'LuminClient'
    LogTargetPlatformManager: Display: Building Assets For WindowsNoEditor
    LogTargetPlatformManager: Display: Building Assets For Windows
    LogAudioDebug: Display: Lib vorbis DLL was dynamically loaded.
    LogShaderCompilers: Display: Using Local Shader Compiler.
    LogDerivedDataCache: Display: Max Cache Size: 512 MB
    LogDerivedDataCache: Display: Starting with empty Boot cache
    LogDerivedDataCache: Display: Pak cache opened for writing ../../../Engine/DerivedDataCache/Compressed.ddp.88E643074C0EDA5BDA9E63988CC07537.
    LogDerivedDataCache: Display: Files in ../../../Engine/DerivedDataCache will be touched.
    LogShaderCompilers: Display: Shaders left to compile 1820
    LogShaderCompilers: Display: Shaders left to compile 1810
    LogShaderCompilers: Display: Shaders left to compile 1800
    LogShaderCompilers: Display: Shaders left to compile 1790
    LogModuleManager: Warning: ModuleManager: Unable to load module 'C:/UnrealEngine/LocalBuilds/InstalledDDC/Engine/Binaries/Win64/UE4Editor-MeshUtilities.dll' because the file couldn't be loaded by the OS.
    LogShaderCompilers: Display: Shaders left to compile 1780
    LogShaderCompilers: Display: Shaders left to compile 1770
    LogShaderCompilers: Display: Shaders left to compile 1760
    LogShaderCompilers: Display: Shaders left to compile 1750
    LogShaderCompilers: Display: Shaders left to compile 1740
    LogShaderCompilers: Display: Shaders left to compile 1730
    LogShaderCompilers: Display: Shaders left to compile 1720
    LogShaderCompilers: Display: Shaders left to compile 1710
    LogShaderCompilers: Display: Shaders left to compile 1700
    LogShaderCompilers: Display: Shaders left to compile 1690
    LogShaderCompilers: Display: Shaders left to compile 1680
    LogShaderCompilers: Display: Shaders left to compile 1670
    LogShaderCompilers: Display: Shaders left to compile 1660
    LogShaderCompilers: Display: Shaders left to compile 1650
    LogShaderCompilers: Display: Shaders left to compile 1640
    LogShaderCompilers: Display: Shaders left to compile 1630
    LogShaderCompilers: Display: Shaders left to compile 1620
    LogShaderCompilers: Display: Shaders left to compile 1610
    LogShaderCompilers: Display: Shaders left to compile 1600
    LogShaderCompilers: Display: Shaders left to compile 1590
    LogShaderCompilers: Display: Shaders left to compile 1580
    LogShaderCompilers: Display: Shaders left to compile 1570
    LogShaderCompilers: Display: Shaders left to compile 1560
    LogShaderCompilers: Display: Shaders left to compile 1550
    LogShaderCompilers: Display: Shaders left to compile 1540
    LogShaderCompilers: Display: Shaders left to compile 1530
    LogShaderCompilers: Display: Shaders left to compile 1520
    LogWindows: Error: begin: stack for UAT
    LogWindows: Error: === Critical error: ===
    LogWindows: Error:
    LogWindows: Error: Assertion failed: Module [File:C:\UnrealEngine\Engine\Source\Runtime\Core\Private\Modules\ModuleManager.cpp] [Line: 373]
    LogWindows: Error: MeshUtilities
    LogWindows: Error:
    LogWindows: Error:
    LogWindows: Error: [Callstack] 0x00007ff9c0249149 KERNELBASE.dll!UnknownFunction []
    LogWindows: Error: [Callstack] 0x00007ff9aed99df7 UE4Editor-Core.dll!ReportAssert() [c:\unrealengine\engine\source\runtime\core\private\windows\windowsplatformcrashcontext.cpp:553]
    LogWindows: Error: [Callstack] 0x00007ff9aed9c9d7 UE4Editor-Core.dll!FWindowsErrorOutputDevice::Serialize() [c:\unrealengine\engine\source\runtime\core\private\windows\windowserroroutputdevice.cpp:79]
    LogWindows: Error: [Callstack] 0x00007ff9aebb8bca UE4Editor-Core.dll!FOutputDevice::LogfImpl() [c:\unrealengine\engine\source\runtime\core\private\misc\outputdevice.cpp:71]
    LogWindows: Error: [Callstack] 0x00007ff9aeb40577 UE4Editor-Core.dll!FDebug::AssertFailed() [c:\unrealengine\engine\source\runtime\core\private\misc\assertionmacros.cpp:440]
    LogWindows: Error: [Callstack] 0x00007ff9aeb41049 UE4Editor-Core.dll!FDebug::CheckVerifyFailedImpl() [c:\unrealengine\engine\source\runtime\core\private\misc\assertionmacros.cpp:418]
    LogWindows: Error: [Callstack] 0x00007ff9aee9f9f2 UE4Editor-Core.dll!DispatchCheckVerify<void,<lambda_5fec1e1801a68e0878de1879580bd439> >() [c:\unrealengine\engine\source\runtime\core\public\misc\assertionmacros.h:161]
    LogWindows: Error: [Callstack] 0x00007ff9aebb7614 UE4Editor-Core.dll!FModuleManager::LoadModuleChecked() [c:\unrealengine\engine\source\runtime\core\private\modules\modulemanager.cpp:373]
    LogWindows: Error: [Callstack] 0x00007ff9a9ed2785 UE4Editor-Engine.dll!BuildStaticMeshDerivedDataKey() [c:\unrealengine\engine\source\runtime\engine\private\staticmesh.cpp:1573]
    LogWindows: Error: [Callstack] 0x00007ff9a9ed33f7 UE4Editor-Engine.dll!FStaticMeshRenderData::Cache() [c:\unrealengine\engine\source\runtime\engine\private\staticmesh.cpp:1694]
    LogWindows: Error: [Callstack] 0x00007ff9a9ed3ff5 UE4Editor-Engine.dll!UStaticMesh::CacheDerivedData() [c:\unrealengine\engine\source\runtime\engine\private\staticmesh.cpp:3454]
    LogWindows: Error: [Callstack] 0x00007ff9a9f00a52 UE4Editor-Engine.dll!UStaticMesh::PostLoad() [c:\unrealengine\engine\source\runtime\engine\private\staticmesh.cpp:3867]
    LogWindows: Error: [Callstack] 0x00007ff9b12661ab UE4Editor-CoreUObject.dll!UObject::ConditionalPostLoad() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\obj.cpp:1052]
    LogWindows: Error: [Callstack] 0x00007ff9a9bbbef2 UE4Editor-Engine.dll!UBodySetup::PostLoad() [c:\unrealengine\engine\source\runtime\engine\private\physicsengine\bodysetup.cpp:912]
    LogWindows: Error: [Callstack] 0x00007ff9b12661ab UE4Editor-CoreUObject.dll!UObject::ConditionalPostLoad() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\obj.cpp:1052]
    LogWindows: Error: [Callstack] 0x00007ff9b131ba3d UE4Editor-CoreUObject.dll!EndLoad() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectglobals.cpp:1576]
    LogWindows: Error: [Callstack] 0x00007ff9b130afc7 UE4Editor-CoreUObject.dll!<lambda_658a191635acc4c238f74bca42f9ae9d>::operator()() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectglobals.cpp:1215]
    LogWindows: Error: [Callstack] 0x00007ff9b132d69c UE4Editor-CoreUObject.dll!LoadPackageInternal() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectglobals.cpp:1316]
    LogWindows: Error: [Callstack] 0x00007ff9b132c6da UE4Editor-CoreUObject.dll!LoadPackage() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectglobals.cpp:1411]
    LogWindows: Error: [Callstack] 0x00007ff9b133bd29 UE4Editor-CoreUObject.dll!ResolveName() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectglobals.cpp:751]
    LogWindows: Error: [Callstack] 0x00007ff9b134605b UE4Editor-CoreUObject.dll!StaticLoadObjectInternal() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectglobals.cpp:813]
    LogWindows: Error: [Callstack] 0x00007ff9b1345823 UE4Editor-CoreUObject.dll!StaticLoadObject() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectglobals.cpp:888]
    LogWindows: Error: [Callstack] 0x00007ff9a92e5ec9 UE4Editor-Engine.dll!ConstructorHelpersInternal::FindOrLoadObject<UStaticMesh>() [c:\unrealengine\engine\source\runtime\coreuobject\public\uobject\constructorhelpers.h:36]
    LogWindows: Error: [Callstack] 0x00007ff9a9598d24 UE4Editor-Engine.dll!ADefaultPawn::ADefaultPawn() [c:\unrealengine\engine\source\runtime\engine\private\defaultpawn.cpp:56]
    LogWindows: Error: [Callstack] 0x00007ff9b10f610f UE4Editor-CoreUObject.dll!UClass::CreateDefaultObject() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\class.cpp:3076]
    LogWindows: Error: [Callstack] 0x00007ff9b1348f86 UE4Editor-CoreUObject.dll!UObjectLoadAllCompiledInDefaultProperties() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectbase.cpp:789]
    LogWindows: Error: [Callstack] 0x00007ff9b13325df UE4Editor-CoreUObject.dll!ProcessNewlyLoadedUObjects() [c:\unrealengine\engine\source\runtime\coreuobject\private\uobject\uobjectbase.cpp:869]
    LogWindows: Error: [Callstack] 0x00007ff6adb6cf44 UE4Editor-Cmd.exe!FEngineLoop::PreInit() [c:\unrealengine\engine\source\runtime\launch\private\launchengineloop.cpp:2359]
    LogWindows: Error: [Callstack] 0x00007ff6adb65377 UE4Editor-Cmd.exe!GuardedMain() [c:\unrealengine\engine\source\runtime\launch\private\launch.cpp:129]
    LogWindows: Error: [Callstack] 0x00007ff6adb655ca UE4Editor-Cmd.exe!GuardedMainWrapper() [c:\unrealengine\engine\source\runtime\launch\private\windows\launchwindows.cpp:145]
    LogWindows: Error: [Callstack] 0x00007ff6adb7316c UE4Editor-Cmd.exe!WinMain() [c:\unrealengine\engine\source\runtime\launch\private\windows\launchwindows.cpp:275]
    LogWindows: Error: [Callstack] 0x00007ff6adb74cb6 UE4Editor-Cmd.exe!__scrt_common_main_seh() [d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
    LogWindows: Error: [Callstack] 0x00007ff9d8ca81f4 KERNEL32.DLL!UnknownFunction []
    LogWindows: Error: [Callstack] 0x00007ff9eba1a271 ntdll.dll!UnknownFunction []
    LogWindows: Error:
    LogWindows: Error: end: stack for UAT
  Took 78.3653556s to run UE4Editor-Cmd.exe, ExitCode=3
  ERROR: Editor terminated with exit code 3 while running DerivedDataCache for C:\UnrealEngine\Templates\FP_FirstPersonBP\FP_FirstPersonBP.uproject; see log C:\UnrealEngine\Engine\Programs\AutomationTool\Saved\Logs\BuildDerivedDataCache\DerivedDataCache-2019.06.18-16.56.49.txt
         (see C:\UnrealEngine\Engine\Programs\AutomationTool\Saved\Logs\BuildDerivedDataCache\Log.txt for full exception trace)
  AutomationTool exiting with ExitCode=1 (Error_Unknown)
Took 78.9746216s to run AutomationTool.EXE, ExitCode=1
ERROR: Recursive UAT command failed (exit code 1)
       while executing task <Command Name="BuildDerivedDataCache" Arguments="-TempDir="C:\UnrealEngine\LocalBuilds\InstalledDDC" -FeaturePacks=Templates/FP_FirstPersonBP/FP_FirstPersonBP.uproject;Templates/TP_FlyingBP/TP_FlyingBP.uproject;Templates/TP_HandheldARBP/TP_HandheldARBP.uproject;Templates/TP_RollingBP/TP_RollingBP.uproject;Templates/TP_SideScrollerBP/TP_SideScrollerBP.uproject;Templates/TP_ThirdPersonBP/TP_ThirdPersonBP.uproject;Templates/TP_TopDownBP/TP_TopDownBP.uproject;Templates/TP_TwinStickBP/TP_TwinStickBP.uproject;Templates/TP_VehicleBP/TP_VehicleBP.uproject;Templates/TP_PuzzleBP/TP_PuzzleBP.uproject;Templates/TP_2DSideScrollerBP/TP_2DSideScrollerBP.uproject;Templates/TP_VehicleAdvBP/TP_VehicleAdvBP.uproject;Samples/StarterContent/StarterContent.uproject;Samples/MobileStarterContent/MobileStarterContent.uproject;Templates/TP_VirtualRealityBP/TP_VirtualRealityBP.uproject -TargetPlatforms=Windows+WindowsNoEditor -HostPlatform=Win64 -SavedDir="C:\UnrealEngine/Engine/Saved\Installed\Win64"" />
       at Engine\Build\InstalledEngineBuild.xml(574)
       (see C:\UnrealEngine\Engine\Programs\AutomationTool\Saved\Logs\Log.txt for full exception trace)
AutomationTool exiting with ExitCode=1 (Error_Unknown)
BUILD FAILED
The command 'cmd /S /C .\Engine\Build\BatchFiles\RunUAT.bat BuildGraph -target="Make Installed Build Win64" -script=Engine/Build/InstalledEngineBuild.xml -set:HostPlatformOnly=true &&        python C:\exclude-components.py C:\UnrealEngine\LocalBuilds\Engine\Windows %EXCLUDE_DEBUG% %EXCLUDE_TEMPLATES% && echo. && echo.RUN directive complete. Docker will now commit the filesystem layer to disk. && echo.Note that for large filesystem layers this can take quite some time. && echo.Performing filesystem layer commit... && echo.' returned a non-zero code: 1
[python.exe -m ue4docker build] Error: failed to build image "ue4-docker.artifactory.bigworldtech.com/ue4-minimal:4.22.2-ltsc2019".
(venv) PS C:\Users\localadmin>

I believe this is the same problem from the UE4 Installed Build: https://forums.unrealengine.com/community/general-discussion/1591379-my-unreal-keeps-crashing-at-startup-does-anybody-have-any-ideas

That's a new one. Do you still have the intermediate container leftover from the previous build by any chance? The Unreal Engine actually proactively preloads dependencies for DLL files under Windows, and will report the name of a missing dependency if it encounters one. However, this detailed error output only ever seems to appear in the log files generated by UAT, rather than actually getting printed to the screen, so it's necessary to run the BuildGraph command interactively in the container produced by the previous RUN directive and retrieve the logs from the filesystem of the interactive container. If you can find the relevant line in the log file, it'll lead you straight to the missing dependency, without the need to search for it using Dependency Walker or its more modern alternatives.
Now that I think about it, adding some sort of wrapper script to surface this information in the event of a failure might be a helpful feature. It was something I considered way back in the early days of creating the Dockerfiles for the Windows container images, but once I got the key set of DLLs sorted it became a non-issue for me and I largely forgot about it.

Incidentally, the Visual C++ 2013 runtime files should already be present in the image, since all versions of the Visual C++ redistributable package are installed prior to installing the Visual Studio build tools in the ue4-build-prerequisites image: https://github.com/adamrehn/ue4-docker/blob/v0.0.35/ue4docker/dockerfiles/ue4-build-prerequisites/windows/install-prerequisites.bat#L3

Sadly, I discarded the failed build once I had diagnosed and attempted a fix.
For reference the new build got further (running out of space in the container when copying from 'builder' to the final image, ala #37. So I need to check the rest of the setup), so adding the missing redists appear to have fixed that issue.
Given that the failure was with the --pull-prerequisites flag passed, I suspect the redists are missing from the version pushed to DockerHub for ltsc2019. I didn't try a local build of the ue4-prerequisites package before patching the list of DLLs to copy.

Did you rebuild the ue4-build-prerequisites image after you modified the list of host DLLs? The DLLs are copied into the container within the ue4-build-prerequisites Dockerfile, so modifying the list should have no effect whatsoever when not building that image from source.

Yes, I modified the dll list and removed the --pull-prequisites flag from my command-line, and that fixed this issue.
I didn't notice that vcredist installer call in the script (I looked, but not closely enough -_-), so I didn't test with just removing the --pull-prerequisites flag, which would have bisected the issue to either a problem with the vcredist installer, or a problem with the currently-pushed prerequisites image.

I'm going to close this issue, it's probably aged-out. I suspect it was an issue with the ue4-build-prerequsites:ltsc2019 image on Dockerhub, which has since been refreshed. And hence #69 is more relevant now.


Add the ability to manage a clients push notification subscriptions.

Allow for the server to handle the following actions on behalf of a
client:
register
update_token
subscribe
unsubscribe

@subsetpark , @clyver: can you guys take a look at my modifications to the pusher library?


FIX Allow HTML 5 input tags in FunctionalTest form submissions

At the moment if you write a FunctionalTest to submit a Form which has HTML5 <input> tags the form will fail to submit because simpletest/form doesn't recognise the newer HTML5 input types.
This PR allows any non-recognised inputs to fallback to text type (as the HTML spec does).

@tractorcow ok, changed


Support for Hapi - 10.3

Hi ,
i am getting below error, while using hapi-swagger with hapi version 10.3.0.
$ node server.js
e:\Workspace\Sathish\hapi-killer\node_modules\hoek\lib\index.js:731
    throw new Error(msgs.join(' ') || 'Unknown error');
    ^

Error: Invalid plugin options {
  "_internals": {
    "defaults": {
      "protocol": null,
      "endpoint": "/docs",
      "documentationPath": "/documentation",
      "prefix": "",
      "appendedPrefix": false,
      "enableDocumentationPage": true,
      "auth": false,
      "basePath": "",
      "pathPrefixSize": 1,
      "payloadType": "json",
      "produces": [
        "application/json"
      ],
      "consumes": [
        "application/json"
      ],
      "ui": true,
      "listing": true,
      "index": false
    }
  }
}
←[31m
[1] "_internals" is not allowed←[0m
    at Object.exports.assert (e:\Workspace\Sathish\hapi-killer\node_modules\hoek
\lib\index.js:731:11)
    at Object.exports.assert (e:\Workspace\Sathish\hapi-killer\node_modules\hapi
\lib\schema.js:15:10)
    at internals.Plugin.register (e:\Workspace\Sathish\hapi-killer\node_modules\
hapi\lib\plugin.js:221:25)
    at Object.<anonymous> (e:\Workspace\Sathish\hapi-killer\server.js:18:8)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:475:10)
    at startup (node.js:117:18)

+1 please fix this.

Looking into it, looks like changes to the validation of plugins has started throwing issue with hapi-swagger. At first glance I may have to make some reasonable size changes to get it working again.

@glennjones Does this fixes the issue, https://github.com/hapijs/hapi/commit/7ee7cc1ba1abcae95bffc198323c1e140e0e617f

@bboysathish and @kelkes - hopefully the issue is now fixed with v2.1.0
@kelkes, yes it was the hapijs/hapi@7ee7cc1 problem, but I also has to removed some exposure of internal functions used for testing, so that plugin structure could be validated against HAPI v10.3.0 new plugin schema. I have updated tests effected to keep same level coverage. This change should not impact the public API.
If you have any more problem please feel free to reopen the issue and comment -
Thanks for pointing out the problem.

wow. thanks for the fix. impressive reaction time! :)

Thanks for the Fix :)


Provide a Key-Manager-Viewer by default.

var keyman = new KeyMan();
var keymanView = new KeyMan.View(keyman);

d7cda8bcf8373d51c5154b183d138b9a2688cb88
db86a3f4b0b4e1e9a18531e3af8b486e81fa73bb
i'm working..


v3: preserve trailing comments

@enisoc
Trailing comments are often used as additional annotation
for queries, especially DML. To support this, Vitess preserves
trailing comments. V3 was not doing this. This change fixes
the behavior.
Implementation: The trailing comments have to be first removed
to allow for the query to match the plan cache. The comments
are then re-added just before routing. This is done for every
query.
Vindex operations are considered to be internal. So, the comments
are not propagated into those.

This change is

Previously, sougou wrote…
> #### v3: preserve trailing comments
>
> @enisoc
>
> Trailing comments are often used as additional annotation
>
> for queries, especially DML. To support this, Vitess preserves
>
> trailing comments. V3 was not doing this. This change fixes
>
> the behavior.
>
>
>
> Implementation: The trailing comments have to be first removed
>
> to allow for the query to match the plan cache. The comments
>
> are then re-added just before routing. This is done for every
>
> query.
>
>
>
> Vindex operations are considered to be internal. So, the comments
>
> are not propagated into those.
>
>
>

Reviewed 10 of 10 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


Test demo not connecting to the api

Test demo not connecting to the api. Looks like a minor configuration issue.

duplicate

duplicate


Codable protocol Swift 4

Thanks a lot for the great tool. It has saved many hours for me.
Just a feature request do you have any plans to use Codable protocol in next version of the library.

Thanks. I have been thinking about how this tool will need to change once Codable is part of the standard library. It's definitely on my mind.

Thanks you are awesome (y)

Hey,
Any Plans to support Codable?

Hey,
Any plans to support Codable now?


Immutability and loss of information

Hi @jkoudys ,
Thanks a lot for sharing your super-accurate work.
I have a question concerning Immutability. Presently, you make your collections immutable by calling return new static(SplFixedArray $fixedArray); at each end of mutator methods.
This works perfectly as long as the collection itself as no more property than the content of the $fixedArray parameter.
For example if I extend ImmArray this way :
class MyLovelyCollection extends ImmArray
{
    protected $feeling = 'loneliness';

    public function __construct($fixedArray, $feeling)
    {
        $this->feeling = $feeling;
        parent::__construct($fixedArray);
    }

    public function getFeeling()
    {
        return $this->feeling;
    }
}

And then call something like
$faces = new MyLovelyCollection([':)', ':/', ':D', 'XD'], 'happiness');

echo $faces->getFeeling() // => 'happiness'

$faces->filter(function($face) {
    return ! preg_match("#[^/]$#", $face);
});

echo $faces->getFeeling() // => 'loneliness'

Because of this, I cannot use together the quality of your iterable ImmArray (it has no point inside a composition) and some properties (mutable or not) that I would attach to. Simple things like composition becomes super hard due to it.
So, more pragmatically, my question is "Why don't do clone $collection; return $collection->doSomething(); instead of return new static(...);?".
Thanks in advance for your time,
Jean

Thanks Jean! This library has definitely always targeted the composition-based approach; while we do support extension (hence the heavy return static approach you've noted), I did consider declaring the ImmArray as final and then providing some interfaces. I think at the time I'd hoped the php-fig would have some kind of focus on collections (e.g. class Foo implements Immutable instead of class Foo extends ImmArray). I should probably revisit this for a PHP7.2+ version that defines an interface where you'd expect mutating methods to fail.
Not all constructor calls create a new SplFixedArray. We DI this and only require it be a Traversable.  If you know the underlying SplFixedArray can't be changed, then you can chain $myStuff->slice(0, 5)->concat($otherStuff)->map(function ($v) { return $v * 2; }), and each step is doing almost nothing (only defining an iterator), which finally builds a new SplFixedArray at the end when you map.
I am thinking now if it's worth implementing the __clone magic method. I wrote __construct as private by design, because we only want to use the factory methods to create new instances. To me, I think __clone would make the most sense if it built a new instance with an SplFixedArray. e.g. right now $foo = $bar->slice(0, 5); keeps the SplFixedArray inside $bar in-scope, and that could be a very large collection. $foo = clone $bar->slice(0, 5); could make $foo have an sfa of count 5, and then $bar can fall out of scope and get GC'd.
So getting back to your example, what you've provided actually fails a bit earlier on the __construct, because parent::__construct is private. You're also missing an assignment, since $faces->filter will do nothing and needs to be $faces = $faces->filter. All that said, I think you're right that if we supported this via its __clone method instead, you could extend your own methods. I'm not too comfortable with relying on the clone if we can avoid it, and ImmArrays that have mutable properties don't make sense (since they're not immutable), and set-once properties at construction don't make sense either (since then it's not an array). Another project had an interesting discussion on the topic.
The ability to extend was really meant more for adding accessor methods, e.g. if I had Csvable that's meant to allow an ImmArray to export as CSV, I could say:
public function csvExport(): string {
  return $this
    ->map('someEscapingFunction')
    ->join(',');
}

Thanks a lot for your detailed answer.
My little example
I would first notice than my example wasn't meant to work perfectly but just to illustrate my purpose. Thus said I didn't realize your __construct() was private, which highlights your integration by composition.
Workflow issue
I understand your point even if extending seems to be a really natural way of integrating an external lib, add it some features temporary and, why not, finally merge it through a Pull Request. This is a super obvious workflow that I try to generalize in my work, especially to use the extended class as sandbox for my coworkers before I have the time to challenge deeply their modifications and take the time to explain why (or not) their work is satisfying our expectations.
Maybe I should search for simple compositions enabling to achieve the same goal but I'm pretty sure the workflow would be much less intuitive.
Built-in immutability
I totally agree that a builtin immutability would be appreciable. Thus said, I'm not really sure an interface would be the best representation of it. I would probably more vote for a dedicated keyword like "static" or "final", by class, property or method.
immutable class String
{
    protected $value;

    public function __construct($string)
    {
        $this->value = $string;
    }

    public function strToLower()
    {
        // here PHP would handle the clone by itself as there is a mutation
        $this->value = strtolower( $string );
        return $this;
    }

    // alternative for a partial Immutability
    public immutable function strToLower()
    {
        // here PHP would handle the clone by itself as there is a mutation
        $this->value = strtolower( $string );
        return $this;
    }
}

Workaround waiting for it
Meanwhile, instead of an interface, I experimented a way to ease the implementation of immutability by providing helpers gathered in a trait and the only way I found to don't break dependency (without Reflection) was by cloning: https://github.com/jclaveau/php-immutable-trait
As you can see it's a little more tricky but I kind of like the hack with the bt :) .
So much questions
All this led me to a lot of questions about immutability the way I find it around:

It induces a lot of integration difficulties (you require composition, some properties are lost with implementations like new static(), the class is totally blocked in implementations like https://github.com/DusanKasan/Knapsack)
As immutability is not a builtin PHP feature, there is no way for PHP to make the possible optimizations of comparisons / copies.
On some very big collections (MB of data), would the GC of PHP be enough responsive to handle all the duplicates rapidly? I guess that, if you recommend your solution for "memory intensive applications", the response is "yes".
As PHP is definitely not the more multi-threaded language ever, is this really required in our case?
Finally, is this pattern followed because it gives you (the maintainer of the lib) some comfort as you can recreate from scratch your output when needed? Because it forces the users to compose with your lib and protects your "safe garden" for patches (e.g. no method name conflicts for end users)?
Maybe, but I wouldn't bet on it as inspiring developers love to question what they do, it is by mimicking habit of the pure functional paradigm?
Or maybe it is to make libraries that can be integrated in applications considered as purely functional? In this case, shouldn't the immutability being optional?

Concerning your implementation

Not all constructor calls create a new SplFixedArray. We DI this and only require it be a Traversable.  If you know the underlying SplFixedArray can't be changed, then you can chain $myStuff->slice(0, 5)->concat($otherStuff)->map(function ($v) { return $v * 2; }), and each step is doing almost nothing (only defining an iterator), which finally builds a new SplFixedArray at the end when you map.

This is the key sentence for me :

If you know the underlying SplFixedArray can't be changed, then you can chain $myStuff->slice(0, 5)->concat($otherStuff)->map(function ($v) { return $v * 2; })

This answers my xmas list of questions above (but i'd love to have your opinion on some so I let them :) ). Here you require the immutability of SplFixedArray to iterate after the chain of actions is defined, step by step.
But does this point requires the ImmArray itself to be immutable or only to copy the last SplFixedArray everytime we use it?
Concerning your implementation 2

I am thinking now if it's worth implementing the __clone magic method. I wrote __construct as private by design, because we only want to use the factory methods to create new instances. To me, I think __clone would make the most sense if it built a new instance with an SplFixedArray. e.g. right now $foo = $bar->slice(0, 5); keeps the SplFixedArray inside $bar in-scope, and that could be a very large collection. $foo = clone $bar->slice(0, 5); could make $foo have an sfa of count 5, and then $bar can fall out of scope and get GC'd.

Here, I'm not sure I understood well what bothers you : do you wan't to avoid this copy of the SplFixedArray to save space or force this copy to let the previous SplFixedArray to the GC?
Something interesting waiting for your clarification
In your example you apply the clone after the slice $foo = clone $bar->slice(0, 5);. In my opinion, for true immutability, the clone must be done first (so the given instance wouldn't be changed by later calls).
If I start from the use of my trait to have the clone before the "mutator" call, I get something like:
    public function slice($begin = 0, $end = null)
    {
        if ($this->callOnCloneIfImmutable($result))
            return $result;

        // $this is now the cloned instance
        $this->sfa = new SliceIterator($this->sfa, $begin, $end);
        return $this;
    }

    public function __clone()
    {
        // I wonder if copying the sfa here is what you need or what you wouldn't.
        $this->sfa = clone $this->sfa;
    }

And the reflection would continue later if I don't take to much of your time :)
Thank you very much again for it!
Jean


send_lines(), command splitting support

Couple small changes from last weekend I want to clear from my WIP branch:
python: add mudpuppy_core.send_lines()
A plural version of MudPuppyCore.send_line() for convenience. Should have had this from the start :-P
support multiple input splitting
The command splitter is specified in the MUD config and defaults to ';;'. Splitting is performed in two places:

When processing human input from an enter keypress (notably, before aliases are evaluated). This allows input like 'say hi;;/py True;;say whatever" where slash commands from aliases can be used.
When processing scripted input from send_line() or send_lines() - in this case alias expansion isn't performed (and getting that to happen is architecturally tricky...) but this is an existing limitation of those APIs.

I'm a little unhappy with the duplication & limitations uncovered by playing with this idea but it's better to make a little progress than block on perfection.

check links / Run Lychee Linkchecker (push) Failing after 1m

Expected: i added an API doc link that points at the yet-to-exist manual section for command splitting.


SQLite fails to load due to "java.lang.NoSuchMethodError: Lorg/sqlite/Collation;.xCompare(Ljava/lang/String;Ljava/lang/String;)I]"

SQLite expects org/sqlite/Collation to have a xCompare(String, String) method. This allows to use Java methods to define collations, like this:
Class. forName("org. sqlite. JDBC");
Connection conn = DriverManager. getConnection("jdbc:sqlite:");

Collation. create(conn, "REVERSE", new Collation() {
  protected int xCompare(String str1, String str2) {
    return str1.compareTo(str2) * -1;
  }
});

conn. createStatement().execute("select c1 from t order by c1 collate REVERSE;");

The existence of this method is checked during loading the sqlite native library. Fontus rewrites this method to be taint-aware, causing the error above.
Slightly curious how we did not hit that before..

As we don't have any possibility to detect this at instrumentation time, we have to implement a workaround. Solution would be to special case sqlite in the Instrumenter to add proxies that call the implemented xCompare methods.

Fixed in a61a712


[Community Tutorials] Set up automated tests and linting

Testing:

[x] Fork Google Cloud Community Tutorials tests (link)
[x] Adapt tests to EE Community Tutorials (e.g. allow "+", updated paths, etc.)
[x] Migrate tests to Jasmine test runner

Linting:

[x] Migrate tests to ES5 (no =>, const, let)
[x] "Relaxed" eslint config for ES5+Google JS style
[x] Other config in .eslint
[x] Fix lint errors in existing tutorials and tests
[x] Run lint tests when running tests

Once merged we can set these up to run on PRs via Travis CI or Github Actions.

Can linting be applied to the JS code blocks in the MD file? These edits to the .js tutorial files create differences between the JS and MD files. An observation: it produces a result different than clang-format - should I continue to clang-format my .js files?

Good catch. The strict formatting may make it hard for tutorial authors to format the code in a way that makes the most sense for the tutorial format, and we really should be using unopinionated lint checking anyway. I'll relax the formatting rules and revert the indentation on the .js.
Created https://github.com/google/earthengine-community/issues/27 to track lint checking of code in Markdown.

Ok, I've disabled indentation checking for now so we can be more flexible wrt formatting/layout. I also added linting and auto fix to code fences in Markdown. Could you PTAL?
Regarding clang-format, did you have it configured to Google style, or another style? If indenting was the only diff w/eslint then with the new config you should be able to continue using that.

Regarding clang-format, did you have it configured to Google style, or another style? If indenting was the only diff w/eslint then with the new config you should be able to continue using that.

I did not specify Google as the style, but I just tried now as a test and it produces the same result.

Regarding clang-format, did you have it configured to Google style, or another style? If indenting was the only diff w/eslint then with the new config you should be able to continue using that.

I did not specify Google as the style, but I just tried it now as a test, and it produces the same result.

Thanks for checking.


Steps not working for Teams Mobile

[Enter feedback here]
I followed the steps mentioned in the page, but i am not able to see the webview opened inside Teams mobile on the inspect-devices browser page. Although the other pages opened in my mobile browser are visible here for debugging.

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

ID: 3df1efbb-c6b2-a495-303d-7abf19c57f72
Version Independent ID: a5b5782f-7031-a989-5e42-dd3010e18893
Content: DevTools for Microsoft Teams tabs - Teams
Content Source: msteams-platform/tabs/how-to/developer-tools.md
Service: msteams
GitHub Login: @surbhigupta
Microsoft Alias: lajanuar

Yes it's the same.
Regards,
Surya Gupta
From: sayali-MSFT @.>
Sent: Friday, July 15, 2022 6:37 PM
To: MicrosoftDocs/msteams-docs @.>
Cc: Surya Gupta @.>; Mention @.>
Subject: Re: [MicrosoftDocs/msteams-docs] Steps not working for Teams Mobile (Issue #6467)
@sugupta427https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsugupta427&data=05|01|Surya.Gupta%40microsoft.com|eb4008591702434bc3ec08da6662f249|72f988bf86f141af91ab2d7cd011db47|0|0|637934872412953964|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=Cycn5PWq7AUKmOb6Yi5B%2FN%2FXy2%2FKqZuzbVk7FCKKS6I%3D&reserved=0 - Are you facing same issue - #6386https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fmsteams-docs%2Fissues%2F6386&data=05|01|Surya.Gupta%40microsoft.com|eb4008591702434bc3ec08da6662f249|72f988bf86f141af91ab2d7cd011db47|0|0|637934872412953964|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=mNFS2eVjXeAOh7cXoMOL%2FjuqWL%2F6SMEawkMuAmk00%2B4%3D&reserved=0

Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fmsteams-docs%2Fissues%2F6467%23issuecomment-1185527675&data=05|01|Surya.Gupta%40microsoft.com|eb4008591702434bc3ec08da6662f249|72f988bf86f141af91ab2d7cd011db47|0|0|637934872412953964|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=VOsYEi%2BF%2Bj1LPa2bXLOCcZJ3UcnhJHGmj%2BGC3kliP%2BA%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAPJLTT2M5IUJACVG5TSZ7FDVUFPALANCNFSM53VFOABA&data=05|01|Surya.Gupta%40microsoft.com|eb4008591702434bc3ec08da6662f249|72f988bf86f141af91ab2d7cd011db47|0|0|637934872412953964|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=R0ugF%2BGptFdOT3C0ZmATZiSrpEf2WyYGpXaG5YnusZk%3D&reserved=0.
You are receiving this because you were mentioned.Message ID: @.***>

@sugupta427 -We are checking it internally and let you know if we get any updates.

I have the same problem on both an Android SDK Emulator and a physical device connected to my development workstation.

@devszr -We are able to repro that issue , We have raised bug for the same and concerned team is looking into it. We will inform you once we get any update. thanks!

@sugupta427,@devszr -Issue is Resolved with Latest Canary 2nd September Build (Version 1416/<IP_ADDRESS>2381101<PHONE_NUMBER>)
Could you please check it once and confirm?


tl_common.h: No such file or directory

I'm following the guide: https://github.com/doctor64/tuyaZigbee/blob/master/docs/sdk_installation.md
When building the following error appears:
fatal error: tl_common.h: No such file or directory
Resource: zb_common.h
Path: /tl_zigbee_sdk/zigbee/common/includes

tl_common.h is a part of Telink zigbee sdk, located in tl_zigbee_sdk/proj/
So looks like some misconfiguration in Eclipse configuration.
To be honest, Eclipse is a total mess, i currently working on switch from Eclipse to cmake build.
Please wait few days for update

I'm sorry, it takes more time what I expected, but finally all projects converted to cmake build.
See docs/linux_build.md for details


Get all passing Metal tests in CI

Get all passing Metal tests in CI
I found the bounty here so want to fix it.

I enabled the metal tests in the new commit.

Can you try test/models/test_train.py::TestTrain::test_vit also?

Metal tests failing


Fix typo

build.sht --> build.sbt

Coverage remained the same at 89.811% when pulling 2ab4bc2630a5390de86561b09e1d30afad3a3c31 on MrCitron:master into 8a236987fbe8fc8c5d65286f9415e5a17721f0a2 on iheartradio:master.

Thanks!


Add @context, alsoKnownAs, controller to DIDDoc

https://www.w3.org/TR/did-core/#also-known-as
https://www.w3.org/TR/did-core/#did-controller
https://www.w3.org/TR/did-core/#json-ld

@dkulic  @yvgny Can we check if Thomas recommendations are included in other didcomm libraries, specially didcomm python? Let's duplicate the issue in the other libraries if needed

@context is critical because its a required attribute and WaltId (correctly) rejects docs that don't have a @context

The JSON-LD Context is either a string or a list containing any combination of strings and/or ordered maps.

PR: https://github.com/sicpa-dlab/didcomm-jvm/pull/77


Prompt for template on reflex init

Ask the user to specify a template interactively on the first reflex init.

One thing I haven't included yet - if the user specifies a template up front we should skip this check. Currently if they do reflex init --template blank it still goes through the prompt. Maybe we can remove the default argument in the init command to catch this.


Issue-v0 final

Automated Review Comments
Issues in README.md:

(1, 'Line exceeds 80 characters')
(7, 'Hardcoded string found')
(8, 'Hardcoded string found')
(9, 'Hardcoded string found')
(13, 'Hardcoded string found')
(14, 'Hardcoded string found')
(15, 'Hardcoded string found')
(19, 'Hardcoded string found')
(20, 'Hardcoded string found')
(21, 'Hardcoded string found')
Issues in main.py:
(2, 'Hardcoded string found')

I got it.


[KYUUBI apache#6476] spark historyserver Show incomplete applications…

:mag: Description
Issue References 🔗

This pull request fixes #6476 : spark historyserver -> Show incomplete applications -> kyuubi query engine ui error（java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long）.
The reason:
it's related to https://github.com/FasterXML/jackson-module-scala/issues/62
Describe Your Solution 🔧
add @JsonDeserialize(contentAs = classOf[java.lang.Long]) annotation
Types of changes :bookmark:

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Behavior Without This Pull Request :coffin:
Behavior With This Pull Request :tada:
Related Unit Tests

Checklist 📝

[x] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

"fix the pr title"  is finished.
Failed checks seems unrelated to the content I modified.  Is there a tool similar to flink project "@flinkbot run azure" available？
May be rerun check.

"fix the pr title" is finished. Failed checks seems unrelated to the content I modified. Is there a tool similar to flink project "@flinkbot run azure" available？ May be rerun check.

Never mind, that's an unrelated failure.

Thanks, merged to master/1.9.2


AVX2 intrinsics unit test fails to compile

Compiling on a Linux system with a i5-6600K CPU (avx2 enabled) with gcc 7.1.1 fails to build the intrinsics unit test with the error below.
The Travis CI build is also failing.
Everything else builds and runs successfully: it is just this unit test that seems to be the problem.
[ 40%] Building CXX object tests/unit/CMakeFiles/test.exe.dir/test_intrin.cpp.o
In file included from /home/bcumming/software/github/nestmc-proto/tests/unit/test_intrin.cpp:3:0:
/home/bcumming/software/github/nestmc-proto/src/backends/multicore/intrin.hpp: In function ‘__m256d nest::mc::multicore::nmc_mm256_exp_pd(__m256d)’:
/home/bcumming/software/github/nestmc-proto/src/backends/multicore/intrin.hpp:152:35: warning: AVX vector return without AVX enabled changes the ABI [-Wpsabi]
 __m256d nmc_mm256_exp_pd(__m256d x) {
                                   ^
/home/bcumming/software/github/nestmc-proto/src/backends/multicore/intrin.hpp: In function ‘void nest::mc::multicore::nmc_mm256_print_pd(__m256d, const char*)’:
/home/bcumming/software/github/nestmc-proto/src/backends/multicore/intrin.hpp:76:6: note: The ABI for passing parameters with 32-byte alignment has changed in GCC 4.6
 void nmc_mm256_print_pd(__m256d x, const char *name) {
      ^~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include/immintrin.h:41:0,
                 from /home/bcumming/software/github/nestmc-proto/src/backends/multicore/intrin.hpp:10,
                 from /home/bcumming/software/github/nestmc-proto/tests/unit/test_intrin.cpp:3:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include/avxintrin.h: In function ‘__m256d nest::mc::multicore::nmc_mm256_exp_pd(__m256d)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include/avxintrin.h:218:1: error: inlining failed in call to always_inline ‘__m256d _mm256_blendv_pd(__m256d, __m256d, __m256d)’: target specific option mismatch
 _mm256_blendv_pd (__m256d __X, __m256d __Y, __m256d __M)
 ^~~~~~~~~~~~~~~~
In file included from /home/bcumming/software/github/nestmc-proto/tests/unit/test_intrin.cpp:3:0:
/home/bcumming/software/github/nestmc-proto/src/backends/multicore/intrin.hpp:217:7: note: called from here
     x = _mm256_blendv_pd(x, detail::nmc_m256d_nan, is_nan);
     ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include/immintrin.h:41:0,
                 from /home/bcumming/software/github/nestmc-proto/src/backends/multicore/intrin.hpp:10,
                 from /home/bcumming/software/github/nestmc-proto/tests/unit/test_intrin.cpp:3:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include/avxintrin.h:218:1: error: inlining failed in call to always_inline ‘__m256d _mm256_blendv_pd(__m256d, __m256d, __m256d)’: target specific option mismatch
 _mm256_blendv_pd (__m256d __X, __m256d __Y, __m256d __M)

I found the problem. If you need to use intrinsics with GCC, you have to pass the corresponding -m. To get this option you have to pass -DNMC_VECTORIZE_TARGET=AVX2 to CMake. However, my AVX2 unit tests ignore that flag and compile always, thus leading to such errors.


Android - NullPointerException within PluginMap.onStart()

I'm submitting a ...  (check one with "x")

[ ] question
[x] any problem or bug report

OS:  (check one with "x")

[x] Android
[ ] iOS
[ ] Browser

cordova information:  (run $> cordova plugin list)
cordova-plugin-actionsheet 2.3.3 "ActionSheet"
cordova-plugin-app-version 0.1.9 "AppVersion"
cordova-plugin-camera 4.1.0 "Camera"
cordova-plugin-cookie-manager 1.0.0 "CookieManagementPlugin"
cordova-plugin-device 2.0.2 "Device"
cordova-plugin-dialogs 2.0.2 "Notification"
cordova-plugin-googlemaps 2.6.3-20190930-1257 "cordova-plugin-googlemaps"
cordova-plugin-inappbrowser 3.1.0-dev "InAppBrowser"
cordova-plugin-ionic-keyboard 2.1.3 "cordova-plugin-ionic-keyboard"
cordova-plugin-ionic-webview 4.1.2 "cordova-plugin-ionic-webview"
cordova-plugin-is-debug 1.0.0 "IsDebug"
cordova-plugin-localization-strings 3.1.0 "Localization"
cordova-plugin-network-information 2.0.2-dev "Network Information"
cordova-plugin-splashscreen 5.0.3 "Splashscreen"
cordova-plugin-whitelist 1.3.3 "Whitelist"
cordova-plugin-wkwebview-inject-cookie 1.0.2 "WKWebViewInjectCookie"
cordova-sqlite-storage 3.2.0 "Cordova sqlite storage plugin - cordova-sqlite-storage plugin version"
ionic-plugin-deeplinks 1.0.20 "Ionic Deeplink Plugin"
uk.co.workingedge.phonegap.plugin.launchnavigator 5.0.4 "Launch Navigator"

Current behavior:
We're having some crash reports from Google Play Store. See error log below. Error happens when onStart() is called.
Expected behavior:
Related code, data or error log (please format your code or data):
Caused by: java.lang.NullPointerException:

  at com.google.maps.api.android.lib6.impl.dc.h (com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(040306-271418971):13)

  at com.google.android.gms.maps.internal.v.a (com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(040306-271418971):8)

  at cv.onTransact (com.google.android.gms.dynamite_mapsdynamite<EMAIL_ADDRESS>(040306-271418971):4)

  at android.os.Binder.transact (Binder.java:612)

  at com.google.android.gms.internal.maps.zza.transactAndReadExceptionReturnVoid (Unknown Source:7)

  at com.google.android.gms.maps.internal.zzk.onStart (Unknown Source:6)

  at com.google.android.gms.maps.MapView$zza.onStart (Unknown Source:2)

  at com.google.android.gms.dynamic.zaf.zaa (Unknown Source:3)

  at com.google.android.gms.dynamic.zaa.onDelegateCreated (Unknown Source:4)

  at com.google.android.gms.maps.MapView$zzb.createDelegate (Unknown Source:47)

  at com.google.android.gms.dynamic.DeferredLifecycleHelper.zaa (Unknown Source:18)

  at com.google.android.gms.dynamic.DeferredLifecycleHelper.onStart (Unknown Source:54)

  at com.google.android.gms.maps.MapView.onStart (Unknown Source:2)

  at plugin.google.maps.PluginMap.onStart (PluginMap.java:504)

  at plugin.google.maps.CordovaGoogleMaps.onStart (CordovaGoogleMaps.java:491)

  at org.apache.cordova.PluginManager.onStart (PluginManager.java:275)

  at org.apache.cordova.CordovaWebViewImpl.handleStart (CordovaWebViewImpl.java:464)

  at org.apache.cordova.CordovaActivity.onStart (CordovaActivity.java:303)

  at android.app.Instrumentation.callActivityOnStart (Instrumentation.java:1340)

  at android.app.Activity.performStart (Activity.java:7200)

  at android.app.Activity.performRestart (Activity.java:7340)

  at android.app.Activity.performResume (Activity.java:7353)

  at android.app.ActivityThread.performResumeActivity (ActivityThread.java:3765)

It seems to be related to Google SDK but I have not found any similar report on the Internet therefore I'm wondering if this plugin is involved with the error. If this plugin is not at all involved, how can I prevent this error?

Could you tell me how many people affected with this error?

It has happened on one Galaxy A3 (2017) with Android 8.0 and on Galaxy Note 9 with Android 9.
It affects only a few people for now (2) because we have just released our app yesterday.

I see. Thanks.
As far as I see the log, I think the timing of your code try to create a map in too much faster.
Because the error occurred in mapView.onStart().
https://github.com/mapsplugin/cordova-plugin-googlemaps/blob/master/src/android/plugin/google/maps/PluginMap.java#L504
Maybe you try to create a map while splash view is displaying.

Do you try to create a map while splash view is displaying?

Yes. I'm hiding the splash screen when MAP_READY has fired.

Thanks for your input. That's an interesting fact about Galaxy devices. I'll give it a try.


[UI] Plot the data from one measurement

In practice, it would be useful to have a quick way to see the datapoints in a measurement. Especially for clean-up of automatically created measurements while setting up. A plot would quickly give that.
Another (more lightweight approach) would be to query the first and last few datapoints of a measurement without having to download the entire thing. That would do the trick just fine, actually. The main info one needs to know if a measurement must be kept are the timestamps, no need a full plot for that.

Suggestion:

Show min/max measurement timestamp on the device page. In the best case, we'd add a link to the plotter.
Most likely the timestamp should be loaded by AJAX (allowing to update it later on)


 Delete the others, including these Instructions.
{{cask_file}} represents the cask file you’re submitting/editing (if applicable).
If there’s a checkbox you can’t complete for any reason, that’s OK. Just explain in detail why you weren’t able to do so.

Changes to a cask
Editing an existing cask

[x] Commit message includes cask’s name (and new version, if applicable).
[ ] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.

Adding a new cask

[ ] Checked there aren’t open pull requests for the same cask.
[ ] Checked there aren’t closed issues where that cask was already refused.
[ ] When naming the cask, followed the token reference.
[ ] Commit message includes cask’s name.
[ ] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.
[ ] brew cask install {{cask_file}} worked successfully.
[ ] brew cask uninstall {{cask_file}} worked successfully.

Changes to the core

[ ] Followed hacking.md.

@thibmaek Delete the instructions section, editing an existing cask section, and changes to the core section. If you did the things in it check the boxes.

You’re not editing an existing cask, you’re adding a new one. I don’t see what the confusion is there, but if it is somehow unclear, please tell us why so we can fix it.
Also, you need to do the requested actions. This submission is now failing precisely because they were not run (and fixed).

There are a few errors here, like the double urls. I ask that you try again in a new PR.


[QUESTION]: Can you add karavictl asset to the releases page

How can the Team help you today?
The main authorization module is usually installed on a stand-alone VM while the karavictl inject command needs to be executed from box that has access to the main Kubernetes cluster.
Today, I have to either build or scp the karavictl command. It will be nice to have it available from the https://github.com/dell/karavi-authorization/releases page.
Thanks !

Thank you for your question @coulof.  I've created a feature assigned to our next milestone to address this: https://github.com/dell/karavi-authorization/issues/101.


DBZ-1178 Synchronize Debezium images

https://issues.jboss.org/browse/DBZ-1178

@jpechane, I'd expect this requires any doc updates, too? It should be mentioned somewhere how to reference those images, i.e. with the registry name as a prefix.

@gunnarmorling intallation link redirected to quay,io. There every image contains correct docker pull command

@gunnarmorling I'd like to take gradual approach. If possible your last PR for examples should use quay.io images.
Then when proved to be wokring we should convert the rest of examples. And the tutorial should be the last one as it is public face and we need to be absolutely sure that all works as it should.

Deal!


[Suggestion] Binnie mods support

it would be great to include "Binnie mods / Extra bees / Extra Trees and Genetic" :D
"Botany" is already available with "NEI Addons" ;)

Moved to #48. I may look into this again now Binnie has shown signs of life.


Getters/setters bark about spacing

var obj = {
  get something() {
  }
};

Gets me this cryptic error:
19:3  error  Expected indentation of 1 characters but found 0  indent

Nevermind; I'm converting an existing project over to XO and it's space-indented :) Might want a better error message for it.

Yeah, that's coming from eslint.

Figured as much. Maybe this issue will help someone else in the future :+1:

@Qix- I've been confused by that error message multiple times too. I've opened an ESLint issue about improving it: https://github.com/eslint/eslint/issues/3340

Awesome, glad to know I'm not the only one.


Update Dyson cloud setup step with warning about the Dyson link app

Very true, this helped me, would be worth merging.

For anyone curious, the issue that caused this strange behavior has been fixed in https://github.com/libdyson-wg/ha-dyson and https://github.com/libdyson-wg/libdyson-neon - forks that were created to continue development of the Dyson Home Assistant integrations.


WIP: transient progress.track #1488

Type of changes

[ ] New feature

Checklist

[ ] I've run the latest black with default args on new code.
[ ] I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
[ ] I've added tests for new code.
[ ] I accept that @willmcgugan may be pedantic in the code review.

Description
experiment with supporting transient as parameter in progress.track
addressees #1488

transient is probably the wrong term, since it is used elsewhere with a somewhat different meaning. I'd suggest 'hide_finished`

@willmcgugan and @RonnyPfannschmidt.
Is this PR still alive?

Closing, assumed stale


cli-visualizer: 1.6 -> 1.7

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/cli-visualizer/versions.
These checks were done:

built on NixOS
ran ‘/nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7/bin/vis -h’ got 0 exit code
ran ‘/nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7/bin/vis --help’ got 0 exit code
ran ‘/nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7/bin/.vis-wrapped -h’ got 0 exit code
ran ‘/nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7/bin/.vis-wrapped --help’ got 0 exit code
found 1.7 with grep in /nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7
directory tree listing: https://gist.github.com/544d33e8edd7362d66363d64c8cabf80

FWIW vis (name of binary for cli-visualizer) is currently broken AFAICT-- aborts on launch and gdb shows something about std::locale, maybe related to #38991 since it works on 18.03.
Hard to do sanity check of functionality when it fails to start! :)

Hmm, but it does it not abort for you/your tool? cc @ryantm

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: cli-visualizer
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: cli-visualizer
Partial log (click to expand)
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/g7xi95kxnfpl46xwhkmgzblhnzqb6zxl-cli-visualizer-1.7
shrinking /nix/store/g7xi95kxnfpl46xwhkmgzblhnzqb6zxl-cli-visualizer-1.7/bin/.vis-wrapped
strip is /nix/store/j7d4mr0ikv974ig7yzhknpsq288js4bs-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/g7xi95kxnfpl46xwhkmgzblhnzqb6zxl-cli-visualizer-1.7/bin
patching script interpreter paths in /nix/store/g7xi95kxnfpl46xwhkmgzblhnzqb6zxl-cli-visualizer-1.7
checking for references to /build in /nix/store/g7xi95kxnfpl46xwhkmgzblhnzqb6zxl-cli-visualizer-1.7...
/nix/store/g7xi95kxnfpl46xwhkmgzblhnzqb6zxl-cli-visualizer-1.7

Success on x86_64-linux (full log)
Attempted: cli-visualizer
Partial log (click to expand)
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7
shrinking /nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7/bin/.vis-wrapped
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7/bin
patching script interpreter paths in /nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7
checking for references to /build in /nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7...
/nix/store/mjifmz701jz9zxicim6wqgjgvjrhm47f-cli-visualizer-1.7

@dtzWill What's the exit code when it aborts for you? nixpkgs-update uses the merge base of staging and master to do it's work, so maybe that's not currently broken?

Exit code is 134, and AFAICT happens on both master and staging:
https://gist.github.com/dtzWill/2f79286ffb9ecda98b6366141ca110ec

Oh, I forgot to include/test-in-the-same-way with 18.03.  Doing similar for the release-18.03 branch, as below, works for me:
$ nix run -I np=https://github.com/NixOS/nixpkgs/archive/release-18.03.tar.gz np.cli-visualizer  -c vis
~~crazy colors~~

I don't mean to hijack your PR, so if you (with these commands) aren't seeing the same behavior I'll go investigate and file an issue or w/e as appropriate.

@dtzWill do you mix libc's somehow?


Broken link

Broken link on readme file and https://code.vmware.com/samples/2562/vsphere-automation-rest-api-postman-resources-and-samples
"vSphere-Automation-Rest-Resources.postman_collection.json provides the individual API resources. They are standalone requests that you can execute or use to build up an end to end workflow."
Points to:
https://github.com/vmware/vsphere-automation-sdk-rest/blob/master/samples/postman/vSphere-Automation-Rest-Resources.postman_collection.json
It should point to:
https://github.com/vmware/vsphere-automation-sdk-rest/blob/master/samples/postman/vSphere-Automation-REST-Resources.postman_collection.json
Rest vs REST

This has been fixed with this commit. I'm not sure how long it will take for the change to show up on VMware {code}, but it will pick up this change at some point. Thanks for the letting me know!