Why use the OnInitialized method instead of the OnInitializedAsync method in the Checkout.razor component?

This Repo is really great and has helped me solve a lot of problems,
but I also get questions like the title when I reference the code.
Why use  OnInitialized method ?
What is the purpose of this _?
protected override  void OnInitialized()
	{
		// In the background, ask if they want to be notified about order updates
		_ = RequestNotificationSubscriptionAsync();
	}

I think the usage should be to use the asynchronous method, not the synchronous
protected override async Task OnInitializedAsync()
	{
			await		RequestNotificationSubscriptionAsync();
	}

@ltm0203
By looking at the history of the code commits - this was coded by @SteveSandersonMS. I am guessing here as to what might be his intention:
If you look at the RequestNotificationSubscriptionAsync() code:
    async Task RequestNotificationSubscriptionAsync()
    {
        var subscription = await JSRuntime.InvokeAsync<NotificationSubscription>("blazorPushNotifications.requestSubscription");
        if (subscription != null)
        {
            try
            {
                await OrdersClient.SubscribeToNotifications(subscription);
            }
            catch (AccessTokenNotAvailableException ex)
            {
                ex.Redirect();
            }
        }
    }
    ```
It's just invoking the service worker's push manager and creating a new subscription. Since this is all in the background and I don't need to wait for what happens inside RequestNotificationSubscriptionAsync() - we have OnInitialized() being used. If there is a need for you to await - you should use OnInitializedAasync() method. This is my guess.

If @SteveSandersonMS  sees this - he can comment on the choice of OnInitialized() vs OnInitializedAsync()  😄


Implement qfunc for kets and make it faster for operators.

Coverage increased (+0.05%) to 95.232% when pulling 1b3576af57e903191f220302ec2ec62dcb90ec88 on qfunc-state into 1324c3fdb28b7c396210bf9eddaaad0429db2f2d on master.


Add hover and active style for scrollbar

Codecov Report

Merging #141 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #141   +/-   ##
=======================================
  Coverage   27.71%   27.71%
=======================================
  Files          13       13
  Lines         184      184
  Branches       32       32
=======================================
  Hits           51       51
  Misses        105      105
  Partials       28       28

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 1ebf1df...8058785. Read the comment docs.


start_yaw has different/ no effect depending on platform

May be just me - but when I use the start_yaw variable it has different results depending on whether I'm viewing on mobile (iPhone 6 Plus, Safari) or desktop (iMac 2015, Safari) - both latest versions as of writing.
I can also confirm this is the case with the latest version of Google Chrome on iPhone.
1) Desktop - initial view as expected when using the start_yaw variable, e.g. start_yaw=90 - does what it says on the tin.
2) Mobile - ignores start_yaw completely.
Images used taken with Ricoh Theta S camera.
Cheers.

This should be fixed, please try again.


[Intel MKL] Enable TF_NUM_INTEROP_THREADS for MKL-DNN backend.

Usually we need to modify model to support inter/intra thread setting for CPU Tensorflow.  This PR enables environment to set intra/inter instead of modifying model with session config:
TF_NUM_INTEROP_THREADS=1 TF_NUM_INTRAOP_THREADS=28 python model.py
TF r1.14 has already supported TF_NUM_INTRAOP_THREADS for MKL-DNN backend, this PR is only to enable TF_NUM_INTEROP_THREADS.
Modified:

tensorflow/core/common_runtime/process_util.cc

Signed-off-by: Lu Teng<EMAIL_ADDRESS>

What do you mean "we need to modify model to support inter/intra thread setting"?

@fisakhan Usually #inter-threads and #intra-threads are set through session options in the TF code. This PR allows the user to also set #inter-threads and #intra-threads from the environment variables.

@penpornk Thanks. How can I confine TensorFlow (C or C++ API) not to generate more than one threads? TF_NUM_INTEROP_THREADS=1 TF_NUM_INTRAOP_THREADS=1 generates 1 thread per core. I have 8 cores and thus tensorflow generates 8 threads. I want TensorFlow to generate only 1 thread in total.

@penpornk Thanks. How can I confine TensorFlow (C or C++ API) not to generate more than one threads? TF_NUM_INTEROP_THREADS=1 TF_NUM_INTRAOP_THREADS=1 generates 1 thread per core. I have 8 cores and thus tensorflow generates 8 threads. I want TensorFlow to generate only 1 thread in total.

Could you start a new issue to describe your question then pin me or @penpornk ? It's hard to answer the question due to lack of information.

Hi @fisakhan, the possible reason is that you used C/C++ API without enabling thread setting. It means that need extra configuration in code:
RunOptions run_options;
run_options.mutable_experimental()->set_use_run_handler_pool(true);
RunMetadata run_metadata;
Status status = session->Run(run_options, input, output_node_names, {}, &output, &run_metadata);

This is because TF has some steps in Python process to initialize thread pool setting, but it will be skipped when uses C/C++ API directly: https://github.com/tensorflow/tensorflow/blob/r2.3/tensorflow/core/common_runtime/direct_session.cc#L600-L601
And TF will use the core number as thread number by default.

Thanks @Zantares . You you can find more information about the issue here https://github.com/tensorflow/tensorflow/issues/42510

If there is no solution for reducing the number of threads to 1 or 2, can we reduce the number of thread by changing the source code of tensorflow (particularly C_API)? what to change in that case?

For normal python process, the work thread pool is initialized here: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/common_runtime/local_device.cc#L76
But I'm not sure if C API goes this path or not.  Can you try to integrate this RunOption(https://github.com/tensorflow/tensorflow/pull/33992#issuecomment-679928166) to your case firstly? I used to enable a C case with wrong thread number, but it become correct after I setting that flag.

TensorFlow cannot be single-threaded (https://stackoverflow.com/questions/48696900/why-tensorflow-creates-so-many-cpu-threads). Is it right?

Not exactly. I'm not familiar with GPU, but CPU can be set to single thread mode with correct configuration: set thread number of all pools(intra, inter, OMP) to be 1. The question is, C API may use another thread pool(your own pool) or set the thread number in other place which is different with python API.
This option run_options.mutable_experimental()->set_use_run_handler_pool(true); forces C API to use the standard thread pool(inter & intra) in TF, so it can be controlled again.
BTW, the issue you posted on stackoverflow may be caused by below reason:

wrong OMP setting
used LocalDevice API before session run, which is a known issue in TF: https://github.com/tensorflow/tensorflow/issues/22229

run_options.mutable_experimental()->set_use_run_handler_pool(true); is not available in C API. It is available in C++ API. As soon as I create a graph or load a .pb model, thread count reaches the number of cores.
The following is my code to load a savedmodel (.pb) and it increases the number of threads from 1 to 8 (using "top -H -b -n1 | grep example | wc -l" command on linux).
tensorflow::GraphDef graph_def;
Status load_graph_status =
ReadBinaryProto(tensorflow::Env::Default(), graph_file_name, &graph_def);
if (!load_graph_status.ok()) {
return tensorflow::errors::NotFound("Failed to load compute graph at '",
graph_file_name, "'");
}


Tracking Discussion: Required steps for GitLab to LocalVC migration

Is your feature request related to a problem?
Like the migration from BitBucket to LocalVC, a similar automatic migration should be possible for the migration from GitLab to LocalVC.
This issue serves as a collection/tracker to discuss required steps for this to be possible.
Relevant items that come to mind right now:

[x] Clone all existing GitLab repos onto the Artemis server
[x] Update all Jenkins build plans to replace the Git URLs pointing to GitLab to instead point to Artemis
[x] Update the Git base URL in the programming_exercise_details table in the Artemis database
[x] User documentation on how to perform the migration

The migration from Bitbucket to LocalVC can be found in chore/bitbucket-localvc-migration-release. It might be helpful.

Why does the BitBucket to LocalVC Migration uses two extra keys for @Value? Both does not seem to be necessary for me:

migration.local-vcs-repo-path could be replaced with artemis.version-control.local-vcs-repo-path, which already exists at the time of the BitBucket migration (e.g. used here).
migration.base-url should be always equal to ${server.url}. Or how can this be different?

@reschandreas can you maybe answer that questions, as the author of the BitBucket to LocalVC migration?

Hi! I intentionally used different values to ensure that migration requires a deliberate action, preventing it from happening accidentally during updates. This way, the Artemis admin must consciously decide and update their configuration to migrate.

@BaumiCoder I guess with our plan to trigger the migration by a class with a special profile this then serves the same purpose and the different configuration values are not required.

Thanks @reschandreas, with this background information I agree with @b-fein. I moved to the existing values for the migration here (see 55836b787974b38a1b7cc354f96cbf0963bfb91d).

The log message here claims that the URL will not be changed in the database, because the migration failed. In contrast to this the lines 344 and 345 are also executed in this case, so the URL is saved, isn't? @reschandreas Is that intended or a bug?

looks like a bug to me. We changed the behaviour of the method several times (we weren't if we should keep the url or not), so this could have slipped through. I'm not aware of any issues during the migration though.

Okay, I fixed that bug (13e0764). However, this bug would have led to an null URL in the database (if that is possible). An old URL is still possible if some error blocks the migration of a repository (e.g. the source repository is not available anymore).

Another GitLab specific thing is in the Artemis Database. If tokens are used for the authentication of the users against GitLab, Artemis stores these tokens in the column vcs_access_token of jhi_user. LocalVC also will have a token authentication (#8664). @SimonEntholzer Will your implementation be able to work with these tokens from GitLab, or should we delete the existing tokens (so that new ones are created if necessary)? I see two differences between the GitLab and the localVC tokens:

Prefix: vcpat- at localVC / glpat- at GitLab
Number of the characters after the prefix (digits and letters): actual 40 at localVC / 21 at GitLab (maybe depending on some GitLab configuration)

To make sure that the old tokens do not cause any trouble or became unnecessary data, the migration now removes the token data (da6b3b3).
FYI: @SimonEntholzer

Actual status:

There is a migration available with Pull Request #8972
The documentation now contains a Jenkins-LocalVC section and Jenkins-GitLab section contains a warning that it will get removed.
The issue #9318 is about removing the GitLab related parts of Artemis.

Do we still need this issue here or should we close it?

You are right, I think this can be closed as resolved.
Thanks for the reminder.


feat: add FoxPage OtherOpportunities component

Description

We need a component to display some links to external opportunities
I added a new component OtherOpportunities displaying an accordion, including 3 panels Liquidity Pools, Farming and Borrowing & Lending

Every panel contains a FoxOtherOpportunityPanel.tsx component containing every opportunity
While reviewing, be careful about FoxCommon.tsx and the mocked data inside Layout.stories.tsx as it define the static opportunities API

Notice

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
#1805

Risk
No risk

Testing

Go on storybook and look at the component, compare with mockups

Screenshots (if applicable)

approved before i fixed the merge conflict


Chore: rename aemeasurable -> aeMeasurable

Zulip

We generally uncapitalize names as a group. E.g. ENNReal -> Continuous.ennreal_mul


Hyper-parameter settings for mmnist

Thank you for releasing the code!
We have tried to train the SimVP model with your default setting. The results we got could be more optimal. This is the line of code that we've run
python tools/non_dist_train.py -d mmnist -m SimVP --model_type gsta --lr 1e-3 --ex_name mmnist_simvp_gsta --epoch 600
The MSE score on the testing set is 47.128. Can you check if there is anything wrong with our settings? And is there a better hyperparameter setting we should use to generate your paper's results?

I'm sorry for the misunderstanding. We need the config file to specify the hyperparameters of the model. I suggest you to

I'm sorry for the misunderstanding. If the config file is not specified, the code will use the default hyperparameters in simvp/utils/parser.py.   To reproduce the experiments in our paper, I suggest you specify the config file:
python tools/non_dist_train.py -d mmnist --lr 1e-3 -c ./configs/mmnist/simvp/SimVP_gSTA.py --ex_name mmnist_simvp_gsta

We have updated the readme and hope this will help you.

Thanks for the swift reply!


[FLINK-27529] Fix Intger Comparison For Source Index in Hybrid Source

Earlier PR for this: https://github.com/apache/flink/pull/19654
Would you mind updating the JIRA number on this PR to refer to https://issues.apache.org/jira/browse/FLINK-27529?
Do you see a reasonable way to have test coverage for this?

Earlier PR for this: #19654
Would you mind updating the JIRA number on this PR to refer to https://issues.apache.org/jira/browse/FLINK-27529?
Do you see a reasonable way to have test coverage for this?

Should be possible; I had tests internally. Update JIRA ticket. Will ping back here

@flinkbot run azure

@tweise can you help me run the CI/CD please?

@flinkbot run azure

@varun1729DD whoops, it appears the CI already run for the most recent commit.


fix(imagecard): add Carbon icon to zoom to fit

Summary

Add Carbon icon to zoom to fit button.

Acceptance Test (how to verify the PR)

Run ImageCard storybook and check if there's a Carbon icon in zoom to fit button.

:tada: This PR is included in version 1.88.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0-beta.9 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.88.0 :tada:
The release is available on npm package (@release-1.x dist-tag)
Your semantic-release bot :package::rocket:


Please update compiler feature support matrix for VS2017

https://github.com/Microsoft/cpp-docs/blob/master/docs/cpp/support-for-cpp11-14-17-features-modern-cpp.md only references up to vs2015

This material has been updated and consolidated with the Visual C++ Language Conformance topic, so that we don't have ever-expanding tables and a lengthening discussion of obsolete bugs cluttering the feature lists. The current page should automatically redirect you to the new page.


_istioctl auto-complete file not found

Bug description
I cannot find the istio autocompletion file as described in the docs
[x] Docs
Expected behavior
There is a _istioctl file that I can source in my .zshrc
Steps to reproduce the bug
❯ ls -aR istio-1.4.0/tools
.                                          convert_RbacConfig_to_ClusterRbacConfig.sh packaging
..                                         dump_kubernetes.sh

istio-1.4.0/tools/packaging:
.      ..     common

istio-1.4.0/tools/packaging/common:
.                 ..                istio-iptables.sh

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
How was Istio installed?
❯ istioctl version --remote
client version: 1.4.0
control plane version: 1.2.8
data plane version: 1.1.14 (1 proxies), 1.2.8 (25 proxies), 1.1.3 (1 proxies)
❯ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-13T11:23:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.10-gke.17", GitCommit:"27b48e2b4c9535d185ec945c6a513537e4d116cf", GitTreeState:"clean", BuildDate:"2019-10-21T20:10:26Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

Thanks for your help and work!

@bookRa thanks for the report! We noticed this recently as well and sent out a fix, so this will be included in 1.4.1. Sorry for the inconvenience. See https://github.com/istio/release-builder/pull/74


Add absolute_import feature from the future

This should prevent local files or modules from shadowing standard
library modules and will provide an all around better experience. This
does not, however, help us in the case where someone uses a library
like pies (which installs broken standard library shims for Python 2/
Python 3 compatibility).
Related to: https://github.com/kennethreitz/requests/issues/2771

\o/

:custard:

:sparkles: :custard: :sparkles:


Add IBKR converter

Added

✨ New broker: Interactive Brokers (IBKR)

Fixes

Fixes #39

One issue remaining is that the sell records don't have an ISIN, so no way to know which symbol to link it to.


RichEditBox should respect Background/Foreground color

Proposal: RichEditBox should respect background color and foreground color

Summary
When I add a RichEditBox to a page and configure it's foreground and background colors, those colors are only respected when the app is unfocused. When the control is hovered or in-focus, there are different colors; background is black for hover, and white when it's in-focus.
This is not expected, and presents an unpleasant experience. What I expect is that the control respect background and foreground color in all states. Even if I set RequestedTheme to Dark, nothing changes.

Rationale

Improved appearance and behavior.
The current behavior is not acceptable; no edit box could be shipped with the default behavior.
reduce the need for re-templating.

Notes
The Xaml Controls Gallery exhibits correct behavior for the control, but the same code in my own app behaves differently.

@Gavin-Williams

When I add a RichEditBox to a page and configure it's foreground and background colors, those colors are only respected when the app is unfocused. [...] This is not expected, and presents an unpleasant experience. What I expect is that the control respect background and foreground color in all states.

The behavior you are seeing is consistent with controls like TextBox , Button and other controls throughout WinUI/UWP.

When the control is hovered or in-focus, there are different colors; background is black for hover, and white when it's in-focus.

It appears to me as if you are using an older WinUI version here. WIth WinUI Version 2.4.2, the hover/focused background color is the same (black in dark mode):
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center" Orientation="Horizontal">
    <TextBox Foreground="Red" Background="Orange" Header="TextBox" MinWidth="150"/>
    <RichEditBox Foreground="Red" Background="Orange" Margin="15,0,0,0 " Header="RichEditBox" MinWidth="150"/>
</StackPanel>

With the current styling system in place, customizing the appearance of a Control via its Foreground/Background properties often means you will also have to use lightweight styling to also change the control's appearance in its other visual states like hover/pressed/focused to get a coherent visual experience:
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center" Orientation="Horizontal">
    <RichEditBox Margin="15,0,0,0 " Header="RichEditBox" MinWidth="150">
        <RichEditBox.Resources>
            <SolidColorBrush x:Key="TextControlBackgroundPointerOver" Color="LightSkyBlue" />
            <SolidColorBrush x:Key="TextControlBackgroundFocused" Color="DodgerBlue" />
        </RichEditBox.Resources>
    </RichEditBox>
</StackPanel>

OK. I'm looking at the RichEditBox page. And I don't see any mention of these default resources. I notice as well that these are undiscoverable in the editor - those keys are magic strings. I can see now that you've told me about them that the Xaml Controls Gallery does make use of them (I think) in C#.
So that I can read more about these resources, where should I look, are these Xaml Theme Resources?

@Gavin-Williams Typically, I just look at the control template of the control I'm interested in located here in the WinUI repo (to get the most up-to-date theme resources available.) For the RichEditBox, for example, this would be this file. If you check the control template and its visual states, you will see which theme resources thedefault control template uses and thus the theme resourcs you should override.
Even if you are not using WinUI but the OS XAML controls instead, it pays off taking a look at the WinUI repo because for many OS XAML controls, their default control templates are already available here. You see that with the RichEditBox control. It's not yet open-sourced but WinUI 2 still already ships it'a default control template lifted out of the OS.
Of course, you can also always look at the generic.xml file which comes with the Windows SDK and contains all the styles and resources shipped with a particular SDK version. This file is typically located at [your specified root path to the Windows SDKs]\WindowKits\10\DesignTime\CommonConfiguration\Neutral\UAP\[SDK version]\Generic\, where [SDK version] is 10.0.18362.0 for the 1903 SDK, for example. Pressing Fn + F12 in VS on a selected resource defined in that file will also open that file in VS. For example, the default background of a UWP Page is set to ApplicationPageBackgroundThemeBrush. Just select that resource, press Fn +  F12 and VS should open the generic.xaml file of the target OS version.
The WinUI repo has the advantage that it separates control templates by control - the generic.xaml file just lumps them all together into one huge file.


fix: Fixed regression with exit code in terraform_docs hook

Put an x into the box if that apply:

[ ] This PR introduces breaking change.
[x] This PR fixes a bug.
[ ] This PR adds new functionality.
[ ] This PR enhances existing functionality.

Description of your changes
Fixes #413
[ -e "" ] produces result code 1 if the file is not found. And that implicitly return as result, which is not expected
How can we test changes
repos:
- repo: https://github.com/antonbabenko/pre-commit-terraform
  rev: 168b3aee5c9927ab104667173eb2555d381c8402
  hooks:
    - id: terraform_docs

@MaxymVlasov

[ -e "" ] produces exit code 1 if the file is not found. And that implicitly return as result, which is not expected

I'm not able to reproduce this:
set -eo pipefail

echo $BASH_VERSION

[ -e "somefile_which_does_not_exit" ] && echo Ok

echo "End"

Execution output:
3.2.0(5)-beta
End

$ [ -e $somefile_which_does_not_exit ] && echo Ok
$ $?
1: command not found

@yermulnik

You're right, it is named not "exit code", but something like "command execution result code", but that's no matter if [ -e "" ] is the last construction in function

This PR is included in version 1.74.1 :tada:

Good fix, btw. (no need to test for existence when using rm -f)

@robinbowes Yep, I was about to suggest adding 1) explicit return or 2)  || true or 3) "proper" if/then/fi to that function to properly handle the [ -e test condition failure, though... rm -f ... can handle this on its own despite an extraneous call to rm where we could avoid doing this.
And, yep, it was me who asked to add [ -e test condition to the code previously 😺


is PM 0.5 and 0.3 integrated??

Hi @fu-hsi
is it possible to integrate a functionality for capturing sensing data on Particles of 0.5 um and 0.3 um in you're library? as the PMS7003 can capture these.
maybe you already have this functionality, I've just not been able to find it in your doc.
best regard

PMS7003 captures:

PM1.0,
PM2.5,
PM10.

For measuring air quality you only need PM10 and PM2.5 in some countries.

Per this doc: https://www.aqmd.gov/docs/default-source/aq-spec/resources-page/plantower-pms5003-manual_v2-3.pdf
The last two digits of the model number are the min distinguishable particle diameter, 03 = 0.3 micrometer, 05=0.5 micrometer, 10 = 1.0 micrometer, 25=2.5 micrometer.


Cross-compiling issue with libcrypto on Linux

I have an Ubuntu Docker image which cross-compiles my application for MacOS.
I use osxcross tools and the OpenSSL 1.1.1g build.
All the crates which depend on openssl-sys are built without errors, but I have an issue with sqlx-macros, which requires some libcrypto symbols, and for some reason rustc is unable to find the library.
   Compiling sqlx v0.4.0-beta.1
     Running `rustc --crate-name sqlx --edition=2018 /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/sqlx-0.4.0-beta.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -Cembed-bitcode=no --cfg 'feature="json"' --cfg 'feature="macros"' --cfg 'feature="postgres"' --cfg 'feature="runtime-async-std"' --cfg 'feature="sqlx-macros"' -C metadata=7c40358ea7c4ec8a -C extra-filename=-7c40358ea7c4ec8a --out-dir /zinc-dev/target/x86_64-apple-darwin/release/deps --target x86_64-apple-darwin -C linker=x86_64-apple-darwin14-clang -L dependency=/zinc-dev/target/x86_64-apple-darwin/release/deps -L dependency=/zinc-dev/target/release/deps --extern sqlx_core=/zinc-dev/target/x86_64-apple-darwin/release/deps/libsqlx_core-97f61aca60bd39af.rmeta --extern sqlx_macros=/zinc-dev/target/release/deps/libsqlx_macros-e396e661b598d675.so --cap-lints allow -L<EMAIL_ADDRESS>-C link-args=-lssl -C link-args=-lcrypto`
error: /zinc-dev/target/release/deps/libsqlx_macros-e396e661b598d675.so: undefined symbol: PKCS5_PBKDF2_HMAC
  --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/sqlx-0.4.0-beta.1/src/lib.rs:59:1
   |
59 | pub extern crate sqlx_macros;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: could not compile `sqlx`.

Could you please give a hint?

I tried to specify linker flags in different manners, but with no effect:
-L<EMAIL_ADDRESS>-C link-args=-lssl -C link-args=-lcrypto
-L<EMAIL_ADDRESS>-lssl -lcrypto

I am not associated with sqlx in any way, but I've recently managed to get this working for musl-libc targets using my Docker image https://github.com/emk/rust-musl-builder. I am happy to support this use case and help improve the documentation.

@emk , thank you very much!
It seems unrelated to my specific MacOS cross-compiling case, but I have found some other potentially viable solutions there.

@emk , thanks one more time!
Adding
[dependencies.openssl]
version = "0.10"
features = [
    "vendored"
]

to the application depending on sqlx-macros worked like a charm!


Disable warnings in console?

My bundle generates warnings that I'd like to hide / filter for the moment. I've set the webpackDevMiddleware's stats's warnings option to false, but the warnings are still shown in the browser console:
[HMR] bundle has 13 warnings
...

Do those stats settings influence what's send to the HMR client? Shouldn't they?
What's the best way to hide these warnings but still get the other information. I prefer not using the noInfo since that might hide more information than just those warnings.

Looks like as far as the client.js goes, the server side options do not get passed to the client side options.

@peteruithoven When including your client file in your bundle, make sure you have the warn=false parameter added like so:
webpack-hot-middleware/client?path=/__webpack_hmr&warn=false

@okcoker That didn't work for me, I commented out the code in the node module displaying the warnings. Would be nice if it worked though so I didn't have to do that.

@jarodccrowe if warn is false, then log won't get called as seen here
You're speaking of the client warnings right?

Actually you might want to try &quiet=true instead of &warn=false as seen here

@okcoker Thx, &quiet=true works!

edit webpack like this
...
entry: ['webpack-hot-middleware/client.js?quiet=true'],
....

HMR] bundle has 2 errors


[Request] Support for Hyper

Hyper is a Hyper amazing Hyper terminal.
Okay sorry I couldn't resist the pun. Jokes aside, I would love it if this plugin could get support for Hyper (aka Hyper Terminal but that's the name for v1.x, not v2.x)

Hi, @Favna. Sorry, but this plugin was written only for iTerm. So Hyper can't be supported as it has own architecture and ecosystem.

Technically you can use this plugin on any Terminal (Terminal.app, iTerm, Hyper, etc.), but only the custom labels will appear in iTerm.
E.g. If you set F1 to copy pwd to your clipboard with the custom label 👉 pwd, if you run zsh in any terminal and press F1 it will have the same behavior as on iTerm.  However, 👉 pwd will not be shown instead of F1.
zsh-apple-touchbar is totally portable except for the custom labels


Update pkg.cloudflare.com urls

See pkg.cloudflare.com changes · Issue #719 · cloudflare/cloudflared

Is there any way to test this out through Galaxy? A couple of my projects are on standby until this is fixed and I can't find a way to use anything other than the broken master branch

You can install @siriusnottin's version by https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#installing-a-specific-version-of-a-role
Please report back, especially whether we should use xenial or bullseye or something else.

I believe the new ppa doesn't contains the cfca package.
See: https://github.com/TypistTech/trellis-cloudflare-origin-ca/pull/60#issuecomment-1220828247

Thanks for the help @TangRufus. It did not seem to accept PRs (getting the error fatal: reference is not a tree) but works with my own forked version of the repo.
As you suggested it fails at the "Install CFCA" stage so we'll have to wait as they seem to be working on it.

Seems Cloudflare has no ETA on adding back cfca and recommands downloading the certs via dashboard.
Anyone know any CLI alternatives to cfca?
See:

https://github.com/cloudflare/cloudflared/issues/719#issuecomment-1221391797
https://github.com/cloudflare/cloudflared/issues/719#issuecomment-1258659872

I think you have to use their API if you want to bypass the Cloudflare dashboard now?
See:

Origin CA certificates · Cloudflare SSL/TLS docs
Cloudflare API v4 Documentation

No problem, thanks for your answer!
I'd like to help if I have more time I'll commit once finished if it's embeddable in this repo or a separate project as a bash script maybe depending on what's more convenient and what suits you.
Thank you for your work, I discover ansible recently and I learn little by little as I code not much these days.


Main

Issue number
Relevant issue number

Resolves #

Please check the following

[ ] Do the tests still pass? (see Run the Tests)
[ ] Is the code formatted properly? (see Linting (Formatting))
For New Features:

[ ] Have tests been added to cover any new features or fixes?
[ ] Has the documentation been updated accordingly?

Please describe additional details for testing this change

@kawaljen is this a duplicate of #456?

@kawaljen is this a duplicate of #456?
no .. just a mistake


Add ability to easily increment to next preprogrammed pattern

At the most basic, I just want to be able to turn the LED's ON/Off and to easily "swipe" through to the next pre-programmed LED pattern directly from a HomeKit accessory control screen would be awesome.

+1


Updated to .Net Core 3.1 which is now LTS

migrated to .Net Core 3.1 as thats now LTS

Thanks for this 👍


Update readme.md

Objective
Add an X next to Kyle Deshon
Changes made
Added my repl ID and an emoji.
Fixed a misspelling in my replID
Who needs to review this Pull Request?
@mention some teammates who will check your Pull Request for any mistakes.
Teammates, leave comments in a review if you approve this change

@aparnachaganty Here's a revised pull request with my correct repl ID. Sorry about that!


What is the difference between yield [takelatest] and yield takelatest; yield takelatest

By reading documentation and other question, I couldn't understand why these two way is the same.
const rootSaga = function * () {
    yield takelatest(A, Asaga);
    yield takelatest(B, Bsaga);
}

const rootSaga = function * () {
    yield [ takelatest(A, Asaga), takelatest(B, Bsaga) ]
}

I think the first way will stuck in A, but in fact, that work for receiving B without receiving A. I am confused how the first way work. Could anyone help me? Thanks

takeLatest is built on top of fork so it using it won't block your saga.
There is no real difference between those two snippets. Subtle technicality is that first one "asks" redux-saga runtime 2x times to do something (starting a watcher in this case) while the latter asks only once - holding both in a 'batch'. yielding arrays is deprecated though - I'd recommend using explicit effect for this:
const rootSaga = function * () {
    yield all([ takelatest(A, Asaga), takelatest(B, Bsaga) ])
}


Run black and pyupgrade over botocore directory

Do NOT squash merge this, it needs a standard merge to maintain the hashes in .git-blame-ignore-revs
This is 2nd of probably 4 PRs we'll be doing to finish out #2472. We'll start by running black and pyupgrade over the botocore directory. This will leaves tests untouched to ensure we're not unintentionally breaking anything. The following PRs will add this same formatting to the test directory and then a final PR will formalize it for all future changes by adding it to pre-commit.

Codecov Report

Merging #2666 (a7f1e76) into develop (f960a8d) will decrease coverage by 0.00%.
The diff coverage is 95.60%.

:exclamation: Current head a7f1e76 differs from pull request most recent head 97eec9c. Consider uploading reports for the commit 97eec9c to get more accurate results

@@             Coverage Diff             @@
##           develop    #2666      +/-   ##
===========================================
- Coverage    95.31%   95.30%   -0.01%
===========================================
  Files           60       60
  Lines        12208    12205       -3
===========================================
- Hits         11636    11632       -4
- Misses         572      573       +1

Impacted Files
Coverage Δ

botocore/crt/auth.py
0.00% <0.00%> (ø)

botocore/docs/__init__.py
100.00% <ø> (ø)

botocore/configprovider.py
94.44% <68.42%> (ø)

botocore/response.py
92.77% <83.33%> (ø)

botocore/httpsession.py
91.60% <88.88%> (ø)

botocore/model.py
98.27% <89.47%> (ø)

botocore/retries/adaptive.py
98.48% <90.00%> (ø)

botocore/waiter.py
98.29% <92.30%> (ø)

botocore/hooks.py
95.66% <93.33%> (ø)

botocore/utils.py
93.60% <93.93%> (-0.07%)
:arrow_down:

... and 49 more

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 f960a8d...97eec9c. Read the comment docs.


VR/Multiview - shader debugging on any slice of the texture

Description
Hello, I am currently developing contents for VR and I am debugging a graphics bug that only happens on one eye.
When I debug a output texture with multiple slices, I find the shader debugger can only debug pixels on the last slice regardless which slice I choose. _ViewIndex (or SV_ViewID) is always 1. Thus I can only debug the pixel on the right eye, not the left.
Is there any way to debug the first slice (left eye) currently? If no we'd like to request this feature.
Thank you.
Environment

RenderDoc version: RenderDoc Meta Fork 55.3 (forked from RenderDoc v1.28) (Qt version 5.9.4)
Operating System: Windows 10/Quest 2
Graphics API: Vulkan

This problem is similar to #763 where pixel debugging can't disambiguate between two draws that overlap the same pixel without a discriminator. In that case it happens with plain instancing and it's not possible to disambiguate because the instance ID can't be obtained in the pixel shader, but in this case with the view index that can be used as an input so it should be possible to resolve this automatically.
As a workaround you may be able to use the pixel history to pick the particular pixel you're interested in, as it will be able to differentiate based on primitive as long as it's a complex enough mesh that it's not the same primitive touching the same pixel in both eyes. If that doesn't work, the other alternative would be to edit the vertex shader to discard the mesh in one of the eyes temporarily, so you only have the instance you want to debug being rendered.

Supported in a9caf68c9a4b5efa9d3b6eb82ccc1e13d311bd63

Thank you soooo much!


phpstan fixes

Thanks.

hm i introduced some styling bugs looks like, didnt noticed failed pipeline, sorry

No problem. I am working on it.


[composer] Addback 2.x series with 2.3.4

Add back 2.x series with 2.3
Add 2.3.4 version info
Update 2.2 series
Fix php version info

FIXES: 1031
BUG: 1031

This will also fix #1031
[note for myself : i really need to learn how to close bugs with commit logs on github ]
@BiNZGi Thank you again for heads up 🎉 👍 🥇 💯

And not related but i think they made a mistake to not bump its min php version to 8.x


[feat] New Comparators

@mattmilburn Here is the list of comparators that could be implemented. What do you think about this list and the comparators naming? Could I take this task in progress?

lessThan
lessThanOrEqual
greaterThan
greaterThanOrEqual
between

@mattmilburn after completing this task, I would like to write and publish an article about this plugin on my blog. In this article, I would describe the use cases, configuration instructions, usage examples, a list of APIs, invite people to contribute to this project, and also indicate you as the creator and maintainer. What do you think about it ? Don't you mind?

@BorysShulyak That would be great to add these new comparators! What do you think about using lt, gt, lte, and gte for the less/greater comparator keys?

@BorysShulyak Absolutely, that would be great! ❤  Let me know when you post it 🙂

@mattmilburn after completing this task, I would like to write and publish an article about this plugin on my blog. In this article, I would describe the use cases, configuration instructions, usage examples, a list of APIs, invite people to contribute to this project, and also indicate you as the creator and maintainer. What do you think about it ? Don't you mind?

@BorysShulyak Absolutely, that would be great! ❤  Let me know when you post it 🙂

After these new comparators are implemented, the plugin will be able to release version 1.1.0 👍🏻

https://github.com/mattmilburn/strapi-plugin-do-not-delete/pull/15 Ready for the review!


feat: uffizzi integration

Description
Uffizzi CI/CD integration.

I added some comments but they're mostly optional changes. This PR looks good!


refactoring: VAEC and SVAEC as subclasses of VAE

There's a lot of duplicated code in the VAE, VAEC, and SVAEC classes. To get rid of it, lets make VAEC and SVAEC subclasses of VAE. In addition to avoiding duplicated code (which is hard to maintain), it's nice conceptually to express our semi-supervised models as specializations or our unsupervised scVI model.
Also, I wonder about whether SVAEC could inherit from VAEC, or whether even we need both SVAEC and VAEC.

For sure, we can at least factorize __init__, sample_from_posterior_z, sample_from_posterior_l, get_sample_scale,  get_sample_rate based on the VAE class. I can take care of that. However the forward methods seems difficult to inherit, so there will be full overriding for VAEC and SVAEC I imagine. I think SVAEC can't inherit anything VAEC: for the __init__ their Classifier has different n_input, n_ouput, and for the forward the only edges in common are already the ones shared with VAE.

431d066: started doing it.
Not sure, however, about how to factorize forward without creating intermediary methods with long arguments list and long signatures.

You're right -- we don't want tiny functions with long argument lists. Maybe fine to have some duplicated code in forward methods then.


DataArrays to/from Zarr Arrays

Right now, open_zarr and Dataset.to_zarr only work with Zarr groups. Zarr Groups can contain multiple Array objects.
It would be nice if we could open Zarr Arrays directly as xarray DataArrays and write xarray DataArrays directly to Zarr Arrays.
However, this might not make sense, because, unlike xarray DataArrays, zarr Arrays can't hold any coordinates.
Just raising this idea for discussion.

We created https://github.com/carbonplan/xrefcoord to generate coordinates from GeoTiff metadata using kerchunk reference files and xarray without needing to store the coordinates. As discussed in https://github.com/fsspec/kerchunk/issues/313, the ability to open Zarr arrays in xarray would allow using kerchunk on a broader set of GeoTIFFs but would require experience with the backend code and/or non-trivial amounts of time.
Do you think using xarray's flexible backends with zarrita could provide a way to both solve this problem and experiment with the most recent v3 spec in xarray without requiring as much experience with xarray's current backend code?

The functionality to call to_zarr has been added and they can be then opened using `open_dataset('...', engine='zarr'), so I think this issues could be closed?
https://github.com/pydata/xarray/issues/7692

