The bouncy bubble example is not working

Taken from https://github.com/processing/p5.js/issues/3600

Nature of issue?

[ x] Found a bug
[ ] Existing feature enhancement
[ ] New feature request

Most appropriate sub-area of p5.js?

[ ] Color
[ ] Core/Environment/Rendering
[ ] Data
[ ] Events
[ ] Image
[ ] IO
[ ] Math
[ ] Typography
[ ] Utilities
[ ] WebGL
[x ] Other (specify if possible)

Which platform were you using when you encountered this?

[ ] Mobile/Tablet (touch devices)
[x ] Desktop/Laptop
[ ] Others (specify if possible)

Details about the bug:
The bouncy bubble example (https://p5js.org/examples/motion-bouncy-bubbles.html) is not working.
There is a problem in the class Ball declaration. In fact, in the constructor method the vx and vx attributes are declared as a local variables instead of class attributes.

p5.js version:
Web browser and version:
Operating System:
Steps to reproduce this:

Feature enhancement details:

New feature details:

I would like to take up this issue please

@mcuz Go ahead! Thanks.

@limzykenneth I have fixed issue and am doing preparation steps for pull request.  however when doing git rebase and running patches I am running into many conflicts.  how can I get help with this?
I initially started working through conflicts assuming that things might improve ... but it seems that as I move through the patches conflicts continue to arise ... and there are 1000 patches! :(

@mcuz If nothing is edited in those files which there probably shouldn't be there won't be any merge conflicts. If you still cannot resolve this, start from a fresh clone that is up to date with master and copy over the changes made to the bouncy bubble example only. Check git status to make sure only the example file is changed then commit the changes. You can then push the new changes to your fork and file a PR, no need to rebase.

thanks very much for that! I'll get working on it


newbie question: slow training on colab possible due to giant training set

First of all: thank you this lib makes getting your hands dirty much faster.
second:
I managed to get everything running in colab with a dataset i've created for doing sentiment analysis. I have quite a lot of data so i thought "why not throw a lot at BERT" then:
begin training using triangular learning rate policy with max lr of 2e-05...
Train on 195000 samples, validate on 76263 samples
Epoch 1/3
   416/195000 [..............................] - ETA: 51:10:26 - loss: 1.6178 - acc: 0.2404

As you can see i am training on 195'000 items and validating on 76263 items and the grand question now is Thats too much data right? cause i dont like the ETA up there: 51 hours!
And that is 51 hours on google colab with GPU support etc.

BERT is quite slow, since it is a large model with lots of parameters (see here).   Some options to address this:

It's possible to train BERT using a TPU instead of GPU (but, this not yet supported directly through ktrain).  See here for more information.  This requires using tf.keras instead of standalone Keras.  tf.keras will be fully supported in ktrain in the near future (experimental support exists now, but it is not well-tested).
Use ALBERT, which is a leaner version of BERT that was just released.  This isn't supported in ktrain yet, but maybe in the future
Use a smaller faster model in ktrain.   For text classification datasets, you'll sometimes find that the BERT performance boost is only about 1 to 3 percentage points in accuracy at most.   So, maybe you can live with a slightly lower accuracy of a model that trains fast?
You can try freezing some of the earlier layers (see learner.freeze method).  Note that I've only used this with image classification models and this has not been tried/tested specifically with BERT.

Like I said, option 1 and 2 is not available in ktrain right now, but probably will be in the future.
Another question you might ask yourself is whether or not you really need a training set that large.  Part of the power of pre-trained models like BERT and pre-trained ImageNet models in computer vision is that you can get away with using smaller training sets when fine-tuning.  If you train on a smaller sample and validate on the rest and get good results, maybe you don't need to train for that long.

Thank you @amaiya for a great and thorough answer. i will look into your proposals and i thank you for your time

In addition to @amaiya  brilliant tips, you could decrease your model train time by increasing the batch_size to whatever colab's RAM capacity supports. For example, I use batch_sieze=128 instead of default ktrain.text.bert with batch_size=6:
learner = ktrain.get_learner(model, train_data=(x_train, y_train), batch_size=128)
Another point which is really efficient is set GPU as runtime in colab instead of default mode (NONE/CPU). In fact, it speeds up your train approximately 8x~50x faster. Note that, you have to restart the colab runtime in order to apply that. However, I think you aware of that and you have activated it.


[0.8][styling] Should be able to mixin sibling properties

Given styles:
* {
  --base-stuff: { color: white; }
  --pretty-things: {
    mixin(--base-stuff);
    background-color: red;
  }

  .foo {
    mixin(--pretty-things);
  }
}

I would expect a <div class="foo"> to be red w/ white text, but currently it appears that the mixin(--base-stuff) is not inherited.

Ah doh, var() is a no go either

/sub

Css doesn't support nesting rules like this. If you put the .foo rule as sibling to the other one, I expect this to work. Another note, * has been replaced with :root.


Unable to verify a caller based on a public key

I'm struggling to verify a caller based on a public key. I generated a private key with openssl ecparam -name secp256k1 -genkey -noout -out identity.pem and a public key with openssl ec -in secp256k1.pem -pubout -out public.pem
I create an identity with let identity = Secp256k1Identity::from_pem_file(private_key_path)?; which gives me a principal of tvfic-z7h73-2yknr-uyp26-pru5d-bjfbs-3tdnz-mctcw-mkj5d-uecaw-aae
Based on the source code for Secp256k1Identity it looks like I need to provide a der-encoded public key to  Principal::self_authenticating:
https://github.com/dfinity/agent-rs/blob/391f38edc4c856660f052e3e29dff486367c1275/ic-agent/src/identity/secp256k1.rs#L71-L75
I'd prefer to support a workflow where users can copy and paste the contents of the public key PEM file, and based on how Secp256kIdentity is encoding the public key I found the following which seems to be exactly what I need:
https://github.com/RustCrypto/elliptic-curves/blob/078363da500b04a031bcefb41bd25363b7ce1df7/p256/tests/pkcs8.rs#L57-L63
This is what I'm doing but the public key fails to parse.
use ic_agent::identity::{Identity as _, Secp256k1Identity};
use p256::pkcs8::EncodePublicKey as _;

fn main() {
    let identity = Secp256k1Identity::from_pem_file(private_key_path)?;

    // This represents the caller as the canister sees it.
    let caller = identity.sender().map_err(|err| anyhow!(err))?;
    trace!("caller: {}", caller);

    // Below represents what I'm trying to do in a canister.

    let public_key = vec![
        "-----BEGIN PUBLIC KEY-----",
        "MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAERzzyM2WgleyVhRLy9UpXBg8UZkvRNCTY",
        "E7X4b0wxP8XED9VZpqKi0n+CBhh7Wgf1o/qCE64kxfzZSs9yOY95xg==",
        "-----END PUBLIC KEY-----",
        "",
    ]
    .join("");

    // Fails with `Error: crypto error`
    let public_key = public_key.parse::<p256::PublicKey>()?;

    let public_key = public_key.to_public_key_der()?;

    let principal_from_public_key = Principal::self_authenticating(public_key);
    trace!("principal from public key: {}", principal_from_public_key,);

    trace!(
        "caller matches principal from public key: {}",
        caller == principal_from_public_key,
    );
}

Lastly, I was quite confused about Secp256k1Identity vs BasicIdentity. BasicIdentity supports ED25519 so I tried to use that first, but I couldn't figure it out.
openssl on my machine didn't support that algorithm which I thought presented a barrier for people, and even then you'd get a v1 key which doesn't guarantee that the private key matches the public key.
Curious if ED25519 is still the better option.

p256 is the crate for secp256r1 keys, the IC uses secp256k1 keys which are provided by the k256 crate. Also, that vec![].join call produces a pem without newlines, which won't parse.

BasicIdentity could more descriptively be named Ed25519Identity. You're right that OpenSSL doesn't support it; that's one of the big reasons we support secp256k1 (the other being that Bitcoin uses it). But it is in a general sense better, which is why the IC primarily targets it.

Also, that vec![].join call produces a pem without newlines, which won't parse.

Thanks, .join("\n") was my intention 🤦♂

p256 is the crate for secp256r1 keys, the IC uses secp256k1 keys which are provided by the k256 crate.

Thanks again. I was using that at first but changed crates when I found the test I linked to and tried to verify that it worked the same on my system.

But it is in a general sense better, which is why the IC primarily targets it.

By "it" do you mean secp256k1?

You're right that OpenSSL doesn't support it

Just to clarify on this, apparently newer versions of OpenSSL support -algorithm ed25519 but asking people to upgrade might be asking too much.
I tried using ssh-keygen since that supports Ed25519 but apparently couldn't generate a key pair in a format that ring would allow me to convert to an Ed25519KeyPair, even when using -m PEM.
If you know how to make this work, I'd appreciate the insight.
Also dfx rejects v1 keys but that seems to be only because agent-rs doesn't parse them:
https://github.com/dfinity/agent-rs/blob/4245c49575a74db680ec5707f23892046101afee/ic-agent/src/identity/basic.rs#L42-L44
I'm not sure if it was a conscious decision to only support v2 keys with from_pkcs8 when from_pkcs8_maybe_unchecked is available.

For some reason, in my standalone example k256 = "0.11" was fine but in my canister k256 = { version = "0.11", features = ["pem"] } was required or I got this error:
let public_key = public_key.parse::<k256::PublicKey>()
                            ^^^^^ the trait `FromStr` is not implemented for `k256::elliptic_curve::PublicKey<k256::Secp256k1>`

It also looks like this may not work in a canister as-is since it appears to be trying to use getrandom and suggests enabling the js feature.
Not sure why randomness is even needed for verification so maybe I can turn off a default feature.
Will look into providing something like I did here if not: https://github.com/codebase-labs/ic-auth-tokens/blob/76113cbaa8b788b1989a9d5ef0868cdb12ee46af/crates/ic-auth-tokens/src/lib.rs#L75-L95

k256 = { version = "0.11", default-features = false, features = ["arithmetic", "pem"] }  seems to be sufficient.

the trait `FromStr` is not implemented

Sounds like you got that backwards - FromStr is only implemented if the pem feature is enabled, and isn't if it's disabled.

If you know how to make this work, I'd appreciate the insight.

The one we use for our tests, I generated in Rust via k256.

By "it" do you mean ed25519Identity or secp256k1?

Ed25519, especially for the speed.

If you know how to make this work, I'd appreciate the insight.

The one we use for our tests, I generated in Rust via k256.

Thanks. I thought that might be it. I was hoping for something that people would likely already have installed.

Thanks for all the help.
I'll make a PR to update the documentation with what was learned here.


Compact session conf and session var use spark's own

What changes were proposed in this pull request?
Why are the changes needed?
Does this PR introduce any user-facing change?
How was this patch tested?

:+1:


How do I setup a Mozilla IoT device

I've setup succesfully the bridge to ha-bridge i can see all the bridged devices but the on/off/dim/color state section is a mystery for me. I've searched in the faq between all the issues. But can't seem to get it to work.

Did you install the Mozilla IOT Gateway shown here https://iot.mozilla.org/gateway/ ?

Yes

Did you put in that information on the Bridge Control Tab for the Mozilla IOT gateway so it can bring up the helper?

Yes, I've successfully connected a hub, I can see the devices on the hub:

Let's say I want to add the Bulb, what do I fill in these fields:

I feel like a noob, usually I can figure stuff like this out, but now I don't know what I'm doing wrong. I also tried to use Postman and this example to see what is what. If I send the same command to through that then I get an error.

So basicly I'm stuck.

Alright so I got a little bit further. I found out that my property links were wrong so I now can successfully send commands through Postman without error's:
PUT http://gateway.local/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17/properties/17-17 contenttype: application/json
body: {"17-17":50} will set the bulb to 50%

But now i don't know what to fill in where in ha-bridge.
Here is all the info i got with the GET method:
{
        "title": "Bulb",
        "@context": "https://iot.mozilla.org/schemas",
        "@type": [
            "Light",
            "OnOffSwitch"
        ],
        "description": "Default-Model",
        "href": "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17",
        "properties": {
            "17-16": {
                "title": "On",
                "type": "boolean",
                "@type": "OnOffProperty",
                "description": "On",
                "links": [
                    {
                        "rel": "property",
                        "href": "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17/properties/17-16"
                    }
                ]
            },
            "17-17": {
                "title": "Brightness",
                "type": "integer",
                "@type": "BrightnessProperty",
                "unit": "percent",
                "description": "Brightness",
                "minimum": 0,
                "maximum": 100,
                "multipleOf": 1,
                "links": [
                    {
                        "rel": "property",
                        "href": "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17/properties/17-17"
                    }
                ]
            }
        },
        "actions": {},
        "events": {},
        "links": [
            {
                "rel": "properties",
                "href": "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17/properties"
            },
            {
                "rel": "actions",
                "href": "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17/actions"
            },
            {
                "rel": "events",
                "href": "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17/events"
            },
            {
                "rel": "alternate",
                "mediaType": "text/html",
                "href": "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17"
            },
            {
                "rel": "alternate",
                "href": "ws://gateway.local/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17"
            }
        ],
        "layoutIndex": 3,
        "selectedCapability": "Light",
        "iconHref": null,
        "id": "http://gateway.local/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17",
        "base": "http://gateway.local/",
        "securityDefinitions": {
            "oauth2_sc": {
                "scheme": "oauth2",
                "flow": "code",
                "authorization": "http://gateway.local/oauth/authorize",
                "token": "http://gateway.local/oauth/token",
                "scopes": [
                    "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17:readwrite",
                    "/things/homekit-CC%3A22%3A3D%3AE3%3ACE%3A31-17",
                    "/things:readwrite",
                    "/things"
                ]
            }
        },
        "security": "oauth2_sc"
    }

Once you hit build item and it goes to the screen with the details, just hit the save device at the top of the screen and then it adds it with the correct commands. It is then available the devices tab. The helper sets it up for you.

I've tried that, but it doesn't do anything. It sees the device, and if i click add, it doesn't work. I even tried to make it work like this with an bearer authorization like this one. I send both screenshots and logs:
Mozilla log:
HTTP response code was not an expected successful response of between 200 - 299, the code was: HTTP/1.1 400 Bad Request with the content of <<<Invalid property name>>>
But it is exactly the same as the Postman method I've send earlier

HTTP log:
On/Off Request failed with: [{"error":{"type":"6","address":"/lights/108","description":"Error on calling url to change device state","method_name":"/lights/108/state"}}]
Same as above

will need to take a look


how to run code coverage for this project

I have mentioned 'coverage' in karma.conf.js , however after running the grunt test , after opening the index.html under coverage folder , it shows nothing ,

@abhijt-zanak Currently we don't support test coverage, however, it is in the works, and there's a pull request that get's it prepped for the coverage that's coming soon.

indeed, I'll push that soon enough, it's already working for the client side here, just need to tied things up, stay tuned!

thanks for the info, I am looking forward.
@lirantal : as you mentioned it is working for client side, please let me know how to run for client side.

Code coverage has been addressed as part of MEAN.JS in this PR: https://github.com/meanjs/mean/pull/811


[e2e]: delegator-generic push main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/5634881775
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Sun Jul 23 06:13:54 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/5637291272
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Sun Jul 23 15:43:01 UTC 2023
Tests are passing now. Closing this issue.


Support for ASP.NET Core 3.0

What is the recommended way to use Castle Windsor with asp.net core 3.0? One place where it can integrated would be the generic host towards which asp.net core 3.0 migrated, probably using UseServiceProviderFactory
Using Castle.AspnetCore.Facility is no longer possible (or at least I didn't found out how) because Startup.ConfigureServices returning IServiceProvider is no longer supported by the framework and AddWindsor cannot be used anymore. Before I used to write something like this in Startup class
public IServiceProvider ConfigureServices(IServiceCollection services)
{
    container.AddFacility<AspNetCoreFacility>(f => f.CrossWiresInto(services));
[...]
    return services.AddWindsor(container,
        opts =>
         {
            opts.RegisterControllers(typeof(MyController).Assembly, LifestyleType.Transient);
         });
}

Probably worth getting together with @schwarzie2478 in #487.

I have the same problem.
I just don't understand if there's going to be a solution soon.
Can you please let me know?
Thanks!

As it seems it looks like a dead subject unfortunately since I don't think that AspNetCoreFacility has any active maintainers.
I've managed to make it work in a .net core 3.0 app by insourcing in my project some of the classes from ASP.NET Core Facility and modifying and eliminating some stuff which I did not need like Tag helpers support whose public APIs changed in the new .net core release. The code was in WindsorRegistrationHelpers.AddApplicationComponentsToWindsor called by extension method named AddWindsor. My app is providing only web apis so fortunately I needed to register only controllers with Windsor.

since I don't think that AspNetCoreFacility has any active maintainers.

@robertmircea correct, no active maintainers as I said in #487.

Thank you for the information

I was gone use Windsor in my core 3 application until i found this. Has any progress been made on this issue? Or are there alternative solutions to integrate windosr in core 3?

Here are two issues that I filed with Microsoft concerning integrating Simple Injector with ASP.NET Core 3:

Microsoft.Extensions.Hosting.Host creates hosted services too early
How to integrate non-conforming containers with Razor Components?

I'm pinging you about this, because it might have impact on integrating Castle Windsor with ASP.NET Core 3 as well.

If I am reading the comments in this issue correctly, there is no official support for ASP.NET Core 3.0, and no plans to add support in the future. Is that correct?

@chrisheil Windsor today does not have first party support for ASP.NET Core 3.0, correct.
It isn't that there are no plans to add support in the future, it is just that no one has contributed it yet. Both @stakx and myself are the only active contributors to all Castle projects, we are individual contributors like most contributors have been over a long time, we are not being paid for work on Castle. Unfortunately without a contributor that is interested in both Windsor and ASP.NET Core stepping up it just isn't going to magically happen, there have been a bunch of people that have shown interest, and I've offered to review designs and code, but there has been no movement.

As it seems it looks like a dead subject unfortunately since I don't think that AspNetCoreFacility has any active maintainers.
I've managed to make it work in a .net core 3.0 app by insourcing in my project some of the classes from ASP.NET Core Facility and modifying and eliminating some stuff which I did not need like Tag helpers support whose public APIs changed in the new .net core release. The code was in WindsorRegistrationHelpers.AddApplicationComponentsToWindsor called by extension method named AddWindsor. My app is providing only web apis so fortunately I needed to register only controllers with Windsor.

Hi @robertmircea , also trying to use Windsor here with ASP.Net Core 3.0 after using Windsor for a few years with .Net Framework. It's my first project with Core so I'm a bit confused here as well. I'm only trying to use my app for WebApis so potentially this might still work? Any chance you can offer some guidance of what you are doing?

@jonorossi Thank you for the response. I appreciate the effort your and everyone else has put into this project, and understand the situation. Would it be possible to add this disclaimer to the AspNetCore documentation to make this a little more clear to anyone else looking for this information? There is a page demonstrating how to set up in an asp.net core 2.0 environment which led to a ton of wasted time trying (and failing) before reaching this conclusion. I could create a PR for this update as well if you would prefer
@marcelNgan  I have a workaround that is a little flawed, but is "workable"
Take a look at Volosoft's adapter. This in your Program.cs file add the following lines
`return Host.CreateDefaultBuilder(args)
.UseServiceProviderFactory(new WindsorServiceProviderFactory())
.ConfigureContainer((hostBuilderContext, windsorContainer) =>
{
                windsorContainer.Kernel.Resolver.AddSubResolver(new CollectionResolver(windsorContainer.Kernel, true));

                windsorContainer.AddFacility<TypedFactoryFacility>();
                windsorContainer.Install(
                    FromAssembly.InThisApplication(typeof(Program).Assembly),
                    FromAssembly.Instance(typeof(SomeOtherClassInAnotherAssembly).Assembly)
                );
            })`

This seems to be working on my initial tests. The weird behavior I noticed is the same as described in this pull request where the adapter isn't properly disposing when trying to Ctrl+C out of "dotnet run" in a terminal.
The project itself was proposed to be included in Castle Winsdor itself, but I wasn't able to find documentation to see how the new version is working. The Volosoft project also does not look to be actively maintained anymore, which is also risky.

@chrisheil happy to accept a PR to add a disclaimer to the docs that the current facility does not work with ASP.NET Core 3.0.

Fellas this is an interesting topic!
In my scenario I am working a greenfield WPF project and was looking to leverage some of the new hosting features offered in .net core, specifically the configuration and logging management. However I wanted to stick with Windsor as an IoC container because of how capable it is.
I came up with a solution that I realize may not be the most orthodox, but it seems to do the trick. Basically I use the HostBuilder to to bootstrap a hosted service that contains the Windsor application. I then created a sub-resolver for Windsor that will cross-wire all the Microsoft provided loggers to the Windsor application. This way I can get the best of both worlds, my Windsor IoC container and all the logging goodies.
Here's my Windsor application implemented as a hosted service. The ILoggerFactory dependency is resolved by the .net DI container and is used to cross-wire the ILogger instances.
public sealed class HostedWindsorApplication : IHostedService, IDisposable
{
    private readonly ILoggerFactory _loggerFactory;
    private readonly IWindsorContainer _container;

    public HostedWindsorApplication(ILoggerFactory loggerFactory)
    {
        _loggerFactory = loggerFactory ?? throw new ArgumentNullException(nameof(loggerFactory));
        _container = new WindsorContainer();
    }

    public async Task StartAsync(CancellationToken cancellationToken)
    {
        // Use sub-resolver to cross-wire ILogger instances
        _container.Kernel.Resolver.AddSubResolver(new LoggerResolver(_loggerFactory));

        _container.Install(new CoreInstaller());
        var app = _container.Resolve<IMyApplication>();
        await app.Run().ConfigureAwait(false);
        _container.Release(app);
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        return Task.CompletedTask;
    }

    public void Dispose()
    {
        _container?.Dispose();
    }
}

Then my App.xaml.cs
public sealed partial class App
{
    private IHost? _host;

    protected override async void OnStartup(StartupEventArgs e)
    {
        _host = new HostBuilder()
            .ConfigureHostConfiguration(c =>
            {
                c.SetBasePath(Directory.GetCurrentDirectory());
                c.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
                c.AddCommandLine(e.Args);
            })
            .ConfigureServices((context, services) =>
            {
                // Use the built-in DI to bootstrap the windsor application
                services.AddHostedService<HostedWindsorApplication>();
            })
            .ConfigureLogging((context, builder) =>
            {
                builder
                    .ClearProviders()
                    .AddConfiguration(context.Configuration)
                    .SetMinimumLevel(LogLevel.Trace)
                    .AddNLog("NLog.config")
                    .AddSentry(o =>
                    {
                        o.ConfigureScope(s => s.SetTag("RootScope", "sent with all events"));
                    });
            })
            .Build();
        await _host.StartAsync().ConfigureAwait(false);
    }

    protected override async void OnExit(ExitEventArgs e)
    {
        using (_host)
        {
            await _host.StopAsync(TimeSpan.FromSeconds(5)).ConfigureAwait(false);
        }
    }
}

And finally my sub-resolver to cross-wire the ILogger instances. This one was kind of tricky since the loggers can be declared as ILogger<ResolvingType>. I had to convert the ILogger<> type into a generic type based on the handler type, and then create a new instance using Activator. There may be a better way to handle this that I'm not aware of.
public class LoggerResolver : ISubDependencyResolver
{
    private readonly ILoggerFactory _loggerFactory;

    public LoggerResolver(ILoggerFactory loggerFactory)
    {
        _loggerFactory = loggerFactory ?? throw new ArgumentNullException(nameof(loggerFactory));
    }

    public bool CanResolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
    {
        return typeof(ILogger).IsAssignableFrom(dependency.TargetType);
    }

    public object Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
    {
        // Resolve loggers of type ILogger<>
        if (dependency.TargetType.IsGenericType && dependency.TargetType.GetGenericTypeDefinition() == typeof(ILogger<>))
        {
            var genericLoggerType = typeof(Logger<>).MakeGenericType(context.Handler.ComponentModel.Implementation);
            return Activator.CreateInstance(genericLoggerType, _loggerFactory);
        }

        // Resolve pure ILogger types
        return _loggerFactory.CreateLogger(model.Implementation.FullName);
    }
}

That's what I've got working right now for my WPF application. I've only hammered it out in the past couple days so it's probably still a bit rough around the edges but it seems to be doing the trick.

Hi All.
I helped @fir3pho3nixx with the original aspnetcore2.x implementation (@fir3pho3nixx did most of the work, this was the way he wanted it).
Does anyone know yet, if we are in a start, to make a 3.x facility for AspNetCore. I will be needing something because EF Core 3.x requires netapp3.x
I can start up in march on looking at this again.
Before that, is anyone interested in grouping up with me, and figuring this out?
We also need a solution for the generic host.

@dotnetjunkie
From: https://github.com/dotnet/aspnetcore/issues/14585

During my research I found a way to circumvent the behavioral difference between
Host and WebHost in a way that doesn't require the use of IServiceProviderFactory.

Can you tell something more about that?
@generik0
Do you still plan on working on this?

Hi @dotnetjunkie.
Yes, thanks. I want to give it a shot. I worked a bit with Gavin on the aspnetcore 2 facility, where we stole your cross registering, so I hope I can work it out.
I am a little worried that nobody else has come forward with intentions for assistance, makes me a little worried that the facility is not needed.
But please, and links/advice you have are more than welcome!!!

@rvdginste,
Let me first summarize the problem with ASP.NET Core 3:

ASP.NET Core 3.0's new Microsoft.Extensions.Hosting.Host creates hosted services between Startup's ConfigureServices and Configure methods, where the 'old' Microsoft.AspNetCore.WebHost creates the hosted services only after the Configure method has run. This behavior difference between Microsoft.AspNetCore.WebHost and Microsoft.Extensions.Hosting.Host is significant, because it disallows users of non-conforming containers (like Simple Injector, Castle Windsor, and Ninject) to resolve hosted services from their container, because the configuration of those containers needs to be finished in the Startup.Configure phase, while resolving hosted services from that container before that configuration is finished, can lead to problems. Simple Injector, for instance, blocks any registrations made after the first resolve (which will be a resolve for MyHostedService if you assume the hosted service to be added using p => container.GetInstance<MyHostedService>()). But even if the container doesn't block registrations, the early request for hosted services can cause trouble, because the hosted service's dependencies might not be registered at that point.

The way we were able to circumvent this problem is by adding an  ContainerLocking event to the container that signals when the container is about to get locked. This happens, for instance, when the first call to GetInstance is being made, but just before the instance is being resolved and before the container is being locked. The ASP.NET Core integration packages hook onto that event in order to do their last-minute registrations. This works around the problem because all registrations need to (obviously) be done before the container gets locked (which is when the first service is being requested), the first resolve might happen between ConfigureServices and Configure in the case of the new Host, while it would always happen after Configure in the old model.
Perhaps unsurprisingly, but this change was a time-consuming endeavor. We needed a lot of discussions, developing, testing, and documenting to get this fix out the door.

@dotnetjunkie I like your point in https://github.com/dotnet/aspnetcore/issues/14585#issuecomment-536742102.
Personally, I wish you had kept on the discussion with @davidfowl regarding the IServiceProviderFactory and aspnetcore3.0 issues with non-conforming DI. I would have loved to give you any backing I could (but I doubt you needed).
My thoughts are, once again, if we want the aspnetcore facility to work in Windsor, we need to look to simple injector for guidance.

@dotnetjunkie Thank you for the explanation!
@generik0 I am willing to help in whatever way I can, but personally I am only interested in support for controllers. So I made a test project that includes the existing facility code to see how the current facility works (using asp.net core 3 with the old WebHost), but I threw out the code related to TagHelpers and ViewComponents.

I think this is the cleanest way to plug in both a conforming and non-conforming container into the system:
https://github.com/dotnet/aspnetcore/issues/14585#issuecomment-536930119
It's a way to give you a a chance to create your own builder (whatever that may be) and it gives you a chance to return a service provider (it a clean way to plug into the lifecycle of the system).

@rvdginste that sounds great! can you share it in e github repo?

HI @davidfowl ! Thanks for joining the conversation!! :-)
I think I understand your point about 14585. It just looks strange to me that we essentially need to double register "stuff". i.e first with our own DI  (conforming or not) and then the with ServiceCollection . We got around this in aspnetcore2.0 with cross registering,
My head doesn't quite understand why MS didn't make the Service collection etc, replaceable with any DI. Why would you lock it to your specific implementation? Or am I wrong here? Is the MS DI replaceable with anything, just by implementing some simple interfaces on our own implementations? And registering some standard MS implementations in "our" DI?
The MS Service Collection is probably designed and programmed very will. However the other DIs like Caste and Simple, just  have so many more powerful features, that we need. they are years in front of the inbuild Di..
Why does MS not provide a simple way for DIs to integrate into the new hosts? One would think it was to your benefit? Or have I misunderstood something, is it very easy or override e.g. Simple and Castle in the new net core release? The example you provide does not seam to make it easy.
Also this whole conforming and none conforming questions. Why shouldn't we be able to register stuff? Just because Martin Fawler said so? Are we really going to make architecture based upon a principle someone made 20 years ago (whichj might have been incorrect since Simple, Castle and Ninject have many use cases where something else was needed). Can we never rethink architecture/prinicples?

Can confirm that using @davidfowl's approach works. I've successfully used this approach with
https://github.com/volosoft/castle-windsor-ms-adapter
to 'cross-wire' the DI registrations.
It is sightly unintuitive because the services registered in ConfigureServices aren't actually registered with Windsor - they're registered to the IServiceCollection and then re-registered with Windsor afterwards, but it is doable.

We have a large suite of code that utilizes Castle.Windsor. We looking to move our web framework over from being NancyFx based to ASP.Net Core. I'm wondering if it makes sense to start this with the WebHost still given the issues I've read through above? It's not completely clear to me (due to my nativity with ASP.Net Core) if there is any way to bridge the gap between asp.net core and Castle.Windsor yet? We're using Castle.Windsor v5.0.1

@robsonj I made a similar migration last year, only the added joy of going from WCF to asp.net core endpoints. The suggestions above are working just fine for us now, we have not encountered any issues yet related to Castle.Windsor on dotnet core 3.
Outside of figuring out the appropriate Lifestyles of course

@robsonj I made a similar migration last year, only the added joy of going from WCF to asp.net core endpoints. The suggestions above are working just fine for us now, we have not encountered any issues yet related to Castle.Windsor on dotnet core 3.
Outside of figuring out the appropriate Lifestyles of course

My confusion was with regard to which solution to utilize from the conversation above, looks like a couple of solutions in this thread, along with some other referenced solutions for other DI frameworks, so I wasn’t sure which way to go. I’m new to asp.net core , so pardon my ignorance etc

@robsonj I would recommend trying the solution dquist provided here first
If that does not work for you, I can verify my solution is usable for now, but with the issue I linked to above.

@robsonj I would recommend trying the solution dquist provided here first
If that does not work for you, I can verify my solution is usable for now, but with the issue I linked to above.

Thank you, I’ll give it a shot, thanks for the help!

Ok, got a bit further. I followed the example above, but I was expecting the Microsoft.Extensions.Logging.ILogger<> dependency in my Razor page .cs (Index.chtml.cs) to result in a call on the LoggerResolver CanResolve() being invoke to determine its actual implementation, that doesn't seem to be the case though? I also tried having the Razor page depend on the Castle ILogger, but that just results in a runtime error.
I'm I doing something wrong, or are my expectations incorrect?
Cheers
Jonathan
PS Let me know if this is the wrong place to be asking these questions.

@robsonj My initial implementation above is pretty rough and I wouldn't recommend it. It uses two separate containers, the Microsoft provided one and Windsor. The sub-resolver allows the Windsor container to resolve instances from the Microsoft container, but not the other way around. That's the biggest drawback is that you have to depend on the Windsor container itself.
I ended up using the https://github.com/volosoft/castle-windsor-ms-adapter project which works well enough and follows Microsofts design for an ASP.NET Core container.
Hope that helps.

@robsonj My initial implementation above is pretty rough and I wouldn't recommend it. It uses two separate containers, the Microsoft provided one and Windsor. The sub-resolver allows the Windsor container to resolve instances from the Microsoft container, but not the other way around. That's the biggest drawback is that you have to depend on the Windsor container itself.
I ended up using the https://github.com/volosoft/castle-windsor-ms-adapter project which works well enough and follows Microsofts design for an ASP.NET Core container.
Hope that helps.

Thank you, I was just looking at the volosoft adapter. Thanks for confirming my understanding was incorrect. We definitely wanna use the Castle ILogger everywhere if possible as we have an entire code base that depends on it (log4net under the covers)

Ok, the volosoft route seems to work better. Got it working much better in 22 minutes :-). Thank you for the help all!

Hi,
had a stab at it, check out https://github.com/EurofficeGroup/windsor-service-provider . It took few days to understand al the .NET Core interfaces. Massive thanks to volosoft for figuring out bunch of the semantics.
This approach, similar to volosoft, doesn't try to run the default container (DefaultServiceProvider) and Windsor side by side but rather using Windsor as the one and only container. It supports .NET Core scopes as well.
There are few things I am not sure about:

what's the semantics of Transient in .NET Core (i.e. services.AddTransient)
tried it only with WebAPI project. Other features might not work but happy to collaborate on getting them working

At some point might be useful to run it through Microsoft.Extensions.DependencyInjection.Specification.Tests

At some point might be useful to run it through Microsoft.Extensions.DependencyInjection.Specification.Tests

That's really the most important part if you go this route. Any failing test will result in some incompatibility in behavior.

@ltines very cool,very interesting!
Are you proposing we replace the castle.aspnetcore. Facility with this implementation?

At some point might be useful to run it through Microsoft.Extensions.DependencyInjection.Specification.Tests

That's really the most important part if you go this route. Any failing test will result in some incompatibility in behavior.

Yup, gave it a shot - have 5 tests failing. Mostly around scopes semantics.

@ltines very cool,very interesting!
Are you proposing we replace the castle.aspnetcore. Facility with this implementation?

IMHO it's cleaner solution than having two containers side-by-side

@ltines Yes, if you/we can get the MS "visioned" implementation of the DI to work using one the Windsor, I think it would be magnificent!
I noticed you Apache License 2.0'ed you repo. Your ok to move to Castle?
@jonorossi:

How do you feel about all this. Should there be branched, and reworked the current castle.aspnetcore.facility = ?
We also need the net app generic host to get working, so it isn't "just" aspnetcore. is castle.aspnetcore.factility the correct name?

I personally promised to also start looking at this in March. Unfortunately, I got one month behind on a major project and managed to get bronchitis (in this time of Corona) {excuses, excuses} but @ltines do you want any help, i think i can manage some time?

@ltines Yes, if you/we can get the MS "visioned" implementation of the DI to work using one the Windsor, I think it would be magnificent!
I noticed you Apache License 2.0'ed you repo. Your ok to move to Castle?

Sure, no problem with that.
I am down to last the failing test - ordering of scoped components disposal.
@generik0

there is expectation that Transient components are actually tracked and disposed on scope dispose. So I made them scoped (while still returning new instance on Resolve). Not sure if it's the right (tm) solution. Opinions?
would be good if you have any reasonably complex Razor / WebPages project to give it a shot.

I'll chime in:

We also need the net app generic host to get working, so it isn't "just" aspnetcore. is castle.aspnetcore.factility the correct name?

ASP.NET Core is not the correct name 😄 . See https://www.nuget.org/packages/Autofac.Extensions.DependencyInjection/

would be good if you have any reasonably complex Razor / WebPages project to give it a shot.

Once those tests pass everything will work like magic

Thanks @davidfowl :-) I think wse need to wait for @jonorossi to chim in with naming. But there is an issue with the name. There is also some web scoping in the facility that nancyfx 2.0 needs. So maybe some things should be refactored :-)
@ltines I have an extremely complex, over engineered :-), angular, node services, entity FW project to integrate (with 1 razor/mvc page (login)). But yes, i think it would be very interesting to try on this. I also have a reasonably complex 100% mvc / razor + ts(webpack/npm build). The last is on net classic, so i need to see if i can migrate.

