ignore files generated by Metals, a vscode extension for Scala.

Reasons for making this change:
Metals, an extension for Scala, will create files.
Links to documentation supporting these rule changes:
https://scalameta.org/metals/docs/editors/vscode.html#gitignore-projectmetalssbt-metals-and-bloop
If this is a new template:

Thanks for the contribution @goatwu1993!
Given #3296 is the approach that I recommend here for defining rules for editors and tooling needs, I'm going to close this out. Let's discuss our options there.


Large number of log files generated

Similar to https://github.com/MerginMaps/mergin-media-sync/issues/22

A duplicate of #52 ?

Correct.


Fixed dotnet sdk rollforward

There was a typo in the rollForward property that prevented our build from picking up higher versions installed on developer machines. (Tested on WSL.) Also disabled pre-release SDKs.

Codecov Report

Merging #454 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #454      +/-   ##
==========================================
- Coverage   91.06%   91.04%   -0.03%
==========================================
  Files         201      201
  Lines        6784     6764      -20
==========================================
- Hits         6178     6158      -20
  Misses        606      606

Flag
Coverage Δ

#dotnet
91.04% <ø> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/Bicep.Cli.UnitTests/PathHelperTests.cs
100.00% <0.00%> (ø)


Allow resize explorer pane and terminal pane to arbitrary width

When you reduce width of explorer pane to certain minimum, it will collapse and hide the pane. But that minimum width is too large for me, there's a huge gap between filename and edge, wasting a lot of space. I rather prefer to be able to resize to any width without sudden collapse. Same request goes for terminal pane on the right/bottom.

Any follow up / comment on this request?

Panel can now be resized to max width. Sidebar can not and we will not change that


podman remote-client readme

addition of a remote-client readme.
Signed-off-by: baude<EMAIL_ADDRESS>

LGTM, thanks @baude! Let's wait for @TomSweeneyRedHat's eagle eyes :)

/lgtm


Tests for ContentKeySessionDelegate + Testability Tweaks

Hopefully MockKeyRequest isn't too java-brained. The "Record and Verify" thing done here is the standard way on that side, and it seemed like it would fit well in this situation.

LGTM


"make frameworks" fails for macosx only J2OBJC_ARCHS

the generation of frameworks (not static libraries) fails using the new "make frameworks" option ...
When J2OBJC_ARCHS is set to the default
"J2OBJC_ARCHS = macosx iphone iphone64 iphonev7s simulator simulator64" (in common.mk),
the frameworks are assembled, but only include non- maxosx architectures
if J2OBJC_ARCHS is set to
J2OBJC_ARCHS = macosx
the frameworks are not assembled at all (because presumably the Makefile is looking for the iOS & Simulator static libs.

This may be working as intended since there's no need for a OSX framework. (the OSX build is mainly used for running unit tests) I'll let Tomm comment on this.

Yes, the issue is that 64-bit iOS emulator and OS X archs can't be put in the same fat library, since they're both x86_64. Since j2objc is iOS focused, having separate OS X frameworks wasn't considered.
That said, we wouldn't ignore a pull request to add make support for a separate OS X framework, as long as it doesn't break the iOS build. ;-)


Add test of query scopes in cache key

Fixes #31

Coverage remained the same at 100.0% when pulling 049b5cfa9ab3c7f433c71a1986245664d09f1ccd on laravel-5.5 into 4ed4484e3103feab47aff256a66f3ad0ca8488d9 on master.

Coverage remained the same at 100.0% when pulling 049b5cfa9ab3c7f433c71a1986245664d09f1ccd on laravel-5.5 into 4ed4484e3103feab47aff256a66f3ad0ca8488d9 on master.

Fixes #11

Coverage remained the same at 100.0% when pulling 5b084ce8e74ddaf4fb9a70980f4a802e4625d165 on laravel-5.5 into 4ed4484e3103feab47aff256a66f3ad0ca8488d9 on master.


Add bitcoin-s unit test class, all unit tests going forward should ex…

…tend this
Creates a common test abstract class for bitcoin unit tests. This PR does not go through the code base and extend this abstract class, it just extends it in one called LnInvoiceUnitTest.
One interesting thing about property based testing is that the longer the code lives, the surer you are that it is correct. This PR also introduces the concept of "old code" and "new code". New code should be executed more often in property based tests, while old code can be executed less times.
See this talk by Bill Venners (creator of ScalaTest) for more info on this:
https://youtu.be/lKtg-CDVDsI?t=2293

From first CI job: [info] Coverage is above minimum [90.01% > 90.0%] :sunglasses:
LGTM!


Need to add option java_outer_classname flag for defining the generated java proto file

We need to add option java_outer_classname flag for defining the generated java proto file

with v0.1.7 release by default java-separate-file option is added. this abolish the need of outer class.


[TwigComponent] [LiveComponent] Add support for embedded live components

Q
A

Bug fix?
no

New feature?
yes

Tickets

License
MIT

