RD2: Telemetry for RD2_Enabled

Critical Changes
Changes
Issues Closed
New Metadata
Deleted Metadata

@force2b The line below my TODO comment on line 124 of src/classes/UTIL_OrgTelemetry_TEST.cls causes a test failure.  Either I am mishandling something, or this line is no longer a valid test of the method.  Would appreciate your guidance.

**lurch: attach W-035303

Tracking W-035303

@sam-knox There is overlap between this work item and W-035558.  I have tried to reflect changes, but it is worth reviewing labels to make sure latest changes are not overwritten.

@force2b package.xml alphabetization change made.

@npsp-reedestockton it appears there are merge conflicts on this branch. Would you mind resolving those first so I know that they don't interfere with accurately testing? Thank you!

Since this was already merged, I will do my checking on the feature/RD2 branch. If that I'll checks out I'll come back here and comment. If now, I'll let the Reed(e)s know: @npsp-reedestockton and @davidmreed .

Confirmed that this code has been successfully added to master and can be pushed to a scratch which is about as far as I can go in testing this ticket until a package is created. I've noted this on our work item so we can consider ways to make sure this is tested once RD2 is merged into master.

@Julian88Tex I reverted the merge by request.

@davidmreed cool.... new PR created? @npsp-reedestockton ?


not all defaults are rendered

when executing
./cty generate -u https://raw.githubusercontent.com/crossplane-contrib/function-go-templating/main/package/input/gotemplating.fn.crossplane.io_gotemplates.yaml

the result looks like:
apiVersion: gotemplating.fn.crossplane.io/v1beta1
delims:
  left: string
  right: "}}"
fileSystem:
  dirPath: string
inline:
  template: string
kind: GoTemplate
metadata: {}
source: string

i wonder why left is without the default value
apiVersion: gotemplating.fn.crossplane.io/v1beta1
delims:
  left: "{{"
  right: "}}"
fileSystem:
  dirPath: string
inline:
  template: string
kind: GoTemplate
metadata: {}
source: string

Oh, that's trimmed by the sanitizer. :DDD It thinks it's a templating value 🤦
I'll fix it. :)) Thanks for reporting.

This is the culprit BTW https://github.com/Skarlso/crd-to-sample-yaml/blob/main/pkg/sanitize/sanitizer.go