@ltines regardning the transient. I see the predicament. If the "parent object" is web scoped, then esentially all transients would also be web scoped (unless resolved from an injected factory). If the transient is injected into a singleton, it essentially is also singleton....
So in a way, a transient injected into a web scope, should also be disposed when the scope is disposed.

@ltines does the new and improved implementation work with the generic host?

@generik0 yeah the weird thing is though when you resolve Transient twice you should get two instances - so its something like ScopedTransient :)
And I believe it should work with Generic host - it uses IHostBuilder to replace IServiceProviderFactory

ctor (IGeneric0 generic1, IGeneric0 generic2)

@generik0
when you resolve Transient component in Windosor, callee is responsible for releasing / disposing.
.NET Core has expectation that Transient components get disposed at the end of the scope or at disposing of ServiceProvider in root scope.
So Windsor Transient <> .NET Core Transient

@ltines i got this out somewhere in the current faciltiy. Used it for a nancy implementation. Does it help?
public class VemPerWebRequestLifestyleModule : IHttpModule
    {
        private const string Key = "castle.per-web-request-lifestyle-cache";

        private static bool initialized;

        public void Init(HttpApplication context)
        {
            initialized = true;
            context.EndRequest += EndRequest;
        }

        protected void EndRequest(Object sender, EventArgs e)
        {
            var scope = GetOrCreateScope(createIfNotPresent: false);
            scope?.Dispose();
        }

        internal static ILifetimeScope AttachScope()
        {
            EnsureInitialized();

            var context = HttpContext.Current;
            if (context == null)
            {
                throw new InvalidOperationException("HttpContext.Current is null. PerWebRequestLifestyle can only be used in ASP.Net");
            }

            return GetOrCreateScope(createIfNotPresent: true);
        }

        internal static ILifetimeScope DetachScope()
        {
            var scope = GetOrCreateScope(createIfNotPresent: true);
            if (scope != null)
            {
                HttpContext.Current.Items.Remove(Key);
            }

            return scope;
        }

        private static void EnsureInitialized()
        {
            if (initialized)
            {
                return;
            }

            throw new ComponentResolutionException($"PerWebRequestLifestyleModule was not initialised. Please refer to https://github.com/castleproject/Windsor/blob/master/docs/systemweb-facility.md for more info.");
        }

        private static ILifetimeScope GetOrCreateScope(bool createIfNotPresent)
        {
            var context = HttpContext.Current;
            if (context == null)
            {
                return null;
            }

            var candidates = (ILifetimeScope)context.Items[Key];
            if (candidates == null && createIfNotPresent)
            {
                candidates = new DefaultLifetimeScope(new ScopeCache());
                context.Items[Key] = candidates;
            }

            return candidates;
        }

        public void Dispose()
        {
        }
    }