Context
Using embedded components was introduced in https://github.com/symfony/ux/pull/317, but support for Live embedded components was not added. The issue is that on a re-render of a Live component you lose the blocks defined within an embedded component. This PR solves that issue.
Example
To explain the solution, take this example:
{# someTemplate.html.twig #}
{% component Foo %}
  {% block content %}
    Override content
  {% endblock %}
{% endcomponent %}

{# Foo.html.twig #}
<div {{ attributes }}>
  {% block content %}
    Default content
  {% endblock %}
</div>

Of course, Foo is a Live component.
This obviously also works with the new Twig syntax.
Background

Each {% component %} tag is compiled by ComponentNode.
It adds an embedded Template to the Template class compiled for someTemplate.html.twig. This is a second class inside the same php file, with a suffix in the form of ___%d. That number at the end is normally random, and is called the embedded template index.
ComponentNode would generate Template code which fetches the embeddedContext from the ComponentRenderer and passed that to the loadTemplate('Foo.html.twig', $index)->display()
When a component is re-rendered (via an action callback) it uses the template of the component (Foo.html.twig), which does not have the original block content, because that's part of the host Template (someTemplate.html.twig).

Solution
We only need to use the embedded Template instead of the component Template to re-render a component.
To make this happen, we need to:

Use a deterministic index for an embedded template during compilation.
Store info on the rendered component's HTML (via the attributes) about the host template and the embedded template's index.
Load the embedded Template during re-render using the info passed along with the other attributes/props.

Remaining

I use loadTemplate now in the ComponentRender, which is marked as internal in the Twig package. Can we ignore that within this package (as both are "Symfony")?
The PreRenderEvent::EMBEDDED constant and the isEmbedded function were introduced to block live embedded components. Should this PR remove those as well?

Tasks

[ ] Remove isEmbedded?
[ ] Remove PreRenderEvent::EMBEDDED?
 Everything is green so I'd love to hear your feedback!

Rebased my branch + removed an isChildComponent check in the LiveControllerAttributesCreator so any component gets a live-id (as discussed with @weaverryan).
This is needed now so embedded components also get a live-id, otherwise actions to nested components wouldn't be linked to the embedded component (but some higher non-embedded component).
It used to be that

only non-embedded components would get a live-id, since

only those are rendered via ComponentRenderer::render(),
and only that function uses the ComponentStack,
by which the isChildComponent is determined

while embedded components are rendered via ComponentRenderer::embeddedContext() + Template::display().

Since embedded components couldn't be live, it follows that live components would always have a live-id (since all of them were guaranteed non-embedded and follow flow 1).
Ergo, now we have to add live-ids on embedded (live) components as well.

I noticed that live (now embedded) components would always re-render, unlike non-embedded components which would only re-render if a LiveProp changed that also allowed the parent component to update the child component. If none of those LiveProps changed no re-render would happen as of 2.8.
This is because of the InterceptChildComponentRenderSubscriber acting on the PreCreateForRenderEvent and short-circuiting the render process, returning a fake/incomplete html for a child component. It's the frontend that decides whether the props have changed and whether another callback to the backend is desired.
However, because non-embedded components are rendered via the createAndRender function, while embedded components are rendered via ComponentRenderer::embeddedContext() + loadTemplate(), the latter don't get a chance to be short-circuited, and have their non-updateable properties be removed, resulting in skipping an redundant and perhaps even unwanted re-render.
I added a new commit to take care of this.

I added a change to make embedded components also be part of the component stack, by which it is determined to add a fingerprint.
Previously, I just removed the isChildComponent-check in the LiveControllerAttributesCreator but after discussing this with @weaverryan, who told me it can be CPU-heavy to generate fingerprints, I decided to handle it this way, by also adding embedded components to the component stack. This way at least root components don't get an unnecessary fingerprint.

@kbond @weaverryan can you guys have another look at this PR?

This is highly technical, but WOW! I can't believe you got this working. I played with it locally, and it's a ton of fun. Great work Bart! Now, time for some docs about this - we need to be sure to mention the limitation of "relying" on an outside variable from within the embedded template contents.


Fix unexpected keyword argument for MongoFileField

@mrjoes this fix has been tested on the latest mongoengine v0.24.2, but it shouldn't break earlier versions.


[TIR] Update SplitHostDevice to post-process with ConvertSSA

Prior to this commit, the same tir::Var could be defined both in the body of the host function and in a parameters of the device function.  While this is legal, as TIR only requires SSA across each PrimFunc, this does result in failure to round-trip through TVMScript, because the round-tripped TIR uses a new tir::Var in each instance.  This PR adds a ConvertSSA() transform that can apply to an entire IRModule, in addition to the existing ConvertSSA(Stmt) utility.
This is part of changes described in https://github.com/apache/tvm/pull/14486, to improve round-trip failures that occur in lowering.

@tvm-bot rerun


Publish roslyn API docs from the roslyn wiki

The roslyn wiki has a number of useful resources for developers starting to write analyzers and code fixes. These should move to docs under the .NET Compiler SDK node.
The two most important would be the FAQ. Each code-related question in this FAQ pointed to a sample unit test demonstrating how to solve some problem using Roslyn APIs. The samples have been removed, but still exist in the source history – https://github.com/dotnet/roslyn/blob/version-2.4.0/src/Samples/CSharp/APISampleUnitTests/FAQ.cs (there’s an equivalent FAQ.vb in a parallel location in the source tree).
/cc @jmarolf

These samples now live here: https://github.com/dotnet/roslyn-sdk/blob/master/samples/CSharp/APISamples/FAQ.cs


add readthedocs builds in PR

I think this can be configured in readthedocs. I know xarray has it but I don't think there is any code for it on github. You can only see it on open PRs e.g. bottom of https://github.com/pydata/xarray/pull/5031

Thanks for the suggestion @raybellwaves. We already have a documentation build on PRs to ensure that they can be built successfully. However it looks like the readthedocs builds do this as well as provide a preview of the docs for each PR -- which is really useful. Today maintainers have to checkout a PR locally and then build the docs themselves, so automating this in a CI build would definitely add value.
If there are no objections, I'll plan to play around with adding readthedocs PR builds this afternoon

May be somewhere in here. I forget

the option is in "Advanced Settings"

Thanks for the tips @raybellwaves @keewis. I opened up a PR over in https://github.com/dask/dask/pull/7397 which demonstrates that the readthedocs build is working (🎉 ) and removes our existing GitHub actions doc build


Additional TypeScript tests

#1431

Eager loading
Graph insert
Graph upsert
Transactions
Validation
Documents
Fixes linting errors in koa-ts example
Initial finder methods (where, notWhere, etc)

@koskimas like #1437, I would consider this "mergeable" at any point tests are passing in order to make the PRs a manageable size. I will continue to make PRs this week towards completing #1431

Thank you so much! Good stuff! One thing though: in v2.0 branch the documentation you are copying has significantly changed and a alot of methods have been deprecated. No need to redo anything as most of this is still relevant in 2.0, but consider copying examples from the new docs in the future if you make additional PR's. As ab example, the eager method is deprecated in 2.0 and replaced by withGraphFetched. You can run the new docs using npm run docs:dev and going to localhost:8080


Change in function massFlowRate corrupts existing models without warning or error

Modified by beutlich on 1 Apr 2016 18:40 UTC
Let us report on a major issue we detected using Dymola 2017 with MSL3.2.2
In Modelica 3.2.1 the function Fluid.Pipes.Baseclasses.Wallfriction.Partialwallfriction looks like this:
replaceable partial function massFlowRate_dp
  "Return mass flow rate m_flow as function of pressure loss dp, i.e., m_flow = f(dp), due to wall friction"
  extends Modelica.Icons.Function;

  input SI.Pressure dp "Pressure loss (dp = port_a.p - port_b.p)";
  input SI.Density rho_a "Density at port_a";
  input SI.Density rho_b "Density at port_b";
  input SI.DynamicViscosity mu_a
    "Dynamic viscosity at port_a (dummy if use_mu = false)";
  input SI.DynamicViscosity mu_b
    "Dynamic viscosity at port_b (dummy if use_mu = false)";
  input SI.Length length "Length of pipe";
  input SI.Diameter diameter "Inner (hydraulic) diameter of pipe";
  input SI.Length roughness(min=0) = 2.5e-5
    "Absolute roughness of pipe, with a default for a smooth steel pipe (dummy if use_roughness = false)";
  input SI.AbsolutePressure dp_small = 1
    "Regularization of zero flow if |dp| < dp_small (dummy if use_dp_small = false)";
  input SI.ReynoldsNumber Re_turbulent = 4000
    "Turbulent flow if Re >= Re_turbulent (dummy if use_Re_turbulent = false)";
  output SI.MassFlowRate m_flow "Mass flow rate from port_a to port_b";
annotation (Documentation(info="<html>
</html>"));
end massFlowRate_dp;

In Modelica 3.2.2 the function Fluid.Pipes.Baseclasses.Wallfriction.Partialwallfriction looks like this:
replaceable partial function massFlowRate_dp
  "Return mass flow rate m_flow as function of pressure loss dp, i.e., m_flow = f(dp), due to wall friction"
  extends Modelica.Icons.Function;

  input SI.Pressure dp "Pressure loss (dp = port_a.p - port_b.p)";
  input SI.Density rho_a "Density at port_a";
  input SI.Density rho_b "Density at port_b";
  input SI.DynamicViscosity mu_a
    "Dynamic viscosity at port_a (dummy if use_mu = false)";
  input SI.DynamicViscosity mu_b
    "Dynamic viscosity at port_b (dummy if use_mu = false)";
  input SI.Length length "Length of pipe";
  input SI.Diameter diameter "Inner (hydraulic) diameter of pipe";
  input SI.Area crossArea = pi*diameter^2/4 "Inner cross section area";
  input SI.Length roughness(min=0) = 2.5e-5
    "Absolute roughness of pipe, with a default for a smooth steel pipe (dummy if use_roughness = false)";
  input SI.AbsolutePressure dp_small = 1
    "Regularization of zero flow if |dp| < dp_small (dummy if use_dp_small = false)";
  input SI.ReynoldsNumber Re_turbulent = 4000
    "Turbulent flow if Re >= Re_turbulent (dummy if use_Re_turbulent = false)";
  output SI.MassFlowRate m_flow "Mass flow rate from port_a to port_b";
annotation (Documentation(info="<html>
</html>"));
end massFlowRate_dp;

The difference: between diameter and roughness a parameter “crossArea” has been introduced. A typical call of this function looked like this in older models:
   m_flow[i] = Modelica.Fluid.Pipes.BaseClasses.WallFriction.Detailed.massFlowRate_dp(dp[i], medium[i-1].d, medium[i].d,
   AirMedium.dynamicViscosity(medium[i-1].state), AirMedium.dynamicViscosity(medium[i].state), cellLength, diameter, roughness, 0.01);

If this is run with Modelica 3.2.2, the roughness-value is used as crossArea, resulting in a very small calculated mass flow.
In this way existing models are corrupted using Dymola 2017 and MSL3.2.2
Possible corrections:

put the new parameter at the end, to simply avoid this issue.

or

enforce a better conversion script (i have doubts that this is possible)

or

use a new function name so that at least this does not happen unnoticed.

As it is right now, it is quite dangerous since it first happens unnoticed. This issue should be corrected asap.

Reported by dzimmer on 1 Apr 2016 14:24 UTC
Let us report on a major issue we detected using Dymola 2017 with MSL3.2.2
In Modelica 3.2.1 the function Fluid.Pipes.Baseclasses.Wallfriction.Partialwallfriction looks like this:
replaceable partial function massFlowRate_dp
  "Return mass flow rate m_flow as function of pressure loss dp, i.e., m_flow = f(dp), due to wall friction"
  extends Modelica.Icons.Function;

  input SI.Pressure dp "Pressure loss (dp = port_a.p - port_b.p)";
  input SI.Density rho_a "Density at port_a";
  input SI.Density rho_b "Density at port_b";
  input SI.DynamicViscosity mu_a
    "Dynamic viscosity at port_a (dummy if use_mu = false)";
  input SI.DynamicViscosity mu_b
    "Dynamic viscosity at port_b (dummy if use_mu = false)";
  input SI.Length length "Length of pipe";
  input SI.Diameter diameter "Inner (hydraulic) diameter of pipe";
  input SI.Length roughness(min=0) = 2.5e-5
    "Absolute roughness of pipe, with a default for a smooth steel pipe (dummy if use_roughness = false)";
  input SI.AbsolutePressure dp_small = 1
    "Regularization of zero flow if |dp| < dp_small (dummy if use_dp_small = false)";
  input SI.ReynoldsNumber Re_turbulent = 4000
    "Turbulent flow if Re >= Re_turbulent (dummy if use_Re_turbulent = false)";
  output SI.MassFlowRate m_flow "Mass flow rate from port_a to port_b";
annotation (Documentation(info="<html>
</html>"));
end massFlowRate_dp;

In Modelica 3.2.2 the function Fluid.Pipes.Baseclasses.Wallfriction.Partialwallfriction looks like this:
replaceable partial function massFlowRate_dp
  "Return mass flow rate m_flow as function of pressure loss dp, i.e., m_flow = f(dp), due to wall friction"
  extends Modelica.Icons.Function;

  input SI.Pressure dp "Pressure loss (dp = port_a.p - port_b.p)";
  input SI.Density rho_a "Density at port_a";
  input SI.Density rho_b "Density at port_b";
  input SI.DynamicViscosity mu_a
    "Dynamic viscosity at port_a (dummy if use_mu = false)";
  input SI.DynamicViscosity mu_b
    "Dynamic viscosity at port_b (dummy if use_mu = false)";
  input SI.Length length "Length of pipe";
  input SI.Diameter diameter "Inner (hydraulic) diameter of pipe";
  input SI.Area crossArea = pi*diameter^2/4 "Inner cross section area";
  input SI.Length roughness(min=0) = 2.5e-5
    "Absolute roughness of pipe, with a default for a smooth steel pipe (dummy if use_roughness = false)";
  input SI.AbsolutePressure dp_small = 1
    "Regularization of zero flow if |dp| < dp_small (dummy if use_dp_small = false)";
  input SI.ReynoldsNumber Re_turbulent = 4000
    "Turbulent flow if Re >= Re_turbulent (dummy if use_Re_turbulent = false)";
  output SI.MassFlowRate m_flow "Mass flow rate from port_a to port_b";
annotation (Documentation(info="<html>
</html>"));
end massFlowRate_dp;

The difference: between diameter and roughness a parameter “crossArea” has been introduced. A typical call of this function looked like this in older models:
   m_flow[i] = Modelica.Fluid.Pipes.BaseClasses.WallFriction.Detailed.massFlowRate_dp(dp[i], medium[i-1].d, medium[i].d,
   AirMedium.dynamicViscosity(medium[i-1].state), AirMedium.dynamicViscosity(medium[i].state), cellLength, diameter, roughness, 0.01);

If this is run with Modelica 3.2.2, the roughness-value is used as crossArea, resulting in a very small calculated mass flow.
In this way existing models are corrupted using Dymola 2017 and MSL3.2.2
Possible corrections:

put the new parameter at the end, to simply avoid this issue.

or

enforce a better conversion script (i have doubts that this is possible)

or

use a new function name so that at least this does not happen unnoticed.

As it is right now, it is quite dangerous since it first happens unnoticed. This issue should be corrected asap.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1973

Comment by beutlich on 1 Apr 2016 18:40 UTC
See also #1656.
Visual diff:
--- "a/msl321.mo"
+++ "b/msl322.mo"
@@ -11,6 +11,7 @@ replaceable partial function massFlowRate_dp
     "Dynamic viscosity at port_b (dummy if use_mu = false)";
   input SI.Length length "Length of pipe";
   input SI.Diameter diameter "Inner (hydraulic) diameter of pipe";
+  input SI.Area crossArea = pi*diameter^2/4 "Inner cross section area";
   input SI.Length roughness(min=0) = 2.5e-5
     "Absolute roughness of pipe, with a default for a smooth steel pipe (dummy if use_roughness = false)";
   input SI.AbsolutePressure dp_small = 1

Comment by dietmarw on 1 Apr 2016 21:31 UTC
I looked into the history of this backwards compatibility breaking change and it turns out it was introduced before MSL3.2.1+build.3. First in 29a67410d01a196bb2671f3ef4ede06b581ade48 as part of #1601 and then later improved as part of #1656. So this means currently the following versions are all broken:

MSL 3.2.1+build.3 released
MSL 3.2.1+build.4 released
MSL 3.2.2+build.2-rc.3 being voted on

Now when looking at #1656 it seems like that @rfranke was aware that there was a non-backward compatible change introduced and this on purpose. Only it was never proper mentioned in the release notes.
So if this non-backward change should be kept then I would suggest fixing the release notes of all those versions stating clearly that it is not really a backward compatible change. This would be a documentation fix only.
If however that should be rolled back then we need at least a 3.2.2+build.3-rc.4 and need to decide later on a 3.2.1+build.5 (we might want to have this anyway).
In addition this shows that we are missing a test model for that function. That should be added as soon as possible.

Comment by dietmarw on 1 Apr 2016 21:38 UTC
I forgot. Of course instead of a roll-back we could fix this like Dirk suggested in this ticket. This at least would mean we have practically only one broken MSL that was shipped with a tool (MSL3.2.1+build.4 if I'm not mistaken).

Comment by otter on 1 Apr 2016 23:37 UTC
Documented the non-backwards compatible change introduced in version 3.2.1 Build.3 in the release notes with deb769161b7828baeb4c2f4b446b6a11538e8451.
Version 3.2.1 Build.4 is already used in Dymola 2016 FD01 and in OpenModelica.
I do not see a possibility to fix this issue in a reasonable way. The suggestions from Dirk all have drawbacks:

put the new parameter at the end, to simply avoid this issue. -> Models generated with 3.2.1 Build.3 or later will give wrong results.

enforce a better conversion script (i have doubts that this is possible) -> conversion scripts can only be provided for a particular version number, but not for a particular build number.

use a new function name so that at least this does not happen unnoticed. -> Every fluid model using a pipe model and build with 3.2.1 Build.4 will fail, and the user does not know how to fix this.

After inspecting the code, I wonder how this non-backwards compatible change can give wrong results: These functions are used as building blocks for replaceable packages that are used in the Pipe models to provide different characteristics for wall friction. The functions are hidden in the Pipe models and not directly used by any model in MSL (with exception of the test model Modelica.Fluid.Pipes.BaseClasses.WallFriction.TestWallFrictionAndGravity that was adapted to the argument change).
Note, there are plenty of test models in Modelica and ModelicaTest where pipe models are used. However, since these functions are never directly called, the test models are still corect. So, this issue cannot be detected by testing.
So, the only way to get a wrong result is by building an own pipe model and using the WallFriction functions.
Probably, proposal (3) is then applicable, so changing the function names (there are 4 functions with this non-backwards compatible change). This will not influence a user that is just using the MSL Pipe models, but will give an error for a user that builds his/her own Pipe models and uses positional function call syntax.

Comment by beutlich on 2 Apr 2016 05:47 UTC
I guess only rfranke can answer if the breaking change was introduced by accident or by purpose.

Comment by rfranke on 2 Apr 2016 12:55 UTC
This change was not by accident but intended. The old implementation did only work for circular pipes, even though non-circular pipes can be configured (#1601). Backwards compatibility was improved in #1656. If someone directly uses these base functions with positional arguments for inputs that have default values, then the compilation error actually helps to reconsider if the model at hand is affected by bug #1601.

Comment by rfranke on 2 Apr 2016 17:58 UTC
I updated the documentation in be54d33ea98d18db935bec2462129285dd2e180f.
Is title of this ticket correct "without warning or error"?
Note that the arguments have different physical units m vs. m2!

Comment by otter on 3 Apr 2016 09:19 UTC
I made now a more thorough analysis of the issue, the potential consequences and evaluated this with the attached test package "TestIssue1973":
In version 3.2.1 Build.2 the wall friction model gave wrong results for non-circular pipes (without any message, and even if the user recognizes it, he/she could not correct it). This was fixed by introducing an additional argument crossArea (with a default crossArea for circular pipes) in functions
Modelica.Fluid.Pipes.BaseClasses.WallFriction.PartialWallFriction.
    massFlowRate_dp
    massFlowRate_dp_staticHead
    pressureLoss_m_flow
    pressureLoss_m_flow_staticHead

The modified DynamicPipe model still gives wrong results, if the new DynamicPipe parameter isCircular is not set to false for a non-circular pipe. However, a user can now set the crossArea for non-circular pipes and can therefore correctly simulate non-circular pipes (which was not possible beforehand).
This bug fix introduced a non-backwards compatible change because a new argument was introduced in the "middle" of the arguments lists of the 4 functions above (with a default value calculated for a circular pipe). This bug fix should have introduced the new argument crossArea at the end of the argument list in order to be fully backwards compatible.
The above change is present in 3.2.1 Build.3, 3.2.1 Build.4, and in 3.2.2 Build.x. 3.2.1 Build.4 is already shipped at least in Dymola 2016 FD01 and in OpenModelica. Since there has been a request to fix the bug for non-circular pipes, it is highly likely that the new feature with the crossArea is already actively used.
From the code review of the library (and evaluated with the test package below), this change has the following consequences on users that generated a corresponding model with MSL 3.2.1 Build.2 and used it with MSl 3.2.1 Build.3 or later:

If one of the pipe models in Modelica.Fluid.Pipes is used, then everything is fine and no issue occurs, because redeclarations of a WallFriction model requires named arguments (since a modifier), and with a modifier the (correct) default value of the crossArea is automatically used (and in the pipe models the correct function calls are made depending on the used MSL version).

If a user implements his/her own pipe model, he/she has to call one or more of the 4 functions above and if these functions are called with positional arguments, an error is present, because the new argument crossArea is present. All arguments after crossArea have a different unit as crossArea has. Therefore, tools that check units, will report this issue.

I tested the above statements with the attached test package TestIssue1973 in the following way:

TestIssue1973.TestFluid1 was generated with MSL 3.2.1 Build.2 (Dymola 2015 FD01) and uses several pipe models where for some pipe models the roughness was changed from the default value of 1e-5 to 1e-9 (the roughess argument is in the argument list after the crossArea argument).

TestIssue1973.TestFluid1 was also simulated with Dymola 2017 Beta.2 (using MSL 3.2.2 Build.3). No error was reported and the results (stateFM[..]) are identical.

TestIssue1973.TestFluid2 was generated with MSL 3.2.1 Build.2 (Dymola 2015 FD01) and uses the demo pipe model TestIssue1973.TestWallFrictionAndGravity (a copy of Modelica.Fluid.Pipes.BaseClasses.WallFriction.TestWallFrictionAndGravity that does not have a crossArea argument).

TestIssue1973.TestFluid2 was also simulated with Dymola 2017 Beta.2 (using MSL 3.2.2 Build.3). A unit error was reported when using the "pedantic" flag set to true, and a unit warning was reported when not using the pedantic flag. If the warning is ignored, Dymola produced a simulation result which is wrong (pipeFriction.V_flow is different in Dymola 2015 FD01 as compared with Dymola 2017 Beta.2).

The question is what do to now. I see the following possibilities (note, in all cases users are not affected that just use the MSL pipe models):

Keep 3.2.2 as it is now (with the documentation of this issue in the release notes). The consequence is that if users have build their own pipe models and ignore warnings of the tool with these non-MSL pipe models, then the simulation result will be wrong (but they will get an error, if unit errors stop translation).

Rename the WallFriction functions in 3.2.2. The consequence is that every user that has build his/her own pipe model with MSl 3.2.1 Build.2, utilizes it in models and uses these models with MSL 3.2.2 will get an error and has to change the function name and then hopefully regocnices that he/she also has to adapt the function argument list. In case he/she does not recognize that a new argument has been added, the same issue as in (1) will still occur. (Note: If someone made a new pipe model and utilized named arguments for the function calls, his/her model is fine, and yet an error will occur).

Move the crossArea argument to the end of the argument lists in 3.2.2 Build.4. The consequence is that every user that has build his/her own pipe model with MSl 3.2.1 Build.3, MSL 3.2.1 Build.4, MSL 3.2.2 Build.3 using function calls with positional arguments and uses a model with this pipe model with MSL 3.2.2 Build.4 or later will get a unit error or warning. If the warning is ignored, the simulation results will be wrong.

My Conclusion is to use variant 1 (keep MSL 3.2.2 as it is now with the improved release notes), because

in all 3 variants there are scenarios where the user can get wrong simulation results (when ignoring warning messages from the tool),
a "usual" user is not affected by this change (in any of the variants), because he/she will use the pipe model from MSL.
Regression testing of MSL 3.2.1 Build.3, Build.4, MSL 3.2.2 Build.2/.3 have been made with respect to many Modelica libraries, including many fluid libraries. If in these libraries the above issue would be present, there would have been regression errors.

Comment by rfranke on 3 Apr 2016 10:47 UTC
Just tried TestIssue1973.TestFluid2 with Dymola 2015FD01 that shipped with MSL3.2.1 build2. When manually loading a newer build of MSL3.2.1 or the trunk version (i.e. MSL3.2.2), this gives the warning:
Incompatible units in
pressureLoss_m_flow_Unique10(pipeFriction.m_flow_nominal, pipeFriction.rho_nominal, pipeFriction.rho_nominal, pipeFriction.mu_nominal, pipeFriction.mu_nominal, pipeFriction.length, pipeFriction.diameter, pipeFriction.roughness, pipeFriction.m_flow_small, 0.01, 4000)

The part
crossArea
has unit m2

The part
pipeFriction.roughness
has unit m

The unit issue reported appeared in the binding equation of the variable
pipeFriction.dp_fric_nominal

As said: if you directly call these detailed pressure loss functions, then it is worth being noted about #1601, in order to reconsider if your pipe is circular.

Comment by otter on 3 Apr 2016 18:16 UTC
The MA board has discussed this and there is agreement to use variant 1. The release notes have been further improved to make this very clear:
In version 3.2.1 Build.3 a new argument crossArea was introduced in the functions of Modelica.Fluid.Pipes.BaseClasses.WallFriction.PartialWallFriction to fix a subtle bug for the calculation of pipe friction for non-circular pipes, see #1601 and #1656. If a user utilized a pipe model of Modelica.Fluid.Pipes, this does not matter because the pipe models have been improved in a fully backwards compatible way. However, if the user constructed an own pipe model based on the partial package PartialWallFriction and calls the functions defined in PartialWallFriction with positional (and not named) arguments, then a unit warning or error will occur (depending on the tool and tool-specific settings) because the new argument crossArea has unit ![m2] and the previous argument at this place, roughness, has unit [m]. If the warning is ignored, the simulation result will be wrong, because the crossArea is used as roughness. The user needs to fix this by adapting his/her pipe model so that the crossArea is used in the function calls, or by using named function arguments.

Comment by fcasella on 3 Apr 2016 21:24 UTC
Fine for me

Comment by dietmarw on 3 Apr 2016 22:11 UTC
So is there a way to get a testmodel for the function in ModelicaTest so that future changes might at least trigger some warning/errors?

Comment by rfranke on 4 Apr 2016 03:05 UTC
There is:
ModelicaTest.Fluid.TestComponents.Fittings.TestWallFriction
which uses:
Modelica.Fluid.Pipes.BaseClasses.WallFriction.TestWallFrictionAndGravity
The latter was adapted along with the fix.

Comment by rfranke on 4 Apr 2016 07:35 UTC
@dzimmer: after having caused so much trouble right before the release of MSL 3.2.2, can you please answer the two open questions:

Do you really don't get a warning, i.e. does you model use physical units?

Do you model a circular pipe or possibly a non-circular air duct?

Comment by dietmarw on 4 Apr 2016 08:15 UTC
@rfranke Could you please open a new ticket since it is crucial that his ticket stays within the 3.2.2 milestone for documentation.
In general I find the "solution" as decided by the board (not MAP-LIB project mind) worrying.
The function that got changed in the non-backward compatible way has been present in the MSL since v3.1 (14th August 2009). So this means for around 6 years. Whereas the newly fixed version with the non-backward compatible change for about 6 month. So the likelihood that users will have the old version in their models is far higher than the new implementation. So fixing the mistake and appending the argument like in the proposed variant 3, would impact far less potential users than keeping the bug in the MSL as it is now.
So I really don't understand from a user's point of view how this issue has been fixed in the best possible way impacting the least users.

Comment by rfranke on 4 Apr 2016 08:33 UTC
Ticket #1601 was closed 15 months ago, after the crossArea argument had been introduced. The leading 1 reduces the likelihood of people being affected now by a factor of 2.5.
Please keep in mind: the crossArea argument is not an extension, which should have been added at the end of the list. It fixes a severe bug. It is considered an advantage if people directly using this base function get notified by the tool.

Comment by dzimmer on 4 Apr 2016 08:44 UTC
Sorry for causing the trouble...
To clarify:
We have used pyhsical units (all nice and proper SI units) and got no warning in Dymola whatsoever. We jsut confirmed that once more in order to be sure.
I may also add that industrial clients of us NEVER read the release notes of the MSL. For them it is just a new Dymola version and things suddenly stop working.

Comment by rfranke on 4 Apr 2016 08:50 UTC
The attached model TestIssue1973.mo generates a warning with default settings of Dymola 2015FD01, see comment:9. What is different in your case?
If people don't read the release notes, then it is even more important that the tool issues a warning or error for the model at hand.

Comment by dietmarw on 4 Apr 2016 08:52 UTC
Replying to [comment:16 rfranke]:

Ticket #1601 was closed 15 months ago, after the crossArea argument had been introduced. The leading 1 reduces the likelihood of people being affected now by a factor of 2.5.

I'm only discussing the time line of actual released MSL versions. So in this case 3.2.1 build.4 (build.3 was never really released since some severe issues were found).

Comment by otter on 4 Apr 2016 11:26 UTC
I am closing this ticket for the documentation of the MSL 3.2.2 release. Please, continue discussion in the new ticket #1974 (with milestone Design90)

Comment by beutlich on 4 Apr 2016 12:20 UTC
OK, I can regenerate the ResolvedTracTickets.html now. @otter: can you please fill the release notes field of this ticket. Thanks.

Comment by hubertus on 4 Apr 2016 12:23 UTC
Replying to [comment:15 dietmarw]:

The function that got changed in the non-backward compatible way has been present in the MSL since v3.1 (14th August 2009). So this means for around 6 years. Whereas the newly fixed version with the non-backward compatible change for about 6 month. So the likelihood that users will have the old version in their models is far higher than the new implementation. So fixing the mistake and appending the argument like in the proposed variant 3, would impact far less potential users than keeping the bug in the MSL as it is now.
So I really don't understand from a user's point of view how this issue has been fixed in the best possible way impacting the least users.

Dietmar, I agree with your argument about the number of affected users, based on 6 years vs. 6 months, so I think we should fix the issue as suggested in the ticket by changing the argument order. But I'd like to separate 2 issues here:

Our release process for a new release which is quite slow and
the proper fixing of a bug that is discovered.

We have plenty of other, unknown bugs in MSL, there will be more that are going to be discovered soon.
It would be great if we have a reasonably simple and swift process to fix such bugs, add them to a released version with a new build number, and make it easy for vendors to pick up an official MSL version that includes the fix. Sort of like continuous integration, but for bug fixes only. This should be discussed in map-lib.

Comment by otter on 4 Apr 2016 13:01 UTC
Replying to [comment:22 hubertus]:

Replying to [comment:15 dietmarw]:

The function that got changed in the non-backward compatible way has been present in the MSL since v3.1 (14th August 2009). So this means for around 6 years. Whereas the newly fixed version with the non-backward compatible change for about 6 month. So the likelihood that users will have the old version in their models is far higher than the new implementation. So fixing the mistake and appending the argument like in the proposed variant 3, would impact far less potential users than keeping the bug in the MSL as it is now.
So I really don't understand from a user's point of view how this issue has been fixed in the best possible way impacting the least users.

The argument was not to fix this in a way that impacts the least users, because it is impossible to judge this:
The user can only get a problem if he/she constructed his/her own pipe model. An industrial user will not do this. So, in nearly all cases, someone else has done this, in most cases it will be a Fluid library developer. However, all important Fluid libraries have been tested against MSL 3.2.1 Build.3, Build.4 and MSL 3.2.2. So the likelyhood that this gives an issue with these libraries is low. The only remaining cases are developments particularly performed for an industrial customer that have not been used for testing against new MSL releases. In case of DLR (that has reported this issue) this is also not critical, because the issue is known now and how to fix it. The industrial customer will just get a new library version and he will be told to use this new library version.
On the other hand, the request for the bug fix #1601 came from a user that detected that the MSL pipe models cannot be correct for non-circular pipes. The likelyhood is large that this user is already using MSL 3.2.1 Build.4 in order to be able to simulate non-circular pipes (and potentially more users working with non-circular pipes). If this user gets now MSL 3.2.2 that is not backwards compatible to MSL 3.2.1 Build.4, he/she will get trouble again.
Coming back to the start of the discussion: The argument was that any solution will lead to a scenario where some users are potentially unhappy. Having now a strategy:

MSL 3.2.1 Build.4 is not backwards compatible to the previous release MSL 3.2.1 Build.2 (and gives trouble for some users).
MSL 3.2.2 is not backwards compatbible to the previous release MSL 3.2.1 Build.4  (and gives trouble for some users).

looks not good at all, and it seems better to have a non-backwards compatible change only once.
Anyway, MSL 3.2.2 is released and we should continue the discussion in #1974.

Comment by hubertus on 4 Apr 2016 13:35 UTC
I don't htink it is impossible to evaluate how many users are affected, but it is of course an estimate and best guess. We can check what version of what tool used which version of MSL, and make an educated guess. Given how slow commercial users update to the latest version, a change 6 months ago certainly has not propagated a lot.

Comment by beutlich on 4 Apr 2016 14:59 UTC
Replying to [comment:21 beutlich]:

@otter: can you please fill the release notes field of this ticket. Thanks.

Reminder.

Modified by otter on 4 Apr 2016 15:07 UTC

Changelog modified by otter on 4 Apr 2016 15:07 UTC
Documented the potentially non-backards compatible change in the functions of PartialWallFriction in MSL 3.2.1+Build.3 due to a bug fix regarding non-circular pipes (can be releveant if wall friction functions are directly called, e.g., by pipe models constructed by the user)

Comment by beutlich on 4 Apr 2016 15:17 UTC
Replying to [comment:23 otter]:

Anyway, MSL 3.2.2 is released and we should continue the discussion in #1974.

What do you mean exactly by "released"? Do you mean finalized instead of? Otherwise can we spread the news on modelica.org, twitter etc., let library providers update their libs and finally make a release party?

Comment by mwetter on 4 Apr 2016 15:23 UTC
Replying to [comment:10 otter]:

The MA board has discussed this and there is agreement to use variant 1. The release notes have been further improved to make this very clear:
In version 3.2.1 Build.3 a new argument crossArea was introduced in the functions of Modelica.Fluid.Pipes.BaseClasses.WallFriction.PartialWallFriction to fix a subtle bug for the calculation of pipe friction for non-circular pipes, see #1601 and #1656. If a user utilized a pipe model of Modelica.Fluid.Pipes, this does not matter because the pipe models have been improved in a fully backwards compatible way. However, if the user constructed an own pipe model based on the partial package PartialWallFriction and calls the functions defined in PartialWallFriction with positional (and not named) arguments, then a unit warning or error will occur (depending on the tool and tool-specific settings) because the new argument crossArea has unit ![m2] and the previous argument at this place, roughness, has unit [m]. If the warning is ignored, the simulation result will be wrong, because the crossArea is used as roughness. The user needs to fix this by adapting his/her pipe model so that the crossArea is used in the function calls, or by using named function arguments.

I am fine with this change.

Comment by beutlich on 5 Apr 2016 08:15 UTC
Replying to [comment:20 otter]:

I am closing this ticket for the documentation of the MSL 3.2.2 release.

The documentation was updated by 54cedcfe056668f9edb484c4a006e6ff8ee77686 (trunk) and f1903445bdad3346b131a46648b581cadb884d0a (maint. 3.2.2).


Contributing with a windows environment

Hi,
Few points to enhance to be able to have some contibutor with windows environment :)

[ ] package.json

[ ] setting environment variables (may be we should use cross-env as you suggested)
[ ] "prettier": "prettier '**/*.{js,json}' --write" should become "prettier": "prettier \"**/*.{js,json}\" --write" but I don't know if it's working on other os than windows

[ ] Tests (5 are failing)

[ ] path.join issue: a\\test.json and a/test.json in snapshots

This issue is more like a reminder :)

If anyone runs Windows regularly and would like to contribute, please go ahead!


Profile module

Implements https://github.com/Element-Research/dpnn/issues/80
I've used this a few times now while debugging, and it's been fairly useful. It adds some overhead though, since it needs to reset and time on every forwards/backwards iteration, and it's also a little weird to use inside cloned modules (since every clone gets its own timer).
If this seems like it'll be too hard for others to use, I'm okay if this doesn't merge. Or I can make changes if you think there's a better way of doing this.
@nicholas-leonard

@juesato Thanks. This is great.


system: reflink: use lazy logging

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (7e07012) 64.26% compared to head (b4b58a2) 63.22%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #232      +/-   ##
==========================================
- Coverage   64.26%   63.22%   -1.05%
==========================================
  Files          26       26
  Lines        2012     2012
  Branches      319      319
==========================================
- Hits         1293     1272      -21
- Misses        659      681      +22
+ Partials       60       59       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


ACTH system URL

Hi,
In Wallonia they want to also use ACTH for the 'observation.code'. This would be used for codes that are not in LOINC or ALBERT. This does not seem to contradict the guidance. What does the WG think?
If we decide to use this code set, what system URL should we use? I propose:
https://www.ehealth.fgov.be/standards/fhir/CodeSystem/acth
Best,
Thibault

Discussed during HL7 Belgium FHIR meeting.
Currenlty : the LIS solutions are able to export the LocalCode + alternative CODE (typically in this case LOINC)
Allowing the export an other alternative code ALBERT
or even a 3th alternative code ACTH is not supported by the LIS solutions.
A complex setup and extra development will be required to support this

The WG decides that the ACTH code can be used according to the rules described in the guidance. The url will not be part of the standard.


CASMNET-1412 - Add ExternalDNS A record changes and PowerDNS deprecation notice in 1.2 release notes

Summary and Scope
Restructure PowerDNS documentation and document bifurcated CAN URL moves that are not backwards compatible in the CSM 1.2 release notes.
Issues and Related PRs

Resolves CASMNET-1412
Change will also be needed in main and release/1.2.5

Risks and Mitigations
Pull Request Checklist

[ ] Version number(s) incremented, if applicable
[ ] Copyrights updated
[ ] License file intact
[ ] Target branch correct
[ ] CHANGELOG.md updated
[ ] Testing is appropriate and complete, if applicable
[ ] HPC Product Announcement prepared, if applicable

Note that this PR is now against the new main branch (which began its life as release/1.2). Ideally you should rebase, and then cherry-pick the commit into the older release branches (release/1.2 and 1.2.5).


feat(ha_nexus): adding support to handle switchover request asynchronously

This PR adds support to create worker tasks to process switchover requests parallely.
Signed-off-by: Abhilash Shetty<EMAIL_ADDRESS>

bors try

bors merge


Allow psr/cache ^1.0 || ^2.0 || ^3.0

Question
Answer

Bug fix?
no

New feature?
no

BC breaks?
no

Deprecations?
no

Tests pass?
yes

Fixed tickets
n/a

License
MIT

Doc PR
n/a

Description
This PR updates packages to expand the range of supported versions for the psr/cache dependency to ^1.0 || ^2.0 || ^3.0.
Would you like me to update the CHANGELOGs for this PR? Happy to do so, but wasn't sure if that was appropriate for a non-release PR. Not sure of your process.
Note: Status check appears to be failing for unrelated reasons, as other PRs are affected as well.
TODO

[ ] Add tests
[ ] Add documentation
[ ] Updated Changelog.md

Simple cache has the signatures.


Crystal 0.34 compatibility.

WIP.  Specs pass but a real program doesn't compile.

How would you like to handle conflicts with System::User/Group and Crystal's?

Did they FINALLY add something? I am a little afraid to look...

Yes.  It's a class instead of struct.
home vs home_directory.
name and username clash.  Crystal uses name for the gecos field.
Maybe keep uid/gid and let crystal have it's own String` id methods?
  # The user's username.
  getter username : String

  # The user's identifier.
  getter id : String

  # The user's primary group identifier.
  getter group_id : String

  # The user's real or full name.
  getter name : String

  # The user's home directory.
  getter home_directory : String

  # The user's login shell.
  getter shell : String

My suggestion:

Remove or alias home.
There's little that can be done with username vs name.  I'd say do it crystal's way and provide a warning somewhere.
Keep the uid/gid methods.

Thank you for adding me as a collaborator.  I know it can be frustrating having all your work thrown out.
If you have feedback to avoid breaking your code I'm all ears.
If I don't hear from I'll:

Assume you have better things which I hope are less stressful.
Use the plan above and attempt to minimize compatibility problems.
Wait a while.
Bump the major version number for the next release with a warning in README.md.

Your proposal sounds fine. I would err on the side of aliasing so that existing code doesn't break (Does crystal have an attribute to mark something as deprecated?).
Feel free to email me (in my profile). I tend to prefer private communication and I regularly check it.

Your proposal sounds fine. I would err on the side of aliasing so that existing code doesn't break (Does crystal have an attribute to mark something as deprecated?).

Yes.  Deprecated aliasing will be used for home and anything else not kept.
name and username clash. Crystal uses name for the gecos field.  This shard uses it for the username.  Deprecation can't solve this issue.  I think they only way forward is release a new version letting crystal manage name, bump the major version and hope it doesn't cause conflicts in anyones code.


[5.9] Observable protocol non-marker, @Observable class only

This cherry-picks #66993 and #67033 to the 5.9 branch.

@swift-ci Please test

@swift-ci Please test


add CI

@homunkulus r+

:pushpin: Commit ae0b5c7 has been approved by japaric

:hourglass: Testing commit ae0b5c7 with merge ae0b5c7...

@homunkulus r+

:pushpin: Commit 99d3a83 has been approved by japaric

:hourglass: Testing commit 99d3a83 with merge 99d3a83...

@homunkulus r+

:pushpin: Commit 4ddd560 has been approved by japaric

:hourglass: Testing commit 4ddd560 with merge 4ddd560...

@homunkulus r+

:pushpin: Commit a1e1031 has been approved by japaric

:hourglass: Testing commit a1e1031 with merge a1e1031...

:sunny: Test successful - status-travis
Approved by: japaric
Pushing a1e10312874fd59326e1a72b95aa77af4a4060aa to master...


⚠ Bofrost.lu has degraded performance

In 8b26083, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1739 ms

Resolved: Bofrost.lu performance has improved in 371b9fb after 6 minutes.


Metrics Tabs: Display only message instead of full stacktrace

As user I want to see only 'message' when testcase got failed instead of full-stacktrace. This helps me in grouping or exporting failures to report
Note: To view full stack-trace I will go through index.html from 'TestNG Log' tab

Fixed in this commit - 26398465c76d6af2dbb92be53c1bcc2cc764d3b4


Add a '--cache' flag to virtctl for controlling disk cache mode

Signed-off-by: crazytaxii<EMAIL_ADDRESS>What this PR does / why we need it:
Providing an option for controlling disk cache mode when using virtctl addvolume command to hotplug disk.
How to use: virtctl addvolume --cache=writeback
Release note:
Add a '--cache' flag to virtctl for controlling disk cache mode

/ok-to-test

/cc @awels @mhenriks

You'll need to add unit tests to check this PR does what you expect it to.
I think the correct place is in the corresponding virtctl pkg.

How should I write the unit test? serialArg flag doesn't have such one in pkg/virtctl/vm/vm_test.go.

I would be most interested in a functional test to ensure that the flag is actually passed to the disk when hotplugged into the VM.

/retest

Looks good. I missed a test verifying this change. Can we add one?

I have added one in tests/storage.

/approve

/lgtm


[dpdk] Update to v22.07

Describe the pull request

What does your PR fix?
Update DPDK to v22.07

Which triplets are supported/not supported? Have you updated the CI baseline?
No

Does your PR follow the maintainer guide?

Yes

Also removed the "libarchive" dependency for the "tests" feature because it is already defined in the main dependency of this port.

Thanks!


Some Examples are broken on Mobile WebGL

Bevy version
I'm not sure, its whatever version of bevy the web examples are using at the time of writing this, if it tracks release then bevy 0.7
Operating system & version
S22 Ultra, Android 12
What you did

Open Chrome or FireFox on Android
Navigate to https://bevyengine.org/examples/3d/lighting/ or https://bevyengine.org/examples/3d/spherical-area-lights/
Wait for the scene to load

What you expected to happen
The example scene renders without artifacts
What actually happened
the scene rendered with artifacts
Additional information
Any additional information you would like to add such as screenshots, logs, etc.

Looks like a bug with clustered forward rendering. Perhaps the cluster index calculation breaks for some reason and then the cluster is shaded with the wrong light list.

i have the same issue on arch linux using amd juniper

Looks like some shader issues, using USB debugging, this is the error I'm getting:
lighting.js:397 panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `pbr_opaque_mesh_pipeline`
    Internal error in VERTEX | FRAGMENT | VERTEX_FRAGMENT shader: Assertion failed: false && "Unknown named pointer type or missing metadata"

Update: The Bevy 0.11 WASM examples are currently working fine on my old Pixel 3 Android.

Sadly, the lighting example for me is still broken.


Quotes in saved graphs are expanded to HTML entities, which results in invalid query syntax for Graphite

We are currently following the development branch of Graphite-Web. After upgrading last week, we noticed that saved graphs with quotes in the entries result in the quotes being expanded to HTML entities. Example:
alias(scale(summarize(collectd.someserver.someservice.somemetric.time-to-prod,"1d","max"),0.0166667),"Daily+Maximum")
Should be:
alias(scale(summarize(collectd.someserver.someservice.somemetric.time-to-prod,"1d","max"),0.0166667),"Daily+Maximum")
This results in many saved graphs being broken. Unfortunately, I haven't been able to track back which package or change caused the difference in behavior.

Perhaps https://github.com/graphite-project/graphite-web/pull/1662?

We, scianos and I, made it working after removing escape in the code.
graphUrlParams[param[0]].append(escape(param[1]))
I think the issue is related to #1662

It definitely looks like the escaping of the quote to an HTML entity is related to the issue at hand. The question is how we implement a fix which both solves the XSS and allows existing graph URLs containing quotes to work (the internal patch we're using will re-open the XSS problem, so this isn't a solution we can/would want to commit back yet without further work).

I'm having lots of random issues recently with that kind of errors in the logs, could that be related?
I think it started happening with a recent Graphite update. I don't see any quote in the query at least in Grafana
KeyError: ({Suppress:("\") W:((){}...)}, u'netapp.perf.VYN.S18SAN.node.S18SAN-02.vol_summary.total_ops', 6, True, True)
KeyError: ("}", u'aliasByNode(highestAverage(netapp.perf.{CEL,HAN,MRI,NOR,ODH,PRI,SHA,TOK,VYN}.{S10SAN,S11SAN,S13SAN,S16SAN,S18SAN,S25SAN,S32SAN,S34SAN,S37SAN}.node.*.vol_summary.total_ops, 4), 5)', 75, True, True)
KeyError: ({{Suppress:("\") W:((){}...)} | W:(!#%$...)}, u'netapp.perf.VYN.S18SAN.node.S18SAN-02.vol_summary.total_ops', 12, False, True)
KeyError: ({{{Suppress:("\") W:((){}...)} | W:(!#%$...)}}..., u'netapp.perf.HAN.S37SAN.node.S37SAN-02.vol_summary.total_data', 15, False, True)
KeyError: ("\", u'aliasByNode(highestAverage(netapp.perf.{CEL,HAN,MRI,NOR,ODH,PRI,SHA,TOK,VYN}.{S10SAN,S11SAN,S13SAN,S16SAN,S18SAN,S25SAN,S32SAN,S34SAN,S37SAN}.node.*.vol_summary.avg_latency, 5), 5)', 33, False, True)

I have been thinking about this bug and I have arrived to the conclusion the xss protection from  #1662 is broken. urlencode works because you do not want your users submiting '"<> and other garbage. But in graphite we need the " or '. And there is no way to protect from XSS if you have " in a url, eg: target=" onload="nasty()".
The threat model in #1470 does not apply to me, because we know personally everybody who has account and can save a graph. We use drawAsInfinite(events('deploy')) very much, so whe have undone the changes from #1662 and live is good again. But I understand graphite as a project can't ignore a XSS. I am also able to fix this if my patches have any posibility to get commited. I think there are various solutions
Adding a configuration variable XSS_PROTECTION that can have 3 values NONE, NAIVE and FULL. NONE is obvious, everything  in, everything out. FULL is as now, with urlencode. NAIVE would be our own custom filter, allowing ' but removing garbage in literals (naive because I am pretty sure it will have some hole). Graphite-web ships with default FULL and document this.
Implementing literal binding? target=drawAsInfinite(events(\1))&literal=deploy and urlencode. Very complex, and I am not sure even if it is viable.
As is, but urldecoding in evaluator.evaluateTokens and fixing the client side to unquote when editing. As it is now, the browser when editing the target shows drawAsInfinite(events('deploy'))

I'm very much in favor of this approach, with Graphite continuing to default to FULL.

Defaulting to FULL means not functioning properly out of the box, no? And also requiring that users potentially reduce security in order for graphite web to function properly, if I'm understanding right. I would hope there is a better solution.

I did a clean install from source on a Raspberry Pi and I just hit this issue too. Am I missing something?
It seems to me that Graphite is fundamentally broken due to #1662 because a graph is broken the moment you save it.
How do people deal with this other than removing #1662 ?

@louwrentius : looks like majority of users using 3rd party dashboards now

@deniszh I guess so, but still a bit sad because that 3rd party dashboard is an additional requirement I would not need. I don't really see a solution either, I'm not that into web programming but I understand maybe just enough that I think that - because of how the GUI works - it may not be fixable.


"Generation" parameter through Crossover operation

Would be possible to alter ICrossover interface
from:
IList Cross(IList parents);
to:
IList Cross(Generation CurrentGeneration, IList parents);
?

Nice question! I would like to know what is the crossover operation you're trying to implement.
Well, we don't need to change the ICrossover interface to get this done, you can just inject the Population in your crossover implementation's constructor, like this:
public class MyCrossover : CrossoverBase
{
     private Population m_population;

     public MyCrossover(Population population) : base(2, 2)
     {
         m_population = population;
     }

     protected override IList<IChromosome> PerformCross(IList<IChromosome> parents)
     {
             // Now you can read current generation from
             // m_population.CurrentGeneration

             // your crossover code...
     }
}

var selection = new EliteSelection();
var mutation = new ReverseSequenceMutation();
var fitness = new MyProblemFitness();
var chromosome = new MyProblemChromosome();

var population = new Population (50, 70, chromosome);
var crossover = new MyCrossover(population);

var ga = new GeneticAlgorithm(population, fitness, selection, crossover, mutation);
ga.Termination = new GenerationNumberTermination(100);
ga.Start();

Great, I will give a try.
It is just abt math operations; I'm using geneticsharp to solve some math problems.
Thanks


ui-select cannot match model value if property used in choises is an object

Using "single property for binding" ui-select cannot load correct object if the property is an object.
Example: http://plnkr.co/stY0BEjwSuFuRw3fzUaN
One solution could be to make ui-select-choices directive offer an attribute to specify a matcher function.

Maybe #1464 will help you?
I think really ui-select should use track by to make a getter function to do the matching, like ngOptions does.

#1464 and track by would be a nice workarounds but I think explicit providing a matcher function would be much more versatile. Just think if you need to track by multiple properties


Support for docker

Can this be using in an unprivileged docker containers?
I  tired with debian stretch and ubuntu 16.04 container but got errors related to fuse device
I know I could run a --privileged flag ,install fuse on host machine then pass --device /dev/fuse
But it's would take away the portability and making it difficult or not possible to deploy on public cloud like openshift , heroku , sloppy.io, GCP

It looks like it's still experimental: http://www.forshee.me/2016/02/22/container-mounts-in-ubuntu-1604.html
Anyway, if you can run any FUSE implementation in your container, you should be able to run google-drive-ocamlfuse without problems.

@astrada thank you for the helpful link. As the post is from 2016 lxc is now replaced by docker ?
I just started using docker and don't know anything about linux containers / ofc
Have you tried the method in above post?

Sorry, I don't really know much about containerization technologies. What about https://stackoverflow.com/a/49021109/2860133 ?

The stackoverflow answer doesn't help as it needs to run the container in privileged mode and attach fuse device from host and so the container is dependent on host and porting the container to another host won't work. But thank you for your answer I will do some more research


there is a bug in SpawnHandle

the underlying future will be canceled when I call SpawnHandle::forget,
extern crate futures;
extern crate tokio_core;

use std::thread;
use std::time::Duration;

use futures::{Future, Stream};
use futures::future::{Executor, ExecuteError, empty};
use futures::sync::mpsc;
use futures::sync::oneshot::{self, Execute};
use tokio_core::reactor::{Core, Remote};

struct MyExecutor {
    handle: Remote,
}

impl MyExecutor {
    fn new(handle: Remote) -> Self {
        MyExecutor { handle: handle }
    }
}

impl<F> Executor<Execute<F>> for MyExecutor
where
    F: Future + Send + 'static,
    F::Item: Send,
    F::Error: Send,
{
    fn execute(&self, future: Execute<F>) -> Result<(), ExecuteError<Execute<F>>> {
        self.handle.spawn(move |_| future);
        Ok(())
    }
}

fn main() {
    let mut core = Core::new().unwrap();
    let my_executor = MyExecutor::new(core.remote());
    thread::spawn(move || {
        let (tx, rx) = mpsc::unbounded();
        let f = rx.for_each(|t| Ok(println!("{}", t)));
        let handle = oneshot::spawn(f, &my_executor);
        handle.forget();
        for i in 1..10 {
            tx.unbounded_send(i).unwrap(); // panic here
            thread::sleep(Duration::from_secs(1));
        }
    });
    core.run(empty::<(), ()>()).unwrap();
}

this code will panic due to the drop of the UnboundedSender.

Oh oops, I think this is a typo! Mind changing that to true locally and see if it works for you? If so, would you want to send a PR?


raft leader loses leadership and the node gets stuck

Found in version 4.14.1 and observed at least 5-10 times for a 16 nodes cluster.
The issue can be seen in these logs.zip, where a cluster is first started and node 153 is elected a leader. However, shortly after this, node 153 and other nodes report "Consensus cannot be reached" e.g. nodes 179 and 155. When other nodes later send vote requests, 153 consistently times out like below. Not only that, but once a new leader is elected, all AppendEntries coming from the leader (and later install snapshot) timeout in the very same way.
2024-02-06 14:14:20.1952|WARN|DotNext.Net.Cluster.Consensus.Raft.Tcp.TcpServer|Timeout occurred while processing request from <IP_ADDRESS>:40802|System.OperationCanceledException: The operation was canceled.
   at DotNext.Result`1.Validate() in /_/src/DotNext/Result.cs:line 186
   at DotNext.Result`1.get_Value() in /_/src/DotNext/Result.cs:line 181
   at DotNext.Threading.Tasks.ValueTaskCompletionSource`1.GetResult(Int16 token) in /_/src/DotNext.Threading/Threading/Tasks/ValueTaskCompletionSource.T.cs:line 230
   at DotNext.Threading.Tasks.ValueTaskCompletionSource`1.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token) in /_/src/DotNext.Threading/Threading/Tasks/ValueTaskCompletionSource.T.cs:line 237
   at DotNext.Net.Cluster.Consensus.Raft.RaftCluster`1.VoteAsync(ClusterMemberId sender, Int64 senderTerm, Int64 lastLogIndex, Int64 lastLogTerm, CancellationToken token) in /_/src/cluster/DotNext.Net.Cluster/Net/Cluster/Consensus/Raft/RaftCluster.cs:line 809
   at DotNext.Net.Cluster.Consensus.Raft.TransportServices.ConnectionOriented.Server.VoteAsync(ProtocolStream protocol, CancellationToken token) in /_/src/cluster/DotNext.Net.Cluster/Net/Cluster/Consensus/Raft/TransportServices/ConnectionOriented/Server.cs:line 56
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at DotNext.Net.Cluster.Consensus.Raft.Tcp.TcpServer.HandleConnection(Socket remoteClient) in /_/src/cluster/DotNext.Net.Cluster/Net/Cluster/Consensus/Raft/Tcp/T

In the log for node 153 I replaced a long section of the repeated timeout error with '...'. Nothing different in there, just the same timeout until we stopped the system.

Does it have stable repro? I can guess that there is a deadlock caused by transitionLock. It can be proven by measuring some metrics. Using dotnet-counters, you can measure DotNext.Threading.AsyncLock group of counters and then capture suspension-duration counter.

It has happened in about 1 of 12 clean starts in that system (we use clean starts when running with new configurations). However, the system is in use so I am not certain I will be able to gather this type of data soon (also need to check if dotnet-counters plays well with the single app deployment as I had trouble earlier with other diagnostic tools).
That said, the way I interpreted those log entries was also about the transitionLock.AcquireAsync timing out. Of course that does not say the reason, so my interpretation was either something is still holding the lock (stuck somewhere) or the lock failed to be released somehow.
I do wonder if it is something that goes wrongs on the first actions the node takes when it has been elected a leader.

Could you provide debug logs?

I have some assumptions, but debug logs are needed to confirm that. According to presented logs for node 153 I see that it's elected a leader
2024-02-06 14:14:16.6664|WARN|leaderchange|New cluster leader is elected - Leader address <IP_ADDRESS>:4250 - Term 1 - Election timeout 00:00:01.5340000

then trying to replicate log entries to some unavailable member (with port 150 which is not presented in the log so I can assume that it's really unavailable)
2024-02-06 14:14:17.2924|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.2899|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3090|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3113|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3212|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3212|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3378|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3449|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3508|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1
2024-02-06 14:14:17.3508|WARN|DotNext.Net.Cluster.Consensus.Raft.RaftCluster|Replication of <IP_ADDRESS>:4250 is failed. Retry replication from entry 1

then leader probably downgrades to follower
2024-02-06 14:14:19.2067|WARN|leaderchange|Consensus cannot be reached - Term 1 - Election timeout 00:00:01.5340000

and then we see the timeout
2024-02-06 14:14:20.1952|WARN|DotNext.Net.Cluster.Consensus.Raft.Tcp.TcpServer|Timeout occurred while processing request from <IP_ADDRESS>:40802

At the moment, I would assume that the issue is not caused by AsyncExclusiveLock. When the node is in the specific state, it doesn't hold transition lock. The lock is needed to protect the transition between states. The leader downgrades to follower and calls MoveToFollowerState. During transition, the lock is acquired that prevents VoteAsync from correct processing. Probably, some async call inside of MoveToFollowerState prevents exit from the transition lock. The only async call is StepDown
https://github.com/dotnet/dotNext/blob/6b36d0b5e3560a4e19860d8b134196b8b9a4b557/src/cluster/DotNext.Net.Cluster/Net/Cluster/Consensus/Raft/RaftCluster.cs#L512-L546
UpdateTermAsync is not cancelable and relies on disk I/O. The next call is DisposeAsync on LeaderState.
Debug logs are needed to see what happened

Does leader trying to downgrade to follower?
Does MoveToFollowerState stuck?

Another approach: you can use dotnet dump to dump the process that was elected as a leader and then provide CLR stacktraces for each tread as described here: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-deadlock

Unfortunately I can't make changes or stop/restart the system where this was reproduced at least in the next 2-4 weeks. I have tried reproducing the issue on a dev cluster (11 nodes instead of 17 nodes) without any luck.
Regarding the rest, a bit confused on this one:

then trying to replicate log entries to some unavailable member (with port 150 which is not presented in the log so I can assume that it's really unavailable)

Were you referring to <IP_ADDRESS>? "Cluster member <IP_ADDRESS>:4250 is unavailable"
There might be varying delays on the start of each node that change the picture, but logs show the process was started in all nodes within ~300ms. The exception to this is node 1, that started a little over 3 seconds later. This is because a script in node 1 starts all processes and only after it triggers that in all nodes it is starting its own process.
I tried adding 1-3 seconds start delay on the dev cluster script but failed to reproduce the issue. Last run I checked in the log it even shows the is unavailable message in the log, but did not reproduce the slow replication that comes with stuck node (in the version I am trying) + I also did not see any of the timeout exceptions in the logs across the cluster.
Re the rest of the analysis, that makes sense to me. However, I do wonder about the various early "Consensus cannot be reached" + related election time => whether nodes really got the very first hearbeats after the election.

After careful analysis of source code (without ability to reproduce) I can conclude that the only suspected is DisposeAsync called on previous state when transition initiated. This is the only uninterruptible asynchronous method called within the transition lock.

That will be hard to do it soon, because I still can only reproduce it the system that is busy + I can't deploy this larger update without it going through some testing in other systems first e.g. as it includes various other changes, like the move to 5+ and .net 8.

Released in 5.0.3. In case of stable repro feel free to reopen it.

I was finally able to gather debuglogs.zip (with 4.14.1). In that run node 164 gets stuck.
With some votes against, 164 gets a clear majority and succesfully transitions to the leader state. Node 1 was clearly unavailable at this point and in fact its log shows it does not starts unil 164 is already stuck.
I find the first round of replications odd because it only shows this message for 14 out of the 16 nodes "Replication of member {Member} started at log index {EntryIndex}". These are 13, which makes sense because node 1 is not live and was in the first list "Replication of {Member} is failed. Retry replication from entry {EntryIndex}".
The only thing that follows the apparently incomplete replication is the member is downgrading message, which does not have a matching member is downgraded message. However, this happens over 2 seconds later, which suggests the first issue to trigger the bug happens before this point.

I managed to reproduce it with this test (added to TcpTransportTests), but it took many runs to trigger it:
    [Fact]
    public async Task LeadershipWithUnavailableNodeCore()
    {
        var ports = new[] { 3265, 3266, 3267, 3268, 3269, 3270, 3271, 3272, 3273, 3274, 3275, 3276, 3277, 3278, 3279, 3280 };

        RaftCluster clusterFactory(int port)
        {
            var config = new RaftCluster.TcpConfiguration(new IPEndPoint(IPAddress.Loopback, port))
            {
                RequestTimeout = TimeSpan.FromMilliseconds(1000),
                ConnectTimeout = TimeSpan.FromMilliseconds(10),
                LowerElectionTimeout = 1500,
                UpperElectionTimeout = 3000,
                TransmissionBlockSize = 8192 * 4 * 10,
                ColdStart = false,
            };
            config.LoggerFactory = LoggerFactory.Create(l => l.AddDebug().SetMinimumLevel(LogLevel.Debug));
            var builder = config.UseInMemoryConfigurationStorage().CreateActiveConfigurationBuilder();
            foreach (var p in ports)
                builder.Add(new IPEndPoint(IPAddress.Loopback, p));
            builder.Build();
            return new(config);
        }

        var hosts = ports.Select(p => clusterFactory(p)).ToList();
        var startedHosts = hosts.Skip(1).Select(async h => {
            await Task.Delay(Random.Shared.Next(300));
            await h.StartAsync();
            }).ToList();
        await Task.WhenAll(startedHosts);

        Debug.WriteLine("----------------");
        Debug.WriteLine("Done starting!");
        Debug.WriteLine("----------------");
        await Task.Delay(8500);

        await hosts[0].StartAsync();
        Debug.WriteLine("----------------");
        Debug.WriteLine("Done starting extra node!");
        Debug.WriteLine("----------------");

        await Task.Delay(30000);

        var leaderPort = ((IPEndPoint)hosts.First().Leader.EndPoint).Port;
        var leader = hosts.Single(h => ((IPEndPoint)h.LocalMemberAddress).Port == leaderPort);

        foreach (var member in leader.Members)
        {
            var status = member.Status;
            if (status is not ClusterMemberStatus.Available)
                Fail($"Member {member.EndPoint} has unexpected status {status}");
        }

        await Task.WhenAll(hosts.Select(h => Task.Run(() => h.StopAsync())));
    }

I just ran it again with RunUntilFailure and it failed in the 18th attempt. Used this version to get nlog logs like the ones I attached from the original system (requires adding the NLog.Extensions.Logging nuget package):
    [Fact]
    public async Task LeadershipWithUnavailableNodeCore()
    {
        var ports = new[] { 3265, 3266, 3267, 3268, 3269, 3270, 3271, 3272, 3273, 3274, 3275, 3276, 3277, 3278, 3279, 3280 };

        RaftCluster clusterFactory(int port)
        {
            var config = new RaftCluster.TcpConfiguration(new IPEndPoint(IPAddress.Loopback, port))
            {
                RequestTimeout = TimeSpan.FromMilliseconds(1000),
                //low ConnectTimeout is needed to ensure the leader moves to the next append quickly when it attempts to reestablish connections to a disconnected follower
                ConnectTimeout = TimeSpan.FromMilliseconds(10),
                //we are using much larger values compared to the default raft timeouts (150-300), because we have trouble in larger systems with the timeouts. Even before this we had it at 300-600 based on earlier stability tests.
                //Lower is desireable for us as it limits the latency in re-election cases (see raft paper for graphs on worse cases depending on the values)
                //A larger difference between lower and upper timeouts compared to the default is likely needed for larger amount of nodes (16 for example),
                //as it reduces the probability of split elections that at the end increase the time to elect a leader (see raft paper graphs)
                LowerElectionTimeout = 1500,
                UpperElectionTimeout = 3000,
                //see https://github.com/copenhagenatomics/dotNext/issues/2 for more info on tuning,
                //but for now we are using approx. 4 times the size of a full 1k values entry (8000 bytes)
                TransmissionBlockSize = 8192 * 4 * 10,
                ColdStart = false,
            };
            config.LoggerFactory = LoggerFactory.Create(b => b.AddNLog(GetLoggingConfiguration(port.ToString())).SetMinimumLevel(LogLevel.Debug));
            var builder = config.UseInMemoryConfigurationStorage().CreateActiveConfigurationBuilder();
            foreach (var p in ports)
                builder.Add(new IPEndPoint(IPAddress.Loopback, p));
            builder.Build();
            return new(config);
        }

        static NLog.Config.LoggingConfiguration GetLoggingConfiguration(string node)
        {
            var minLevel = NLog.LogLevel.Debug;
            var config = new NLog.Config.LoggingConfiguration(new() { GlobalThreshold = minLevel });
            config.AddRuleForAllLevels(new NLog.Targets.FileTarget("raft" + node) { FileName = $"{node}.log" });
            return config;
        }

        var hosts = ports.Select(p => clusterFactory(p)).ToList();
        var startedHosts = hosts.Skip(1).Select(async h => {
            await Task.Delay(Random.Shared.Next(300));
            await h.StartAsync();
            }).ToList();
        await Task.WhenAll(startedHosts);

        Debug.WriteLine("----------------");
        Debug.WriteLine("Done starting!");
        Debug.WriteLine("----------------");
        await Task.Delay(8500);

        await hosts[0].StartAsync();
        Debug.WriteLine("----------------");
        Debug.WriteLine("Done starting extra node!");
        Debug.WriteLine("----------------");

        await Task.Delay(30000);

        var leaderPort = ((IPEndPoint)hosts.First().Leader.EndPoint).Port;
        var leader = hosts.Single(h => ((IPEndPoint)h.LocalMemberAddress).Port == leaderPort);

        foreach (var member in leader.Members)
        {
            var status = member.Status;
            if (status is not ClusterMemberStatus.Available)
                Fail($"Member {member.EndPoint} has unexpected status {status}");
        }

        await Task.WhenAll(hosts.Select(h => Task.Run(() => h.StopAsync())));
    }

@sakno I can't reopen the issue. The test above reproduces the bug in 5.1.0.
The last 2 runs using RunUntilFailure reproduced it in the 5th and 6th attempt respectively.

In short I did these to reproduce, but not sure how much of it is needed to do so:

Same TcpConfiguration
Uses in memory configuration storage initialized with all the nodes
first node is started 8.5 seconds after the other nodes started
there is a random delay of 0-300 ms before starting the nodes, to try to repro the more natural spread we see starting that cluster
after 30 seconds of running, we get the leader RaftCluster instance and check that all members are detected as available / the idea being that the node that is stuck would not be available
a Debug log file named after the port number is created for each node. Used after the failure to confirm the node was actually stuck in the same way.

Could you share debug log files from the test? From my side, I'll port LeadershipWithUnavailableNodeCore to XUnit to include the test to existing collection of tests.

I did not kept the ones from those runs, but here are the ones from a new run failing on the 9th attempt with node with port 3276 having status Unavailable (logs.zip

I just reproduced without most of those settings, left only ConnectTimeout. Doing another run without it now, since an earlier run without it did not reproduce in 20 runs.

Ok, even that is not needed / reproduced on the first attempt.

Simplified test, less moving parts and faster attempts.
Changes:

Default TcpConfiguration (except ColdStart = false)
Removed starting of the last node and extra wait there. The node is stuck by then, so no point in including that later action
Reduced the wait after all nodes are started to 6 seconds

Above said, the runs I tried varied wildly in amount of attempts to reproduce.
    [Fact]
    public async Task LeadershipWithUnavailableNodeCore()
    {
        var ports = new[] { 3265, 3266, 3267, 3268, 3269, 3270, 3271, 3272, 3273, 3274, 3275, 3276, 3277, 3278, 3279, 3280 };

        RaftCluster clusterFactory(int port)
        {
            var config = new RaftCluster.TcpConfiguration(new IPEndPoint(IPAddress.Loopback, port)){ ColdStart = false, };
            config.LoggerFactory = LoggerFactory.Create(b => b.AddNLog(GetLoggingConfiguration(port.ToString())).SetMinimumLevel(LogLevel.Debug));
            var builder = config.UseInMemoryConfigurationStorage().CreateActiveConfigurationBuilder();
            foreach (var p in ports)
                builder.Add(new IPEndPoint(IPAddress.Loopback, p));
            builder.Build();
            return new(config);
        }

        static NLog.Config.LoggingConfiguration GetLoggingConfiguration(string node)
        {
            var minLevel = NLog.LogLevel.Debug;
            var config = new NLog.Config.LoggingConfiguration(new() { GlobalThreshold = minLevel });
            config.AddRuleForAllLevels(new NLog.Targets.FileTarget("raft" + node) { FileName = $"{node}.log" });
            return config;
        }

        var hosts = ports.Select(clusterFactory).ToList();
        var startedHosts = hosts.Skip(1).Select(async h => {
            await Task.Delay(Random.Shared.Next(300));
            await h.StartAsync();
            }).ToList();
        await Task.WhenAll(startedHosts);
        await Task.Delay(6000);

        var firstPort = ports[0];
        var leaderPort = ((IPEndPoint)hosts.Skip(1).First().Leader.EndPoint).Port;
        var leader = hosts.Single(h => ((IPEndPoint)h.LocalMemberAddress).Port == leaderPort);

        foreach (var member in leader.Members)
        {
            if (((IPEndPoint)member.EndPoint).Port == firstPort)
                continue; // we don't check node 1 because we never started it
            var status = member.Status;
            if (status is not ClusterMemberStatus.Available)
                Fail($"Member {member.EndPoint} has unexpected status {status}");
        }

        await Task.WhenAll(hosts.Skip(1).Select(h => Task.Run(() => h.StopAsync())));
    }

Thanks for your code. I was able to repro the issue with the provided test. At least it proves that the root case not inside of persistent WAL, because it's reproducible with in-memory consensus-only WAL Currently, I found that the issues somewhere within LeaderState<TMember>.ForkHeartbeats private method.


feature(plugins/sct): Add fields for origin and branch names

This change adds fields for tracking sct repository and branch used for
a test run.
Task: #302

LGTM
Now we need to update the client in SCT ?

Yes


clean up label comments

Preview:
https://deploy-preview-15397--kubernetes-io-master-staging.netlify.com/docs/contribute/intermediate/

/lgtm
/approve


openstack: clone from the teuthology master

Do not clone from an obsolete development branch by default.
Signed-off-by: Loic Dachary<EMAIL_ADDRESS>

Refer to this link for build results (access rights to CI server needed):
http://jenkins.ceph.com//job/teuthology-pull-requests/1852/
Test PASSed.


Enhancements

@klaus78
Well firstly this is a nice initiative project, It can be a nice learning resource for newbies, so good work!
But there is some enhancements related to the layout of the content I think they must be approached so It would be easier and more effective browsing throught the flashcards:

First thing I thought of is "back to top" button mentionned in #19, even if the clicking on top bar do the job but It's not intuitive for the user so a nice floating button on the top right is helpful.
More importantly in my opinion is the navigation tree, instead of putting it on the top and having to go back everytime the user look for different category, you can fix it on the left side where it will appear all the time when navigating down for the questions.
Another necessary feature is the search bar, where we can search for questions by keywords so all related question would appear nested under the their respective categories.
last but not least, a category filter can be added on top as keywords so when clicked on "machine learning" for example I will get only machine learning questions.

P. S. I see some questions include images althought they're not centered, but such illustration should be a standard for all questions as it makes more context and add value to the content of the cards!
This is what I thought of so far as good features for this project!

@iaminebriki I welcome your suggestions and improvements. This site is generated with jekyll, which is a static site generator. Is it possible to add a search bar in a static site?
The navigation tree on the left is a nice idea so you have less up und down scrolls. I am thinking that it should be possible to show/hide it because on mobile devices you have a small screen. But also I wonder if this can be done with jekyll. If yes it would be great.
Illustrations are great but time consuming :) as all the images are original material and not copy/pasted from other images but I definetly agree that taking about data science and machine learning without images is a bit a limiting experience.

I'm no web developer but at first glance it looks like it is indeed possible to have a search bar on a Jekyll site, see these links for refrences: link1, link2. One possible and simple option is to use Lunr.js
A collapsible navigation tree would be great, and I think it's possible with some js code like:
$(document).ready(function () {
  // Add a click event handler to toggle the submenus
  $('.nav-tree li:has(ul) > a').click(function (e) {
    e.preventDefault();
    $(this).parent('li').toggleClass('collapsed');
    $(this).next('ul').slideToggle();
  });
});
Agreed on the illustartions part 💯

Thank you I will check those links and give it a try. Feel free to try it in case you have more time than me :)


Docs update

By official Google docs, it seems that library can convert the following: JPEG, PNG or TIFF, but in the documentation (or at least the README) it says only first two.

WebP Convert checks the file extension and only allow files with png, jpg or jpeg extension to be converted. So docs are alright... But WebP Convert could be changed so it does not filter out TIFF.

Makes sense, it seems like you are keeping allowed extensions in the helper.
What about moving it in some abstract class and each converter, e.g. WebP extending this class. It would follow polymorphism and we have a choice to define allowed extension list per converter (as it is usually like that).
Such as:
class WebP extends BaseConverter {
    $allowedExtensions = ['image/jpeg', 'image/jpg', 'image/png', 'image/tiff'];
...
}

class BaseConverter {
    protected $allowedExtensions = [];
}

Yes, I'm actually on it (the BaseConverter). The 2.0.0 branch uses that pattern. I'm not completely through with that refactoring

Just released 2.0.0-beta. I will probably release 2.0.0 tomorrow


develop <- master

Merge PR to develop along with master branch push for article publication. Created by this action: https://github.com/falgon/roki-web-post/actions/runs/5654039875

Build log
Preview build with this PR (3d0ae06c36c880ef2321dccca2b6475851058044)

more info:cloud: Storage Free space   6.93 GiB    46.20%:open_file_folder: 111.50 MiB  CI_WORK/GitHubActions/roki-web


Add formatting for MatchCase

Summary
This PR adds formatting support for MatchCase node with subs for the Pattern
nodes.
Test Plan
TODO
resolves: #6299

Current dependencies on/for this PR:

main

PR #6286

PR #6360   👈

This comment was auto-generated by Graphite.


fix(deps): update terraform-module

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-cbr
module
patch
v1.23.0 -> v1.23.1

terraform-ibm-modules/cbr/ibm (source)
module
patch
1.23.0 -> 1.23.1

terraform-ibm-modules/kms-all-inclusive/ibm (source)
module
minor
4.14.2 -> 4.15.2

Release Notes

terraform-ibm-modules/terraform-ibm-cbr (github.com/terraform-ibm-modules/terraform-ibm-cbr)
v1.23.1
Compare Source
Bug Fixes

Event Notifications introduced SMTP API that does not support report enforcement mode. By default report mode is set which excludes SMTP API. If enforcement mode is set to enabled, CBR will be applied to the SMTP API as well.- Added MQ segmentation to add data plane API type id (#485) (fa554b3)

terraform-ibm-modules/terraform-ibm-kms-all-inclusive (terraform-ibm-modules/kms-all-inclusive/ibm)
v4.15.2
Compare Source
Bug Fixes

deps: update terraform terraform-ibm-modules/key-protect/ibm to v2.8.1 (#525) (71bd47c)

v4.15.1
Compare Source
Bug Fixes

deps: update terraform terraform-ibm-modules/cbr/ibm to v1.23.1 (#523) (bf747e2)

v4.15.0
Compare Source
Features

added support for creating Context Based Restrictions (CBRs) using new input cbr_rules.
The existing_kms_instance_guid input in the module has been updated to existing_kms_instance_crn (#516) (defd93d)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

/run pipeline

:tada: This issue has been resolved in version 1.11.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Update manual_annotation.md

fix a typo

@d-v-b thank you for the interest but this is probably best fixed in https://github.com/napari/napari-workshop-template which we've forked here. We're not actually going to follow the same structure so this file will probably just disappear here.


New Website Logo: ioBroker

Please fill the following out:

Name: ioBroker
Homepage url: http://www.iobroker.com/
Brand Guidelines/Licensing: https://github.com/ioBroker/awesome-iobroker#trademark-legal-notice
Logo: https://raw.githubusercontent.com/ioBroker/awesome-iobroker/master/images/awesome-iobroker.svg

Correction: The url is www.iobroker.net


Probability of BABE stalling?

I've found in the docs + checked code that BABE has only 2 fallbacks in case no primary blocks: SecondaryPlain + SecondaryVRF.
While I'm happy to have discovered this extra SecondaryVRF I was not aware of, yet two secondary authors seems a bit low to me because it's quite easy to have a faulty node in a epoch, even more with sleeping attackers.
Is there another fallback I'm not aware of? Don't you think there is a security issue here? Am I missing something?

You only need one block per epoch/session to prevent BABE from stalling.

I don't get it. The problem is the same to me whether the block is the first of an epoch, the second or the last.
Don't we have a stalling if no next block is proposed?

What you mean? When no block is produced anymore? Why should there be no  block be produced anymore?

Because of VRF leading to no primary block (no validator matching), same for secondary VRF, and same for secondary plain because, as I understand it, only one validator is selected per slot and he might be faulty.

There is no problem if one slot is skipped.

That was my blind spot. Thanks.


feat: add ICT for most tools

To be merged after #525
This PR adds ICT specification files for most tools in the repo:
OpenMP tools have validation errors that did not allow for ICT conversion https://github.com/PolusAI/image-tools/issues/526
This PR also includes the script used to convert the Tools to ICT. It can be used as a CLI Application, with options --alll, -a to convert all and --name, -n to specify the name of the Tool to convert.
$ python3 to_ict.py --all
03/13/2024 11:17:36 PM - INFO - Found 108 manifests in /Users/camilovelezr/image-tools
03/13/2024 11:17:36 PM - INFO - all: True
 33%|███████████████▊                                | 34/103 [00:00<00:00, 338.40it/s]03/13/2024 11:17:36
100%|███████████████████████████████████████████████| 103/103 [00:00<00:00, 321.20it/s]
03/13/2024 11:17:36 PM - INFO - Converted 103/103 plugins
$ python3 to_ict.py -n "roi-relabel-tool"
03/13/2024 11:13:35 PM - INFO - Found 108 manifests in /Users/camilovelezr/image-tools
03/13/2024 11:13:35 PM - INFO - name: roi-relabel-tool
03/13/2024 11:13:35 PM - INFO - all: False
03/13/2024 11:13:35 PM - INFO - Converted 1/1 plugins

This looks good. However one question. How could we best handle the dependency to ICT?
I think this PR should only contain the icts.
I think it will be best for the to-ict code to belongs to polus.tools and then be able to point the script to a tool repo and have it recursively found the plugin.json and do the conversion

Also it would be good to log the path of the created ict so this can be easily be checked


Evaluator Review: Neutroswap milestone 0 delivery #136

Review, approve, or deny https://github.com/eosnetworkfoundation/grant-milestones/pull/136

Closed per @DenisCarriere approval for https://github.com/eosnetworkfoundation/grant-milestones/pull/136.


Project Page - New Status - Dropped Required

New status Required for project
scenarios -
Client dont want to continue Project
Client left
etc

Problems-
System want every project finish at finished State, so system can start working , create reports from it

not sure about implementation with team


Fixing index.html formatting error

I like to make these sort of changes on my own. But i appreciate the efforts. Thank you.


Update artwork_rail.js

fixed

          1 Warning

  :warning:
  Please assign someone to your PR

  Generated by :no_entry_sign: danger

Awesome @cristianavalancha , thanks for catching that!  👀


Implement loadgenerator k8petstore e2e test

Output perf data to a local file that can be regression checked in any CI.
Separated from #3139

cc @timothysc here's what im working on now :)

@satnam6502 @roberthbailey

PR is here, post 1.0 #8145 . I'm ok closing this issue, as the PR is enough


Version 1.0.3 (Public Release)

README.md is cleaned up to keep instruction simple and easy to use.

nice!


Set up associations

Set up associations

Run a program using the command line.
Set up associations between classes and objects.

Status: Invalid 🔴
Hi @M1rn4 🙋♀,
While you made a great effort in this project, I can't review your code.
Invalid Code Review Request
You have submitted a project that has a README that is not professional. Here is a key point to consider when documenting your README.

All main headers from the README template should be present. You are missing the entire Getting Started, kindly make sure that you add information on how to clone the project and run it locally.

Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers 🥂  and Happy coding!!! 👯
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Remember to tag me @KDlamini  in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.