chore: update @stencil/core to the latest version (fix #7)

To install this version:
npm install arthur-fontaine/stencil-solid-output-target#pull/9/head

You can just try "@stencil/core":"^4", you can release "@stencil/core":"^3" and "@stencil/core":"^4" separately, and download the corresponding stencil-solid-output-target in the different stencil versions!!

Fixed in 9db42e...18dc7d


too many 504 error responses

All my query requests are currently failing with:
requests.exceptions.RetryError: HTTPSConnectionPool(host='www.notion.so', port=443): Max retries exceeded with url: /api/v3/queryCollection (Caused by ResponseError('too many 504 error responses'))
Also:
requests.exceptions.RetryError: HTTPSConnectionPool(host='www.notion.so', port=443): Max retries exceeded with url: /api/v3/queryCollection (Caused by ResponseError('too many 502 error responses'))
Is anyone else running into this?

It looks like this was transient.

This was rectified on the Notion side, for now.


fix: openapi docs for staking endpoint

Checklist

[x] My change requires a documentation update, and I have done it.
[x] I have filled out the description and linked the related issues.

Description

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

This PR is an extension of #3365
Screenshots (if appropriate):

Please, indicate the Open API version number changes in the PR description:
Swarm.yaml: <majon,minor,patch,none>
SwarmDebug.yaml: <majon,minor,patch,none>
SwarmCommon.yaml: <majon,minor,patch,none>

See: #3344

Please, indicate the Open API version number changes in the PR description:
Swarm.yaml: <majon,minor,patch>
SwarmDebug.yaml: <majon,minor,patch>
SwarmCommon.yaml: <majon,minor,patch>

See: #3344

done


Update Readme for demo app setup steps

Update Readme for demo app setup steps
Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

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

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Opened to the main repo directly.


[LIVY-587] Remove unused guava dependency

What changes were proposed in this pull request?
Guava was unused any more, and it's too heavy to include, so remove the guava dependency.
How was this patch tested?
Existing unit tests.

Integration test is failed, I think it is due to the removal of guava, please check and fix.

Codecov Report

Merging #181 into master will decrease coverage by 0.03%.
The diff coverage is 75%.

@@             Coverage Diff              @@
##             master     #181      +/-   ##
============================================
- Coverage      68.6%   68.56%   -0.04%
  Complexity      904      904
============================================
  Files           100      100
  Lines          5666     5669       +3
  Branches        850      851       +1
============================================
  Hits           3887     3887
- Misses         1225     1227       +2
- Partials        554      555       +1

Impacted Files
Coverage Δ
Complexity Δ

...e/livy/server/interactive/InteractiveSession.scala
69.11% <ø> (ø)
44 <0> (ø)
:arrow_down:

...ala/org/apache/livy/utils/LineBufferedStream.scala
80.48% <75%> (-1.1%)
5 <0> (ø)

...cala/org/apache/livy/scalaapi/ScalaJobHandle.scala
52.94% <0%> (-2.95%)
7% <0%> (ø)

...main/scala/org/apache/livy/server/LivyServer.scala
34.97% <0%> (-0.99%)
11% <0%> (ø)

...c/main/scala/org/apache/livy/repl/ReplDriver.scala
33.33% <0%> (+2.56%)
7% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

@jerryshao Integration tests and Unit tests all succeed.

Close the PR to retest it.

Merging to master branch. Thanks for the fix.


Fix types for cellSelection

Closes https://github.com/ProseMirror/prosemirror-tables/issues/159

Hi @ocavue , thanks for reopening maintenance.
I am having trouble with CellSelection not applying to setSelection() and would like to incorporate this patch.
I have imported the latest master branch and would like you to review it.


Test case to test kdump over network and different smt levels.

This test covers kdump over ssh, nfs and dump with different smt levels.
Signed-off-by: Pavithra<EMAIL_ADDRESS>

Will raise new PR after addressing given comments, closing the PR.


Not enough witness outputs

re lncli openchannel node_key=03da1c27ca77872ac5b3e568af30673e599a47a5e4497f85c7b5da42048807b3ed  --local_amt=450000 --push_amt=0 --connect=<IP_ADDRESS>:9735
[lncli] rpc error: code = Unknown desc = not enough witness outputs to create funding transaction, need 0.0045 BTC only have 0.000639 BTC  available
bitcoin-cli getbalance
0.01041585
... All transactions have min 30 confirms at this point? Tried a reboot of lnd .. no joy :(

lnd can only use funds from its own wallet. You'll need to transfer them there and then open the channel.


Hardcoded values

There are hardcoded values scattered all around the code, which might pose issues later regarding responsiveness. Examples:
Hardcoded sizes (of a shadow in this case) in pixels, rem or the like should rather be used: https://github.com/codidact/co-design/blob/develop/src/_modals.scss#L22

Absolute length units are not recommended for use on screen

See W3Schools for details.
Hardcoded ratio (of a modal body, which can only have 2/3 of the modal's width, which will lead to trouble on mobile devices): https://github.com/codidact/co-design/blob/develop/src/_modals.scss#L62

I'll review this later/tomorrow and fix some of these things.
However, at least the last point is not a problem:

If the modal body exceeds that height, scroll bars appear.
On mobile, the modal body spans the whole height, due to this rule: https://github.com/codidact/co-design/blob/c969990dc246e4db361356b8ca86d14540854d34/src/_modals.scss#L115


[simplify-cfg] When moving cond_fail to preds, do not bail early.

What's in this pull request?

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

This commit fixes a bug where we were not checking that all predecessors had the
cond_fail block as its only successor. This occured since we were bailing early
when we saw a constant. So if we saw a predecessor with a constant before a
predecessor that had multiple successors, we would optimize even though we would
be introducing an extra cond_fail along a path.
I added a new utility pass to test this code since so much is going on in
SimplifyCFG that it is difficult to construct a test case running the full
pass.
Really this code should be in a different pass (properly SIL Code Motion TBH).
But for now, this commit just fixes the bug.
rdar://26904047

@swift-ci Please smoke test and merge

@swift-ci Please smoke test and merge


IOptions not required in classes using POCO options class

Problem
Currently, using the IOptions<TOptions> pattern requires that the class using the TOptions have a dependency on IOptions<TOptions> rather than TOptions. This forces the class to have a dependency on Microsoft.Extensions.Options.  This is not desirable for classes that could be used outside of ASPNET Core classes or apps.
Ideally, the class should only be dependent on the TOptions POCO class.
Solution
By adding a
services.AddSingleton<TOptions>(sp => sp.GetRequiredService<IOptions<TOptions>>().Value);

After each
services.AddSingleton<IConfigureOptions<TOptions>>(new ConfigureOptions<TOptions>(configureOptions));

This allows the ServiceProvider to resolve TOptions to a correctly initialize instance of TOption when used in an ASPNET Core app, and to an manually initialized instance in cases where the ASPNET Core Dependency Injection and Configuration is not used.
`

Hi @matthewDDennis, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;

@matthewDDennis, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, DNFBOT;

The thing you mention as the problem is part of the design. If you don't want to depend on options then don't use this project. There's a standalone configuration binder that can give you what you need. You can also avoid the dance around registering a callback and register the poco object however you like.
The intent of IOptions is to have some indirection so the pattern of IConfigureOptions can be used to compose different component setting options.
For that reason I'd reject this change as it goes against the intended design.

This proposal does nothing to change the use of IConfigureOptions to compose options.
All it does is prevent the need to pass in an IOptions<TOptions> in the constructor of the consuming class, only to reference the value property.
By registering a service for TOptions as sp => sp.GetRequiredService<IOptions<TOptions>>().Value all the goodness of the current functionality for configuring the options values is still used.  When the TOption is resolved from the ServiceProvider, the IOptions<TOption> implementation OptionsManager is still created with the IEnumerable<Action<TOption>> collection of register setups.
All my simple change does is

Eliminate the need to pass in an IOptions<TOptions> in the consuming class' constructor, only to get the Value.  This is accomplished by moving the accessing of the value from a IOptions<TOptions> passed to the class, to the DI container with an ImplementationFactory for the TOption which just gets the value from theOptionsManager(the IOptions<>  implementation)
Eliminate the dependency of the consuming class on the IOptions interface and all its dependencies.

The consuming class doesn't need or care about IOptions, only the TOptions value.  Passing in an IOptions is leaking implementation details that the consuming class should not need to know about.
However, if you have a current implementation the uses IOptions<TOption> as the constructor dependency, the code will still work, as this change does not change any of the existing service registrations associated with the Options, only adds one more registration that allows the constructor dependency to be an instance TOptions class, without the need for accessing the Value property.

I understand the change I just don't agree with it nor do I think it should be in the box.

Eliminate the need to pass in anIOptions in the consuming class' constructor, only to get the Value. This is accomplished by moving the accessing of the value from a IOptions passed to the class, to the DI container with an ImplementationFactoryfor the TOption which just gets the value from theOptionsManager(the IOptions<> implementation)

Eliminate the dependency of the consuming class on the IOptions interface and all its dependencies.

I think that is a non goal of this project. If you want that then like I said, add the factory yourself or add the poco directly. IOptions<T> isn't meant to replace that.

/cc @lodejard @divega @HaoK For their thoughts

Your call, but thinking it over, I realize that the IOptions interface is only required in the internal implementation to provide a means to allow multiple steps of configuration to be execute the **first **time the TOptions value is requested.  There is no benefit to the consumer of the TOption to be passed an IOptions at all.  It only increases the complexity (very slightly to be sure), and adds an unnecessary dependency which is not small.  In most cases, an class of options should only be dependent on System as the properties are only int, bool, string, TimeSpans,  or other simple types.
Don't get me wrong, I think the Options design and implementation is amazing, and makes configuring a system extremely flexible and easy.  It just seems like you ran 99 yards, and stopped at the 1 yard line.

Others have also tried to explain this issue. See issues #82 and #31.

Now that there is nothing useful on the IOptions interface (RIP NamedOptions) other than the Value, I agree that it would be nicer to just take the Options class directly in ctors.  Even if we are just saving everyone from calling IOptions.Value, that seems worth considering if there's no loss in flexibility or functionality...
This also would have a nice benefit of letting us remove the options dependencies from several of our repos.

I was thinking in the same lines as @haok. With no named options in the picture and given the ability to register a Func<IServiceProvider,TService> in DI, I cannot think of a reason doing what is proposed in this PR would be wrong.
IOptions<T> still provides additional features, e.g. the lazyness (nothing happens until the first access to .Value) and potentially change notification if we end up merging that in, but for the most common usage depending on just the TOptions is rather nice.
The only reason I can speculate we wouldn't want this is if we decided that consuming options needs to be a bit more cumbersome than consuming any standard class just to make it clear at consuming time that they get created differently... But personally I see the seemlessnes of this proposal as a nice feature.

I was thinking in the same lines as @haok. With no named options in the picture and given the ability to register a Func<IServiceProvider,TService> in DI, I cannot think of a reason doing what is proposed in this PR would be wrong.

3 against 1! That's fine. I'd caution against using delegates by default, it's less performant than binding against types directly.

IOptions still provides additional features, e.g. the lazyness (nothing happens until the first access to .Value) and potentially change notification if we end up merging that in, but for the most common usage depending on just the TOptions is rather nice.

So what do we recommend to users and what do we do with our middleware? (for example). Writing code is easy, looking at the impact is what I'm having a hard time with. Do we tell people to call Configure<T>(...) and then look for a T in their classes? What happens when we have change notification, is there a grow up story where you have to use IOptions<T> or is it basically just a lazy T?

Yeah, using the TOptions as a service instead of IOptions does break the graph each place it occurs. Even if it was available I think we'd still keep the IOptions interface in our own code for perf reasons...

Yeah, I think it would be something like a grow up story, e.g. we would tell customers to only use IOptions<T> if you need the extra stuff it provides.
BTW, I don't think the lazyness part has a big impact. I think it would go from "nothing happens until someone uses the value" to "nothing happens until someone resolves an instance of TOptions". Whether this was intended or not in most of our current usages we access the value in the constructor of the class that depends on IOptions<T>
Let me also clarify that for the time being change notification on options requires you to depend on yet another interface, but I see an opportunity to converge on a single interface (see #100).

I think if we take this change, this would be one big reason why we shouldn't collapse change notifications into IOptions.
It seems a bit weird that we would add this feature but not use it ourselves, are we sure the perf difference is large enough to not have one consistent usage pattern for options (IOptions would basically be buried if we switched to this pattern)

Sure we can keep using IOptions<T> in our own code. To @haok's point on the advantage of not having to depends on options, if we want it to be an even lighter weight dependency to have, we should consider moving the interfaces to an abstractions package.

@haok not sure I understand what you mean but we can chat offline.

It seems a bit weird that we would add this feature but not use it ourselves, are we sure the perf difference is large enough to not have one consistent usage pattern for options (IOptions would basically be buried if we switched to this pattern)

We should obviously measure but the delegate pattern is less efficient in general. You're basically hiding the dependency graph from the DI system. I'm worried about the concept count as well. You need to be able to describe to people why IOptions<T> exists and when it should be used.

Sure we can keep using IOptions in our own code. To @haok's point on the advantage of not having to depends on options, if we want it to be an even lighter weight dependency to have, we should consider moving the interfaces to an abstractions package.

Is options heavyweight?
/cc @DamianEdwards

Options is pretty light right now, it depends on only DI.Abstractions and System.Primitives (which is from the change notifications, so we could split that one out potentially)

Assuming we are able to switch to TOptions usage everywhere, the answer to when you should use IOptions is never right?  It becomes purely an implementation mechanism for how we were able to get all of the IConfigureOptions stuff to work...

Assuming we are able to switch to TOptions usage everywhere, the answer to when you should use IOptions is never right? It becomes purely an implementation mechanism for how we were able to get all of the IConfigureOptions stuff to work...

I don't see the point in keeping IOptions<T> if we go with this approach (assuming the performance doesn't suffer).

We need something we can call in the delegate :smile:

Well I guess we can remove it entirely if we want to explicitly depend on our implementation of OptionsManager<T> I guess...

Or we can keep it and say use IOptions<T> if you want the performance benefit :smile:

I dunno... Hiding the call to IOptions<T>.Value... Breaks the service graph and obfuscates where the T is coming from... The T is a model rather than a service after all... I got a really bad feeling about this...
After all we're in the middle of trying to remove GetService calls and factory delegates right now, aren't we?

I dunno... Hiding the call to IOptions.Value... Breaks the service graph and obfuscates where the T is coming from... The T is a model rather than a service after all... I got a really bad feeling about this...

That's my gut as well. It's like making removing IHttpContextAccessor and instead using a delegate to represent injecting the HttpContext directly, it smells bad.

After all we're in the middle of trying to remove GetService calls and factory delegates right now, aren't we?

Yap, because performance.
Can we agree that this should be an addon?

That is a good point about IHttpContextAccessor, as it seems like both of these should have the same behavior.  The code still read betters with direct injection since you can't do anything else with IHttpContextAccessor/IOptions...
Maybe just inject extension methods instead of directly doing it as part of Configure?
  services.InjectHttpContext();
  services.InjectOptions<TOptions>();

I'm still on the side of the fence that we don't do either - I think the point behind hiding the http context access or was that it is also a bad idea.
For example, if we hide the IOptions for end-users it'll look like the T is a service, and if they register the T class like they do any other service it'll work - but only for half of the consumers.
Imho, I don't think any good can come from wallpapering over how things really work with an illusion. After all, you are in reality still getting an IOptions.Value - if there's a real problem with that it's one thing - but I'm still uncomfortable with a purely cosmetic change that obfuscates and degrades the system...

I don't think there is a performance issue at all.  The delegate is registered as a Singleton, so it will be evaluated on first use and cached in the ServiceProvider.  It should actually be faster as there will no longer be a call to OptionsManager.Value.
I believe the DI code is compiling the delegates, so they should be fast.  If they aren't they should.  When writing Munq DI, I found this to be a major performance boost.  Basically, do the expensive stuff once and early, on registration if possible, and on first use if not.

re @lodejard
Isn't the main point of this change (if we make it opt in via a new Inject like method) to give developers the option to ask for this cosmetic behavior if they desire.  This is just sugar for making hiding these easier, unless you are saying that people should not be encouraged to hide this at all?

I'm with @lodejard on this change. It's something that can be trivially added to any change and I don't think we should do it by default.

I don't think there is a performance issue at all. The delegate is registered as a Singleton, so it will be evaluated on first use and cached in the ServiceProvider. It should actually be faster as there will no longer be a call to OptionsManager.Value.

Not quite, I don't have any numbers but creating a type is always faster than using a delegate registration.

Yeah, actually another issue could be if nobody calls Configure for a BlahOptions then an IOptions<BlahOptions>.Value dependency will return a default new BlahOptions(), but a BlahOptions dependency will be a missing service...
Urrr.... That said... It's true if IOptions<TOptions>.Value is for the immutable case always... At the risk of opening a whole new can of worms... We could consider changing the pattern to consider the TOptions class itself the service, and move away from the IOptions<TOptions>.Value altogether in favor of an options constructor pattern.
public class BlahOptions
{
    public BlahOptions(IEnumerable<IConfigureOptions<BlahOptions>> alterations = null)
    {
        if (alterations != null) foreach(var alteration in alterations)
        {
            alteration.Configure(this);
        }
    }
}

That way depending on BlahOptions as a service would actually be the correct thing to do all the time public class Blah { public Blah(BlahOptions options) {...} ... }. Down-side is that BlahOptions takes a boiler-plate constructor, the options POCO depends on IConfigureOptions interface, and must be registered as an .AddSingleton<BlahOptions>() service, but on the plus side there's no need for an OptionsManager<TOptions> or IOptions<TOptions> constructor dependency and it's slightly less magical how the system works.

I sort of like it, but I'd prefer combining/hiding the registration and boilerplate into a new services.AddOptions<T> which could setup a delegate to invoke the IConfigureOptions and register the result as a singleton all at once.  Its a bit more magical, but enables the POCOs to remain clean like today...

Well, the whole idea is to avoid the using the last resort features like delegate services and IServiceProvider.GetService. Those techniques should be used when there's literally no other way to accomplish a dependency in a declarative way - not as an alternative to having your actual dependencies declared as constructor arguments...

In that case, this has nudged me back towards IOptions.Value as the lesser of the two evils...
I really like being able to use any vanilla POCO Options class, and the fact that the new requirements for making options a service are in your face, it feels a lot more complicated...

Due to your concern about performance I decided to measure getting the IOptions<TOptions> and the TOptions from a ServiceProvider.  Measured each in a loop of 100000.  I used code from one of the tests.  Contrary to your expectations, the TOptions version takes half the time as the IOptions<TOptions> version.
Interestingly, the value returned is incorrect.  It appears that the
            services.Configure<FakeOptions>(config);

is not working.
I'm running RC1-update.
Results
IOptions.Value.Message has incorrect value of "Igetstompedaz"
FakeOptions.Message has incorrect value of "Igetstompedaz"
IOptions took 00:00:00.0292005
FakeOptions took 00:00:00.0150615
Do it again in reverse order
FakeOptions took 00:00:00.0150976
IOptions took 00:00:00.0276157
Press ENTER to exit
Code
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.OptionsModel;

namespace OptionsTest
{
    public class Program
    {
        public static void Main(string[] args)
        {
            const int NumLoops = 100000;
            Stopwatch stopwatch = new Stopwatch();

            // Setup the DI
            var services = new ServiceCollection().AddOptions();
            var dic = new Dictionary<string, string>
            {
                {"Message", "!"},
            };
            var builder = new ConfigurationBuilder().AddInMemoryCollection(dic);
            var config = builder.Build();
            services.Configure<FakeOptions>(o => o.Message += "Igetstomped");
            services.Configure<FakeOptions>(config);
            services.Configure<FakeOptions>(o => o.Message += "a");
            services.Configure<FakeOptions>(o => o.Message += "z");
            services.AddSingleton<FakeOptions>(sp => sp.GetRequiredService<IOptions<FakeOptions>>().Value);

            // get the FakeOptions to ensure the ServiceProvider has resolved and cached the results.
            var serviceProvider = services.BuildServiceProvider();
            var iopFake1 = serviceProvider.GetRequiredService<IOptions<FakeOptions>>();
            if (iopFake1.Value.Message != "!az")
                Console.WriteLine($"IOptions<FakeOptions>.Value.Message has incorrect value of \"{iopFake1.Value.Message}\"");
            var fake1 = serviceProvider.GetRequiredService<FakeOptions>();
            if (fake1.Message != "!az")
                Console.WriteLine($"FakeOptions.Message has incorrect value of \"{fake1.Message}\"");

            string message;
            stopwatch.Restart();
            for (int i = 0; i < NumLoops; i++)
                message = serviceProvider.GetRequiredService<IOptions<FakeOptions>>().Value.Message;
            var IOpTime = stopwatch.Elapsed;

            stopwatch.Restart();
            for (int i = 0; i < NumLoops; i++)
                message = serviceProvider.GetRequiredService<FakeOptions>().Message;
            var POCOTime = stopwatch.Elapsed;

            // and do it again in reverse order
            stopwatch.Stop();
            Console.WriteLine($"IOptions<FakeOptions> took {IOpTime}");
            Console.WriteLine($"FakeOptions took {POCOTime}");
            Console.WriteLine("Do it again in reverse order");

            stopwatch.Restart();
            for (int i = 0; i < NumLoops; i++)
                message = serviceProvider.GetRequiredService<FakeOptions>().Message;
            POCOTime = stopwatch.Elapsed;

            stopwatch.Restart();
            for (int i = 0; i < NumLoops; i++)
                message = serviceProvider.GetRequiredService<IOptions<FakeOptions>>().Value.Message;
            IOpTime = stopwatch.Elapsed;

            // and do it again in reverse order
            stopwatch.Stop();
            Console.WriteLine($"FakeOptions took {POCOTime}");
            Console.WriteLine($"IOptions<FakeOptions> took {IOpTime}");
            Console.WriteLine("Press ENTER to exit");

            Console.ReadLine();

        }
    }
}

Nice, I was just about to do this myself :)  So the delegate usage is faster than IOptions (which is using an open generic service)

@HaoK if you haven't already, could you try this micro-benchmark with our current bits to double check?
Anyway, I suspect the perf concern with delegate registration applies more to larger graphs of dependencies, e.g. activate a controller that depends on a few services them themselves depend on options. I also suspect that @matthewDDennis is onto something when he says that the service being a singleton will make a difference.

Interestingly, the value returned is incorrect.

Sounds like we could have a bug :disappointed:. @HaoK can you please take a look?

@matthewDDennis I was going to run something like this, feel free to rerun your benchmarks with these scenarios that don't have any of the test code that might muddle things up. @divega I can take a look, its likely some weirdness with the test though as this particular test is doing a bunch of weird stuff.
Scenario A: IOptions today unchanged with controller
public class OptionsA {
  public string Stuff { get; set; }
}
public class ControllerA {
    private OptionsA _o;
    public ControllerA(IOptions<OptionsA> options) { _o = options.Value; }
}

public void ScenarioA() {
 var services = new ServiceCollection();
 services.AddOptions();
 services.Configure<OptionsA>(o => o.Stuff = "Yes");
 services.AddTransient<ControllerA>();
 var sp = services.BuildServiceProvider();
 // measure this
 var controller = sp.GetService<Controller>();
}

Scenario B: Using this PR's behavior
public class OptionsB {
  public string Stuff { get; set; }
}
public class ControllerB {
    private OptionsB _o;
    public ControllerB(OptionsB options) { _o = options; }
}

public void ScenarioB() {
 var services = new ServiceCollection();
 services.AddOptions();
  services.Configure<OptionsB>(o => o.Stuff = "Yes");
services.AddTransient<ControllerB>();
 var sp = services.BuildServiceProvider();
 // measure this
 var controller = sp.GetService<ControllerB>();
}

Scenario C: Using this @lodejard 's pattern
public class OptionsC {
   public OptionsC(IEnumerable<IConfigureOptions<OptionsC> configs) {
       foreach (var c in configs) c.Configure(this);
   }

  public string Stuff { get; set; }
}
public class ControllerC {
    private OptionsC _o;
    public ControllerC(OptionsC options) { _o = options; }
}

public void ScenarioC() {
 var services = new ServiceCollection();
 services.AddTransient<ControllerC>();
 services.Configure<OptionsC>(o => o.Stuff = "Yes");
 services.AddSingleton<OptionsC>();
 var sp = services.BuildServiceProvider();
 // measure this
 var controller = sp.GetService<ControllerC>();
}

Scenario D: My hybrid approach
public class OptionsD {
  public string Stuff { get; set; }
}
public class ControllerD {
    private OptionsD _o;
    public ControllerD(OptionsD options) { _o = options; }
}

public void ScenarioD() {
 var services = new ServiceCollection();
 services.AddTransient<ControllerD>();
 services.Configure<OptionsD>(o => o.Stuff = "Yes");
 services.AddSingleton<OptionsD>(sp => {
    var o = new OptionsD();
    foreach (var c in sp.GetRequiredService<IEnumerable<IConfigureOption<OptionD>>>())
        c.Configure(o);
    return o;
 });
 var sp = services.BuildServiceProvider();
 // measure this
 var controller = sp.GetService<ControllerD>();
}

It looks like the error in the resolve value in my perf program may have been due to the version.  I pull down the sources and ran against them and got the correct value.

I ran some numbers with these 4 scenarios with a very basic controller/setup.
The obvious difference between today and all 3 options is the switch away from IOptions.Value, I'm guessing the large hit is purely based on the OptionsManager's EnsureLazyInitialized call in IOptions.Value.
It does confirm that there is indeed a (slight) perf difference as we expected from each pattern.
For Iterations = 50000000;
Perf Today: 18.8780305s
PerfPR: 12.1215447s
PerfLou: 11.9652762s
PerfHao: 12.377871s
Full test code below:
        private const int Iterations = 50000000;

        public class ControllerNow {
            public OptionsNow O;
            public ControllerNow(IOptions<OptionsNow> options) { O = options.Value; }
        }
        public class OptionsNow { public string Stuff { get; set; } }

        [Fact]
        public void PerfNow()
        {
            var services = new ServiceCollection();
            services.AddOptions();
            services.AddTransient<ControllerNow>();
            services.Configure<OptionsNow>(o => o.Stuff = "Whatever");
            var sp = services.BuildServiceProvider();

            // prime it once
            Assert.Equal("Whatever", sp.GetRequiredService<ControllerNow>().O.Stuff);
            var stopwatch = new Stopwatch();
            stopwatch.Start();
            for (var i=0; i< Iterations; i++) Assert.Equal("Whatever", sp.GetRequiredService<ControllerNow>().O.Stuff);
            stopwatch.Stop();
            Assert.Equal(0, stopwatch.Elapsed.TotalSeconds);
        }

        public class ControllerPR {
            public OptionsPR O;
            public string Stuff;
            public ControllerPR(OptionsPR options) { O = options; }
        }
        public class OptionsPR { public string Stuff { get; set; } }

        [Fact]
        public void PerfPR()
        {
            var services = new ServiceCollection();
            services.AddOptions();
            services.AddTransient<ControllerPR>();
            services.AddSingleton(s => s.GetRequiredService<IOptions<OptionsPR>>().Value);
            services.Configure<OptionsPR>(o => o.Stuff = "Whatever");
            var sp = services.BuildServiceProvider();

            // prime
            Assert.Equal("Whatever", sp.GetRequiredService<ControllerPR>().O.Stuff);
            var stopwatch = new Stopwatch();
            stopwatch.Start();
            for (var i = 0; i < Iterations; i++) Assert.Equal("Whatever", sp.GetRequiredService<ControllerPR>().O.Stuff);
            stopwatch.Stop();
            Assert.Equal(0, stopwatch.Elapsed.TotalSeconds);
        }

        public class ControllerLou {
            public OptionsLou O;
            public string Stuff;
            public ControllerLou(OptionsLou options) { O = options; }
        }
        public class OptionsLou {
            public OptionsLou(IEnumerable<IConfigureOptions<OptionsLou>> cs) { foreach (var c in cs) c.Configure(this); }
            public string Stuff { get; set; }
        }

        [Fact]
        public void PerfLou()
        {
            var services = new ServiceCollection();
            services.AddTransient<ControllerLou>();
            services.AddSingleton<OptionsLou>();
            services.Configure<OptionsLou>(o => o.Stuff = "Whatever");
            var sp = services.BuildServiceProvider();

            // prime
            Assert.Equal("Whatever", sp.GetRequiredService<ControllerLou>().O.Stuff);
            var stopwatch = new Stopwatch();
            stopwatch.Start();
            for (var i = 0; i < Iterations; i++) Assert.Equal("Whatever", sp.GetRequiredService<ControllerLou>().O.Stuff);
            stopwatch.Stop();
            Assert.Equal(0, stopwatch.Elapsed.TotalSeconds);
        }

        public class ControllerHao {
            public OptionsHao O;
            public ControllerHao(OptionsHao options) { O = options; }
        }
        public class OptionsHao { public string Stuff { get; set; } }

        [Fact]
        public void PerfHao()
        {
            var services = new ServiceCollection();
            services.AddTransient<ControllerHao>();
            services.AddSingleton(s => {
                var o = new OptionsHao();
                foreach (var c in s.GetRequiredService<IEnumerable<IConfigureOptions<OptionsHao>>>())
                    c.Configure(o);
                return o;
            });
            services.Configure<OptionsHao>(o => o.Stuff = "Whatever");
            var sp = services.BuildServiceProvider();

            // prime
            Assert.Equal("Whatever", sp.GetRequiredService<ControllerHao>().O.Stuff);
            var stopwatch = new Stopwatch();
            stopwatch.Start();
            for (var i = 0; i < Iterations; i++) Assert.Equal("Whatever", sp.GetRequiredService<ControllerHao>().O.Stuff);
            stopwatch.Stop();
            Assert.Equal(0, stopwatch.Elapsed.TotalSeconds);
        }

I agree that injecting SomeOptions directly would be nice. This would remove the need to reference any Options-package for most libraries. However I also agree that injecting regular objects is a little bit weird.
Would it help somehow to move the dependency from the service to the Options POCO? SomeOptions could have to implement a marker interface (ideally IOptions but this would be a big breaking change). The DI process and ConfigureOptions() could now verify that only objects implementing this interface are used for this. But since this still requires a dependency on the Options-package, I don't think that this would be an improvement.
This is also related to the question I just asked: Why no Microsoft.Extensions.Options.Abstractions? (sorry for not reading this PR first). I think the package structure is not consistent with other Extensions-projects. In case we have to keep the IOptions<TOptions> usage, it would feel better to me to have a dependency on an Abstractions package with no other dependencies at all. Most libraries don't care about the actual implementation of the Options system. This way it would be similar to injecting an ILoggerFactory and so on.
This would also remove the need to have the Microsoft.Extensions.Options.ConfigurationExtensions-package. Instead, we would just have Microsoft.Extensions.Options and Microsoft.Extensions.Options.Abstractions.

@HaoK Your tests are using AddTransient instead of AddSingleton for the TOption.  This will make a difference in your measurements.  I think Singleton is the more likely pattern to use here, unless you are working with auto reloading on config file changes.

BTW, I just did a performance comparison of Munq DI with the ASPNET Core DI.  Surprisingly, the ASPNET DI came out slightly faster, and has better error checking for cyclic dependencies. I am impressed.
Not sure why someone would want to use Autofac or Structuremap instead based on performance numbers.  Granted, there are a few features they have that aren't in the ASPNET DI, but I really don't think that they are important in a properly designed system.

@matthewDDennis I wanted the controllers to be transient, the options are registered as singletons.  If both were registered as singletons, I would hope all of these tests end up close to identical times after this many iterations...

One other nice benefit of treating Options as a service would be letting us normalize Configure<T> into => AddOptions<T> like the rest of our frameworks...
 // Just registers the MyOptions singleton
services.AddOptions<MyOptions>()

// Register the options singleton and configure it
services.AddOptions<MyOptions>(options => options.Setting = "Whatever"); //

Thanks for this PR, we discussed this today and are going in a similar direction with the following changes outlined here: https://github.com/aspnet/Options/issues/122


Let users store and use custom CSS  per page

[ ] Generate 3 CSS presets for a specific UI each, the user can choose from one them in a drop down which include an additional choice "Other" that open the possibility to upload your own CSS file
the presets can be uploaded as medias on Sections website project and we use the links from there
We could simplify things and define as many presets as we want through env variable by putting a json made of the preset name and the url to the file That way we could edit the presets on the go
The file name is the name of the preset
You will read from this folder to show the existing presets in the drop down list
For each preset you choose you will have a link to download it
You can modify it and then use it to upload a custom css
[ ] Let users store and use custom CSS  per page
They will show in the user media library
[ ] Minify CSS

Acceptance testing

[ ] Have available a specific folder in amazone to store the presets
[ ] The file name of the preset should be the name of the preset
[ ] From the site you will have a drop down list to select one of those preset that will be applied to the site
[ ] When selecting a preset I must have a link to download the css file
[ ] From the drop down there will be a choise "Other" and if selecting it you can upload your own css file that will be stored in your media library only and that will be applied to the site
[ ] Check the site you are testing on using this tool https://pagespeed.web.dev/ for mobile and desktop

The 3 CSS presets for a specific UI each are for what exactly ? Themes for section controls in Admin edit mode ?
The idea is clear however this needs more elaboration and grooming to be done correctly and the updates needed on the library are quite big to support this feature as we are going to change the way css is currently set to have specific classes per elements, a part of this was done in the cname update.
I can't give a correct estimation for this one but I can give a range of 5-8h

After discussion with Julien:
The goal is to rely on tailwind configs to speed up the setting of some styles.
But to also allow feeding custom css styles too.

Define the standard as part of the preset+custom css feature in the nuxt-sections Library (document it)
⚠ Do not reinvent the wheel and rely on the standards provided by tailwind

Implement the standard in 1. inside the sections that ship with the vue-cli-plugin

Create presets following the standard (a preset will work the same way as a custom css it's just that it's made available to use out of the box to users)

Create a custom css that follows the standard too

The presets can be uploaded as medias on Sections website project and we use the links from there
We could simplify things and define as many presets as we want through env variable by putting a json made of the preset name and the url to the file
That way we could edit the presets on the go

@akramsarkis

Just for now as I don't have access to sections website prod, I have uploaded the presets on sections dev as Preset 1, Preset 2, Preset 3. Please do not update these files directly

For your QA use the sections of blogs as they are the ones that are following the css Tailwind rules standards and skip the other sections that are for sections website which will be removed later

You can use the page I was using that is /blogs

@mahfouzhseineweev please find below my feedbacks

[ ] When I select a preset and I save my settings, I am required to refresh my page to see the changes, they should see directly after saving my settings
[ ] When I select a preset and I click on export nothing is happening

@jfayad all good but there is just the comment above about Preset1 if you can check it, for the other preset I can export them without any problem.
For now Hussein put them as static as you were not there to add them as env variable, he will adjust it once you are there

@mahfouzhseineweev when adding a custom css (or using a preset) how is the impact on the performance ?

@jfayad  For the presets, I used main standard classes that will not affect the performance and they just override existing Tailwind classes (colors, fonts etc...)
For the custom css uploaded, it will depend on the content of the CSS, and if these CSS classes are used in the page or not. If they are not used it will increase the Unused CSS but according to page speed it wont have a noticeable impact unlike the unused scripts and the large containtfull painting

noted, LGTM

@mahfouzhseineweev  you are using a  fetch type when downloading a preset file which is causing the CORS from amazon , you need to checj what you can use maybe Get in instead of Fetch

@akramsarkis But then why would it work for a file and not for another ?

@akramsarkis But then why would it work for a file and not for another ?

Well @mahfouzhseineweev  no idea but this is Julien that mention this , I just added it there

@mahfouzhseineweev make sure the user can also choose to not have any preset nor custom css file on his page

All good, closing


Wrong size limit in gcm.c

Hi,
I'm trying to en/decrypt a large file (>70MB) with the AES-128-GCM algorithm. Unfortunately I get the error MBEDTLS_ERR_GCM_BAD_INPUT for files larger than 67 108 832 Bytes (0x03FFFFE0).
As far as I understood, in GCM Mode, the plain data (data to be encrypted) is limited to (2^39-256) bits (FFFFFFFE0), which is something like 68GB. I found these line of code in gcm.c:362 which are raising the error:
/* Total length is restricted to 2^39 - 256 bits, ie 2^36 - 2^5 bytes
 * Also check for possible overflow */
if( ctx->len + length < ctx->len || (uint64_t) ctx->len + length > 0x03FFFFE0ull ) {
   return( MBEDTLS_ERR_GCM_BAD_INPUT );
 }

This behavior can be reproduced with the executable in mbedtls-2.2.0/programs/aes
dd if=/dev/urandom of=file.plain bs=1024 count=70000;
crypt_and_hash 0 file.plain file.aes AES-128-GCM SHA1 hex:E76B2413958B00E193
mbedtls_cipher_update() returned error

Thanks and regards Andreas

ARM Internal Ref: IOTSSL-557

Thanks for your report, and sorry for not replying earlier (I thought I did, but apparently not). This will be fixed in a future release.


A small bug in tutorials/mnist/mnist_with_summaries.py

Please fix the bug in Line 85 of file tensorflow/tensorflow/examples/tutorials/mnist/mnist_with_summaries.py
the code
writer = tf.train.SummaryWriter(FLAGS.summaries_dir, sess.graph)
should be changed to
writer = tf.train.SummaryWriter(FLAGS.summaries_dir, sess.graph.as_graph_def()),
otherwise there will be an error  'Graph' object has no attribute 'SerializeToString'

I look at the history of this file and find that the line 85 is changed to fit for the new API, which is somehow not consistent with the API in 0.7.1. Maybe some comments  here should add in this file as it is linked in the tutorial of the official website.

The link from the website actually points to the r0.7 version of the branch: https://github.com/tensorflow/tensorflow/blob/r0.7/tensorflow/examples/tutorials/mnist/mnist_with_summaries.py, so I'm not sure what else we can do here -- it is generally recommended (for all software), to match the binary install you are using with the branch that matches it.


Update email list links and addresses to the new ASWF groups.

I think I included that already? Is it a different file than the one listed in https://github.com/imageworks/opencue.io/pull/41/files ?

Sorry, my mistake. That's the one, so LGTM and thanks again. Glad to see other contributors to this repo!
Nothing you did, but this PR confused me a little as we've configured Netlify to auto-deploy PRs but there was no preview, so I think I got a little side tracked with that and missed that you had included the change. I'll investigate further about the previews and might ask someone to try creating a PR.

Happy to help debug more, let me know.


Update Error Handler

Updated ErrorHandler to allow custom ExceptionRenderers to be registered. Also add has() method to JsonBody.

Yes… I will definitely write tests, but I wanted to get the actual working code in so that my front end guys can test against the API.
On 26 Jan 2017, at 12:25, Sebastian Heuer <notifications<EMAIL_ADDRESS>wrote:
@belanur approved this pull request.
Please consider writing tests (can be added later)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/kartenmacherei/rest-framework/pull/2#pullrequestreview-18601213, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVsUNSuEVs4dyRxfn2S_gAz_3LY7D0luks5rWIKxgaJpZM4LudnY.


Security Policy is outdated

https://owncloud.org/security/policy/
This site could need an update. Consider putting this page into your release-todo-list.

@Peter-Prochaska

Update was in https://github.com/owncloud/owncloud.org/pull/1170
Thanks...


Fix: disable empty variable of VariableStyle

Currently styles will parse $:10 style class to
.\$\:10 {
    --: 10;
}

But empty variable property (--) is invalid in CSS so I change the regex to make sure variable name is not empty.

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Special list of imag's

We have tried several image's from the juniper vSRX 15.1 only the all freeze, with the console message
Wind River Linux <IP_ADDRESS> localhost console
INIT: Sending processes the TERM signal
Is there maybe a specific url for the right vSRX 15.1 image's?

There are a few things we need to know to help you out:
1: is this from the built in console in wistar, or from vish console, the web console will never show console, it has a challenge with transitioning from windriver to bsd. virsh console does work.
2: What OS/Version/Kernel
3: cat /etc/modprobe.d/qemu-system-x86.conf
options kvm_intel nested=1 pml=0
Make sure you have pml=0 that will often hang vSRX.

I've added a note to the tips and tricks document indicating tested version of 15.1 is media-vsrx-vmdisk-15.1X49-D60.7.qcow2. Let me know if we should add anything else here as well.

Can you please direct to the tips and tricks document. I am facing the same issue when I am trying to spin up a vSRX on an Ubuntu 14.04 Server/Desktop.

On Mon, Nov 20, 2017 at 7:08 PM pantanshul<EMAIL_ADDRESS>wrote:

Can you please direct to the tips and tricks document. I am facing the
same issue when I am trying to spin up a vSRX on an Ubuntu 14.04
Server/Desktop.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Juniper/wistar/issues/18#issuecomment-345873177, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKau1H6DK2vpPrjuFHHe3-zL17WtBNoMks5s4hSYgaJpZM4P-SP_
.

What issue exactly? Not sure we have anything formal.
But certainly can offer some assistance.

The issue is that when I am trying to spin up a vSRX on Ubuntu14.04...I am getting the following error:
Wind River Linux <IP_ADDRESS> localhost console
INIT: Sending processes the TERM signal
I have tried to use the following two vSRX images but I get the same error:
vsrx 15.1X49 D15.4
vsrx 15.1X49D110.4
I also read that this issue arises on an ESXi if a wrong Network Adapter is selected.
On the same lines, I am using the Virtual Machine Manager to spin up the vSRX and the vNIC setting on the VMM is as attached in the file.

try watching the boot with "virsh console" versus the vmm
the vsrx changes console from windriver to bsd and that plays poorly with
graphical consoles.
also make sure PML=0
cat /etc/modprobe.d/qemu-system-x86.conf
options kvm_intel nested=1 pml=0
On Tue, Nov 21, 2017 at 8:46 PM, pantanshul<EMAIL_ADDRESS>wrote:

The issue is that when I am trying to spin up a vSRX on Ubuntu14.04...I am
getting the following error:
Wind River Linux <IP_ADDRESS> localhost console
INIT: Sending processes the TERM signal
I have tried to use the following two vSRX images but I get the same error:
vsrx 15.1X49 D15.4
vsrx 15.1X49D110.4
I also read that this issue arises on an ESXi if a wrong Network Adapter
is selected.
On the same lines, I am using the Virtual Machine Manager to spin up the
vSRX and the vNIC setting on the VMM is as attached in the file.
[image: screen shot 2017-11-22 at 12 41 01 pm]
https://user-images.githubusercontent.com/33849376/33105773-036ffff6-cf83-11e7-9675-97c347eaa43e.png
[image: screen shot 2017-11-22 at 12 44 38 pm]
https://user-images.githubusercontent.com/33849376/33105783-0f8a762c-cf83-11e7-8b06-86f1cb201e9d.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Juniper/wistar/issues/18#issuecomment-346217832, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKau1JcY0qk5RC1nvYLiHVjc7pL1piHRks5s43zagaJpZM4P-SP_
.

Connection to console is getting refused. Also my initial setting has always been pml=n.

I may be mistaken, butt pretty sure PML=0 or PML=1, not n
as for virsh console,
in your virsh list, type virsh console  so either virsh console 25 or
virsh console vsrx
On Tue, Nov 21, 2017 at 10:02 PM, pantanshul<EMAIL_ADDRESS>wrote:

Connection to console is getting refused. Also my initial setting has
always been pml=n.
[image: screen shot 2017-11-22 at 1 53 53 pm]
https://user-images.githubusercontent.com/33849376/33107972-cb4a0512-cf8d-11e7-932b-ec0956669873.png
[image: screen shot 2017-11-22 at 2 00 20 pm]
https://user-images.githubusercontent.com/33849376/33107973-cb7718b8-cf8d-11e7-895c-0663883a4a8b.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Juniper/wistar/issues/18#issuecomment-346229452, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKau1IdpJDMFqejACwUl_KLolgG_jNqfks5s447ggaJpZM4P-SP_
.

Ok...my PML=n but when I try to get in to virsh console , I am able to log in to the vSRX and can see the baseline config...does this mean that this issue is just of the graphical consoles and the vSRX has spun up correctly?

correct. graphical consoles are busted.
it has to do with 2 'unix' nested vm and some reason why we do not
transition the console correctly.
On Tue, Nov 21, 2017 at 10:25 PM, pantanshul<EMAIL_ADDRESS>wrote:

Ok...my PML=n but when I try to get in to virsh console , I am able to log
in to the vSRX and can see the baseline config...does this mean that this
issue is just of the graphical consoles and the vSRX has spun up correctly?
[image: screen shot 2017-11-22 at 2 25 00 pm]
https://user-images.githubusercontent.com/33849376/33108567-fa014ec6-cf90-11e7-8b1d-c59ed9b5fb31.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Juniper/wistar/issues/18#issuecomment-346232442, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKau1F8m2SROEzRAbXOOtpbcx3zV1N4pks5s45QsgaJpZM4P-SP_
.

Thanks...looks like it is sorted out for me :)

closing this one out for now.


⚠ ClamAV has degraded performance

In f67b93d, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 555 ms

Resolved: ClamAV performance has improved in 875cc9d after 15 minutes.


Update list of supported Linux distributions

Based on list of supported Linux distros (https://github.com/memgraph/memgraph/pull/1814) we need to:

Update direct download links
Update release notes

Closed with https://github.com/memgraph/documentation/pull/619.


Add a testing framework

Is your feature request related to a problem? Please describe.
It's not possible to publish this project to node.js as package by github automatically. The pipeline fails on not configured testing command: https://github.com/opendata-guru/peacock-user-ui/actions/runs/1880792149
Describe the solution you'd like
Add a testing framework. Add the test npm command. Add first and most important tests for this package.
Describe alternatives you've considered
Simple add a test command without functionality.

Vue Test Util are now installed: https://v1.test-utils.vuejs.org/guides/#getting-started
How to use? https://testdriven.io/blog/vue-unit-testing/


Add ingressClassName chart value

This PR adds the controller option ingress-class-name value in the Helm chart values.
The option was implemented here: https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/pull/1482

@vpbarb could you please help me understand why this was closed?
I'm currently having issues setting ingress class name and this looked like a solution, so I'm confused why this didn't make it. Is there an alternative way out there?

@vpbarb could you please help me understand why this was closed? I'm currently having issues setting ingress class name and this looked like a solution, so I'm confused why this didn't make it. Is there an alternative way out there?

@a-shkarupin I made this PR before the spark-operator maintenance was moved to Kubeflow. I waited for 3 months for some feedback and realized that it would not be merged. So I closed this. I ended up having a fork used internally for our company needs.


Add dots to hedgehog image

We removed dots from hedgehog to make image smaller.
But what if we will add extra layer with dots on top of SVG?

It is cool even without dots


TypeError: 'NoneType' object is not iterable

When removing an recursion I have a TypeError because it tries to add the None recursion.

closed with 118b84752e08ee6cbea77a5a4ee3d2064f034d54


Fix SkyDNS setup for helios-solo

In the default case of HELIOS_NAME being set to helios.solo. the
SkyDNS curl tried to access
http://<IP_ADDRESS>:4001/v2/keys/skydns//solo/helios

and got back a 301 Moved Permanently. Since curl doesn't follow that
automatically the DNS entry was never set.
Also SkyDNS was only set to be the authorative source
for "local." domain and in the default case the domain is "solo.".
The new approach should set things up correctly in the default case
and force a "local." domain in case the HELIOS_NAME is set without a
domain.

Current coverage is 48.09%

Merging #877 into master will not affect coverage as of 7238c9e

@@            master    #877   diff @@
======================================
  Files          271     271
  Stmts        12803   12803
  Branches      1644    1644
  Methods          0       0
======================================
  Hit           6157    6157
+ Partial        467     466     -1
- Missed        6179    6180     +1

Review entire Coverage Diff as of 7238c9e

Powered by Codecov. Updated on successful CI builds.

@negz @spotify/helios-team

looks ok to me but tagged some of the main authors for more feedback
(and thanks @deverant )

LGTM as well, but I'm not too familiar with this part of the code. @rohansingh Is the best to ask.

@deverant I can't find where HELIOS_NAME is defaulting to helios.solo. Could you point it out to me?
I updated this script recently to support the HeliosSoloDeployment Java implementation of Helios Solo. The update was necessary because the HeliosSoloDeployment uses a namespaced HELIOS_NAME like namespace.solo.local.
I had intended my change to cover the above HELIOS_NAME as well as solo.local. as set by helios-up, but I missed the place where we set HELIOS_NAME to helios.solo.

@negz Oops, maybe the HELIOS_NAME setup is a mismatch with some earlier version of helios. Can't see it in the current master at least myself either.
I guess that means the DOMAIN setup is not needed, but I think the curl to setup skydns records in etcd is still broken and needs fixing?

https://ghe.spotify.net/helios/spotify-helios-testing/blob/master/src/main/resources/helios-base.conf#L9
https://github.com/spotify/helios/blob/af0c71efcfef49b37eb99e0086fd4e1dab471cce/helios-integration-tests/src/test/java/com/spotify/helios/HeliosSoloIT.java#L95
I think service discovery inside Helios Solo could break if the SkyDNS domain is set to anything but .local due to the interaction with TemporaryJobs as configured by helios-base.conf above. SPOTIFY_POD and SPOTIFY_DOMAIN are set to to randomjobprefix.local in an attempt to namespace them to the relevant job. At least it would break for the HeliosSoloIT above. Not sure if others follow that convention.
All in all these interactions are super confusing and hurt my brain. :(

@deverant Wouldn't the curl to work as long as the HELIOS_NAME ends in .local?
messremb(negz@spotify-puppet)$ echo moo.solo.local.|python -c "import sys;h=sys.stdin.read().strip().split('.');h.reverse();print '/'.join(h)"
/local/solo/moo
messremb(negz@spotify-puppet)$ echo solo.local.|python -c "import sys;h=sys.stdin.read().strip().split('.');h.reverse();print '/'.join(h)"
/local/solo

Check my initial commit message, the URL has a double forward-slash and that, at least when I tested, returned 301 instead of doing anything meaningful.

Ahhh, the double slash breaks it? Gotcha.

I switched to VMWare Fusion based docker-machine this morning and have subsequently spent the last four hours trying to get a working Helios Solo to replicate this. I'm going to take a break before I throw my laptop out the window and look again tomorrow.

LGTM!

@deverant this should be available in helios-solo 0.8.753 now.


init() got an unexpected keyword argument 'do_basic_tokenize'

In the README, this line is written:
tokenizer = BertTokenizer.from_pretrained('bert-base-uncased', do_lower_case=True, do_basic_tokenize=True)

But when I execute it, I get this error:
__init__() got an unexpected keyword argument 'do_basic_tokenize'

Which version of pytorch-pretrained-bert are you using?
Can you give the full error message to see which call to __init__() is failing?
We should have the keyword argument here

I have the last version (0.6.1).
This is what I have on my computer:


Update/Add Docker image "azure-sql-edge:latest"

Tool name
Docker image => mcr.microsoft.com/azure-sql-edge:latest
Tool license
unknown
Add or update?

[X] Add
[ ] Update

Desired version
latest
Approximate size
No response
Brief description of tool
Docker image of azure sql edge.
URL for tool's homepage
https://hub.docker.com/_/microsoft-azure-sql-edge
Provide a basic test case to validate the tool's functionality.
¯\_(ツ)_/¯

Platforms where you need the tool

[ ] Azure DevOps
[ ] GitHub Actions

Runner images where you need the tool

[ ] Ubuntu 20.04
[X] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[ ] macOS 14 Arm64
[ ] Windows Server 2019
[ ] Windows Server 2022

Can this tool be installed during the build?
# FILE =  ./docker-compose.yml
# CMD = docker-compose up -d
version: "3.7"
services:
  db:
    image: mcr.microsoft.com/azure-sql-edge:latest
    volumes:
      - mydatabase:/var/opt/mssql
    ports:
      - 1433:1433
    environment:
      - ACCEPT_EULA=Y
      - SA_PASSWORD=P@ssw0rd

volumes:
  mydatabase:

Tool installation time in runtime
30 to 60 seconds
Are you willing to submit a PR?
sure :)

Hey @emn-dev!
Due to maintenance concerns and the fact that the image is easily and quickly added in runtime, we would not want to add it to the image.

@erik-bershel thanks for the speedy reply! I totally understand your comment. However, just curious... when it comes to pre-installed databases (https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md#databases) there is no Sql Server/Express/etc. Why does PostgreSQL or MySQL get to be pre-installed?


score-based diffusion models as density estimators

Is your feature request related to a problem? Please describe.
Score estimation has been introduced for SBI, see

Compositional score estimation, good for iid data: https://proceedings.mlr.press/v202/geffner23a.html
sequential score estimation, for NLE and NPE: https://openreview.net/references/pdf?id=anxDgYxrx

it would be great to integrate these approaches into sbi.
Describe the solution you'd like

Add score-based diffusion models as density estimators here: https://github.com/sbi-dev/sbi/tree/main/sbi/neural_nets/density_estimators
Add neural posterior score estimation as inference method, e.g., here: https://github.com/sbi-dev/sbi/tree/main/sbi/inference/snpe
add neural likelihood score estimation as inference method here: https://github.com/sbi-dev/sbi/tree/main/sbi/inference/snle
add the option of compositional score estimation for iid data.

(feel free to move the last three points to separate issues, or create individual PRs for each).

I would also be interested in doing this!

me too!

I am not part of the org yet, though would like to be assigned.

rough work plan for the "basic" components:

in neural_nets, something like a VectorFieldEstimator super class that is the generic class for specific subclasses, including ScoreEstimator and FlowMatchEstimator, corresponding to score matching (i.e., denoising diffusion model) and flow matching, respectively, with their specific losses
a VectorFieldSampler class in samplers that receives the VectorFieldEstimator and samples by, e.g., solving the ODE/SDE
a VectorFieldPosterior object in inference/posteriors/ that receives the VectorFieldEstimator and sets up a VectorFieldSampler to create the posterior distribution, similar to DirectPosterior

does this sound about right? (also @janfb, @michaeldeistler, etc.)

torchdiffeq seems to me like the most reasonable choice for ODEs in pytorch. It's also used in dingo!

I don't know how to link the branch to the issue here but it's in score_estimator


Add type and meteormethod for Meteor Methods

Ohi,
There is a fork around with the described abilities: https://github.com/rafaelcorreiapoli/meteor-delete-button/commit/01001aa1dae0d7d6673dbb06cf2ca0b1c75d0b1c
Could you please pull this feature in?

+1


Swapchain recreation - happens multiple times on resize

In the current implementation Daxa checks if the swapchain is out of date two times. FIrst in impl_swapchain.cpp when acquiring new immage, second in impl_device.cpp when presenting the image to the screen. I find this innitself a bit weird as I believe the check should be done only once per frame ( when acquiring the immage ).
In the provided examples a third check is done by the user via the use of glfw window resized callback. This in turn calls the recreation of the swapchain again (with wrong values - but they get ignored by the daxa implementation anyways so it has no effect).

I created some very crude logging into the console and I it gives pretty good hint as to what what happens. This is one of the frames that I logged when I was continually resizing the window:

Swapchain acquires the immage wihtout any problems
Draw() tries to present to the screen and present in impl_device.cpp detects swapchain out of date

impl_device.cpp calls impl_swapchain.cpp recreate() function recreates swapchain with dimenstions 1480 x 600

GLFW detects window resize with dimensions 1460 x 600 ( I believe GLFW is delayed here - note that I was continously expanding the window)
User application (main.cpp in mandelbrot in my case) calls  resize() located in impl_swapchain.cpp

resize() calls recreate()

recreate() overwrites the values provided by resize() by current PhysicalDeviceSurfaceCapabilities
recreate() recreates the swapchain with dimensions 1480 x 600

This is very interesting, to be sure. I will do some local testing now. I'd definitely like to get this resizing stuff sorted

So for anyone who sees this in the future, it actually turns out that swapchain recreation is an underspecified portion of the Vulkan spec at the moment, and the only way to "correctly" do it is to wait idle before creating a new one. Another note is that acquisition of the swapchain image actually is a call that does nothing because of some vendor stuff (more underspecified Vulkan), so it's not enough to rely on the swapchain being invalidated. So we force the user to prompt Daxa to recreate the swapchain if a window management event comes up that should affect it.


[FEAT] Add implementation of handle GET request

This pull request includes significant changes to the configuration handling and request processing in the web server. The most important changes include the addition of new configuration structures, enhancements to request handling classes, and updates to the configuration files.
Configuration Enhancements:

Added RequestConfig struct to encapsulate various configuration parameters for HTTP requests (include/config/RequestConfig.hpp).
Added new methods to ConfigHttpBlock to retrieve configuration values (include/config/ConfigHttpBlock.hpp, source/config/ConfigHttpBlock.cpp). [1] [2]

Request Handling Improvements:

Introduced ARequestHandler base class and implemented GetHandler for handling GET requests (include/kernel/ARequestHandler.hpp, source/kernel/ARequestHandler.cpp, include/kernel/GetHandler.hpp, source/kernel/GetHandler.cpp). [1] [2] [3] [4]
Created RequestHandlerManager to manage different request handlers (include/kernel/RequestHandlerManager.hpp, source/kernel/RequestHandlerManager.cpp). [1] [2]

Configuration File Updates:

Updated configs/default.conf to change root and index settings, and added a new location block for CSS files (configs/default.conf).

Miscellaneous Changes:

Removed unused #include <set> statements from configuration header files (include/config/ConfigGlobalBlock.hpp, include/config/ConfigHttpBlock.hpp). [1] [2]
Refactored RequestProcessor to include methods for setting up and retrieving request configurations (include/kernel/RequestProcessor.hpp).

These changes collectively enhance the flexibility and maintainability of the web server's configuration and request handling mechanisms.

The AI summary looks so useful XD

It looks good but it means nothing


clarifying database and RP queries in QUERIES.md

Merging for now and will update once we've had a chance to verify against release.


Add Phel syntax to Github

I did some research, and I found that github/linguist has the syntax for the languages in Github.
In their contributing file, you can find how to do this:  https://github.com/github/linguist/blob/master/CONTRIBUTING.md
The goal is to investigate and try this out.

We try only to add languages once they have some usage on GitHub. In most cases we prefer that each new file extension be in use in hundreds of repositories before supporting them in Linguist.

Spread the world and make a lot of repositories :laughing:

We try only to add languages once they have some usage on GitHub. In most cases we prefer that each new file extension be in use in hundreds of repositories before supporting them in Linguist.

Spread the world and make a lot of repositories :laughing:

I will close this ticket until Phel has enough usage.


Add [Aerogrudge] #personal GBEFEX…UO6UDL

Address: GBEFEXVXLIOKYUCROOL5DD5PFSQN65IO64N7JRTSLBEFPTSYFWUO6UDL
Tags: personal
Title: Aerogrudge
Requested by @aerogrudge

@Aerogrudge with over 7 million stellar wallets it is not possible to label them on the database of stellar.expert


new password hashing technique

Fixes #212.
This is quite risky! I think I've tested most of the cases (certfp, autoupgrade, creation of new accounts with the new code) but let me know if you think of any edge cases you want tested.
I implemented the Dropbox-style technique described on #212, but only for user passphrases, not for passwords that get hardcoded in the config file (i.e., the passwords used by PASS, OPER, and WEBIRC). This is a potential source of confusion. I don't have extremely strong feelings about this technique so I could rip it all out and use plain bcrypt everywhere if you think that's better.
The bcrypt cost used with user passphrases has been downgraded from 14 to 12; on my hardware, this takes the time cost of a hash check from 1 second down to 250 milliseconds.

Ignore this --- I broke webirc. I'll submit a new PR.

(Never mind, I pushed a fix and reopened this one.)


[Bug] Net::HTTP is returning 403 Forbidden on getting Apple Auth Keys

Bug report:

Expected Behavior:
Production Environment when verifying user identity, request to Apple Auth Keys should return 200 response code.
I tried to hit the same URL using RestClient and got 200 response code with the expected response body.

Actual Behavior:
Production Environment when verifying user identity, request to Apple Auth Keys is returning 403 Forbidden.

Steps to Reproduce:

Deploy a rails app
rails console
Net::HTTP.get(URI.parse('https://appleid.apple.com/auth/keys'))
Response code is 403

Version of the repo:
AppleAuth 1.0.0

Ruby and Rails Version:
ruby-2.7.1 rails-<IP_ADDRESS>

Hey, have you solved the issue? I am encountering this issue as well.

@Gnash-Obial
check your config/initializers/apple_auth.rb and make sure you escape the line brake:
config.apple_private_key = ENV.fetch('APPLE_PRIVATE_KEY', 'apple_private_key').gsub("\\n", "\n")

I also override the method by using RestClient to do this request as it does not require authentication:
module AppleAuth
  class UserIdentity
    private

    def apple_key_hash
      certificate = JSON.parse(response)
      matching_key = certificate['keys'].select { |key| key['kid'] == jwt_kid }
      ActiveSupport::HashWithIndifferentAccess.new(matching_key.first)
    end

    def response
      @response ||= RestClient.get(APPLE_KEY_URL).body
    end
  end
end


Simplify flexSize (+misc)

nvd3-behavior

drop getViewBox()
generateChart() / nv.addGraph() - bind function context to element to avoid that.
Use Polymer automatic node finding to find svg element
Bug: data is bound to global array, make instance-specific
Bug: margin is bound to global object, make instance-specific

nvd3-donut

NVD3/D3 latest versions does not seem to need to sync internal
height/width with <svg> height/width, drop attached
Camel case attributes such as viewBox gets lowercased with Polymer, needs to
be set with setAttribute() or similar but is not needed for now anyway.
Bind context in _chart default value function to avoid that
Add container id to containing div for uniformity

demo - nvd3-donut, nvd3-sunburst

Use iron-flex-layout classes to demo flexSize
Add demo instance for flexSize

bower.json

Add iron-flex-layout dependency

Thanks for the PR.
Before merging it, I like to know the followings:

Why we id="container" in donut and sunburst charts?
Since which version of the nvd3 we don't need to sync internal width/height? Should we update the nvd3 version in the bower.json?

Sorry I was confused about the id="container" stuff, dropped now.
The version mask in bower.json is fine, I think we needed it for 1.8.2 but I'm not sure.


Add image parameter passing to the BoxDecoration super constructor.

This PR adds an image parameter passing to the BoxDecoration super constructor.
Fixes: https://github.com/johynpapin/flutter_inset_box_shadow/issues/10

Hi @johynpapin, could you please take a look at this PR?

@chitochi thanks :)

Hello !
Thank you very much for this PR, I've just tested it and it works for me! :smile:
I'll try to publish a new version of the package as soon as possible.


Create km.json

Outline Client UI strings, translated into Khmer from Localization Sprint.

I signed the Google CLA as an individual contributor.


Analyzer: Add time-filtering functionality

This PR is meant as a proof-of-concept and is not necessarily production quality. It builds on both #119 and #121, only 5ace21f811df27adaf1ba403d97215d05e6cd1a7 contains new functionality compared to #121.
This PR introduces a new time-filtering functionality for analyzing link and vehicle data over a specified time window (t_seconds). This allows for more granular, time-sensitive analysis, which is particularly useful when evaluating the most recent simulation behavior.
Key changes:

Time-based filtering for data export:

Added an optional t_seconds parameter to several data export functions (link_to_pandas, vehicles_to_pandas, etc.), enabling filtering of data from the last t_seconds of simulation time.
This functionality is applied across link-level, vehicle-level, and area-based analyses, ensuring consistency in time-filtered outputs.

Updates to cumulative tracking in Link objects:

Modified how cumulative vehicle arrivals and departures are tracked. Each time step now records both the current time and cumulative count, allowing time-based filtering to function properly.

Enhancements to data structure for link travel times:

The link_to_pandas function now includes a t column, recording the simulation time for each data point. This is used to apply time-based filtering for link statistics like traffic volume, remaining vehicles, and travel times.
Similarly, vehicles_to_pandas includes time filtering, ensuring vehicle logs reflect only recent events.

Cumulative arrival and departure handling:

Adjustments were made to ensure cumulative vehicle arrivals and departures are correctly updated across multiple time steps and used in conjunction with the new filtering functionality.

These changes improve the flexibility of the analysis tools, allowing users to inspect the most recent simulation data without manually post-processing large datasets. The changes also maintain backwards compatibility by default, only applying time filters if the t_seconds parameter is specified.
Known bugs:

The total_travel_time is currently negative, starting around 0 and getting increasingly negative
The average_speed, as added in #121, starts now negative, and increases, in some cases it converges towards 0.

More validation of other numbers is needed, but other variables generally look good.
Part of #120.

While traffic volume, delays and vehicle density look reasonable, the vehicles remaining, total travel time and average speed don't (yet).

For some reason the traffic_volume_rows in are negative, which is df_links.loc[rows, "traffic_volume"] - df_links.loc[rows, "vehicles_remain"]).values

I think that's because vehicles_remain is too large and keeps increasing. That causes traffic_volume_rows to be negative, which makes total_travel_time negative, which filters out most average_speed values, since a total_travel_time > 0 is applied.
Hopefully that's the single underlying issues that when resolved will fix all symptoms.

should we close this PR?

Yes, succeeded by #130.


LLVM ERROR with avx2 instructions

when running "cargo test" on the following code with "rustc 1.24.0-nightly (1abeb436d 2017-12-27)" I get
LLVM ERROR: Do not know how to split the result of this operator!
extern crate stdsimd;

use stdsimd::vendor::*;
use stdsimd::simd::u32x8;

//Find minimum val within 3 registers and splat it to a new register
pub fn splat_min(v1: u32x8, v2: u32x8, v3: u32x8) -> u32x8 {
    unsafe {
        //across registers
        let mut min = _mm256_min_epu32(_mm256_min_epu32(v1, v2), v3);

        //within 128 bit halfs
        let mut tmp = _mm256_shuffle_epi32(min.into(), 0x4E).into();
        min = _mm256_min_epu32(min, tmp);
        tmp = _mm256_shuffle_epi32(min.into(), 0xB1).into();
        min = _mm256_min_epu32(min, tmp);

        //across 128 bit halfs
        tmp = _mm256_permute2f128_si256(min.into(), min.into(), 1).into();
        _mm256_min_epu32(min, tmp)
    }
}

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test() {
        let v1 = u32x8::new(0,1,2,3,4,5,6,7);
        let v2 = u32x8::new(8,9,10,11,12,13,14,15);
        let v3 = u32x8::new(16,17,18,19,20,21,22,23);

        assert_eq!(splat_min(v1,v2,v3), u32x8::splat(0));
    }
}

I'm having a similar issue with non-avx2 instructions - I think the issue is caused by calling an intrinsic in an assert! macro.
See here for another example of this issue.

I still get the error even if I remove the assert
#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test() {
        let v1 = u32x8::new(0,1,2,3,4,5,6,7);
        let v2 = u32x8::new(8,9,10,11,12,13,14,15);
        let v3 = u32x8::new(16,17,18,19,20,21,22,23);

        splat_min(v1,v2,v3);
    }
}

Here's a smaller example which I copied from the stdsimd test for _mm256_permute2f128_si256
The issue seems to be with _mm256_permute2f128_si256.
If get the error with
cargo run
but not with
cargo run --release
or by adding
#[target_feature = "+avx"]
Which mean's it's probably not going to compile to the right instruction anyway. But it would nice if it returned a more useful error if it shouldn't compile.
extern crate stdsimd;

use stdsimd::vendor::_mm256_permute2f128_si256;
use stdsimd::simd::i32x8;

fn main() {
    unsafe {
        let a = i32x8::new(1, 2, 3, 4, 1, 2, 3, 4);
        let b = i32x8::new(5, 6, 7, 8, 5, 6, 7, 8);
        let r = _mm256_permute2f128_si256(a, b, 0x20);
        let e = i32x8::new(1, 2, 3, 4, 5, 6, 7, 8);
        assert_eq!(r, e);
    }
}

@Cocalus last example is compiling main  with SSE, but unconditionally calling an AVX2 function in it so unless it is compiled with -C target-feature=+avx2 this example has undefined behavior. In --release LLVM probably just deduces that fn main() can only run in AVX2 targets (its UB otherwise) and just compiles it with AVX2 (which will work on AVX2 hosts).
In debug mode, main is compiled with SSE, and because i32x8 has a different ABI in SSE than in AVX2 this should trigger: https://github.com/rust-lang/rust/issues/44367 , why it triggers the LLVM error instead, I don't know (sometimes this works and crashes, sometimes it doesn't compile).
However, I don't understand why using #[target_feature = "+avx"] fn main() { ... } fixes this issue in debug builds. It should not, in particular, because i32x8 has also a different ABI in AVX than in AVX2, which should again trigger: https://github.com/rust-lang/rust/issues/44367
@alexcrichton ?

I was wondering why all the vendor functions were marked unsafe, I guess the requirement on the programmer is that they are only used a section of code where the relevant target features are enabled. It seems like it should be possible to statically check that _mm256_permute2f128_si256 is only called in a an avx enabled section of code, then a lot of unsafe blocks could be avoided. I'm might be missing other reasons the vendor functions are tagged as unsafe.
In my original code I had the splat_min as an inner function and I expected the target_feature to apply to everything within the function, including inner functions and closures. Which is apparently not the case. I haven't figured out the incantation to get closures to work. Though this could also be related to repr(simd) issue.
Using cargo run on this only produces the right answer for good. Notable there is no unsafe here.
#![feature(target_feature)]

extern crate stdsimd;

use stdsimd::vendor::*;
use stdsimd::simd::i32x8;

#[target_feature = "+avx,+avx2"]
fn main() {
    let x = i32x8::splat(0);
    let y = i32x8::splat(1);

    let bad = |a,b| {a+b};

    fn alsobad(a: i32x8, b: i32x8) -> i32x8{
        a+b
    }

    #[target_feature = "+avx,+avx2"]
    fn good(a: i32x8, b: i32x8) -> i32x8{
        a+b
    }

    #[target_feature = "+avx,+avx2"]
    let stillbad = |a,b| {a+b};

    let alsostillbad = |a,b| {
        #[target_feature = "+avx,+avx2"]
        {a+b}
    };

    println!("{:?}", bad(x,y));
    println!("{:?}", alsobad(x,y));
    println!("{:?}", good(x,y));
    println!("{:?}", stillbad(x,y));
    println!("{:?}", alsostillbad(x,y));
}

In general these are probably either LLVM bugs or otherwise consequences of https://github.com/rust-lang/rust/issues/44367 where we're mismatching enabled target features per function.

It seems like it should be possible to statically check that _mm256_permute2f128_si256 is only called in a an avx enabled section of code, then a lot of unsafe blocks could be avoided.

There is an RFC for that: https://github.com/rust-lang/rfcs/pull/2212


Restrict Access to Metadata Service by Default

Story
As a cluster administrator I want to provide clusters to my users which are secure by default and that don't leak any information that an attacker can use who is running code in the cluster. Access to the metadata service may compromise security as well as my leak information.
Motivation
Although we tell our users of the impact of the metadata service and how to prevent possible dangers they might forget or ignore the advice making their solutions potentially vulnerable. There is also a problem as the metadata service is located on different IP addresses (e.g. <IP_ADDRESS> on Alibaba, <IP_ADDRESS> on AWS and OpenStack, metadata.google.internal on google)  that our users cannot envision. In the interest of security by default we shall deny access to pods by default. A cluster administrator who wants to re-enable access to the metadata service can do so at his own risk.
Implementation Options
There are several options to shut down network communication with the metadata service that need to be evaluated prior to implementation. It is not possible to deploy a single or multiple network policies that would deny access to the metadata service. These are the options that have been discussed so far:

Use one of the following of a similar service to control to the metadata service:

https://github.com/jtblin/kube2iam
https://github.com/uswitch/kiam
https://github.com/GoogleCloudPlatform/k8s-metadata-proxy

Personally I doubt that this is a good idea as the main purpose of these services appears to be to provide some kind of credentials and to prevent access is only a minor functionality (if at all).

Use a Webhook to add a network policy whenever a new namespace is created.

This would include adding network policies for the kube-system and default namespaces at the time when the cluster is created. Deployment of this Webhook could be configured in the shoot manifest.

Deploy iptables rules during cloud init that deny traffic to the metadata service for pods

This is probably the easiest and most straightforward solution. As a downside however it would make it much more difficult for cluster administrators to remove these rules. This could be configured in the shoot manifest.

Deploy a Daemon set

It appears possible to deploy a deamon set that would start a pod on each newly created node. From this pod the iptables rules could be deployed once that prevent traffic to the metadata service from pods.

An approach we haven't thought of so far

...
Personally my favorite would be 2 above.
Notes

It is currently unknown whether the above mechanisms would prevent pods with hostNetwork=true to access the metadata service - we suspect not.
Keep in mind that the kubelet must be able to access the metadata service.

Acceptance Criteria

[ ] Knowledge is distributed: Have you spread your knowledge?
[ ] ´The investigation is documented and a reason is given for the selected approach
[ ] Limitations are documented
[ ] A new issue is created which describes the implementation approach

Since calico is used in Shoots, could the Calico's Global Network Policy Resource be an option:
https://docs.projectcalico.org/v3.1/reference/calicoctl/resources/globalnetworkpolicy
Note that the Global Network Policy is a Calico specific resource and won't work for any other kubernetes network implementations.

Wow, @bergerx, I didn't know of that, thank you, that may indeed be the solution for our Calico-run clusters!

@mvladev, @alban, @dkistner, @marwinski, @swapnilgm, @amshuman-kr would you agree as well, that this would be the simplest solution to restrict access to the metadata service the fastest?

@vlerenc @bergerx yes GlobalNetworkPolicy makes sense for the Shoot

I don't know, please reach out to @marwinski @alban and @schu.
The issue is closed because restricting access to metadata service from shoots is not part of Gardener core scope (consequently, not done).


GPIO port pin mask DT helper

Shorten a common pattern with a new helper. The non-inst version will be used in the nordic GPIO driver in a separate PR.

8: UC4 Line exceeds max length (109>72): " 's/GPIO_PORT_PIN_MASK_FROM_NGPIOS(DT_INST_PROP(([0-9]+), ngpios))/GPIO_PORT_PIN_MASK_FROM_DT_INST(\1)/'"

I'm going to ignore this, as I think it's best to record how such automated changes are made when possible.

added a commit on top that fixes up the cases that are embedded in macros.


Create user in auth_provider#after_authenticate

Addressing issue discussed here: https://meta.discourse.org/t/userauthtoken-error-when-trying-to-create-new-user-in-authprovider/57456/3
Reports of users not being able to sign in, seeing 	 ActiveRecord::StatementInvalid (PG::NotNullViolation: ERROR: null value in column "user_id" violates not-null constraint in logs:
/var/www/discourse/app/models/user_auth_token.rb:16:in `generate!'
/var/www/discourse/lib/auth/default_current_user_provider.rb:133:in `log_on_user'
/var/www/discourse/lib/current_user.rb:18:in `log_on_user'
/var/www/discourse/app/controllers/users/omniauth_callbacks_controller.rb:125:in `user_found'
/var/www/discourse/app/controllers/users/omniauth_callbacks_controller.rb:104:in `complete_response_data'
/var/www/discourse/app/controllers/users/omniauth_callbacks_controller.rb:63:in `complete'

selfie, tested locally


⚠ Processors has degraded performance

In 614dd82, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 345 ms

Resolved: Processors performance has improved in bfd7c93.


[Question] So...how much are you guys spending?

I wonder, how does this compare to other CDN providers in terms of cost?
I'ts nearly impossible to find any straight answer like "$0.04 / GB" for example.
There's that google calculator with a billion options that requires 3 astronauts to understand it.
So.
Is there anyone who actually used this on a site and got billed already? How much are they charging you?

Hello @Salamander3 - you may want to ask your question over on our WordPress.org forum at https://wordpress.org/support/plugin/wp-stateless
GitHub is primarily focused on developer discussions around improving the plugin and organizing new releases.


Standardize code style

In #1442 discussion we thought about the possibility of standardizing code style, I think it would make development easier as it helps with reading code, removes "useless" linter warnings and overall makes things more organized.
One of the main points in my opinion is at least standardizing indentation size, as in lax_numpy.py we have some places using indentation of 2 spaces and a few using 4 spaces.
I propose using yapf with the following .yapf.style file:
[style]
based_on_style = chromium
split_before_logical_operator = true
join_multiple_lines = true
column_limit = 100
split_before_named_assigns = false

I think the major reluctance among devs here to adopt yapf, (or black, etc.) is that nearly every python formatter out there tends to mutilate math-heavy code and causes a net -decrease- in readability, even though they might decrease linter noise.  They're all rather over-specialized on the conventions for webdev, systems code, etc.
That's not to say that stylistic consistency isn't a worthy goal to be pursued (e.g. consistent indentation...), but I've personally been sorely underwhelmed by the utility of automated python formatters in scientific code in the past, and typically have spent as much time fighting them as I have deriving any tangible benefits.  ...perhaps if there was an extremely "light-touch" configuration that only fixed obvious issues, it might be considered?  Any full chromium/pep-8 enforcement probably won't be welcomed at the moment.

Well we can add a .yapf.style file and customize what yapf will do, the configs I posted above for example already make it waste less vertical space by telling it to not split before names assigns. Probably adding rules that forbid it from splitting before arithmetical operators could help?
Can you test the config above and give me some feedback on it's effects?

I've become quite partial to black, which I find to produce nicer results than YAPF (at least, with Google's default settings). There are still (very rare) fail cases with poor formatting, but most of those are solved by splitting expressions manually into multiple lines. And it's really nice not to need to argue about code formatting anymore
Take a look at https://github.com/google/jax/pull/1449 if you're curious what this looks like on JAX. Probably the main downside is that you get one commit that changes literally every line in the Git history, but we still found it to be quite worthwhile for xarray.

So, I think this one has the problem of wasting too much vertical space as @skye pointed out, also it's using 4 spaces instead of 2 (which seems to be  the standard used in jax programs), and it seems black is not configurable.
Should I open a PR using my yapf configuration so we can compare them?

So, the yapf version looks more compact and we can customize the style. What do you think?


How to know if a device is already registered without calling Pushy.register to get the device token?

Hi! right now I have a secured app that allows the user to accept to receive notifications via pushy. When the user press the button "NOTIFY ME" i will call the Pushy.register and then save the user Id/device token pair in my database. Then when is needed i will send the notification to that user using the registered device token.
Now, I need to make a Settings page for this user. And show the options "DISABLE NOTIFICATIONS" if the device is already registered for that user.
How can I know if that device(browser) is already registered without calling the Pushy.register to get the device token?

Hi @marianolc,
Thanks for reaching out. We'd be glad to assist.
You can call Pushy.isRegistered() instead, as follows:
// Check if the user is registered
if (Pushy.isRegistered()) {
    // User is registered
}

To unregister a device from receiving push notifications:
// Unregister from notifications
navigator.serviceWorker.getRegistrations().then(function(registrations) {
    for(let registration of registrations) {
        registration.unregister();
    }
});

Please let us know if you have any further inquiries.


removes unnecessary reseeding and makes it optional altogether

fixes a minor bug and allows to set the seed only once

Thank you very much! :)

what about torch.manual_seed? I only see numpy.random.seed being set here.

I just left it there for legacy reasons, seeding shouldn't be done there IMHO.


Unable to setup

I'm unable to setup this app with the latest version. On the second screen I see the message "Seite konnte nicht geladen werden" (site could not be loaded).
When starting the app in the terminal, I get the following output:
nemo@Sailfish ~]$ harbour-quartermaster
[D] unknown:0 - Using Wayland-EGL
[W] unknown:9 - file:///usr/share/harbour-quartermaster/qml/harbour-quartermaster.qml:9:30: QML OverviewPage: Bi
nding loop detected for property "status"
[W] unknown:1283 - file:///usr/lib/qt5/qml/Sailfish/Silica/PageStack.qml:1283:13: QML AnimatedLoader: (file:///u
sr/share/harbour-quartermaster/qml/pages/wizard/WizardConnectionPage.qml:77:22: Cannot assign a value to a signa
l (expecting a script to be run)
EnterKey.onClicked: false
^)

Thanks for your report! It is fixed with version 0.2.5.

Thank you for fixing this so fast, it works now!


/ui2/cl_json inheritance issue

I'm getting errors when trying to inherit the standard JSON class /ui2/cl_json:

CLASS lcl_json_custom DEFINITION FINAL INHERITING FROM /ui2/cl_json.
  PUBLIC SECTION.

  PROTECTED SECTION.
ENDCLASS.
CLASS lcl_json_custom IMPLEMENTATION.

ENDCLASS.

But there are no errors, when I'm using this standard class in my code:

DATA ls_body TYPE sflight.

DATA(lv_json) = /ui2/cl_json=>serialize(
                                data           = ls_body
                                pretty_name    = /ui2/cl_json=>pretty_mode-low_case
                                numc_as_string = abap_true ).
WRITE lv_json.

yea, its not in the playground
when inheriting, abaplint needs to know the super class to do a proper syntax check. But it doesn't need it for a method call
dependencies can be added in abaplint.jsonc, either with a url or local to the repo,

We have added it to the dependencies and it works, thanks. @larshp you can just close this.


Other buttons in the header bar are not functioning properly

it seems they are blocked by the injected UI

this is resolved by https://github.com/sevensinjai/file-view-for-bitbucket/pull/7