@ltines and i guess the net core implementation doesn't have a nice release call, where it can dispose...
Can the current implememation be used? https://github.com/castleproject/Windsor/blob/4830718f99fd71e539133b34f9e54daa49049d6f/src/Castle.Facilities.AspNetCore/AspNetCoreExtensions.cs#L67

@ltines btw, a nice litttle mvc check for you is if these resolve / can be registered:

IHttpContextAccessor
IActionContextAccessor
IHtmlLocalizer (you need to make a resource file)
--> Component.For<IHtmlLocalizer>().ImplementedBy<HtmlLocalizer>()

:-)

@ltines and i guess the net core implementation doesn't have a nice release call, where it can dispose...
Can the current implememation be used?
https://github.com/castleproject/Windsor/blob/4830718f99fd71e539133b34f9e54daa49049d6f/src/Castle.Facilities.AspNetCore/AspNetCoreExtensions.cs#L67

Actually it does. We're providing our own ScopeFactory and linking .NET Core scope with Windsor scope. I am just not perfectly happy with my solution.

Maybe this applies :-)

How do you feel about all this. Should there be branched, and reworked the current castle.aspnetcore.facility = ?

@generik0 I'd leave the existing facility as is, its design is tied to ASP.NET Core which today is wrong, and we'll remove it as people move over, the new facility should not reference ASP.NET Core. I'd expect it to reference Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Hosting so you can use it in a console application without dragging in ASP.NET Core libraries.