The functionality to call to_zarr has been added and they can be then opened using `open_dataset('...', engine='zarr'), so I think this issues could be closed? #7692

They primary functionality we found missing in https://github.com/fsspec/kerchunk/issues/313 was the ability to open Zarr arrays as xarray DataArrays. afaik https://github.com/pydata/xarray/issues/7692 allows dataarrays to be written to Zarr groups, and Zarr groups can be read as datasets, but Zarr arrays still cannot be read by Xarray. The ability to directly read Zarr arrays would be extremely helpful for reading data objects created outside Xarray.

Hi, is there any update on this?
I also am saving a DataArray to zarr, which I would then need to read as a DataArray (right now it only reads as DataSet).

For everyone interested in this feature: we would welcome a PR! It should be a straightforward extension of open_dataaaray. The xarray core dev team would be happy to provide support and advice along the way. To get started, check out the contributing guide.

For everyone interested in this feature: we would welcome a PR! It should be a straightforward extension of open_dataaaray. The xarray core dev team would be happy to provide support and advice along the way. To get started, check out the contributing guide.

Hi @rabernat,
Unhappily, I'm not (in any short-medium time) going to have bandwidth for a PR.
However, I managed to get this code running for myself:
import xarray as xr

ds = xr.open_zarr(path)
array = ds.to_array(dim='extra').squeeze('extra')

That seems to work easily enough.

@rabernat do you think this may be a manageable first contribution? I see that to_zarr is implemented already, but this would implement the corresponding open_zarr bit from what I understand.
I'll take a closer look this week at what it might take.
I would also benefit from this as I often only have a single variable and often select the variable as shown ^.


istiod: emote error: tls: unknown certificate

Bug description
# kubectl get pod -n istio-system
NAME                                    READY   STATUS    RESTARTS   AGE
istio-ingressgateway-7ddfcd8cfc-vzxmd   1/1     Running   0          33m
istiod-7d64d56fd4-jmmd4                 1/1     Running   0          16m
prometheus-f5957c89d-zbrdf              2/2     Running   0          16m

# kubectl logs -f -n istio-system istiod-7d64d56fd4-jmmd4 --tail=20
2020-03-06T11:18:49.546985Z     info    http: TLS handshake error from <IP_ADDRESS>:43200: remote error: tls: unknown certificate
2020-03-06T11:18:50.631100Z     info    http: TLS handshake error from <IP_ADDRESS>:54202: remote error: tls: unknown certificate
2020-03-06T11:18:56.771569Z     info    http: TLS handshake error from <IP_ADDRESS>:43264: remote error: tls: unknown certificate
2020-03-06T11:18:57.854760Z     info    http: TLS handshake error from <IP_ADDRESS>:53230: remote error: tls: unknown certificate
2020-03-06T11:19:03.844121Z     info    http: TLS handshake error from <IP_ADDRESS>:53296: remote error: tls: unknown certificate
2020-03-06T11:19:12.726721Z     info    http: TLS handshake error from <IP_ADDRESS>:54416: remote error: tls: unknown certificate

[X ] Installation
How was Istio installed?
# cat IstioOperator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: istiocontrolplane
spec:
  profile: default
  hub: harbortest.hupu.io/k8s
  tag: "1.5.0"
  namespace: istio-system
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      hub: harbortest.hupu.io/k8s
      tag: 1.5.0
      cniBinDir: /opt/cni/bin
      cniConfDir: /etc/cni/net.d
      excludeNamespaces:
       - istio-system
       - istio-operator
       - kube-system
       - monitoring
      logLevel: info

# kubectl apply -f IstioOperator.yaml

Environment where bug was observed (cloud vendor, OS, etc)
centos 7.6
istio 1.5.0

Can you provide some more info? Are those IPs failing to connect some proxies? are they 1.4 proxies or 1.5?

We are seeing same observation where ingressgateways stood on 1.4.5 and never got updated to 1.5 and istiod showing a lot of tls errors as @kong62 mentioned.
So far we have had to revert to a working 1.4.5 version since the environment was completely down.
Will play with this for the weekend and open or keep posting here some findings out.

@cober what is your config for the 1.4? Specifically, can you check the discoveryAddress (should be a flag on the gateway, or check the gateway logs)?

@howardjohn this is a log from one of our ingressgateway pods, however 1.5 ones are not even there.
the way we update istio is like this, however, I have some issues getting logs but some I was also getting some errors doing it that way, that could explain why Gateway resource is not even applied. Error was something like:
proto: tag has too few fields: "-"
cat <<EOF > istio.yaml apiVersion: install.istio.io/v1alpha2 kind: IstioControlPlane spec:   trafficManagement:     components:       pilot:         k8s:           hpaSpec:             maxReplicas: 5             minReplicas: 3   telemetry:     enabled: ${TELEMETRY_ENABLED}   gateways:     components:       ingressGateway:         k8s:           hpaSpec:             maxReplicas: 5             minReplicas: 3 EOF
NAME                                    READY   STATUS    RESTARTS   AGE
ab-ingressgateway-6fb5d98f96-xdpnd      1/1     Running   0          118m
istio-ingressgateway-85846f5c74-2kg7d   1/1     Running   0          3h29m
istio-ingressgateway-85846f5c74-kmhj2   1/1     Running   0          3h29m
istio-ingressgateway-85846f5c74-vr562   1/1     Running   0          3h29m
istiod-59f6fbc78f-86vvb                 1/1     Running   0          8m8s
istiod-59f6fbc78f-fgjkf                 1/1     Running   0          8m8s
istiod-59f6fbc78f-qtjss                 1/1     Running   0          8m8s
prometheus-568b44b54f-mn2tp             2/2     Running   0          7m43s
`2020-03-06T14:18:35.263098Z     info    FLAG: --applicationPorts="[]"
2020-03-06T14:18:35.263140Z     info    FLAG: --binaryPath="/usr/local/bin/envoy"
2020-03-06T14:18:35.263146Z     info    FLAG: --concurrency="0"
2020-03-06T14:18:35.263149Z     info    FLAG: --configPath="/etc/istio/proxy"
2020-03-06T14:18:35.263161Z     info    FLAG: --connectTimeout="10s"
2020-03-06T14:18:35.263165Z     info    FLAG: --controlPlaneAuthPolicy="MUTUAL_TLS"
2020-03-06T14:18:35.263169Z     info    FLAG: --controlPlaneBootstrap="true"
2020-03-06T14:18:35.263172Z     info    FLAG: --customConfigFile=""
2020-03-06T14:18:35.263175Z     info    FLAG: --datadogAgentAddress=""
2020-03-06T14:18:35.263178Z     info    FLAG: --disableInternalTelemetry="false"
2020-03-06T14:18:35.263181Z     info    FLAG: --discoveryAddress="istio-pilot.istio-system:15011"
2020-03-06T14:18:35.263184Z     info    FLAG: --dnsRefreshRate="300s"
2020-03-06T14:18:35.263231Z     info    FLAG: --domain="istio-system.svc.cluster.local"
2020-03-06T14:18:35.263237Z     info    FLAG: --drainDuration="45s"
2020-03-06T14:18:35.263241Z     info    FLAG: --envoyAccessLogService=""
2020-03-06T14:18:35.263245Z     info    FLAG: --envoyMetricsService=""
2020-03-06T14:18:35.263250Z     info    FLAG: --help="false"
2020-03-06T14:18:35.263254Z     info    FLAG: --id=""
2020-03-06T14:18:35.263258Z     info    FLAG: --ip=""
2020-03-06T14:18:35.263262Z     info    FLAG: --lightstepAccessToken=""
2020-03-06T14:18:35.263266Z     info    FLAG: --lightstepAddress=""
2020-03-06T14:18:35.263270Z     info    FLAG: --lightstepCacertPath=""
2020-03-06T14:18:35.263274Z     info    FLAG: --lightstepSecure="false"
2020-03-06T14:18:35.263279Z     info    FLAG: --log_as_json="false"
2020-03-06T14:18:35.263308Z     info    FLAG: --log_caller=""
2020-03-06T14:18:35.263313Z     info    FLAG: --log_output_level="default:info"
2020-03-06T14:18:35.263317Z     info    FLAG: --log_rotate=""
2020-03-06T14:18:35.263322Z     info    FLAG: --log_rotate_max_age="30"
2020-03-06T14:18:35.263326Z     info    FLAG: --log_rotate_max_backups="1000"
2020-03-06T14:18:35.263330Z     info    FLAG: --log_rotate_max_size="104857600"
2020-03-06T14:18:35.263335Z     info    FLAG: --log_stacktrace_level="default:none"
2020-03-06T14:18:35.263351Z     info    FLAG: --log_target="[stdout]"
2020-03-06T14:18:35.263356Z     info    FLAG: --mixerIdentity=""
2020-03-06T14:18:35.263360Z     info    FLAG: --parentShutdownDuration="1m0s"
2020-03-06T14:18:35.263364Z     info    FLAG: --pilotIdentity=""
2020-03-06T14:18:35.263370Z     info    FLAG: --proxyAdminPort="15000"
2020-03-06T14:18:35.263375Z     info    FLAG: --proxyComponentLogLevel="misc:error"
2020-03-06T14:18:35.263379Z     info    FLAG: --proxyLogLevel="warning"
2020-03-06T14:18:35.263384Z     info    FLAG: --serviceCluster="istio-ingressgateway"
2020-03-06T14:18:35.263389Z     info    FLAG: --serviceregistry="Kubernetes"
2020-03-06T14:18:35.263393Z     info    FLAG: --statsdUdpAddress=""
2020-03-06T14:18:35.263397Z     info    FLAG: --statusPort="15020"
2020-03-06T14:18:35.263402Z     info    FLAG: --templateFile=""
2020-03-06T14:18:35.263407Z     info    FLAG: --trust-domain="cluster.local"
2020-03-06T14:18:35.263426Z     info    FLAG: --zipkinAddress="zipkin.istio-system:9411"
2020-03-06T14:18:35.263475Z     info    Version 1.4.6-f288658b710d932bd4b0200728920fe3cbe0af61-Clean
2020-03-06T14:18:35.263676Z     info    Obtained private IP [<IP_ADDRESS>]
2020-03-06T14:18:35.263732Z     info    Proxy role: &model.Proxy{ClusterID:"", Type:"router", IPAddresses:[]string{"<IP_ADDRESS>", "<IP_ADDRESS>"}, ID:"istio-ingressgateway-85846f5c74-2kg7d.istio-system", Locality:(*envoy_api_v2_core.Locality)(nil), DNSDomain:"istio-system.svc.cluster.local", ConfigNamespace:"", Metadata:(*model.NodeMetadata)(nil), SidecarScope:(*model.SidecarScope)(nil), MergedGateway:(*model.MergedGateway)(nil), ServiceInstances:[]*model.ServiceInstance(nil), WorkloadLabels:labels.Collection(nil), IstioVersion:(*model.IstioVersion)(nil)}
2020-03-06T14:18:35.263745Z     info    PilotSAN []string{"spiffe://cluster.local/ns/istio-system/sa/istio-pilot-service-account"}
2020-03-06T14:18:35.263753Z     info    MixerSAN []string{"spiffe://cluster.local/ns/istio-system/sa/istio-mixer-service-account"}
2020-03-06T14:18:35.264412Z     info    Effective config: binaryPath: /usr/local/bin/envoy
configPath: /etc/istio/proxy
connectTimeout: 10s
controlPlaneAuthPolicy: MUTUAL_TLS
discoveryAddress: istio-pilot.istio-system:15011
drainDuration: 45s
envoyAccessLogService: {}
envoyMetricsService: {}
parentShutdownDuration: 60s
proxyAdminPort: 15000
serviceCluster: istio-ingressgateway
statNameLength: 189
tracing:
zipkin:
address: zipkin.istio-system:9411
2020-03-06T14:18:35.264450Z     info    Monitored certs: []string{"/etc/certs/cert-chain.pem", "/etc/certs/key.pem", "/etc/certs/root-cert.pem"}
2020-03-06T14:18:35.264457Z     info    waiting 2m0s for /etc/certs/cert-chain.pem
2020-03-06T14:18:35.264478Z     info    waiting 2m0s for /etc/certs/key.pem
2020-03-06T14:18:35.264486Z     info    waiting 2m0s for /etc/certs/root-cert.pem
2020-03-06T14:18:35.264515Z     info    PilotSAN []string{"spiffe://cluster.local/ns/istio-system/sa/istio-pilot-service-account"}
2020-03-06T14:18:35.264530Z     info    Starting proxy agent
2020-03-06T14:18:35.264584Z     info    Opening status port 15020
2020-03-06T14:18:35.264852Z     info    Received new config, creating new Envoy epoch 0
2020-03-06T14:18:35.264924Z     info    watching /etc/certs for changes
2020-03-06T14:18:35.264910Z     info    Epoch 0 starting
2020-03-06T14:18:35.280582Z     info    Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-ingressgateway --service-node router~<IP_ADDRESS>~istio-ingressgateway-85846f5c74-2kg7d.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 --local-address-ip-version v4 --log-format [Envoy (Epoch 0)] [%Y-%m-%d %T.%e][%t][%l][%n] %v -l warning --component-log-level misc:error]
[Envoy (Epoch 0)] [2020-03-06 14:18:35.324][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, no healthy upstream
[Envoy (Epoch 0)] [2020-03-06 14:18:35.324][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:54] Unable to establish new stream
2020-03-06T14:18:36.388935Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:38.388900Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:40.388967Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:42.388781Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:44.388769Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:46.388672Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
[Envoy (Epoch 0)] [2020-03-06 14:18:46.564][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
[Envoy (Epoch 0)] [2020-03-06 14:18:47.703][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
2020-03-06T14:18:48.388790Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:50.388727Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
[Envoy (Epoch 0)] [2020-03-06 14:18:50.903][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
2020-03-06T14:18:52.388762Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
[Envoy (Epoch 0)] [2020-03-06 14:18:52.631][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
2020-03-06T14:18:54.388657Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:56.392473Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:18:58.388692Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:00.388911Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:02.388769Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:04.388732Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:06.388982Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:08.388757Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:10.389141Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:12.388962Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:14.388914Z     info    Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected
2020-03-06T14:19:16.390303Z     info    Envoy proxy is ready
[Envoy (Epoch 0)] [2020-03-06 14:33:59.538][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 14:51:49.430][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:04:05.693][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:09:06.668][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:14:07.776][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:19:08.825][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:24:09.825][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:29:10.789][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:34:11.777][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:39:12.853][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:44:13.868][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:49:14.835][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:52:16.280][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 15:59:16.776][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:04:17.867][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:09:18.897][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:14:19.770][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:19:20.839][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:19:50.039][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:29:22.859][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:34:23.860][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:39:24.997][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:44:25.922][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:49:26.908][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:52:29.174][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 16:59:28.993][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:04:29.977][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:09:31.086][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:14:32.079][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:19:32.959][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:20:06.615][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:29:35.041][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:34:36.018][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:39:37.090][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:40:16.116][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
[Envoy (Epoch 0)] [2020-03-06 17:40:16.505][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
[Envoy (Epoch 0)] [2020-03-06 17:40:16.691][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
[Envoy (Epoch 0)] [2020-03-06 17:40:18.648][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
[Envoy (Epoch 0)] [2020-03-06 17:40:20.823][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
[Envoy (Epoch 0)] [2020-03-06 17:40:28.183][19][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, upstream connect error or disconnect/reset before headers. reset reason: connection failure
[Envoy (Epoch 0)] [2020-03-06 17:40:39.583][26][warning][filter] [src/istio/mixerclient/report_batch.cc:110] Mixer Report failed with: UNAVAILABLE:upstream connect error or disconnect/reset before headers. reset reason: connection failure`
istiod logs:
2020-03-06T17:40:57.760004Z     info    Handling event update for pod prometheus-568b44b54f-mn2tp in namespace istio-system -> <IP_ADDRESS> 2020-03-06T17:41:00.851749Z     info    http: TLS handshake error from <IP_ADDRESS>:57832: remote error: tls: unknown certificate 2020-03-06T17:41:01.221354Z     info    successfully acquired lease istio-system/istio-leader 2020-03-06T17:41:01.221597Z     info    Starting validation controller 2020-03-06T17:41:01.221671Z     info    Starting ingress status controller 2020-03-06T17:41:01.221730Z     info    validationController    Reconcile(enter): initial request to kickstart reconciliation 2020-03-06T17:41:01.221755Z     info    validationController    Endpoint istiod is not ready: resource not found 2020-03-06T17:41:01.222034Z     warn    validationController    validatingwebhookconfiguration.admissionregistration.k8s.io "istiod-istio-system" not found 2020-03-06T17:41:01.225437Z     info    validationController    Reconcile(enter): add event (v1, Kind=Endpoints) istio-system/istiod 2020-03-06T17:41:01.225480Z     info    validationController    Endpoint istiod is not ready 2020-03-06T17:41:01.236650Z     info    validationController    Not ready to switch validation to fail-closed: dummy invalid config not rejected 2020-03-06T17:41:01.241679Z     info    validationController    Successfully updated validatingwebhookconfiguration istiod-istio-system (failurePolicy=Ignore,resourceVersion=230375737) 2020-03-06T17:41:01.241741Z     info    validationController    Reconcile(enter): add event (admissionregistration.k8s.io/v1beta1, Kind=ValidatingWebhookConfiguration) istiod-istio-system 2020-03-06T17:41:01.255568Z     info    validationServer        configuration is invalid: gateway must have at least one server 2020-03-06T17:41:01.258003Z     info    validationController    Endpoint successfully rejected invalid config. Switching to fail-close. 2020-03-06T17:41:01.262234Z     info    validationController    Successfully updated validatingwebhookconfiguration istiod-istio-system (failurePolicy=Fail,resourceVersion=230375738) 2020-03-06T17:41:01.262275Z     info    validationController    Reconcile(enter): update event (admissionregistration.k8s.io/v1beta1, Kind=ValidatingWebhookConfiguration) istiod-istio-system 2020-03-06T17:41:01.265583Z     error   validationController    Failed to update validatingwebhookconfiguration istiod-istio-system (failurePolicy=Fail, resourceVersion=230375737): Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istiod-istio-system": the object has been modified; please apply your changes to the latest version and try again 2020-03-06T17:41:01.265636Z     error   Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istiod-istio-system": the object has been modified; please apply your changes to the latest version and try again 2020-03-06T17:41:01.265649Z     info    validationController    Reconcile(enter): update event (admissionregistration.k8s.io/v1beta1, Kind=ValidatingWebhookConfiguration) istiod-istio-system 2020-03-06T17:41:01.266009Z     info    validationController    validatingwebhookconfiguration istiod-istio-system (failurePolicy=Fail, resourceVersion=230375738) is up-to-date. No change required. 2020-03-06T17:41:01.266856Z     info    validationController    Reconcile(enter): update event (admissionregistration.k8s.io/v1beta1, Kind=ValidatingWebhookConfiguration) istiod-istio-system 2020-03-06T17:41:01.267225Z     info    validationController    validatingwebhookconfiguration istiod-istio-system (failurePolicy=Fail, resourceVersion=230375738) is up-to-date. No change required. 2020-03-06T17:41:01.321678Z     info    Namespace controller started 2020-03-06T17:41:01.476955Z     info    http: TLS handshake error from <IP_ADDRESS>:53480: remote error: tls: unknown certificate 2020-03-06T17:41:02.236952Z     info    validationController    Reconcile(enter): retry dry-run creation of invalid config 2020-03-06T17:41:02.237459Z     info    validationController    validatingwebhookconfiguration istiod-istio-system (failurePolicy=Fail, resourceVersion=230375738) is up-to-date. No change required. 2020-03-06T17:41:04.120330Z     info    http: TLS handshake error from <IP_ADDRESS>:38838: remote error: tls: unknown certificate 2020-03-06T17:41:04.832626Z     info    Handling event update for pod prometheus-568b44b54f-mn2tp in namespace istio-system -> <IP_ADDRESS> 2020-03-06T17:41:04.839084Z     info    Handle EDS: 1 endpoints for prometheus in namespace istio-system 2020-03-06T17:41:04.939381Z     info    ads     Push debounce stable[10] 1: 100.214996ms since last change, 100.214743ms since last push, full=false 2020-03-06T17:41:04.939509Z     info    ads     XDS:EDSInc Pushing:2020-03-06T17:40:40Z/5 Services:map[prometheus.istio-system.svc.cluster.local:{}] ConnectedEndpoints:0 2020-03-06T17:41:04.939517Z     info    ads     Cluster init time 787ns 2020-03-06T17:40:40Z/5 2020-03-06T17:41:05.114624Z     info    http: TLS handshake error from <IP_ADDRESS>:39934: remote error: tls: unknown certificate 2020-03-06T17:41:05.749006Z     info    http: TLS handshake error from <IP_ADDRESS>:35070: remote error: tls: unknown certificate 2020-03-06T17:41:07.456668Z     info    http: TLS handshake error from <IP_ADDRESS>:47500: remote error: tls: unknown certificate 2020-03-06T17:41:08.028275Z     info    http: TLS handshake error from <IP_ADDRESS>:58012: remote error: tls: unknown certificate 2020-03-06T17:41:09.960373Z     info    http: TLS handshake error from <IP_ADDRESS>:41350: remote error: tls: unknown certificate 2020-03-06T17:41:12.800727Z     info    http: TLS handshake error from <IP_ADDRESS>:35734: remote error: tls: unknown certificate 2020-03-06T17:41:13.146325Z     info    http: TLS handshake error from <IP_ADDRESS>:48390: remote error: tls: unknown certificate 2020-03-06T17:41:14.146204Z     info    http: TLS handshake error from <IP_ADDRESS>:55770: remote error: tls: unknown certificate 2020-03-06T17:41:16.807028Z     info    http: TLS handshake error from <IP_ADDRESS>:55158: remote error: tls: unknown certificate 2020-03-06T17:41:18.365102Z     info    http: TLS handshake error from <IP_ADDRESS>:39082: remote error: tls: unknown certificate 2020-03-06T17:41:19.857020Z     info    http: TLS handshake error from <IP_ADDRESS>:35350: remote error: tls: unknown certificate 2020-03-06T17:41:20.774989Z     info    http: TLS handshake error from <IP_ADDRESS>:44442: remote error: tls: unknown certificate 2020-03-06T17:41:22.003314Z     info    http: TLS handshake error from <IP_ADDRESS>:56176: remote error: tls: unknown certificate 2020-03-06T17:41:22.738424Z     info    http: TLS handshake error from <IP_ADDRESS>:33614: remote error: tls: unknown certificate 2020-03-06T17:41:23.653863Z     info    http: TLS handshake error from <IP_ADDRESS>:54124: remote error: tls: unknown certificate 2020-03-06T17:41:24.294697Z     info    http: TLS handshake error from <IP_ADDRESS>:38904: remote error: tls: unknown certificate 2020-03-06T17:41:26.043473Z     info    http: TLS handshake error from <IP_ADDRESS>:47082: remote error: tls: unknown certificate 2020-03-06T17:41:26.745589Z     info    http: TLS handshake error from <IP_ADDRESS>:41668: remote error: tls: unknown certificate 2020-03-06T17:41:28.893879Z     info    http: TLS handshake error from <IP_ADDRESS>:44116: remote error: tls: unknown certificate 2020-03-06T17:41:29.374973Z     info    http: TLS handshake error from <IP_ADDRESS>:35544: remote error: tls: unknown certificate 2020-03-06T17:41:35.750881Z     info    http: TLS handshake error from <IP_ADDRESS>:38580: remote error: tls: unknown certificate 2020-03-06T17:41:37.071084Z     info    http: TLS handshake error from <IP_ADDRESS>:49068: remote error: tls: unknown certificate 2020-03-06T17:41:37.192421Z     info    http: TLS handshake error from <IP_ADDRESS>:42510: remote error: tls: unknown certificate 2020-03-06T17:41:39.777400Z     info    http: TLS handshake error from <IP_ADDRESS>:54578: remote error: tls: unknown certificate 2020-03-06T17:41:40.091853Z     info    http: TLS handshake error from <IP_ADDRESS>:48064: remote error: tls: unknown certificate 2020-03-06T17:41:41.045698Z     info    http: TLS handshake error from <IP_ADDRESS>:44852: remote error: tls: unknown certificate 2020-03-06T17:41:42.928681Z     info    http: TLS handshake error from <IP_ADDRESS>:43472: remote error: tls: unknown certificate 2020-03-06T17:41:43.163509Z     info    http: TLS handshake error from <IP_ADDRESS>:47522: remote error: tls: unknown certificate 2020-03-06T17:41:45.497516Z     info    http: TLS handshake error from <IP_ADDRESS>:36442: remote error: tls: unknown certificate 2020-03-06T17:41:47.312218Z     info    http: TLS handshake error from <IP_ADDRESS>:40034: remote error: tls: unknown certificate 2020-03-06T17:41:49.283749Z     info    http: TLS handshake error from <IP_ADDRESS>:44262: remote error: tls: unknown certificate 2020-03-06T17:41:49.465068Z     info    http: TLS handshake error from <IP_ADDRESS>:39768: remote error: tls: unknown certificate 2020-03-06T17:41:51.537973Z     info    ads     ADS:CDS: REQ <IP_ADDRESS>:53940 sidecar~<IP_ADDRESS>~pmt-website-6d795fc696-dnjlc.test~test.svc.cluster.local-1 1.334368ms version:2020-03-06T14:18:27Z/12 2020-03-06T17:41:51.543541Z     info    ads     CDS: PUSH for node:pmt-website-6d795fc696-dnjlc.test clusters:143 services:99 version:2020-03-06T17:40:40Z/5 2020-03-06T17:41:51.543885Z     warn    ads     service lookup for hostname istio-sidecar-injector.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.543940Z     warn    ads     service lookup for hostname istio-policy.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.543960Z     warn    ads     service lookup for hostname istio-policy.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.544005Z     warn    ads     service lookup for hostname istio-galley.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.544018Z     warn    ads     service lookup for hostname istio-galley.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.544049Z     warn    ads     service lookup for hostname istio-galley.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.544069Z     warn    ads     service lookup for hostname istio-galley.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.544084Z     warn    ads     service lookup for hostname istio-citadel.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.544103Z     warn    ads     service lookup for hostname istio-citadel.istio-system.svc.cluster.local failed 2020-03-06T17:41:51.546388Z     info    ads     EDS: PUSH for node:pmt-website-6d795fc696-dnjlc.test clusters:125 endpoints:141 empty:23 2020-03-06T17:41:51.554520Z     info    ads     LDS: PUSH for node:pmt-website-6d795fc696-dnjlc.test listeners:119 2020-03-06T17:41:51.557413Z     info    ads     RDS: PUSH for node:pmt-website-6d795fc696-dnjlc.test routes:89 2020-03-06T17:41:52.068604Z     info    ads     EDS: PUSH for node:pmt-website-6d795fc696-dnjlc.test clusters:121 endpoints:158 empty:14 2020-03-06T17:41:52.395885Z     info    ads     RDS: PUSH for node:pmt-website-6d795fc696-dnjlc.test routes:90 2020-03-06T17:41:53.917186Z     info    http: TLS handshake error from <IP_ADDRESS>:51306: remote error: tls: unknown certificate 2020-03-06T17:41:57.531869Z     info    http: TLS handshake error from <IP_ADDRESS>:44908: remote error: tls: unknown certificate 2020-03-06T17:41:58.786317Z     info    http: TLS handshake error from <IP_ADDRESS>:36130: remote error: tls: unknown certificate 2020-03-06T17:41:58.855977Z     info    http: TLS handshake error from <IP_ADDRESS>:36132: remote error: tls: unknown certificate 2020-03-06T17:42:01.293291Z     info    http: TLS handshake error from <IP_ADDRESS>:58808: remote error: tls: unknown certificate 2020-03-06T17:42:01.712578Z     info    http: TLS handshake error from <IP_ADDRESS>:55132: remote error: tls: unknown certificate

I am seeing similar errors, has there been any movement on debugging this?

I believe this is fixed in Istio 1.5.2: https://github.com/istio/istio/issues/22841
Please try this version. if this reproduces please open another issue/reopen. Thanks!


NTR: coma severity assay

Definition: An assay that has the objective to determine the severity of coma in a patient.
Parent: physical examination of individual
I'm submitting this as a general term for an assay that has a coma scale as an output, such as the Blantyre or Glasgow coma scale.

discussed on 2021-06-14: def= A physical examination of individual that has the objective to determine the severity of coma in a patient.
examples of usage:  examining a patient and grading their coma status on the Blantyre or Glasgow coma scale.


Add thin platforms that you can jump up through but stand on.

In 2D platforms that you can jump up through make a lot of sense. Bit like ladders, but can stand on top of them.
Add another setting to the block definition, blocksHead, and adjust the "isHittingHead" check.

I got this

I don't think this should block on sides either though. Will use blocks:false, blocksDown:true and only change standingOnSomething()

Thanks for approving! In my decades of coding this was my first merge request to open source.


tpnote: 1.24.10 -> 1.24.11

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/getreu/tp-note/releases.
meta.description for tpnote is: Markup enhanced granular note-taking
meta.homepage for tpnote is: https://blog.getreu.net/projects/tp-note/
meta.changelog for tpnote is: https://github.com/getreu/tp-note/releases/tag/v1.24.11
Updates performed

Rust version update

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.24.11 with grep in /nix/store/7xhi9rnrpys0nqjfi5gk2r1m1vnhjprj-tpnote-1.24.11
found 1.24.11 in filename of file in /nix/store/7xhi9rnrpys0nqjfi5gk2r1m1vnhjprj-tpnote-1.24.11

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

tpnote

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7xhi9rnrpys0nqjfi5gk2r1m1vnhjprj-tpnote-1.24.11 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A tpnote https://github.com/r-ryantm/nixpkgs/archive/520ecf9e4efc82879be7849d0e80cd711361d0d6.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/520ecf9e4efc82879be7849d0e80cd711361d0d6#tpnote

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/7xhi9rnrpys0nqjfi5gk2r1m1vnhjprj-tpnote-1.24.11
ls -la /nix/store/7xhi9rnrpys0nqjfi5gk2r1m1vnhjprj-tpnote-1.24.11/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

tpnote

Maintainer pings
cc @getreu for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

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

@NixOS/nixpkgs-merge-bot merge


Albums are not ordered Correctly

Chora isn't ordering songs in a album correctly even if correct track numbering is provided

Will be fixed in the next release.
In the new Navidrome integration i wasn't getting the track index.


Add webpack.config.js example to install doc

What: Update to the installation documentation

Why: Clarify adding emotion via webpack.config.js vs .babelrc. If users have babel-loader in webpack config, putting emotion plugin into .babelrc can cause subtle bugs, depending on which other plugins are being used – seems that plugins in webpack.config.js run before those in .babelrc.

How:

Checklist:

[x] Documentation
[ ] Tests N/A
[ ] Code complete N/A

Codecov Report

Merging #158 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #158   +/-   ##
=======================================
  Coverage   90.14%   90.14%
=======================================
  Files          22       22
  Lines         700      700
  Branches      166      166
=======================================
  Hits          631      631
  Misses         56       56
  Partials       13       13

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 e9c820d...01830b3. Read the comment docs.


wsl doesn't keep running in background after closing window

Version
Microsoft Windows [版本 10.0.25267.1000]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Ubuntu
Other Software
WSL 版本： <IP_ADDRESS>
内核版本： <IP_ADDRESS>
WSLg 版本： 1.0.47
MSRDC 版本： 1.2.3575
Direct3D 版本： 1.606.4
DXCore 版本： 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows版本： 10.0.25267.1000
Repro Steps
After closing the wsl window
Expected Behavior
ubuntu stops working after closing the window

Actual Behavior
no
Diagnostic Logs
No response

Howdy. Do you have any daemonized processes running inside wsl? If not then this looks like expected behavior to me.

Howdy. Do you have any daemonized processes running inside wsl? If not then this looks like expected behavior to me.

There is a docker daemon running.

Facing the same issues.

Howdy. Do you have any daemonized processes running inside wsl? If not then this looks like expected behavior to me.

There is a docker daemon running.

Can you show the output of ps -auxf? If the process in question is not parented to relay init (Pid 564 in my case) then it will not keep the distro alive.

@hipengwen Can you try the below?
I have several WSL2 environments, using either one config below will autorun the WSL2 Ubuntu instance and it will keep running in the background.

Config# 1
No global .wslconfig or Ubuntu's /etc/wsl.conf are defined
Put a cmd script file, e.g. startwsl.cmd in the Windows startup folder.
(For Windows 10/11, press WIN+R, enter shell:startup.)
Since I use putty to ssh to the WSL Ubuntu instance, the script file starts the openssh service

wsl sleep 3; sudo service ssh start
timeout /t 3

Config#2
Under registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss\<Instance-UUID> where instance-uuid refers to the WSL Ubuntu instance.
Config the key DefaultUid the default user id that matches the username defined in /etc/wsl.conf below. (user id can be found in cmd id)
create a instance config file /etc/wsl.conf

[user]
## username NOT user id
default=<default_username>

[boot]
## command=<command to run upon instance starting>
command=service ssh start

[wsl2]
localhostForwarding=true

WSL2 version info
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.1555

Will this fix in version 2.0.0 ?


Configuration file read check

Description
Configuration is not stored when the file containing configuration can't be read for any reason.
Fixes #84
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Testing steps
New unit tests are provided, so please use ./test.sh

Codecov Report

Merging #85 into master will increase coverage by 0.53%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #85      +/-   ##
==========================================
+ Coverage    31.5%   32.03%   +0.53%
==========================================
  Files          12       12
  Lines         692      693       +1
==========================================
+ Hits          218      222       +4
+ Misses        470      468       -2
+ Partials        4        3       -1

Impacted Files
Coverage Δ

commands/configurations.go
69.87% <100%> (+4.02%)
:arrow_up:

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 236f8e9...fd55040. Read the comment docs.


Showing additional information about objects

Is it possible to show more relevant information about objects?
Try to debug this code for example:
for procData in ComObjGet("winmgmts:").ExecQuery("SELECT * FROM Win32_Process WHERE name = 'explorer.exe'")
{
	cmd := procData.CommandLine
	OutputDebug cmd: %cmd%
}

Expected: commandLine value as well as all the fields from the link below are shown in a list of variables of the procData variable:
https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-process
Actual: four items are shown (Value, VarType, DispatchType, DispatchIID).

Unfortunately, the debug program only returns these four properties, so this is impossible, since 2.4.0, which supports OutputDebug printing in the console, may improve your development experience.

I did some experiments and found that it is indeed not supported.


Make this add-on Fastboot Safe

Removed the self invoking function and passed window and document in a safe time to use those references

Hey, I am willing to update this anyway you want I just needed to make this work for a important fastboot project. Just let me know what updates you want me to make. I changed up the format a bit to understand what this was doing so I could fix it. Not really sure how to add tests to prove it is fastboot safe, but it is because we using it in production. So I can assure you it is. Please add feedback, wanting to contribute back.

Thanks for the hard work, let me help you out. 😁

Also if you have any good ideas on writing a fastboot test please feel free to comment back, our team is relatively new to building and using fastboot env's and not 100% sure how to write those tests for that env yet.

Hi @jamesmenera! Thanks for putting together this pull request. I haven't used fastboot, so you're the expert. 😜
You'll likely need to rebase as I've recently merged another PR.
As a starter for feedback, please make sure the code passes linting. As far as I can tell, that's the main reason Travis CI is failing. Also, I really like the direction you're headed with refactoring the clamp function, but it would be better, organizationally, if it were a separate PR. Take care of those, clean up commented out code and trailing whitespace, and I think this will be ready to merge.

Resolved by #29


Multiple caches with the same key were stored

As far as I remember, cache keys must be unique and you cannot store two caches under the same key, correct?
If I remember correctly and that is, how it should be, then there is something broken or racy I guess.
I run a matrix build today that run a job on ubuntu-latest and a job on macos-latest in parallel.
This action checked on both jobs around 15:00 GMT whether there is a cache to restore at key innosetup.exe_6.3.3.
Both found no entry as I just added the cache action.
After the ubuntu-latest build was finished, it stored a new entry for key innosetup.exe_6.3.3 at around 15:03 GMT.
After the macos-latest build was finished, it also stored a new entry for key innosetup.exe_6.3.3 at around 15:04 GMT.
When rerunning both jobs, each restored a cache entry by that key and it seems each stored its individual entry.
I see both entries in the list of caches and see that both were reused by the rerun:

What is the explanation for this?
Does not using enableCrossOsArchive make the OS an implicit additional cache key part?
If so, the description of the option should be adapted, because it suggests that it is only relevant if Windows is part of the game which is not the case here.
So either here some implementation or infrastructure bug seems to exist,
or "just" a documentation issue.

No, enableCrossOsArchive does not change anything.
Maybe there now the same discrepancy between macos-latest and ubuntu-latest that previously were only there between Windows and the other two and enableCrossOsArchive should not only affect Windows, but also the other OS.


Feedback session 2 [meta]

Small

[x] #159 - reduce vertical spacing

[x] https://github.com/openclimatefix/nowcasting/issues/160 - OCF hyperlink

[x] https://github.com/openclimatefix/nowcasting/issues/161 - headline figure 1.d.p

[x] https://github.com/openclimatefix/nowcasting/issues/169 -set MW (not %) to default

Medium

[x] https://github.com/openclimatefix/nowcasting/issues/171
[x] https://github.com/openclimatefix/nowcasting/issues/172
[x] https://github.com/openclimatefix/nowcasting/issues/173
[ ] https://github.com/openclimatefix/nowcasting/issues/175
[x] https://github.com/openclimatefix/nowcasting/issues/170

R&D

[x] https://github.com/openclimatefix/nowcasting/issues/174
[x] https://github.com/openclimatefix/nowcasting/issues/162 - rainbow colours

Ill close this for the moment


Authoring HEVC files with hvc1 codec ID

Muxing any h265 elementary streams results in the final output track to have a codec ID of hev1 and not hvc1
This goes against Apple's HLS and QuickTime spec, and hence the final file doesn't play in QuickTime.
(I am trying to mux an HDR10 HEVC file with it's Atmos track)

Please check my fork! I followed yusesope's advice to force Apple QuickTime compatibility. It works fine for me. You are welcomed to have a try!
https://github.com/HongyuS/dlb_mp4base

Thanks for the tip! I'll be sure to make use of it

It has been fixed in v1.1.0.

Thanks @ShaoWeiguo

fixed.


[5.3] [SE-0286] Trailing closure forward scan (backward-bias edition)

Implementation of SE-0286 with the dual-scan source-compatibility trick and biasing toward maintaining existing behavior with the backward scan.
Implements rdar://problem/65615074

@swift-ci please test

@swift-ci please test source compatibility

Build failed
Swift Test OS X Platform
Git Sha - 1af4c6d0082075fc4d4556c24cd651f86245960e

fatal: the remote end hung up unexpectedly

restarting some builds

@swift-ci please test macOS

Build failed
Swift Test OS X Platform
Git Sha - 1af4c6d0082075fc4d4556c24cd651f86245960e

/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-release/5.3/swiftpm/Tests/FunctionalTests/MiscellaneousTests.swift:230: error: -[FunctionalTests.MiscellaneousTestCase testSwiftTestParallel] : XCTAssertTrue failed

I'm certain I didn't break that. Try #3.

@swift-ci please test macOS

@swift-ci please test source compatibility Release

error: index-pack died of signal 15
fatal: index-pack failed

@swift-ci please test source compatibility Release

Jenkins error. Sigh.

@swift-ci please test source compatibility Release


Asking for a yearly, recurring reminder fires a reminder every "1 year and 1 day"

For some reason the bot translates "1 year" into "1 year and 1 day" for recurring reminders.
I initially thought this might be due to leap years or something. I also tried seeing if there was some point in the year that we crossed over that extended the check out one day, but checking a little under 1 year:

we get the exact right answer. 350 days is exactly 50 weeks.

Is this really a bug? "every 1 year" translates to "every 365 days", and 52 weeks are 52 * 7 days = 364 days. So you need one extra day to get to 365.

UX wise, my intuition is that every 1 year should be the same date (day and month) every year. for example !r every 1 year; january 15 noon; example should translate to (the equivalent of) the cron expression 0 12 15 1 *.


Type error when using .schema() on a model (2.0.0-beta.0)

Versions

sequelize: 6.3.4
sequelize-typescript: 2.0.0-beta.0 (but also 1.1.0)
typescript: 3.9.7

I'm submitting a ...
[x] bug report
[ ] feature request
Actual behavior:
src/sq-ts.ts:8:9 - error TS2740: Type 'Model<{}, {}>' is missing the following properties from type 'Thing': $add, $set, $get, $count, and 3 more.

   const broken: Thing = await Thing.schema('test').findOne()
          ~~~~~~

Expected behavior:
No type error
Steps to reproduce:
Use the code from below with the versions specified above.
Related code:
import { Model } from 'sequelize-typescript';

class Thing extends Model<Thing> {
}

(async () => {
  const working: Thing = await Thing.findOne()
  const broken: Thing = await Thing.schema('test').findOne()
})()

News? I have same problem


Howto:  Using the memory manager with GPUs

We could use a high level article describing how to use the memory manager when GPUs are involved. For the meantime put it in this branch of the web repo:
https://github.com/mfem/web/tree/searchable-articles/src/howto
Examples can be found in that folder.

@camierjs Can you put this together?