We also need the net app generic host to get working, so it isn't "just" aspnetcore. is castle.aspnetcore.factility the correct name?

@generik0 I agree with @davidfowl. I think the name should be Castle.Facilities.MsDependencyInjection.

@jonorossi That perfect. thx!!
Naming you mean:
Castle.Facilities.Extensions.DependencyInjection
or
Castle.Windsor.Extensions.DependencyInjection
i think that is what @davidfowl refered to.. https://www.nuget.org/packages/Autofac.Extensions.DependencyInjection/

Naming you mean:
Castle.Facilities.Extensions.DependencyInjection
or
Castle.Windsor.Extensions.DependencyInjection

I don't see much value in the adding the "Extensions" part of the namespace, making it the full namespace would give you "Castle.Facilities.Microsoft.Extensions.DependencyInjection", which is silly.
For historic reasons all the first party facilities are under the facilities namespace, not the Windsor namespace.
I (not unlike the Volosoft guys) think that "Castle.Facilities.DependencyInjection" isn't clear enough this is for the .NET Core Extensions project support, therefore the extra prefix, DotNetExtensions as a prefix is just too long.
I thought exactly as I wrote Castle.Facilities.MsDependencyInjection made the most sense. If you disagree, happy to hear another proposal.

We are probably getting caught in the weeds here, but Castle.Facilities.ExtensionsDependencyInjection (without a dot) could also work?
I always see that Autofac example and think the Autofac.Extensions.* as a namespace for extensions (lowercase e), rather than Extensions.DependencyInjection as the integrated product.

@jonorossi I am "græskkatolsk" (Danish saying which means I don't mind either way). However, I do many times find naming harder than coding, and sometimes just as important getting right :-)

@generik0 @davidfowl
Done few fixes and reworked how scoping works. Now it passes all the tests.
@generik0 @jonorossi
I would suggest Castle.Windsor.Extensions.DependencyInjection mainly becase it's not a facility and will match other containers naming

@generik0 I'd avoid using .NET Core branding since Core is slowly disappearing, the project is named ".NET Extensions".
@ltines let's go for it, no real reason to keep the old namespace convention since we've deprecated so many facility in recent years anyway.
Only nitpick with Castle.Windsor.Extensions.MsDependencyInjection, is that the "Extensions" bit now with the MS prefix isn't referring to the "Microsoft.Extensions" (.NET Extensions) project, and everything not in Castle.Windsor really is an extension, so Castle.Windsor.MsDependencyInjection would be enough, or do as Autofac did Castle.Windsor.Extensions.DependencyInjection.
So:

Castle.Windsor.Extensions.DependencyInjection, or
Castle.Windsor.ExtensionsDependencyInjection, or
Castle.Windsor.MsDependencyInjection

With my preference now to 1 or 2, since the project is ".NET Extensions DependencyInjection".

Castle.Windsor.MsDependencyInjection - would make the most sense to me given that castle windsor itself is a dependency injection framework, without the Ms It could be confusing as to what that namespace is the subject of.

@ltines i have written to you on issues for your own repo, to initialize some planing and your expectations.
Please tell me how you would like me to assist.
I can start by integrating what you have already done on Friday?

I also just remembered that Castle.Windsor.MsDependencyInjection would conflict with the existing volosoft package with the same name.

@generik0 i'll move the code as PR here (once i figure out how to do it)
@jonorossi @robsonj
Castle.Windsor.MsDependencyInjection would be beautfiul. So i still think the closes is Castle.Windsor.Extensions.MsDependencyInjection. It's an extension to .NET Core

@ltines that's perfect! Let me know when you have a pre-release or something ready. FYI, The castle project builds a little funny (to a build folder), so from what I remember your dll/nugets land there (just a hint).
Regarding name. I vote for "Castle.Windsor.Extensions.DependencyInjection", Don't like the MS prefix, as you will need to change the name if MS changed the name of there repo, (or gave the whole .net core away to a foundation, like Oracle did for apache)... Thats just my thoughts. Do as you feel best @ltines
Either way, looks like I can just sit back and play the tester in a bit, and that is nerver a bad role :-).
Let me know when you have a fork ready with the code please  @ltines.
Looking forward to hearing more. Great work everyone. Great work @ltines :-)

Any update guys?

Any update guys?

Sorry for not getting to this yet, been busy but will make time on Sunday.

In which state is the nuget package? Was it published?

I was last to comment on #517 10 days ago, not sure where @ltines is at.

Published v5.1.0-beta001:
https://www.nuget.org/packages/Castle.Windsor.Extensions.DependencyInjection/
Please log any problems in new issues.
Thanks everyone.

5.1.0-beta001 working fine for me. Is there any thought on an approximate release timeframe, i.e 1week, 1month, 1quarter away?

I have a rather large aspnetcore project with many integrations (e.g. including node services). I would like to try the beta.
Just need a little time to get time and do a update prototype...
Has anyone tested the EF Core integration security integration with the package?

Great work! Thank you all for putting in the hard work to get this added.
One question, what would the proper setup be for this update? The documentation still mentions using the old Castle.Facilities.AspNetCore package

@chrisheil please look here:
https://github.com/castleproject/Windsor/blob/master/docs/net-dependency-extension.md
@ltines did a great job. The aspnetcore facility has been improved with the net dependence extension for dotnet+

5.1.0-beta001 working fine for me. Is there any thought on an approximate release timeframe, i.e 1week, 1month, 1quarter away?

@robsonj All depends on when you all are happy for it to go out after bugs are ironed out. So the more use now will likely speed up people's confidence.

One question, what would the proper setup be for this update? The documentation still mentions using the old Castle.Facilities.AspNetCore package

@chrisheil @generik0 I've just edited the warning on the old ASP.NET Core 2.x facility page. Feel free to send pull requests to improve the documentation.

@generik0 That did the trick, thank you.
I have been running this in our test servers for a couple days and experiencing no issues. I did have to find a workaround for replacing the Volosoft MsScopedLifestyleManager with ScopedToNetServiceScope on one of my registrations. In case anyone else runs into a similar problem here's how I worked around it.
Original code:
container.Register(Classes
    .FromAssemblyContaining<IFoo>()
    .BasedOn<IFoo>()
    .WithServiceBase()
    .LifestyleCustom<MsScopedLifestyleManager>()); // From the Volosoft nuget package

Updated code
container.Register(Classes
    .FromAssemblyContaining<IFoo>()
    .BasedOn<IFoo>()
    .WithServiceBase() // <== Cannot use ".Lifestyle.ScopedToNetServiceScope()"
    .Configure(component => component.LifeStyle.ScopedToNetServiceScope()));

I am trying to inject IHttpClientFactory as a constructor parameter to one of my classes and I receive the following exception when using Castle.Windsor.Extensions.DependencyInjection
DefaultHttpClientFactory is an internal class which is registered by Microsoft for supporting IHttpClientFactory.
Previously, I was using Volosoft with no issues.
Any idea on how to solve this?
Castle.MicroKernel.ComponentNotFoundException: No component for supporting the service Microsoft.Extensions.Http.DefaultHttpClientFactory was found
   at Castle.MicroKernel.DefaultKernel.Castle.MicroKernel.IKernelInternal.Resolve(Type service, Arguments arguments, IReleasePolicy policy, Boolean ignoreParentContext)
   at Castle.MicroKernel.DefaultKernel.Resolve(Type service, Arguments arguments)
   at Castle.Windsor.WindsorContainer.Resolve(Type service)
   at Castle.Windsor.Extensions.DependencyInjection.WindsorScopedServiceProvider.ResolveInstanceOrNull(Type serviceType, Boolean isOptional)
   at Castle.Windsor.Extensions.DependencyInjection.WindsorScopedServiceProvider.GetRequiredService(Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at Microsoft.Extensions.DependencyInjection.HttpClientFactoryServiceCollectionExtensions.<>c.<AddHttpClient>b__0_0(IServiceProvider serviceProvider)
   at Castle.Windsor.Extensions.DependencyInjection.RegistrationAdapter.<>c__DisplayClass4_0`1.<UsingFactoryMethod>b__0(IKernel kernel)
   at Castle.MicroKernel.Registration.ComponentRegistration`1.<>c__DisplayClass84_0`1.<UsingFactoryMethod>b__0(IKernel k, ComponentModel m, CreationContext c)
   at Castle.MicroKernel.ComponentActivator.FactoryMethodActivator`1.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.ScopedLifestyleManager.<>n__0(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.ScopedLifestyleManager.<>c__DisplayClass4_0.<Resolve>b__0(Action`1 afterCreated)
   at Castle.Windsor.Extensions.DependencyInjection.Scope.ExtensionContainerScope.GetCachedInstance(ComponentModel model, ScopedInstanceActivationCallback createInstance)
   at Castle.MicroKernel.Lifestyle.ScopedLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired)
   at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernelByType(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernel(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.TryResolveCore(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency, Object& value)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.CreateConstructorArguments(ConstructorCandidate constructor, CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.SingletonLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired)
   at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernelByType(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernel(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.TryResolveCore(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency, Object& value)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.CreateConstructorArguments(ConstructorCandidate constructor, CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.SingletonLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context, Boolean instanceRequired)
   at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernelByType(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.ResolveFromKernel(CreationContext context, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.TryResolveCore(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency, Object& value)
   at Castle.MicroKernel.Resolvers.DefaultDependencyResolver.Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.CreateConstructorArguments(ConstructorCandidate constructor, CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.Instantiate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.DefaultComponentActivator.InternalCreate(CreationContext context)
   at Castle.MicroKernel.ComponentActivator.AbstractComponentActivator.Create(CreationContext context, Burden burden)
   at Castle.MicroKernel.Lifestyle.AbstractLifestyleManager.CreateInstance(CreationContext context, Boolean trackedExternally)
   at Castle.MicroKernel.Lifestyle.SingletonLifestyleManager.Resolve(CreationContext context, IReleasePolicy releasePolicy)
   at Castle.MicroKernel.Handlers.DefaultHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired, Burden& burden)
   at Castle.MicroKernel.Handlers.DefaultHandler.Resolve(CreationContext context

Hi @robertmircea
Did you register it?

I didn't have to register it when using Volosoft's adapter. DefaultHttpClientFactory was automatically registered when calling services.AddHttpClient() in Startup.cs to register my http clients. However, after switching to Castle.Windsor.Extensions.DependencyInjection, the same code (no modifications) no longer works.

I see, so you have services.AddHttpClient() which should register it, but just to the castle container.
Did you use the other package with net core 3 also? Because it might be changes in net core 3?
Maybe the default factory needs to be registered first with “IncludeNonPublicTypes”?
Maybe find the code for the default factory aspnetcore lib? Also check what the “AddHttpClient” is doing in the github repo, and try doing it yourself with castle registrations?

I was wondering what the current thoughts are on non beta Castle release to include this feature?

@robsonj there are a couple of new issues open, no idea if they are blockers.

 But the "WebHost" does not allow the extension to register castle Windsor as the service provider- only "Host".
Any thoughts? Shouldn't there be an extension to WebHost?

@ltines ie:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/web-host?view=aspnetcore-3.1

@generik0 It is best to create new issues to track things since this is already closed and released (as a beta).

hello everyone,
is there any date for release the final version of this component? for now it's still in beta, :(
thanks!

Hi @rmszc81 have you been using the Beta?
We are almost through the issues We know about, but still need more beta testers to make sure all configurations are Working

Yeah, I have been using the beta and it's working fine for me, so, in short:
it's an asp.net core 3.1 web api application, including:

automapper
serilog
castle dynamic proxy,
castle windsor (obviously)

injections are mostly done by constructors, a few by properties.
no known issues, it's running properly and performance is good too.

@generik0 We upgraded our application the day the beta came out, and have been cleared in QA and UAT after several months of testing. In fact, this beta resolved some issues we had faced with the workarounds we had introduced with the earlier solutions before the beta
We are running on asp.netcore 3.0 web api with the following:

automapper
castle dynamic proxy
graylog
Entity Framework Core 2.2
FluentValidation

We are also upgrading another product to use this beta with similar dependencies, and early signs are positive

Good news @chrisheil. Thanks!!!!


Linux linux_web_engine timing out but not closing the engine tree

For example https://ci.chromium.org/ui/p/flutter/builders/prod/Linux linux_web_engine/1214/overview.
As a separate issue, that page also does not indicate which of the sub-builds timed-out.

Seems like it's due to code checkout https://luci-milo.appspot.com/ui/p/flutter/builders/prod/Linux Production Engine Drone/153162/overview.
But this should close the tree so that the engine sheriff et al. know that there is a P0.

There is an misbehave from gob side: http://irm/i_QPt2Z8XM3ZcjmZnUYFrd

Canceled builds should block the tree is being tracked: https://github.com/flutter/flutter/issues/125012. Considering this is happening frequently, bumping the priority.

Increase the timeout of orchestrator by 10m to ensure the subbuild timeouts are presented correctly:
https://github.com/flutter/engine/pull/41839

Fixing caches: https://flutter-review.googlesource.com/c/infra/+/44064


Android: Visual glitch when displaying navigation panel

This occurs if Hybrid Composition is used. This is a known Flutter issue that will be fixed in Flutter SDK 2.10.

Not fixed in Flutter 2.10.0-0.1.pre

Seems to be fixed (https://github.com/flutter/engine/pull/30724). Probably in next Flutter release.

Fixed in Flutter 2.10.0-0.2.pre! Closing this issue.


[Crash] Skeleton doesn't have additionalentityattributes:player.critical_bonus_damage

crash-2024-02-19_22.28.47-server.txt
latest.log
This crash is because my mod includes additionalentityattributes 1.7.0+1.20.0 while zenith includes additionalentityattributes 1.4.0+1.20.0.
Why can't mobs have critical bonus damage?

L2327: Caused by: java.lang.IllegalArgumentException: Can't find attribute additionalentityattributes:player.critical_bonus_damage
Interesting lines L2332-2334:
	at dev.shadowsoffire.attributeslib.impl.AttributeEvents.lambda$apothCriticalStrike$3(AttributeEvents.java:200) ~[zenith_attributes-0.1.5.jar:?]
	at io.github.fabricators_of_create.porting_lib.entity.events.living.LivingEntityDamageEvents.lambda$static$0(LivingEntityDamageEvents.java:15) ~[porting_lib_entity-2.1.1127+1.20-fb24e5b47219a943.jar:?]
	at net.minecraft.class_1309.handler$fep000$porting_lib_entity$fireHurtEvent(class_1309.java:22823) ~[client-intermediary.jar:?]

The relevant lines in Zenith-Attribs:
https://github.com/TheWinABagel/ZenithAttributes/blob/d127b6efe640b59473f0d10b3e3a29c3437258f1/src/main/java/dev/shadowsoffire/attributeslib/impl/AttributeEvents.java#L194
Zenith does not check the existence of the attribute, but always accesses it for all living entities.
Given that the attribute was always present on all LivingEntities this was no issue at all.

Why can't mobs have critical bonus damage?

Critical Damage is only dealt by players under certain conditions and AEA only ever evaluated the attribute for players. As such, adding the attribute to non-players always was pretty much an oversight on AEAs part, that has since been corrected.
Ideally Zenith updates to use the new version of AEA and checks for players, or better if the entity has that attibute (in case mods add that attribute to their own mobs). In the meantime, you are safe using the previous version of AEA, unless you want to use the attribute that was added with last update.
I'll let Bagel know!

Zenith fixed that one.


DRAFT: Sideload URSYS into MEME

[!WARNING]
DO NOT MERGE YET because this might break Turbo360 or build. Waiting for final commits from Ben post October 15.

The new URSYS modular system is being retrofitted into older codebases. Because we have to retain compatibility with Turbo360's build system as it's being developed, ursys may have to be sideloaded as it is in NetCreate 2.0 ITEST.
What is "Sideloading"?
This is our term for copying the _ur and _ur_addons directories into an existing project's root file, rather than using the nested installation intended in the future.
The key differences:

for our old projects, we are using old build systems that do not understand Typescript, and use the older CommonJS module conventions.
for the modern standalone version of URSYS, we are using Typescript and Node ES modules. This is fundamentally incompatible/

The _ur and _ur_addons are self-contained build systems that export CommonJS libraries that are compatible with older systems like MEME. They are located in the root directories in both URSYS installation methods, but in the newer system we put apps into subdirectories each with their own package.json configurations. By comparison, older systems like MEME or NetCreate occupy the entirety of the root folder.
Work in Progress
This PR commits the changes needed to add a side-loaded installation of URSYS:

@build-ursys.sh script file added to meme root
preset-typescript added to the babel transpiler chain
tsconfig.json added to meme root, enabling typescript live linting and command-line typescript build
meme root package.json updates npm run dev to use @build-ursys-sh, and adds dependencies for @ursys
[tbd] _ur directory copied
[tbd] _ur_addons directory copied, skipping unnecessary addons

Not sure if this is important: Noting that ursys-meme-wrapper is using v18.18.2, but meme-2023 is using lts/hydrogen (18.20.4).


User Import doesn't handle CRFL line endings [v5.5]

I was helping Laurel/BMEC use the user import function, and noticed it was choking on her CSV, which was created by Microsoft Excel 2011 and riddled with ^M characters, which is the FL of Windows-only line ending CRFL. The server-side log error messages indicated it couldn't find any users to import. (specifically choking on line 60 of import_users_controller.rb, method keys unavailable on object nil---indicating there was no first user in the hash of imported users. Using Vim, I replaced all ^M characters with standard \r, and the import progressed further.

@dgoerger could you get me a csv that caused this problem so I can make sure I've solved it properly?

@dgoerger :bell:

Sorry, it appears to have been CR line endings, which is even more absurd and less widely used. I'll update the description.
Hopefully git clone won't rewrite this file to the more common LF line terminator (it worked for me, but if your gitconfig is configured to convert e.g. for Windows compatibility that may present an issue): https://gist.github.com/dgoerger/354c79fe9b16f3cb493d

Thanks, worked perfectly!


Update window and document properties check

Only the last commit needs to be reviewed, because the dev branch has not been updated to the state of the main branch

I'm not so sure about the "OutlierProperties", maybe more suitable "UnexpectedProperties" or  "DistinctiveProperties"?


Missing switch back to train() mode

Hello. In the following lines:
https://github.com/KaiyuanZh/FLIP/blob/b3fd729670b29af549e54f2245031ff6982cfd0c/invert_CIFAR.py#L85
and
https://github.com/KaiyuanZh/FLIP/blob/b3fd729670b29af549e54f2245031ff6982cfd0c/invert_CIFAR.py#L321
The model is set to eval() mode (thus batch-norm statistics are not tracked) but is never reverted to train() as it should be, since the model is still in the process of training.

Hi @iamgroot42, thank you for reporting this. I have fixed it. Please let me know if you encounter any other issues.


After deleting all sub-pages it's not possible to delete the parent page

Describe the Bug
Its not directly possible to delete a page after deleting its sub-pages. The parent page first has to be updated or the page tree needs to be refreshed (e.g. by moving a page or creating a new page) before the page can be deleted.
Steps to Reproduce

Go to 'Pages'
Create a new page
Create a second page as a sub-page for the first page
Go back to 'Pages'
Delete the sub-page
Delete the parent page
See that "Delete" icon is inactive (screenshot below)

Expected Behavior
"Delete" button should be clickable without having to update the page or page tree after deleting the sub-pages
Actual Behavior
After deleting the last sub-page of a page the "Delete" icon is greyed out and cannot be clicked. It only becomes available once page is updated or the page tree was refreshed, e.g. by moving a page or creating a new one.
Additional Information
Found in Version: 2024.10.12-alpha

Cannot reproduce this locally, but I can on the test server. Since I have redis disabled locally, it is probably a redis caching issue.

I mentioned during the call that I could reproduce it on the test system, even so far that I could not delete the page, even after refreshing - I found the problem with that @PeterNerlich: there were archived pages still attributed to this parent page so it appeared empty in the page tree but for system logic was not, bcs the archived pages are connected to it. I only saw that once I opened the page and tried to delete it there... so probably it is what David says :)

We could think about that but definitely low prio as it is a problem that only affects us and not the municipalities. I think we have bigger issues to work on right now :)


files: handle file initialization failure

Package version (if known): v6.0
Describe the bug
When a file is failing to be initialized the error is not reported in the UI.
Steps to Reproduce

Go to the uploads page and save a draft without files
Open a new window and navigate to the same draft
Upload a file e.g test.txt to one of the 2 windows
Now try to upload the same to the other one
The error that you can see in the network panel is that the file already exists thus it's failing to get initialized

Expected behavior
We should report the error in the screen similar to #381
Screenshots (if applicable)

it was implemented


⚠ Bofrost.es has degraded performance

In afddb1f, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1684 ms

Resolved: Bofrost.es performance has improved in d9c0ebb after 6 minutes.


x/fuzzdata: new repository for fuzzing corpus data

Summary
In #30719 and #30979, dvyukov/go-fuzz compatible fuzz functions were landed in:

the standard library in src/image/png/fuzz.go
golang.org/x in golang.org/x/image/tiff/fuzz.go

The follow-up item in this issue here is to add a new golang.org/x/corpus repository to hold an example fuzzing corpus for portions of the standard library and x subrepos. This is to help with the exploration requested by the core Go team in discussion of the #19109 proposal to "make fuzzing a first class citizen".
The name for the new corpus repo alternatively could be golang.org/x/fuzz or something else; some additional naming discussion below.
Note that this issue is at least currently intended to be solely about creating the repository itself, and this issue does not cover checking in any corresponding fuzzing corpus (which is likely to be a follow-up issue).
Background
See the "Background" section of #30719 or https://github.com/golang/go/issues/19109#issuecomment-441442080.
Additional Details
As part of the #19109 proposal discussion, there were multiple comments/requests from the core Go team asking to develop a better understanding of how a fuzzing corpus looks and behaves when it resides in a repository. For example, this March 2017 request in https://github.com/golang/go/issues/19109#issuecomment-289573239 from Russ:

add fuzz tests to at least the x subrepos and maybe the standard library, so that we can understand the implications of having them in the source repos (including how much space we're going to spend on testdata/fuzz corpus directories

In the March 2017 proposal document in https://github.com/golang/go/issues/19109#issuecomment-285456008, @dvyukov proposed:

For the standard library it is proposed to check in corpus into golang.org/x/fuzz repo.

golang.org/x/fuzz seems to be a very reasonable name. Two alternative possible names:

golang.org/x/corpus
golang.org/x/fuzzcorpus

Personally, I think x/corpus or x/fuzzcorpus might be more evocative than x/fuzz (e.g., someone might incorrectly think x/fuzz is where the fuzzing implementation or fuzzing functions live), but I do not have a strong opinion on the name and suspect others will have stronger opinions. Until there is additional feedback on the name, the rest of this comment here will use the term golang.org/x/corpus.
Populating the corpus
The initial seeding of the corpus can likely come from https://github.com/dvyukov/go-fuzz-corpus for a given Fuzz function. If that happens, then right now, there would be two corpus directories populated: go-fuzz-corpus/png/corpus and go-fuzz-corpus/tiff/corpus.
In parallel, multiple people are making progress on integrating dvyukov/go-fuzz into oss-fuzz in google/oss-fuzz#36, google/oss-fuzz#2188, dvyukov/go-fuzz#213 and elsewhere. Most likely, it will make sense to periodically update the golang.org/x/corpus repo with the output from oss-fuzz (which otherwise by default is stored in a Google Cloud Storage bucket).
However, the exact mechanism of populating and updating golang.org/x/corpus repo I think can be discussed outside of this particular issue. (Reason: In general, it seems more tractable to make progress if things are broken down into more manageable discrete chunks of work, especially to break out into separate steps the things that must be done by someone on the core Go team, vs. could be done by someone from the broader community. This issue is focused on the creation of the repo, which presumably must be done by someone on the core Go team, whereas populating the corpus can be done by a greater range of people from the broader community in consultation with the core Go team).
I am of course happy to discuss anything here, and happy to be corrected if any of the above is different than how people would like to proceed.
CC @dvyukov @josharian @FiloSottile @bradfitz @acln0

LGTM. I suspect bringing the full oss-fuzz corpus back into the repo might bloat it too much, but we definitely need a place for seed corpus, so this sounds good.

Related issue: #14304.

Oh, how about x/fuzzdata? (Bikeshed!)

will the repository used only for fuzzing?

For reasons of clarity, I personally like x/fuzzdata or x/fuzzcorpus over x/corpus or x/fuzz.  I led off the issue using x/corpus mainly because it seems the core Go team generally places great weight on brevity.

I was also going to suggest fuzzdata.

@kybin

will the repository used only for fuzzing?

That is the current intent of the suggestion in this issue.

LGTM. I suspect bringing the full oss-fuzz corpus back into the repo might bloat it too much, but we definitely need a place for seed corpus, so this sounds good.

If it's only for seed corpus, then seed corpus may belong to the main repo better. We do want to use it in unit tests too! See https://github.com/dvyukov/go-fuzz/issues/218#issuecomment-478467743 for more explanation.

To clarify, I mean only seed corpus, i.e. small number of high-quality inputs without significant churn (no more than what happens with code). For a fuzzer-generated corpus we do need a separate repo.

Part of what is tricky is there are really 2 things running in parallel, I think:

Actually fuzzing the stdlib much more (mainly via oss-fuzz).

Use the stdlib and x subrepos as a “pilot” for the “first class fuzzing” proposal (at Russ’ suggestion).

For #2, it seems important that golang.org/x/fuzzdata gets created so that the stdlib and x subrepos can be a pilot of at decent size project that stores a decent sized corpus with some churn in a repo... and I think that is important even under the split corpus idea in https://github.com/dvyukov/go-fuzz/issues/218#issuecomment-478467743, which I commented on there yesterday (probably too enthusiastically, sorry).

Hi @katiehockman, I had a question for you about the generated corpus under the current draft  design for first class fuzzing, which in turn might have some implications for what to do this with issue.
The draft includes:

The generated corpus will be in a new directory within $GOCACHE, in the form $GOCACHE/fuzz/$pkg/$test/$name,

and also:

A generated corpus will be managed by the fuzzing engine and will live outside the module in a subdirectory of $GOCACHE. This generated corpus will grow as the fuzzing engine discovers new coverage.
The details of how the corpus is built and processed should be unimportant to users.

It makes sense that the details of what is inside the generated corpus can effectively be opaque to ordinary users, but the generated corpus itself is fairly valuable, and often worthy of keeping around & building up over time.
Given that generated corpus is valuable, it can be fairly useful to allow more direct control of the location of the generated corpus (to allow for easier storage in a separate repo, or cloud storage, or a shared filesystem, or easier integration with the diversity of CI systems in use, or purpose built fuzzing systems like OSS-Fuzz)
The prior first class fuzzing proposal went through a couple iterations on corpus behavior, but the behavior in the fzgo prototype of that proposal ultimately defaulted to reading from testdata (e.g., for a seed corpus), wrote to GOPATH/pkg/fuzz by default as a local cache for the generated corpus, but also allowed more direct control of the generated corpus via an optional -fuzzdir flag to support use cases such as those mentioned just above.
GOCACHE certainly can be made to work in different scenarios, but what are your thoughts around a more convenient flag or fuzz-specific env variable to allow more direct control of the location of the generated corpus?
Thanks, and exciting to see the progress you have been making! 🚀

I’d like to second the notion that corpuses are valuable and should be (able to be) retained and shared. It’s not just computational resources to generate them. Some corpuses I’ve developed alongside the code, so they contain good coverage already for alternative implementations. And other corpuses are seeded manually, which can make a dramatic difference to fuzzing effectiveness.

It makes sense that the details of what is inside the generated corpus can effectively be opaque to ordinary users, but the generated corpus itself is fairly valuable, and often worthy of keeping around & building up over time.

Agreed. Even though it defaults to$GOCACHE, we are still making sure that go clean would not delete it unless specified. I added those details to the design draft, so thanks for bringing that up. From @jayconrod's CL where he implemented this:
Although files are written into a subdirectory of GOCACHE, they are
not removed automatically, nor are they removed by 'go clean -cache'.
Instead, they may be removed with 'go clean -fuzzcache'.

But to your point about making this customizable, I've gone ahead and added that to the open issues section of the design draft. It's something that we'll likely be considering in the future, it is just unlikely to make it into the first experimental release: https://go.googlesource.com/proposal/+/master/design/draft-fuzzing.md


Task instance log cannot be updated

工作流定义完成  运行
工作流实例运行的时候    任务实例的日志没有更新   也没有反应

Could you paste a screen capture?

can you provide more information？ for example error log

At present, when the shell task is running, you cannot view the log. You can only view the log after the shell task is executed. Does anyone want to fix it?

flush log has two condition : log size > 64 or flush time interval 1s , otherwise save memory .
if you use sleep test .
for example :
echo<PHONE_NUMBER>
sleep 100
echo<PHONE_NUMBER>
echo<PHONE_NUMBER> can read , but doesn't match above conditions . so don't flush
if you doubt why sleep 100 . time condition   doesn't match . because process not output and flush method doesn't execute

flush log has two condition : log size > 64 or flush time interval 1s , otherwise save memory .
if you use sleep test .
for example :
echo<PHONE_NUMBER>
sleep 100
echo<PHONE_NUMBER>
echo<PHONE_NUMBER> can read , but doesn't match above conditions . so don't flush
if you doubt why sleep 100 . time condition doesn't match . because process not output and flush method doesn't execute

size > 64 ? what's unit of 64? Kib?

List logBuffer size

@xingchun-chen have other advice ?

At present, when the shell task is running, you cannot view the log. You can only view the log after the shell task is executed. Does anyone want to fix it?

I think this is OK, no need to fix to avoid disk pressure


Add Support for Product Videos

What is the motivation for adding / enhancing this feature?
Magento 2 supports the ability to add videos in the product gallery. While editing the product you can add a video using a URL from YouTube or Vimeo. Vimeo is supported by default, but you need API key for YouTube to work. Magento uses the API to pull in the title, description, and a placeholder image for the video.
On the front-end of Magento's Luma theme it simply displays the video placeholder image as a product image in the gallery with a "play" icon over it. Once clicked the embedded video is displayed and played.
There are additional configurations available such as auto-starting the video, auto re-starting the video, and showing related videos.
What are the acceptance criteria

Videos are available in the product gallery to be played using the video_url provided
Placeholder images are used in place of videos until user interacts to initiate playback.

Can you complete this feature request by yourself?
Yes / Possibly.
Additional information
If anyone else takes this on before I get the chance, here is a sample JSON that is returned from the media API which contains an image, a YouTube video, and a Vimeo video.
[
    {
        "id": 3423,
        "media_type": "image",
        "label": null,
        "position": 1,
        "disabled": false,
        "types": [
            "image",
            "small_image",
            "thumbnail",
            "swatch_image"
        ],
        "file": "/s/h/shop_home_we_1.jpg"
    },
    {
        "id": 3431,
        "media_type": "external-video",
        "label": null,
        "position": 2,
        "disabled": false,
        "types": [],
        "file": "/h/q/hqdefault_1.jpg",
        "extension_attributes": {
            "video_content": {
                "media_type": "external-video",
                "video_provider": "",
                "video_url": "https://youtu.be/M7R0bQHilgw",
                "video_title": "Storefront Cloud - Technical Overview",
                "video_description": "Storefront Cloud is a Mobile-first eCommerce Platform that helps you build engaging user-experience across all platforms and devices. Get focus on client interactions without any changes on the backend.\r\n\r\n\r\nStorefront Cloud Platform combine features offered by most modern browsers with the benefits of the native mobile experience, to give your business a significant profits.\r\n\r\nPowered by:\r\n\r\nProgressive Web Apps (PWA) \r\nAccelerated Mobile Pages (AMP) \r\nOpen Loyalty Platform \r\n\r\n\r\nPWA is a Web application which behaves the same way like the native:\r\n\r\n- can be used without the internet connection,\r\n\r\n- like an app - is blazingly fast,\r\n\r\n- can be added to Home screen but without installation process,\r\n\r\n- in contrast to Apps is linkable - easy to share,\r\n\r\n- offers the same UX and UI like native apps, with push notifications etc.\r\n\r\n\r\nSo, our goal was to create Mobile-first, Offline-first eCommerce app which will be:\r\n\r\n- Fault tolerant - because it can work even without Internet access, it can run without any central servers - there is no such traffic peak that will kill the service,\r\n\r\n- We're to use all the PWA benefits - app manifest to install it on the home screen, use Service Workers to cache data etc. More on that later!\r\n\r\n- Would be great if we can achieve the response times within few dozen milliseconds per interaction,\r\n\r\n- The storefront is also designed to be platform agnostic - so to be able to integrate the same way with Magento, Pimcore, Shopify Plus or other platforms.\r\n\r\n\r\n\r\nFollow Storefront Cloud Online Here:\r\n\r\nWebsite: https://storefrontcloud.io\r\nCo-Founders:\r\nhttps://twitter.com/piotrkarwatka\r\nhttps://twitter.com/filrakowski",
                "video_metadata": ""
            }
        }
    },
    {
        "id": 3432,
        "media_type": "external-video",
        "label": null,
        "position": 3,
        "disabled": false,
        "types": [],
        "file": "/7/2/724617781_640.jpg",
        "extension_attributes": {
            "video_content": {
                "media_type": "external-video",
                "video_provider": "",
                "video_url": "https://vimeo.com/289059028",
                "video_title": "Vue Storefront 2.0",
                "video_description": "New Vue Storefront branding",
                "video_metadata": ""
            }
        }
    }
]

Great feature, go on! :)

I will open related PRs in the other repos and link back to here.

I will work on it with him :)

Everything is merged. @rain2o can we somehow see it on test?

@patzick I have added the videos to the Magento instance, so once a data pump is performed with the merged update then the videos should show up on the Luma Yoga 4 Life products (https://demo.vuestorefront.io/p/240-LV09/luma-yoga-for-life).


Set resolution for abmplot to have pixel perfect plots

I want to plot an Agent Based Model with each agent being one square of color so that the plot doesn't have any white space. To do so I have set the shape of the agent as a :rect and chosen a size for the marker. I imagine that if I set the resolution of the plot to the number of agents in each side multiplied by the size of each agent, no white space should be visible and the markers won't overlap each other.
As model I have an AgentBasedModel with (50,50) grid dimension and each Gamer has a propertie named strategy that controls the color.
using Agents
using Random

L=50

mutable struct Gamer <: AbstractAgent
    id::Int
    pos::Tuple{Int, Int}
    strategy::Int
end

Base.@kwdef mutable struct Properties

end

function initialize(; seed = 1234, grid_dims = (L,L), kwargs...)
    rng = Random.MersenneTwister(seed)
    properties = Properties(;kwargs...)
    space = GridSpace(grid_dims; periodic = true, metric = :euclidean)
    # space = GridSpace(grid_dims; periodic = true, metric = :manhattan)
    scheduler = Schedulers.Randomly()
    model = AgentBasedModel(Gamer, space; properties, rng, scheduler)
    function how_to_fill(pos)
        x, y = pos # these are the x,y coordinates
        strategy = rand(model.rng, 1:3)
        return (strategy)
    end
    fill_space!(model, how_to_fill)
    return model
end

model = initialize()

I'm not able to change the resolution for abmplot. It throws ERROR: setting resolution for scene via plot attribute not supported anymore
using InteractiveDynamics, GLMakie
strategy_to_color = Dict(1=>:slateblue, 2=>:red2, 3=>:limegreen)

ac(a) = strategy_to_color[a.strategy]
as=5
am=:rect

plotkwargs = (;
    ac,as,am)

fig, = abmplot(model; (resolution=(250,250)),plotkwargs...)
display(fig)

How could I set the resolution instead? Or, is there any other way to get a plot with a square grid of each agent as a colored square without any white space?
I have tried setting a custom heatmap but the moment one of the strategies with largest or smaller number disappears, the colors changes.

You're better off using a matrix to represent the properties instead of agents. Seems like you're making a cellular automaton. See e.g. https://juliadynamics.github.io/AgentsExampleZoo.jl/dev/examples/forest_fire/
In the meantime, I think I'll make this the way that GridSpaceSingle is plotted, which is a grid space that allows at most one agent per position.


Approach to Exercise 4 Level 1

Am I supposed to just make use of a loop to modify the output of the toString method? Or am I supposed to make use of the Collector class to modify the String?

Personally I used a for loop to add to the output string in the toString method

I too used for loops to generate the output string. I added \n to create new lines when needed. Be careful not to add a space at the end of each line as that will be considered as not passing the test cases.

I used ImLists and kinda created a data structure that stores the input in a 2D matrix, then simply printed out the matrix in my toString according to the desired format

I think you can use a loop to get your desired output for toString() method. For me, I created a String variable s, and just iterate through each element that is passed in the list and add the desired specifications (e.g "{" or ";") to that s. Then, I return s at the end of the toString() method.


Putting tested application window into foreground

Hello,
When I'm starting my tests in VS the driver successfully starts the application of my chosing, but it is run in the background (VS is still visible and I can only see a new application icon in the taskbar).
Then the code goes on and clicks a button, which is behind my VS window and, of course, fails as a required windows did not open after clicking.
Is there a way to put the application window into foreground?

Will the solution to the problem?


Update Readme to reflect current toolboxes

Clearing operations was still referring to a toolbox for ArcMap and Pro, this toolbox has been refactored as a python toolbox that will work across both applications.

Thanks @mfunk, can you merge the commit, I don't have access


Gqw/s2 pccl compile

S2动态加载PCCL需求。对于多机，libpccl.so加入LD_LIBRARY_PATH会正常调用，对于单机无libpccl.so的情况，会打印log并使用Fallback的形式

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: Gong-air:x: qqqq seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


veiwing numpy complex data with Data Viewer

Data Viewer does not display numpy complex data

@kopalx Could you provide an example notebook that illustrates this? Not fully sure what type of complex data you are referring to here.

Hi,
I mean complex number. For instance, invoke following code and view it with the data viewer:
import numpy as np
aaa = np.array([1+j,1-j])
BR,
Alex

Dupe of #1610